Thesis Final Version

DYNAMIC GENERATION OF ADAPTATION PLANS FOR SELF-ADAPTIVE SOFTWARE SYSTEMS
a thesis submitted to The University of Kent at Canterbury in the subject of computer science for the degree of doctor of philosophy (phd).
By Carlos Eduardo da Silva May 2011
Abstract
The increasing dynamism and complexity of software systems have driven the search for systems that are able to self-adapt at run-time while dealing with changes in requirements, their environments or the system themselves. One of the characteristics of this class of system is that some of the activities of the software life cycle now need to be performed during run-time. These activities can be captured by dierent processes - sequences of steps for achieving a particular objective - that need to be generated during run-time due to the dynamic nature of self-adaptive software systems. Although there are dierent approaches for generating processes during runtime, these approaches are very specic to their respective application domains, which make them costly to be used across several stages of the software life cycle. Therefore, it is necessary to dene an engineering approach for the dynamic generation of processes for self-adaptive software systems that can be used across dierent application domains. Based on this, the aim of this thesis is the development of a framework for the dynamic generation of processes that factors out common process generation mechanisms and provides explicit customisation points to tailor process generation capabilities to dierent application domains. The framework encompass a reference process for managing the dynamic generation of processes, a reusable infrastructure for generating processes and a methodology for its instantiation in dierent application domains. The framework explores model driven technology for simplifying the generation of processes in dierent domains, and includes faulttolerance mechanisms for dealing with faults during generation and execution of processes. The framework has been evaluated through its instantiation into two application domains (software architectural reconguration, and component-based integration testing).
ii
Acknowledgements
First and foremost, I am deeply thankful to my supervisor, Rogrio de Lemos, e for his encouragement, insightful knowledge and patience. His support over the course of this work has been invaluable, from receiving us into his house in our rst day in the UK, through tough meetings preparing me to face the real world, to the completion of this thesis. Many thanks to my wife, Mrjory Cristiany da Costa Abreu, who joined me in a this adventure of pursuing a Ph.D. Her presence was the main pillar that allowed me to conclude this work. My thanks to the members of the thesis panel, Michel Wermelinger and Eerke Boiten, for carefully reviewing my work and providing valuable comments to elevate its quality. I must not forget to thank Adilson who was also available, even for a silly chat, and together with Gledson, helped me with the rst steps of this journey. Many thanks to all the Brazilian friends (from Erick Lopes who taught me how to cook, Carlos Silla for the weekly afternoon talks and Fernando Otero who saved us from house hunting in our last year!) who were close by (in Canterbury or in Europe) during the time of my Ph.D. and made my adaptation process easier and the one-week-holidays so great. I can not forget to thank all my friend and colleagues of the University of Kent who made my day-to-day life so enjoyable and therefore made the journey of getting the Ph.D. less heavy. A special thanks to the (past and current) members of the Zoo (Ed, Edd, Jael, Luana, Matt, Mex, Patrick, Thomas), the administrative sta of the School of Computing (Sonnary, Angela), and Prof. Sally Fincher who helped in the nal steps of the PhD. Thanks to the friends from outside the School of Computing, specially the members of the Saturday Legion (thanks Peter for organising our weekly football). To my parents and brother, and to my in-laws, who all showed belief in me. And to all my friends who are in Brasil but always have shown interest for me even when I was so far away. They always reminded me where I came from. And nally, I am very grateful to the nancial support given by the Programme Alan, the European Union Programme of High Level Scholarships for Latin America (scholarship no. E07D401107BR).
iii
Contents
Abstract Acknowledgements List of Tables List of Figures List of Publications 1 Introduction 1.1 Research Problem . . 1.2 Approach Overview . 1.3 Thesis Contributions 1.4 Thesis Organisation . ii iii vii xi xii 1 2 4 5 6 7 7 8 10 15 18 22 25 26 26 28 28 30 34 39 40 43 45 49
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
2 State of the Art 2.1 Self-adaptive Software Systems . . . . . . . . . . . . . . . . 2.1.1 Characterising Self-adaptive Software Systems . . . . 2.1.2 Reference Models for Self-adaptive Software Systems 2.2 Processes and Plans . . . . . . . . . . . . . . . . . . . . . . . 2.3 Generation of Processes . . . . . . . . . . . . . . . . . . . . 2.4 Processes and Exception Handling . . . . . . . . . . . . . . . 2.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . 3 A Framework for the Dynamic Generation of 3.1 Introduction . . . . . . . . . . . . . . . . . . . 3.2 Background . . . . . . . . . . . . . . . . . . . 3.2.1 Articial Intelligence Planning . . . . . 3.2.2 Model Driven Engineering . . . . . . . 3.2.3 Coordinated Atomic Actions . . . . . . 3.3 The Framework . . . . . . . . . . . . . . . . . 3.3.1 General Model of the Framework . . . 3.3.2 Types of Workow . . . . . . . . . . . 3.4 The Domain Model . . . . . . . . . . . . . . . 3.5 The Reference Process . . . . . . . . . . . . . iv Workows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
3.6 3.7
3.8
3.5.1 The Strategic Phase . . . . 3.5.2 The Tactical Phase . . . . . 3.5.3 The Operational Phase . . . The Supporting Infrastructure . . . Instantiating the Framework . . . . 3.7.1 Tailoring the Domain . . . . 3.7.2 Tailoring the Process . . . . 3.7.3 Tailoring the Infrastructure Chapter Summary . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
50 54 56 58 62 62 67 68 70 71 71 73 79 79 82 83 86 90 90 91 92 93 96 96 107 123 133 134 136 136 139 141 141 143 144 146 148 149 150 151 153 153 158
4 A Case Study on Architectural Reconguration 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 State of the Art . . . . . . . . . . . . . . . . . . . . . . . 4.3 The Reconguration Domain . . . . . . . . . . . . . . . . 4.3.1 The Architectural Metamodel . . . . . . . . . . . 4.3.2 The PDDL Domain Model . . . . . . . . . . . . . 4.3.3 The Transformation Rules . . . . . . . . . . . . . 4.3.4 The Task Templates . . . . . . . . . . . . . . . . 4.4 The Reconguration Process . . . . . . . . . . . . . . . . 4.4.1 The Strategic Phase . . . . . . . . . . . . . . . . 4.4.2 The Tactical Phase . . . . . . . . . . . . . . . . . 4.4.3 The Operational Phase . . . . . . . . . . . . . . . 4.5 The Reconguration Infrastructure . . . . . . . . . . . . 4.6 Experimental Evaluation . . . . . . . . . . . . . . . . . . 4.6.1 Demonstration of the Reconguration Process . . 4.6.2 Quantitative Evaluation . . . . . . . . . . . . . . 4.6.3 Experiments with Dierent Architectural Features 4.6.4 Discussion . . . . . . . . . . . . . . . . . . . . . . 4.7 Chapter Summary . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
5 A Case Study on Component-based Integration Testing 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 State of the Art . . . . . . . . . . . . . . . . . . . . . . . . 5.3 The Integration Testing Domain . . . . . . . . . . . . . . . 5.3.1 The Integration Testing Metamodel . . . . . . . . . 5.3.2 The PDDL Domain Model . . . . . . . . . . . . . . 5.3.3 The Transformation Rules . . . . . . . . . . . . . . 5.3.4 The Task Templates . . . . . . . . . . . . . . . . . 5.3.5 The Reconguration Sub-domain . . . . . . . . . . 5.4 The Integration Testing Process . . . . . . . . . . . . . . . 5.4.1 The Strategic Phase . . . . . . . . . . . . . . . . . 5.4.2 The Tactical Phase . . . . . . . . . . . . . . . . . . 5.4.3 The Operational Phase . . . . . . . . . . . . . . . . 5.5 The Integration Testing Infrastructure . . . . . . . . . . . 5.6 Experimental Evaluation . . . . . . . . . . . . . . . . . . . v
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
5.7
5.6.1 Demonstration of the Integration Testing 5.6.2 Quantitative Evaluation . . . . . . . . . 5.6.3 Discussion . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . .
Process . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
159 171 177 178 181 182 182 184 186 191 194 199 202
6 Conclusions 6.1 Thesis Contributions 6.2 Discussion . . . . . . 6.3 Limitations . . . . . 6.4 Future Work . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
A Domain Independent Transformation Rules B Domain Specic Transformation Rules for Reconguration C Domain Specic Transformation Rules for Testing Bibliography
vi
List of Tables
4.1 Times obtained for the activities of the reconguration process considering the graph of Figure 4.22 for a conguration with ve components and four connections (5/4) (times presented in ms). . . . Times obtained for the activities of the reconguration process considering the graph of Figure 4.23 for a conguration with ve components and four connections (5/4) (times presented in ms). . . . Times obtained for the activities of the integration testing process (times presented in ms). . . . . . . . . . . . . . . . . . . . . . . . Times obtained for the Translate into workow activity (times presented in ms). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Times for instantiating the IntegrateComponent tasks (times presented in ms). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
114
4.2
116 173 174 174
5.3 5.4 5.5
vii
List of Figures
2.1 2.2 2.3 2.4 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 4.1 4.2 4.3 4.4 4.5 Reference model for self-adaptive systems presented by Oreizy et al. [116]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IBMs autonomic element [82]. . . . . . . . . . . . . . . . . . . . . Three layer architecture model for self-managed systems [95]. . . . Generic feedback control loop [51]. . . . . . . . . . . . . . . . . . The 3+1 organisation architecture of MDE (extracted from [24]). Dierent technical spaces organised in the three layers architecture of MDE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MDE model transformation pattern [85]. . . . . . . . . . . . . . . View of the CAA behaviour (taken from [35]). . . . . . . . . . . . View of the simplied CAA behaviour adopted in this work. . . . General structure for dening workow tasks. . . . . . . . . . . . General structure for implementation of nested task templates. . . Overview of workow generation in relation to the three layer model. Overview of workow generation in relation to the overall feedback control loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simplied PDDL Metamodel. . . . . . . . . . . . . . . . . . . . . Metamodel for the specication of task templates. . . . . . . . . . Overview of the process for managing workow generation and execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of the activities of the strategic phase of the generation process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of the activities of the tactical phase of the generation process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of the activities of the operational phase. . . . . . . . . Overview of the supporting infrastructure of the framework. . . . Detailed view of the Translate into workow activity. . . . . . . . . Instantiation of the MDE transformation pattern. . . . . . . . . . Architectural metamodel based on xADL 2.0. . . . . . . . . . . . Task template implementation of the Connect task using an Yawl diagram (connect.yawl). . . . . . . . . . . . . . . . . . . . . . . . . Overview of the strategic phase of the reconguration process. . . Overview of the tactical phase of the reconguration process. . . . Overview of the infrastructure for supporting the reconguration process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12 13 14 31 33 34 37 37 38 39 40 42 46 48 50 51 55 57 58 60 63 81 89 91 92 93
viii
4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26
4.27 4.28 4.29
Detailed view of the Translate into workow activity of the reconguration process. . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Example of abstract architectural congurations. . . . . . . . . . 98 Example of a generated abstract workow for establishing the abstract conguration of Figure 4.7c. . . . . . . . . . . . . . . . . . 101 Example of concrete conguration for abstract conguration of Figure 4.7c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Example of concrete workow for the experiments without failures. 102 Example of a generated recovery workow for experiments with recovery at tactical phase. . . . . . . . . . . . . . . . . . . . . . . 103 Example of new concrete conguration for abstract conguration of Figure 4.7c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Example of a new concrete workow. . . . . . . . . . . . . . . . . 104 Example of a generated recovery workow. . . . . . . . . . . . . . 105 Example of a generated abstract workow for abstract conguration of Figure 4.7b. . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Example of a concrete conguration for abstract conguration of Figure 4.7b. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Example of a generated concrete workow. . . . . . . . . . . . . . 107 Example of concrete conguration with nine components and eight connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Reconguration process identifying the activities considered during the experiments. . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Reconguration process based on the approach of Arshad et al. [11]. 110 Reconguration process based on the approach of Ranganathan and Campbell [121]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Results obtained when comparing Our and Arshads processes without and with failure during execution of the generated workow. . . . 113 Results obtained when comparing Our and Ranganathan processes without and with failure during execution of the generated process. 115 Example of abstract congurations with dierent number of components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Time for generating a concrete workow for a xed abstract conguration changing the number of components available. . . . . . 118 Comparison between Our and Ranganathan processes xing the size of the conguration and changing the number of components available. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Times of the individual activities of both processes, changing the number of components available. . . . . . . . . . . . . . . . . . . 120 Comparison between Our and Ranganathan processes changing both the size of the conguration and the number of components available.121 Times of the individual activities of both processes, changing both the size of the conguration and the number of components available.122
ix
4.30 Example of a generated abstract workow for establishing a conguration with three components considering components in the quiescent state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 4.31 Impact of considering dierent architectural features xing the size of the conguration and changing the number of components available. a)our reconguration process; b)Ranganathan process. . . . 127 4.32 Software architecture of the web shop example application. . . . . 129 4.33 Example of a generated abstract workow for replacement of stateful component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 5.1 Metamodel for component-based integration testing. . . . . . . . . 142 5.2 Task template implementation for running tests in a component. . 148 5.3 Activities of the strategic phase of the component-based integration testing process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 5.4 General view of the tactical phase of the component-based integration testing process. . . . . . . . . . . . . . . . . . . . . . . . . . . 152 5.5 General view of the architecture for supporting the componentbased integration testing process. . . . . . . . . . . . . . . . . . . 154 5.6 Detailed view of the Translate into workow activity of the componentbased integration testing process. . . . . . . . . . . . . . . . . . . 155 5.7 Possible abstract congurations for the web shop example application.160 5.8 Example of abstract workow for integrating and testing the abstract conguration of Figure 5.7a. . . . . . . . . . . . . . . . . . 162 5.9 Abstract sub-workow associated with the IntegrateComponent (C4) task considering the abstract conguration of Figure 5.7a. . . . . 162 5.10 Example of concrete conguration for used in our experiment without failure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 5.11 Example of generated concrete workow based on the PDDL plan of Listing 5.6 and concrete conguration of Figure 5.10. . . . . . . 163 5.12 Concrete sub-workow associated with the IntegrateComponent (PCWP1) task. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 5.13 System conguration after failure of the TestComponent(PCWP1) task. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 5.14 Example of generated recovery workow. . . . . . . . . . . . . . . 165 5.15 Example of sub-workow associated with the Restore conguration task of the recovery workow for experiments with recovery at tactical phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 5.16 New concrete conguration replacing PCWP1 (the component that failed the test) with PCWP2. . . . . . . . . . . . . . . . . . . . . . 166 5.17 Example of a new concrete workow for integration testing generated during our experiments with recovery at the tactical phase. . 167 5.18 Example of concrete sub-workow associated with the IntegrateComponent(PCWP2) task. . . . . . . . . . . . . . . . . . . . . . . 167 5.19 Conguration after failure of the TestComponent(PCWP2) task. . 168
5.20 Example of sub-workow associated with the Restore conguration task of the recovery workow for experiments with recovery at strategic phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 5.21 Example of generated abstract workow for the conguration of Figure 5.7a. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 5.22 Abstract sub-workow associated with the IntegrateComponent (C4) task considering the abstract conguration of Figure 5.7b. . . . . 171 5.23 Concrete conguration based on abstract conguration of Figure 5.7b. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 5.24 Concrete workow generated based on concrete conguration of Figure 5.23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 5.25 Concrete sub-workow associated with the IntegrateComponent (PCNP1) task considering the concrete conguration of Figure 5.23. . . . . 172 5.26 Integration testing process identifying the activities considered during the quantitative experiments. . . . . . . . . . . . . . . . . . . 173 5.27 Example of abstract congurations with dierent number of components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 5.28 Time for generating a workow varying the size of the conguration.176 5.29 Time for individual activities of the integration testing process, varying the size of the conguration. . . . . . . . . . . . . . . . . 176
xi
List of Publications
Journal papers: 1. Da Silva, C. E. and De Lemos, R. A Framework for Automatic Generation of Processes for Self-Adaptive Software Systems. Informatica (Ljubljana) special issue on Autonomic and Self-Adaptive Systems, 35:3-13, 2011. Conference papers: 1. Da Silva, C. E., De Lemos, R. Dynamic Plans for Integration Testing of Self-adaptive Software Systems. In ICSE 2011 6th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS 2011), 2011. 2. Da Silva, C. E., De Lemos, R. Towards the Use of Dynamic Workows for Coordinating the Self-adaptation of Software Systems. In: 31st International Conference on Software Engineering - Doctoral Symposium, p.383 386, 2009. 3. Da Silva, C. E., De Lemos, R. Using Dynamic Workows for Coordinating Self-adaptation of Software Systems. In ICSE 2009 International Workshop on Software engineering for adaptive and self-managing systems (SEAMS 2009), p.86 - 95, 2009.
xii
Chapter 1 Introduction
With the continuous evolution of software technology, software systems are constantly growing in size and complexity, as observed by the move from stand-alone to ubiquitous and distributed systems that are now integrated in dierent ways (e.g., Internet and Web) [39] [128]. This increasing complexity has impacted, among other aspects, the management of these systems, and can be perceived in terms of administrative overheads, higher costs, and higher number of faults [64]. Moreover, the uncertainty and variability associated with the environment of todays software systems have contributed to an increasing demand to deal during run-time with changing goals, unexpected conditions (e.g., failures) and unpredictable environments [128]. Hence, software systems must become more exible, resilient, dependable, congurable, and energy-ecient, just to mention some properties that are expected from future software systems [83]. In a search for new ways to design and manage software systems, researchers of dierent areas of software engineering, as from other research communities, have looked into self-adaptation as a means to attain the above mentioned properties [32]. It is commonly agreed that a self-adaptive software system is able to autonomously modify its own structure and/or behaviour during run-time in order to deal with changes in its requirements, the environment in which it is deployed or the system itself. A self-adaptive system must be able to observe itself and its environment, identify the need to adapt, deciding on how to adapt itself 1
CHAPTER 1. INTRODUCTION
in response to its observations, and execute the adaptation accordingly [116]. Compared to traditional software systems, one of the characteristics of a selfadaptive software system is that the traditional separation between developmentand run-time becomes blurred [15], and some design decisions are moved from development-time towards run-time. After deployment, a self-adaptive software system should continue to adapt in order to deal with changes that might happen during run-time. Due to this, some of the processes associated with the software life-cycle, usually conducted in a controlled environment at development-time, now need to be also performed at run-time in a dynamic and distributed environment and without any human intervention. Processes that manage self-adaptive software systems must be able to deal during run-time with unanticipated changes that may occur in the software requirements, its environment, or software itself, such as changes in the variability of resources, and failures. In this way, these processes depend on several factors that may change during the system operational lifetime, and thus should also adapt depending on changes that may occur. In this context, it is expected that selfadaptive software systems should be able to dynamically generate processes for managing software self-adaptation during run-time. This should take into account the actual state of the system and its environment, in order to deal eectively with the variability and uncertainty involved in software self-adaptation.
1.1
Research Problem
The research problem considered in this thesis concerns the automatic generation of processes for managing self-adaptive software systems. More specically, we are interested in providing mechanisms for the dynamic generation of adaptation plans for self-adaptive software systems. In the following, we briey summarise how existing approaches have dealt with this research problem. Some existing approaches for self-adaptive software systems (such as [20] [45] [68] [87]) explore policy-based mechanisms for the selection of adaptation plans,
where each available plan and the conditions associated with the selection of that plan are dened at development-time using event-condition-action (ECA) rules. These policies expressed as ECA rules dictate the action to be performed when a certain event occurs and the specied condition is satised. However, writing adaptation policies can become a very complicated task when considering complex systems. One of its diculties is the existence of conicts between policies that may only be detected during run-time [45] [81]. Other solutions incorporate utility functions into adaptation policies for quantifying the possible adaptation responses, allowing the selection of the best adaptation plan based on the current state [40]. However, the denition of utility functions may be extremely hard, as every aspect that inuences the decision making must be quantied [81]. The main problem with these approaches is the necessity of dening adaptation policies during development-time, as it is dicult to anticipate all possible contexts when adapting these systems. For example, resources considered when designing the adaptation policies may not be available during system execution. In order to deal with this problem, it is necessary to dene mechanisms for providing a self-adaptive software system with the capability for generating during run-time adaptation plans that allow the system to modify itself. Otherwise, the self-adaptation process would cease to be consistent with the actual system that it controls, since the adaptation process would not be able to consider the actual system state. Currently, we can nd a wide range of techniques in several application domains that support the dynamic generation of processes, such as, web service composition [52], grid computing [50], software management [10], and architectural reconguration [11]. However, these approaches present solutions that are specic to their respective domains, which are dicult to be reused across domains [50], and in some cases, within the same domain [11]. Therefore, it is necessary to dene an engineering approach for the dynamic generation of adaptation plans for self-adaptive systems.
1.2
Approach Overview
Considering that self-adaptive software systems should be able to dynamically generate processes in order to deal with unanticipated changes, in this thesis, we propose an engineering approach for the dynamic generation of processes for selfadaptive software systems that can be applied across dierent application domains. Our approach consists in the denition of a framework for the dynamic generation of processes that factors out common process generation mechanisms and provides explicit customisation points to tailor process generation capabilities to dierent application domains. The framework encompasses a reference process for managing the dynamic generation and execution of adaptation plans, a reusable supporting infrastructure that enables the generation of processes, and a methodology for its instantiation into dierent application domains. The framework is based on a combination of several techniques, such as, model transformation, articial intelligence (AI) planning and workows. Model transformation is employed for simplifying the generation of processes in dierent domains by translating domain specic models into planning problems. AI planning is used to dynamically generate the processes, while workows are used as a means to represent processes. In order to increase the scalability of the framework, the generation of processes is split into two levels of abstraction, namely, strategic and tactical, whose interaction is based on the explicit representation of feedback control loops [32]. The framework also employs principles from atomic actions as a mechanism for structuring the generation and execution of workows in order to incorporate exception handling as a mean for the provision of fault-tolerance. In order to evaluate our framework, it has been instantiated in two application domains. The rst instantiation considers the generation of workows
for managing software architectural reconguration, while the second instantiation involves the generation of workows for managing the integration testing of component-based software systems. These case studies have been used for performing a series of experiments that demonstrate the feasibility of our framework.
1.3
Thesis Contributions
In summary, the aim of this thesis is the design and implementation of a framework for the dynamic generation of processes that can be instantiated into dierent application domains. This thesis presents a number of contributions in pursuit of this aim. The main contribution of this thesis is the denition of a reference process, and its supporting infrastructure, for managing the dynamic generation of processes. Existing approaches for process generation are very specic towards their respective application domains, incorporating domain specic activities and components into the generation. Both the reference process and its supporting infrastructure provides explicit customisation points that can be used to tailor process generation into dierent application domains. Based on the reference process and its supporting infrastructure, another contribution is the denition of a methodology for providing self-adaptive systems the capability of generating processes during run-time. With this, our framework not only can be applied to dierent domains, but also clearly identies what and how should be modied for supporting changes in the generation of processes, such as, the replacement of the technique used. Another contribution of this thesis is the exploration of model transformation techniques for translating domain specic models into planning problems. Existing approaches for the generation of processes require the specication of domain specic models using a planning language, which make it dicult to use domain specic tools that rely on these models for dierent purposes. Moreover, some approaches dene the generation based on a particular process specication language. The use of model transformation techniques increases the portability of our approach by maintaining a separation between domain specic and planning concerns, allowing the use of dierent planning techniques, process specication languages and/or execution environments.
1.4
Thesis Organisation
The rest of this thesis is organised as follows. Chapter 2 presents a literature review that places our work in the context of other related work. The topics covered in this literature review are: self-adaptive software systems; processes and the representation of adaptation plans; generation of processes; and exception handling. Chapter 3 introduces our framework for the dynamic generation of workows, presenting a review on the dierent technologies that have been used for dening the framework. The chapter then proceeds to describe the main features of the framework and the dierent elements that compose the framework (a series of domain specic artefacts, a reference process, and its supporting infrastructure). Finally, the chapter describes how these elements are modied for instantiating the framework into a particular application domain. Chapter 4 presents our rst case study, which is the architectural reconguration of self-adaptive software systems. The chapter presents a brief literature review on the topic of architectural reconguration, the dierent domain artefacts that have been dened for instantiating the framework, and a reconguration process (and its supporting infrastructure) responsible for coordinating the generation and execution of workows. Finally, the chapter presents some experiments performed in this application domain, and discusses some of the results obtained. Chapter 5 presents a case study in the domain of component-based integration testing. The chapter presents a brief literature review related to integration testing of component-based software systems, and describes the instantiation of our framework in the domain of integration testing, presenting some experiments conducted in this application domain. Chapter 6 presents the conclusions of the thesis, with an discussion on the experiments conducted, a discussion on the thesis limitations and some indications of future work.
Chapter 2 State of the Art

This chapter presents a literature review related to topics of this research, describing its main concepts, and positioning our work in the context of related work. The chapter is structured as follows. Section 2.1 presents an overview on self-adaptive software systems. Section 2.2 presents an overview on the topic of processes and plans, briey discussing how existent approaches represent the processes that coordinate software self-adaptation. Section 2.3 presents a brief discussion on some of the existent techniques for generating processes. Section 2.4 presents a discussion on exception handling in the context of processes, focusing mostly on how processes should be structured.
2.1
Self-adaptive Software Systems
This section is focused on the existing work about self-adaptive systems. As a rst step in the discussion of self-adaptive software systems, it is important to present and discuss some of the characterisations existent in the literature. This is then followed by a discussion on some reference models.
CHAPTER 2. STATE OF THE ART
2.1.1
Characterising Self-adaptive Software Systems
Several attempts have been made in the literature for characterising self-adaptive software systems, e.g., [9] [81] [128]. In the following, we present some of these characterisations and identify how our approach ts into them. One of the most common characterisations is related to how the system is organised in order to achieve adaptation, which can be divided into two approaches [9] [32] [128]. The rst category comprises a top-down approach, where a centralised controller is responsible for managing the aspects associated with the system adaptation. On the other hand, a bottom-up approach, usually referred to as selforganising, is characterised by a decentralisation of control, where several components interact locally without knowledge of the whole system, and the global behaviour of the system emerges from these interactions. Another characterisation corresponds to the dierent properties that inuence the activities of a self-adaptive software system. These properties are commonly known as self-* properties, and their denitions are derived from the properties proposed by IBM in its blueprint for autonomic computing [81] [128]. The IBM autonomic computing blueprint denes four main properties: self-conguration, self-healing, self-optimisation and self-protection [82]. Self-conguration is the capability of reconguring themselves in response to changes. Self-healing is the capability of detecting, diagnosing and reacting to problems. Self-optimisation is the capability of monitoring and tuning resources automatically. Self-protection is the capability of detecting, identifying and protecting against threats. Another characteristic associated with self-adaptive software systems is related to the type of adaptation supported by the system. The type of adaptation varies from parametric adaptation to structural adaptation, and can also be a combination of both [9]. Parametric adaptation involves the modication of the parameters of the system components which determine the system behaviour [103]. One problem with parametric adaptation is that the possible adaptations are limited to behaviours dened during the development of the system that are modied
through its parameters. On the other hand, structural adaptation (also called compositional adaptation) involves changes in the structure of the software system, supporting the replacement of software components. The type of adaptation can also be related to artefact and granularity, and concerns what artefact, attribute or resource is aected by the adaptation, and at which level of granularity [128]. Examples of the dierent types of adaptation can be found in a number of works in the literature. For example, Huebscher and McCann [81], and Salehie and Tahvildari [128], have identied several examples of approaches that consider dierent types of adaptation, including the change of the quality of transmitted data, the change of data type, the tuning of system parameters, the replacement of software components, and the modication of the system structure. Bradbury et al. [29] have also identied a number of approaches dealing with structural adaptation, considering how they deal with the architectural reconguration of self-adaptive software systems. Another aspect is related with the decision making process of a self-adaptive software system, which can vary from static to dynamic [128]. A static decision making process is hard-coded into a self-adaptive software system at development time, while dynamic decision making involves adaptations that are automatically dened by the system during run-time according with the current state of the system and its environment [116]. Huebscher and McCann [81] have identied a number of approaches that employ adaptation policies (in terms of eventcondition-action rules) dened during development-time, ranging from the use of utility functions for dealing with possible conicts in adaptation policies, and to aggregation of information about the software system and its environment through the use of models. Going towards dynamic decision making, Salehie and Tahvildari [128] have identied some approaches that provide support for the modication of the decision making process through the use of policies that can be modied during run-time (e.g., [68]), or through the use of high-level goals-based policy where the actions to adapt the system are dynamically dened (e.g., [91]).
10
Considering the dierent characteristics mentioned in this section, our work adopts a top-down approach for self-adaptive software systems, where a centralised controller entity is responsible for the activities associated with the adaptation of the system. Regarding the dierent self-* properties, our approach is not restricted to any particular property, and can be applied as the means for achieving any one of them. In this thesis, we are focusing on structural adaptability, employing our approach for conducting architectural reconguration and component-based integration testing of software systems. Finally, our work can be characterised as dynamic decision making, since our aim is to provide mechanisms that support the dynamic generation of the process responsible for adapting the software system.
2.1.2
Reference Models for Self-adaptive Software Systems
Several research communities have provided contributions towards the development of self-adaptive software systems [39] [95]. In these dierent contributions, one of the main characteristics of a self-adaptive system is the existence of one or more feedback control loops providing the generic mechanisms for managing software adaptation [32]. In one of the rst works towards the denition of a methodology for the development of self-adaptive systems, Oreizy et al. [116] presented an architecturebased self-adaptation model, supporting two simultaneous processes: system adaptation, and system evolution. An overview of their proposed methodology is presented in Figure 2.1. The life-cycle of system adaptation (Adaptation management) consists in detecting changing circumstances, planning and deploying responsive modications. Monitor and evaluate observations corresponds to all forms of observing and evaluating an applications execution, including for example, performance monitoring, safety inspections, and constraint verication. Plan changes refers to the task of dening an appropriate adaptation, and constructing a plan that contains the steps necessary for executing that adaptation. Deploy change descriptions represent the execution of an adaptation plan, eectively modifying the software system.
11
Figure 2.1: Reference model for self-adaptive systems presented by Oreizy et al. [116]. This model requires an infrastructure for supporting the monitoring and modication of software systems, which is represented by Evolution management. It provides explicit representations of the software architecture and of the environment where the software is deployed (captured by System model). It also provides capabilities for automating tasks within the adaptation loop. The System model is used to reason about changes, and to maintain system consistency. An explicit architectural model of the system is maintained on the implementation platform and used to reason about changes. Changes to the architectural model are reected into the applications implementation, ensuring that the model and the implementation are consistent with one another. The IBMs autonomic computing initiative also proposes a common approach and terminology for developing self-managed autonomic computing systems, describing the architectural building blocks used to construct autonomic systems [82]. This model relies on one or more autonomic elements [90], which deliver services and manage themselves. Figure 2.2 presents an overview of the IBMs
12
autonomic element. An autonomic element consists of a Managed element and an Autonomic manager. The Managed element corresponds to the system, or resource, being managed, while the Autonomic manager is responsible for managing the system adaptation. Managed elements provide standard manageability interfaces (Sensor and Eector), where the Sensor is used for the gathering of information about the Managed element, and the Eector is used for modifying the Managed element.
Figure 2.2: IBMs autonomic element [82]. Autonomic managers implement a feedback control loop that collects details from the system and acts accordingly. The feedback control loop, also known as the MAPE-K control loop, is divided into four functions: monitor, analyse, plan and execution. The four parts communicate and collaborate with one another and exchange appropriate knowledge and data through a knowledge base (the K on MAPE-K). The Monitor function provides mechanisms that collect, aggregate, lter and report details collected from a Managed element, correlating them into symptoms that can be analysed. The Analyse function provides the mechanisms to analyse the collected details to determine if some change needs to be made. If a change is necessary, the Plan function is activated for constructing the sequence of actions needed to achieve the identied goals. The designated change plan is then passed to the last function (Execute), which provides mechanisms that control the execution of plans. These mechanisms schedule and perform the necessary changes
13
to the system, carrying out the procedure that was generated by the plan function. An Autonomic manager can also be a Managed element. This is achieved by providing the manageability interfaces. In this case, an autonomic manager that has a high-level view of the system can orchestrate/coordinate multiple autonomic managers. Another reference model for self-managed systems has been proposed by Kramer and Magee [95], which is shown in Figure 2.3. Their model is based on the three layer model applied in robotics systems proposed by Gat [67].
Figure 2.3: Three layer architecture model for self-managed systems [95]. The bottom layer is the Component control layer, which consists of the set of interconnected components that accomplish the system function. This layer includes facilities to support the manipulation of components (e.g., component creation, deletion and interconnection), and mechanisms to report the current status of components to higher layers, such as event and status reporting. This layer contains feedback loops to adjust the operating parameters of components. The middle layer is the Change management layer, which is responsible for modifying the conguration of the components in reaction to events from the Component control layer, or to new objectives required by the system introduced from the layer above. This layer consists of a set of plans that describe the behaviour of the system towards the goals of the top layer. If a situation is reported for which a plan does not exist, then this layer must invoke the services of the top layer. The top layer is the Goal management layer. This layer deals with the high level goals of the system, producing the plans of the Change management layer in response to
14
requests from the layer below and in response to the introduction of new goals. In all of those reference models, it is possible to identify one or more feedback control loops, which encompass several processes - sequences of steps for achieving a particular objective - that allow a self-adaptive software system to determine the actions to be taken to adapt itself [32]. In this context, our work assumes a generic view of the feedback control loop as introduced by Dobson et al. [51] and presented in Figure 2.4. This generic feedback loop is composed of four key phases: collect, analyse, decide and act.
Figure 2.4: Generic feedback control loop [51]. Collect corresponds to the collection of information about the software system and its environment, which can be achieved through the use of sensors or other sources that are able to capture the current state of the system. The collected information is then analysed for determining the necessity of adapting the system (Analyse phase). This analysis can be based on models, rules and theories. If an adaptation is deemed to be necessary, the next phase must make a decision about how to adapt the system to reach a designated goal state (Decide phase). This phase can rely on the use of risk analysis, decision theory or planning for resulting
15
in an adaptation plan. The Act phase is responsible for executing the adaptation plan, eectively changing the software system through actuators or eectors. Considering the dierent phases of the feedback control loop, the scope of our work is restricted to the decide and act phases. More specically, we are interested in investigating the aspects associated with the generation of the adaptation plans that modify a self-adaptive software system. Taking as a basis the three layer reference model of Kramer and Magee [95], our work is positioned at the Change management layer. In this context, we are focused on the generation of the adaptation plan that modies the system at the Component control layer based on the goals of the Goal management layer.
2.2
Processes and Plans
The management of a self-adaptive software system involves several processes that may aect multiple system components and thus require some kind of coordination for carrying out the adaptation in a concerted fashion. One example of such a process, and the focus of this work, is the adaptation plan that denes the steps necessary to modify a system. This section presents a brief overview of the dierent forms that are used for representing adaptation plans for self-adaptive software systems, and identies the notation used in our work. One of the early forms of expressing software adaptation was by hardwiring the adaptation within the software system source code using, for example, conditional expressions [103] [116]. However, this is a limited solution which complicates software development by intertwining adaptation logic with the software application logic [109]. With the separation between software adaptation and application (in which one of the rst approaches has been presented by Kramer and Magee [94]), several solutions have been proposed as the means for coordinating the adaptation of self-adaptive software systems, ranging from scripting to imperative languages that follow dierent formalisms. According to Huebscher et al. [81], a number of works explore adaptation
16
languages based on event-condition-action rules, where adaptation plans (actions) are associated to events that trigger their use when certain conditions are satised. In this context, the PONDER policy language is one of the most notable examples for the management of distributed systems [45]. Other examples include the work of Baresi and Guinea [17], and Georgas and Taylor [68]. Regarding the use of script-based languages, we can cite the Gerel reconguration language in which rst order logic is used for specifying adaptation plans that are expressed as change scripts [54]. We can also mention the approach presented by Batista and Rodriguez, in which Lua scripts are used for specifying adaptation plans in the LuaSpace environment [19]. Lua scripts have also been used for expressing adaptation plans in the OpenCOM reective middleware environment [84]. David et al. [48] have presented FScript, a scripting language that is used for specifying adaptation plans for the Fractal component-based environment. A number of approaches in the context of software architectural reconguration have been described by Bradbury et al. [29]. These approaches are based on dierent formalisms, including graphs, process algebras, logic and formal methods. Other examples include the CASA framework that employs an XML-based adaptation language (CASA XML-based application contract) [110], and the Clipper adaptation language presented by Agnew et al. [5], which is an adaptation language based on C++. Another example is the stitch adaptation language adopted by the Rainbow framework [40] [65], which is an imperative language for expressing software adaptation in terms of changes to Acme constructs. An important characteristic of that approach is the decoupling between the rules that detect the necessity of an adaptation and the actual adaptation plan that contains the steps for changing the system, dierent from the rule-based approaches, where the adaptation plan is explicitly described in the adaptation policies. Not only adaptation plans are becoming decoupled of the rules that trigger their selection and execution, but it is now possible to nd the use of process
17
coordination languages (i.e., workows) being applied to manage software adaptation (e.g., [133], [144]). Typically, workows allow people and organisations to automate, manage, and improve business processes by coordinating and controlling the ow of work and information between participants. A business process is dened as a set of one or more linked procedures or tasks which collectively realise a business objective or policy goal, dening functional roles and relationships [151]. A workow represents a business process in terms of activities (or tasks) and their relationships, rules and control data. A workow may contain references to sub-processes, separately dened, which make up part of the overall process denition. Workows are manipulated by a Workow Management System (WFMS). A WFMS is a software system which provides support for the denition, management and execution of workows, being able to interact with workow participants, and when required invoke the use of IT tools and applications [151]. In this way, workow management technology can be used for managing software adaptation by representing an adaptation plan as a workow, and exploring a WFMS for controlling its execution. In our work, we employ workow management technology as a means for coordinating the self-adaptation. The choice for workows relies on the fact that workow management technology has reached a signicant level of maturity in the management of business processes by supporting heterogeneous environments and technologies, and dierent distributed computing architectures. The success of the workow technology can be veried by the proliferation of workow management systems, for example, many software companies are providing stand alone workow products or implementing a workow component in their existing software package [136]. Moreover, in the same way that a workow can be used to manage a business process, it can be used to manage a computing system process, being applied to a variety of domains beyond traditional business processes such as DNA sequencing [104], scientic computing [50], and grid computing [34]. Workows have
18
also been explored for managing the adaptation process. Valetto and Kaiser [145] have presented a workow based approach to control and coordinate software adaptation. The approach uses a workow engine, named workakes, to coordinate the execution of mobile agents, which are responsible for eecting software adaptation in a distributed environment. The Task Control and Coordination Service (TCCS) [133] is another approach that combines workows and agents. It explores a distributed workow system and a distributed agent system for creating a framework for service provisioning, where the service behaviour and the service deployment/adaptation are represented as workows.
2.3
Generation of Processes
In our work, we are concerned with the dynamic generation of workows that coordinate the process responsible for adapting a software system (i.e., the workow that represent an adaptation plan). In this context, this section presents a brief literature review on the dynamic generation of workows, describing some of the existing techniques and approaches, and positioning our work amongst the existing literature. Similar to the decision making process of self-adaptive software systems presented in Section 2.1, the techniques for the generation of workows can be classied into static or dynamic [52]. Static (or development-time) techniques for generating workows are employed during development or compile-time, when workows are not expected to change during run-time. On the other hand, dynamic (or runtime) techniques support the generation or modication of workows at run-time in order to handle changes that may occur. Since our aim in this work is to dene a framework for workow generation during run-time, we present a brief overview of some of the existing techniques for dynamic workow generation. By analysing the dierent existing techniques for the dynamic generation of workows, it is possible to further split dynamic workow generation into two
19
distinct categories. This division is based on the inputs of the generation and explores a division of workows into two levels of abstraction: abstract and concrete [50]. An abstract workow describes the structure of the workow in terms of its tasks and the data dependencies among them without identifying the resources used during execution, while a concrete workow identies the actual resources associated with the tasks and is ready to be executed. In this way, an abstract workow can be mapped into several concrete workows by using dierent combinations of resources. Based on this, techniques of the rst category receive as input an abstract workow with its structure, and generate a concrete workow by identifying the appropriate resources that will be used during its execution. On the other hand, the techniques of the second category automatically create the workow structure and select the appropriate resources that dene the concrete workow. Among the approaches of the rst category (which receive an abstract workow as input), we can cite: JOpera [78], the Yawl Worklet Service [1], eFlow [37], and OPENow [77]. The JOpera [78] is an example of a distributed workow engine that employs late binding mechanisms for the generation of concrete workows. Late binding mechanisms allow the identication of the resources to be used by the workow tasks when they are actually needed [77] [88]. JOpera has an architecture composed of navigators and dispatchers. Navigators control workow instances, while dispatchers deal with tasks. These two elements can be distributed, and dispatchers (tasks) are dynamically allocated for execution in dierent hosts based on the workload. The Yawl Worklet Service [1] provides a mechanism for dynamic workow composition for the Yawl WFMS [146]. Yawl is a WFMS that has a service oriented architecture, supporting the integration of custom services to the workow engine, and providing a workow language with a formal foundation based upon Petri nets. A worklet is a workow specication that acts as a subworkow and handles a specic task in a composite process. Worklets are kept in
20
a repository and dynamically selected and invoked to compose a workow at runtime. The selection is made according to data values within the workow instance, using an extensible set of rules with associated exceptions, organised in a binary tree structure, known as Ripple Down Rules (RDRs). The RDRs are stored in a repository that, like the worklets repository, can be changed at anytime. The eFlow [37] is another approach that oers support for dynamic workow generation through late binding mechanisms. It provides mechanisms for the dynamic selection of resources through selection rules associated to abstract tasks of the workow, and allows the denition of dierent types of dynamic tasks, including tasks that can be executed multiple times in parallel, and generic tasks that are dened during run-time. OPENow [77] is a distributed transactional workow system. It has a task model that enables exible workow composition through the use of tasks that can be dened during run-time. It also supports dynamic workows through late binding mechanism. As previously mentioned, these approaches require an abstract workow describing the workow structure as input. On the other hand, the techniques of the second category automatically create the workow structure and select the appropriate resources for dening concrete workows. Techniques of this category usually involve the use of a library of tasks with associated pre- and post-conditions, where dierent techniques/algorithms can be applied for nding the sequence of tasks for a particular objective [10] [50] [100] [142]. Some approaches have developed search-based algorithms for generating workows. Lu et al. [100] consider workow generation as search problem in a search space graph. They have developed a formal model in which workows are assumed to be constructed from a library of tasks with pre- and post-conditions, and algorithms that synthesise a workow from a description and a given tasklibrary. Another approach based on algorithms has been presented by Shankar and Campbell [131]. Their approach explore tasks with pre- and post-conditions for generating workows based on actions (tasks) identied by event-condition-action (ECA) rules. Their focus is on determining the ordering of execution of dierent
21
actions when several rules are activated by a single event. Shepelev and Director [132] have presented an approach for the automatic generation of workows for computer-aided design of very-large-scale integration (VLSI) circuits. Other approaches have explored Articial Intelligence (AI) planning techniques in dierent domains. AI planning concerns the generation of a sequence of actions to solve a problem within a particular domain based on a given initial state [71]. Xiao et al. [153] present an approach for automatic generation of data processing workows in the context of grid computing, where there is a high volume of data and operations. Given a collection of inputs, a collection of desired outputs and a set of operations, their approach uses backtracking-based planning to nd the set of operations that will map the inputs into outputs. In the domain of business processes, we can cite the work of Schuschel and Weske [130], Chun et al. [41] and Ambite and Kapport [8]. In the domain of web service composition we can cite the work of McDermott [102], where a planner and its representation language are extended for dealing with web service composition. Sirin et al. [134] have combined AI planning with semantic web descriptions for composing web services. Other approaches for the generation of workows in the domain of web service composition have been identied by Alamri et al. [6], Dustdar and Schreiner [52], Peer [119], and Rao and Su [122]. AI planning has also been used for dealing with software adaptation. Andrzejak et al. [10] have applied AI planning for generating the workows that coordinate the management of a distributed system, while Arshad et al. [11] have employed AI planning for managing software architectural reconguration, and Ranganathan and Campbell [121] have used planning for the management of pervasive environments. An interesting approach is presented by Deelman et al. [50], whereby an AI planner is explored for generating workows that coordinate physics experiments in a grid environment. Although they generate concrete workows from the user specications, they separate the generation in two stages. In the rst stage, an AI planner generates an abstract workow based on the user requirements, while in the second stage, the abstract workow is mapped into a concrete workow
22
based on the resources available in the grid environment. Another approach that divides the generation in abstract and concrete workows has been presented by Agarwal et al. [4] in the context of web service composition. All these approaches present dierent solutions that are very specic to their respective application domains, intertwining domain specic issues with generation related activities, e.g., issues associated with physical experiments in grid computing environment [50], or the generation of web service compositions [4]. Moreover, these solution require the explicit encoding of domain specic models using a planning specic language, which restricts their use to a xed set of resources (e.g., [121]), or to planning goals envisioned at development-time (e.g., [11]). Our work also follows the division between abstract and concrete workows. However, dierent from the majority of the approaches mentioned, and similar to the approaches of Deelman et al. [50] and Agarwal et al. [4], we generate both abstract and concrete workows. We employ AI planning as the means to generate abstract workows, as it has achieved enough maturity to be applied to dierent application domains, and there are dierent techniques available [112]. Moreover, our focus is the denition of a general workow generation framework that can be applied in dierent application domains.
2.4
Processes and Exception Handling
In our work, we are also interested in the fault tolerance aspects associated with workows. Our intention is to incorporate exception handling mechanisms into our framework for generating workows. This section presents a brief overview on exception handling and how to structure software systems for dealing with faults, followed by a description of some of the existing work on exception handling for workows.
23
Exception handling mechanisms [63][72] provide support for detecting and recovering errors on software systems. Exception mechanisms allow software developers to dene the activities that capture the exceptional behaviour of a software system, and to structure these activities in the system by means of handlers. In order to control the additional complexity associated with the introduction of exceptional behaviour, a software system should be well structured with respect to its normal and exceptional behaviours [63] [120]. Moreover, the implementation of exception handling mechanisms for multi-threaded applications (e.g., concurrent object-oriented systems) is further complicated because the dierent threads must be involved in the handling of an exception. To deal with this, the concept of coordinated atomic actions (CAA) has been dened as a structuring mechanism for coordinating the interaction of multi-threaded applications and ensuring consistent access to objects (resources) in the presence of concurrent and potential faults [154]. It provides a mechanism for structuring coordinated activities integrating conversations (for supporting cooperative concurrency) and transactions (for maintaining the consistency of shared resources, dealing with competitive concurrency) for providing fault tolerance using exception handling [61]. In their seminal work, Avizienis et al. [14] present a taxonomy of faults and fault tolerance techniques, including the dierent error handling techniques that can be used for system recovery. The choice of fault tolerance techniques and their implementation is strongly dependent on the fault model being considered (the assumptions about the faults that can occur in the system). Similarly, some works have tried to identify types of faults that can aect workows [38], and how these faults should be handled [126]. Russel et al. [126] identies a series of exception handling patterns for workows. Their work identies dierent dimensions associated with exception handling, such as, the type of the exception, how the work item that triggered the exception will be handled, how the other work items in the case will be handled, and what recovery action will be taken to resolve the eects of the exception. They then explore the combination of these dimension for identifying the dierent patterns, resulting in a total of of 135 possible
24
patterns. Lerner et al. [98] present a more abstract view of exception handling patterns that have been dened based on the authors experience in developing processes in dierent domains. They have identied three categories of exception handling patterns for processes: 1) considering alternative ways of conducting a task; 2) inserting additional tasks before returning to the normal process execution; and 3) cancelling the current process execution. Their work describes each pattern using dierent modelling languages, providing examples and variations of the patterns. Casati and Cugola [36] have also presented a fault taxonomy for business processes, identifying a taxonomy of exceptions, their possible eects in a process, and dierent recovery approaches and how they are supported by existing commercial tools. Chan et al. [38] have presented a fault taxonomy for workows of web services, identifying the elementary fault classes that they judge relevant for web services composition, as part of their eorts in the denition of recovery patterns for web service composition. These exception handling patterns can be implemented in a number of ways by exploring the dierent exception handling mechanisms for workows. For example, Friedrich et al. [60] deal with exceptions in workows of web services by computing a repair plan based on the current state of the workow, a set of repair actions and rules for applying these actions. A repair plan modies the current workow in order to achieve the desired outcome of the workow. Another example is the work of Greiner and Rahm [76], where event-condition-action (ECA) rules are used for handling exceptions in web service composition. Another ECAbased approach has been presented by Baresi and Guinea [16] [17] where conditionrecovery rules are used for adding self-managing capabilities to BPEL processes. They have dened a language (WS-CoL) for the specication of monitoring rules responsible for collecting and analysing data about BPEL processes, and a language (WSReL) for the specication of recovery strategies, which are composed of a set of recovery actions. Adams et al. [2] have presented an approach based on the Yawl worklet service [1]. They have identied a series of exception types, and exception handling primitives that are used for dening exception handling
25
processes. The dierent exception types are employed for dening the worklet selection rules, while the exception handling primitives are used for dening the worklets that capture the exception handling processes. These exception handling processes (worklets) are dynamically selected based on context of the executing process using the selection mechanisms of the worklet service. In our work, we employ Coordinated Atomic Actions (CAA) as a mechanism for structuring generated workows. Although CAA has shown to be an eective structuring mechanism for dealing with concurrent multi-threaded application, in this work, we are restricting its use for the structuring of sequential workows that are dynamically generated. Regarding the mechanisms for handling exceptions in generated workows, we employ a solution similar to the approach of Friedrich et al. [60], dynamically computing a repair workow for dealing with the exception. However, dierent from their approach, we have restricted the handling of exceptions to backward error recovery.
2.5
Chapter Summary
This chapter has presented a literature review of the topics related to this thesis aiming to provide a context for our work. The chapter has initially identied the scope of our work in the context of self-adaptive software systems. Following that, we have presented the dierent notations and formalisms being used for the representation of adaptation plans, and the notation used in our work (workows). After that, the chapter presented a review on the techniques that can be used for generating processes that have been applied in dierent application domains. Finally, the chapter has presented a review on how exception handling can be incorporated into workows as a means of dealing with abnormal behaviours.
Chapter 3 A Framework for the Dynamic Generation of Workows

3.1 Introduction
One of the main characteristics of self-adaptive software systems is the move from development-time towards run-time, where some of the processes associated with the software life-cycle are now conducted at run-time in a dynamic environment, and without any human intervention. Since these processes depend on several factors that may change during the systems operational lifetime, it is commonly agreed that a self-adaptive software system should be able to dynamically generate processes for managing software adaptation, taking into account the actual state of the system and its environment. Based on this, our work is focused on providing self-adaptive software systems with the capability for the dynamic generation of adaptation plans (the processes that manage software adaptation). In our approach, processes are implemented in terms of workows, and since there are a lot of approaches in several application domains (e.g., grid computing [34], scientic computing [50], DNA sequencing [104]) that employ workows for capturing processes, the denition of a systematic way of generating workows can bring benets to dierent domains. For
26
CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS
27
example, the dynamic generation of workows can be used for controlling the architectural reconguration of software systems, coordinating the execution of Web service compositions, controlling the process of integration testing, or executing experiments in a grid computing environment. This chapter presents a framework for the dynamic generation of processes for self-adaptive software systems. The framework, which can be applied to dierent application domains, consists of a series of artefacts (e.g., domain specic models and transformation rules) associated with a domain model, a reference process, a supporting infrastructure, and a methodology for its instantiation. The framework is based on the use of several concepts and techniques, exploring articial intelligence (AI) planning, model-driven engineering (MDE), feedback control loops and fault-tolerance. MDE techniques are employed for translating domain specic models into planning problems that are used as input for an AI planner. An AI planner generates a plan that is translated into a workow. The generation is structured in terms of feedback control loops, while fault-tolerance concepts (i.e., atomic actions and exception handling) are used as structuring mechanisms in order to provide the means to deal with faults during execution of generated workows. The chapter is structured as follow. Section 3.2 presents some background information on the technologies used in the framework. Section 3.3 denes the context of the proposed framework, presents its general model and main characteristics, and identies two types of workows considered in this work. Section 3.4 describes the dierent domain independent models, metamodels and transformation rules that are used for generating workows in dierent application domains. Section 3.5 presents the reference process for managing the dynamic generation of workows. Section 3.6 describes the infrastructure of the framework, identifying its main components. Section 3.7 presents the steps necessary for instantiating the framework into a particular application domain. Finally, Section 3.8 presents the chapter conclusions.
28
3.2
Background
This section presents a summary of the concepts and technologies used in the denition of the framework, namely, articial intelligence (AI) planning, modeldriven engineering (MDE) and coordinated atomic actions (CAA).
3.2.1
Articial Intelligence Planning
In our research, we explore articial intelligence (AI) planning techniques in order to generate workows. This section presents a brief overview and introduces the main concepts associated with AI planning1 . The objective of AI planning is to nd a sequence of actions that achieves an objective when applied to a particular initial state. A planning problem is represented following a state-transition model, considering the notion of state of the world, and relating actions to transitions between these states. It involves a description of the possible actions which may be executed, a description of the initial state of the world, and a description of the desired goal [71] [112] [119]. Planning has been thoroughly investigated by the AI community, consisting of a family of techniques that can be ne tuned for the situation in which it is being applied [119]. In fact, AI planning research has achieved enough maturity to be employed in dierent applications [112], as demonstrated by its successful application in dierent domains that range from game playing [135] to the control of space vehicles [55], Web service composition [119], grid computing [50], and software reconguration [11]. In order to use AI planning, it is necessary to dene a domain representation and a problem representation. The domain representation includes the predicates available for describing the world state, the possible types for the existent objects, and the actions available in the world. Actions are specied with associated preand post-conditions, which are expressed in terms of the predicates identied in the domain representation. A problem representation includes the objects involved
1
A detailed overview of planning can be found in [71]
29
in the problem, a description of the initial state, and a description of the desired goal. Currently, there is a wide variety of AI planners available, which employ different algorithms and techniques from state-space search to planning graphs and translation into other problems (such as satisability [89] and model checking [42]), with support for dierent heuristics, and extensions for dealing with hierarchical decomposition, and temporal reasoning [119]. With the development of dierent planning systems, several planning languages have been created, supporting dierent levels of expressiveness. One of the rst languages used for planning is STRIPS2 (also called STRIPS notation) [57]. STRIPS was used in the 1970s for describing domains for a robot system. In STRIPS, the state is usually represented as a conjunction of positive literals (propositional and rst-order literals). A goal is expressed as a conjunction of literals that must hold in a particular state. Actions are specied through action schemas, which can be instantiated in a number of dierent actions by instantiating their variables. Actions are specied with associated pre- and post-conditions. An action is only applicable if the pre-condition is satised by the current world state (pre-conditions must hold before an action is executed). The post-condition (or eect) is a conjunction of function-free literals, describing what changes in the state when the action is executed. STRIPS has several restrictions and assumptions, chosen to make planning algorithms simpler and more ecient, but which limit its expressiveness [127]. One assumption is that every literal not mentioned in an action eect remains unchanged. Another restriction is that literals are function-free, guaranteeing that any action schema can be turned into a nite collection of propositional actions with no variables. In this way, all possible values for action variables are considered during planning, which can dramatically increase the number of actions that must be considered in a given problem. Several extensions for the STRIPS notation have been proposed to overcome its
2
STRIPS means STanford Research Institute Problem Solver
30
limited expressiveness. One of these proposals is the Action Description Language (ADL) [118]. ADL extends the STRIPS notation with improved expressiveness supporting, for example, quantied variables in goals, conditional eects for actions and, positive and negative literals in states. Other extensions have been developed, supporting dierent levels of expressiveness, e.g., temporal reasoning (time for executing the task), metrics, and task networks (tasks that can be decomposed into further tasks). This resulted in dierent planning representation languages, making dicult to compare the eectiveness of AI planners in solving real problems. The dierent representation languages have been unied in a standard syntax called the Planning Domain Denition Language (PDDL) [59] [70], which has allowed to compare and exchange benchmark problems between researchers. PDDL supports dierent levels of expression, including subsets for dierent planning notations (e.g., STRIPS, ADL), and having the notion of time, conditional plan and non-determinism. In this thesis, we employ PDDL for expressing planning domains and problems. An advantage of PDDL is that it has been used by many AI planners, allowing us to easily change the planner without any, or little, impact to other elements of our framework for the dynamic generation of workows.
3.2.2
Model Driven Engineering
Our work explores model driven engineering (MDE) techniques as a means to enable the portability of our framework across dierent application domains. MDE aims to manage complexity in software development by increasing the level of abstraction and the level of automation in the development process [24] [25]. The level of abstraction is raised by the use of models at dierent layers. Transformations between these models contribute to increasing automation, where higher level models are transformed into lower level models. These models represent a given aspect of a system, and are specied based on a metamodel, which captures the concepts of a particular domain and denes the relationships among these concepts. A model that follows a particular metamodel
31
is said to conform to this metamodel. The elements of the metamodel are called metaelements. It is important to mention that several model elements may be associated to the same metaelement, and that not all metaelements need to be associated with a model element. It means that a model must conform to a metamodel, and that a metamodel may have dierent models conforming to it [24] [25] [26] [86]. One of the basic principles of MDE is that Everything is a model [24]. This principle, together with the relationship between models and metamodels, allows for an indenite number of layers exploring the conforms to relationship between models and metamodels. In practice, it does not happen, since most works identify three dierent layers [86]. These layers, and the relationships among them, are captured by a 3+1 architecture [24], which is presented in Figure 3.1.
Figure 3.1: The 3+1 organisation architecture of MDE (extracted from [24]). This organisation architecture divides its layers into the real world and the modelling world. The real world, at layer M0, corresponds to the system. The system is represented by a terminal model at layer M1. As previously mentioned, this terminal model must conform to a metamodel located at layer M2. Since the metamodel is also a model, it must conform to a metametamodel located at
32
layer M3. Finally, a metametamodel must conform to itself. The three top levels corresponds to the concerns of the modelling world [24]. The three layers of the modelling world can be found in dierent technological domains. For example, a XML document is considered as an XML model, while a Java program is considered as a Java model. To distinguish between these models, it is necessary to identify the model context. This context is captured by the notion of technical space (TS) [25] [96]. A technical space identies a working context consisting of a set of concepts, body of knowledge, tools and required skills [27] [96]. The concept of technical space is used in MDE to denote dierent technologies at a more abstract level in order to reason about their similarities, dierences and integration [25] [27] [96]. One example of a technical space is the OMG Model Driven Architecture (MDA) standard [107]. The OMG MDA standard is one of the best known MDE initiatives. It promotes the use of models as rst class entities in the software development process, providing a set of guidelines for specifying systems, platforms and transformations between specications (models). One of its objectives is to separate models into Platform Independent Models (PIM) that are neutral descriptions of the system; and Platform Specic Models (PSM) that are bound to a particular technology, and to apply transformations from PIM into PSM. Figure 3.2 shows the three levels organisation of dierent TSs. In the MDA TS, the metametamodel is called Meta-Object Facility (MOF) [107] [113]. It provides a language for dening the abstract syntax of modelling languages. The MDA TS has several standard metamodels at the level M2 that can be used for describing models. One example of a modelling language in the MDA TS is UML, which resides at level M2. UML models (e.g., class diagrams) reside at level M1, and conform to the UML metamodel. In the XML TS, XML documents (level M1) conform to XML schemas (level M2), which in turn conform to the XML Metaschema (level M3). In the Java TS (also known as grammarware TS), the EBNF (Extended Backus-Naur Form) at level M3 is a framework for dening the syntax of programming languages (e.g.,
33
Figure 3.2: Dierent technical spaces organised in the three layers architecture of MDE. Java). These denitions take the form of context-free grammars at level M2 (Java grammar). Syntactically correct Java programs can be dened, at level M1, based on the Java grammar. Models at dierent levels are related through the conforms to relationship. This relationship has dierent meanings in dierent TSs. For example, in the MDA TS it is dened by the MOF language. In the XML TS it is based on the notion of validity of XML documents. In the Java TS (grammarware TS), conforms to means that a sentence is syntactically correct according to the grammar rules. Usually, every TS provide tools for checking the conforms to relation. For instance, in the grammarware TS, these tools are language parsers, and in XML TS, the tool is a validating XML parser. One of the pillars of MDE is the concept of transformation. Transformations allow the generation of dierent artefacts (such as source code or simulation inputs) based on high level models, ensuring consistency between the models and the generated artefacts [107]. These transformations may occur between models of the same TS or between dierent TSs. The transformation between models of the same TS follows the MDE model transformation pattern, which is presented in Figure 3.3 (extracted from [85]).
34
Model transformation in a same technical space is dened through a model transformation language, which is used for dening a transformation program (Tab) that allows the transformation of a model Ma into a model Mb, based on their respective metamodels (MMa and MMb). The transformation program is composed of a set of rules, and should itself be considered as a model, that conforms to a transformation metamodel (MMt). Examples of transformation languages and tools include OMG QVT [115], Kermeta [111], ATL [85] and GReAT [3].
Figure 3.3: MDE model transformation pattern [85]. Transformations between dierent TSs are referred to as bridges [25], and aim to explore the strong characteristics of dierent spaces, where some TSs may perform better than other in a particular problem. One example is the generation of code from UML diagrams, where UML is explored for describing the system, and a programming language is used to execute the system. Examples of transformation tools and languages that can be used across dierent TSs include OMG MOF Model to Text specication [114], Atlas technical projectors [26], and Acceleo3 .
3.2.3
Coordinated Atomic Actions
Workows provide the ability for coordinating the interaction between several participants towards a particular objective. A participant in this context is any
3
http://www.eclipse.org/acceleo/
35
resource involved in the execution of the workow [151]. In the event of an exception during the execution of a workow, some of its participants may have to be involved in the activities associated with the handling of this exception. In order to coordinate the handling of an exception involving several participants, we explore coordinated atomic actions (CAA) as a mechanism for structuring generated workows [44] [49]. This section presents the main concepts associated with CAAs, and how these concepts are mapped into workows. Coordinated atomic actions (CAA) have been initially designed as a structuring mechanism for coordinating the interaction of multi-threaded applications and ensuring consistent access to objects (resources), integrating conversations and transactions for providing fault tolerance using exception handling [61] [154]. Transaction is a mechanism for maintaining the consistency of shared resources. A transaction has four basic properties: atomicity, consistency, isolation and durability (also known as ACID properties), allowing dierent participants (processes/threads) to access resources as if they are at their exclusive disposal, in a manner transparent to the participants (processes/threads) [75]. On the other hand, conversations provide support for cooperative concurrency, where a number of concurrent cooperating participants (processes/threads/objects) enter and leave a conversation concurrently to cooperate towards the execution of dierent activities [120]. A CAA involves multiple roles that are activated by action participants, which cooperate in their activities towards the execution of a service. The CAA participants correspond to the resources involved in the execution of the workow (the workow participants). CAAs can be nested, so that the execution of the system can be viewed as a tree that is dynamically updated. The main rules of nesting are simple: sibling actions cannot overlap; if a participant takes part in an action, it has to take part in the father action; the action is over only if all of its nested actions are terminated. In this context, we consider that the tasks that compose a workow are equivalent to nested CAAs, and must follow the same rules of nesting of CAAs.
36
A CAA execution looks like atomic transactions to the outside world. A CAA starts when all roles have been activated, and nishes when all of them reach the action end, when the dierent roles must agree on the action outcome. Regarding the possible CAA outcomes and how they are achieved, we consider the CAA behaviour adopted by Capozucca et al. [35], which has identied four possible outcomes: normal, exceptional, failure and abort. These outcomes are based on the results of its execution (related to the satisfaction of pre- and post-conditions associated with the CAA), and the handling of exceptions. Figure 3.4 presents a view of the CAA behaviour (using an UML state diagram) of Capozucca et al. [35], identifying its possible outcomes, and associating the outcomes with the state they lead to. The Enclosing context is used to identify the possible states resulted from the CAA outcomes. A CAA is initially at state S0, and is transitioned to state Service when the CAA pre-condition is satised. Service represents the execution of the services associated with the CAA. State S1 is reached when the post-condition is fully satised, representing a normal outcome. In case of an exception during its execution, a Recovery mechanism is activated. This mechanism is dened as a combination of forward and backward error recovery techniques. According with the behaviour presented by Capozucca et al. [35], forward error recovery is attempted rst, and in case it is able to handle the exception, and the post-condition is satised, the CAA nishes with a normal outcome (state S1). If the post-condition is satised, but the recovery is not able to fully handle the exception, the CAA nishes with an exceptional outcome (state S2) and the exception is propagated outside the CAA. If forward error recovery is not possible, backward error recovery tries to undo the eects of the CAA, nishing with an abort outcome (state S0) in case of success in the recovery, or with a failure outcome (state S3) in case backward error recovery is not able to deal with the exception. The dierent outcomes, as well as exceptions propagated outside a nested CAA, are handled by the outermost CAA. Thus, in case of an exceptional, abort or failure outcome, the outermost CAA decides what to do to deal with the inner
37
Figure 3.4: View of the CAA behaviour (taken from [35]). CAA outcome. For example, it can try to execute the CAA again in case of an abort outcome caused by a transient fault. The CAA behaviour is used as the basis for dening the behaviour associated with generated workows. However, we are adopting a simplied version of the CAA behaviour, which is presented in Figure 3.5, and considers for now only two possible outcomes: normal or exceptional. Similar to the CAA behaviour, the initial state is the state S0, and the Enclosing context reaches the Service state when a pre-condition is satised. A normal outcome (state S1) is achieved when the post-condition is satised. In case of a problem during the execution of the service, or a violation of the post-condition, the Recovery is activated. Although the CAA concepts provide support for forward and backward error recovery, for now we only consider backward error recovery, always trying to undo the CAA eects, before nishing with an exceptional outcome (state S2). In order to explore our simplied CAA behaviour, we have dened a base
Figure 3.5: View of the simplied CAA behaviour adopted in this work.
38
structure that is used for the specication of generated workows. This base structure is also used for the specication of the tasks that can be used to compose a workow. Figure 3.6 presents the base structure dened, which uses a notation based on UML activity diagrams, identifying two types of ows (normal and exceptional).
Figure 3.6: General structure for dening workow tasks. We have included activities associated with pre- and post-condition checks, respectively, before and after the execution of the associated service. The Service activity represents the specic service to be provided by a task/workow, while the Recovery activity represents the exception handling process associated with the task/workow, which is activated by a problem during the execution of the Service, or by the non-satisfaction (violation) of the Pre-condition or Post-condition. The Recovery activity can be implemented in dierent ways, and must consider the source of exception (Pre-condition, Service or Post-condition). The recovery technique to be used must be dened during the design of the task/workow. This structure also assumes the existence of a mechanism capable of saving the state of the involved resources for the recovery. The execution of the Service can be implemented as a sub-workow, which in itself may consist of several nested task (CAAs). In this scenario, the subworkows must also follow the base structure of Figure 3.6. In case of only one nested sub-workow, its outcome is used to determine the outcome of the Service
39
activity, in other words, the service activity is replaced by the sub-workow that implements the nested CAA.
Figure 3.7: General structure for implementation of nested task templates. In case there are two or more nested CAAs (sub-workows), these nested CAAs are executed sequentially (we do not consider the parallel execution of nested CAAs), as they represent the dierent tasks that compose a generated workow. The sequential execution of the sub-workows (nested CAAs) are used as a replacement for the Service activity (represented in Figure 3.7). The normal outcome of the Service activity is reached when all nested CAAs are successfully executed. Whenever there is an exception in one of the nested CAAs, the execution is interrupted and the Recovery is activated.
3.3
The Framework
Our framework for the dynamic generation of workows is composed of three main elements: a domain model, a reference process, and a supporting infrastructure. The domain model encompasses the domain independent and domain dependent models, metamodels and transformation rules that are used during the generation. The reference process describes the main activities associated with the generation, while the supporting infrastructure identies the dierent components that provide support for the execution of the reference process.
40
Before presenting the elements that compose the framework, this section identies the basis for our work in terms of a general model of the framework. After that, we discuss the dierent ways in which workows can be generated depending on the application domain.
3.3.1
General Model of the Framework
As previously mentioned, we have adopted as a basis for the dynamic generation of workows ideas that have been applied to self-adaptive software systems, such as the three layer reference model for self-managed systems introduced by Kramer and Magee [95] and feedback control loops [32] [51]. Figure 3.8 presents a simplied view of our approach for the dynamic generation of workows based on the three layer reference model. Our approach ts into the Change management layer whereby the workow produced, which is going to change Resources, depends upon the Goals received from the layer above (Goal management layer) and the Current state of the Resources of the Component control layer.
Figure 3.8: Overview of workow generation in relation to the three layer model. The Goals associated with the workow may include preferences and quality of service (QoS) requirements, which are based on the application domain where the generated workow will be executed. For example, in the case of a workow for booking a dinner in a restaurant in the context of a Web service composition,
41
one of the requirements may indicate to look for transportation for the guests, or to nd a restaurant within a certain price range. The Current state reects the actual state of the Resources that can be used for generating the workow. These resources are used during the execution of the generated workow. Our framework for the dynamic generation of processes divides the generation and execution of workows in three phases: strategic, tactical and operational. This partition allows to increase the scalability and performance of the generation process, providing an eective way of dealing with the variability in the resources, and the failures that may occur during the generation and execution of workows. This separation is based on the ideas presented by Lee et al. [97], and is similar to that of strategies and tactics adopted by Cheng et al. [40]. In terms of the dynamic generation of workows, the separation between strategies and tactics implies that at the strategic phase the abstract workows are generated, while at the tactical phase the abstract workows are mapped into concrete workows. An abstract workow, without referring to actual system resources, describes the set of tasks and the data dependency amongst tasks. In a concrete workow the tasks refer to concrete system resources. It is important to note that at the strategic phase, the resources associated with the tasks are referred to by a logical name and a type, which should be sucient to identify the actual resources at the tactical phase. In this way, an abstract workow can be mapped into several concrete workows by using dierent combinations of resources. At the operational phase, the concrete workow is executed. If there is a problem during the execution of a concrete workow, the process goes back to the tactical phase where a new concrete workow is generated, without the need to generate a new abstract workow. If it is not possible to generate a concrete workow (e.g., there are not enough resources), the process goes back to the strategic phase, where a new abstract workow is generated. In the eventuality that it is not possible to generate an abstract workow, the generation nishes with an exception. Regarding the feedback control loop previously presented in Section 2.1, our
42
reference process for the dynamic generation of workows is focused on the Decide and Act phases. Figure 3.9 presents an overall view of the feedback loop, where we can identify its four key phases: Collect, Analyse, Decide and Act, and domain specic Sensors and Eectors, which are responsible for monitoring and controlling (or aecting) the resources.
Figure 3.9: Overview of workow generation in relation to the overall feedback control loop. During the Collect phase, a monitoring activity collects information from the resources that are part of the actual system where the generated workow will be applied. This is achieved through the use of domain specic Sensors, which provide a well-dened interface for the collection of data from the Resources. This phase is highly dependent on the application domain in which the framework is instantiated. The Analyse phase is responsible for analysing the collected information in order to detect the need for generating a workow. Workow generation (and consequently execution of the generated workow) can be started for dierent reasons, including changes in the resources or their environment, and changes in the goals associated with the generated workow. Similar to the Collect phase, this phase is also dependent on the application domain of the framework, which determines how the collected information is analysed and what is the trigger for starting the generation of a workow. This phase is also responsible for stopping
43
the current workow being executed, in case there is one being executed, and for providing the Domain-specic goals that can be used for generating workows. These goals are dened based on the Current state of the Resources and the High level goals. The Decide phase of the feedback control loop is responsible for generating the workow based on the received Domain specic goals, and the Current state. This phase encompasses the Strategic and Tactical phases of the generation process, producing as output a Concrete workow. The Act phase corresponds to the Operational phase of the framework, being responsible for executing the generated concrete workow. This execution may aect the Resources through domain specic Eectors. The Current state of the Resources is monitored for determining if its execution achieved the objectives associated with the generated workow. This phase is also dependent on the application domain where generated workows are being executed, which inuences, among other things, how to execute the generated workow, and how to check for the successful outcome of its execution. Similar to the three layer reference model, if an error occurs at a particular phase, which is not able to handle it, the error is propagated to the previous phase. This is represented through the exceptional ow between the three phases of Figure 3.9.
3.3.2
Types of Workow
Depending on the application domain, we have identied two basic ways in which a workow can be generated based on how it relates to a system considering the eects of its execution, and how this relationship between the generated workow and the application domain may aect the generation process. Workows can either be integral to the system or they can be peripheral to it. A workow is integral to a system if its execution constitutes the system itself. This is the case of workows that implement business processes, where each executed task contributes to the service to be delivered by the business (the goal of
44
the workow). In these workows, the non-functional properties associated with the workow may inuence the non-functional properties of the system itself. For example, the execution time associated with a particular task should inuence the time it takes for the workow to execute, corresponding to the execution time of the system. Moreover, the criteria for selecting which tasks should be part of a workow and how they are composed should be dictated by the requirements associated with the system. For example, in the case of a Web service based business process (a business process composed of Web services), depending on the expected overall execution time of the workow, the appropriate combination of Web services (which correspond to the workow tasks) should be identied to compose the workow. On the other hand, a workow is peripheral to a system if its execution produces (as an outcome) a system, or some part of it, that is expected to deliver the actual services. This is the case of workows, for example, that coordinate architectural reconguration of software systems, where the goal of the workow is to generate a system conguration that can deliver the actual services. In these workows, the non-functional properties associated with the workow have almost no relation with the properties of the system being managed by the workow. Thus, it is expected that the criteria for generating the workow, and the criteria for generating the system from the execution of the workow will be distinct. For example, in the architectural reconguration of a software system, reliability could be a key property for that system, and it may not be considered when generating the workow that would produce the actual system. Thus, it might be the case that a larger workow (in terms of number of tasks) that takes longer to execute and results in a system with a higher reliability is preferable over a smaller workow that runs faster but results in a system with poor reliability.
45
3.4
The Domain Model
As one of the elements of the framework, the domain model captures all artefacts (models, metamodels and transformation rules) that are needed for generating processes. These can be domain independent artefacts that are used across applications, or domain specic artefacts that need to be dened according to the application domain. The domain independent artefacts are a PDDL metamodel used for dening the dierent models associated with planning (i.e., PDDL domain model, PDDL problem model and PDDL plan model ), a set of transformation rules for translating PDDL models into PDDL specications that are used by an AI planner, and a task template metamodel used for specifying the tasks available in an application domain. The domain specic artefacts include a domain specic metamodel used for dening domain specic models, a PDDL domain model capturing the characteristic of the domain that are considered for planning, a set of domain specic transformation rules for translating domain specic models into planning problem models, and the task templates that can be used to generate a workow. In this section, we describe the domain independent artefacts that are used for dening the domain specic artefacts during the instantiation of the framework. We start by presenting the PDDL metamodel and the transformation rules that translate PDDL models (used to represent planning domain, problem and plans) into PDDL specications (the input/ouput of an AI planner). The PDDL metamodel is presented in Figure 3.10 using an UML2 class diagram developed using the Eclipse Modelling Framework (EMF)4 . In this diagram, DomainModel represents the PDDL domain model, which captures the characteristics of the application domain that are considered for planning. We have created elements for representing the PDDL requirements associated with the model (Requirement), the types available in the planning domain (Type), the possible predicates (Predicate), and the available task templates (Action), which may
4
Thus the use of EString to represent String type
46
have one or several parameters (Parameter) with specic types. The Actions preand post-conditions are dened in terms of the predicates of the DomainModel populated with the Action parameters (represented through the ActionPredicate element). We have also considered the case where no types are used in the domain specication (as supported by the PDDL language).
Figure 3.10: Simplied PDDL Metamodel. A PDDL problem model is captured by the ProblemModel element, which contains an identier to the problem (problem attribute) and references to the associated PDDL domain model and to the objects involved in the planning problem (ProblemObject). It also contains attributes for representing the dierent elements that compose a PDDL problem model (init, goal, constraints). The PlanModel element is used to capture a PDDL plan model. It provides an attribute for storing any comments produced by the planner (comments), and is composed of several actions (PlanAction) with their respective parameters. Dierent from the actions of the PDDL domain model, the actions of a plan identify their parameters in terms of the objects involved in the planning problem (parameters link), and contain a reference to their respective Action element (through the actionTemplate link), which must exist in the PDDL domain model (DomainModel). In order to run an AI planner, the PDDL problem model and PDDL domain model need to be translated into planning specications expressed in PDDL (which are referred to as PDDL problem specication and PDDL domain specication,
47
respectively). To do that, we have dened a set of transformation rules based on the dened PDDL metamodel. These are transformations from model to text, and we have applied the Acceleo transformation language5 .
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [ t e m p l a t e p u b l i c pddlProblem2Text ( p : ProblemModel ) ] [ f i l e ( p d d l P r o b l e m F i l e . pddl , f a l s e , UTF8 ) ] ( d e f i n e ( problem [ p . problem / ] ) ( : domain [ p . domain . domain / ] ) ( : o b j e c t s [ f o r ( o : ProblemObject | p . o b j e c t s ) ] [ o . name / ] [ o . t y p e . v a l u e / ] [ / f o r ] ) ( : i n i t [ for ( ini : String | p . i n i t ) ] [ ini /] [/ for ] ) ( : g o a l ( and [ f o r ( g o a l : S t r i n g | p . g o a l ) ] [ goal /] [/ for ] )) [ i f ( p . c o n s t r a i n t s >notEmpty ( ) ) ] ( : c o n s t r a i n t s ( and [ f o r ( c o n s t : S t r i n g | p . c o n s t r a i n t s ) ] [ const /] [/ for ] )) [/ i f ] ) [ / f i l e ] [ / template ]
Listing 3.1: Extract of the transformation rules from PDDL problem model to PDDL problem specication.
Listing 3.1 presents a extract of the rules dened for translating PDDL problem models into PDDL problem specications. This transformation creates a PDDL problem specication by navigating the received ProblemModel (p : ProblemModel in the listing) and obtaining the elements for the dierent parts of a PDDL problem specication. It includes a reference to the associated domain (:domain on line 4), and a list with the objects involved and their respective types (:objects on lines 5-6). The pre-condition is represented by :init on lines 7-8, while the post-condition is represented by goal on lines 9-10. In case constraints are used, they are captured by the :constraints keyword (lines 12-14). In addition to the PDDL problem specication, an AI planner also requires a PDDL domain specication. Listing 3.2 presents a extract of transformation rules that translate PDDL domain models into PDDL domain specications. The elements of the PDDL domain model correspond to the dierent parts that compose a PDDL domain specication le. A PDDL domain model is represented by the variable d dened on line 1. The transformation starts by obtaining the
5
http://www.eclipse.org/acceleo
48
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
[ t e m p l a t e p u b l i c PddlDomain2Text ( d : DomainModel ) ] . . . ( d e f i n e ( domain [ d . domain / ] ) ( : r e q u i r e m e n t s [ f o r ( r e q : Requirement | d . r e q u i r e m e n t s ) ] [ req . value /] [/ f o r ] ) [ i f ( d . t y p e s >notEmpty ( ) ) ] ( : t y p e s [ f o r ( t : Type | d . t y p e s ) ] [ t . value /] [/ f o r ] ) [/ i f ] ( : p r e d i c a t e s [ f o r ( pred : P r e d i c a t e | d . p r e d i c a t e s ) ] [ pred . v a l u e / ] [ / f o r ] ) [ f o r ( act : Action | d . a c t i o n s ) ] ( : a c t i o n [ a c t . name / ] : p a r a m e t e r s ( [ f o r ( para : Parameter | a c t . p a r a m e t e r s ) ] . . . [ / f o r ] ) : p r e c o n d i t i o n ( and [ f o r ( p r e d i : P r e d i c a t e | a c t . p r e c o n d i t i o n ) ] [ predi . value / ] [ / f o r ] ) : e f f e c t ( and [ f o r ( p r e d i : P r e d i c a t e | a c t . e f f e c t ) ] [ predi . value / ] [ / f o r ] ) ) [/ for ] ...
Listing 3.2: Extract of the transformation rules from PDDL domain model to PDDL domain specication.
identication of the domain model (d.domain on line 2). Then, all requirements (:requirements keyword) are obtained using a loop (lines 3-4). If the domain employs types, they are also obtained (lines 5-7). After that, a loop is used for obtaining the domain predicates (lines 8-9). Finally, for each action contained in the domain model, a respective entry is created in the PDDL domain specication, considering the actions parameters, pre- and post-conditions (lines 10-18). The domain model also includes the tasks that can be used for generating workows, which are captured as task templates. We have dened a metamodel for the denition of task template models, which is presented in Figure 3.11. A model of a task template includes basic information about the task (such as its name and parameters), as well as elds to identify whether the task is associated with peripheral and/or integral workows, and to indicate the task that undo
Figure 3.11: Metamodel for the specication of task templates.
49
the eects of the task template. It also contains a reference to its associated task template specication (taskSpecication), which is an instance of the Action element of the metamodel presented in Figure 3.10, and to the task template implementation (taskImplementation), which corresponds to an identication that can be used to load the implementation of the task in the notation used to execute workows and contains the ow of actions for achieving the respective task. The dierent artefacts presented in this section are used by the dierent activities of the reference process that controls the generation and execution of workows, which is presented in the next section.
3.5
The Reference Process
The activities associated with the generation and execution of workows have been organised in a reference process that follows the partition in three phases presented in Section 3.3.1. Each phase of the dened reference process is composed of several activities6 , where some of these activities are dependent on the application domain in which the generation framework is being used. The reference process is implemented as an Yawl workow, and the dierent artefacts (models) used during the generation are passed between activities in a XMI serialised format. Figure 3.12 presents an overview of the reference process for dynamic generation of workows. The Generate abstract workow activity corresponds to the Strategic phase, producing an abstract workow based on the current state and the goals in the application domain. The Generate concrete workow activity corresponds to the Tactical phase, receiving the generated abstract workow as input, and identifying the concrete resources that will be used to produce a concrete workow. Finally, the Execute concrete workow activity corresponds to the Operational phase, where the generated concrete workow is executed. The reference process has two possible outcomes: normal and exceptional. It
Although tasks and activities can be used interchangeably, in this work, activities refer to the steps associated with the reference process for managing the generation of workow, while tasks are associated with the generated workow.
6
50
Figure 3.12: Overview of the process for managing workow generation and execution. nishes successfully (normal outcome) in case the generated workow is correctly executed. In case of a problem in its execution, the process goes back to the tactical phase, where a new concrete workow is generated, and then executed at the operational phase. In case of problems at the tactical phase, the process tries to generate a new abstract workow at the strategic phase. The process nishes with an Exceptional outcome in case it is not possible to generate a new abstract workow. In the sequel, we detail the activities of each phase (strategic, tactical and operational).
3.5.1
The Strategic Phase
This section details the activities associated with the strategic phase of the reference process. The main objective of this phase is the generation of an abstract workow, which takes into account a library of tasks templates (with associated pre- and post-conditions), the workow goals, and the workow initial state. For generating abstract workows, it is necessary to rst obtain the initial state (which is the current state of the resources of the system), and the goals associated with the workow. The initial state and goals are then translated into pre- and post-conditions expressed in a planning description language, which are used as input for an AI planner. The planner result, in case a plan has been
51
found, is then translated into an abstract workow that is passed to the tactical phase. In case it is not possible to nd a plan, or there is a problem at the tactical phase, the initial state is updated and a new goal must be selected. In case it is not possible to nd a goal based on the current state, the process nishes with an exceptional outcome.
Figure 3.13: Overview of the activities of the strategic phase of the generation process. The activities of the strategic phase are presented in Figure 3.13, in which we can identify two types of activities. Domain specic activities are responsible for providing the inputs needed through the generation, and should be dened during the instantiation of the framework depending on the application domain in which the framework is being used. Domain independent activities are those activities that can be reused across dierent application domains without modications. In the following, we detail each one of these activities. Obtain current state The Obtain current state activity is responsible for obtaining the current state of the system resources, which corresponds to the workow initial state used in the generation. The way the current state is obtained is highly dependent on the application domain, and is represented in terms of a domain specic model. Thus, this activity must be dened at the moment of the instantiation of the framework. In case of problems during the generation, the process restarts from this activity, where the current state of the system resources is updated.
52
Obtain domain specic goals The Obtain domain specic goals activity is responsible for obtaining the domain specic goals that correspond to the workow goals. This activity depends on the application domain in which the framework is being instantiated, and might consider the current state of the system for producing the goals of the workow using a domain specic model. We also assume that, if there is a problem during the generation, the previous selected goal can not be achieved, and a new goal must be attempted. If Obtain domain specic goals activity is not able to identify a goal for the workow, it nishes with an exception that is interpreted as an Exceptional outcome of the generation process. Translation into pre/post The Translate into pre/post represents the activity of translating the initial state and goals into pre- and post-conditions. This activity receives as input the domain specic goals and the current state expressed in a domain specic model, and employs model transformation techniques [85] for translating them into a PDDL problem model, which is produced as the output of the Translate into pre/post activity. This translation is necessary in order to run the planner and, as the translation is achieved through domain specic model transformation rules that are dened during the the instantiation of our framework, this activity does not need to be modied. Run planner Once the pre- and post-conditions have been translated into a PDDL problem model, the next step is the execution of the planner (Run planner activity). For doing that, it is necessary to provide: a PDDL domain specication which contains, among other information, the possible task templates that can be employed for generating the plan, and a PDDL problem specication, which captures the
53
pre- and post-conditions expressed in the PDDL problem model produced by the previous activity (Translate into pre-/post). The PDDL domain specication is automatically generated based on the PDDL domain model dened during the instantiation of the framework. Before running the planner, this activity obtains the task template models from a repository and uses them to populate the PDDL domain model. The PDDL domain model (with the task templates) and the PDDL problem model are then translated into PDDL specications (PDDL domain specication and PDDL problem specication respectively) through the use of the domain independent transformation rules presented in Section 3.4. Finally, the PDDL domain and problem specications are used by a planner for generating a PDDL plan specication, which is then translated into a PDDL plan model that is passed to the next activity. Depending on the planning technique used, there may be several alternatives of generated plans. In our approach, we do not deal with these alternatives, which are considered internally by the planner during its search for a plan based on the heuristic implemented in the planner (such as the number of tasks in the generated plan, or some non-functional property associated with the generated plan). In case it is not possible to nd a plan for a given set of pre- and postconditions, the Run planner activity nishes with an exceptional outcome, and the process goes back to the Obtain current state activity. Translate into workow Once a plan is generated, the last step (Translate into workow) of the strategic phase is a transformation from the format used for representing plans to the format used for representing abstract workows. The Translate into workow activity receives a PDDL plan model (the output of Run planner), and translates it into a workow model based on the Yawl workow modelling language [147] (the format used for specifying workows in our approach). This activity is also responsible for loading the pre- and post-conditions of the generated workow. The workow pre- and post-conditions are dependent on the application domain, and might be
54
based on the current state and domain specic goal previously obtained. The generated abstract workow is then passed to the tactical phase of the generation process.
3.5.2
The Tactical Phase
The main concern of this phase is to allocate the appropriate resources to the tasks of the abstract workow, resulting in the concrete workow (composed of concrete tasks) that can be executed. The way in which the resources are identied is dependent on the application domain. Considering the two types of workows identied in Section 3.3.2, the activities of this phase can be structured in a way that allows the use of one or both of the types. The decision on which type of workow to consider must be made during the instantiation of the framework, and the tactical phase of the reference process must be modied accordingly. When dealing with workows that are integral to the system, the resources of the tactical phase are called tactical tasks, which dene the behaviour associated with abstract tasks of the abstract workow. In case of workows that are a peripheral part of the system, the resources of the tactical phase are called concrete parameters, which are used as the task parameters, replacing the logical names that are used as the parameters of the abstract tasks. Making an analogy to object orientation concepts, the abstract tasks can be interpreted as interfaces, while the tactical tasks are interpreted as the dierent classes that implement these interfaces, and the concrete parameters correspond to the parameters used when invoking a method. Figure 3.14 presents the activities of the tactical phase considering the use of both types of workows (peripheral and integral). The rst activity at the tactical phase, Extract abstract tasks, consists in extracting the abstract tasks that compose the received abstract workow. This domain independent activity is responsible for identifying the abstract tasks that will be considered during the remainder of the tactical phase. This is achieved by querying the task template model of each
55
task that compose the abstract workow.
Figure 3.14: Overview of the activities of the tactical phase of the generation process. The next activity (Select concrete parameters) is responsible for identifying the concrete parameters of a peripheral workow, producing domain specic models from which the concrete parameters are obtained. This is a domain specic activity that must be dened during the instantiation of the framework. Depending on the application domain, the Extract abstract tasks and Select concrete parameters activities can be executed in parallel. However, for simplicity reasons, we only consider the sequential execution of the activities of the reference process. Once the concrete parameters have been identied, they are used by the Replace tasks parameters activity as replacement for the logical names in the abstract tasks. This is done by using the logical names for querying the concrete parameters from domain specic models that are received as inputs. These tasks, with the concrete parameters identied, are then used in the next activity (Select tactical tasks) for selecting the tactical tasks of an integral workow. This activity is also dependent on the application domain, and must be associated with the technique being employed for the selection during the instantiation of the framework. Finally, the Associate concrete tasks activity receives the concrete tasks with their concrete parameters and tactical tasks identied, and uses them to replace the abstract tasks of the abstract workow, resulting in a concrete workow, which is then passed to the operational phase. The tactical phase is structured for considering the occurrence of exceptions
56
during generation and execution of workows. If errors are detected while executing the generated workow, the ow is diverted from the operational phase to the tactical phase for new tactical tasks to be selected. If no tactical tasks can be selected based on the concrete parameters, new concrete parameters are selected and the process is repeated. If it is not possible to identify the concrete parameters, the tactical phase nishes with an exception, and the process goes back to the strategic phase. As previously mentioned, the activities of the tactical phase can be structured in dierent ways based on the application domain and the type of workow being considered. For example, the recovery path (Exceptional ow) can be modied to go straight to the Select concrete parameters activity in case of a problem at the operational phase. Another example is the customisation of this phase for the generation of peripheral workows by eliminating the Select tactical tasks activity, since the generation of this type of workow considers only the replacement of concrete parameters. On the other hand, the tactical phase could be customised for the generation of integral workows by eliminating the Select concrete parameters and the Replace tasks parameters activities
3.5.3
The Operational Phase
The operational phase of the reference process is responsible for controlling the execution of the generated concrete workow, and for generating and executing a recovery workow in case errors occur while executing the concrete workow. An overview of the activities of this phase is presented in Figure 3.15. The Execute concrete workow activity corresponds to the generated workow, which is structured as a sequence of CAAs (presented in Figure 3.7). This phase involves the check of the pre-/post-conditions associated with the generated workow (Check pre-condition and Check post-condition), before and after the execution of the workow tasks. Pre-condition checks detect changes in the current state since the generation started, and conrms whether the generated workow is applicable in the current state or not. Post-condition checks are used to conrm the
57
successful execution of the generated workow. These checks are dependent on the application domain in which the framework is being instantiated, and may be based on the use of domain specic models and tools.
Figure 3.15: Overview of the activities of the operational phase. The Recovery activity represents the activation of a recovery mechanism in case of a violation of one of the pre-/post-conditions or a problem during workow execution, and can be achieved in a number of ways, exploring dierent mechanisms [14]. For now, we rely on backward error recovery as the means for handling errors. When the Recovery is activated, the Generate recovery workow activity generates a recovery workow, which is dependent on the application domain and its underlying execution infrastructure. In this way, this activity must be customised during the instantiation of the framework. For now, we provide two mechanisms for supporting backward error recovery: the undo of the generated workow, which considers the tasks of the workow for identifying the tasks that undo their eects, and the use of the AI planner for the generation of a concrete workow that brings the resources aected to the state before the execution of the generated workow. The recovery also considers the source of the exception (Check workow pre-condition, Execute generated workow or Check workow postcondition). In case of a problem in the execution of the generated workow or in the post-condition, a recovery workow is generated, while in case of violation of
58
the pre-condition, the recovery workow will not have any tasks. The recovery workow is then executed by the Execute recovery workow activity for recovering the state of the system resources to one that preceded the execution of the workow. This should be performed before the control of the process is passed to the tactical phase.
3.6
The Supporting Infrastructure
This section describes the components that compose the supporting infrastructure of the framework, which is presented in Figure 3.16. All elements have been implemented in Java, and the communication among them uses Web service technology. We distinguish between the components that are provided by the framework (Domain independent components), components that must be customisable in some way during the instantiation of the framework (Customisable components), and components that are specic of the application domain (Domain specic components). It is important to mention that the instantiation of the framework into an application domain may require other Domain specic components apart from the ones identied in this diagram.
Figure 3.16: Overview of the supporting infrastructure of the framework.
59
A workow management system (WFMS) is responsible for controlling the generation and execution of workows, interacting with all other components of the infrastructure for generating a workow, and aecting the Resources of the application domain. Workow specications are modelled using the Yawl workow modelling language [147], and are executed in the Yawl Workow Management System (WFMS). In the sequel, we introduce the components of the supporting infrastructure according to the activities of the reference process. We assume the existence of a Starter component, which is responsible for triggering the generation process. This component is dependent on the application domain, and represents a mechanism capable of detecting the need for generating a new workow, and starting the execution of the instantiation of the reference process. The Model translator component is responsible for translating domain specic models into PDDL problem models, providing support for the Translate into pre/post activity of the reference process. This component is implemented based on the Atlas Transformation Language (ATL) [85], which is used for specifying the transformation rules that translate domain specic models into planning models, while models and metamodels are expressed via EMF Ecore7 . The Planner component represents the AI planner used, and implements the Run planner activity. We have explored dierent planning techniques through the use of dierent planners (e.g., Satplan, SGPlan6, LPG-td, LAMA)8 . All the planners considered use PDDL as planning specication language. For using these planners, we have created wrapper components in Java that receive a PDDL problem model and a PDDL domain model as input, and produce a PDDL plan model as output. This component uses the domain independent transformation rules presented in Section 3.4 for creating PDDL domain and problem specications from the received PDDL domain and problem models. The PDDL domain and
Eclipse Modelling Framework (EMF) project Web site: http://www.eclipse.org/emf Participants of dierent editions of the International Planning Competition: http://ipc.icaps-conference.org/
8 7
60
problem specications are used as inputs for an AI planner, which produces a PDDL plan specication. The PDDL plan specication is then translated into a PDDL plan models by a simple parser implemented in Java. The task templates available are stored in the Task templates repository, and task template implementations are dened using the Yawl workow editor. The Workow translator component supports the execution of the Translate into workow activity, translating a PDDL plan model into a workow model based on the Yawl modelling language. This component accesses the Task templates repository for recovering the task template models and task template implementation associated with the tasks of the PDDL plan model. A detailed view of the behaviour of this component is presented in Figure 3.17, using an UML activity diagram notation. It starts by loading the pre-conditions associated with the workow (Load pre-condition). After that, each task that compose the PDDL plan model is processed. Once all tasks of the PDDL plan model have been processed, the workow post-condition is loaded, resulting in an abstract workow.
Figure 3.17: Detailed view of the Translate into workow activity. The iteration through all tasks of the PDDL plan model is represented by the loop in the diagram where the guard [No more tasks] represents that all tasks of the plan have been processed. The processing of each task of the PDDL plan model follows a base structure involving the loading of its corresponding task template implementation (Load task implementation), where the parameters of the PDDL plan model tasks are used as parameters of the task template implementation, and the association of the task implementation as a task of the generated workow (Save sub-workow). This processing can also include other activities, e.g., a task
61
template implementation may require a conguration step after its loading and before it is saved as a workow task. In order to capture this scenario, the diagram includes a choice construct, where each possibility corresponds to a dierent task template available domain (e.g., [task1], [task2], [taskn]). Thus, this component must be modied based on the task templates available in the application domain. The Workow model handler component provides dierent services for manipulating workow models, such as the extraction of workow tasks and parameters, and the replacement of strategical tasks with tactical tasks. This component supports the execution of the Extract strategic tasks, Replace tasks parameters and Replace tasks activities, and is implemented as a simple wrapper based on the API of the Yawl WFMS. The Workow model repository is used for storing the dierent model artefacts used during the generation, such as abstract workows and the extracted abstract tasks. The Tactical tasks selector is responsible for implementing the decision making associated with the selection of tasks in the tactical phase (Select tactical tasks activity), while the Tactical tasks repository is used for storing all available tactical tasks. These components are dependent on the application domain and deal with model representations of the tactical tasks that are used during the process. The Recovery handler component implements the recovery mechanism associated with the Generate recovery workow activity. This component uses the services of the Workow model handler, and employs the API of the Yawl WFMS. We assume the existence of a Registry component as part of the infrastructure. This domain specic component is responsible for providing updated information about the Resources. Any modication in the Resources is reected on the Registry through the use of Probes, which employ the resources sensors mentioned previously. We also assume the existence of a domain specic Concrete parameter selector component, which is responsible for selecting the concrete parameters of strategic tasks, providing support for the Select concrete parameters activity.
62
3.7
Instantiating the Framework
This section describes the procedures that need to be followed for instantiating our framework. The section considers the dierent customisation points dened by the framework, identifying the methodology dened for exploring them, and including the dependency relationship between the dierent artefacts that are dened during the instantiation of our framework. Since this chapter abstracts away from the application domain, we do not present examples of the artefacts that are created during the instantiation of the framework.
3.7.1
Tailoring the Domain
The instantiation of the domain model involves the decision on the type of workow being considered (integral, peripheral or both), and the dierent domain specic artefacts that are used during the generation. As previously mentioned, these artefacts are a domain specic metamodel used for dening domain specic models, a PDDL domain model capturing the characteristics of the domain that are considered for planning, a set of domain specic transformation rules for translating domain specic models into PDDL problem models, and the task templates that can be used to generate a workow. The rst step when tailoring the domain model is to specify the domain specic metamodel to be used by our framework, which should be based on the execution environment in which the framework will be applied, and must be represented using EMF models. The domain specic metamodel captures information necessary for dening goals in terms of domain specic models. It can be based on a metamodel that is already established in the application domain (e.g., used by dierent domain specic tools), or it can be specically dened for a particular domain. The domain specic metamodel is used as a basis for establishing the PDDL domain model, where the elements that compose the domain specic metamodel
63
are specied in terms of PDDL predicates and types. The PDDL domain model identies the information from the application domain that should be considered for planning, and also includes the PDDL features being considered, which aect the way the types and predicates are specied. Once the PDDL features, types and predicates have been decided, it is necessary to provide the domain specic transformation rules and the task templates.
Figure 3.18: Instantiation of the MDE transformation pattern. The transformation of domain specic models into PDDL problem models is dened following the MDE transformation pattern [85], which is presented in Figure 3.18. Ecore and ATL represent the tools used for the transformation, where Ecore is used for specifying metamodels, and ATL is the Atlas Transformation Language [85], which is used for specifying transformations based on the object constraint language (OCL). App. domain metamodel represents the domain specic metamodel associated with the application domain. PDDL metamodel corresponds to the PDDL metamodel presented in Figure 3.10. The App. domain model represents the domain specic models capturing the initial state and the goals of the workow, and are used as input for the Transformation rules (representing the
64
domain specic transformation rules), resulting in the PDDL problem model. The domain specic transformation rules are written using the ATL editor plugin for eclipse development environment. For such, it is necessary to identify the domain specic models (in terms of the elements of the domain specic metamodel ) that represent the initial state and the goals of the generated workow. Listing 3.3 presents an example that can be used as a base template for dening transformation rules. It includes references for the metamodels involved, which are identied through URIs9 (lines 1-2). Line 4 declares the variables that can be used during the transformation, where OUT corresponds to the PDDL problem model, IN represents the domain specic model(s), and IN2 represents the PDDL domain model.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 @nsURI PDDL=h t t p : / / p d d l . p d d l m o d e l @nsURI DomainSpecificMetamodel=h t t p : / / domain . metamodel . u r i / module D o m a i n S p e c i f i c T r a n s f o r m a t i o n T e m p l a t e ; create OUT : PDDL from IN : DomainSpecificMetamodel , IN2 : PDDL; rule DomainReferences { from d : PDDL! DomainModel , d o m a i n S p e c i f i c M o d e l : DomainSpecificMetamodel ! AModel to t : PDDL! ProblemModel ( problem < Problem model i d e n t i f i c a t i o n , domain < d , o b j e c t s < Sequence{ d o m a i n S p e c i f i c M o d e l . anElement>c o l l e c t ( c | t h i s M o d u l e . processAnElement ( c ) ) }, i n i t < Sequence{ t h i s M o d u l e . p r o c e s s I n i t i a l S t a t e ( d o m a i n S p e c i f i c M o d e l ) } , g o a l < Sequence{ t h i s M o d u l e . p r o c e s s G o a l S t a t e ( d o m a i n S p e c i f i c M o d e l ) } ) } C r e a t e a p d d l problem o b j e c t from AnElementType o b j e c t lazy rule processAnElement { from e : AnElementType to p : PDDL! ProblemObject ( name < e . a n A t t r i b u t e , t y p e < t h i s M o d u l e . recoverAnElementPDDLType ( ) ) } Return t h e PDDL t y p e a s s o c i a t e d w i t h anElement helper def : recoverAnElementPDDLType ( ) : PDDL! Type = PDDL! Type . a l l I n s t a n c e s ( )> s e l e c t ( t a r g e t T y p e | t a r g e t T y p e . v a l u e = anElementType )>a t ( 1 ) ; Return p r e d i c a t e s s p e c i f y i n g t h e i n i t i a l s t a t e helper def : p r o c e s I n i t i a l S t a t e ( model : DomainSpecificMetamodel ! AModel ) : Set ( String ) = model . otherElement >c o l l e c t ( item | ( PDDLPredicate +item . a t t r i b u t e+ ) )>a s S e t ( ) ; Return p r e d i c a t e s f o r t h e g o a l s t a t e helper def : p r o c e s s G o a l S t a t e ( model : DomainSpecificMetamodel ! AModel ) : Set ( String ) =
9
Universal Resource Identier
65
39 40
model . goalElement > c o l l e c t ( item | ( a n o t h e r P r e d i c a t e
+item . a n o t h e r A t t r i b u t e+ ) )>a s S e t ( ) ;
Listing 3.3: Base template for the denition of transformation rules. The transformation should contain a main ATL rule (line 5) that produces a ProblemModel object (line 7) from the models received as input (line 6). This main rule is divided based on the attributes of a ProblemModel object. problem (line 8) is the identier of the problem model. domain (line 9) is a reference to the PDDL domain model received as input. objects (line 10) includes those elements of the model that are considered during planning. These objects are used during planning for populating the dierent predicates of the PDDL domain model, and are used as parameters of the task templates of a generated plan. init (line 13) captures the workow pre-condition, and should be composed of PDDL predicates that represents the elements of the received models. goal (line 14) represents the workow post-condition, and is also dened through PDDL predicates based on the received models. The ProblemModel attributes (objects, init and goal) are associated with auxiliary rules that must be dened according with the application domain. In this example, the rule associated with the objects attribute (line 11) considers all occurrences of the anElement object in the domanSpecicModel, and processes each one of them (through the collect construct) using the processAnElement auxiliary rule (dened on line 19). This lazy rule receives an object associated with the AnElementType (line 20), and produces a ProblemObject (line 21), where its name attribute receives the content of anAttribute of the received object (line 22), and another auxiliary rule (line 23) is used to obtain the PDDL type that corresponds to AnElementType in the PDDL domain model. Task templates are dened based on the domain specic metamodel, the execution environment, and the PDDL domain model. For each task template available
66
in the application domain, it is necessary to dene a task template model, a task template specication, and a task template implementation. A task template model is used to represent a task template within our framework, and is dened based on the task template metamodel (presented in Figure 3.11). A task template specication is described in terms of the PDDL metamodel presented in Figure 3.10. A task template implementation is dened based on the workow execution environment. A task template model and a task template specication are dened using the eclipse EMF tool, while a task template implementation is designed using the Yawl workow editor. A task template implementation is treated as a subworkow that must follow the structuring based on CAA (presented in Section 3.2.3), and is dened based on the type of workow being considered in the application domain. In case of peripheral workows, a task template implementation is ready to be executed as soon as its parameters are dened. On the other hand, a task template implementation of an integral workow acts as an interface for the concrete task that will be used during execution of the workow, which must be available as a Web service that is referenced through its WSDL address. Besides the task templates available in the application domain, it is necessary to dene task templates that capture the pre- and post-conditions of generated workows. These task templates are based on the domain specic models that represent the workow initial state and goals, and are used for checking whether the generated workow can be executed (pre-condition) and whether its execution has a successful outcome (post-condition). Once the artefacts of the domain model have been instantiated, they can be modied respecting the dependency between them. For example, it is possible to change a task template without aecting the other artefacts of the domain model. On the other hand, a change in the PDDL domain model (e.g., to consider more information about the domain specic metamodel during planning) might require changes in other artefacts (e.g., the inclusion of a new PDDL predicate that needs to be considered by the transformation rules and the task templates). An example
67
of modication of the PDDL domain model is the use of dierent PDDL features (e.g., temporal based planning), which requires new PDDL predicates, changes in the task templates specication (e.g., including the cost of each task) and in the domain specic transformation rules used to translate domain specic models into PDDL problem models (e.g., include the metric used by the planner, such as, minimise the total execution time of the generated plan).
3.7.2
Tailoring the Process
As part of the instantiation of the framework, the reference process (presented in Section 3.5) needs to be instantiated according with the respective application domain. The instantiation of the reference process is achieved using the Yawl workow editor, and involves the association of the dierent activities to their respective components (i.e., the setting of the component WSDL address), the provision of domain specic activities, the removal of the unnecessary activities based on the type of workow being generated, and the adjustment of the exceptional path. Starting with the strategic phase, it is necessary to dene the activities associated with the Obtain current state and Generate domain specic goals. These domain specic activities act as place holders, and may comprise a dierent number of activities depending on the application domain. For example, the generation of domain specic goals may be achieved through a simple web service call, the activation of some legacy component, or through a sub-workow implementing some domain specic process. The other activities of the strategic phase (Translate into pre/post, Run planner, and Translate into workow) do not need to be modied during the instantiation, besides setting the WSDL address of their respective supporting components. Following to the tactical phase, it is necessary to remove any unnecessary activities, and to dene the exceptional ow according with the application domain and the type of workow being considered. The Extract abstract tasks, Replace tasks parameters and Associate concrete tasks activities do not need to be modied.
68
Similar to the strategic phase, the domain dependent activities (Select concrete parameters and Select tactical tasks) act as place holders, and must be associated to the techniques responsible for selecting concrete parameters (or tactical tasks) in the application domain. Once the activities of the tactical phase have been dened, it is necessary to modify the exceptional ow accordingly. The operational phase needs to be modied by dening the steps associated with the Generate recovery workow activity. It involves the use of one of the recovery mechanisms provided by the framework, and may include further modications according with the application domain. Although the reference process can be customised during its instantiation (e.g., augmented with any number of domain specic activities, or incorporated into a larger domain specic process), it imposes a strict structuring regarding the normal execution ow of domain independent activities (e.g., Translate into pre/post, Run planner and Translate into workow). On the other hand, the exceptional ow can be freely modied as to what activity is executed in the event of an exception. An example of such at the strategic phase is the activation of the Obtain domain specic goals in case of an exception of the Run planner activity, while examples at the tactical phase have been presented in Section 3.5.2. The behaviour of domain independent activities can be modied, aecting how a plan is generated, by altering the dierent domain specic artefacts (e.g., domain specic transformation rules, and task templates) and components that support them (e.g., Workow translator component), or by introducing activities that can manipulate the models used/produced by these activities (e.g., introducing a activity that does some processing in a PDDL problem model between Translate into pre/post and Run planner activities).
3.7.3
Tailoring the Infrastructure
Once the domain model has been dened, the infrastructure can be tailored. It involves the provision of the artefacts of the domain model to the components that need them, any necessary component customisation, the addition of domain
69
specic components and the removal of any unused component. The Model translator component is customised by providing the domain specic metamodel and domain specic transformation rules that are used for generating PDDL problem models from domain specic models. The next step is the denition of the planner to be used (Planner component), which will reect the planning technique being applied. The planner must use PDDL as its planning description language and support the PDDL features included in the PDDL domain model. This component is customised during the instantiation of the framework by providing the PDDL domain model, while the task templates are stored in the Task templates repository. New planners can be incorporated into the framework by implementing their corresponding wrappers. The Workow translator components needs to be modied based on the task templates available in the domain, considering whether their processing requires any extra step. The implementation of this component involved the denition of a Java class that can be used for processing task templates that follow the base processing structure presented in Figure 3.17 (Load task implementation and Save sub-workow). In this case, no modication is necessary, as the information available in a task template model is sucient for loading its implementation and setting its parameters. On the other hand, in case a task template requires an extra step as part of its processing, a new class must be dened by extending the base processing class for including the extra steps involved in the processing of the task template, and then registered in the Workow translator component in order to be available during generation. Finally, it is necessary to dene the behaviour of the Recovery handler component, selecting between the two behaviours provided, and making any further modications that are necessary based on the application domain. The available behaviours are implemented as distinguished Java classes that are selected during the instantiation of the infrastructure. The instantiation of the infrastructure also requires the provision of the domain specic components (Starter, Concrete parameter selector, Tactical tasks selector,
70
Tactical tasks repository, Registry and its Probes). The components necessary are dened by the type of workow being generated. Thus, in case of peripheral workow, it is not necessary to provide the Tactical tasks repository and Tactical tasks selector components. On the other hand, when dealing with integral workows, it is not necessary to provide the Concrete parameters selector component. These components must provide Web service interfaces.
3.8
Chapter Summary
This chapter has presented a framework for the dynamic generation of workows that can be applied across dierent application domains. Initially, we have described the basic concepts for the development of the framework. We have then presented the dierent domain artefacts (i.e., metamodels, models and transformation rules) needed for the generation of workows, exploring MDE-based techniques for increasing the portability of our approach. A reference process for managing workow generation and its supporting infrastructure have been presented next. Finally, the chapter described a methodology for instantiating the framework into a particular application domain. In order to evaluate the framework, we have instantiated it into dierent application domains. The supporting evidence of this thesis is presented in the next chapters, which present the instantiation of the framework into two application domains: architectural reconguration (Chapter 4), and component-based integration testing (Chapter 5).
Chapter 4 A Case Study on Architectural Reconguration

4.1 Introduction
This chapter presents, as a case study, an approach for the architectural reconguration of self-adaptive software systems based on the instantiation of our framework for the dynamic generation of workows. Regarding the development of self-adaptive software systems, we explore software architecture for reasoning and conducting software adaptation, where architectural models are used for representing the software system and adaptations consist in the dynamic reconguration of the software architecture of the system [29] [64] [95] [116]. The architecture of a software system may be looked at from dierent perspectives, which characterise the several architectural structures, or architectural views, of the system [18] [56]. We are considering the componentconnector view because it characterises the run-time behaviour and state of the system. In this way, the architecture of a software system can be seen, from a run-time view, as an abstraction of the system structure in terms of its constituent components and connectors. As previously mentioned, our focus is on the decide and act phases of the feedback control loop, assuming the existence of mechanisms responsible for the 71
CHAPTER 4. ARCHITECTURAL RECONFIGURATION
72
other phases (collect and analyse). The decide phase is responsible for identifying an adaptation plan for changing the current system conguration into a new conguration, while the act phase is concerned with the execution of the generated plan. In our work, we abstract away from the problem of selecting a conguration for the system, which can be achieved in a number of ways [7] [140] [152]. Instead, our objective is to generate during run-time reconguration plans which change the system conguration. A reconguration plan contains the sequence of steps necessary for modifying the system conguration, and is captured in terms of a workow that is dynamically generated based on our framework previously introduced in Chapter 3. For instantiating our framework into the domain of architectural reconguration, we need to dene the dierent domain artefacts needed to generate a workow, such as the metamodel used to represent architectural models, dene a reconguration process responsible for managing the generation and execution of the workows that change the system conguration, and dene the necessary infrastructure by extending the supporting infrastructure provided by our framework. In order to evaluate the instantiation of our framework in the context of architectural reconguration, we have performed several experiments, demonstrating what we have called peripheral workows, that is, the generated workows are used for altering the software system responsible for providing the services, and comparing our work against two other approaches that explore AI planning for managing architectural reconguration. The rest of the chapter is organised as follows. Section 4.2 presents a brief literature review considering how existing approaches for the architectural reconguration of self-adaptive software systems deal with the decide phase of the feedback control loop, and briey compares these approaches against ours. Section 4.3 presents the artefacts that have been produced for instantiating the framework.
73
Section 4.4 describes the instantiation of the reference process into a reconguration process for managing the generation and execution of workows. Section 4.5 presents the implemented infrastructure, which supports the execution of the process for architectural reconguration. Section 4.6 presents some experiments conducted in order to evaluate our approach, followed by a discussion of the results obtained. Finally, Section 4.7 presents some concluding remarks considering the instantiation of our framework into architectural reconguration.
4.2
State of the Art
In order to position and motivate our work, this section presents a brief literature review on the architectural reconguration of self-adaptive software systems from the perspective of generating plans for reconguring the system architecture. We start with those approaches that require the denition of reconguration plans at development-time, moving towards the approaches that generate reconguration plans at run-time. According to Sykes et al. [138], there are several approaches for architectural reconguration that rely on the specication of reconguration plans at development-time. Such approaches (e.g., [64], [68]) rely on the use of rule-based techniques for the selection of reconguration plans. These represent reconguration plans as a set of condition-action rules where each available plan and the conditions associated with the selection of that plan are dened at developmenttime. One such approach has been presented by Georgas and Taylor [68] [69], in which they employ adaptation policies, also captured as condition-action rules, for generating the reconguration plans that manage the self-adaptation of software systems. The process of reconguration relies on the use of an architectural model of the system, where the alterations are rst applied to a copy of this model, which is then analysed. If no problems are found, the reconguration is applied to the actual model of the running system.
74
Another approach is the Rainbow framework [40] [64] [66]. Rainbow captures reconguration plans in terms of strategies and tactics. A strategy for solving a particular problem can be achieved by means of dierent tactics. A strategy is composed of a set of condition-action pairs organised in a tree-like structure with dierent execution paths, where each action corresponds to a tactic. Each tactic is composed of a sequence of operators. These operators dene the ways one can change the system architecture (e.g., add or remove components and connectors). Strategies and tactics are manually dened during development-time, while the execution path in the tree of tactics is dened at run-time. If the execution of a reconguration plan fails, the reconguration is aborted, and an exception is raised for notifying a system administrator of the failure. Kim et al. [92] [93] also divide the reconguration into two levels of abstraction and explore reconguration strategies dened at development-time. In their approach, conguration models are divided into abstract and concrete. An abstract conguration model identies the architecture of the system, and is associated to a strategy that contains a set of constraints that must be satised for its use (condition), and the steps necessary for changing the system conguration to this particular architecture (actions). Once a set of strategies has been identied for a particular situation, concrete components are used for building candidate concrete congurations (and reconguration strategies), and the best conguration (reconguration strategy) is selected. There are many other approaches for architectural reconguration dened at development-time. Bradbury et al. [29] identied more than 10 approaches in their survey on dynamic software architecture specications. Other approaches include the works of Bencomo et al. [20] and Parra et al. [117]. A major limitation with these approaches is the fact that it is not possible to anticipate all possible contexts of reconguration for some classes of systems. The generation of reconguration plans must take into account several factors that may change during the systems operational lifetime. For example, one is not able to know at development-time all available components and possible congurations
75
from which the reconguration plans are dened. Another problem is associated with the increasing size of software systems. The combinatorial nature between conditions and reconguration plans not only impacts the number of plans that must be designed, but also the selection and the management of these plans. In order to overcome the limitations of generating reconguration plans at development-time, several eorts have been made towards the generation of reconguration plans during run-time. In this direction, we can cite the work of Autili et al. [13] in the context of the PLASTIC project [12], and the work of White et al. [152]. Both approaches are focused on the selection during run-time of the best conguration for the system based on the state of the environment and the resources required for enabling it. However, there is a price/cost to be paid in these solutions, since these approaches employ the reboot of the software system as the means for changing the system architecture, where the whole software system is deactivated and reactivated with the new conguration. In this way, the replacement of a single component requires the deactivation of all components of the system. An alternative solution to avoid the complete disruption of the service would be to keep running those elements that are unaected by the reconguration, and change only those elements that are aected. In this direction, Dashofy et al. [46] present an infrastructure, developing tools and methods, that permit model-based architectural reconguration of self-adaptive systems. Their approach computes the dierences between two architectural models for identifying the steps necessary to change the old model into the new one. However, the ordering of these steps can not be guaranteed, and the reconguration is achieved by suspending all involving components (and their neighbours) at the beginning of the process, and resuming their execution after all steps have been executed. Alia et al. [7] present an approach for selecting the best conguration for a software system in the context of the MUSIC project, employing the approach of Dashofy et al. [46] for changing the system architectural conguration. Morin et al. [108] also explore model comparison techniques, and these are extended by applying priority
76
rules for ordering the steps of the reconguration plan where, for example, all disconnections must happen before the connections. However, model comparison and priority rules are not enough for generating reconguration plans. Without guarantees about the ordering of the reconguration steps, it can not be applied to a scenario where a component that requires a particular service must be disconnected before being connected to a new component that provides the respective service. Even with priority rules for ordering the reconguration steps, all components involved in the reconguration are suspended for the duration of the reconguration, which does not allow to minimise disruption. Besides not allowing the optimisation of the ordering of the steps of a reconguration plan for minimising the disruption to the system, priority rules are not enough to deal with complex relationships between the reconguration steps, which can be captured by pre- and post-conditions as demonstrated by Shankar and Campbell [131]. Examples of such relationships include components that have dierent life-cycle states that must be reached during the reconguration, and the transfer of operational state between components. The problems associated with the optimisation of reconguration plans, or the possible relationships that must be considered during their generation can be tackled by employing AI planning techniques [71] [112]. Arshad et al. [11] have used an AI planner to generate reconguration plans and to select a new architectural conguration for the system at same time. In their approach, the time it takes for reconguring the system is considered as the only criterion for selecting the system conguration, thus selecting the conguration that takes less time to be instantiated, and not considering other non-functional properties associated with the system. However, it is inevitable for the scalability of the planning task to be aected when combining the selection of the system conguration with the generation of the reconguration plans for changing the system architecture. In the work by Ranganathan and Campbell [121], this problem has been addressed, in the context of pervasive systems, by clearly separating the selection of
77
congurations and the generation of reconguration plans. However, the downside of this approach is again scalability since it considers for the purpose of building reconguration plans all available components from which the services can be obtained. FEEDBACKFLOW [10] is another approach that explores AI planning for the generation of plans. Similar to Ranganathan and Campbells approach [121], FEEDBACKFLOW receives as input the current system state and target system state for generating a plan. In manner similar to Arshad et al. [11] and Ranganathan and Campbell [121], it also includes all available components in the planner, aecting its scalability. Dierently from the above mentioned approaches ([11] [121]), FEEDBACKFLOW is the only approach that explores a workow management system for coordinating the execution of the generated reconguration plan. Dierent from all three mentioned AI planning-based approaches, our work does not include all available components in the AI planner, allowing an increase in its scalability by reducing the planner search space. Another dierence of our work is that it does not need to manually encode the possible congurations and all available components in a planning description language. This not only makes other approaches too complex for non-planning specialists, but also restricts them to components and congurations known at development-time. Dierent from these approaches, we employ MDE techniques for transforming architectural models into planning problems. In this way, our approach abstracts away from the planning description language and technique being employed for generating the plan, supporting the generation of plans to congurations not envisioned at development-time, and simplifying its integration with other solutions that explore architectural models. Another approach that explore plans at run-time is presented by Sykes et al. [137][139][140]. They explore AI planning for generating a reactive plan based on high-level goals. However, the generated plan is not used for adaptation, but to
78
dene the behaviour of the system, and the actions of this plan are used for identifying a conguration for the system. Once a conguration has been selected, the system is recongured based on a process that considers issues such as safe reconguration (exploring the concept of tranquility [149]), transfer of state between components and tries to minimise the disruption of the system. Since the main focus of their approach is on selecting the best system conguration based on high-level goals, they have made a simplication on how to eect changes in the system conguration. In their approach, the interconnection between components is considered as implicit, meaning that a required interface of a particular type is connected to any provided interface of this same type. In this way, the interconnections between components are automatically derived based on their interfaces types, which is sucient for congurations with only one implementation for each provided interface. However, as pointed out by Sykes [137], it restricts the possible applications of their approach. Their approach can not be applied to systems with congurations that involve two or more components that provide the same interface type, e.g., a conguration where a load balance component requires two redundant server components. Comparing with the work of Sykes et al. [137][139][140], our work has a dierent objective. Our aim is to generate the reconguration plans that change the system conguration, while their focus is on how to select the best conguration for a system based on high-level goals. In this sense, their approach can be seen as complementary to ours. Concerning the generation of the steps for changing the system architecture, our approach does not impose any restrictions on the possible congurations for the system. Similar to their approach, our work also supports issues such as safe reconguration, transfer of state between components and minimisation of system disruption. Dierent from their approach, our work considers possible failures during execution of the generated reconguration plan. In summary, our main focus is on the generation during run-time of the reconguration plans for changing the system architecture, however, it assumes the existence of mechanisms responsible for selecting a conguration for the system.
79
In fact, our work can be integrated with any of the existent approaches that tackle the problem of selecting a conguration for the system. Our approach is not restricted to a xed set of components for generating reconguration plans, nor require the inclusion of all available components in the planner, or makes any assumptions about the possible congurations of the system, as we employ MDEbased technology for translating architectural models into planning problems. Our approach is also able to generate reconguration plans during run-time while minimising the disruption to the software system. The partition of our approach into dierent levels of abstraction provides support for dealing with variations in the resource availability and reduces the search space considered by the planner, as it is not necessary to include all available components into the planner, increasing its scalability and performance.
4.3
The Reconguration Domain
This section describes the artefacts that have been dened for instantiating our framework, namely, a domain specic metamodel, a PDDL domain model, domain specic transformation rules, and the task templates available in the domain.
4.3.1
The Architectural Metamodel
The domain specic metamodel is an architectural metamodel, which captures the concepts and properties associated with the architectural elements (e.g., components and congurations). It should consider the underlying execution environment, the assumptions made about the architectural elements, and meta-information related to non-functional properties. The execution infrastructure dictates the features that can be considered during the reconguration, such as, the possible life-cycle states for a component (e.g., quiescent, running, etc.), or if the components are stateful or stateless. In order to explore a particular architectural feature (e.g., transfer of state), the metamodel must allow the representation of the concepts associated with this feature (e.g., if a component is stateful or not, and the
80
current state of stateful components). Thus, the use of a particular architectural feature may require the modication of the metamodel if it does not capture this feature. Our architectural metamodel is an extension to the xADL 2.0 architectural description language [47]. We have created an EMF1 model based on xADL 2.0, and then extended this model allowing the representation of dierent properties of architectural elements. In this way, we are able to use architectural models for representing software components during run-time. Following our division between abstract and concrete workows, architectural models are also divided into two levels of abstraction, as supported by xADL 2.0. An abstract conguration describes a system conguration in terms of the desired/required properties, both functional and non-functional, of its architectural elements, identifying the structure of the system, but abstracting away from the actual component instances (identifying the component types). A concrete conguration, on the other hand, describes a system conguration in terms of actual component instances, and their respective properties. An abstract conguration can be instantiated into dierent concrete congurations depending on the availability of actual component instances. Figure 4.1 presents our architectural metamodel. The shaded elements correspond to the elements introduced by us in the metamodel, while the clear elements are dened by xADL 2.0. Abstract congurations are captured by the ArchStructure element, composed of abstract components (Component element) and links (Link element) between two interfaces. It is important to mention that, for now, we are abstracting away from architectural connectors, exploring Link elements for representing connections between two interfaces. Concrete congurations are captured by the ArchInstance element, and are composed of concrete components (ComponentInstance) and concrete links (LinkInstance).
http://www.eclipse.org/modeling/emf/
Figure 4.1: Architectural metamodel based on xADL 2.0.
81
82
The InterfaceInstance element represents the interfaces of a concrete component, while the Interface element captures the interfaces of abstract components. The Direction element indicates if an interface is required or provided. Concrete components, interfaces and links are extended (e.g., PrescribedComponentInstance) for including a reference to their associated abstract counterpart. Abstract components and interfaces have also a reference to their respective types, which are expressed using the ArchType element of xADL 2.0. Our extension to xADL 2.0 has included a Repository element that contains references to dierent conguration models. We have also created a MyPrescribedComponentInstance element for including the dierent properties associated with concrete components. The InstanceProperties element captures these properties. It includes properties used during selection of components (availability, correctness, cost and responseTime), the current state of a component in case it is stateful (operationalState), and the current life-cycle state (componentState), which can be either running or quiescent. The blocked attribute of the InstanceProperties element means that a component is taking part in a reconguration. The InterfaceInstanceProperties element contains the information necessary for accessing a particular interface of a component instance using web services (e.g., WSDL address), and whether the interface is connected of not (bound).
4.3.2
The PDDL Domain Model
Once the architectural metamodel has been dened, the next step is the denition of its associated PDDL domain model, which captures the concepts of the architectural metamodel that are considered when generating reconguration plans. For example, the architectural metamodel might allow the identication of the component manufacturer as one of its non-functional properties, and this information does not need to be included in the PDDL domain model. Listing 4.1 presents the XMI representation of our PDDL domain model created using the EMF platform. It contains an identication to the model (RecongurationDomain
83
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
<?xml version = 1 . 0 e n c o d i n g = UTF8 ?> <pddlmodel:DomainModel x m i : v e r s i o n = 2 . 0 xmlns:xmi = h t t p : //www. omg . o r g /XMI x m l n s : p d d l m o d e l = h t t p : // pddl . pddlmodel domain = R e c o n f i g u r a t i o n D o m a i n > <r e q u i r e m e n t s v a l u e = a d l /> <t y p e s v a l u e = component /> <t y p e s v a l u e = r e q u i r e d I n t e r f a c e /> <t y p e s v a l u e = p r o v i d e d I n t e r f a c e /> <t y p e s v a l u e = o p e r a t i o n a l s t a t e /> </ pddlmodel:DomainModel>
Listing 4.1: PDDL domain model for architectural reconguration.
on line 1), and the features oered by PDDL that are used in this domain (requirements element on line 2). The types considered correspond to components and interfaces (lines 3 - 5). The predicates must consider objects of the types dened. For example, the predicate of lines 6 - 8, (connected ?C1 - component ?RIntf - requiredInterface ?C2 - component ?PIntf - providedInterface), represents a connection between a required interface of component C1 to the provided interface of component C2. We have also included predicates for representing dierent information about components, such as its current life-cycle state (e.g., running or quiescent), if it is blocked, and if it is stateful.
4.3.3
The Transformation Rules
The architectural metamodel and the PDDL domain model are used as a basis for dening the domain specic transformation rules that translate architectural models into planning inputs. These rules can be applied to the reconguration of any software system that follows the dened architectural metamodel. We have organised the transformation rules in two blocks associated with the workow pre- and post-conditions, respectively. In each block, there are four
84
rules, considering the components and connections of the current and selected conguration models. The rules associated with the workow pre-condition can be described informally in the following way: Pre01: For each component of the current conguration (i.e., existing components), create PDDL predicates capturing the component actual state (i.e., running and unblocked - the default state for existing components); Pre02: For each component of the selected conguration that are not part of the current conguration (i.e., new components), create PDDL predicates capturing the component actual state (i.e., quiescent and unblocked, the default state for new components); Pre03: For each connection of the current conguration, create PDDL predicates stating the connection as established; Pre04: For each connection of the selected conguration that is not in the current conguration, create PDDL predicates stating the connection as not established. In a similar way, the rules for dealing with the workow post-condition can be described informally in the following way: Post01: For each component of the current conguration that is not part of the selected conguration (i.e., removed component), create PDDL predicates stating the component as quiescent and unblocked; Post02: For each component of the selected conguration, create PDDL predicates state the component as unblocked and running; Post03: For each connection of the current conguration that is not part of the selected conguration, create PDDL predicates stating the connection as not established;
85
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
module Reconfiguration2PDDLModel ; create OUT : PDDL from IN : a r c h i t e c t u r e M e t a m o d e l , IN2 :PDDL; rule DomainReferences { from d : PDDL! DomainModel , r e p o : a r c h i t e c t u r e M e t a m o d e l ! R e p o s i t o r y to t : PDDL! ProblemModel ( problem < R e c o n f i g u r a t i o n P r o b l e m , domain < d , o b j e c t s < Sequence{ t h i s M o d u l e . c o m p o n e n t C o l l e c t i o n ( )> c o l l e c t ( e | t h i s M o d u l e . component2PddlObject ( e ) ) , . . . } , i n i t < Sequence{ r e p o . a r c h S t r u c t u r e >a t ( 1 ) . component> c o l l e c t ( c | t h i s M o d u l e . processCurrentComponentPre ( c ) ) , . . . } , g o a l < Set { . . . , r e p o . a r c h S t r u c t u r e >a t ( 2 ) . l i n k > c o l l e c t ( l i n k | thisModule . linkToConnected ( l i n k ) ) } ) } lazy rule component2PddlObject { from s : a r c h i t e c t u r e M e t a m o d e l ! Component to p : PDDL! ProblemObject ( name < s . id , t y p e < t h i s M o d u l e . recoverComponentType ( ) ) }
Listing 4.2: Extract of the transformation rules for translating architectural models into planning problem model.
Post04: For each connection of the selected conguration, create PDDL predicates stating the connection as established. Listing 4.2 presents some parts of the transformation rules, which are specied using the Atlas Transformation Language (ATL) [85] (A full description of these rules is presented in the Appendices). Our module Reconguration2PDDLModel produces a PDDL problem model (line 2) from two objects received as input (line 3). OUT represents the PDDL problem model, while IN represents the architectural models (current and selected congurations), and IN2 corresponds to the PDDL domain model. Architectural models conform to the architectural metamodel presented in Figure 4.1 (represented by architecturalMetamodel), and are contained in a Repository element as an ordered list associated with the archStructure attribute. The PDDL models (IN2 and OUT) conform to the PDDL metamodel presented in Chapter 3.
86
The DomainReferences rule (line 5) is the main rule of the transformation, and is activated by the models received as input, which are associated with two variables that are used during the transformation (line 6): d is associated with the PDDL domain model, while repo is associated with the Repository element that contains the conguration models. This rule creates a ProblemModel element (line 7), and populates its attributes. The problem attribute is used to identify the generated model (line 8), while the domain attribute is associated to the PDDL domain model received as input (lines 6 and 9). The objects attribute consists of all components and interfaces of both congurations (lines 10 - 12), and these are obtained from auxiliary rules, for example, the componentInstance2PddlObject rule (used in line 12 and dened in lines 22 - 28) is responsible for creating a ProblemObject from a Component element. This rule uses the component identication as the ProblemObject name (line 25), and uses another auxiliary rule to recover the PDDL domain model element associated with components (line 26). The componentInstance2PddlObject rule is an example of an auxiliary rule, as indicated by the lazy keyword. The init attribute (line 13) represents the workow pre-condition, while the goal attribute (line 16) represents the workow post-condition. Both attributes are populated through the rules previously presented. For example, lines 14 and 15 present the implementation of rule #Pre01, which is used to obtain the current state (processCurrentComponentPre) of all components of the current conguration (indicated by repo.archStructure->at(1).component on line 14). The implementation of rule #Post04 is presented in lines 17 - 18, where the auxiliary ATL rule linkToConnected is used to state all connections of the selected conguration (identied by repo.archStructure->at(2).link).
4.3.4
The Task Templates
Once the architectural metamodel and its associated PDDL domain model have been specied, we can dene the task templates available in the domain. For the domain of architectural reconguration, we have considered a total of eight task
87
templates: Connect: responsible for connecting a required interface to a provided interface; Disconnect: responsible for disconnecting a required interface from a provided interface; Block: responsible for blocking a component, representing that the component is involved in a reconguration; Unblock: responsible for unblocking a component; Start: responsible for starting the execution of a component; Stop: responsible for stopping the execution of a component, changing the component to a state of quiescence; LoadState: responsible for loading the operational state into a component; SaveState: responsible for saving the operational state of a component. All task templates, apart from Connect and Disconnect, involve only one component. Each connection/disconnection involves exactly two components, a required interface and a provided interface. Thus, the connection of components with multiple interfaces is achieved through one connection task for each interface. In the sequel, we present an example of each one of the task templates artefacts exploring the task for connecting two components. Listing 4.3 presents the XMI representation of the Connect task template specication, with its name dened on line 1. The parameters of this task are presented in lines 2 to 13, where we can identify references to their respective types, dened in the PDDL domain model. This task connects a required interface (?RIntf) of component ?C1 to a provided interface (?PIntf) of component ?C2. Pre-and post-conditions (represented as precondition and eect respectively) are
88
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
<A c t i o n name= c o n n e c t > <t y p e h r e f = R e c o n f i g u r a t i o n D o m a i n . pddl#//@types . 0 /> <t y p e h r e f = R e c o n f i g u r a t i o n D o m a i n . pddl#//@types . 1 /> <t y p e h r e f = R e c o n f i g u r a t i o n D o m a i n . pddl#//@types . 0 /> <t y p e h r e f = R e c o n f i g u r a t i o n D o m a i n . pddl#//@types . 2 /> < e f f e c t v a l u e = ( c o n n e c t e d ?C1 ? R I n t f ?C2 ? P I n t f ) /> < e f f e c t v a l u e = ( bound ?C1 ? R I n t f ) /> </Action>
Listing 4.3: XMI representation of the Connect task template specication.
specied based on the predicates dened by the PDDL domain model. According to the pre-condition (lines 14 - 19), components must be blocked (lines 14 and 15) and in a quiescent state (lines 16 and 17), the required interface must not be connected to any other provided interface (line 18), and the connection not established (line 19). The post-condition states that the connection is established (line 20) and the required interface is bound (line 21). Listing 4.4 presents the XMI representation of the Connect task template model, where we can identify the parameters of the task template (lines 4 - 7), a reference to the task that undoes its eects (line 2), and an indication that it is a peripheral task (line 3). It also includes a reference to the task template specication presented in Listing 4.3 (line 8), and to its task template implementation (line 3). Figure 4.2 presents the task template implementation for the Connect task template using an Yawl diagram (connect.yawl). The Pre-condition and Postcondition tasks implement, respectively, the pre-conditions and eects of listing 4.3. This task implementation starts by verifying its pre-condition (Pre-condition task). In case of violation of the pre-condition (Exception ow), no recovery is necessary,
89
1 2 3 4 5 6 7 8 9
<TaskTemplate name= c o n n e c t undoTask= d i s c o n n e c t p e r i p h e r a l= t r u e t a s k I m p l e m e n t a t i o n= c o n n e c t . yawl > <parameterNames>C1</ parameterNames> <parameterNames>R I n t f</ parameterNames> <parameterNames>C2</ parameterNames> <parameterNames>P I n t f</ parameterNames> < t a s k S p e c i f i c a t i o n h r e f= c o n n e c t . pddl#/ /> </ TaskTemplate>
Listing 4.4: XMI representation of the Connect task template model.
Figure 4.2: Task template implementation of the Connect task using an Yawl diagram (connect.yawl). and the task nishes with a Exceptional outcome. After the verication of the pre-condition (Success ow), the interfaces of the components can be connected (Connect(C1, RIntf, C2, PIntf) task). If there is a problem during the connection (represented by the Exception ow), it is aborted and the task template nishes with a Exceptional outcome. In this case, we assume that the components are not connected, and that the recovery would involve the replacement of one of the components, which is outside the control of this task template. In case there is a violation of the post-condition (represented by the Exception ow from the Post-condition task), the components are disconnected (disconnect(C1, RIntf, C2, PIntf) task), and the task template nishes with an Exceptional outcome. The task nishes successfully when the components are successfully connected and the post-condition is met.
90
4.4
The Reconguration Process
This section presents the reconguration process, which is an instantiation of the reference process presented in Chapter 3, and describes its main activities. In our work, we have focused on the generation of reconguration plans that change the system architecture, assuming the existence of mechanisms responsible for selecting a conguration for the system. A reconguration can be triggered by dierent reasons, such as violations of the system requirements, faults in the resources that compose the application, and changes in the system environment or its requirements. As previously mentioned, we assume the existence of mechanisms responsible for starting the reconguration process. These mechanisms collect and analyse information about the components that are part of the actual system conguration, the environment in which the software system is deployed, and the requirements of the application. Following the division of the generation in two levels of abstraction, an abstract workow is generated based on an abstract conguration at the strategic phase, while at the tactical phase, a concrete conguration is used for for mapping an abstract workow into a concrete workow. In the following, we detail the different phases of the reconguration process (strategic, tactical and operational), identifying how the reference process has been instantiated into the domain architectural reconguration.
4.4.1
The Strategic Phase
An overview of the activities of the strategic phase is presented in Figure 4.3. The Obtain current conguration activity (which corresponds to the Obtain current state activity of the reference process) is responsible for obtaining an architectural model that describes the current conguration of the system, representing the initial state of the workow. The Obtain abstract conguration activity is responsible for obtaining the goal of the workow, which corresponds to the abstract conguration selected for the
91
Figure 4.3: Overview of the strategic phase of the reconguration process. system. This activity corresponds to the Obtain domain specic goals of the reference process. We assume the existence of mechanisms responsible for selecting an abstract conguration for the system. The other activities of the process (Translate into pre/post, Run planner, and Translate into workow) are not modied. In case of a problem in the generation (e.g., plan is not found), the process is restarted. In this scenario, the Obtain current conguration activity is activated for updating the current conguration that is used by the Obtain abstract conguration activity. In case it is not possible to obtain a new abstract conguration for the system, the process nishes with an Exceptional outcome.
4.4.2
The Tactical Phase
An overview of the activities of the tactical phase is presented in Figure 4.4. In the present application domain, the generated workows are classied as peripheral workows, thus the tactical phase of the reconguration process has been modied by eliminating the Select tactical tasks activity of the reference process, and by changing the exceptional ow accordingly. The Extract abstract tasks activity has not been modied during the instantiation of the framework, receiving the Abstract workow produced in the previous phase and extract all abstract tasks that are going to be used during the tactical phase. The Obtain concrete conguration activity is responsible for nding a concrete conguration for the system, based on the abstract conguration identied at the
92
Figure 4.4: Overview of the tactical phase of the reconguration process. strategic phase. It is a domain specic activity that corresponds to the Select concrete parameters activity of the reference process. Since we are not concerned with the problem of selecting a concrete conguration for the system, this activity can be associated with one of the dierent techniques existent for selecting a conguration (e.g., [7] [152]). It is important to observe that in the domain of architectural reconguration, the Obtain concrete conguration activity can be executed in parallel with the Extract abstract task. Nevertheless, for simplicity reasons, we have decided to consider only sequential activities in the reconguration process. The Replace tasks parameters and the Associated concrete tasks activities have not been modied compared with the reference process. The resultant Concrete workow is passed to the operational phase for execution. In case there is a problem at the operational phase, the reconguration process comes back to the tactical phase, where a new concrete conguration is selected for generating a new concrete workow. If it is not possible to nd a concrete conguration, the reconguration process returns to the strategic phase.
4.4.3
As previously mentioned, the operational phase of the reconguration process is responsible for executing the generated concrete workow, and for generating and executing a recovery workow. An overview of the activities of this phase has been previously described during the presentation of the operational phase of the reference process (Figure 3.15). The recovery has been customised for using the undo mechanism previously
93
presented. It checks whether any task in the generated workow has nished its execution successfully and builds a recovery workow that undo its eects starting from the last successful task. The reason for the failure is logged, as well as a copy of the conguration models used during the generation.
4.5
The Reconguration Infrastructure
The infrastructure for supporting the execution of the reconguration process, which is presented in Figure 4.5, has been developed based on the supporting infrastructure presented in Section 3.6. In this section, we describe the infrastructure dened, and detail its implementation, focusing on the customisable and domain specic components.
Figure 4.5: Overview of the infrastructure for supporting the reconguration process. The Adaptation starter component is responsible for starting a reconguration. This component is equivalent to the Starter component of the supporting infrastructure (presented in Figure 3.16). It implements the mechanisms associated with the analyse phase of the feedback control loop. In this way, this component
94
checks the non-functional properties (e.g., response time) of the components of the established conguration against a dened threshold. In case of violation, it starts the execution of the reconguration process. The Model translator component supports the Translate into pre/post activity, and is customised by providing the architectural metamodel and the transformation rules presented in Section 4.3. The Planner component (supporting the Run planner activity) has been customised by selecting the planner that will be used, and providing the PDDL domain model and task templates dened for the domain of reconguration. The PDDL domain model is stored in the Planner component, while the task templates are stored in the Task templates repository. The workow translator component supports the Translate into workow activity, and has been modied for querying architectural models based on the architectural metamodel previously dened. The behaviour of this component is presented in Figure 4.6 using an UML activity diagram notation. The loading of the preand post-conditions are based on the current and selected abstract conguration. After the loading of the pre-condition, the tasks of the PDDL plan model are processed. Since this domain contains eight tasks, the Translate into workow activity includes eight dierent paths for processing task templates. These tasks do not require any additional step for their processing, following the base structure provided by the framework (i.e., Load task implementation and Save sub-workow). Thus, the implementation provided by our reference infrastructure for dealing with the processing of tasks of a PDDL plan was sucient for this application domain. The Registry component is responsible for providing an accurate view of the system. It stores a model of the system conguration, all available components and their respective attributes. We assume that the Registry is responsible for monitoring the available components. Any changes in the components availability should be reected at the Registry. This is achieved through the use of probes that query the components of the system at specic intervals.
95
Figure 4.6: Detailed view of the Translate into workow activity of the reconguration process. The Congurator component represents the mechanisms responsible for selecting a concrete conguration for the system. This component is equivalent to the Concrete parameter selector of the supporting infrastructure. It uses the Congurations repository for storing the dierent architectural models involved in the reconguration process. The selection of a conguration has been implemented based on the use of a utility function that is a linear combination of the utilities of the dierent elements, but it can be easily changed to use other selection techniques (such as [7] [152]). Since we consider the generation of peripheral workows, the Tactical tasks selector component is deactivated (not present in Figure 4.5). No changes have been made to the domain independent components: WFMS, Workow model repository and Workow model handler. The Recovery handler component has been customised for employing the undo mechanism based on the tasks that have been successfully executed. It generates a recovery workow that tries to bring the system back to the initial conguration, exploring tasks that undo the eects of the concrete workow tasks. The components of the software system, captured by the Resources in Figure 4.5, are implemented in Java and use web service as communication technology. In order to impose separation of concerns, these components provide two dierent types of interfaces as presented in [150], where it is possible to identify application and conguration services interfaces: The application services interfaces
96
provide access to the operations associated with the implementation of business rules, while the conguration services interfaces provide access to the operations associated with the architectural reconguration.
4.6
Experimental Evaluation
The objective of this section is to demonstrate the application of our framework in the context of architectural reconguration, considering the presence of failures during the reconguration, evaluating its feasibility and scalability, and the impact of considering dierent architectural features. The experiments are presented in three groups. The rst group demonstrates the behaviour of our approach with and without failures, considering reconguration of a simple software application. The second group is focused on a quantitative evaluation of our approach, comparing its performance and scalability against two existing approaches that employ AI planning for managing software reconguration. The third group of experiments investigates the impact of dierent architectural features (e.g., quiescence) when instantiating the reconguration process. Finally, the section concludes with a brief discussion of this exercise.
4.6.1
Demonstration of the Reconguration Process
In the following, we present the rst group of experiments conducted, demonstrating an instantiation of our framework, and showing how it can deal with failures that can be recovered at dierent phases of the reconguration process. For that, we have considered three dierent scenarios involving the reconguration of a stock quote web service application. The rst scenario is based on the execution of a generated workow without any failures. The second scenario explores a failure that is recovered at the tactical phase of the process, while the third scenario involves a failure that can only be recovered at the strategic phase. In the sequel, we describe the stock quote application and the architectural features being considered in these experiments, before presenting the three above
97
mentioned scenarios. Stock Quote Application and Architectural Features This case study consists in a web service application that addresses the problem of obtaining stock quotes from the web. The stock quotes are collected from dierent sources, and dierent techniques are applied to deal with inconsistencies and mismatches between the acquired data in order to provide dependable (correct) and available stock quotes. These dierent techniques are captured by alternative architectural congurations. The software architecture of this case study (presented in Figure 4.7) consists of a FrontEnd component, three dierent components responsible for obtaining the quotes (Voter, Comparator and Single), and dierent sources of stock quotes (for example, BridgeYahoo and BridgeGoogle - a bridge handles architectural mismatches between the online sources and our system, and provides a well dened interface for accessing dierent online sources of stock quotes). The FrontEnd component acts as the client interface, allowing a client to specify its interested stock quote and a time interval for receiving updates on the stock quotes price. The Voter component requires three dierent sources of stock quotes, and performs majority voting on the values received, being able to detect and tolerate a fault. The Comparator component applies comparison between two sources of stock quotes for detecting inconsistencies, and the Single component requires only one source of stock quotes. The components that implement the dierent fault-tolerant/detection techniques consider the value of the stock price and its respective time stamp. Figure 4.7 presents three abstract congurations of the stock quote application. An abstract conguration identies the functional properties associated with each component using its type. For example, C1 :FrontEnd indicates that the component with logical name C1 has functional properties associated with components of type FrontEnd. The selection of an abstract conguration is implemented using an ordered list, where the conguration that requires more components is tried rst.
98
Figure 4.7: Example of abstract architectural congurations. We assume a crash-failure semantics for the components of this application. It means that whenever there is a problem in a component (e.g., an internal error, discrepancies in the acquired values or no response from a bridge), this component halts its execution and does not reply to any subsequent invocation. For example, if there are three dierent values received by the Voter component, this component, and the aected bridges, are crashed. In this way, the failure of a component can be detected through a time-out mechanism, which is used by the tasks of generated workows. In this case study, we have simplied our assumptions about the execution environment of the software components. We have explored the architectural metamodel, PDDL domain model and task templates previously presented, simplifying them according to the following assumptions about the case study: components must be blocked before being involved in a reconguration operation and required interfaces can only be connected to one provided interface. With these two assumptions, we abstract away from the other features of the architectural metamodel presented in Section 4.3. Listing 4.5 presents the PDDL domain model used in these experiments, where we can notice the identication for the model (domain attribute in line 2), the
99
PDDL requirements considered (line 3), and the types according with the architectural metamodel (lines 4-6). The PDDL domain model has been modied by removing the predicates associated with the features not considered in the case study (e.g., whether a component is in the running or quiescent state), resulting in predicates for stating a connection between two interfaces (line 7), stating that a required interface is currently connected (line 8), stating that a component contains a provided/required interface (lines 9-10), and that a component is blocked (line 11).
1 2 3 4 5 6 7 8 9 10 11 12 <?xml v e r s i o n =1.0 e n c o d i n g=UTF8?> <pddlmodel : DomainModel xmi : v e r s i o n =2.0 xmlns : xmi=h t t p : / /www. omg . o r g /XMI xmlns : pddlmodel=h t t p : / / pddl . pddlmodel domain=R e c o n f i g u r a t i o n D o m a i n> <r e q u i r e m e n t s v a l u e=a d l /> <t y p e s v a l u e=component/> <t y p e s v a l u e= r e q u i r e d I n t e r f a c e /> <t y p e s v a l u e= p r o v i d e d I n t e r f a c e /> </pddlmodel : DomainModel>
Listing 4.5: PDDL domain model used in the rst group of experiments with the reconguration process.
This case study required modications on the domain specic transformation rules presented in Section 4.4.1, from which we have removed the rules associated with the features and predicates not considered in the case study (e.g., quiescent and running states). It has involved four task templates: connect, disconnect, block and unblock, which have also been modied accordingly, i.e., removing the predicates associated with quiescence from their pre- and post-conditions. In addition, once a component instance has been selected for a particular concrete conguration, this component is not longer available, while blocked components are not considered when selecting a new conguration for the system, thus, all components involved in a new conguration are unblocked.
100
Experiments with no Failures In the sequel, we present the experiment conducted for the rst scenario, giving examples of the dierent artefacts that are automatically created during the execution of the reconguration process, such as, the PDDL problem model used by the planner, and the generated PDDL plan model workow. These examples consider the establishment of the abstract conguration of Figure 4.7c (involving the Voter component) from a state of non-conguration.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ( d e f i n e ( problem R e c o n f i g u r a t i o n P r o b l e m ) ( : domain R e c o n f i g u r a t i o n D o m a i n ) ( : o b j e c t s C1 C2 C3 C4 C5 component C1 IR C2 IR1 C2 IR2 C2 IR3 r e q u i r e d I n t e r f a c e C2 IP C3 IP C4 IP C5 IP p r o v i d e d i n t e r f a c e ) (: init ) ( : g o a l ( and ( not ( b l o c k e d C1 ) ) ( not ( b l o c k e d C2 ) ) ( not ( b l o c k e d C3 ) ) ( not ( b l o c k e d C4 ) ) ( not ( b l o c k e d C5 ) ) ( c o n n e c t e d C1 C1 IR C2 C2 IP ) ( c o n n e c t e d C2 C2 IR1 C3 C3 IP ) ( c o n n e c t e d C2 C2 IR2 C4 C4 IP ) ( c o n n e c t e d C2 C2 IR3 C5 C5 IP ) ) ))
Listing 4.6: PDDL description of problem model for abstract conguration of Figure 4.7c.
First, we present in Listing 4.6 an example of a PDDL problem model produced by the Translate into pre/post activity of the reconguration process. This problem model is automatically generated by our framework through model transformation. The header has an identier for the problem (RecongurationProblem on line 1) and a reference to the PDDL domain model (line 2). The list of objects involved (lines 3-5) includes all components (identied by logical names) and their provided and required interfaces. In this example, the workow pre-condition (init section on lines 7-8) states that all involved components are unblocked and all connections are not established, which following the PDDL language, is indicated by the absence of the respective predicates. The post-condition (goal section on lines 9-17) corresponds to all components unblocked and all connections established.
101
1 2 3 4 5 6 7 8 9 10 11 12 13 14
(BLOCK C1 ) (BLOCK C2 ) (BLOCK C3 ) (BLOCK C4 ) (BLOCK C5 ) (CONNECT C1 C1 (CONNECT C2 C2 (CONNECT C2 C2 (CONNECT C2 C2 (UNBLOCK C1 ) (UNBLOCK C2 ) (UNBLOCK C3 ) (UNBLOCK C4 ) (UNBLOCK C5 )
IR C2 C2 IP ) IR1 C3 C3 IP ) IR2 C4 C4 IP ) IR2 C5 C5 IP )
Listing 4.7: Example of a generated plan in PDDL.
The PDDL problem model is used, together with the PDDL domain model and the task templates, by the Run planner activity for generating a PDDL plan model. Listing 4.7 presents one example of a plan generated based on these inputs expressed in PDDL. This plan is used as input for the Translate into workow activity that processes each of its tasks using the appropriate task template implementations, resulting in an abstract workow, which is presented in Figure 4.8. This workow identies the task templates to be used, populated with the logical names of the abstract conguration.
Figure 4.8: Example of a generated abstract workow for establishing the abstract conguration of Figure 4.7c. The abstract workow is then passed to the tactical phase of the reconguration process, where a concrete conguration will be selected, and its concrete components are used for converting the abstract workow into a concrete workow.
102
BridgeYahoo_IP Vot1_IR1 Gui_IR Gui :C1 :FrontEnd Vot1_IP Vot1 :C2 :Voter Vot1_IR2 BridgeGoogle_IP Vot1_IR3 BridgeMsn_IP
BridgeYahoo :C3 :Bridge
BridgeGoogle :C4 :Bridge
BridgeMsn :C5 :Bridge
Figure 4.9: Example of concrete conguration for abstract conguration of Figure 4.7c. Figure 4.9 presents an example of concrete conguration (based on the abstract conguration of Figure 4.7c), which is used for creating the concrete workow presented in Figure 4.10. In this diagram, Gui stands for the instance associated with the C1 component, Vot1 for the C2 component, BY for the C3 component (BridgeYahoo), BG for the C4 component (BridgeGoogle), and BM for the C5 component (BridgeMsn).
Figure 4.10: Example of concrete workow for the experiments without failures. The concrete workow is executed at the operational phase of the reconguration process, and since we do not consider any failures in this experiment, the concrete conguration is successfully established. Experiments with Failure - Recovery at Tactical Phase In the following, we present the experiments conducted for demonstrating how our approach can deal with failures that can be recovered at the tactical phase,
103
generating a new concrete workow without the need to restart the reconguration process. For that, we have repeated the experiments presented above, and have injected faults in the system for crashing dierent components during the reconguration process. Considering the concrete workow presented in Figure 4.10, we have injected faults in the BridgeYahoo (BY) component for crashing it during the Connect(Vot1, Vot1 IR1, BY, BY IP) task, triggering the generation and execution of a recovery workow before the process goes back to the tactical phase.
Figure 4.11: Example of a generated recovery workow for experiments with recovery at tactical phase. The recovery workow, which is presented in Figure 4.11, is generated based on a simple backward error recovery scheme, undoing the eects of the generated workow, and returning the system to its previous conguration (i.e., a state of non-conguration). It contains tasks that involve crashed components (e.g., Unblock(BY) on Figure 4.11), and these tasks might nish with an exceptional outcome, depending on their task template implementation. For now, the recovery workow deals with this situation by continuing its execution with the next task. This allows, for example, to disconnect a client component from a crashed server component (e.g., disconnect a voter type component from a crashed bridge component type). Once at the tactical phase, a new concrete conguration is selected (which is presented in Figure 4.12) and used to generate a new concrete workow based on the abstract workow previously generated (presented in Figure 4.8). The new concrete conguration uses the BridgeFinancialTimes component (shaded in the Figure) for replacing the failed BridgeYahoo component.
104
BridgeFinancialTimes_IP Vot1_IR1 Gui_IR Gui :C1 :FrontEnd Vot1_IP Vot1 :C2 :Voter Vot1_IR2 BridgeGoogle_IP Vot1_IR3 BridgeMsn_IP
BridgeFinancialTimes :C3 :Bridge
Figure 4.12: Example of new concrete conguration for abstract conguration of Figure 4.7c. The new concrete workow is presented in Figure 4.13, in which the shaded tasks identify the dierences between this concrete workow and the previous one (presented in Figure 4.10), where BY (BridgeYahoo) has been replaced by BF (BridgeFinancialTimes).
Figure 4.13: Example of a new concrete workow. This time, the concrete workow is successfully executed at the operational phase, establishing the concrete conguration of Figure 4.12. Experiments with Failure - Recovery at Strategic Phase To further investigate the behaviour of our approach in the presence of failures, we have conducted another set of experiments involving the case study presented in this section. In these experiments, our goal is to demonstrate how our approach deal with with failures that are recovered at the strategic phase of the reconguration process.
105
For these experiments, we have considered the concrete conguration of Figure 4.12 and its respective concrete workow (presented in Figure 4.13), injecting faults in the BridgeFinancialTimes (BF) component that crashes it during the Connect(Vot1,Vot1 IR1, BF, BF IP) task.
Figure 4.14: Example of a generated recovery workow. Similar to our previous experiment, a recovery workow is generated for undoing the eects of the concrete workow. The recovery workow is presented in Figure 4.14, where the shaded task identies the dierence between this workow and the recovery workow of Figure 4.11. After the execution of the recovery workow, the process goes back to the tactical phase, where a new concrete conguration is attempted. In this scenario, a concrete conguration can not be selected because there is no other bridge component available, and the process goes back to the strategic phase. Back at the strategic phase, the abstract conguration of Figure 4.7b is selected, and then used by the Translate into pre/post activity for producing a PDDL problem model, which is presented in Listing 4.8. Compared to Listing 4.6, this PDDL problem model contains a dierent number of components and interfaces (line 3-5), and the post-condition captures the abstract conguration of Figure 4.7b (lines 9-16). Following the reconguration process, the PDDL problem model is used by the Run planner activity for generating a PDDL plan model, which is then used by the Translate into workow activity for producing an abstract workow of Figure 4.15. Following the reconguration process, this abstract workow is passed to the tactical phase, where a concrete conguration is obtained and used to generate a
106
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
( d e f i n e ( problem R e c o n f i g u r a t i o n P r o b l e m ) ( : domain R e c o n f i g u r a t i o n D o m a i n ) ( : o b j e c t s C1 C2 C3 C4 component C1 IR C2 IR1 C2 IR2 r e q u i r e d I n t e r f a c e C2 IP C3 IP C4 IP p r o v i d e d i n t e r f a c e ) (: init ) ( : g o a l ( and ( not ( b l o c k e d C1 ) ) ( not ( b l o c k e d C2 ) ) ( not ( b l o c k e d C3 ) ) ( not ( b l o c k e d C4 ) ) ( c o n n e c t e d C1 C1 IR C2 C2 IP ) ( c o n n e c t e d C2 C2 IR1 C3 C3 IP ) ( c o n n e c t e d C2 C2 IR2 C3 C3 IP ) ) ))
Listing 4.8: Example of problem model in PDDL for abstract conguration of Figure 4.7b.
Figure 4.15: Example of a generated abstract workow for abstract conguration of Figure 4.7b. new concrete workow. The concrete conguration is presented in Figure 4.16. Based on this concrete conguration, the abstract workow is converted into a concrete workow, which is presented in Figure 4.17. The concrete workow is then passed to the operational phase for execution, and the system is successfully congured. These experiments have demonstrated the use of our reconguration process for managing software reconguration with and without failures during the reconguration process, presenting examples of the dierent artefacts produced: PDDL problem model, PDDL plan model, abstract workow and concrete workow. These were generated based on the artefacts provided to the reconguration
107
BridgeGoogle_IP BridgeGoogle :C3 :Bridge Gui :C1 :FrontEnd Gui_IR Cmp1_IP Cmp1 :C2 :Comparator Cmp1_IR1 Cmp1_IR2 BridgeMsn :C4 :Bridge BridgeMsn_IP
Figure 4.16: Example of a concrete conguration for abstract conguration of Figure 4.7b.
Figure 4.17: Example of a generated concrete workow. process: architectural metamodel, PDDL domain model, task templates, and domain specic transformation rules. We have repeated these experiments considering dierent abstract and concrete congurations for the stock quote application, and involving failures at different steps of the generated workow. During these experiments workows were successfully generated during run-time (i.e., the generated workows were able to establish the conguration used as input), supporting the handling of failures that are recovered at dierent phases of the reconguration process. We noticed that a conguration is successfully established, providing that there are enough resources available for at least one concrete conguration.
4.6.2
Quantitative Evaluation
We have conducted another set of experiments with the goal of evaluating the performance and scalability of our reconguration process, considering the division between strategic and tactical phases of the generation process. This has
108
been done by comparing the performance of our reconguration process against two existent approaches that explore AI planning in the context of architectural reconguration. In the sequel, we describe the experiments conducted for evaluating the performance of the reconguration process, followed by another set of experiments for evaluating its scalability. Performance Experiments In the performance experiments, we have explored the stock quote application previously presented, introducing a new component type (Adjudicator), which can be used by the FrontEnd component for employing two intermediary components in the same conguration. Figure 4.18 presents an example of a concrete conguration where an Adjudicator is connected to a Comparator and a Voter. It is important to observe that this fault-tolerant architecture has been employed with the sole purpose of increasing the number of components involved in a conguration. With this, we can change the size of a conguration by combining dierent component types.
BridgeGoogle_IP Cmp1_IP BridgeGoogle :C4 :Bridge Cmp1 :C3 :Comparator Cmp1_IR1 Cmp1_IR2 BridgeMsn :C5 :Bridge Gui_IR Gui :C1 :FrontEnd Adj1_IP Adj1 :C2 :Adjudicator Adj1_IR1 BridgeMsn_IP BridgeFinancialTimes_IP Vot1_IR1 Adj1_IR2 Vot1_IP Vot1 :C6 :Voter Vot1_IR2 BridgeMsn_IP Vot1_IR3 BridgeGoogle_IP BridgeFinancialTimes :C7 :Bridge
Figure 4.18: Example of concrete conguration with nine components and eight connections. In addition to our approach, and for the purpose of comparison, these experiments have also considered two existing approaches that explore AI planning
109
in the context of architectural reconguration [11] [121]. These approaches have been implemented by altering our reconguration process according to their descriptions, which have been adapted for dealing with our reconguration domain. In the following, we describe the processes considered in these experiments. We start by presenting a simplied view of our reconguration process, shown in Figure 4.19, by identifying those activities that were considered for measuring the time for generating a workow, which appear shaded in the diagram. We have considered only these activities because they are the activities provided by our framework, we assume the existence of mechanisms for dealing with the selection of a conguration, and the workow execution is dependent on its execution environment.
Figure 4.19: Reconguration process identifying the activities considered during the experiments. The second reconguration process (presented in Figure 4.20) is based on the work of Arshad et al. [11], where an AI planner is used for nding a conguration for a system and generating its respective concrete workow. The selection of a conguration is based on the time it takes to establish it, which is calculated from non-functional properties associated with concrete components. In order to support the selection of a concrete conguration based on a given abstract conguration, it is necessary to encode all possible abstract congurations in the PDDL domain model and to associate them to PDDL predicates. It is also necessary to include predicates for dealing with temporal characteristics of the task templates and component instances. There are no strategic task templates in this reconguration process, since it does not consider the generation of abstract workows, and the parameters of the task templates dened by the planner correspond to
110
the concrete components that compose the selected conguration. Thus, it is necessary to include all available component instances in the planner. The shaded activities in this diagram correspond to the activities considered when measuring the time for generating a workow.
Figure 4.20: Reconguration process based on the approach of Arshad et al. [11]. In this process, the Obtain current conguration activity is responsible for obtaining the current system conguration as well as all available component instances. The domain specic transformation rules of the Translate into pre/post activity have been altered according to the changes in the PDDL domain model, translating the abstract conguration received into the PDDL predicates used to represent such conguration, and including all available components into the PDDL problem model. The workow produced by the Translate into workow activity is ready for execution. Their process deals with failures by undoing the eects of the generated workow, and updating the current state of the system (current conguration and available components) before generating a new workow. Dierent from Arshad et al.s original approach, our implementation of their approach has considered more general predicates (e.g., we do not consider the machine in which a component is instantiated) and task templates (e.g., connect two interfaces instead of one task template for dealing with local connections, and one for distributed connections), although all the dierent component types have been encoded into the PDDL domain model in order to specify valid congurations. The third reconguration process is based on the work of Ranganathan and Campbell [121]. Similar to ours, this process separates the selection of a conguration from the generation of the workow, however, their reconguration process
111
does not consider the division between strategic and tactical phase, and includes all available component instances in the planner. An overview of this process is presented in Figure 4.21. Similar to Arshad et al.s process, the Obtain current conguration activity is responsible for obtaining the current system conguration as well as all available component instances. The transformation rules of the Translate into pre/post activity have been altered for considering a concrete conguration. Their approach deals with failures during the execution of generated workows by restarting the whole reconguration process.
Figure 4.21: Reconguration process based on the approach of Ranganathan and Campbell [121]. We employ architectural models for capturing system congurations, whereas in their approach, congurations are captured using PDDL-based predicates. Another dierence is the use of the task templates presented in Section 4.3 for generating a plan, while their original approach explored the services oered by the component instances as task templates for the planner. In summary, the main dierence between the three reconguration processes is the amount of information given to the planner. Our reconguration process (identied by Our from now on) explores the division between strategy and tactics using logical names for representing the components of a conguration. The process based on the approach of Ranganathan and Campbell [121] (identied by Ranganathan), separates the selection of a conguration from the generation of the plan, but includes all available component into the planner. On the other hand, the reconguration process based on the approach of Arshad et al. [11] (identied by Arshad), uses the planner for selecting a conguration for the system, including all possible congurations and all available components into the planner. These processes were used for conducting dierent experiments, with and
112
without failures during execution of the generated workow. As previously mentioned, these experiments considered the total time for generating a concrete workow that establishes a given conguration. The times presented correspond to an average of ve executions. We have considered dierent congurations for the stock quote application varying the number of components and connections involved in the conguration, which impacts the number of tasks in the generated workow. We assume a non-conguration state as initial state for all reconguration processes, which consider as input the same abstract conguration. In these experiments, every component of a conguration must be blocked before being involved in a connection, and unblocked at the end of the reconguration. In this way, a conguration with x components and y connections will have 2x+y tasks. For example, the conguration of Figure 4.18, with nine components and eight connections, requires a workow with 26 tasks (blocking the nine components, establishing the eight connections, and unblocking the nine components). The number of components available is xed and equal to 16, encompassing one instance of the FrontEnd component, one instance of the Adjudicator component, two instances of each Single, Comparator and Voter components, and eight instances of the Bridge component. This number was chosen for allowing the use of congurations with up to 10 components, and up to two failures during execution of the generated workow. Since our reconguration process can deal with failures at its dierent phases, we have conducted two sets of experiments involving failures: the rst set considered failures that can be handled at the tactical phase of the reconguration process; while the second set considers failures that are recovered at the strategic phase. In these situations, the rst generated workow fails during its execution, and a new workow is generated after a new conguration is selected. Initially, we have considered the impact of including the selection of a conguration in the planner, comparing the time of our approach against the time of Arshads process. The planner used for these experiments was the LPG-TD planner (the successor of the planner used by Arshad et al.). Figure 4.22 presents the
113
times obtained in one of these experiments when varying the size of the conguration received as input, with and without failures during execution of the generated workow, where Our(T) corresponds to the times obtained by handling a failure at the tactical phase of the reconguration process, and Our (S) represents the time for recovering from a failure at the strategic phase. For this graph, we have stopped at a conguration with ve components and four connections due to limitations of the planner regarding the number of components received as input and the PDDL domain model used in Arshads process. Nevertheless, this graph shows the high overhead caused by incorporating the selection of a conguration in the generation process (Arshad curve) with and without failures during execution of the generated workow. It also shows the performance of our approach when recovering from failures at its dierent phases.
Figure 4.22: Results obtained when comparing Our and Arshads processes without and with failure during execution of the generated workow. We have conducted an initial analysis of these results considering the dierent activities of both reconguration processes, whose times are presented in Table 4.1 for a conguration with ve components and four connections. In this analysis, we have focused on the activities of the strategic phase. As expected, the Translate into pre/post and Run planner activities in Arshads process take longer than in Our process. This, and the fact that most of the time is associated with the Run planner activity, show that the decision of not considering all available components and not employing a planner for selecting a conguration indeed improve the time
114
it takes to generate a workow. However, Our process appears to take longer to translate the resulting PDDL plan into an abstract workow (Translate into workow). This is caused by the extra processing associated to abstract tasks, whereas Arshads process only consider concrete tasks. Our process also incurs an extra time associated with the tactical phase of the reconguration process, which is compensated by the improvement on the times of the other activities.
Strategic phase Tactical Translate Run Translate phase into planner into pre/post workow 0.159 138.978 3.826 21.954 0.547 642.000 2.994 Total
Our Arshad
164.916 645.541
Table 4.1: Times obtained for the activities of the reconguration process considering the graph of Figure 4.22 for a conguration with ve components and four connections (5/4) (times presented in ms). Compared to the results presented by Arshad et al. in [11], our experiments with the implementation of their approach are positioned between their experiments with explicit (where the desired conguration is given as the workow post-condition) and implicit congurations (where the planner is responsible for nding the system conguration), as we dene the desired abstract conguration but let the planner decide which concrete components to use. Considering the numbers obtained in their experiments presented in [11], the best time is around 4.92 seconds involving a conguration obtained from 18 component instances, while our implementation of their approach takes around 650 ms for a conguration that requires ve components that are selected from a total of 16 components available. However, it is important to observe that we employ a dierent planner, running in a dierent execution environment with a dierent planning domain model and problem. Moreover, we have no knowledge about the structure of the desired conguration used in their experiments. We have conducted another set of experiments in order to evaluate the division between abstract and concrete workows. In these experiments, we have compared our approach against Ranganathan process (presented in Figure 4.21).
115
Figure 4.23 presents the results obtained in these experiments, when varying the abstract conguration considered as input, and using the same number of component instances of our previous experiments (16 component instances available). We have used the Satplan2006 planner [89], which is the successor of the planner used by Ranganathan and Campbell in [121]. Again, we present the times obtained without failure (Figure 4.23a) and with one failure (Figure 4.23b) during execution of the generated workow, identifying the times associated with recovery at dierent phases - Our (T) and Our (S).
Figure 4.23: Results obtained when comparing Our and Ranganathan processes without and with failure during execution of the generated process. By analysing these results, we can notice the impact in the performance when all available components are considered by the planner (Ranganathan curve). We can also notice the gain in performance by dealing with failures at both tactical and strategic phases. Since no experimental results regarding the generation time have been presented by Ranganathan and Campbell [121], we can not establish a comparison against the results obtained. We have also conducted an analysis of these results based on the activities of the reconguration for a conguration with ve components and four connections, whose times are presented in Table 4.2. These results further conrm the improvement on performance by not including all components available in the planner (as
116
Our Ranganathan
Strategic phase Tactical Translate Run Translate phase into planner into pre/post workow 0.223 65.613 4.423 25.718 1.466 140.984 3.596
Total
95.978 146.045
Table 4.2: Times obtained for the activities of the reconguration process considering the graph of Figure 4.23 for a conguration with ve components and four connections (5/4) (times presented in ms). shown by the times of the Translate into pre/post and Run planner activities), and that Run planner is the most time consuming activity. Considering the time of the Translate into pre/post activity against the time of table 4.1, we notice that Ranganathan process takes considerably longer to translate the received architectural model into a planning problem when compared against the time obtained for Arshads process. While both processes include all available component into the planner, Ranganathan process translates the received conguration model into a planning problem with several PDDL predicates (similar to our process), and Arshads process only employs one predicate for indicating the abstract conguration received, which is previously encoded into the PDDL domain model. These experiments have demonstrated the feasibility of our reconguration process for generating the workows that coordinate the architectural reconguration. They have also conrmed the improvement in performance when separating the selection of a conguration from the generation of the workow for establishing this conguration, and that the division of the generation in two phases (strategic and tactical) improves the performance of workow generation. Scalability Experiments Considering the results obtained in our previous experiments, we have conducted another set of experiments for evaluating the scalability of our approach. In these experiments, we have employed the same reconguration processes of our previous experiments, considering a higher number of components available, and larger conguration sizes.
117
The software architecture used in these experiments consists of three types of components: source, lter and sink. The source component represents some source of information that is processed by dierent lters until it reaches the sink component, where the information is consumed. Due to our interest in evaluating the scalability of the reconguration process, this case study supports an arbitrary number of lters, simplifying the realisation of experiments with dierent conguration sizes. Figure 4.24 presents examples of abstract congurations where we can notice the variation in the number of components. Figure 4.24a presents an example of a conguration involving three components, while Figure 4.24b shows a conguration involving four components. Finally, Figure 4.24c shows a conguration involving n components.
Figure 4.24: Example of abstract congurations with dierent number of components. In these experiments, we adopt the same PDDL domain model, transformation rules and task templates that have been used in our performance experiments. Similar to our previous experiments, we have considered the establishment of a given conguration, involving all components of the conguration, and assuming a state of non-conguration as initial state for all reconguration processes. The number of tasks in the generated workow follows the same rules of our previous experiments, i.e., a workow for a conguration with x components and y connections will have 2x+y tasks. The planner used during these experiments was the SGPlan6 [80]. This planner has been chosen for these experiments because it is a more recent planner, it allows the execution of all processes with their respective PDDL domain models,
118
and supports bigger conguration sizes than the previous planners. The LPG-TD planner (the successor of the planner used by Arshad et al.) supports all PDDL domains involved in these experiments, however, it has a limitation on the size of its input, with a maximum value being hardcoded without any option for its modication, and without access to its source code. The Satplan2006 planner [89] (the successor of the planner used by Ranganathan and Campbell in [121]) does not support the PDDL domain used in Arshads process. In order to investigate the impact of the number of components available, we have initially considered all three processes, and a conguration involving ve components and four connections. Figure 4.25 presents the times obtained in this experiment. This graph conrms the overhead of incorporating the selection of a conguration into the planner (Arshad curve) when considering all three processes. This happens because in Arshads approach, all available components are considered by the planner while looking for the best conguration considering the time necessary to instantiate it.
Figure 4.25: Time for generating a concrete workow for a xed abstract conguration changing the number of components available. Based on these results, we have conducted other experiments considering only Our and Ranganathan processes, where we considered a conguration that involves
119
10 components and nine connections, and have varied the number of components available. Figure 4.26 presents the results obtained in this experiment.
Figure 4.26: Comparison between Our and Ranganathan processes xing the size of the conguration and changing the number of components available. By analysing the results obtained, we noticed that Ranganathan process presents a better result when the number of components available is low, which demonstrates the overhead caused by the separation between abstract and concrete workows. However, as the number of components available increases, it is possible to notice a considerable overhead in Ranganathan process, demonstrating the improvement in performance (time to generate a workow) of Our process. This graph also shows that the number of components available does not aect the time it takes to generate a workow when dividing the generation in two phases. Considering these results, we have analysed the individual times of the activities of both processes, which are presented in Figure 4.27. Since each activity presents a very distinct time, it is important to notice that the scales presented in those graphs are dierent. We start by discussing the time of the Translate into pre/post activity. As expected, the increase in the number of components impacts the transformation of architectural models into PDDL problem models of Ranganathan process, which considers all components available when generating a workow. These results also conrm that this activity is not aected by the
120
number of components available in Our process. Comparing the time of the Run planner activity against the total generation time (presented in Figure 4.26), we further conrm that the biggest impact in the reconguration process is caused by the planner execution. Again, this activity is not aected in Our process, as we do not include all components available into the planner.
Figure 4.27: Times of the individual activities of both processes, changing the number of components available. The graph of the Translate into workow activity shows that this activity is not aected by the number of components available in both processes, and that the dierence between them is less than one millisecond, which indicates that considering abstract tasks when translating planning models into abstract workows has minimal impact at the time it takes to generate a workow. Regarding the division between strategic and tactical phases, we noticed that the time associated to the tactical phase of the process is constant and around 26 ms, conrming that this phase is also not aected by number of components available.
121
To further investigate the scalability of both processes, we have conducted another set of experiments varying the size of the conguration and the number of components available. Figure 4.28 presents the results of one of those experiments, where we have assumed that the number of components available for each conguration size is the double of the number of components required by the conguration, e.g., when running the experiments for the conguration with size 20, we have considered 40 components available.
Figure 4.28: Comparison between Our and Ranganathan processes changing both the size of the conguration and the number of components available. Based on these results, we noticed that both processes present a quadratic progression in relation to the size of the abstract conguration received as input, which is expected considering that both approaches are based on AI planning. These results conrm the improvement of Our process when increasing the size of the conguration being considered. Taking as an example a conguration that involves 300 components, Ranganathan process takes around 40 minutes (2445 seconds) to generate a workow, while Our process takes approximately 15% of this time (less than six minutes - 346 seconds). We have also repeated the analysis of the individual activities of both processes based on the results obtained, which are presented in Figure 4.29. The results obtained have shown that the Translate into pre/post activity presents a linear progression on both processes, with Ranganathan being aected by considering all components available. The times obtained for the Run planner activity further
122
Figure 4.29: Times of the individual activities of both processes, changing both the size of the conguration and the number of components available. conrms that the quadratic behaviour of both processes is caused by the execution of the planner, as the activity with biggest impact on the reconguration process. The times of the Translate into workow activity further conrm the minimal impact caused for considering abstract tasks, and show the linear progression of this activity when increasing the size of the conguration. The tactical phase of Our process presents a linear progression, with minimal impact at the time it takes to generate a workow, corresponding to less than 1% of the total generation time. The experiments presented in this section have demonstrated the improvement in the performance of the generation by our reconguration process, conrming that the division between abstract and concrete workows indeed improves the generation of workows for managing architectural reconguration when compared against existent approaches.
123
4.6.3
Experiments with Dierent Architectural Features
We have performed another set of experiments extending the assumptions about the execution environment that supports the process for reconguring the system architecture. Our goal with these experiments is to demonstrate an instantiation of our reconguration process considering dierent architectural features, and to investigate the impact in the generation of workows caused by such features. For doing that, we have extended the architectural features considered in the previous experiments by rst introducing the concept of quiescence [94] into the architecture; and second, considering the transfer of state between components. Depending of the features of the architecture new domain artefacts (e.g., PDDL domain model and domain specic transformation rules) have to be dened. In the sequel, we describe the modications performed for the reconguration of quiescent components compared with the domain model used in our previous experiments, and present the experiments conducted, followed by a demonstration of our approach for the reconguration with transfer of state. Reconguration with Quiescence In this scenario, we have considered the other features of the architectural metamodel (quiescent and running states), ignoring the properties associated with the state of components. Based on this, we have modied the PDDL domain model by including the predicates associated with the life-cycle state of components (e.g., running or quiescent). Listing 4.9 presents an example of the PDDL domain model used in this scenario, where, compared to the PDDL domain model of our previous experiments, we can mention the inclusion of the above mentioned predicates on line 9. Based on the new predicates, we have modied the existing task templates (e.g., connect/disconnect) by including the predicates associated with component quiescence in their pre- and post-conditions, and included new task templates
124
1 2 3 4 5 6 7 8 9 10
( d e f i n e ( domain R e c o n f i g u r a t i o n D o m a i n ) ( : requirements : adl ) ( : t y p e s component r e q u i r e d I n t e r f a c e p r o v i d e d I n t e r f a c e ) (: predicates ( c o n n e c t e d ?C1 component ? R I n t f r e q u i r e d I n t e r f a c e ?C2 component ? P I n t f p r o v i d e d I n t e r f a c e ) ( bound ?C component ? R I n t f r e q u i r e d I n t e r f a c e ) ( b l o c k e d ?C component ) ( q u i e s c e n t ?C component ) ( r u n n i n g ?C component ) ))
Listing 4.9: PDDL domain model for reconguration of quiescent components.
responsible for starting/stopping the execution of a component (bringing/putting it in the quiescent state). The transformation rules have been modied by incorporating rules associated with quiescent/running state of components. We have repeated the experiments presented in the previous sections using the domain artefacts dened for dealing with the reconguration of quiescent components. These experiments considered the pipe-and-lter architecture of Figure 4.24. We have considered the following assumptions for these experiments: every component must be blocked before being involved in a reconguration, and unblocked at the end of the process; every component must be in a state of quiescence before being involved in a connection/disconnection, and must nish the process in a running state; and all components that are not part of the conguration at the beginning of the process are in a state of quiescence. These assumptions allow us to calculate the size of the generated workow in function of the number of components and connections in the conguration. In this way, a workow for establishing a conguration with x components and y connections will have 3x+y tasks. For example, a conguration with three components and two connections requires a workow with 11 tasks (blocking the three component, establishing the two connections, changing the three components from quiescent to running state, and unblocking the three components). In the sequel, we present examples of the artefacts that have been produced by our reconguration process for establishing a conguration with three components and two connections.
125
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
( d e f i n e ( problem R e c o n f i g u r a t i o n P r o b l e m ) ( : domain R e c o n f i g u r a t i o n D o m a i n ) ( : o b j e c t s C1 C2 C3 component C1 IR C2 IR r e q u i r e d I n t e r f a c e C2 IP C3 IP p r o v i d e d i n t e r f a c e ) (: init ( q u i e s c e n t C1 ) ( q u i e s c e n t C2 ) ( q u i e s c e n t C3 ) ) ( : g o a l ( and ( not ( b l o c k e d C1 ) ) ( not ( b l o c k e d C2 ) ) ( not ( b l o c k e d C3 ) ) ( r u n n i n g C1 ) ( r u n n i n g C2 ) ( r u n n i n g C3 ) ( c o n n e c t e d C1 C1 IR C2 C2 IP ) ( c o n n e c t e d C2 C2 IR C3 C3 IP ) ) ))
Listing 4.10: PDDL description of problem model for abstract conguration with 3 components.
First, we present in Listing 4.10 an example of a PDDL problem model produced by the Translate into pre/post activity. This problem model is similar to the ones presented in our previous experiments, with an identier for the problem (RecongurationProblem on line 1) and a reference to the PDDL domain model (line 2). Dierent from our previous PDDL problem model, in this example, the workow pre-condition (init section on lines 7-8) states that all involved components are in a quiescent state (line 8), unblocked, and all connections are not established (indicated by the absence of the respective predicates), while the postcondition (goal section on lines 10-14) corresponds to all components in a running state (line 12), unblocked (line 11), and all connections established (lines 13-14). Following the activities of the reconguration process, this problem model is used by Run planner activity for producing a PDDL plan model, which is presented in Listing 4.11. An example of a generated abstract workow produced by the Translate into workow activity based on this PDDL plan model is presented in Figure 4.30. Compared to the abstract workows of our previous experiments (Figure 4.8 and 4.15), this workow contains tasks for starting the execution of software components (Start task), which change the component from the quiescent state to a running state.
126
1 2 3 4 5 6 7 8 9 10 11
(BLOCK C1 ) (BLOCK C2 ) (BLOCK C3 ) (CONNECT C1 C1 IR C2 C2 IP ) (CONNECT C2 C2 IR C3 C3 IP ) (START C1 ) (START C2 ) (START C3 ) (UNBLOCK C1 ) (UNBLOCK C2 ) (UNBLOCK C3 )
Listing 4.11: Example of a generated plan in PDDL.
Figure 4.30: Example of a generated abstract workow for establishing a conguration with three components considering components in the quiescent state. The abstract workow is then passed to the tactical phase of the reconguration process, where a concrete conguration will be selected, and its concrete components are used for converting the abstract workow into a concrete workow. Dierent architectural features mean dierent predicates in the PDDL domain model and task templates, and bigger workow sizes in terms of number of tasks, which further complicates the planning task. To investigate the impact caused by the incorporation of quiescence in the reconguration process, we have repeated the scalability experiments previously presented (Figure 4.26), using their results as a basis for comparison. In these experiments, we have used the same planner (SGPlan6 [80]) of previous experiments, and the numbers in the graphs corresponds to the average of ve executions for each point. Figure 4.31 presents the results obtained for a conguration that involves 10 components and nine connections, varying the number of components available
127
between 10 and 100. Based on the number of components (x ) and connections (y), the generated workow without quiescence has 29 tasks (2x+y), while the workow generated considering quiescence has 39 tasks (3x+y). In these graphs, we are interested in the impact caused by a dierent architectural feature in both Our and Ranganathan processes.
Figure 4.31: Impact of considering dierent architectural features xing the size of the conguration and changing the number of components available. a)our reconguration process; b)Ranganathan process. Figure 4.31a presents the impact in our reconguration process, where Our corresponds to the numbers obtained in our previous scalability experiments, and OurQuiescent represents the numbers obtained when considering quiescence. On the other hand, Figure 4.31b presents the impact of dierent architectural features in Ranganathans reconguration process, where Ranganathan corresponds to the numbers obtained in our previous scalability experiments, and RangQuiescent represents the Ranganathan process with quiescence. These results show that our approach suer less impact from introducing a new architectural feature, which conrms the improvement of the division between abstract and concrete workows in supporting the generation of larger workows (in terms of number of tasks). The inclusion of new domain artefacts (predicates and task templates) combined with all components available, has a huge impact in Ranganathan process due to the increased number of possibilities that must be considered by the planner based on the combinations between the components available and the
128
predicates/task templates involved in the domain. Reconguration with State Transfer After the incorporation of quiescence into the reconguration process, we have started to consider the transfer of state between components. This scenario involved all artefacts of the reconguration domain presented in Section 4.3. In the sequel, we describe the changes that have been made to the reconguration process for dealing with transfer of state between components, taking as a basis the artefacts used in the experiment with the reconguration of stateless component and quiescence. The PDDL domain model and the domain specic transformation rules have been modied for including the predicates associated with the representation of component state (e.g., stateful), while we have included two new task templates that deal with the state transfer between components (LoadState and SaveState). The incorporation of state transfer did not require modifying the other task templates. Listing 4.12 presents the PDDL domain model used in this scenario. Compared to the PDDL domain model of Listing 4.9, we can notice the inclusion of types and predicates for dealing with the transfer of state between components, e.g., operationalState, stateful, stored and contains. The operationalState type (line 3) captures the dierent states that can be loaded into a component. The predicate stateful (line 10) represents that the associated component is stateful. The stored predicate (line 11) represents that the associated state is saved in a state repository, while the contains predicate (line 12) indicates that a particular state is loaded into a component. For demonstrating the reconguration with transfer of state between components, we have developed another case study application. This case study involves a simple webshop application that can be used to sell goods on the internet. This webshop application has been inspired by the case study application used in [149]. The software architecture of this case study consists of nine component types:
129
1 2 3 4 5 6 7 8 9 10 11 12 13
( d e f i n e ( domain R e c o n f i g u r a t i o n D o m a i n ) ( : requirements : adl ) ( : t y p e s component r e q u i r e d I n t e r f a c e p r o v i d e d I n t e r f a c e o p e r a t i o n l S t a t e ) (: predicates ( c o n n e c t e d ?C1 component ? R I n t f r e q u i r e d I n t e r f a c e ?C2 component ? P I n t f p r o v i d e d I n t e r f a c e ) ( bound ?C component ? R I n t f r e q u i r e d I n t e r f a c e ) ( b l o c k e d ?C component ) ( q u i e s c e n t ?C component ) ( r u n n i n g ?C component ) ( s t a t e f u l ?C component ) ( s t o r e d ?S o p e r a t i o n l S t a t e ) ( c o n t a i n s ?C component ?S o p e r a t i o n l S t a t e ) ))
Listing 4.12: Example of the PDDL domain model for reconguration of quiescent components.
FrontEnd, ShopServ, ProductLocator, ProductDb, CurrConvtr, PriceCalculator, PromotionRules, RateLocaliser, and RateProvider. We assume that these component types contain states that must be transferred in the event of a reconguration. An example of a concrete conguration for this cases study is presented in Figure 4.32.
Conv1_IP Conv1 :C2 :CurrConvtr Conv1_IR RateLoc1_IP RateLoc1 :C5 :RateLocaliser RateLoc1_IR RatProv1_IP RatProv1 :C8 :RateProvider
Gui_IR2 Gui :C1 :FrontEnd Gui_IR1 SServ1_IP
SServ1_IR1 SServ1 :C3 :ShopServ SServ1_IR2 PricCal2_IP PricCal2 :C4 :PriceCalculator PricCal2_IR PR1_IP PR1 :C7 :PromotionRules SServ1_IR3 PL1_IP PL1 :C6 :ProductLocaliser
PL1_IR1 PDb1_IP PL1_IR2
PDb1 :C9 :ProductDb($)
PDb2_IP
PDb2 :C10 :ProductDb()
Figure 4.32: Software architecture of the web shop example application. The FrontEnd provides an user interface for purchasing products. This component displays all products in the currency of the users preference, regardless of the currency used by the rest of the system. The ShopServ acts as the coordinator of the application, controlling the enquiries and purchases of the clients. The ProductLocaliser acts as an access point to dierent local stock databases (ProductDb). It is responsible for nding products from the available databases for the items specied by the user. The PriceCalculator captures the business logic responsible
130
for calculating the total price of a clients shopping basket, considering any current promotions and the delivery costs. The PromotionRules component captures the existent promotions that are used by the PriceCalculator. The CurrConvtr maintains the conversion rates of the dierent currencies and performs conversions between dierent currencies when required. In this way, a RateProvider represents one specic online currency rate source. This component acts like a bridge component, handling architectural mismatches between the online sources and the system, and providing a well dened interface for accessing dierent online sources of conversion rates. The RateLocaliser corresponds to the dierent components that can be applied for obtaining rates, and similar to the Stock quote application, we consider three dierent types of RateLocaliser components: Single, Comparator and Voter. In the following, we present an example of the dierent models generated during the reconguration process for replacing a stateful component. In this experiment, we are considered the replacement of the PDb2:C10:ProductDb() component, simulating the replacement of a local stock database due to, for example, a problem in the suppliers delivery chain, which is detected by a change in one of its non-functional properties. Listing 4.13 presents the PDDL problem model for replacing component C10 with component C10R, focusing on the components involved in the reconguration. In this example, C10R (which is in a quiescent state) stands for the logical name of the component that will be used to replace component C10. We can notice the predicates for indicating that a component is stateful (line 10), and a predicate to indicate which component contains which state (line 11). Following the reconguration process, the PDDL problem model is used to generate a PDDL plan model that is then translated into an abstract workow, which is presented in Figure 4.33. The Stop task is responsible for stopping the component execution, and putting the respective component in a quiescent state, while the Start task is responsible for starting the component execution, removing this component from the quiescent state.
131
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
( d e f i n e ( problem r e c o n f P r o b l e m ) ( : domain r e c o n f i g u r a t i o n D o m a i n ) ( : o b j e c t s C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C10R component C1 IR1 C1 IR2 C2 IR C3 IR1 C3 IR2 C3 IR3 C4 IR C5 IR C6 IR1 C6 IR2 requiredInterface C2 IP C3 IP C4 IP C5 IP C6 IP C7 IP C8 IP C9 IP C10 IP C10R IP providedinterface S0 o p e r a t i o n a l S t a t e ) (: init ( r u n n i n g C1 ) ( r u n n i n g C2 ) ( r u n n i n g C3 ) ( r u n n i n g C4 ) ( r u n n i n g C5 ) ( r u n n i n g C6 ) ( r u n n i n g C7 ) ( r u n n i n g C8 ) ( r u n n i n g C9 ) ( r u n n i n g C10 ) ( s t a t e f u l C10 ) ( c o n t a i n S t a t e C10 S0 ) ( c o n n e c t e d C1 C1 IR1 C3 C3 IP ) ( bound C1 C1 IR1 ) ( c o n n e c t e d C1 C1 IR2 C2 C2 IP ) ( bound C1 C1 IR2 ) ( c o n n e c t e d C2 C2 IR C5 C5 IP ) ( bound C2 C2 IR ) ( c o n n e c t e d C3 C3 IR1 C2 C2 IP ) ( bound C3 C3 IR1 ) ( c o n n e c t e d C3 C3 IR2 C4 C4 IP ) ( bound C3 C3 IR2 ) ( c o n n e c t e d C3 C3 IR3 C6 C6 IP ) ( bound C3 C3 IR3 ) ( c o n n e c t e d C4 C4 IR C7 C7 IP ) ( bound C4 C4 IR ) ( c o n n e c t e d C5 C5 IR C8 C8 IP ) ( bound C5 C5 IR ) ( c o n n e c t e d C6 C6 IR1 C9 C9 IP ) ( bound C6 C6 IR1 ) ( c o n n e c t e d C6 C6 IR1 C10 C10 IP ) ) ( bound C6 C6 IR1 ) ( q u i e s c e n t C10R ) ( s t a t e f u l C10R ) ) ( : g o a l ( and ( r u n n i n g C1 ) ( r u n n i n g C2 ) ( r u n n i n g C3 ) ( r u n n i n g C4 ) ( r u n n i n g C5 ) ( r u n n i n g C6 ) ( r u n n i n g C7 ) ( r u n n i n g C8 ) ( r u n n i n g C9 ) ( q u i e s c e n t C10 ) ( r u n n i n g C10R ) ( c o n t a i n S t a t e C10R S0 ) ( c o n n e c t e d C1 C1 IR1 C3 C3 IP ) ( bound C1 C1 IR1 ) ( c o n n e c t e d C1 C1 IR2 C2 C2 IP ) ( bound C1 C1 IR2 ) ( c o n n e c t e d C2 C2 IR C5 C5 IP ) ( bound C2 C2 IR ) ( c o n n e c t e d C3 C3 IR1 C2 C2 IP ) ( bound C3 C3 IR1 ) ( c o n n e c t e d C3 C3 IR2 C4 C4 IP ) ( bound C3 C3 IR2 ) ( c o n n e c t e d C3 C3 IR3 C6 C6 IP ) ( bound C3 C3 IR3 ) ( c o n n e c t e d C4 C4 IR C7 C7 IP ) ( bound C4 C4 IR ) ( c o n n e c t e d C5 C5 IR C8 C8 IP ) ( bound C5 C5 IR ) ( c o n n e c t e d C6 C6 IR1 C9 C9 IP ) ( bound C6 C6 IR1 ) ( not ( c o n n e c t e d C6 C6 IR1 C10 C10 IP ) ) ( c o n n e c t e d C6 C6 IR1 C10R C10R IP ) ) ) ))
Listing 4.13: Example of pre- and post-conditions in PDDL.
Compared to the abstract workow of our previous experiment (presented in Figure 4.30), it can be noticed the inclusion of tasks responsible for loading (LoadState) and saving (StoreState) the state to/from components. In this gure, S0 identies the state that has been obtained from component C10 and is loaded into component C10R. Similar to our previous examples, a concrete workow is achieved by replacing the logical names with the respective component instance (concrete parameter). The concrete workow is then passed to the operational phase where it is executed and, since we have not considered failures during its execution, the new
132
Figure 4.33: Example of a generated abstract workow for replacement of stateful component. concrete component is successfully included into the existing conguration, and initialised with the state of the component that has been removed. This experiment has showed the application of our approach for generating the workow that changes the system conguration considering the transfer of state between components. However, since architectural reconguration is just a case study of our framework, and our main aim was to show the application of our approach in variations of a particular application domain, further performance and scalability experiments with reconguration and transfer of state must be conducted in order to evaluate the impact that the transfer of state between components incurs in our reconguration process. The experiments presented in this section have demonstrated the several models created during the reconguration process considering dierent architectural features (e.g., quiescence and transfer of state), showing that our approach can be easily adapted to variations of an application domain with a low impact in the time it takes to generate workows with dierent sizes when compared against another approach based on AI planning.
133
4.6.4
Discussion
The experiments presented in this chapter have demonstrated the feasibility of our approach for generating the workows that manage software architectural reconguration. The use of several case studies and dierent architectural features (e.g., quiescence and transfer of state) have demonstrated how our reconguration process can be tailored for dealing with distinct environments, and demonstrated the impact of including a new architectural feature into an existing reconguration process. The experiments conducted have shown that our approach is capable of dealing with failures during reconguration, and that the division between abstract and concrete workow improves the performance and scalability of the reconguration process when compared against two other approaches for architectural reconguration based on AI planning. Although the division between abstract and concrete workows has been previously used for generating workows in the context of grid computing, to the best of our knowledge, this is the rst time it is being explored for generating reconguration workows. Since our objective in this chapter was to investigate one instantiation of our framework, the reconguration process has some limitations that were not addressed in the current prototype. For example, system architectural congurations must be selected before workows are generated. Regarding the transfer of state between components, our experiments only involved the replacement of components in a same abstract conguration, not considering state transfer when the reconguration requires the modication of the system structure. Also, our experiments involving failures are limited to situations where it is possible to undo the eects of a generated workow, returning the system to the state it had before the execution of the generated workow. This is similar to the atomic reconguration supported by the Fractal environment [33]. Although the experiments conducted have presented very promising results, we have not evaluated the use of our work for managing ultra large scale software systems (e.g., systems with thousands of components), which might aect the scalability of our framework
134
due to the inherent nature of AI planning.
4.7
Chapter Summary
This chapter has demonstrated the instantiation of our framework into a process that manages the architectural reconguration of self-adaptive software systems. It has presented examples of the artefacts developed for this instantiation, which are an architectural metamodel, a PDDL domain model, the task templates available and domain specic transformation rules that translate architectural models into a PDDL problem model. By choosing to represent the PDDL domain model following a particular architectural metamodel and execution environment (architectural features), we make our solution applicable to any software application that follows this particular architectural metamodel. In order to evaluate our approach, we have developed a prototype, based on the supporting infrastructure presented in Chapter 3, which has been used for conducting experiments with dierent case studies, evaluating the performance and scalability of our reconguration process against existing approaches. These experiments have shown that our process is feasible but presents scalability restrictions, caused by the use of AI planning. We have also demonstrated how our framework for workow generation can be modied for dealing with dierent features of a particular application domain (such as support for quiescence and transfer of state), and how it supports the handling of failures during the reconguration. A possible future work for dealing with the problem of selecting a conguration before the generation is to adopt some sort of incremental generation combined an incremental conguration selection approach, like the one presented in [140]. A possible way of improving the scalability of our approach would be to employ some kind of model comparison technique in order to reduce the amount of information passed to the planner. Another future work, associated with the presence of failures during the reconguration, would be to consider situations where the
135
system conguration can not be restored in case of failures, possibly considering other recovery strategies that are being adopted for other types of processes (e.g., web service composition). Another possible future work involves the application of our reconguration process exploring well-known component-based execution environments such as Fractal [33], OpenCOM [43] and OSGI2 .
http://www.osgi.org/
Chapter 5 A Case Study on Component-based Integration Testing

5.1 Introduction
Software testing consists in the verication of the behaviour of a software system through the observation of its execution against a specied expected behaviour [21]. Testing is a complex process which comprises a variety of activities, techniques and actors, and is further aggravated by the recent advances on software engineering and the inherent complexity of todays software systems [22] [23] [123]. With the increasing number of software systems being required to self-adapt during run-time, there is a necessity for developing processes, techniques and tools that would support automated testing during run-time [22]. Among the existing testing models and methods, it is possible to nd a distinction between three dierent levels (or phases) of testing: unit, integration and system [21] [101] [123]. Unit testing refers to tests involving a specic unit of code, e.g., classes in an object-oriented environment, or components in component-based development. Unit testing is usually used to assure that the software unit under
136
CHAPTER 5. COMPONENT-BASED INTEGRATION TESTING
137
test works independently. Integration testing is focused on verifying the interactions between the dierent elements that compose the software system. It usually happens after unit testing and consists in aggregating the dierent elements that compose a software system, and then conducting tests in these aggregates. System testing is the execution of tests in the whole system in order to check if the system meets its specied requirements. Considering the three phases of testing, this chapter deals with the integration testing of component-based software systems. Component-based integration testing is concerned with tests involving interfaces between components in order to determine whether these components are able to interoperate [101]. We adopt an incremental approach for integration testing, where components are gradually integrated into a conguration and tested, in a way that a conguration that passes the integration testing is combined with a new component, resulting in a new conguration that is tested again (considering now the new element). These steps are repeated until all software components are integrated and tested, following an integration order based on the component dependencies in way that minimises the number of stubs required. Among the activities involved in this process, we can mention the calculation of the integration order of the software components, and the generation of stubs and test cases. In this context, the main objective of this chapter is to demonstrate the instantiation of our general framework for the dynamic generation of workows (presented in Chapter 3) into the domain of component-based integration testing, generating during run-time the workow that integrates and tests a software conguration. In order to achieve this, this chapter relies on the following assumptions. First, it is assumed that test cases associated with each component are available beforehand, second, there are techniques that calculate the integration order of components [79], and select a conguration for the system [140] [152], and nally, all necessary stubs are also made available. The instantiation of our framework involves the specication of the dierent artefacts that compose the domain of integration testing (such as an integration
138
testing metamodel, and domain specic transformation rules), the denition of a process for generating the workow responsible for executing the tests, and the denition of its supporting infrastructure. Our approach explores the division between abstract and concrete workows, and employs architectural models for conducting integration testing, which are also divided into abstract and concrete, similar to the component testing approach presented in [21]. We have dened abstract tasks associated with the execution of test cases for the components of an abstract conguration. These abstract tasks do not identify the test cases to be conducted, but act like a place holder for the concrete test cases that are associated with a particular concrete component. We have also dened abstract tasks for capturing the dierent activities that support the architectural recongurations involved in the integration testing process (one at each integration step). These tasks are seen as reconguration sub-workows that are dynamically generated based on the reconguration process presented in Chapter 4. This chapter demonstrates the instantiation of our framework for generating integral workows, and how the multiple instantiations of our framework can be integrated for generating and combining multiple workows. In particular, we show in the following how to integrate workows for managing integration testing and architectural recongurations. This chapter is organised as follows. Section 5.2 presents a brief literature review on the automation of component-based integration testing. Section 5.3 describes the artefacts that are needed for instantiating our framework. Section 5.4 presents the component-based integration testing process for the generation of workows. Section 5.5 presents the implemented infrastructure for supporting the generation and execution of the workows for integration testing. Section 5.6 presents an evaluation of our framework when applied to component-based integration testing. Finally, Section 5.7 presents the conclusions of the chapter.
139
5.2
State of the Art
In order to position our work, this section presents a brief literature review in the area of automated component-based software testing, focusing on integration testing1 . There are a number of approaches for dealing with the automation of testing of software components [123]. However, these approaches either have been targeted to development-time [21] [101], or they automate only particular aspects of the testing process (e.g., generation of test cases, generation of stubs, or execution of test cases) [31]. Compared to these approaches, our work goes in the direction of automating the whole integration testing process in a way that it can be executed by a self-adaptive software system during run-time (one of the dreams of the software testing research community [22]). The Component Deployment Testing (CDT) is a framework for the development and codication of tests, providing an environment for executing tests over a selected candidate component [23]. This work is similar to ours since the CDT framework explores the decoupling between test specications and test execution based on the use of architectural models at dierent levels of abstraction. Test cases are designed using method signatures of abstract components, while the execution of the tests are based on concrete components. Dierent from the CDT framework, our work considers not only the execution of tests, but also the modications of the system conguration (e.g., connection and disconnection of components/stubs) based on the integration order of the components of the system under test. The CDT framework has been dened as a development-time tool, requiring manual eort for integrating the dierent components, for example, while our approach focuses on providing automated testing capabilities during run-time. An approach for integration testing of software components has been presented by Machado et al. [101]. They have developed a method for integration testing of component-based software systems, which is able to generate test cases for each
1
A detailed survey has been presented by Rehman et al. [123]
140
integration step based on UML models annotated with OCL (Object Constraint Language), and providing tools for execution and interpretation of test results according with OCL specications. Similar to our approach, their method denes a process encompassing all activities of integration testing and employs architectural models for conducting tests. However, their method is not automated and has been dened to be used at development-time, assuming that the integration of software components is part of the development activities that occur in parallel with their method. One interesting approach towards the automation of software testing has been presented by Yoon et al. [155] [156]. They have developed an automated infrastructure for conducting compatibility tests of component-based software systems. Their approach has focused on testing whether a system can be built across all of its possible congurations when considering dierent versions of the involved components. Similar to ours, their approach explores conguration models at different levels of abstraction, and attempts to fully automate the testing process. An abstract conguration model is used to capture the dependencies between the system components and for dening the testing order, while concrete congurations are derived by considering the versions available for each component. However, the testing of all possible combinations restricts their approach to developmenttime, while our objective is to obtain a single conguration that passes the integration test during run-time. Another dierence is that our approach performs functional tests between components considering their required and provided interfaces, which is indicated as future work in their approach. Moreover, in their work, the testing order of the components is manually dened, with no support for congurations that require component stubs. Regarding software testing during run-time, it is possible to observe a movement towards the development of techniques for online testing, also called testing at service-time (opposed to testing at deployment-time, where the software system is tested in its deployment environment before being accessible to its users) [22][30]. Brenner et al. [30] have presented an infrastructure for automating the
141
run-time execution of tests on software components based on Built-In Test (BIT). They have proposed a method for developing components that can be tested during run-time, and a supporting infrastructure that manages the execution of tests when they have a minimal impact on the services being delivered by the system. However, their approach is only concerned with the execution of tests. Metzger et al. [106] have proposed the use of online testing as the means for augmenting the monitoring process of self-adaptive software systems for increasing the condence level of predicted failures used to trigger pro-active software adaptation. Although they explore generation and execution of test cases during run-time, dierent from our approach, the test results are used to increase the amount of monitoring data available. Compared to these works, our approach aims to develop an automated environment for conducting integration testing of self-adaptive systems based on the dynamic generation of processes, considering the complete automation of the testing process, and its dynamic generation and execution during run-time.
5.3
The Integration Testing Domain
This section presents those artefacts that were tailored while instantiating our framework into the domain of component-based integration testing, namely, a domain specic metamodel, a PDDL domain model, domain specic transformation rules, and the task templates available in this application domain. The section also presents the artefacts being considered for the reconguration process.
5.3.1
The Integration Testing Metamodel
The domain specic metamodel dened for integration testing is a modication of the architectural metamodel employed for managing architectural reconguration (an extension of the xADL 2.0 architectural description language [46]). Besides capturing the concepts and properties associated with software components and congurations, it has been augmented with properties associated with the execution of tests, and the integration order of components.
CHAPTER 5. COMPONENT-BASED INTEGRATION TESTING 142
Figure 5.1: Metamodel for component-based integration testing.
143
Figure 5.1 presents the integration testing metamodel, in which the shaded elements are the elements introduced by us, while the clear elements are dened by xADL 2.0. Similar to the architectural metamodel, a Repository element is used to hold references to dierent conguration models. Abstract congurations are captured by the ArchStructure element, while concrete congurations are represented by the ArchInstance element. Compared to the architectural metamodel of Figure 4.1, we have modied the InstanceProperties element by including attributes that can be used to indicate whether a component: has been successfully tested, has failed a test, or is ready to be tested (with all of its required interfaces connected to either other components or stubs). We have also included an element for capturing the order of integration of the components of an abstract conguration (IntegrationOrdering), and have extended the ArchStructure element (MyArchStructure) to include a reference to the integration order of its components.
5.3.2
The PDDL Domain Model
The PDDL domain model for component-based integration testing is based on the elements of the integration testing metamodel presented in the previous section, including predicates to indicate whether or not a component has been integrated into a conguration (ready to be tested), and whether a component has been tested. It also allows to capture the integration order of the involved components.
1 2 3 4 5 6 7 8 9 10 11 <?xml version= 1 . 0 e n c o d i n g=UTF8 ?> <pddlmodel:DomainModel x m i : v e r s i o n= 2 . 0 xmlns:xmi= h t t p : //www. omg . o r g /XMI x m l n s : p d d l m o d e l= h t t p : // pddl . pddlmodel domain= I n t e g r a t i o n T e s t i n g D o m a i n > <r e q u i r e m e n t s v a l u e= a d l /> <r e q u i r e m e n t s v a l u e= f l u e n t s /> <t y p e s v a l u e= component /> <f u n c t i o n s h e a d e r= ( t e s t i n g s t e p ) retur nType=number /> <f u n c t i o n s h e a d e r= ( i n t e g r a t i o n s t e p ) returnT ype=number /> <f u n c t i o n s h e a d e r= ( i n t e g r a t i o n o r d e r ?C component ) ret urnType=number /> </ pddlmodel:DomainModel>
Listing 5.1: Extract of the the PDDL domain model for component-based integration testing.
144
Listing 5.1 presents a partial XMI representation of the PDDL domain model of component-based integration testing, where we can notice the model identication on line 1 (IntegrationTestingDomain). The requirements (lines 2 - 3) identify the PDDL features that are used in this domain, where adl identies the rules used for dening actions, pre- and post-conditions, and uents allow the use of functions in the planning domain. The (tested ?C - component) predicate at line 5 represents that a component has been tested, while (integrated ?C - component) on line 6 represents that the component has been successfully integrated into a conguration and is ready to be tested. The functions (presented in lines 7 10) are used for incorporating the integration order of the components involved into the planner, where testing step and integration step are used to capture, respectively, the current testing and integration step at each stage of the plan, and integration order indicates the integration order of its associated component.
5.3.3
The Transformation Rules
The domain specic transformation rules are based on the integration testing metamodel, and the predicates of the PDDL domain model. Since we assume the initial state to be a state of non-conguration, the rules consider the complete integration of the conguration received, and their associated integration order. The rules can be described informally in the following way: Pre01: For each component of the selected conguration, create PDDL predicates indicating the component as not tested and not integrated; Pre02: For each component referenced by the IntegrationOrdering element, populate the testing step, integration step and integration order functions with the component and its respective integration order; Post01: For each component of the selected conguration, create PDDL predicates stating the component as tested.
145
Listing 5.2 presents a fragment of the domain specic transformation rules using the Atlas Transformation Language (ATL)[85]. Similar to the transformation rules used for reconguration, our module IntegrationTesting receives two types of models as input. IN captures the current and selected conguration models inside a Repository element (where the current conguration is assumed to be empty), while IN2 corresponds to the PDDL domain model. The conguration models conform to the integration testing metamodel (presented in Figure 5.1 and represented by integrationMetamodel), and the PDDL domain model (presented in Listing 5.1) conforms to the PDDL metamodel presented in Chapter 3.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 module I n t e g r a t i o n T e s t i n g ; create OUT : PDDL from IN : i n t e g r a t i o n M e t a m o d e l , IN2 : PDDL; rule DomainReferences { from d : PDDL! DomainModel , r e p o : i n t e g r a t i o n M e t a m o d e l ! R e p o s i t o r y to t : PDDL! ProblemModel ( problem c o l l e c t ( e | t h i s M o d u l e . component2PddlObject ( e ) ) } , i n i t < Sequence { . . . , t h i s M o d u l e . i n t e g r a t i o n O r d e r i n g ( r e p o . a r c h S t r u c t u r e >a t ( 2 ) ) } , g o a l < Sequence { . . . , t h i s M o d u l e . componentsAsTested ( r e p o . a r c h S t r u c t u r e >a t ( 2 ) ) } ) }
Listing 5.2: Extract of the transformation rules for integration testing in ATL.
The DomainReferences rule (line 3) is the main rule of the transformation. It associates the received models to variables that are used by the rule (e.g., DomainModel to d) (line 4). It also creates a ProblemModel object (represented by t on line 5), and populates its attributes. The objects (lines 8 - 10), init (lines 11 - 12) and goal (lines 13 - 14) attributes are populated through the use of auxiliary rules. For example, the objects attribute (the list of objects involved in a planning problem) is populated through the use of two auxiliary rules. The componentCollection (line 9) is responsible for grouping all components of the received conguration models into an unique set. This set is then used by the collect construct which invokes the component2PddlObject rules (line 10) for each component e, transforming the respective component into a PDDL object. In
146
a similar way, the integrationOrdering rule (line 12) is used for processing the integration order of the selected abstract conguration.
5.3.4
The Task Templates
According to the instructions for instantiating the framework, for each task available, it is necessary to dene a task template specication, a task template model, and a task template implementation, which are based on the PDDL domain model, the integration testing metamodel and the workow execution environment being used. For the domain of component-based integration testing, we have considered four task templates: IntegrateComponent: responsible for integrating a component into a particular conguration; TestComponent: responsible for conducting test in a component; ClearTest: responsible for clearing the tested property of components; RestoreConguration: responsible for restoring the system to a particular conguration. ClearTest and RestoreConguration are used in the recovery workow that is generated when a failure occurs at the operational phase. IntegrateComponent and RestoreConguration are associated to sub-workows dynamically generated using the reconguration process presented in Chapter 4, as these tasks involve changes in the system conguration. While the sub-workow associated with the IntegrateComponent task is generated when the main workow is generated, the sub-workow of the RestoreConguration task is only generated when a fault occurs. In the sequel, we present an example of each of the task template artefacts that must be dened during the instantiation of the framework, exploring the task template for conducting tests on a particular component (TestComponent).
147
Listing 5.3 presents the XMI representation for task template specication of the TestComponent. The task name is dened on line 1, while its input parameter is presented in line 2, where we can identify a reference to its respective type (line 3), dened in the PDDL domain model. The pre-condition states that the component has not been tested (line 5), and that it must be integrated (line 6). It also includes a predicate for considering the current testing step and the integration order associated with the component under test (line 7). The postcondition states that the component is tested (line 8), and that the testing step is incremented by 1 (line 9).
1 2 3 4 5 6 7 8 9 10 <t y p e h r e f = I n t e g r a t i o n T e s t i n g D o m a i n . pddl#//@types . 0 /> < e f f e c t v a l u e = ( t e s t e d ?C) /> < e f f e c t v a l u e = ( i n c r e a s e ( t e s t i n g s t e p ) 1 ) /> 
Listing 5.3: specication.
PDDL action model for the TestComponent task template
The task template model for TestComponent is presented in Listing 5.4. We can identify the parameter of the task template (line 4), and an indication that it is an integral task (line 3). The task template model also includes a reference to the task template specication (line 5), presented in Listing 5.3, and identies its respective task template implementation on line 3 (TestComponent.yawl).
1 2 3 4 5 6 <ta sk Te mp lat e: Ta sk Tem pl at e name= TestComponent undoTask = C l e a r T e s t i n t e g r a l = t r u e t a s k I m p l e m e n t a t i o n = TestComponent . yawl > <parameterNames>C</ parameterNames> < t a s k S p e c i f i c a t i o n h r e f = TestComponent . pddl#/ /> </ tas kT em pl ate :T as kTe mp la te>
Listing 5.4: TestComponent task template model.
Figure 5.2 presents the task template implementation for the TestComponent task template. Following the base structure for task template, it starts by checking
148
the pre-condition associated with the test. The pre-condition checks if the component under test is ready to be tested (e.g., if it has been integrated in the current system conguration). The Run test(C) activity represents the execution of the test case(s) associated with component C. The post-condition check conrms the success of the test case(s) execution (by checking its log and the obtained output), and if the component has been marked as tested. This task nishes successfully when the post-condition is evaluated to true after the test execution. The Recovery is activated in case of an exception during test execution (e.g., failure of the associated test case), or violation of post-condition. It simply marks the component as failed before nishing the task template with an exceptional outcome. In all exceptional cases (violation of pre- or post-conditions, or failure of the test), the reason for the exception is saved in a log.
Figure 5.2: Task template implementation for running tests in a component. In the sequel, we describe the artefacts that have been dened for supporting the generation of workows for changing the system conguration.
5.3.5
The Reconguration Sub-domain
Since our approach for integration testing explores the reconguration process presented in Chapter 4, it is necessary to dene the domain artefacts that will be used for generating reconguration workows. Most of these issues were discussed previously, and we just summarise the artefacts used in this chapter.
149
As the domain specic metamodel, we are employing the integration testing metamodel presented in Section 5.3.1. The PDDL domain model and the domain specic transformation rules have been modied to reect the metamodel being used. We assume that components must be in a quiescent state before being involved in a reconguration, and that only quiescent components are considered when selecting a new conguration. We are employing a total of six task templates: start, stop, add, remove, connect and disconnect. These task templates have been modied for considering the quiescent state of components in their pre- and postconditions.
5.4
The Integration Testing Process
The integration testing process, is the process responsible for generating the workows that will be performing the integration testing of the components of a software architecture. It is an instantiation of the reference process provided by our framework (presented in Section 3.5), and as such, is divided into three phases, strategic, tactical and operational. At the strategic phase, the process generates an abstract workow based on an abstract architectural conguration, the integration order calculated for this conguration, and any necessary stubs. At the tactical phase, a concrete workow is generated based on a concrete conguration and the test cases that are going to be used with each concrete component. At the operational phase, the concrete workow is executed and, in case of failures during its execution, a recovery workow is generated and executed before the process goes back to the tactical phase. The integration testing process relies upon the reconguration process presented in Chapter 4 (which generates workows for managing software reconguration), by associating the tasks that integrate new components to the system being tested to workows generated by the reconguration process. Following the structuring of its dierent phases (strategic, tactical and operational), the integration testing process deals with failures in the following way. In
150
case it is not possible to establish a particular concrete conguration (a concrete component has failed the test), the process selects a new concrete conguration for the system (i.e., trying to replace the failed component), and generates a new concrete workow by selecting a new set of test cases. In case it is not possible to generate a new concrete workow (e.g., there are not enough concrete components for establishing the selected abstract conguration), the process goes back to the strategic phase where a new abstract workow is generated. The process nishes with an exceptional outcome in case it is not possible to generate another abstract workow. In the sequel, we detail the dierent phases of the integration testing process.
5.4.1
The Strategic Phase
The main objective at this phase is to nd the sequence of tasks that will dene an abstract workow. An overview of the activities of this phase is presented in Figure 5.3, which is an instantiation of the diagram presented in Figure 3.13. The Obtain current conguration activity represents the Obtain current state activity of the reference process. Since we assume the initial conguration to be a state of non-conguration, this activity produces an empty architectural model representing the current conguration of the system. The Obtain domain specic goals activity is represented by two dierent activities: Obtain abstract conguration and Calculate integration order. The Obtain abstract conguration activity is responsible for recovering the abstract conguration that will be used by the integration testing process. We provide support for using alternative abstract congurations (in case they exist) for dealing with situations when it is not possible to generate a concrete workow at the tactical phase. In this scenario, the Obtain abstract conguration activity can try another abstract conguration, or nish with an exceptional outcome, representing that there is no abstract conguration available. The Calculate integration order activity calculates the integration order that minimises the use of stubs during the execution of the integration testing. The
151
Figure 5.3: Activities of the strategic phase of the component-based integration testing process. outcome of this activity is an architectural model augmented with the integration order calculated. This activity is also responsible for identifying the stubs necessary for the integration testing, and for including this information in the architectural model to be used for generating an abstract workow. For now, we are assuming the existence of the necessary stubs. The Translate into pre/post, Run planner, and Translate into workow activities are not modied, only the domain artefacts that are used by those activities (namely, integration testing metamodel, domain specic transformation rules, PDDL domain model and task templates), and the components that support their execution. The Translate into pre/post activity translates the current conguration and the abstract conguration containing the integration order and any stubs necessary into a PDDL problem model, which is used by the Run planner activity for generating a PDDL plan model. In case it is not possible to nd a plan for the given inputs (e.g., the integration order requires two stubs, but only one has been provided) the process goes back to the Obtain abstract conguration activity. At the end of the strategic phase, the abstract workow is passed to the tactical phase. In case of a problem at the tactical phase, the process starts again from the Obtain abstract conguration activity.
5.4.2
The Tactical Phase
At the tactical phase, the abstract workow is converted into a concrete workow by associating the correspondent concrete components and their respective test cases, and conguring the necessary stubs. An overview of the activities of this
152
phase is presented in Figure 5.4. The Extract abstract tasks activity has not been modied, receiving an abstract workow and extracting its abstract tasks, which will be used during the tactical phase. The Obtain concrete conguration activity corresponds to the Select concrete parameters of Figure 3.14, and represents the mechanisms used to select a concrete conguration for the system. Since the selection of a conguration does not consider the tasks of the abstract workow, but the abstract conguration that has been dened at the strategic phase, these activities (Extract abstract tasks and Obtain concrete conguration) could be executed in parallel. However, for simplicity, we decided to organise these activities in a sequential execution. Following the reference process, the Replace tasks parameters activity receives the abstract tasks that compose an abstract workow and the concrete conguration obtained by the Obtain concrete conguration activity, which is then used for replacing the tasks parameters with the concrete components that will be tested. This activity has not been modied.
Figure 5.4: General view of the tactical phase of the component-based integration testing process. The Obtain test cases activity corresponds to the Select tactical tasks activity of Figure 3.14, and is responsible for obtaining the test cases that are going to be used for each component. We assume that test cases are available, and associated to each concrete component in the form of meta-data. The test cases are also used for conguring any necessary stubs, based on the strategy adopted by Rocha and Martins [124]. Finally, the Associate concrete tasks activity replaces the abstract tasks of the abstract workow with the concrete tasks (identifying the concrete components
153
and associated test cases), resulting in a concrete workow that is ready to be executed. The concrete workow is then passed to the operational phase. In case of a problem at the operational phase, the process tries to select a new concrete conguration (Select concrete conguration activity) before generating a new concrete workow, reusing the abstract workow and the abstract conguration previously dened. In case it is not possible to nd a concrete conguration, the process goes back to the strategic phase.
5.4.3
The operational phase is responsible for executing the generated concrete workow. The activities of this phase have been previously presented during the explanation of the operational phase of the reference process on Chapter 3 (Figure 3.15). Compared to the reference process, this phase is customised by dening the technique adopted for recovery. We have employed a simple undo scheme, including tasks that clear the tested ag of each component that has been successfully tested (based on the successful TestComponent tasks). The recovery workow also includes a RestoreConguration task, attempting to restore the system architecture to the conguration it had at the beginning of the integration testing process (i.e., empty conguration). This task is associated with a reconguration sub-workow that is dynamically generated.
5.5
The Integration Testing Infrastructure
This section describes the infrastructure dened for supporting the execution of the integration testing process, which is presented in Figure 5.5. This infrastructure has been implemented as prototype based on the supporting infrastructure provided by our framework (presented in Section 3.6). Like the supporting infrastructure previously presented, all the components have been implemented in
154
Java, and the communication among them uses web service technology. Most of the components of this infrastructure are the same as those dened for the supporting infrastructure (e.g., YAWL Workow management system as process execution environment [147]), though some needed to be changed (Customisable element - e.g., Model translator, Planner, Workow translator), and few needed to be introduced (Domain specic element - e.g., Ordering calculator, Congurator, Test cases selector).
Figure 5.5: General view of the architecture for supporting the component-based integration testing process. The Testing starter component represents the mechanisms that can be used to start the integration testing process, corresponding to the Starter component of the supporting infrastructure. The Model translator component (responsible for the Translate into pre/post activity) has been modied with the domain specic transformation rules and the integration testing metamodel. The Planner component (supporting the Run planner activity) has been modied by providing the PDDL domain model and selecting the planner to be used. The task templates are stored in the Task templates repository. The Workow translator component (supporting the Translate into workow activity) has been modied for querying models that conform to the integration
155
testing metamodel, and for dealing with the tasks employed in the domain of integration testing. A description of the behaviour of this component using an activity diagram notation is presented in Figure 5.6, which is an instantiation of the diagram presented in Figure 3.17. As explained in Chapter 3, it loads the workow pre-condition, processes each task of a PDDL plan model, and loads the workow post-condition, resulting in an abstract workow. We consider a total of four tasks in the domain of integration testing, which are represented by the conditions associated with the decision point in the diagram (IntegrateComponent, TestComponent, ClearTest and RestoreConguration). The processing of ClearTest and TestComponent follows the base structure dened by the framework, and consists in loading the corresponding task template implementation, and saving the task template implementation as a sub-workow. The tasks that involve changes in the system conguration (IntegrateComponent and RestoreConguration) require some additional steps as part of their processing, and thus required the implementation of a task processing class in Java for each task.
Figure 5.6: Detailed view of the Translate into workow activity of the componentbased integration testing process. A PDDL plan model contains several IntegrateComponent tasks depending on the number of steps in the integration order. The processing of these tasks involves the generation of an abstract reconguration sub-workow for each one of them. This is achieved by exploring the reconguration process presented in Chapter 4,
156
which produces a workow for changing a system conguration based on models representing the current and the target congurations. In this way, the processing of each IntegrateComponent task (represented by the Process IntegrateComponent of Figure 5.6) of a PDDL plan model involves: 1. Load task implementation: The loading of a task template implementation, which includes populating the task inputs with the logical names used in the plan; 2. Build target model: The denition of conguration models representing the state of the system before (current) and after (target) the corresponding IntegrateComponent task; 3. Reconguration strategic phase: The activation of the reconguration process using the dened conguration models (current and target) as input; 4. Save sub-workow: The association of the generated abstract reconguration workow with the IntegrateComponent task implementation. The denition of the conguration models used as input for the reconguration process depends on the integration order of the associated IntegrateComponent task. The current conguration of the rst IntegrateComponent task of the generated plan corresponds to an empty conguration model, while in the other integration steps, the target conguration model of the previous IntegrateComponent task is used as current conguration model of the next task. The target conguration of a IntegrateComponent task is dened based on its current conguration. This is achieved by including the component associated with the IntegrateComponent task in the conguration, together with all connections in which this component is the client, and their respective required components in case they have been tested. In case a required component has not been tested, it is replaced by a stub. In case the component being integrated has been previously replaced by a stub, the stub is removed from the target conguration model, and the component is used in all connections in which the stub was involved.
157
The activation of the strategic phase of the reconguration process is achieved by a Java class that invokes the Yawl workow management system for starting the corresponding workow implementation passing the respective conguration models as parameters and receiving the generated abstract reconguration workow as reply. Similar to the IntegrateComponent, the processing of the RestoreConguration involves the generation of a reconguration sub-workow, and a similar design has been followed when implementing its associated task processing class. However, since this task is only considered for recovery workows, the conguration models used for generating a reconguration sub-workow consist in the current system conguration and an empty conguration model, which is used as target for the reconguration workow. The Ordering calculator component is responsible for calculating the integration order of the received abstract conguration (Calculate integration order activity). In our current implementation, the integration order is calculated based on the the algorithm explored in [79], and stored in this component. The Congurator component is responsible for providing abstract and concrete congurations (supporting the Obtain abstract conguration and Obtain concrete conguration activities), and for managing stubs, which are treated as software components. This component is used by the Ordering calculator component whenever it needs to use a stub. The selection of abstract congurations consider an ordered list with priority for conguration with the biggest number of components. For the purpose of this work, we have employed a simple utility function for selecting a concrete conguration.This component is also responsible for nding replacements for concrete components in case of failures during execution of the generated workow. For now, this is done by selecting a component with biggest utility. The Registry component stores information about the actual components and their respective attributes. This component is updated through the use of Probes associated to the dierent components (represented through the Resources element
158
in Figure 5.5). The Test case selector component is responsible for obtaining the test cases associated with the component under test (Obtain test cases activity), representing the Tactical tasks selector component of the supporting infrastructure. Since we assume that all available test cases are dened as meta-data, this component and its associated Test case repository are implemented as a facade [62] to the Congurator and Registry components. The tests are executed through calls to the provided interfaces of the components, and we use the JUnit2 framework as execution infrastructure. The Reconguration generator component implements the infrastructure presented in Section 4.5, which is used to generate the workows responsible for changing the system conguration. The Recovery handler component employs the undo mechanism presented in the supporting infrastructure. This component has been modied to activate the Reconguration generator component during generation of the recovery workow, and for saving the information used for generating the recovery in a log le.
5.6
Experimental Evaluation
This section presents some experiments performed to demonstrate the application of our framework in the context of component-based integration testing, considering the presence of failures during the integration testing, and evaluating its feasibility and scalability. In these experiments, we assume that the integration order for a particular architectural conguration is calculated outside the generated process, and that all necessary stubs are available. We also assume that the test cases are provided for each concrete component. Regarding the occurrence of failures during execution of generated workows, we only consider the failure of test cases. The experiments are presented in two groups. The rst group demonstrates
2
http://www.junit.org/
159
the application of the integration testing process with and without failures, considering the integration and testing of a simple software application. The second group is a quantitative evaluation of the integration testing process, evaluating its feasibility and scalability. Finally, we conclude the section with a brief discussion of the experiments conducted.
5.6.1
Demonstration of the Integration Testing Process
For demonstrating the instantiation of our framework into the domain of integration testing, we have considered three sets of experiments. The rst set corresponds to the successful execution of the generated workow without any failures. The second set involves a failure that is recovered at the tactical phase of the process by replacing a particular concrete component and its associated test case. The third set involves a failure that is recovered at the strategic phase by changing the abstract conguration, and generating a new abstract workow. In the sequel, we present a web shop application used as example in these experiments, before detailing the experiments conducted. Webshop Application The example application used in these experiments consists in a simplied version of the webshop application presented in Chapter 4. We have considered two abstract congurations, presented in Figure 5.7, which involve seven dierent component types: FrontEnd, ShopServ, ProdDB, PriceCalcWP, PriceCalcNP, DeliveryQuot, and PromoRules. The FrontEnd represents an user interface for purchasing products. The ShopServ is the coordinator of the application, controlling the enquiries and purchases of the clients. The ProdDB represents the products stock database. The PriceCalc captures the business logic responsible for calculating the total price of a client shopping basket, considering the delivery costs (calculated by the DeliveryQuot
160
Figure 5.7: Possible abstract congurations for the web shop example application. component). For simulating two dierent abstract congurations, we have considered two types for the PriceCalc component, based on whether or not this component considers any promotions in its calculations. Figure 5.7a presents an abstract conguration involving the use of promotions. In this conguration, we use the PriceCalcWP component, which requires a component responsible for capturing the existent promotions (PromoRules component). Figure 5.7b presents an example of abstract conguration that does not consider any promotions, involving the PriceCalcNP component. Experiments with no Failures In the sequel, we present one of the experiments without failures, demonstrating the artefacts created during the generation of a workow for the establishment of the abstract conguration of Figure 5.7a. Following the integration testing process, once the integration order is included in the abstract conguration model, the Translate into Pre/Post activity is activated, resulting in a PDDL problem model, which is presented in Listing 5.5 described in PDDL.
161
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
( d e f i n e ( problem I n t e g r a t i o n T e s t i n g P r o b l e m ) ( : domain I n t e g r a t i o n T e s t i n g D o m a i n ) ( : o b j e c t s C1 component C2 component C3 component C4 component C5 component C6 component ) (: init (= ( i n t e g r a t i o n s t e p ) 1 ) (= ( t e s t i n g s t e p ) 1 ) (= ( i n t e g r a t i o n o r d e r C5 ) 1 ) (= ( i n t e g r a t i o n o r d e r C6 ) 2 ) (= ( i n t e g r a t i o n o r d e r C3 ) 3 ) (= ( i n t e g r a t i o n o r d e r C4 ) 4 ) (= ( i n t e g r a t i o n o r d e r C2 ) 5 ) (= ( i n t e g r a t i o n o r d e r C1 ) 6 ) ) ( : g o a l ( and ( t e s t e d C1 ) ( t e s t e d C2 ) ( t e s t e d C3 ) ( t e s t e d C4 ) ( t e s t e d C5 ) ( t e s t e d C6 ) ) ))
Listing 5.5: Example of a PDDL problem model for integrating and testing the abstract conguration of Figure 5.7a.
The objects entry (line 3) identies all components involved in the problem. The pre-condition (init on line 6) states the initial integration step and testing step (line 7), and the integration order of the participant components (lines 8 - 10). It also states that all involved components are not integrated and not tested, indicated by the absence of the associated predicates (integrated and tested). The post-condition (goal on line 13) states that all components must be tested (lines 12 - 13). This PDDL problem model is used as input for the Run planner activity, which generates a PDDL plan model. Listing 5.6 presents an example of a plan generated during this experiment, where we can notice that tasks for integrating and testing components are intercalated.
1 2 3 4 5 6 7 8 9 10 11 12 (INTEGRATECOMPONENT (TESTCOMPONENT C5 ) (INTEGRATECOMPONENT (TESTCOMPONENT C6 ) (INTEGRATECOMPONENT (TESTCOMPONENT C3 ) (INTEGRATECOMPONENT (TESTCOMPONENT C4 ) (INTEGRATECOMPONENT (TESTCOMPONENT C2 ) (INTEGRATECOMPONENT (TESTCOMPONENT C1 ) C5 ) C6 ) C3 ) C4 ) C2 ) C1 )
Listing 5.6: Example of generated plan in PDDL based on the PDDL problem model of Listing 5.5
162
The PDDL plan model is then translated into an abstract workow by the Translate into workow activity, which is presented in Figure 5.8, where we can notice tasks for integrating (IntegrateComponent) and testing (TestComponent) components.
Figure 5.8: Example of abstract workow for integrating and testing the abstract conguration of Figure 5.7a. Each IntegrateComponent task is associated with a sub-workow that changes the system conguration for including the component being integrated. These sub-workows are automatically generated by the Translate into workow activity. Figure 5.9 presents the abstract workow generated for the IntegrateComponent (C4) task. This abstract workow adds the component C4 into the conguration, stops components C5 and C6, connects C4 to components C5 and C6, and starts all involved components before nishing.
Figure 5.9: Abstract sub-workow associated with the IntegrateComponent (C4) task considering the abstract conguration of Figure 5.7a. Once the abstract workow is generated, it is passed to the tactical phase of the
163
integration testing process, where a concrete conguration is obtained and used for populating the parameters of the generated workow. Figure 5.10 presents an example of a concrete conguration.
Gui1 :C1 :FrontEnd
Gui1_IR
SS1_IP
SS1 :C2 :ShopServ

SS1_IR2 PCWP1_IP
SS1_IR1
PDB1_IP
PDB1 :C3 :ProdDB
PCWP1_IR1 DQ1_IP
DQ1 :C5 :DeliveryQuot
PCWP1 :C4 :PriceCalcWP

PCWP1_IR2
PR1_IP
PR1 :C6 :PromoRules
Figure 5.10: Example of concrete conguration for used in our experiment without failure. The concrete workow generated based on this concrete conguration is presented in Figure 5.11, in which the concrete components are used to replace the logical names in the parameters of the workow tasks, and the test cases are associated to the TestComponent tasks based on the concrete component under test.
Figure 5.11: Example of generated concrete workow based on the PDDL plan of Listing 5.6 and concrete conguration of Figure 5.10. Figure 5.12 presents an example of a concrete sub-workow associated with the IntegrateComponent(PCWP1) task of the concrete workow of Figure 5.11, where the logical names have been replaced with concrete component names according to the selected concrete conguration. This sub-workow is based on the abstract sub-workow of Figure 5.9. At the operational phase, the concrete workow is executed, integrating and testing the selected concrete conguration, one component at a time. Since we
164
Figure 5.12: Concrete sub-workow associated with the IntegrateComponent (PCWP1) task. assume no failures during workow execution, the integration testing process nishes with a successful outcome, and the conguration is established and tested. Experiments with Failure - Recovery at Tactical Phase In the sequel, we present the experiments performed to demonstrate how the integration testing process can deal with faults that occur at the operational phase, and which can be recovered at the tactical phase by reusing the generated abstract workow. For that, we have repeated the experiment presented in the previous section, injecting faults on dierent component instances to trigger violations of their test cases. Exploring the concrete workow presented in the previous example (Figure 5.11), we have considered the failure of component instance PCWP1 (task TestComponent(PCWP1)). The current system conguration right after the failure of this task is presented in Figure 5.13. Figure 5.14 presents the recovery workow generated for undoing the eects of the concrete workow. This workow brings the system conguration to the state it was before the execution of the failed workow (Restore conguration task), and set the component instances tested so far as not tested (ClearTest tasks). The Restore conguration task corresponds to a workow generated using the
165
PDB1_IP
PDB1 :C3 :ProdDB
PCWP1_IP
PCWP1_IR1 DQ1_IP

PCWP1_IR2
PR1_IP
PR1 :C6 :PromoRules
Figure 5.13: System conguration after failure of the TestComponent(PCWP1) task.
Figure 5.14: Example of generated recovery workow. reconguration process of Chapter 4, using the conguration of Figure 5.13 as current conguration, and the initial conguration of the integration testing process (i.e., empty conguration) as target. Figure 5.15 presents an example of the subworkow associated with the Restore conguration task. This sub-workow stops the involved components, disconnects any established connection, and removes all components from the conguration.
Figure 5.15: Example of sub-workow associated with the Restore conguration task of the recovery workow for experiments with recovery at tactical phase.
166
After the execution of the recovery workow, the process goes back to the tactical phase, where the abstract workow is reused, and a new concrete conguration will be obtained. It is important to observe that the failure of a test case means that the component under test and the components it depends on do not interoperate in the tested conguration. In this case, one or more of the component instances need to be replaced, and the new concrete conguration (presented in Figure 5.16) replaces the component instance that failed the test (component instance PCWP1 that is replaced by PCWP2 component instance).
Gui1 :C1 :FrontEnd
Gui1_IR
SS1_IP
SS1 :C2 :ShopServ

SS1_IR2 PCWP2_IP
SS1_IR1
PDB1_IP
PDB1 :C3 :ProdDB
PCWP2_IR1 DQ1_IP

PCWP2_IR2
PR1_IP
PR1 :C6 :PromoRules
Figure 5.16: New concrete conguration replacing PCWP1 (the component that failed the test) with PCWP2. Based on the abstract workow previously generated (presented in Figure 5.8, the new concrete conguration (Figure 5.16) and the test cases of its components, a new concrete workow is obtained. This new concrete workow is presented in Figure 5.17. Compared to the concrete workow of Figure 5.11, we can notice the replacement of the PCWP1 component instance with the PCWP2 component instance (shaded tasks). The test case associated with the Testcomponent (PCWP2) task has also been modied. Some of the sub-workows of the concrete workow have also been modied. Figure 5.18 presents the sub-workow associated with the IntegrateComponent (PCWP2) task of the new concrete workow, where the PCWP1 component has been replaced with the PCWP2 component (shaded tasks) when compared to the sub-workow of the previous section (Figure 5.12). Finally, the concrete workow is passed to the operational phase, where it
167
Figure 5.17: Example of a new concrete workow for integration testing generated during our experiments with recovery at the tactical phase.
Figure 5.18: Example of concrete sub-workow associated with the IntegrateComponent(PCWP2) task. is executed. This time, all components pass their test cases, and the integration testing process nishes with a successful outcome, resulting in the concrete conguration of Figure 5.16 integrated and tested. Experiments with Failure - Recovery at Strategic Phase We have performed another experiment involving failures during the execution of the generated concrete workow, with the goal of investigating the behaviour of our approach in the presence of failures that can only be recovered at the strategic phase of the integration testing process (the process that generates the workow that manages integration testing). We have considered the concrete workow of Figure 5.17, and have injected
168
faults in the PCWP2 component instance, causing the failure of the TestComponent(PCWP2) task, and triggering the generation of a recovery workow. The current system conguration after the failure of this task is presented in Figure 5.19. The shaded component identies the dierence between this conguration and the example presented in our previous experiment (Figure 5.13), where PCWP1 is replaced with PCWP2, reecting the new concrete conguration used. The recovery workow generated for this scenario is similar to the recovery workow of our previous experiment (presented in Figure 5.14), with a dierence in the Restore conguration sub-workow, which is presented in Figure 5.20, where PCWP2 is used instead of PCWP1. After executing the recovery workow, the integration testing process goes back to the tactical phase. In the current scenario, we have reduced the number of component instances available in a way that the generated abstract workow is no longer valid (i.e., it is not possible to select a concrete conguration for generating a concrete workow). The process then goes back to the strategic phase, where the abstract conguration of Figure 5.7b is selected, and its integration order is calculated. Following the integration testing process, the new abstract conguration model with its associated integration order is then translated into a PDDL problem model, which is presented in Listing 5.7. Compared to the previous problem model (Listing 5.5), this PDDL problem model reects the abstract conguration of Figure 5.7b, which involves ve components.
PDB1 :C3 :ProdDB
PDB1_IP
PCWP2_IP
PCWP2_IR1 DQ1_IP
PCWP2_IR2 PR1_IP
PR1 :C6 :PromoRules
Figure 5.19: Conguration after failure of the TestComponent(PCWP2) task.
169
Figure 5.20: Example of sub-workow associated with the Restore conguration task of the recovery workow for experiments with recovery at strategic phase.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ( d e f i n e ( problem I n t e g r a t i o n T e s t i n g P r o b l e m ) ( : domain I n t e g r a t i o n T e s t i n g D o m a i n ) ( : o b j e c t s C1 component C2 component C3 component C4 component C5 component ) (: init (= ( i n t e g r a t i o n s t e p ) 1 ) (= ( t e s t i n g s t e p ) 1 ) (= ( i n t e g r a t i o n o r d e r C5 ) 1 ) (= ( i n t e g r a t i o n o r d e r C3 ) 2 ) (= ( i n t e g r a t i o n o r d e r C4 ) 3 ) (= ( i n t e g r a t i o n o r d e r C2 ) 4 ) (= ( i n t e g r a t i o n o r d e r C1 ) 5 ) ) ( : g o a l ( and ( t e s t e d C1 ) ( t e s t e d C2 ) ( t e s t e d C3 ) ( t e s t e d C4 ) ( t e s t e d C5 ) ) ))
Listing 5.7: Example of a PDDL problem model for integrating and testing the abstract conguration of Figure 5.7b.
An example of the plan generated based on this PDDL problem model is presented in Listing 5.8. Similar to the rst experiment, this PDDL plan model is translated into an abstract workow, which is presented in Figure 5.21. Compared to the abstract workow of Figure 5.8, this abstract workow contains fewer tasks (corresponding to the ve components of the conguration of Figure 5.7b). Again, each IntegrateComponent task is associated with a sub-workow that changes the system conguration (similar to our previous experiment). Figure 5.22 presents an example of a generated sub-workow for the IntegrateComponent (C4) task of the new abstract workow. Compared to the sub-workow of Figure 5.9, we can notice that component C4 is only involved in one connection, reecting
170
1 2 3 4 5 6 7 8 9 10
(INTEGRATECOMPONENT (TESTCOMPONENT C5 ) (INTEGRATECOMPONENT (TESTCOMPONENT C3 ) (INTEGRATECOMPONENT (TESTCOMPONENT C4 ) (INTEGRATECOMPONENT (TESTCOMPONENT C2 ) (INTEGRATECOMPONENT (TESTCOMPONENT C1 )
C5 ) C3 ) C4 ) C2 ) C1 )
Listing 5.8: Example of generated plan in PDDL for abstract conguration of Figure 5.7b.
Figure 5.21: Example of generated abstract workow for the conguration of Figure 5.7a. the new abstract conguration used. The new abstract workow and its respective abstract conguration are passed to the tactical phase, where a new concrete conguration is obtained and used to generate a new concrete workow. Figure 5.23 presents the new concrete conguration, which is then used for replacing the logical names of the abstract workow. The concrete components are also used for obtaining their respective test cases, which are associated to the tasks of the abstract workow, resulting in the concrete workow of Figure 5.24. Figure 5.25 presents an example of the concrete sub-workow associated with the IntegrateComponent(PCNP1) task (based on the concrete conguration of Figure 5.23, and the abstract sub-workow of Figure 5.22). The generated concrete workow is then executed at the operational phase, this time without any failures in the test cases, resulting in the concrete conguration of Figure 5.23 integrated and tested.
171
Figure 5.22: Abstract sub-workow associated with the IntegrateComponent (C4) task considering the abstract conguration of Figure 5.7b.
Gui1 :C1 :FrontEnd
Gui1_IR
SS1 :C2 :ShopServ

SS1_IR2
SS1_IR1 PDB1_IP
PDB1 :C3 :ProdDB
SS1_IP
PCNP1_IP
PCNP1 :C4 :PriceCalcNP
PCNP1_IR DQ1_IP
Figure 5.23: Concrete conguration based on abstract conguration of Figure 5.7b. These experiments have demonstrated that our integration testing process is able to integrate and test an architectural conguration with and without failures during its execution, and showing how our approach can recover from failures at dierent phases. This can be achieved by either replacing a component instance that failed its test case for generating a new concrete workow, or considering a new abstract conguration for generating a new abstract workow. We have repeated these experiments with a conguration that requires stubs during its integration testing, and the generated workow was able to integrate and test the conguration, employing stubs, and replacing these stubs with concrete component instances, according with the calculated integration order of the conguration.
5.6.2
Quantitative Evaluation
We have also performed experiments for evaluating the performance and scalability of the integration testing process, measuring the time to generate a concrete
172
Figure 5.24: Concrete workow generated based on concrete conguration of Figure 5.23.
Figure 5.25: Concrete sub-workow associated with the IntegrateComponent (PCNP1) task considering the concrete conguration of Figure 5.23. workow for integrating and testing a particular abstract conguration. In these experiments we have employed the SGPlan6 planner [80], and have considered an average of ve executions for the times presented. For each experiment, the number of components available is the same number of components required by the abstract conguration received as input as, based on the activities considered when measuring the time for generating a workow (shaded activities of Figure 5.26), the time to generate a workow is not aected by the number of components available (as demonstrated in the experiments of Chapter 4). In our rst experiment, we have evaluated the performance of our approach, considering the abstract conguration of Figure 5.7b. The rst analysis performed was related to the activities of the integration testing process, whose times are
173
Figure 5.26: Integration testing process identifying the activities considered during the quantitative experiments. presented in Table 5.3 with their respective standard deviation. From a total generation time of 567.818 ms, only 31.060 ms were associated with the tactical phase of the generation. Focusing on the strategic phase, we have considered the individual times of each activity, with the Translate into workow activity corresponding to 88% of the total time for generating a workow.
Strategic phase Tactical Translate Run Translate phase into planner into pre/post workow 6.150 28.863 501.745 31.060 Total
567.818
Table 5.3: Times obtained for the activities of the integration testing process (times presented in ms). Based on this, we have focused our analysis into the Translate into workow activity, considering the activities that translate a PDDL plan model into an abstract workow (which have been presented in Figure 5.6). The times of the individual activities are presented in Table 5.4, where Process tasks corresponds to the times for processing all tasks of the generated plan and involves the use of planning for generating reconguration sub-workows. These numbers have conrmed that the processing of the workow tasks is the most time consuming activity since it needs to generate a workow for each IntegrateComponent task.
174
Translate into workow Load pre- Process Load Total condition tasks postcondition 3.987 497.415 0.004 501.406
Table 5.4: Times obtained for the Translate into workow activity (times presented in ms). To further investigate the impact caused by the processing of the dierent task templates, we have considered the times for processing each task of the PDDL plan model. The total time for processing all TestComponent tasks of the plan corresponds to 0.145 ms, while the total time for all IntegrateComponent tasks is 496.958 ms. Focusing on the IntegrateComponent tasks, we have considered the dierent activities involved in their processing, which are presented in Table 5.5.
Process task implementation Step #1 Step #2 Step #3 Step #4 Step #5 Total (C5) (C3) (C4) (C2) (C1) 0.034 0.041 0.038 0.039 0.044 0.196 Process IntegrateComponent Build target Reconguration models strategic phase 0.742 1.275 1.829 2.980 2.838 9.665 68.427 81.907 89.516 101.193 145.943 486.985 Save abstract sub-workow 0.022 0.022 0.023 0.022 0.022 0.111 Total 69.225 83.245 91.406 104.234 148.847 496.958
Table 5.5: Times for instantiating the IntegrateComponent tasks (times presented in ms). We can observe that most of the time is associated with the generation of reconguration workows (486.985 ms), which correspond to 97% of the time associated with the Translate into workow activity (501.720 ms). We have also observed that the time for generating a reconguration workow at each integration step increases with the number of steps, which is caused by the increase in the number of components involved in each integration step. All abstract components of the current and target system congurations of a particular integration step are considered by the AI planner when generating a reconguration workow, as specied by the reconguration process presented in Chapter 4. Even though the generated reconguration workow may not involve all components, these components are treated as planning objects by the AI planner, which increases the
175
search space, explaining the increase in the generation time with the number of steps. Scalability Experiments We have conducted another set of experiments involving larger conguration sizes in order to evaluate the scalability of our approach. These experiments involved the same pipe-and-lter software architecture used in our experiments with the reconguration process (presented in Section 4.6.2), which we present again in Figure 5.27. This architecture consists of three types of components (source, lter and sink) structured based on the pipe-and-lter architectural style, where we can control the conguration size (in terms of number of components/connection) by changing the number of lters involved.
Figure 5.27: Example of abstract congurations with dierent number of components. In these experiments, we have observed the total time to generate a concrete workow for integrating and testing a particular abstract conguration, varying the number of components involved in the conguration. Figure 5.28 presents the times obtained when varying the size of the conguration. This graph shows an exponential progression in the time to generate a workow with the increase in the conguration size, which restricts the application of our approach based on the timeliness requirements of the software system being managed by the generated workow. Based on these results, we have repeated the analysis of the dierent activities of the integration testing process, which is presented in Figure 5.29. It is important
176
Figure 5.28: Time for generating a workow varying the size of the conguration. to mention that the scales of the graphs presented are dierent, as each activity presents a very distinct time.
Figure 5.29: Time for individual activities of the integration testing process, varying the size of the conguration. As expected, the Translate into pre/post activity presents a linear progression when increasing the size of the conguration. Comparing the time of the Run planner activity against the total time, we noticed that this activity has very few impact in the integration testing process, and presents a quadratic progression.
177
On the other hand, these results conrm the impact of the Translate into workow activity, which presents an exponential progression. By analysing the times of this activity against the total time of the integration testing process, we noticed that the time associated with the generation of reconguration workows corresponds to 88% of the total generation time for a conguration involving ve components, and continually increases to 99% for the dierent conguration sizes used in this experiment. Finally, the Tactical phase presents a linear progression, corresponding to less than 1% of the total time to generate a workow. These experiments have demonstrated that our approach is suitable to be applied for a conguration with a reasonable number of components, showing that the architectural recongurations involved in the integration testing cause most impact in the generation of workows, and limit the application of our approach based on the timeliness requirements of the software system being tested.
5.6.3
Discussion
The experiments presented in this chapter have shown that our approach is able to integrate and test a particular system conguration, and also to deal with failures that can be recovered at dierent phases of the integration testing process (e.g., replacing a particular component instance, or generating a new abstract workow based on a new abstract conguration for the system). These experiments have also shown that the time it takes to generate a workow is exponential in relation to the size of the conguration, showing that our approach is feasible to be applied to a conguration with up to a certain number of components. This is caused by the several reconguration sub-workows that are generated as part of the process, where the time it takes to generate a sub-workow increases with the number of integration steps. The growth in the number of components involved in each integration step contributes to expanding the search space considered by the AI planner, which aects the time it takes to generate a reconguration plan. In this chapter, we were interested in evaluating our framework for dynamic generation of workow, and because of that, we have made some assumptions and
178
simplications related to the dierent activities associated with integration testing. We have assumed the existence of the dierent testing harnesses (such as the integration testing order, component stubs and test cases) needed for generating the workow that controls the integration testing. We believe that the integration order and component stubs should be dynamically dened. The integration order may change based on the coverage criteria considered (e.g., required/provided interfaces, or control ow based on interface operations and exceptions [124]), and aects the provision of component stubs, as dierent stubs are needed based on the order being considered. Although there are techniques for dynamically building these two test harnesses (integration order [79] and stubs [105] [124]), our assumption that they are already available restricts our approach to architectural congurations known at development-time, where one would know what stubs are necessary. On the other hand, the provision of test cases is a reasonable assumption, as demonstrated by the number of approaches exploring built-in testing and metadata-based testing [123]. Our approach also assumes that a component that has been tested while connected to a stub does not need to be re-tested when the stub is replaced by a concrete component. This assumption is based on the existing works on integration testing (e.g., [143]), which, to the best of our knowledge, have not mentioned this as an issue. Another simplication involves the replacement of components in case of test failures. In this situation, our approach marks the last integrated component as failed, and this component is not considered in any other conguration. Also, the scalability experiments considered only a particular type of architecture (based on the pipe-and-lter style).
5.7
Chapter Summary
This chapter has presented the instantiation of our framework for dynamic generation of workows into the domain of component-based integration testing. The
179
framework has been used as a basis for the denition and implementation of a process that controls the generation and execution of a workow that manages the integration testing of a software system in terms of its architecture. It is assumed that components and their respective test cases are available, equally the order in which the components should be integrated, and any necessary stubs. The dened integration testing process captures the activities involved in the integration testing of software components, and provides the means for the automatic execution of component-based integration testing. This chapter has demonstrated that our framework can be applied into dierent application domains, and conrms the ability of our framework to be easily instantiated into a prototype for integration testing. Compared with the instantiation of our framework into the domain of architectural reconguration, the component-based integration testing domain has demonstrated the use of the framework when considering integral workows, and that multiple instantiations of our framework can co-exist in the same system, since the workow that coordinates integration testing involves several architectural recongurations. In order to evaluate our framework, we have performed some experiments exploring the integration testing process. These experiments have shown that our approach is able to generate workows for managing the integration testing of component-based system. The experiments have also shown that our approach is feasible for congurations with a reasonable amount of components. In order to tackle the limitations identied in this chapter, future research directions involve further experiments with the integration testing process, considering dierent architectural styles, and further investigation on the re-test of a conguration when a stub is replaced by another component. Another issue is related to which component instance to replace in case of failure of a test case (e.g., the one that failed the test, or one of its dependencies), where it is necessary to analyse the failure information in order to determine the root cause of the failure. Another possibility includes the development of a fully automated integration testing environment, one of the dreams of the software testing research
180
community [22]. For that, it is necessary the incorporation of tools and techniques for dynamically generating the dierent testing harness, for example, tools that support the selection and generation of test cases [31], calculation of integration order [79], and the generation of component stubs [105] [124].
Chapter 6 Conclusions
This thesis has presented a framework for the automatic generation of processes for self-adaptive software systems based on workows, AI planning and model transformation. The framework can be applied to dierent application domains, encompassing a reference process, a supporting infrastructure, and guidelines for its instantiation. Moreover, the framework reduces the search space considered by a planner by splitting the generation into two levels of abstraction, provides support for generating dierent types of workows, and can deal with failures in a well-dened and structured fashion. The framework has been instantiated into two application domains, namely, architectural reconguration and component-based integration testing, which have been used for performing experimental evaluation. Considering architectural reconguration, we have demonstrated how our framework can be employed for dynamically generating the workows responsible for changing the system conguration. Regarding integration testing, our framework has been applied to dynamically generate workows that integrate and test a component-based software system. A discussion on the contributions made by this thesis is presented in Section 6.1. Section 6.2 presents an evaluation of the work presented. Section 6.3 describes some issues and limitations of our work. Section 6.4 presents some directions for further research. 181
CHAPTER 6. CONCLUSIONS
182
6.1
Thesis Contributions
The aim of our work was the development of a framework for the dynamic generation of processes for self-adaptive software systems that can be applied to dierent application domains. In pursuit of this aim, this thesis has made the following contributions. The main contribution of this thesis was the denition of a reference process, and its supporting infrastructure, for the dynamic generation of processes, identifying the main activities/components associated with process generation, and dening customisation points in both the reference process and its supporting infrastructure that can be used to tailor process generation into dierent application domains. As part of our framework, another contribution is the denition of a methodology for the application of process generation into dierent domains exploring the framework presented in this thesis. In fact, this is the rst work to consider the dynamic generation of processes across dierent application domains, clearly identifying what should be modied for supporting changes in the generation of processes, and describing how these modications should be made. Another contribution of this thesis is the exploration of model transformation techniques for translating domain specic models into planning models that can be used for generating processes. This supports the use of domain specic models, allowing the leverage of existing domain specic tools for dealing with these models, while increases the portability of our approach, and allows the use of dierent planning techniques, process specication languages and execution environments.
6.2
Discussion
The framework presented in this thesis has identied the common mechanisms needed for engineering process generation solutions across dierent application domains. In order to show that, the framework has been instantiated into two
183
application domains: architectural reconguration (presented in Chapter 4) and component-based integration testing (presented in Chapter 5), which have been used for conducting a series of experiments for evaluating our framework in the context of their respective application domains. This section presents a summary of the experiments conducted and a more general discussion of the results obtained. The case studies presented in this thesis have demonstrated how our framework can be tailored to generate the processes that manage self-adaptive software systems, presenting examples of the several models that are automatically generated, and showing how our approach can recover from failures. The experiments conducted have shown that our approach is able to generate the workows that manage software architectural reconguration and component-based integration testing, demonstrating dierent instantiations of our framework. Moreover, the framework clearly identies modications necessary for accommodating changes when generating processes, which has been demonstrated by the instantiation of our framework into variations of particular application, i.e., software reconguration with dierent architectural features, such as software components with/without quiescence, and transfer of state between components. Based on the experiments conducted, we have demonstrated the feasibility of our approach, and that the division between strategy and tactics indeed improves the performance and scalability associated with the generation of workows when compared against two existing solutions. Concerning architectural reconguration, the time it takes to generate a workow presents a quadratic progression with the size of the conguration. For example, it takes around 17 seconds to generate a workow for establishing a conguration involving 100 components. Concerning component-based integration testing, the time it takes to generate a workow presents an exponential progression in relation to the size of the conguration. For example, it takes around 17 seconds to generate a workow for integrating and testing a conguration involving 30 components. This behaviour
184
is inherent of the type of AI planner we have employed in this work, which restricts the application of our approach up to a reasonable conguration size based on the timeliness requirements of the managed software system.
6.3
Limitations
Some limitations of our approach have already been reported with regard to the domains of architectural reconguration and component-based integration testing. This section presents some general limitations of our framework. In our approach we have explored domain independent planning techniques, in which a planner takes as input the problem specication and knowledge about its domain [112]. This choice, as opposed to domain specic or domain-congurable planning which include domain specic knowledge to constrain the search space, was motivated by our aim of developing a framework that can be applied across dierent application domains. In the context of domain independent planning, our work has explored what is referred to as classical planning, which makes a number of assumptions about the planning domain, and encompasses techniques based on state-space search, plan-space search, graph-based planning, and translation of planning problems into satisability or constraint satisfaction problems [71] [112]. As a consequence of the use of classical planning, our approach is restricted to those applications that do not have strict timeliness requirements (i.e., realtime systems). This has been demonstrated by the experiments conducted for evaluating the scalability of our framework, which presents a quadratic progression when considering architectural reconguration (Chapter 4), and an exponential progression when dealing with component-based integration testing (Chapter 5). Another related limitation concerns the heuristics considered during plan generation. We have successfully used dierent planners based on dierent techniques and dierent heuristics applied to the planner search space. However, we have not investigated how domain specic (non-functional) information can be used for guiding the generation of plans. Moreover, we have also not considered planning
185
techniques that deal with partial knowledge about the application domain, which is also referred to as planning under partial observability [112], as evidenced by the need to fully identify an abstract conguration before generating an abstract workow for software reconguration (Chapter 4). Another consequence of classical planning, is that our approach is limited to the generation of simple sequential workows. In other words, the task templates that can be used to generate a workow have deterministic eects. This simplication happens because of one of the assumptions of classical planning, in which non-determinism is not considered during plan generation. Another limitation of our approach involves the decisions associated with the incorporation of fault-tolerance. Although the task templates for our framework are structured using atomic actions, one issue that was not yet fully investigated is how to exploit this for the provision of fault tolerance. In our approach we have simplied the possible outcomes associated with atomic actions, and restricted it to a backward error recovery strategy. The recovery mechanism adopted at the operational phase tries to undo the eects of the generated workow in case of failure during its execution (trying to return the resources aected to the state they had at the beginning of the generation) before returning control to the tactical phase. However, the complete undo of a generated workow is not always necessary, and in some cases, undesirable or even impossible. Another limitation of our work is related to the correctness of generated workows. For now, we assume that a generated workow is corrected with regard to the received input (goals), and these are guaranteed by the dierent transformations being employed during the generation process. However, we have not applied any type of workow verication technique in order to guarantee the correctness of a generated workow.
186
6.4
Future Work
This section presents some further directions of research exploring the work presented in this thesis, which are grouped in the following categories: software product line, meta-generation layer, verication and validation, dierent planning techniques, fault tolerance, distributed process generation and execution, and other application domains. Software Product Line During our experiments we noticed the necessity of dealing with variability of the generation of processes in order to better support the instantiation of our framework into dierent variations of a particular application domain. For example, the generation of processes for integration testing may involve dierent types of stubs [105] that are created in dierent manners. Another example involves the use of dierent task templates for dealing with variations of the application domain, such as architectural reconguration with and without state transfer between software components. To deal with this, a future research direction is the application of software product line concepts for managing the generation of processes. Such research would involve the application of congurable process models [73] [74] for capturing the reference process of our framework, possibly taking inspiration from the existing work on software process lines [125] [141], and investigating how these could improve the actual generation of workows. Meta-generation layer Furthermore, some of the changes in the generation of processes may need to be conducted during run-time. Thus, another future research direction would be to explore a meta-generation of processes, similar to the concepts of metaadaptation, where the mechanisms for adapting a software systems are also adapted during run-time. This would be based on the concepts of computational
187
reection and models at run-time [28]. We envision the denition of a meta-generation layer, which would be responsible for, at a rst moment, conguring (equivalent to a parametric adaptation) the process executed at the generation layer (composed of the strategic and tactical phases), which in turn generates the workow that is executed at the operational layer. On a second moment, the meta-generation layer would dynamically generate (structural adaptation) the processes of the generation layer, applying our framework recursively. Such meta-generation could be applied, in conjunction with the ideas of software product lines, for dynamically dealing with variability in a particular application domain, or for dealing with dierent instantiations of our framework (similar to our case study in component-based integration testing - Chapter 5). Verication and Validation Another research direction concerns the use of verication and validation techniques for guaranteeing the correctness of a generated workow with respect to the specication (domain specic models) received as input. We envision three aspects that might be considered for such research: 1. We rely on model transformation techniques for translating domain specic models into planning problems, and for translating generated plans into workows. In this way, the guarantee of correct workows could be achieved by guaranteeing the correctness of the transformation rules being applied, e.g., [53]. 2. Planning guarantee the correctness of a generated plan by exploring the predicates used during planning based on the dened domain model. A plan for a given problem is found if the state (set of predicates) resultant from its execution contains the goal state (workow post-condition), in other words, a plan is said to be correct if the goal to be achieved by the plan is a sub-set of the state that results from the plan execution.
188
3. Techniques for analysis and verication of workows [58] [99] check if there are dead-ends in the workow specication, or check for behaviour mistakes like the data type between the tasks. In this context, a possible solution for guaranteeing the correctness of a generated workow would consider the dierent aspects cited above. Model transformation, with the guarantee of correctness of the transformation rules [53], could be used for translating the planning outputs into domain specic models that can be directly veried against the received specication. Concerning planning, some sort of verication technique could be applied to the planning domain model dened during the instantiation of our framework. Finally, traditional workow verication techniques could be applied to the generated workow [58] [99] and their output translated into domain specic models for verication. Dierent Planning Techniques Since dierent application domains may require dierent planning techniques, it is our intent to investigate other techniques that can be incorporated into the framework. In particular, the following issues can be considered when investigating other planning techniques. The use of domain-congurable planning in order to improve the performance of our approach, which would involve to explore the usage of hierarchical task networks (HTN) and control rules [112]. HTN planning is based on a collection of tasks that are decomposed into subtasks until the planner reaches primitive tasks that can be executed. These primitive tasks correspond to the task templates dened in this thesis, and a collection of methods would be used to guide the decomposition. Control-rule planners include a set of domain specic rules (expressed using some sort of logic) that are used to reduce the search space considered by the planner. A future work in this direction would be the mapping of domain specic non-functional properties into decomposition methods or control rules.
189
The investigation of non-classical planning techniques concerning, for example, planning under uncertainty, where the possible outcomes of the available actions are non-deterministic, which may lead to a plan with many dierent execution paths. Among the techniques being used for planning with uncertainty, we can cite planning based on Markov Decision Processes, and planning by model checking [71]. The use of such techniques could provide support for the generation of workows involving complex control ow constructs, such as conditional and parallel branches and loops. Fault Tolerance Since we have adopted several simplications concerning the fault-tolerant aspects of our approach, another future work involves the relaxation of the assumptions made. In this sense, it is necessary to investigate how the other aspects associated with atomic actions aect the generation of processes. For example, how workows with parallel branches or the use of forward error recovery impact our framework. Another aspect is the incorporation of checkpoints [61], and the investigation on how these checkpoints can be automatically dened, exploring the idea of partial roll backs and restart to workows [151]. Distributed Process Generation and Execution In our work, we have adopted a centralised control, where the generation and execution of workows is managed from a single point. In this context, two aspects related with distributed control can be considered as future work: distributed workow execution and distributed workow generation. The rst aspect concerns the use of a distributed process execution environment (such as JOpera [78]). In such environment, the tasks that compose a workow are performed in a distributed fashion, providing an environment for investigating workows with parallel execution branches, and the impact of distributed exception handling capabilities of atomic actions applied to our framework.
190
This would also allow the instantiation of the framework into application domains such as grid computing environments, and intensive data processing systems. Another aspect concerns the distributed generation of processes, exploring the idea of distributed planning [129], and investigating how planning techniques that support partial observability (partial knowledge of the domain environment during generation) could be employed. Other Application Domains Another future work is the instantiation of our framework into other application domains, in order to evaluate its overall eectiveness. An example of application domain is the generation of Web service-based business processes, exploring semantic information as the means for capturing Web services as task templates at the strategic level, and non-functional properties and Web service selection mechanisms at the tactical phase. Other example is the generation of workows for performing scientic experiments in grid computing environment.
Appendix A Domain Independent Transformation Rules

This appendix contains the full code of the domain independent Acceleo transformation rules used to translate PDDL models into PDDL specications. Problem model to problem specication
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 [ comment e n c o d i n g = UTF8 / ] [ module G e n e r a t e P r o b l e m S p e c i f i c a t i o n ( h t t p : / / pddl . pddlmodel ) / ] [ t e m p l a t e p u b l i c g e n e r a t e P r o b l e m S p e c i f i c a t i o n ( p : ProblemModel ) ] [ comment @main / ] [ f i l e ( P d d l P r o b l e m F i l e . pddl , f a l s e , UTF8 ) ] ( d e f i n e ( problem [ p . problem / ] ) ( : domain [ p . domain . domain / ] ) (: objects [ f o r ( o : ProblemObject | p . o b j e c t s ) ] [ o . name / ] [ o . t y p e . v a l u e / ] [/ for ] ) (: init [ for ( ini : String | p . i n i t [ ini /] [/ for ] )
) ]
( : g o a l ( and [ for ( goal : String | p . goal ) ] [ goal /] [/ for ] ) ) [ i f ( p . c o n s t r a i n t s >notEmpty ( ) ) ] (: constraints ( and
191
APPENDIX A. PDDL TRANSFORMATION RULES
192
31 32 33 34 35 36 37 38 39
[ for ( const : String | p . constraints ) ] [ const /] [/ for ] ) ) [/ i f ] ) [/ f i l e ] [ / template ]
Listing A.1: Transformation rules from PDDL problem model to PDDL problem specication.
Domain model to domain specication

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 ) [/ for ] [/ i f ] [ i f ( d . d e r i v e d P r e d i c a t e s >notEmpty ( ) ) ] [ for ( derivedPredicate : DerivedPredicate | d . derivedPredicates ) ] ( : d e r i v e d [ d e r i v e d P r e d i c a t e . headValue / ] [ d e r i v e d P r e d i c a t e . bodyValue / ] ) (: predicates [ f o r ( pred : P r e d i c a t e | d . p r e d i c a t e s ) ] [ pred . v a l u e / ] [/ for ] ) [/ i f ] [ i f ( d . t y p e s >notEmpty ( ) ) ] ( : types [ f o r ( t : Type | d . t y p e s ) ] [ t . value /] [/ for ] [ comment e n c o d i n g = UTF8 / ] [ module G e n e r a t e D o m a i n S p e c i f i c a t i o n ( h t t p : / / pddl . pddlmodel ) / ] [ t e m p l a t e p u b l i c G e n e r a t e D o m a i n S p e c i f i c a t i o n ( d : DomainModel ) ] [ comment @main / ] [ file ( PddlDomainFile . pddl , f a l s e , UTF8 ) ]
( d e f i n e ( domain [ d . domain / ] ) ( : requirements [ f o r ( r e q : Requirement | d . r e q u i r e m e n t s ) ] : [ req . value /] [/ for ] )
APPENDIX A. PDDL TRANSFORMATION RULES
193
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 67 68 69 70 71 ) [/ f i l e ] [ / template ] ) [/ for ] [/ i f ] ) [ else ] [ a c t . e f f e c t > f i r s t ( ) . v a l u e / ] : effect [ i f ( a c t . e f f e c t >s i z e ( ) > 1 ) ] ( and [/ i f ] ) [ else ] [ a c t . p r e c o n d i t i o n > f i r s t ( ) . v a l u e / ] ) : p r e c o n d i t i o n [ i f ( a c t . p r e c o n d i t i o n >s i z e ( ) > 1 ) ] ( and [ f o r ( act : Action | d . a c t i o n s ) ] ( : a c t i o n [ a c t . name / ] : parameters ( [ f o r ( para : Parameter | a c t . p a r a m e t e r s ) ] [ para . name / ] [ i f ( para . type>notEmpty ( ) ) ] [ para . t y p e . v a l u e / ] [ / i f ] [/ for ] ) [/ i f ] [ i f ( d . f u n c t i o n s >notEmpty ( ) ) ] (: functions [ f o r ( func : Function | d . f u n c t i o n s ) ] [ f u n c . h e a d e r / ] [ i f ( f u n c . returnT ype . s i z e ( ) >0) ] [ f u n c . re turnType / ] [ / i f ] [/ for ]
[ for ( predi : ActionPredicate | act . precondition ) ] [ predi . value /] [/ for ]
[ for ( predi : ActionPredicate | act . e f f e c t ) ] [ predi . value /] [/ for ]
Listing A.2: Transformation rules from PDDL domain model to PDDL domain specication.
Appendix B Domain Specic Transformation Rules for Reconguration

This appendix contains the full description of the domain specic transformation rules dened for architectural reconguration (Chapter 4).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 @nsURI @nsURI @nsURI @nsURI PDDL=h t t p : / / p d d l . p d d l m o d e l A r c h i t e c t u r e M e t a m o d e l=h t t p : / / a r c h i t e c t u r e . x a d l / i n s t a n c e=h t t p : / /www. i c s . u c i . edu / pub / a r c h / xArch / i n s t a n c e . x s d t y p e s=h t t p : / /www. i c s . u c i . edu / pub / a r c h / xArch / t y p e s . x s d
module Reconfiguration2PDDLBQR ; create OUT : PDDL from IN : A r c h i t e c t u r e M e t a m o d e l , IN2 : PDDL; rule DomainReferences { from d : PDDL! DomainModel , r e p o : A r c h i t e c t u r e M e t a m o d e l ! R e p o s i t o r y to t : PDDL! ProblemModel ( problem < R e c o n f i g u r a t i o n P r o b l e m , domain < d , o b j e c t s < Sequence{ A l l components t h i s M o d u l e . c o m p o n e n t C o l l e c t i o n ( )> c o l l e c t ( e | t h i s M o d u l e . component2PddlObject ( e ) ) , A l l r e q u i r e d i n t e r f a c e s if t h i s M o d u l e . r e q u i r e d I n t e r f a c e N a m e s C o l l e c t i o n ( )>isEmpty ( ) then t h i s M o d u l e . r e q u i r e d I n t e r f a c e N a m e 2 P d d l O b j e c t ( dummyRequired ) e l s e t h i s M o d u l e . r e q u i r e d I n t e r f a c e N a m e s C o l l e c t i o n ( )> c o l l e c t ( e | thisModule . requiredInterfaceName2PddlObject ( e ) ) endif , A l l p r o v i d e d i n t e r f a c e s i f t h i s M o d u l e . p r o v i d e d I n t e r f a c e N a m e s C o l l e c t i o n ( )>isEmpty ( ) then t h i s M o d u l e . p r o v i d e d I n t e r f a c e N a m e 2 P d d l O b j e c t ( dummyProvided ) e l s e t h i s M o d u l e . p r o v i d e d I n t e r f a c e N a m e s C o l l e c t i o n ( )> c o l l e c t ( e | thisModule . providedInterfaceName2PddlObject ( e ) ) endif }, i n i t < Sequence{ Components o f t h e c u r r e n t c o n f i g u r a t i o n r e p o . a r c h S t r u c t u r e >a t ( 1 ) . component>
194
APPENDIX B. RECONFIGURATION TRANSFORMATION RULES
195
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 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
c o l l e c t ( c | t h i s M o d u l e . processCurrentComponentPre ( c ) ) , Components o f t h e s e l e c t e d c o n f i g u r a t i o n t h a t a r e n o t on c u r r e n t configuration ( t h i s M o d u l e . getCompIds ( r e p o . a r c h S t r u c t u r e >a t ( 2 ) . component ) t h i s M o d u l e . getCompIds ( r e p o . a r c h S t r u c t u r e >a t ( 1 ) . component ) )> c o l l e c t ( e | r e p o . a r c h S t r u c t u r e >a t ( 2 ) . component>s e l e c t ( f | f . i d = e ) )> f l a t t e n ( )> c o l l e c t ( c i | t h i s M o d u l e . p r o c e s s S e l e c t e d C o m p o n e n t P r e ( c i ) ) > a s S e t ( ) , C o n n e c t i o n s o f t h e c u r r e n t c o n f i g u r a t i o n r e p o . a r c h S t r u c t u r e >a t ( 1 ) . l i n k > c o l l e c t ( l i | thisModule . linkToConnectedAtInit ( l i ) ) Connection o f t h e s e l e c t e d c o n f i g u r a t i o n Not e s t a b l i s h e d , do n o t h i n g }> f l a t t e n ( ) , g o a l < Set { Components o f t h e c u r r e n t c o n f i g u r a t i o n t h a t a r e n o t on s e l e c t e d configuration ( t h i s M o d u l e . getCompIds ( r e p o . a r c h S t r u c t u r e >a t ( 1 ) . component ) t h i s M o d u l e . getCompIds ( r e p o . a r c h S t r u c t u r e >a t ( 2 ) . component ) )> c o l l e c t ( e | r e p o . a r c h S t r u c t u r e >a t ( 1 ) . component>s e l e c t ( f | f . i d = e ) ) > f l a t t e n ( )> c o l l e c t ( c i | t h i s M o d u l e . pr ocessCurr entCompone ntPost ( c i ) ) > a s S e t ( ) , Components o f t h e s e l e c t e d c o n f i g u r a t i o n r e p o . a r c h S t r u c t u r e >a t ( 2 ) . component> c o l l e c t ( c | thisModule . processSelectedComponentPost ( c ) ) , C o n n e c t i o n s o f t h e c u r r e n t c o n f i g u r a t i o n t h a t a r e n o t on s e l e c t e d configuration thisModule . processLinkToDisconnection ( r e p o . a r c h S t r u c t u r e >a t ( 1 ) , r e p o . a r c h S t r u c t u r e >a t ( 2 ) ) , C o n n e c t i o n s o f t h e s e l e c t e d c o n f i g u r a t i o n r e p o . a r c h S t r u c t u r e >a t ( 2 ) . l i n k > c o l l e c t ( l i n k | thisModule . linkToConnected ( l i n k ) ) } ) } Return a s e t w i t h a l l components helper def : c o m p o n e n t C o l l e c t i o n ( ) : Collection ( t y p e s ! Component ) = A r c h i t e c t u r e M e t a m o d e l ! Component . a l l I n s t a n c e s ( )> c o l l e c t ( e | e . i d )>a s S e t ( )> c o l l e c t ( e | A r c h i t e c t u r e M e t a m o d e l ! Component . a l l I n s t a n c e s ( )> s e l e c t ( f | f . i d = e )> f i r s t ( ) ); Convert a component o b j e c t i n t o a PDDL o b j e c t lazy rule component2PddlObject { from s : A r c h i t e c t u r e M e t a m o d e l ! Component to p : PDDL! ProblemObject ( name < s . id , t y p e < t h i s M o d u l e . recoverComponentType ( ) ) } r e t u r n t h e PDDL o b j e c t a s s o c i a t e d w i t h component t y p e helper def : recoverComponentType ( ) : PDDL! Type = PDDL! Type . a l l I n s t a n c e s ( )> s e l e c t ( t a r g e t T y p e | t a r g e t T y p e . v a l u e = component )>a t ( 1 ) ; Return a s e t w i t h a l l r e q u i r e d i n t e r f a c e s helper def : r e q u i r e d I n t e r f a c e C o l l e c t i o n ( ) : Set ( t y p e s ! I n t e r f a c e ) =
196
100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163
ArchitectureMetamodel ! I n t e r f a c e . a l l I n s t a n c e s ( ) > s e l e c t ( i n t f | i n t f . d i r e c t i o n . v a l u e = #out )>a s S e t ( ) ; Return a s e t w i t h t h e names o f a l l r e q u i r e d i n t e r f a c e s We don t c o n s i d e r t h e component name i n t h i s method helper def : r e q u i r e d I n t e r f a c e N a m e s C o l l e c t i o n ( ) : Set ( String ) = t h i s M o d u l e . r e q u i r e d I n t e r f a c e C o l l e c t i o n ( )> c o l l e c t ( e | e . i d . s p l i t ( )>a t ( 2 ) )>a s S e t ( ) ; C r e a t e a p d d l o b j e c t from t h e r e q u i r e d i n t e r f a c e name lazy rule r e q u i r e d I n t e r f a c e N a m e 2 P d d l O b j e c t { from s : String to p : PDDL! ProblemObject ( name < s , t y p e < t h i s M o d u l e . r e c o v e r R e q u i r e d I n t e r f a c e T y p e ( ) ) } Return t h e PDDL t y p e a s s o c i a t e d w i t h r e q u i r e d i n t e r f a c e s helper def : r e c o v e r R e q u i r e d I n t e r f a c e T y p e ( ) : PDDL! Type = PDDL! Type . a l l I n s t a n c e s ( )> s e l e c t ( t a r g e t T y p e | t a r g e t T y p e . v a l u e = r e q u i r e d I n t e r f a c e )>a t ( 1 ) ; Return a s e t w i t h a l l p r o v i d e d i n t e r f a c e s helper def : p r o v i d e d I n t e r f a c e C o l l e c t i o n ( ) : Set ( t y p e s ! I n t e r f a c e ) = ArchitectureMetamodel ! I n t e r f a c e . a l l I n s t a n c e s ( ) > s e l e c t ( i n t f | i n t f . d i r e c t i o n . v a l u e <> #out )>a s S e t ( ) ; Return a s e t w i t h t h e names o f a l l p r o v i d e d i n t e r f a c e s helper def : p r o v i d e d I n t e r f a c e N a m e s C o l l e c t i o n ( ) : Set ( String ) = t h i s M o d u l e . p r o v i d e d I n t e r f a c e C o l l e c t i o n ( )> c o l l e c t ( e | e . i d . s p l i t ( )>a t ( 2 ) )>a s S e t ( ) ; C r e a t e a p d d l problem o b j e c t from a p r o v i d e d i n t e r f a c e name lazy rule p r o v i d e d I n t e r f a c e N a m e 2 P d d l O b j e c t { from s : String to p : PDDL! ProblemObject ( name < s , t y p e < t h i s M o d u l e . r e c o v e r P r o v i d e d I n t e r f a c e T y p e ( ) ) } Return t h e PDDL t y p e a s s o c i a t e d w i t h p r o v i d e d i n t e r f a c e s helper def : r e c o v e r P r o v i d e d I n t e r f a c e T y p e ( ) : PDDL! Type = PDDL! Type . a l l I n s t a n c e s ( )> s e l e c t ( t a r g e t T y p e | t a r g e t T y p e . v a l u e = p r o v i d e d I n t e r f a c e )>a t ( 1 ) ; P r o c e s s a component o f t h e c u r r e n t c o n f i g u r a t i o n f o r t h e w o r k f l o w pre condition . helper def : processCurrentComponentPre ( c : A r c h i t e c t u r e M e t a m o d e l ! Component ) : Set ( String ) = Set { thisModule . running ( c ) , thisModule . r e g i s t e r e d ( c ) , c . i n t e r f a c e >c o l l e c t ( i n t f | i f i n t f . d i r e c t i o n . v a l u e = #out then t h i s M o d u l e . r e q u i r e s ( i n t f ) else thisModule . provides ( i n t f ) endif )>a s S e t ( ) }> f l a t t e n ( ) ; P r o c e s s a component removed from t h e c u r r e n t c o n f i g u r a t i o n f o r t h e p o s t condition helper def : proces sCurrentC omponentP ost ( c : A r c h i t e c t u r e M e t a m o d e l ! Component ) : Set ( String ) = Set { ( not +t h i s M o d u l e . r e g i s t e r e d ( c )+ ) ,
197
164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219
thisModule . q u i e s c e n t ( c ) , ( not +t h i s M o d u l e . b l o c k e d ( c )+ ) }; P r o c e s s a component added by t h e s e l e c t e d c o n f i g u r a t i o n f o r t h e prec o n d i t i o n helper def : p r o c e s s S e l e c t e d C o m p o n e n t P r e ( c : A r c h i t e c t u r e M e t a m o d e l ! Component ) : Set ( String ) = Set { thisModule . q u i e s c e n t ( c ) , c . i n t e r f a c e >c o l l e c t ( i n t f | i f i n t f . d i r e c t i o n . v a l u e = #out then t h i s M o d u l e . r e q u i r e s ( i n t f ) else thisModule . provides ( i n t f ) endif )>a s S e t ( ) }> f l a t t e n ( ) ; P r o c e s s a component o f t h e s e l e c t e d c o n f i g f o r t h e w o r k f l o w p o s t c o n d i t i o n helper def : p r o c e s s S e l e c t e d C o m p o n e n t P o s t ( c : A r c h i t e c t u r e M e t a m o d e l ! Component ) : Set ( String ) = Set { thisModule . r e g i s t e r e d ( c ) , thisModule . running ( c ) , ( not +t h i s M o d u l e . b l o c k e d ( c )+ ) }; r e t u r n a s e t w i t h t h e i d s o f a l l components o f t h e r e c e i v e d s e t helper def : getCompIds ( i n p u t : Set ( A r c h i t e c t u r e M e t a m o d e l ! Component ) ) : Set ( String ) = i n p u t >c o l l e c t ( e | e . i d )>a s S e t ( ) ; S t a t e t h e r e c e i v e d l i n k as c o n n e c t e d helper def : l i n k T o C o n n e c t e d ( l : a r c h i t e c e t u r e M e t a m o d e l ! Link ) : String = l e t p o i n t 1 : i n s t a n c e ! P o i n t = l . p o i n t >a t ( 1 ) in l e t p o i n t 2 : i n s t a n c e ! P o i n t = l . p o i n t >a t ( 2 ) in ( c o n n e c t e d +p o i n t 1 . a n c h o r O n I n t e r f a c e . i d . s p l i t ( )>a t ( 1 ) + + p o i n t 1 . a n c h o r O n I n t e r f a c e . i d . s p l i t ( )>a t ( 2 ) + + p o i n t 2 . a n c h o r O n I n t e r f a c e . i d . s p l i t ( )>a t ( 1 ) + + p o i n t 2 . a n c h o r O n I n t e r f a c e . i d . s p l i t ( )>a t ( 2 ) + ) ; S t a t e t h e l i n k o f t h e c u r r e n t c o n f i g u r a t i o n as c o n n e c t e d helper def : l i n k T o C o n n e c t e d A t I n i t ( l : a r c h i t e c e t u r e M e t a m o d e l ! Link ) : Sequence ( String ) = l e t p o i n t 1 : i n s t a n c e ! P o i n t = l . p o i n t >a t ( 1 ) in l e t p o i n t 2 : i n s t a n c e ! P o i n t = l . p o i n t >a t ( 2 ) in Sequence{ t h i s M o d u l e . l i n k T o C o n n e c t e d ( l ) , ( bound +p o i n t 1 . a n c h o r O n I n t e r f a c e . i d . s p l i t ( )>a t ( 1 )+ +p o i n t 1 . a n c h o r O n I n t e r f a c e . i d . s p l i t ( )>a t ( 2 )+ ) }; Checks w h e t h e r two l i n k s a r e t h e same helper def : e q u a l L i n k s ( l i n k 1 : t y p e s ! A r c h S t r u c t u r e , l i n k 2 : t y p e s ! A r c h S t r u c t u r e ) : Boolean = i f l i n k 1 . p o i n t >a t ( 1 ) . a n c h o r O n I n t e r f a c e . i d = l i n k 2 . p o i n t >a t ( 1 ) . a n c h o r O n I n t e r f a c e . i d and l i n k 1 . p o i n t >a t ( 2 ) . a n c h o r O n I n t e r f a c e . i d = l i n k 2 . p o i n t >a t ( 2 ) . anchorOnInterface . id then t r u e else f a l s e endif ; s t a t e t h e l i n k s o f t h e c u r r e n t c o n f i g u r a t i o n t h a t a r e n o t p a r t o f t h e selected configuration as n o t c o n n e c t e d helper def : p r o c e s s L i n k T o D i s c o n n e c t i o n ( s o u r c e M o d e l : t y p e s ! A r c h S t r u c t u r e , targetModel : types ! ArchStructure ) : Sequence ( String ) = s o u r c e M o d e l . l i n k >
198
220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239
s e l e c t ( l i | not t a r g e t M o d e l . l i n k >e x i s t s ( l i 2 | t h i s M o d u l e . e q u a l L i n k s ( l i , )) > c o l l e c t ( l i n k | ( not +t h i s M o d u l e . l i n k T o C o n n e c t e d ( l i n k )+ ) ); helper def : p r o v i d e s ( i : A r c h i t e c t u r e M e t a m o d e l ! I n t e r f a c e ) : String = ( p r o v i d e s +i . i d . s p l i t ( )>a t ( 1 )+ +i . i d . s p l i t ( )>a t ( 2 )+ ) ; helper def : r e q u i r e s ( i : A r c h i t e c t u r e M e t a m o d e l ! I n t e r f a c e ) : String = ( r e q u i r e s +i . i d . s p l i t ( )>a t ( 1 )+ +i . i d . s p l i t ( )>a t ( 2 )+ ) ; helper def : q u i e s c e n t ( c : t y p e s ! Component ) : String = ( q u i e s c e n t +c . i d+ ) ; helper def : r u n n i n g ( c : A r c h i t e c t u r e M e t a m o d e l ! Component ) : String = ( r u n n i n g +c . i d+ ) ; helper def : r e g i s t e r e d ( c : A r c h i t e c t u r e M e t a m o d e l ! Component ) : String = ( r e g i s t e r e d +c . i d+ ) ; helper def : b l o c k e d ( c : A r c h i t e c t u r e M e t a m o d e l ! Component ) : String = ( b l o c k e d +c . i d+ ) ;
li2 )
Listing B.1: Transformation rules for translating architectural models into planning problem model.
Appendix C Domain Specic Transformation Rules for Testing

This appendix contains the full description of the domain specic transformation rules for the domain of component-based integration testing.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 @nsURI @nsURI @nsURI @nsURI PDDL=h t t p : / / p d d l i n t e g r a t i o n M e t a m o d e l=h t t p : / / a r c h i t e c t u r e . x a d l / i n s t a n c e=h t t p : / /www. i c s . u c i . edu / pub / a r c h / xArch / i n s t a n c e . x s d t y p e s=h t t p : / /www. i c s . u c i . edu / pub / a r c h / xArch / t y p e s . x s d
module I n t e g r a t i o n T e s t i n g ; create OUT : PDDL from IN : i n t e g r a t i o n M e t a m o d e l , IN2 : PDDL; rule DomainReferences { from d : PDDL! DomainModel , r e p o : i n t e g r a t i o n M e t a m o d e l ! R e p o s i t o r y to t : PDDL! ProblemModel ( problem c o l l e c t ( e | t h i s M o d u l e . component2PddlObject ( e ) ) }, i n i t < Sequence{ thisModule . i n i t i a l i s e C o u n t e r s ( ) , t h i s M o d u l e . i n t e g r a t i o n O r d e r i n g ( r e p o . a r c h S t r u c t u r e > f i r s t ( ) ) }, g o a l < Sequence{ t h i s M o d u l e . componentsAsTested ( r e p o . a r c h S t r u c t u r e > f i r s t ( ) ) } ) } Return a s e t w i t h a l l components helper def : c o m p o n e n t C o l l e c t i o n ( ) : Collection ( t y p e s ! Component ) = i n t e g r a t i o n M e t a m o d e l ! Component . a l l I n s t a n c e s ( )> c o l l e c t ( e | e . i d )>a s S e t ( )> c o l l e c t ( e | i n t e g r a t i o n M e t a m o d e l ! Component . a l l I n s t a n c e s ( )> s e l e c t ( f | f . i d = e )> f i r s t ( ) ); Convert a component o b j e c t i n t o a PDDL o b j e c t
199
APPENDIX C. TESTING TRANSFORMATION RULES
200
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 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93
lazy rule component2PddlObject { from s : i n t e g r a t i o n M e t a m o d e l ! Component to p : PDDL! ProblemObject ( name < s . id , t y p e < t h i s M o d u l e . recoverComponentType ( ) ) } r e t u r n t h e PDDL o b j e c t a s s o c i a t e d w i t h component t y p e helper def : recoverComponentType ( ) : PDDL! Type = PDDL! Type . a l l I n s t a n c e s ( )> s e l e c t ( t a r g e t T y p e | t a r g e t T y p e . v a l u e = component )> at (1) ; Return a s e t w i t h a l l r e q u i r e d i n t e r f a c e s helper def : r e q u i r e d I n t e r f a c e C o l l e c t i o n ( ) : Set ( t y p e s ! I n t e r f a c e ) = integrationMetamodel ! I n t e r f a c e . a l l I n s t a n c e s () > s e l e c t ( i n t f | i n t f . d i r e c t i o n . v a l u e = #out )>a s S e t ( ) ; r e t u r n a s e t w i t h t h e i d s o f a l l r e q u i r e d i n t e r f a c e s helper def : r e q u i r e d I n t e r f a c e I d C o l l e c t i o n ( ) : Set ( String ) = t h i s M o d u l e . r e q u i r e d I n t e r f a c e C o l l e c t i o n ( )> c o l l e c t ( e | e . i d . s p l i t ( )>a t ( 2 ) )>a s S e t ( ) ; Return a s e t w i t h a l l p r o v i d e d i n t e r f a c e s helper def : p r o v i d e d I n t e r f a c e C o l l e c t i o n ( ) : Set ( t y p e s ! I n t e r f a c e ) = integrationMetamodel ! I n t e r f a c e . a l l I n s t a n c e s () > s e l e c t ( i n t f | i n t f . d i r e c t i o n . v a l u e <> #out )>a s S e t ( ) ; r e t u r n a s e t w i t h t h e i d s o f a l l p r o v i d e d i n t e r f a c e s helper def : p r o v i d e d I n t e r f a c e I d C o l l e c t i o n ( ) : Set ( String ) = t h i s M o d u l e . p r o v i d e d I n t e r f a c e C o l l e c t i o n ( )> c o l l e c t ( e | e . i d . s p l i t ( )>a t ( 2 ) )>a s S e t ( ) ; r e t u r n a s e t w i t h t h e t y p e s ( d e s c r i p t i o n ) o f a l l i n t e r f a c e s helper def : i n t e r f a c e T y p e s C o l l e c t i o n ( ) : Set ( String ) = i n t e g r a t i o n M e t a m o d e l ! I n t e r f a c e . a l l I n s t a n c e s ( )> c o l l e c t ( e | e . d e s c r i p t i o n . v a l u e )>a s S e t ( ) ; helper def : i n i t i a l i s e C o u n t e r s ( ) : String = (= ( i n t e g r a t i o n s t e p ) 1 ) (= ( t e s t i n g s t e p ) 1 ) ; helper def : i n t e g r a t i o n O r d e r i n g ( c o n f i g u r a t i o n : i n t e g r a t i o n M e t a m o d e l ! MyArchStructure ) : Set ( String ) = c o n f i g u r a t i o n . i n t e g r a t i o n O r d e r i n g . component> c o l l e c t ( item | (= ( i n t e g r a t i o n o r d e r +item . i d+ ) +c o n f i g u r a t i o n . i n t e g r a t i o n O r d e r i n g . component>i n d e x O f ( item )+ ) )>a s S e t ( ) ; helper def : componentsAsTested ( c o n f i g u r a t i o n : i n t e g r a t i o n M e t a m o d e l ! MyArchStructure ) : Set ( String ) = c o n f i g u r a t i o n . i n t e g r a t i o n O r d e r i n g . component>c o l l e c t ( item | ( t e s t e d +item . i d+ ) )>a s S e t ( ) ; helper def : r e c o v e r R e q u i r e d I n t e r f a c e T y p e ( ) : PDDL! Type = PDDL! Type . a l l I n s t a n c e s ( )> s e l e c t ( t a r g e t T y p e | t a r g e t T y p e . v a l u e = r e q u i r e d I n t e r f a c e )>a t ( 1 ) ; helper def : r e c o v e r P r o v i d e d I n t e r f a c e T y p e ( ) : PDDL! Type = PDDL! Type . a l l I n s t a n c e s ( )> s e l e c t ( t a r g e t T y p e | t a r g e t T y p e . v a l u e = p r o v i d e d I n t e r f a c e )>a t ( 1 ) ; helper def : r e c o v e r I n t e r f a c e T y p e ( ) : PDDL! Type = PDDL! Type . a l l I n s t a n c e s ( )> s e l e c t ( t a r g e t T y p e | t a r g e t T y p e . v a l u e = i n t e r f a c e T y p e )>a t ( 1 ) ; lazy rule r e q u i r e d I n t e r f a c e 2 P d d l O b j e c t {
APPENDIX C. TESTING TRANSFORMATION RULES
201
94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141
from s to p : name type ) }
: String PDDL! ProblemObject ( < s , < t h i s M o d u l e . r e c o v e r R e q u i r e d I n t e r f a c e T y p e ( )
lazy rule p r o v i d e d I n t e r f a c e 2 P d d l O b j e c t { from s : String to p : PDDL! ProblemObject ( name < s , t y p e < t h i s M o d u l e . r e c o v e r P r o v i d e d I n t e r f a c e T y p e ( ) ) } lazy rule i n t e r f a c e T y p e 2 P d d l O b j e c t { from s : String to p : PDDL! ProblemObject ( name < s , t y p e < t h i s M o d u l e . r e c o v e r I n t e r f a c e T y p e ( ) ) } helper def : setComponentReady ( c o n f i g u r a t i o n : i n t e g r a t i o n M e t a m o d e l ! MyArchStructure ) : String = c o n f i g u r a t i o n . component>s e l e c t ( comp | t h i s M o d u l e . isComponentReady ( comp ) )> c o l l e c t ( e | ( r e a d y + e . i d + ) ) ; helper def : isComponentReady ( c : i n t e g r a t i o n M e t a m o d e l ! Component ) : Boolean = c . i n t e r f a c e >s e l e c t ( i n t f | i n t f . d i r e c t i o n . v a l u e = #out ) . isEmpty ( ) ; helper def : r e q u i r e s ( i : t y p e s ! I n t e r f a c e ) : String = ( r e q u i r e s +i . i d . s p l i t ( )>a t ( 1 )+ +i . i d . s p l i t ( )>a t ( 2 )+ ) ; helper def : r e q t y p e ( i : t y p e s ! I n t e r f a c e ) : String = ( r e q t y p e +i . i d . s p l i t ( )>a t ( 2 )+ +i . d e s c r i p t i o n . v a l u e+ ) ; helper def : p r o v i d e s ( i : t y p e s ! I n t e r f a c e ) : String = ( p r o v i d e s +i . i d . s p l i t ( )>a t ( 1 )+ +i . i d . s p l i t ( )>a t ( 2 )+ ) ; helper def : p r o v t y p e ( i : t y p e s ! I n t e r f a c e ) : String = ( p r o v t y p e +i . i d . s p l i t ( )>a t ( 2 )+ +i . d e s c r i p t i o n . v a l u e+ ) ; helper def : r e c o v e r I n t e r f a c e T y p e s ( i : t y p e s ! I n t e r f a c e ) : String = i f i . d i r e c t i o n . v a l u e = #out then ( r e q t y p e +i . i d . s p l i t ( )>a t ( 2 )+ +i . d e s c r i p t i o n . v a l u e+ ) else ( p r o v t y p e +i . i d . s p l i t ( )>a t ( 2 )+ +i . d e s c r i p t i o n . v a l u e+ ) endif ;
Listing C.1: Transformation rules for translating architectural models into planning problem models in the domain of integration testing.
Bibliography
[1] Michael Adams, Arthur H. M. ter Hofstede, David Edmond, and Wil M. P. van der Aalst. Worklets: A Service-Oriented Implementation of Dynamic Flexibility in Workows. In 14th International Conference on Cooperative Information Systems (CoopIS06), volume 4275 of Lecture Notes in Computer Science, pages 291308, 2006. [2] Michael Adams, Arthur H. M. ter Hofstede, and Wil M. P. van der Aalst. Dynamic, Extensible and Context-aware Exception Handling for Workows. In 15th International Conference on Cooperative Information Systems (CoopIS07), volume 4803 of Lecture Notes in Computer Science, pages 95 112, 2007. [3] Aditya Agarwal, Gabor Karsai, and Feng Shi. Interpreter Writing Using Graph Transformations. Technical Report ISIS-03-401, Institute for Software Integrated Systems, Vanderbilt University, 2003. [4] Vikas Agarwal, Koustuv Dasgupta, Neeran Karnik, Arun Kumar, Ashish Kundu, Sumit Mittal, and Biplav Srivastava. A service creation environment based on end to end composition of Web services. In 14th International Conference on World Wide Web (WWW05), pages 128137, 2005. [5] Brent Agnew, Christine Hofmeister, and James Purtilo. Planning for change: a reconguration language for distributed systems. Distributed Systems Engineering, 1(5):313322, 1994. [6] Atif Alamri, Mohamad Eid, and Abdulmotaleb El Saddik. Classication of the state-of-the-art dynamic web services composition techniques. International Journal of Web and Grid Services, 2(2):148166, 2006. [7] Mourad Alia, Geir Horn, Frank Eliassen, Mohammad Ullah Khan, Rolf Fricke, and Roland Reichle. A Component-Based Planning Framework for Adaptive Systems. In On the Move to Meaningful Internet Systems: CoopIS, DOA, GADA and ODBASE, OTM Confederated International Conferences06, volume 4276 of Lecture Notes in Computer Science, pages 16861704, 2006. [8] Jos Luis Ambite and Dipsy Kapoor. Automatic generation of data proe cessing workows for transportation modeling. In 8th annual international 202
BIBLIOGRAPHY
203
conference on Digital government research: bridging disciplines & domains, pages 8291, 2007. [9] Jesper Andersson, Rogrio de Lemos, Sam Malek, and Danny Weyns. Mode eling Dimensions of Self-Adaptive Software Systems. In Software Engineering for Self-Adaptive Systems, volume 5525 of Lecture Notes in Computer Science, pages 2747. 2009. [10] Artur Andrzejak, Ulf Hermann, and Akhil Sahai. FEEDBACKFLOW An Adaptive Workow Generator for Systems Management. In 2nd International Conference on Automatic Computing (ICAC05), pages 335336, 2005. [11] Naveed Arshad, Dennis Heimbigner, and Alexander L. Wolf. Deployment and dynamic reconguration planning for distributed software systems. Software Quality Journal, 15(3):265281, 2007. [12] Marco Autili, Paolo Di Benedetto, and Paola Inverardi. Context-aware adaptive services: the PLASTIC approach. In International Conference: Fundamental Approaches to Software Engineering (FASE), member conference of the European Joint Conferences on Theory and Practice of Software (ETAPS), volume 5503 of Lecture Notes in Computer Science, pages 124 139, 2009. [13] Marco Autili, Paolo Di Benedetto, Paola Inverardi, and Damien A. Tamburri. Towards Self-evolving Context-aware Services. In 3rd Federated Conference on Distributed Computing Techniques 2008 (DisCoTec08), Contextaware Adaptation Mechanisms for Pervasive and Ubiquitous Services (CAMPUS08), 2008. [14] Algirdas Avizienis, Jean-Clause Laprie, Brian Randell, and Carl Landwehr. Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE Transactions on Dependable and Secure Computing, 1(1):1133, 2004. [15] Luciano Baresi and Carlo Guezzi. The disappearing boundary between development-time and run-time. In FSE/SDP workshop on Future of software engineering research (FOSER10), pages 1722, 2010. [16] Luciano Baresi and Sam Guinea. A dynamic and reactive approach to the supervision of BPEL processes. In 1st India software engineering conference (ISEC08), pages 3948, 2008. [17] Luciano Baresi and Sam Guinea. Self-supervising BPEL Processes. IEEE Transaction on Software Engineering, 37(2):247263, 2010. [18] Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley, 2nd edition edition, 2003.
BIBLIOGRAPHY
204
[19] Thais Batista and Noemi Rodriguez. Dynamic Reconguration of Component-based Applications. In International Simposium on Software Engineering for Parallel and Distributed Systems (PDS 00), pages 3239, 2000. [20] Nelly Bencomo, Gordon S. Blair, Carlos A. Flores-Corts, and Peter Sawe yer. Reective Component-based Technologies to Support Dynamic Variability. In 2nd International Workshop on Variability Modelling of SoftwareIntensive Systems (VAMOS08), pages 141150, 2008. [21] Antonia Bertolino. Software testing research and practice. In Abstract State Machines, 10th International Workshop on Advances in Theory and Practice (ASM03), volume 2589 of Lecture Notes in Computer Science, pages 121, 2003. [22] Antonia Bertolino. Software Testing Research: Achievements, Challenges, Dreams. In ICSE 2007 Future of Software Engineering (FOSE07), 2007. [23] Antonia Bertolino and Andrea Polini. A framework for component deployment testing. In the 25th International Conference on Software Engineering (ICSE03), pages 221231, 2003. [24] Jean Bzivin. In search of a Basic Principle for Model Driven Engineering. e Novatica/Upgrade, V(2):2124, 2004. [25] Jean Bzivin. Model Driven Engineering: An Emerging Technical Space. e In International Summer School on Generative and Transformational Techniques in Software Engineering (GTTSE05). Revised Papers, volume 4143 of Lecture Notes in Computer Science, pages 3664, 2006. [26] Jean Bzivin, Frdric Jouault, Peter Rosenthal, and Patrick Valduriez. e e e Modeling in the Large and Modeling in the Small. In the European MDA Workshops: Foundations and Applications, MDAFA 2003 and MDAFA 2004, volume 3599 of Lecture Notes in Computer Science, pages 3346, 2005. [27] Jean Bzivin and Ivan Kurtev. Model-based Technology Integration with e the Technical Space Concept. In Metainformatics Symposium 2005, 2005. [28] Gordon Blair, Nelly Bencomo, and Robert B. France. Models@ run.time. IEEE Computer, 42(10):2227, oct. 2009. [29] Jeremy S. Bradbury, James R. Cordy, Juergen Dingel, and Michel Wermelinger. A survey of self-management in dynamic software architecture specications. In 1st ACM SIGSOFT workshop on Self-managed systems (WOSS 04), pages 2833, 2004. [30] Daniel Brenner, Colin Atkinson, Rainer Malaka, Matthias Merdes, Barbara Paech, and Dima Suliman. Reducing verication eort in component-based
BIBLIOGRAPHY
205
software engineering through built-in testing. Information Systems Frontiers, 9(2-3):151162, July 2007. [31] Lionel C. Briand, Yvan Labiche, and Michal M. Swka. Automated, o contract-based user testing of commercial-o-the-shelf componens. In 28th International Conference of Software Engineering (ICSE06), pages 92101, 2006. [32] Yuriy Brun, Giovanna Marzo Serugendo, Cristina Gacek, Holger Giese, Holger Kienle, Marin Litoiu, Hausi Mller, Mauro Pezz`, and Mary Shaw. u e Engineering Self-Adaptive Systems through Feedback Loops. In Software Engineering for Self-Adaptive Systems, volume 5525 of Lecture Notes in Computer Science, pages 4870. 2009. [33] Eric Bruneton, Thierry Coupaye, Matthieu Leclercq, Vivien Quma, and e Jean-Bernard Stefani. The FRACTAL component model and its support in Java: Experiences with Auto-adaptive and Recongurable Systems. Software Practice and Experience, 36(11-12):12571284, 2006. [34] Junwei Cao, Stephen A. Jarvis, Subhash Saini, and Graham R. Nudd. GridFlow: workow management for grid computing. In 3rd IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid03), pages 198 205, 2003. [35] Alfredo Capozucca, Nicolas Guel, Patrizio Pelliccione, Alexander Romanovsky, and Avelino F. Zorzo. CAA-DRIP: a framework for implementing Coordinated Atomic Actions. In 17th International Symposium on Software Reliability Engineering (ISSRE 06), pages 385394, 2006. [36] Fabio Casati and Gianpaolo Cugola. Error handling in process support systems. In Advances in Exception Handling Techniques, volume 2022 of Lecture Notes in Computes Science, pages 251270. 2001. [37] Fabio Casati, Ski Ilnicki, Li jie Jin, Vasudev Krishnamoorthy, and MingChien Shan. Adaptive and Dynamic Service Composition in eFlow. In 12th International Conference on Advanced Information Systems Engineering (CAISE00), volume 1789 of Lecture Notes in Computer Science, pages 1331, 2000. [38] K. S. May Chan, Judith Bishop, Johan Steyn, Luciano Baresi, and Sam Guinea. A Fault Taxonomy for Web Service Composition. In 3rd ICSOC 2007 International Workshop on Engineering Service-Oriented Applications: Analysis, Design, and Composition (WESOA07), ICSOC 2007 International Workshops, volume 4907 of Lecture Notes in Computer Science, pages 363375, 2009. [39] Betty H. Cheng, Rogrio de Lemos, Holger Giese, Paola Inverardi, Je e Magee, Jesper Andersson, Basil Becker, Nelly Bencomo, Yuriy Brun, Bojan
BIBLIOGRAPHY
206
Cukic, Giovanna Di Marzo Serugendo, Schahram Dustdar, Anthony Finkelstein, Cristina Gacek, Kurt Geihs, Vincenzo Grassi, Gabor Karsai, Holger M. Kienle, Je Kramer, Marin Litoiu, Sam Malek, Raaela Mirandola, Hausi A. Mller, Sooyong Park, Mary Shaw, Matthias Tichy, Massimo u Tivoli, Danny Weyns, and Jon Whittle. Software Engineering for SelfAdaptive Systems: A Research Roadmap. In Software Engineering for Self-Adaptive Systems, volume 5525 of Lecture Notes in Computer Science, chapter 1, pages 126. 2009. [40] Shang-Wen Cheng, David Garlan, and Bradley Schmerl. Architecture-based Self-Adaptation in the Presence of Multiple Objectives. In ICSE 2006 Workshop on Software Engineering for Adaptive and Self-Managing Systems (SEAMS 06), pages 28, 2006. [41] Soon Ae Chun, Vijayalakshmi Atluri, and Nabil R. Adam. Domain Knowledge-Based Automatic Workow Generation. In 13th International Conference on Database and Expert Systems Applications (DEXA02), volume 2453 of Lecture Notes in Computer Science, pages 8192, 2002. [42] Alessandro Cimatti, Marco Pistore, Marco Roveri, and Paolo Traverso. Weak, strong, and strong cyclic planning via symbolic model checking. Articial Intelligence, 147(1-2):3584, 2003. [43] Geo Coulson, Gordon Blair, Paul Grace, Francois Taiani, Ackbar Joolia, Kevin Lee, Jo Ueyama, and Thirunavukkarasu Sivaharan. A generic component model for building systems software. ACM Transactions on Computer Systems (TOCS), 26(1):142, 2008. [44] Carlos Eduardo da Silva and Rogrio de Lemos. Using Dynamic Worke ows for Coordinating Self-adaptation of Software systems. In ICSE 2009 Workshop on Software Engineering for Adaptive and Self-Managing Systems (SEAMS 09), pages 8695, 2009. [45] Nicodemos Damianou, Naranker Dulay, Emil Lupu, and Morris Sloman. The Ponder Policy Specication Language. In International Workshop on Policies for Distributed Systems and Networks (POLICY 01), pages 1838, 2001. [46] Eric M. Dashofy, Andr van der Hoek, and Richard N. Taylor. Towards e Architecture-based Self-healing Systems. In 1st Workshop on Self-healing Systems (WOSS02), pages 2126, 2002. [47] Eric M. Dashofy, Andr van der Hoek, and Richard N. Taylor. A Compree hensive Approach for the Development of Modular Software Architecture Description Languages. ACM Transactions on Software Engineering Methodology (TOSEM), 14(2):199245, 2005.
BIBLIOGRAPHY
207
[48] Pierre-Charles David, Thomas Ledoux, Marc Lger, and Thierry Coupaye. FPath and FScript: Language support for navigation and reliable reconguration of Fractal architectures. Annals of Telecommunications, 64:4563, 2009. [49] Rogrio de Lemos. Architectural Reconguration Using Coordinated Atomic e Actions. In ICSE 2006 Workshop on Software Engineering for Adaptive and Self-Managing Systems (SEAMS 06), pages 4450, 2006. [50] Ewa Deelman, Jamer Blythe, Yolanda Gil, Carl Kesselman, Gaurang Mehta, Karan Vahi, Kent Blackburn, Albert Lazzarini, Adam Arbree, Richard Cavanaugh, and Scott Koranda. Mapping Abstract Complex Workows onto Grid Environments. Journal of Grid Computing, 1(1):2539, 2003. [51] Simon Dobson, Spyros Denazis, Antonio Fernndez, Dominique Ga Erol a ti, Gelenbe, Fabio Massacci, Paddy Nixon, Fabrice Sare, Nikita Schmidt, and Franco Zambonelli. A survey of autonomic communications. ACM Transactions on Autonomous and Adaptive Systems (TAAS), 1(2):223 259, 2006. [52] Schahram Dustdar and Wolfgang Schreiner. A survey on web services composition. International Journal of Web and Grid Services, 1(1):130, 2005. [53] Hartmut Ehrig and Claudia Ermel. Semantical Correctness and Completeness of Model Transformations Using Graph and Rule Transformation. In 4th international conference on Graph Transformations (ICGT08), pages 194210, 2008. [54] M. Endler and J. Wei. Programming generic dynamic recongurations for distributed applications. In Workshop on Congurable Distributed Systems, pages 6879, 1992. [55] Tara A. Estlin, Daniel M. Gaines, Caroline Chouinard, Rebecca Castao, n Benjamin Bornstein, Michele Judd, Issa A. D. Nesnas, and Robert C. Anderson. Increased Mars Rover Autonomy using AI Planning, Scheduling and Execution. In IEEE International Conference on Robotics and Automation (ICRA07), pages 49114918, 2007. [56] Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine, 2000. [57] Richard Fikes and Nils J. Nilsson. STRIPS: a new approach to the application of theorem proving to problem solving. Articial Intelligence, 2(3/4):189208, 1971. [58] Howard Foster, Sebastian Uchitel, Je Magee, and Je Kramer. WSEngineer: A Tool for Model-Based Verication of Web Service Compositions and Choreography. In 28th International Conference on Software Engineering (ICSE 2006), 2006.
BIBLIOGRAPHY
208
[59] Maria Fox and Derek Long. PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains. Journal of Artical Intelligence Research, 20:61124, 2003. [60] Gerhard Friedrich, Mariagrazia Fugini, Enrico Mussi, Barbara Pernici, and Gaston Tagni. Exception Handling for Repair in Service-Based Processes. IEEE Transactions on Software Engineering (TSE), 36(2):198215, 2010. [61] Barbara Gallina, Nicolas Guel, and Alexander Romanovsky. Coordinated Atomic Actions for Dependable Distributed Systems: the Current State in Concepts, Semantics and Verication Means. In 18th IEEE International Symposium on Software Reliability (ISSRE07), pages 2938, 2007. [62] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, 1995. [63] Alessandro F. Garcia, Cec M. F. Rubira, Alexander Romanovsky, and lia Jie Xu. A comparative study of exception handling mechanisms for building dependable object-oriented software. Journal of systems and Software, 59(2):197222, 2001. [64] David Garlan, Shang-Wen Cheng, An-Cheng Huang, Bradley Schmerl, and Peter Steenkiste. Rainbow: Architecture-Based Self-Adaptation with Reusable Infrastructure. IEEE Computer, 37(10):4654, 2004. [65] David Garlan and Bradley Schmerl. Model-based Adaptation for Selfhealing Systems. In 1st Workshop on Self-healing Systems (WOSS02), pages 2732, 2002. [66] David Garlan, Bradley Schmerl, and Shang-Wen Cheng. Software Architecture-Based Self-Adaptation. In Autonomic Computing and Networking, pages 3155. 2009. [67] Erann Gat. Three-layer architectures, pages 195210. MIT Press, 1998. [68] John C. Georgas and Richard N. Taylor. Towards a Knowledge-based Approach to Architectural Adaptation Management. In 1st ACM SIGSOFT Workshop on Self-managed Systems (WOSS04), pages 5963, 2004. [69] John C. Georgas and Richard N. Taylor. Policy-Based Self-Adaptive Architectures: A Feasibility Study in the Robotics Domain. In ICSE 2008 Workshop on Software Engineering for Adaptive and Self-managing Systems (SEAMS 08), pages 105112, 2008. [70] Alfonso Gerevini and Derek Long. Preferences and Soft Constraints in PDDL3. In ICAPS Workshop on Preferences and Soft Constratints in Planning, pages 4653, 2006.
BIBLIOGRAPHY
209
[71] Malik Ghallab, Dana Nau, and Paolo Traverso. Automated Planning Theory and Practice. Morgan Kaufmann, 2004. [72] John B. Goodenough. Exception handling: issues and a proposed notation. Commuications of ACM, 18(12):683696, December 1975. [73] Florian Gottschalk, Wil van der Aalst, and Monique Jansen-Vullers. Congurable Process Models: A Foundational Approach. In Reference Modeling: Ecient Information Systems Design Through Reuse of Information Models, pages 5978, 2007. [74] Florian Gottschalk, Wil M. P. van der Aalst, Monque H. Jansen-Vullers, and Marcello La Rosa. Congurable Workow Models. International Journal of Cooperative Information Systems (IJCIS), 17(2):177221, 2008. [75] Jim Gray and Andreas Reuter. Transactions Processing: Concepts and Technics. Morgan Kaufmann, 1993. [76] Ulrike Greiner and Erhard Rahm. Quality-Oriented Handling of Exceptions in Web-Service-Based Cooperative Processes. In GI-/GMDS Workshop on Enterprise Application Integration (EAI04), pages 1118, 2004. [77] Jonathan J. Halliday, Santosh K. Shrivastava, and Stuart M. Wheater. Flexible Workow Management in the OPENow System. In 5th IEEE International Conference on Enterprise Distributed Object Computing (EDOC 01), pages 8292, 2001. [78] Thomas Heinis, Cesare Pautasso, and Gustavo Alonso. Design and Evaluation of an Autonomic Workow Engine. In 2nd International Conference on Automatic Computing (ICAC 05), pages 2738, 2005. [79] Rattikorn Hewett and Phongphun Kijsanayothin. Automated Test Order Generation for Software Component Integration Testing. In IEEE/ACM International Conference on Automated Software Engineering (ASE 09), pages 211220, 2009. [80] Chih-Wei Hsu and Benjamin W. Wah. The SGPlan Planning System in IPC-6. In 6th International Planning Competition (IPC-2008), page 3 pp, 2008. [81] Markus C. Huebscher and Julie A. McCann. A survey of autonomic computing - degrees, models, and applications. ACM Computing Surveys (CSUR), 40:7:17:28, 2008. [82] IBM. An Architectural Blueprint for Autonomic Computing. White Paper, June 2006. 4th edition.
BIBLIOGRAPHY
210
[83] Paola Inverardi and Massimo Tivoli. The Future of Software: Adaptation and Dependability. In Software Engineering - International Summer Schools, ISSSE 2006-2008, Salerno, Italy, Revised Tutorial Lectures, volume 5413 of Lecture Notes in Computer Science, pages 131. 2009. [84] Ackbar Joolia, Thais Batista, Geo Coulson, and Antonio Tadeu A. Gomes. Mapping ADL Specications to an Ecient and Recongurable Runtime Component Platform. In 5th Working IEEE/IFIP Conference on Software Architecture (WICSA 05), pages 131140, 2005. [85] Frdric Jouault, Freddy Allilaire, Jean Bzivin, and Ivan Kurtev. ATL: A e e e model transformation tool. Science of Computer Programming, 72(1-2):31 39, 2008. [86] Frdric Jouault and Jean Bzivin. KM3: A DSL for Metamodel Specicae e e tion. In the 8th IFIP WG 6.1 International conference on Formal Methods for Open Object-based Distributed Systems (FMOODS06), volume 4037 of Lecture Notes in Computer Science, pages 171185, 2006. [87] Gail Kaiser, Janak Parekh, Philip Gross, and Giuseppe Valetto. Kinesthetics eXtreme: An External Infrastructure for Monitoring Distributed Legacy Systems. In 5th International Workshop on Active Middleware Service, pages 2230, 2003. [88] Peter J. Kammer, Gregory Alan Bolcer, Richard N. Taylor, Arthur S. Hitomi, and Mark Bergman. Techniques for Supporting Dynamic and Adaptive Workow. Computer Supported Cooperative Work, 9(3/4):269292, 2000. [89] Henry A. Kautz, Bart Selman, and Jrg. SatPlan: Planning as Satisability. o In Abstracts of the 5th International Planning Competition (IPC2006), 2006. [90] Jerey O. Kephart and David M. Chess. The Vision of Autonomic Computing. IEEE Computer, 36(1):4150, 2003. [91] Jerey O. Kephart and William E. Walsh. An Articial Intelligence Perspective on Autonomic Computing Policies. In 5th International Workshop on Policies for Distributed Systems and Networks (POLICY04), pages 3 12, 2004. [92] Dongsun Kim and Sooyong Park. Designing Dynamic Software Architecture for Home Service Robot Software. In the International Conference on Embedded and Ubiquitous Computing (EUC06), volume 4096 of Lecture Notes in Computer Science, pages 437448, 2006. [93] Dongsun Kim, Sooyong Park, Youngkyun Jin, Hyeongsoo Chang, Yu-Sik Park, In-Young Ko, Kwanwoo Lee, Junhee Lee, Yeon-Chool Park, and Skhan Lee. SHAGE: A Framework for Self-managed Robot Software.
BIBLIOGRAPHY
211
In ICSE 2006 Workshop on Software Engineering for Adaptive and SelfManaging Systems (SEAMS 06), pages 7985, 2006. [94] Je Kramer and Je Magee. The Evolving Philosophers Problem: Dynamic Change Management. IEEE Transaction on Software Engineering (TSE), 16(11):12931306, 1990. [95] Je Kramer and Je Magee. Self-Managed Systems: an Architectural Challenge. In Future of Software Engineering 2007 (FOSE07), pages 259268, 2007. [96] Ivan Kurtev, Jean Bzivin, and Mehmet Aksit. Technological Spaces: An e Initial Appraisal. In International Conference on Cooperative Information Systems (CoopIS) DOA 2002 Federated Conferences (DOA02), Industrial track, pages 16, 2002. [97] Kevin Lee, Norman W. Paton, Rizos Sakellariou, Ewa Deelman, Alvaro A. A. Fernandes, and Gaurang Mehta. Adaptive Workow Processing and Execution in Pegasus. In 3rd International Conference on Grid and Pervasive Computing - Workshops (GPC-WORKSHOPS 08), pages 99106, 2008. [98] Barbara Staudt Lerner, Stefan Christov, Leon J. Osterweil, Reda Bendraou, Udo Kannengiesser, and Alexander Wise. Exception Handling Patterns for Process Modeling. IEEE Transactions on Software Engineering, 36(2):162 183, 2010. [99] Nazia Leyla, Ahmed Shah Mashiyat, Hao Wang, and Wendy MacCaull. Towards workow verication. In Conference of the Center for Advanced Studies on Collaborative Research (CASCON10), pages 253267, 2010. [100] Shiyong Lu, Arthur Bernstein, and Philip Lewis. Automatic Workow Verication and Generation. Theoretical Computer Science, 353(1):7192, 2006. [101] Patrcia D. L. Machado, Jorge C. A. Figueiredo, Emerson F. A. Lima, Ana E. V. Barbosa, and Helton S. Lima. Component-based integration testing from UML interaction diagrams. In IEEE International Conference on Systems, Man and Cybernetics (ICSMC07), pages 26792686, 2007. [102] Drew McDermott. Estimate-Regression Planning for Interactions with Web Services. In the AI Planning Systems Conference (AIPS02), pages 204211, 2002. [103] Philip K. McKinley, Seyed Masoud Sadjadi, Eric P. Kasten, and Betty H. C. Cheng. Composing adaptive software. IEEE Computer, 37(7):5664, 2004. [104] Joo Meidanis, Gottfried Vossen, and Mathias Weske. Using Workow Mana agement in DNA Sequencing. In the First IFCIS International Conference on Cooperative Information Systems (COOPIS 96), pages 114123, 1996.
BIBLIOGRAPHY
212
[105] Gerard Meszaros. XUnit Test Patterns: Refactoring Test Code. AddisonWesley, 2007. [106] Andreas Metzger, Osama Sammodi, Klaus Pohl, and Mark Rzepka. Towards pro-active adaptation with condence: augmenting service monitoring with online testing. In ICSE 2010 Workshop on Software Engineering for Adaptive and Self-Managing Systems (SEAMS 10), pages 2028, 2010. [107] Joaquin Miller and Jishnu Mukerji. MDA Guide Version 1.0.1. Technical report, OMG, 2003. [108] Brice Morin, Franck Fleurey, Nelly Bencomo, Jean-Marc Jzquel, Arnor e e Solberg, Vegard Dehlen, and Gordon S. Blair. An Aspect-Oriented and Model-Driven Approach for Managing Dynamic Variability. In 11th International Conference on Model Driven Engineering Languages and Systems (MoDELS08), volume 5301 of Lecture Notes in Computer Science, pages 782796, 2008. [109] Arun Mukhija and Martin Glinz. Runtime Adaptation of Applications Through Dynamic Recomposition of Components. In Systems Aspects in Organic and Pervasive Computing (ARCS2005), volume 3432 of Lecture Notes in Computer Science, pages 124138, 2005. [110] Arun Mukhija and Martin Glinz. The CASA Approach to Autonomic Applications. In 5th IEEE Workshop on Applications and Services in Wireless Networks (ASWN 2005), pages 173182, 2005. [111] Pierre-Alain Muller, Franck Fleurey, Zo Drey, Damien Pollet, Frdric e e e Fondement, and Philippe Studer. On Executable Meta-Languages applied to Model Transformations. In Model Transformations In Practice Workshop, 2005. [112] Dana Nau. Current trends in automated planning. AI Magazine, 28(4):43 58, 2007. [113] OMG. Meta Object Facility (MOF) Specication, 2.0, 2006. [114] OMG. MOF Model to Text Transformation Language (MOFM2T), 1.0, 2008. [115] OMG. MOF Query/View/Transformation Specication, 1.0, 2008. [116] Peyman Oreizy, Michael M. Gorlick, Richard N. Taylor, Dennis Heimhigner, Gregory Johnson, Nenad Medvidovic, Alex Quilici, David S. Rosenblum, and Alexander L. Wolf. An Architecture-Based Approach to Self-Adaptive Software. IEEE Intelligent Systems, 14(3):5462, 1999.
BIBLIOGRAPHY
213
[117] Carlos Parra, Xavier Blanc, and Laurence Duchien. Context awareness for dynamic service-oriented product lines. In 13th International Software Product Line Conference (SPLC 09), 2009. [118] Edwin P. D. Pednault. ADL. Exploring the Middle Ground Between STRIPS and the Situation Calculus. In 1st International Conference on Principles of Knowledge Representation and Reasoning (KR89), pages 324 332, 1989. [119] Joachim Peer. Web Service Composition as AI Planning - a Survey. Technical report, University of St. Gallen, Switzerland, 2005. [120] Brian Randell. System Structure for Software Fault Tolerance. IEEE Transaction on Software Engineering, 1(2):221232, 1975. [121] Anand Ranganathan and Roy H. Campbell. Autonomic Pervasive Computing Based on Planning. In 1st International Conference on Autonomic Computing (ICAC04), pages 8087, 2004. [122] Jinghai Rao and Xiaomeng Su. A Survey of Automated Web Service Composition Methods. In 1st International Workshop on Semantic Web Services and Web Process Composition (SWSWPC 2004), volume 3387 of Lecture Notes in Computer Science, pages 4354, 2004. [123] Muhammad Jaar-ur Rehman, Fakhra Jabeen, Antonia Bertolino, and Andrea Polini. Testing software components for integration: a survey of issues and techniques. Software Testing, Verication and Reliability, 17(2):95133, 2007. [124] Camila Ribeiro Rocha and Eliane Martins. A method for model based test harness generation for component testing. Journal of the Brazilian Computer Society, 14:723, 2008. [125] Dieter Rombach. Integrated Software Process and Product Lines. In Unifying the Software Process Spectrum - Revised Selected Papers of the International Software Process Workshop (SPW05), volume 3840 of Lecture Notes in Computer Science, pages 8390. 2005. [126] Nick Russell, Will M. P. van der Aalst, and Arthur H. M. ter Hofstede. Workow Exception Patterns. In 18th International Conference on Advanced Information Systems Engineering (CAiSE06), volume 4001 of Lecture Notes in Computer Science, pages 288302, 2006. [127] Stuart Russell and Peter Norvig. Articial Intelligence: A Modern Approach, chapter 11 - Planning, pages 375416. Prentice Hall, 2003. [128] Mazeiar Salehie and Ladan Tahvildari. Self-adaptive Software: Landscape and research challenges. ACM Transactions on Autonomous and Adaptive Systems (TAAS), 4(2):142, 2009.
BIBLIOGRAPHY
214
[129] Benjamin Satzger, Andreas Pietzowski, Wolfgang Trumler, and Theo Ungerer. Using Automated Planning for Trusted Self-organising Organic Computing Systems. In 5th International Conference on Autonomic and Trusted Computing (ATC08), volume 5060 of Lecture Notes in Computer Science, pages 6072, 2008. [130] Hilmar Schuschel and Mathias Weske. Integrated workow planning and coordination. In Database and Expert Systems Applications, volume 2736 of Lecture Notes in Computer Science, pages 771781. 2003. [131] Chetan Shankar and Roy Campbell. Ordering Management Actions in Pervasive Systems using Specication-enhanced Policies. In 4th IEEE International Conference on Pervasive Computing and Communications (PERCOM 06), pages 234238, 2006. [132] Vladimir A. Shepelev and Stephen W. Director. Automatic workow generation. In conference on European design automation (EURO-DAC 96/EURO-VHDL 96), pages 104109, 1996. [133] Santosh K. Shrivastava, Luc Bellissard, David Fliot, M. Herrmann, Noel e de Palma, and Stuart M. Wheater. A Workow and Agent Based Platform for Service Provisioning. In 4th International Enterprise Distributed Object Computing Conference (EDOC00), pages 3847, 2000. [134] Evren Sirin, Bijan Parsia, Dan Wu, James A. Hendler, and Dana S. Nau. HTN planning for Web Service composition using SHOP2. journal Web Semantic, 1(4):377396, 2004. [135] Stephen J. J. Smith, Dana S. Nau, and Thomas A. Throop. Computer Bridge - A Big Win for AI Planning. AI Magazine, 19(2):93106, 1998. [136] Edward A. Stohr and J. Leon Zhao. Workow Automation: Overview and Research Issues. Information Systems Frontiers, 3(3):281296, 2001. [137] Daniel Sykes. Autonomous Architectural Assembly And Adaptation. PhD thesis, Department of Computing - Imperial College of Science, Technology and Medicine, February 2010. [138] Daniel Sykes, William Heaven, Je Magee, and Je Kramer. Plan-directed architectural change for autonomous systems. In 2007 conference on Specication and verication of component-based systems (SAVCBS07), pages 1521, 2007. [139] Daniel Sykes, William Heaven, Je Magee, and Je Kramer. From goals to components: a combined approach to self-management. In ICSE 2008 Workshop on Software Engineering for Adaptive and Self-Managing Systems (SEAMS 08), pages 18, 2008.
BIBLIOGRAPHY
215
[140] Daniel Sykes, William Heaven, Je Magee, and Je Kramer. Exploiting Non-Functional Preferences in Architectural Adaptation for Self-Managed Systems. In 2010 ACM Symposium on Applied Computing (SAC10), 2010. [141] Thomas Ternit. Process Lines: A Product Line Approach Designed for e Process Model Development. In 35th Euromicro Conference on Software Engineering and Advanced Applications (SEAA09), pages 173180, 2009. [142] Craig Thompson, Wing Ning Li, and Zhichun Xiao. Workow Planning on a Grid. IEEE Internet Computing, 11(1):7477, 2007. [143] Yves Le Traon, Thierry Jron, Jean-Marc Jezequel, and Pierre Morel. Ee cient object-oriented integration and regression testing. IEEE Transactions on Reliability, 49(1):1225, mar. 2000. [144] Giuseppe Valetto. Orchestrating the dynamic adaptation of distributed software with process technology. PhD thesis, Columbia University, 2004. [145] Giuseppe Valetto and Gail Kaiser. Using Process Technology to Control and Coordinate Software Adaptation. In 25th International Conference on Software Engineering (ICSE 03), pages 262272, 2003. [146] Wil M. P. van der Aalst, Lachlan Aldred, Marlon Dumas, and Arthur H. M. ter Hofstede. Design and Implementation of the YAWL System. In 16th International Conference on Advanced Information Systems Engineering (CAiSE04), volume 3084 of Lecture Notes in Computer Science, pages 142159, 2004. [147] Wil M. P. van der Aalst and Arthur H. M. ter Hofstede. YAWL: Yet Another Workow Language. Information Systems, 30(4):245275, 2005. [148] Wil M. P. van der Aalst, Arthur H. M. ter Hofstede, Bartek Kiepuszewski, and Alistair P. Barros. Workow Patterns. Distributed and Parallel Databases, 14(1):551, 2003. [149] Yves Vandewoude. Dynamically updating component-oriented systems. PhD thesis, Katholieke Universiteit Leuven Departement Computerwetenschappen (Department of Computer Science), 2007. [150] Michel Wermelinger, Georgios Koutsoukos, Jos Luiz Fiadeiro, Luis Ane drade, and Joo Gouveia. Evolving and Using Coordinated Systems. In a Proc. of the International Workshop on Principles of Software Evolution (IWPSE02), 2002. [151] WfMC. Terminology and Glossary, 3rd Edition. Technical Report WfMCTC-1011, Workow Management Coalition, 1999.
BIBLIOGRAPHY
216
[152] Jules White, Brian Dougherty, Harrison D. Strowd, and Douglas C. Schmidt. Using Filtered Cartesian Flattening and Microrebooting to Build Enterprise Applications with Self-adaptive Healing. In Software Engineering for SelfAdaptive Systems, volume 5525 of Lecture Notes in Computer Science, pages 241260, 2009. [153] Zhichun Xiao Xiao, Craig W. Thompson, and Wing Li. Automating Workow for Data Processing in Grid Architecture. In 2006 International Conference on Information & Knowledge Engineering (IKE 2006), pages 191195, 2006. [154] Jie Xu, Brian Randell, Alexander B. Romanovsky, Cecilia M. F. Rubira, Robert J. Stroud, and Zhixue Wu. Fault Tolerance in Concurrent ObjectOriented Software Through Coordinated Error Recovery. In Symposium on Fault-Tolerant Computing, pages 499508, 1995. [155] Il-Chul Yoon, Alan Sussman, Atif Memon, and Adam Porter. Directdependency-based software compatibility testing. In 22nd IEEE/ACM international conference on Automated software engineering (ASE07), 2007. [156] Il-Chul Yoon, Alan Sussman, Atif Memon, and Adam Porter. Prioritizing component compatibility tests via user preferences. In IEEE International Conference on Software Maintenance (ICSM09), pages 2938, 2009.

Thesis Final Version

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Thesis Final Version

Uploaded by

Copyright:

Available Formats

DYNAMIC GENERATION OF ADAPTATION PLANS FOR SELF-ADAPTIVE SOFTWARE SYSTEMS

By Carlos Eduardo da Silva May 2011

116 173 174 174

5.3 5.4 5.5

4.27 4.28 4.29

Chapter 2 State of the Art

Self-adaptive Software Systems

CHAPTER 2. STATE OF THE ART

Characterising Self-adaptive Software Systems

CHAPTER 2. STATE OF THE ART

CHAPTER 2. STATE OF THE ART

Reference Models for Self-adaptive Software Systems

CHAPTER 2. STATE OF THE ART

CHAPTER 2. STATE OF THE ART

CHAPTER 2. STATE OF THE ART

CHAPTER 2. STATE OF THE ART

CHAPTER 2. STATE OF THE ART

Processes and Plans

CHAPTER 2. STATE OF THE ART

CHAPTER 2. STATE OF THE ART

CHAPTER 2. STATE OF THE ART

CHAPTER 2. STATE OF THE ART

CHAPTER 2. STATE OF THE ART

CHAPTER 2. STATE OF THE ART

CHAPTER 2. STATE OF THE ART

Processes and Exception Handling

CHAPTER 2. STATE OF THE ART

CHAPTER 2. STATE OF THE ART

CHAPTER 2. STATE OF THE ART

Chapter 3 A Framework for the Dynamic Generation of Workows

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

Articial Intelligence Planning

A detailed overview of planning can be found in [71]

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

STRIPS means STanford Research Institute Problem Solver

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

Model Driven Engineering

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

Coordinated Atomic Actions

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

General Model of the Framework

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

The Domain Model

Thus the use of EString to represent String type

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

Figure 3.11: Metamodel for the specication of task templates.

CHAPTER 3. DYNAMIC GENERATION OF WORKFLOWS

The Reference Process