University of Southern California Dissertations and Theses

A reference architecture for integrated self‐adaptive software environments

(USC Thesis Other)

A reference architecture for integrated self‐adaptive software environments

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content A REFERENCE ARCHITECTURE FOR INTEGRATED SELF-ADAPTIVE SOFTWARE ENVIRONMENTS by Hossein Tajalli A Dissertation Presented to the FACULTY OF THE USC GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (COMPUTER SCIENCE) August 2014 Copyright 2014 Hossein Tajalli Dedication I dedicate my dissertation to my high school teacher and my friend, Hamid Reza Mesgari, who taught me programming at first. He guided me, encouraged me, and provided me with opportunities to explore and enjoy programming. ii Acknowledgments First and foremost, I would like to express my eternal gratitude to my adviser, Professor Nenad Medvidovic, for his influential guidance, encouragement, patience, and tremen- dous concern for the success of this research. He was not only my academic advisor, but also my friend and my mentor. Additionally, I would like to acknowledge my dis- sertation committee members, Professor Barry Boehm, Professor William G.J. Halfond, Professor Milind Tambe, and Professor Massoud Pedram, for all of their insightful and helpful feedback. I would like to also acknowledge my colleagues in the research group, George Ed- wards, Joshua Garcia, Ivo Krka, Reza Safi, and Jae Young Bang. They listened to my presentations many times and provided me with valuable input and feedback. Finally, I am grateful to my parents and my wife, Nazbanoo Noroozi, who supported me uncon- ditionally. iii Table of Contents Dedication ii Acknowledgments iii List Of Tables vi List Of Figures vii Abstract xi Chapter 1 Introduction 1 1.1 Concepts and Terminology 4 1.2 Motivation and Research Problems 12 1.3 Solution Elements 17 1.4 Solution Technique 22 1.5 Contributions 24 Chapter 2 Adaptive Layered Software Style 26 2.1 Approach 28 2.2 Implementation Support 33 Chapter 3 iDARE Reference Architecture 45 3.1 Standalone Development Environments 49 3.2 Life-cycle development environments 51 3.3 Integrated development and run-time environments 54 3.4 Designs of the Existing SALEs 59 3.5 Desirable Structural and Quality Properties of SALEs 67 3.6 iDARE Reference Architecture 70 Chapter 4 PLASMA 77 4.1 Approach 79 4.2 Design and Implementation 90 Chapter 5 The 6A Approach 105 5.1 Motivating Application Domain 108 5.2 Domain of Software Adaptation 110 iv 5.3 Approach 121 5.4 Software Adaptation Artifacts 136 5.5 Time Complexity 158 Chapter 6 Implementation 176 6.1 Architecture of Eclipse 176 6.2 Design of Plug-ins in 6A 178 6.3 Architecture of 6A 181 Chapter 7 Evaluation 187 7.1 Adaptation of Run-time Application 188 7.2 Adaptation of Adaptation Engine 198 Chapter 8 Related Works 218 8.1 The Sykes Approach 221 8.2 Feature-oriented Declarative Approach 222 8.3 Data-flow Declarative Approach 224 8.4 AI-based Declarative Approach 224 8.5 ArchStudio3 226 8.6 Service-oriented Declarative Approach 226 8.7 Aura 227 8.8 MADAM 228 8.9 Goal-oriented Declarative Approach 229 8.10 Web-service Composition 230 8.11 Summary 231 Chapter 9 Conclusions 233 9.1 Future Research Directions 237 References 239 Appendix A 6A Internal Language Grammar 248 Appendix B SADEL Syntax Summary 254 v List Of Tables 5.1 Time complexity of 6A, where n is number of interfaces and m is the number of candidate configurations in the absence of structural constraints.174 7.1 Equivalent modeling element classes in 6A vs. the Sykes approach. 196 7.2 Comparison of adaptation artifacts utilized by 6A vs. the other similar declarative adaptation approaches. 214 7.3 Comparison of domain architect’s activities and eort to provide and maintain adaptation artifacts in 6A vs. similar declarative adaptation approaches. 216 8.1 Comparison of self-adaptive declarative software approaches. 231 vi List Of Figures 1.1 Two-layer adaptive software style. 6 1.2 High-level common architecture of SALEs. 7 1.3 Adaptive layered software style. 18 1.4 High-level architecture of iDARE reference architecture. 19 1.5 High-level architecture of PLASMA. 20 1.6 High-level architecture of 6A. 23 2.1 Notional depiction of an example adaptive layered architecture. 31 2.2 UML class design view of Prism-MW. Middleware core classes are high- lighted. 34 2.3 Layered view of the Prism-MW architecture. 35 2.4 UML class design of the extended Prism-MW. 37 2.5 Energy-aware robotics system. 41 2.6 UML class design for the energy-aware robotics system. 41 2.7 Implementations for the (top) IRequirement and the (bottom) Energy Requirement from example in Figure 2.6. 42 2.8 Excerpt for theEnergyAdmin implementation from example in Figure 2.5. 43 3.1 Common architecture for standalone development environments. 49 3.2 Common architecture for life-cycle development environments. 51 vii 3.3 Common architecture for exploratory programming environments. 54 3.4 Common architecture for SALEs. 56 3.5 Architecture of RAIDE in terms of the iDARE constructs. 61 3.6 Architecture of PBAAM in terms of the iDARE constructs. 62 3.7 Architecture of PESOI in terms of the iDARE constructs. 65 3.8 Architecture of SADE in terms of the iDARE constructs. 66 3.9 iDARE Reference Architecture. 71 4.1 (a) An example application domain model. (b)The example extended with an additional capability. 80 4.2 An example adaptation domain model. 82 4.3 The PLASMA adaptive layered architecture. 83 4.4 The SADEL specification for theLoader component. 93 4.5 The SADEL specification for theAdmin meta-level component. 94 4.6 An NPDDL domain model description for the example domain. 95 4.7 NPDDL domain model description for the example adaptation domain. 100 4.8 Architecture of the run-time application and the adaptation layer after both of them are adapted. 103 5.1 Partial architectural view of the disaster response application. 110 5.2 General life-cycle state transition model of components. 112 5.3 General life-cycle state models for connector classes and instances in an architecture-based adaptive software system. 114 5.4 Partial state model for a client in the domain of client-server applications. 115 5.5 An overview of general adaptation actions in the domain of architecture- based software adaptation captured in an HTN. 117 viii 5.6 Decomposition of a primitive action to exclusive disjunction of domain- specific action implementations. 118 5.7 Decomposition of a composite action. 119 5.8 Two example initial states before Image Collector and Data Collector are welded. 120 5.9 Partial architectural view of the disaster response application, after adap- tation. 124 5.10 6A in the context of PLASMA. 125 5.11 An excerpt of the applications’s current state of the running example. 126 5.12 An excerpt of the adaptation plan for the running example. 127 5.13 An excerpt of the synthesis plan for the running example. 128 5.14 An example method in SHOP2. 129 5.15 An example operator in SHOP2. 130 5.16 The method to check the structural constraints in the 6A HTN with an example constraint. 134 5.17 A customized method to calculate cost values in SHOP2. 135 5.18 An example of functional requirements used by 6A. 136 5.19 An example of ADL models of the C2 architecture. 139 5.20 An example SADEL model of an adaptation component. 142 5.21 Resolve component dependencies in 6A Adaptation HTN. 160 5.22 Behavior of 6A in the absence of structural constraints and quality prefer- ences. 166 5.23 Behavior of 6A for acyclic configuration requirements. 168 5.24 Optimal and sub-optimal planning time in 6A for non-additive quality properties. 170 5.25 Optimal planning in case of additive quality properties. 172 ix 6.1 Architecture of Eclipse. 178 6.2 Overall architecture of 6A. 182 6.3 A snapshot of the 6A environment. 184 7.1 A simplified view of the domain model description of the ABS system, when all components are available. 191 7.2 Architecture of the run-time application when all components are available.192 7.3 Architecture of the run-time application after theLocal-Builder compo- nent failure. 192 7.4 Architecture of the run-time application after the File-Hist-Mngr com- ponent failure. 193 7.5 Architecture of the run-time application after theBuild-Fetcher compo- nent failure. 193 7.6 The self-adaptability framework to compare the self-adaptability level of architecture-centric self-adaptive approaches. 201 7.7 The time complexity of 6A vs. the Alloy analyzer, in the presence of structural constraints. 208 7.8 Required Memory for planning vs. number of interfaces in Alloy and 6A. 209 7.9 Required time for planning vs. number of interfaces. 210 7.10 Required Memory for planning vs. number of components. 211 x Abstract Modern software systems are increasingly expected to satisfy high reliability and high availability requirements. During their life-span, they need to constantly and seamlessly adapt and evolve in response to new requirements and changing circumstances. Soft- ware adaptation and evolution in modern software systems could not degrade software availability. Consequently, self-adaptive software systems are desirable. Adaptation tools in several recent self-adaptive software systems are implemented as development environment tools. This resulted in the tight integration of the de- velopment and run-time environments in these systems. Although integration of the development and run-time environments has several benefits, tight integration of these environments causes several structural and quality shortcomings (e.g., availability and resource consumption) in self-adaptive software environment. Therefore, new soft- ware environments with loosely integrated development and run-time environments are desirable. In addition, as a software system evolves during its life-span, adaptation activities that pertain to it also evolve. Consequently, a self-adaptive software system should also evolve its adaptive behavior autonomously. New tools and approaches are demanded to support self-adaptation of the adaptation tools in self-adaptive software systems. Additionally, there is a disconnect between the modeling and the adaptation xi artifacts in the existing self-adaptive software systems, which limits the self-adaptability of those systems. New modeling techniques are required to link models and adaptation artifacts in self-adaptive software systems. This dissertation provides a reference architecture for integrated self-adaptive soft- ware environments that addresses several structural and quality shortcomings of the existing integrated software environments. Additionally, this dissertation provides a model-driven software self-adaptation technique to support adaptation of both run- time application and adaptation tools in self-adaptive software systems. This technique leverages architectural models in order to synthesize behavioral models of the run-time application and the adaptation tools, at run-time. The resulting synthesized behavioral models are used to guide the adaptation behavior of the system. Both the reference architecture and the adaptation technique provided in this dissertation are based on a new adaptive, layered, architectural style introduced in this dissertation. The resulting self-adaptive software environment provided in this dissertation delivers higher flexi- bility, separation of concerns, fault-tolerance, adaptability, and robustness compared to the existing self-adaptive software systems. xii Chapter 1 Introduction Modern software systems are increasingly expected to satisfy high reliability and high availability requirements. During their life-span, they need to constantly and seamlessly adapt and evolve in response to new requirements and changing circumstances. Soft- ware adaptation and evolution in modern software systems could not conflict with their availability. For example, in safety- and mission-critical software systems, stopping and restarting the system for any software alteration causes unacceptable delays, increased cost, and risk. Air trac control, telephone switching, and process automation software are in this class of software systems. Moreover, frequent software architect access to autonomous software systems is undesirable and time-consuming. These systems need to heal themselves in the case of software failures and adapt to the new circumstances on their own. Some space robotic applications and sensor networks deployed in unreach- able environments are in this class of software systems. Consequently, modern software systems are expected to autonomously alter and extend their functionality, handle fail- ures of software and hardware components, adapt to new environment conditions, and apply updates and bug fixes while the system is executing, i.e., without being stopped 1 and restarted. A software system with such capabilities is called a self-adaptive software system. Software maintenance and evolution tools are required to design, analyze, validate, plan, stage, and perform run-time software adaptations in self-adaptive software sys- tems. These tools perform both development-time and run-time activities, and a natural place to implement and integrate them is software development environments. Inte- gration of the development-time and run-time tools is essential to the performance of self-adaptive software systems and resulted in the integration of the development and run-time environments for several self-adaptive software system. I call such integrated environments Self-Adaptive Life-cycle Environments (SALEs). PESOI [96], Rainbow [19], PBAAM [38], SADE [29], and ArchStudio [23] are examples of SALEs. SALEs have emerged recently and have not been studied adequately. The tight integration of the de- velopment and run-time environments in SALEs results in several structural and quality shortcoming (e.g., availability and resource consumption). A flexible design for environ- ment integration and new types of run-time tools are necessary to resolve the deficiencies of SALE. As a software system evolves during its life-span, adaptation activities that pertain to it also evolve. Consequently, a self-adaptive software system should also be able to autonomously change its adaptive behavior. Changes to the adaptation aspects of a system (e.g., type and range of adaptable elements and adaptation optimization criteria) have dierent levels of severity. While the less severe changes can be accommodated by adjusting the adaptation artifacts, the more severe changes may actually necessitate structural adaptation of the tools that carry software adaptation, which is usually harder 2 and more expensive to perform. New tools and approaches are demanded to support self-adaptation of the adaptation tools in self-adaptive software systems. Software modeling and analysis techniques have been employed by many self- adaptive software systems. For instance, models are used to specify a system that must undergo run-time adaptation(e.g., in [38]), and analysis techniques are used to examine the implications of system adaptations (e.g., in [23]). Self-adaptive software systems use various modeling techniques with dierent modeling capabilities and in dierent capacities. Modeling techniques used for software adaptation usually model components and connectors and their interconnections in a system. Complex modeling techniques (e.g., [22, 34, 67]) with modeling support for structural constraints, proper- ties of software elements, and run-time behavior of software modules are employed for advanced self-adaptive software systems. It is also promising to utilize modeling techniques in order to model, manage, and adapt the adaptive behavior of self-adaptive software systems. Additionally, there is a disconnect between the modeling and the adaptation artifacts in the existing self-adaptive software systems, which limits the self- adaptability of those systems. New modeling techniques to link models and adaptation artifacts of self-adaptive systems are required. This dissertation provides a reference architecture for integrated self-adaptive soft- ware environments that address several structural and quality shortcomings of the exist- ing SALEs. Moreover, it provides two model-driven approaches to support adaptation of both run-time application and adaptation tools in a self-adaptive software system. These approaches dynamically synthesize behavioral models of the run-time application and the adaptation tools from software models. The resulting synthesized behavioral models 3 are used to guide the adaptation behavior of the system. The core of the proposed refer- ence architecture an the adaptive, layered architectural software style introduced in this dissertation. The design of the reference architecture and the model-driven approaches that comes with it provide higher flexibility, separation of concerns, fault-tolerance, adaptability, and robustness compared to the existing SALEs. 1.1 Concepts and Terminology This section summarizes the foundational concepts and defines the key terms used in this dissertation. 1.1.1 Architectural Models A software or system architecture is the set of principal design decisions for that sys- tem [93]. Architecture of a system can be captured in an architectural model using a particular modeling notation, frequently referred to as Architecture Description Language (ADL) [93]. ADLs usually capture components, connectors, and topology of a system. Com- ponents encompass the processing and data concerns of the system, while connectors deal with interaction concerns. The topology of a system determines how components and connectors are composed in the system. 4 1.1.2 Architecture-based Software Adaptation Existing run-time software adaptation approaches enact software changes at dierent granularity levels. Older approaches tend to treat the systems at the level of software pro- cedures, modules, and classes. For example, the On-line Software Version Change [42], PODUS [85], and Smalltalk [94] and Interlisp [41] environments allow run-time software updates at the level of statements and procedures. DYMOS [56], Erlang [1, 7], and the Peterson et al.’s approach [81] adapt systems at the level of software modules. Dynamic C++ Classes [44], Dynamic Java [4], and Dynamic Java Classes [62] update software classes. Modern self-adaptive software systems, such as ArchStudio3 [24], PBAAM [37], Rainbow [33], on the other hand, take an architecture-centric approach to run-time soft- ware adaptation. In this approach, software adaptation happens at the level of system’s architecture and proceeds from a strong architectural foundation. Moreover, an explicit architectural model of the system exists and adapts concurrently with the run-time ap- plication. This architectural model is leveraged to reason about the adaptation activities required by a system [78]. Adaptation in this approach includes activities such as adding, removing, and relocating components and connectors and changing the system’s topol- ogy. Architecture-based approaches to run-time software adaptation have several advan- tages. They utilize composition, hierarchy, and abstraction to reduce complexity and increase scalability. Furthermore, a rich area of existing work on software architecture modeling and analysis can be exploited. For example, a variety of existing ADLs can 5 Run-time Application Run-time Environment Adaptation Engine ` Autonomic Component Adaptation Components Application Component Application Component Application Component Figure 1.1: Two-layer adaptive software style. be used to model a system that must undergo run-time adaptation, and architectural analysis techniques can be used to examine the implications of system adaptations. 1.1.3 Software Adaptation Style An architectural style is a named collection of architectural design decisions to constrain a system’s architecture in a given development context to elicit beneficial qualities in each resulting system [93]. Many architecture-based self-adaptive software systems have employed the two-layer adaptive software style. Adherence to this style results in the separation of the application and adaptation concerns in a system. As depicted in Figure 1.1, run-time environment of a system in this style comprises two key lay- ers: Adaptation Engine and Run-time Application. Run-time application encompasses (application) components, which together enforce the logic of the system. Adaptation engine, on the other hand, encompasses meta-components that impose the adaptation logic of the run-time application to monitor, adapt, and maintain it. Several self-adaptive systems, such as [19, 38, 54, 91], follow this style. 6 Run-time Environment Run-time Application Development Environment Adaptation Engine Figure 1.2: High-level common architecture of SALEs. 1.1.4 Integrated Software Environments Software development environments are intended to augment or automate a range of critical software development activities, from requirements elicitation and negotiation, modeling, and design, through system implementation, testing, debugging, and deploy- ment, to maintenance and evolution. They also help to coordinate ideas, artifacts, and resources involved with a software system. Development and run-time environments have dierent levels of interaction in var- ious systems. In specific classes of software systems, these environments are fully inte- grated. We categorize integrated software environments into two classes: environments for exploratory programming and SALEs. Some traditional development environments, such as Interlisp [94], Smalltalk [41], Cedar [89], and Rational Environment [6], support the exploratory style of programming. This style allows rapid generation of the software in increments, while the programmer is experimenting with the software prototypes. In this type of systems, development and run-time environment are one and the same. 7 Self-adaptive Life-cycle Environments (SALEs) provide development-time and run-time tools to support all the stages in the life-cycle of a self-adaptive software system. They are specially interesting as they form a growing class of emerging development envi- ronments (e.g., [19, 23, 29, 38, 96] are among the SALEs emerged during the last decade). As depicted in Figure 1.2, the adaptation engines in the SALEs are implemented as run-time development environment tools. This brings the benefits of tool integration in development environments to self-adaptive software systems. This way, the process of artifact design, implementation, verification, validation, deployment, evolution, and adaptation can be orchestrated in the same environment among dierent development- time and run-time tools. SALEs also provide tools to design the adaptation logic and user interfaces to control the adaptation behavior of a system. 1.1.5 Adaptation Artifacts Architecture-based software self-adaptation requires a variety of software artifacts, in- cluding adaptation logic and adaptation plans. Software adaptation is triggered autonomi- cally according to adaptation logic and executed autonomically according to adaptation plans. Adaptation logic specify when an adaptation is necessary (e.g., ComponentA fails to respond to a service request, or average response time of a web service drops be- low a threshold), what the outcome of an adaptation should be (e.g., ComponentA is replaced with ComponentB, or the web service is deployed on a faster server), and how the outcome of the adaptation should be achieved (i.e., the adaptation plan). Adapta- tion plans specify the sequence of adaptation actions necessary to achieve that outcome (e.g., record ComponentA’s context, uninstantiate ComponentA, download ComponentB’s 8 implementation, instantiateComponentB, setComponentB’s context). An adaptation plan is determined by the adaptation logic of a system and is expressed in terms of archi- tectural elements described in the architectural models of a system. Other adaptation artifacts may be required by various self-adaptive approaches to support generation and management of adaptation logic and adaptation plans. 1.1.6 Adaptation Logic Classification There are two major approaches to self-adaptive software systems: prescriptive and declar- ative. In the prescriptive approach, adaptation logic is provided in form of adaptation policies. A policy is a set of condition-action rules that determines behavioral and struc- tural system modifications when a software adaptation is required. In this approach, application architect needs to anticipate the adaptation requirements and manually pro- vide adaptation policies. An adaptation logic evaluator examines the adaptation policies against the state of the system and determines the required adaptation plan. Prescriptive approach puts a burden on the software architect and is error-prone. Rainbow [33] and PBAAM [37] are examples of this approach. In contrast, in the declarative approach, adaptation logic is provided (by the adapta- tion approach) in the form of a composition algorithm. In this approach, software architect only declares what is expected from the system, and does not prescribe how her expec- tations should be achieved. The composition algorithm in this approach searches in the solution space to find a solution that satisfies the software architect’s declared require- ments. In order to cope with the run-time conditions that result in violation of system requirements, the composition algorithm automatically calculates a new topology and 9 an adaptation plan to adapt the system to its new topology. Failures, system updates, and changes in the environment conditions or system-requirements are among the condi- tions that result in a software adaptation in this approach. A comprehensive composition algorithm needs to consider three types of requirements: functional requirements, qual- ity requirements, and structural constraints. The declarative approach is employed by systems such as [32, 91] and is more desirable than the prescriptive approach, because it is less human intensive and hence scalable and less error-prone. 1.1.7 Software Adaptation Roles At least, three classes of roles can be recognized in the domain of architecture-based self-adaptive software systems: Software architects are responsible for designing a system’s architecture and capturing it in an Architectural Description Language (ADL) [93]. Two groups of software architects design a self-adaptive software system in dierent levels of abstraction: Domain architect designs the vocabulary, high-level rules and constraints, and relationships for architectural elements for a specific domain or archi- tectural style, to be used with a specific self-adaptive approach. Domain architect also designs the related adaptation actions applicable to a domain or architectural style. Application architect designs architectural elements (e.g., components and connectors) for a specific application, in a specific domain or architectural style. Application architects for advanced self-adaptive software systems, 10 such as the one introduced in this dissertation, do not need to deal with the topology of the run-time application, as the topology is automatically calculated and managed by the self-adaptive systems. Software developers are responsible for implementing architectures provided by soft- ware architects: Platform developer implements software frameworks or run-time platforms to support implementation and execution of architecture-centric software sys- tems. Domain developer implements software elements to back up a specific do- main or an architectural style on a specific framework or run-time platform. This also involves implementation of meta-components for those domains or architectural styles. Application developer Implements application components and connectors to be run on a specific platforms. Software end-user specifies run-time software requirements and preferences, runs ap- plications, and supervise their execution. The ultimate goal of the self-adaptive software approaches is to minimize the responsibilities of this role in order to reach fully automated software systems. 11 1.2 Motivation and Research Problems Tight integration between the development and run-time environments in SALEs results in several structural and quality shortcomings. Moreover, the static structure of the adaptation engines in SALEs (the static structure of the adaptation engines in general) limits the evolvability of the adaptation behavior of self-adaptive software systems. Fur- thermore, the architecture of the existing two-layer adaptive style is insucient to design self-adaptive adaptation tools. There is also a disconnect between the adaptation arti- facts and architectural models in declarative self-adaptive software systems, which limits the self-adaptability aspects of some of the existing declarative self-adaptive software systems. 1.2.1 Tight Integration SALEs are intended to manage systems with high availability and dependability re- quirements. The development and run-time environments in existing SALEs are tightly integrated. Therefore, the availability and dependability of run-time applications in existing SALEs are highly dependent on the structural and quality properties of their development environments. Because of the tight integration of the development and run-time environments in existing SALEs, unavailability of the development environment in a SALE essentially results in the unavailability of its run-time application. A development environments in a SALE may become unavailable due to tool failures, maintenance activities, and lack of resources. First, the failure of a development environment tool may result in the failure 12 of the entire SALE. Even if a SALE does not fail because of a constituent tool’s failure, it may still need to be restarted to recover from that failure. Moreover, the development en- vironment in a SALE may need to be brought down for maintenance of its infrastructure or tools. In Section 1.2.2, we identify and classify several unanticipated run-time condi- tions in which a SALE’s run-time tool set needs to be altered. Finally, lack of memory or computational resources may prevent the execution of the development environment in a SALE. In circumstances when the development environment and the run-time applica- tion of a SALE are distributed on dierent hosts, scarcity of the communication resources may result in the unavailability of the development environment. 1.2.2 Static Adaptation Tools As a run-time application evolves during its life-span, adaptation activities that pertain to it also evolve. To respond to changing adaptation needs of a system, the behavior and the structure of the adaptation engines should be adaptable themselves. Changes to the adaptation aspects of a system have dierent levels of severity. While the less severe changes can be accommodated by adjusting the adaptation artifacts, the more severe changes may actually necessitate structural adaptation of the adaptation tools, which is usually harder and more expensive to perform. I distinguish five aspects of software adaptation that may change at run-time. Structural changes in an adaptation engine may be required to accommodate changes to all but the first aspect: 1. Adaptation plans. The set of required condition-action rules for a system may change at run-time. A naive approach to declare the adaptive behavior of a system is to hard-code the behavior into the system’s adaptation engine. In such a system, the 13 adaptation plan can only be changed by changing the structure of the adaptation engine. To avoid structural adaptations in this case, the adaptation plans of a system should be separated from the tools that enact the plans, i.e., the adaptation plans should be dynamically provided to the adaptation tools as separate artifacts. 2. Optimization criteria on adaptation plans. an adaptation plan of a system may be optimized in various ways. End-user’s preferences on the optimization criteria to calculate an adaptation plan may change at run-time. For instance, the end- user may prefer to optimize the adaptation plan in a way that system adaptation takes a minimal time, or the utility of the run-time application after adaptation be maximized. 3. Underlying platform. A system may need to manage and adapt architectural ele- ments that run on a new platform. In this case, the adaptation logic should evolve to incorporate new adaptation actions that conform to the new platform. 4. Type and range of adaptable elements. A system may need to manage and adapt new types of application components and connectors that require dierent adap- tation steps to be added, updated, or removed. For example, to add a data access component to an application, a data access connector should be used and the con- nection between the component and a database engine should be initiated. As a result, an adaptation engine with no knowledge about data access components and connectors is unable to employ a data access component. 14 5. Type and range of supported adaptation logic. This level of change may be interpreted dierently for various self-adaptive approaches. In the case of a prescriptive ap- proach, the policy type may change. For example, a system that handles policies of the form if-condition-then-action, may need to handle policies of the form when- event-if-condition-then-action. On the other hand, in the case of a declarative approach, an adaptation engine may need to support new types of requirements. For example, an adaptation engine that handles functional requirements may need to handle non-functional requirements as well. Moreover, a declarative adaptation engine may need to support adaptation policies (and vice versa: a prescriptive one may need to support requirements). Adaptability of the adaptation engine in a self-adaptive software system contributes to the availability and dependability of the system as a whole. On the one hand, a system with adaptable adaptation engines can be updated without going down for maintenance when adaptation needs of its run-time application change. On the other hand, adaptable adaptation engines are more dependable because they can be altered or restarted in unanticipated situations (such as tool failure). 1.2.3 Inadequate Self-adaptive Style The existing two-layer adaptive style is insucient to support the adaptability, fault- tolerance, and robustness of the adaptation engines in architecture-based self-adaptive software systems. This style encloses the adaptation tools in a single module and pro- vides no abstraction for monitoring and adaptation of the adaptation engine itself. 15 1.2.4 Disconnect of Adaptation Artifacts and Architectural Models Adaptation artifacts are related to both the application elements that should undergo adaptation and the adaptation operations (of meta-level components) that should be enacted on the run-time application. However, in the existing approaches, there is a disconnect between the adaptation artifacts and architectural models of the application and adaptation elements. This disconnect limits dierent aspects of adaptability of self- adaptive systems. For instance, in [91], software adaptation is based on a domain model description (DMD), which describes the applicable actions to the run-time application and how they transform the state of the application. However, the application architect needs to manually map the DMD to the architectural model of the run-time application. Similarly, in [32], software adaptation is based on a feature model that specifies the re- lation of the run-time application’s features. A feature is an abstraction of a capability provided by the run-time application. The mapping between the features and the archi- tectural model of the run-time application is provided by the application architect. On the other hand, in Planit [8] the adaptation artifacts are not tied to the meta-components that enact the adaptation actions on the run-time application. Planit utilizes a domain model description that describes adaptation actions applicable to a system in order to find adaptation plans. However, the actions provided by this domain model description are not tied to the meta-components that actually provide those actions. Changes to the application and adaptation artifacts in these approaches do not reflect on the adaptation artifacts of the system, causes discrepancy of the adaptation artifacts, and limits the adaptability of the system. For example, in the case of [91], when a 16 component fails, the DMD cannot be automatically updated. Therefore, the only possible adaptations after a component failure is to find a replacement component or to restore the failed component, which may not always be possible. Moreover, in the case of Planit, changes in the adaptation capabilities (e.g., by providing a new meta-level component) cannot be automatically reflected on the domain model description used by Planit. 1.3 Solution Elements This dissertation provides a fully adaptable integrated environment for declarative soft- ware self-adaptation, which comprises several integrated architecture-centric solution el- ements. Each of these elements resolves one of the problems associated with architecture- based self-adaptive software systems, recognized in Section 1.2. The elements of my solution are (1) an adaptive, layered, architectural software style, (2) a reference archi- tecture for integrated software environments (iDARE), (3) an architectural approach to automatically create adaptation artifacts from architectural models (PLASMA) in declar- ative systems, and (4) an architectural approach to automatically synthesize and update composition algorithms (6A) for declarative systems. The rest of this section describes the individual elements in my solution. 1.3.1 Adaptive Layered Style In this dissertation, I introduce the adaptive layered architectural style, shown in Figure 1.3. This style distinguishes two types of components: application-level components and meta-level components (or meta-components). Application-level components implement 17 Application Layer Meta1 Layer . . . Meta n Layer Legend Admin Collector Analyzer Application Components Architecture Architectural Reference Meta Architecture Figure 1.3: Adaptive layered software style. functionality that achieves the application goals. Meta-level components are architec- turally aware and facilitate adaptation and management of architectural elements (e.g., components and connectors) in a system. Adaptive layered style distinguishes three distinct, specialized types of meta-level components: collectors, analyzers, and admins. Collectors monitor components, analyzers evaluate adaptation policies or adaptation plans based on monitored data, and admins actually modify architectural elements. This style allows meta-level components to themselves be monitored, managed, and adapted by other (higher layer) meta-level components. To this end, adaptive layered style presents a meta-layering scheme. Traditionally, layering implies that components at a given layer invoke the services of components at the layer below. In contrast, meta- level components at a given meta-layer in the adaptive layered style monitor, manage, and adapt components at the layer below. Adaptive layered style allows for layering of arbitrary depth and supports the design of adaptable adaptation engines. 18 Run-time Environment Run-time Application Adaptation Engine Manager Development Environment Detachable Adaptation Engine Figure 1.4: High-level architecture of iDARE reference architecture. 1.3.2 iDARE The design of SALEs (see Section 1.1.4) have inspired me to introduce iDARE, a ref- erence architecture for integrated Development And Run-time Environments, depicted in Figure 1.4. This architecture is useful for understanding, classifying, and studying development environments from the perspective of their interaction with run-time en- vironments. The adaptation engine in iDARE lies at the intersection of the development and run-time environments. However, the adaptation engine in iDARE is optional and a “floating” component (i.e., it can float between environments to cover both environ- ments or only one of them). Consequently, iDARE can be used to express a wide range of development environments, with dierent interaction level with run-time environments. iDARE classifies tools in development environments based on both their development and run-time responsibilities. iDARE is designed to loosen the tight integration of the 19 Adaptation Layer Run-time Application Synthesis Layer Adaptation Engine Figure 1.5: High-level architecture of PLASMA. development and run-time environments and to support the desirable structural and quality properties of SALEs. To this end, iDARE introduces new classes of run-time tools that can be adapted or detached from the development enviornment at run-time. Design of iDARE leverages the adaptive layered software style. 1.3.3 PLASMA The Plan-based Layered Architecture for Software Model-driven Adaptation (PLASMA), introduced in this dissertation, addresses the issue of disconnected adaptation artifacts and architectural models by automatically synthesizing the key adaptation artifacts from the architectural models. PLASMA comprises three constituent elements: AI planning techniques, architectural models, and the adaptive layered style. In PLASMA, an AI planning technique finds an application plan in order to satisfy the high-level goals of the system, specified by the end-user. To this end, the DMD of the run-time application (i.e., an adaptation artifact) and the system’s high-level goal should be provided to the the planner. Then, the application plan is utilized by PLASMA to determine the behavior and the structure of the run-time application. PLASMA synthesizes the required DMD 20 from architectural models of the application components in the system. Consequently, changes in the architectural models can be automatically reflected on the adaptation logic of the system. As depicted in Figure 1.5, PLASMA is a three-layer instantiation of the adaptive layered style. To plan and adapt the behavior and structure of its adaptation layer, PLASMA fol- lows the same approach (provided above). To this end, meta-components in PLASMA are modeled in an ADL and a DMD of the adaptation domain is synthesized from these models. The adaptation DMD and the high-level goal of the adaptation layer (i.e., adapt- ing the run-time application to its desirable architecture) is provided to an AI planner. Consecutively, an adaptation plan is found and is leveraged by PLASMA to determine the behavior and structure of the adaptation layer. To enhances and customizes this process for the domain of software adaptation, I introduce the 6A approach, in Section 1.3.4. 1.3.4 6A In this dissertation, I also introduce An Automated Adaptable Architectural Adaptation Approach (6A) to support management and adaptation of the adaptation engines them- selves. 6A dynamically synthesizes and automatically adapts a composition algorithm for the declarative approach to software self-adaptation. 6A leverages Hierarchical Task Networks (HTNs) to model and plan the adaptation activities in a system. HTN provides a modeling notation to capture the activities applicable to a software domain in a recur- sive fashion. Composite tasks in an HTN are high-level activities composed from other composite tasks and primitive tasks. The primitive tasks, on the other hand, are low-level tasks that can be directly enacted on a domain. In addition, an HTN captures the state 21 transitions caused by performing the primitive tasks on a domain. Particularly, the com- posite tasks in the domain of software adaptation, include high-level adaptation actions such as system adaptation, resolving component dependencies, and removing crashed components. The primitive tasks in this domain, include basic adaptation actions such as adding or removing a component. The composition algorithm in 6A synthesizes, manages, and utilizes a dynamic adap- tation HTN that captures all adaptation activities applicable to the run-time application. The tasks in the adaptation HTN are divided to two parts: common adaptation ac- tivities and domain-specific adaptation actions. 6A provides the common adaptation activities required by composition algorithms and lets the domain architects provide the domain-specific adaptation actions. 6A composes these two parts in a single adaptation HTN. Beside the custom adaptation actions, adaptation HTN in 6A provides two other variation points: custom optimization cost functions and custom structural constraint. The above domain-specific custom adaptation artifacts are extracted from architectural models of meta-components, provided to 6A. 1.4 Solution Technique This dissertation provides a novel technique to declarative integrated self-adaptive soft- ware environments that resolves the disadvantages of the existing self-adaptive systems discussed in Section 1.2. To this end, 6A is implemented in the context of a software environment. This implementation follows the design of iDARE reference architecture. As depicted in Figure 1.6, the run-time environment in 6A is a four-layer instantiation of 22 Run-time Environment Run-time Application Environment Layer Development Environment Adaptation Layer Synthesis Layer Adaptation Engine Figure 1.6: High-level architecture of 6A, which follows the design of iDARE reference architecture. the adaptive layered style. The top-most layer, the environment layer, is responsible for detaching the development and run-time environments, while the rest of layers monitor and adapt the run-time application. My technique (6A) can be evaluated by the following three hypotheses: Hypothesis 1. Using the dynamically synthesized domain model descriptions, with the same software performance, my technique handles all adaptation scenarios that can be handled by the state-of-the-art declarative approach, and it can handle more component failure scenarios depending on the structure of the Domain Description. Hypothesis 2. Using the dynamically synthesized domain model descriptions, with marginally higher level of application architect’s eort for modeling, my technique im- proves reuse of modeling artifacts compared to the state-of-the-are declarative approach. Hypothesis 3. A dynamic declarative approach can achieve the same level of perfor- mance as the existing static declarative approaches, and requires less domain architect’s 23 eort to be set up and maintained, while it can handle a larger number of run-time adaptation scenarios. 1.5 Contributions The contributions of this dissertation are organized based on the individual elements of my solution. Adaptive layered style 1. An architectural style, called adaptive layered style, to achieve clear separation of adaptation concerns by allowing arbitrary number of meta-layers, when an adaptable adaptation engine is desirable. iDARE 2. A reference architecture for integrated Development and Run-time Environments (iDARE) to study, understand, and improve software development environments in a unified manner, from the perspective of their relation to run-time environments. 3. Classification of software environments based on the interaction level of their development and run-time environments, in the context of iDARE reference archi- tecture. 4. Codification of the existing SALEs’ architectures and their shortcomings in the context of the iDARE reference architecture. 5. Characterization of SALEs in terms of their structural, functional, and quality properties. 24 PLASMA 6. An automated approach to synthesize adaptation artifacts from ADL models to improve self-adaptability of declarative self-adaptive software systems. 7. The plan-based layered architecture for software model-driven adaptation, which allows realization of adaptable adaptation engines. 6A 8. An automated approach to synthesize, adapt, and evolve the self-adaptive behavior for declarative approach to software self-adaptation. 9. A novel approach to automatically synthesize and manage an adaptable compo- sition algorithm. Three aspects of this composition algorithm can be customized at run-time in a unified manner: (1) available adaptation logic and actions, (2) optimization criteria on the adaptation plans, and (3) structural constraints of the target application. 10. The self-adaptability framework to compare the self-adaptability level of various architecture-centric adaptation approaches. 11. A methodology to adaptation engine development life-cycle, which decreases do- main architect eort to provide and maintain adaptation engines in declarative adaptation approach. 25 Chapter 2 Adaptive Layered Software Style In this chapter, I introduce the adaptive layered style, and extend an architectural mid- dleware infrastructure to enable and support implementation of the adaptive layered systems (i.e., systems that follow the adaptive layered style). In this style, system com- ponents are explicitly layered, but the relationship between components in dierent layers is very dierent than the relationship between components in traditional layered software systems. Normally, layering implies that components at a given layer invoke the services of components at the layer below (and are prohibited from invoking the services of components at the layers above). In adaptive layered systems, on the other hand, components at a given layer monitor, manage, and adapt components at the layer below. In this way, each successive layer may: ensure the correct operation of the layer below (fault-tolerance), modify the functionality at the layer below (dynamic update), add new capabilities to the layer below (resource discovery), relocate components to improve quality-of-service properties (redeployment), or 26 implement other self-adaptive mechanisms. Note that the use of adaptive layering does not preclude the use of traditional layering within an adaptive layer. That is, the components that comprise a layer in an adaptive layered system may themselves be organized into layers, such that each layer invokes the services of the layer below. I encapsulate facilities for monitoring, managing, and adapting application software components into meta-level components. Moreover, because meta-level components can themselves be seamlessly introduced, reconfigured, replaced, or removed during system run-time, they can hierarchically or recursively monitor, manage, and adapt other meta- level components. This allows: the creation of adaptive layered architectures of arbitrary depth, the specification of arbitrary system adaptation logic, and the provision of intelligent facilities for constructing adaptation plans on-the-fly. Furthermore, to provide implementation and execution support for adaptive layered systems, I extend an architectural middleware infrastructure, which supports a close correspondence between a system’s architectural design and its implementation. I begin in Section 2.1 with a summary of the key architectural concepts that are the basis of the approach described in this chapter. I then define the three specialized types of meta-level components and explain how meta-level components can be layered to produce hierarchical self-management and self-adaptation. Then, in Section 2.2, I discuss how enhancement of an architectural middleware technology enabled me to 27 faithfully implement the design concepts discussed in Section 2.1, in order to provide implementation and execution support for the adaptive layered systems. 2.1 Approach The basis of my approach is the concept of meta-level components, components that facilitate adaptation and management of application-level components. My approach applies two key enhancements to the traditional usage of meta-level components (i.e., adaptation engines’ components in two-layer adaptive systems): (1) I utilize three dis- tinct, specialized types of meta-level components for the three fundamental activities of a self-adaptive system: sensing, computation, and control. The way that these compo- nents can manipulate other components is restricted by their types. (2) I allow meta-level components to themselves be monitored, managed and adapted by other (higher layer) meta-level components. 2.1.1 Architectural Foundations Architecture-based software adaptation, described in Section 1.1.2, treats a software sys- tem as a collection of components that engage in interaction via explicit communication facilities, i.e., connectors. The use of first-class architectural constructs (i.e., compo- nent and connector) facilitates software adaptation by providing target entities to which atomic adaptation actions, such as component life-cycle operations and link creation, 28 can be applied. Components and connectors are self-contained, decoupled, and inde- pendently deployable, which allows them to be migrated among hosts, be updated or replaced at run-time, or flexibly be reconfigured in the topology of a system. Adaptation and management services in the adaptive layered systems are imple- mented using meta-level components. Meta-level components instantiate, configure, monitor, and deploy application-level components according to application-specific poli- cies or requirements (in prescriptive approach or declarative approach, respectively). The key dierence between meta-level and application-level components is that meta-level components are architecturally aware. That is, meta-level components have access to an internal representation of the system’s current application architecture (e.g., the set of active components, the links among components and connectors, etc.) and are allowed to manipulate that architecture in specific ways. Therefore, architectural awareness allows meta-level components to implement advanced services by manipulating application- level components. For example, meta-level components implement fault-tolerance by replicating application components and dynamic update by replacing components. 2.1.2 Meta-Level Component Types Adaptation mechanisms in software are reactive: they detect, for example, the availabil- ity of new services or the occurrence of a failure, and subsequently plan and execute changes to the running system. Consequently, researchers have proposed approaches to adaptive software in general that embrace the sense-compute-control paradigm [52]. Our approach uses design constructs that correspond directly to the primary activities of reactive systems. We define the following types of meta-level components: 29 Collector components gather data about the components at the layer below. This could include both behavioral data, such as the utilization of resources and the frequency of service invocations, and structural data, such as the topology of component instances and the assignment of components to hardware hosts. The nature of the data collected is application- and scenario-specific. Analyzer components interpret the data produced by collectors to evaluate the adaptation logic and create adaptation plans. Adaptation logic commonly specifies high-level goals, such as the satisfaction of quality-of-service (QoS) requirements (e.g., continuous availability or predictable performance). The construction of adaptation plans that achieve these goals can be quite complex, and analyzer com- ponents may implement sophisticated algorithms to do so. Consequently, adaptive systems may comprise several analyzer components to control the complexity of their adaptation behavior. In Chapter 3, I classify analyzers more precisely based on the specific roles that they commonly play in an adaptation engine. Admin components control and manipulate components at the layer below ac- cording to the adaptation plans produced by analyzers. This control is exercised via management interfaces that implement adaptation operations. All three types of meta-level components are architecturally aware. This architec- tural awareness is achieved by providing each meta-level component with access to a run-time representation of the system’s architecture. Through this representation, meta- level components can access all the sub-elements (components, connectors, ports, etc.) of the architecture of the layer below. Collector components extract information about 30 movement vector Object Follower camera fault new component Reactive Fault Handler Recovery Performance fault tolerance strategy Fault- Tolerance Strategy Selector Application Layer Meta Layer Meta2 Layer Fault Tolerance Deployer Replacement Deployer Fault Recovery Evaluator Replacement Selector Fault Detector Fault Recovery Monitor Motor Actuator Object Follower Camera Driver video Legend Admin Collector Analyzer Application Components Architecture Architectural Reference Meta Architecture Figure 2.1: Notional depiction of an example adaptive layered architecture. the architecture and its sub-elements and package it in a form usable by an analyzer. To this end, collectors install system-specific monitors into the architectural elements in the layer below. These monitors collect data on an element’s interactions, state variables, and exceptions on behalf of their associated collectors. Analyzers check whether infor- mation about the architecture meets conditions that warrant adaptation. Analyzers are also responsible for transmitting component and connector implementations to other (possibly distributed) analyzers if needed. If conditions for adaptation are met, an ana- lyzer produces a set of adaptation instructions. Admins then make modifications to the architecture and its sub-elements according to these instructions. To control the com- plexity of adaptation and management services in a system, each of the sense, compute, and control activities in a system may be implemented in several meta-level component layers, by several meta-level components of each type, in each meta layer. 2.1.3 Meta-Level Component Layering The ability of meta-level components to manage other meta-level components allows for a layered or hierarchical management structure of arbitrary depth. Figure 2.1 shows 31 a conceptual depiction of a system implemented using my approach that demonstrates the power of multi-layer adaptive capabilities. At the bottommost layer, the Application Layer, application components implement a basic robot behavior: object following. The Camera Driver takes raw streaming video from a camera hardware device. The Object Follower interprets the video to locate the relative position of the object being followed. TheMotorActuator directs the robot motor to move in the required direction. At the Meta Layer, meta-level components implement a basic adaptive behavior: reactive fault recovery. The Reactive Fault Handler architecture detects when faults occur and then takes a mitigating action. The Fault Detector monitors the camera and reports failures to aReplacementSelector. TheReplacementSelector determines the best replacement component for the camera based on the adaptation logic. The ReplacementSelector notifies theReplacementDeployer of the new component that is needed, and theReplacementDeployer instantiates the new component. At the Meta2 Layer, meta-level components implement an advanced adaptive behav- ior: fault-tolerance strategy selection. The Fault Tolerance Strategy Selector architec- ture permits the use of dierent fault-tolerance mechanisms for dierent circumstances. For example, if reactive fault recovery is resulting in unacceptable down-time during replacement selection and deployment, the active replication fault-tolerance strategy can be used instead. Active replication ensures that multiple synchronized copies of a component are always available in case one fails. The Fault Recovery Monitor records the amount of system down-time after each fault. The Fault Recovery Evaluator de- termines whether the system availability is acceptable. If reactive fault recovery is not 32 meeting availability requirements, the Fault Tolerance Deployer instantiates a new set of meta-level components that implement active replication. 2.2 Implementation Support To support the implementation of adaptive layered systems described in section 2.1, I extend an existing architectural middleware platform. An architectural middleware provides implementation-level constructs for architectural design abstractions, such as components, connectors, interfaces, and styles, which helps to ensure architectural con- formance. Specifically, I utilized the Prism-MW architectural middleware platform [65] to implement my specialized meta-level components and enforce the constraints of the adaptive layered style. In this section, I summarize the key features of Prism-MW and show how I leveraged, and where necessary, adapted and enhanced those features. 2.2.1 Architectural Constructs Prism-MW is a lightweight middleware platform implemented in Java and C++. Nu- merous mobile and embedded systems [63, 65] have been developed using Prism-MW. Figure 2.2 shows the high-level design of Prism-MW. Middleware core classes are high- lighted in this figure. Brick is an abstract class that represent the architectural building blocks (i.e.,Component,Connector,Architecture, andPort). EachArchitecture object serves as a run-time container for a topology of Component and Connector objects. Components implement application services and data, while Connectors implement 33 IComponent IConnector Abstract Monitor Scaffold Abstract Dispatcher Round Robin Dispatcher Abstract Scheduler FIFO Scheduler Abstract Scaffold Brick Architecture Abstract Topology Extensible Component Component Connector Abstract Handler Extensible Port Extensible Event Event Port IPort Extensible Connector Extensible Architecture IArchitecture #mutualPort Abstract Implementation Event Extensions ... ... Style-specific Handler ... Style-specific Component Behavior Awareness Extensions ... java.io.Serializable ... Application Specific Impl. ... Style-specific Topology ... Style-specific Connector Behavior Port Extensions ... Figure 2.2: UML class design view of Prism-MW. Middleware core classes are high- lighted. interaction-oriented services. Components and Connectors communicate by exchang- ing Events via Ports. Abstract Implementations provide system-specific behavior for Components in a system. Prism-MW supports software management and adaptation by providingExtensible Components and Abstract Monitors. Extensible Components in Prism-MW contain a reference to an Architecture object via the IArchitecture interface, and are able to monitor, manage, and adapt the sub-elements in thatArchitecture. Architectural mon- itoring in Prism-MW is done by a set of customized monitors situated in the architectural elements of a system. Abstract Monitor class provides the required abstractions to facilitate monitoring needs of a system. Monitors in Prism-MW extend the Abstract 34 Dispatcher Scaffold Style Constraints Handler Scheduler Connector Architecture Event Port Component Mutex Factory Semaphore Factory Event Factory File Factory Thread Factory Mutex Abstraction Semaphore Abstraction Device Abstraction Sockect Abstraction Thread Abstraction Semaphore Mutex System Call Interface Device Driver Native Threads Process Management Scocket Library DDL Support I/O Management File System Deployment Monitoring Run-time Analysis Run-time Adaptation Resource Discovery Hardware Advanced Services Architectural Middleware Virtual Machine Operating System Figure 2.3: Layered view of the Prism-MW architecture. Monitor class and are associated through the Scaffold (Scaffold facilitates and coor- dinates a system’s interactions) withBricks, and autonomously monitor their run-time behaviors. Architectures in Prism-MW can enforce stylistic constraints, such as interaction pat- terns, structural rules, and deployment requirements, to produce desirable system qual- ities. For instance, to enforce structural rules, an Extensible Architecture with an Style-Specific Topology, and to enforce interaction patterns Extensible Connectors withStyle-SpecificHandlers can be designed and employed. My approach leverages this capability to enforce the constraints of architectural styles that support self-awareness 35 and self-adaptation, and incorporate those styles’ desirable qualities. Moreover, integra- tion of multiple styles into a single software system is readily supported by Prism-MW. This is an advantage because complex applications commonly employ several architec- tural styles [93]. A complete description of the constructs shown in Figure 2.2 can be found in [65]. Prism-MW’s architectural constructs are the core of a complete layered middleware solution [63], depicted in Figure 2.3, that (1) provides the necessary low-level abstractions for interfacing with the underlying operating system, network, and hardware; (2) imple- ments software systems in terms of design-level constructs, and (3) enables an extensible collection of advanced services, such as resource discovery and fault-tolerance. Several advanced services (shown at the top layer of Figure 2.3) were previously im- plemented using meta-level components [67,69]. While these services provided support for generalized monitoring, management, and adaptation, they cannot themselves be managed and adapted. My proposed technique in this chapter generalizes the notion of meta-level components to allow implementation of adaptive layered systems. 2.2.2 Implementation Support for Meta-Level Component Types To support implementation of meta-level components, I extended the Prism-MW archi- tectural constructs, as shown in Figure 2.4. To this end, theAnalyzer,Admin,Collector, andMetaArchitecture classes, andIMonitor,IArchitectureRead, andIArchitecture Write interfaces are added, and Brick class and IArchitecture interface are modified (see the heavily highlighted elements in Figure 2.4). 36 Brick Architecture Component Abstract Topology Extensible Architecture Meta Architecture IArchitecture IArchitecture Write iMonitor IArchitecture Read Admin Analyzer Collector Figure 2.4: UML class design of the extended Prism-MW. Recall that meta-level components gain architectural awareness through access to an internal representation of the system’s current architecture. This representation exists natively in Prism-MW applications in the form ofArchitecture objects. Dierent meta- level components require dierent level of access to an Architecture. Consequently, to control the access of meta-level components, the IArchitecture interface in the ex- tended Prism-MW is composed from theIArchitectureRead andIArchitectureWrite interfaces, which separate the read and write methods of theIArachitecture interface. Because Collectors are only permitted to gather information, they hold a read-only reference to the Architecture (i.e., via IArchitecture Read interface), which prevents them from modifying the architecture. Analyzers also hold a read-only reference to the Architecture, which allows them to retrieve component implementations and configu- rations for transmission to other distributed Analyzers. Admins are the only meta-level components that hold a readable and writable reference to the Architecture (i.e., via IArchitecture interface). 37 Application-specific monitors in the original design of Prism-MW are associated with Brick instances (Brick is the abstract base class of all Prism-MW architectural constructs; recall Figure 2.2). Consequently, they have limited monitoring capabilities. On the one hand, theAbstractMonitor can only monitor the event communications. On the other hand, design of Prism-MW allows several Bricks to share a single Scaffold, which limits the monitoring of the individual Bricks. To provide a wide range of monitoring capabilities to adaptive layered systems, I provide the IMonitor interface. In the extended Prism-MW, a monitor is utilized by a Collector component and is installed into aBrick. IMonitor interface enables (1) monitoring of events, (2) detection of run-time exceptions, and (3) monitoring ofBrick’s state variables. Collectors gather all information about the Architecture necessary to evaluate adaptation logic and create adaptation plans. Application developers utilizeCollectors by implementing a set of monitors, each of which implements the IMonitor interface. Monitors define methods that capture data of interest and transmit it back to their associatedCollector. Collectors receive, store, aggregate, filter, and package the data for transmission toAnalyzers. Analyzers evaluate the adaptation logic based on monitoring data and construct adaptation plans. Application developers implement domain-specific algorithms to evaluate adaptation logic and construct plans. The Analyzer class may be extended further to provide customized support for the prescriptive and declarative adaptation logic classes (recall Section 1.1.6). In a distributed system, multiple Analyzers will likely need to exchange information about a system’s state and collaboratively determine system-wide adaptation plans. Analyzers are responsible for requesting and retrieving 38 the binary implementation of a software component when an adaptation plan requires a component to be transmitted across hosts. Admins execute the adaptation plans created byAnalyzers and utilize theIArchite- cture, IComponent, IConnector, and IPort interfaces to manipulate the corresponding Prism-MW architectural constructs. For example, the IArchitecture interface imple- ments methods to add and remove components, while the IComponent interface imple- ments methods to add and remove ports. To destroy a component, anAdmin component disconnects all ports of the component and removes the component from the architecture. 2.2.3 Implementation Support for Meta-Level Component Layering To support the meta-level component layering for adaptive layered systems, I extended the Prism-MW by adding theMetaArchitecture construct. As depicted in Figure 2.4, the MetaArchitecture class extends theExtensibleArchitecture. Consequently, stylistic topology constraints can be designed and applied to Meta Architectures. Moreover, theMetaArchitecture class has a reference to theArchitecture that resides in the layer below. In distributed applications developed using Prism-MW, each host in the system exe- cutes one or moreArchitecture objects, each of which encapsulates a set of components. In adaptive layered systems, the components on each host are separated into distinct Prism-MW Architectures corresponding to each layer. The application-layer architec- ture contains application-level components, while the Meta Architectures contain col- lectors, analyzers, and admins. Each meta-level component of aMetaArchitecture pos- sesses a reference to the sameArchitecture that is referenced by itsMetaArchitecture. 39 Separating layers into distinct Architectures provides the following benefits: 1. Components can be easily prevented from interacting with components in other layers, except through prescribed mechanisms, thus preserving architectural in- tegrity. 2. Meta-level components are only given access to the monitoring and control in- terfaces of components at the layer directly below, helping to ensure that system adaptation only occurs in predefined, controlled ways. 3. The components within each layer are insulated from failures and unaware of adaptations taking place in other layers. 4. Dierent architectural styles can easily be used within each layer. For example, components within the application layer might use a traditional layered architec- ture, while components in the meta-layer interact via peer-to-peer mechanisms. Interactions among components in an adaptive layered system are not restricted by physical host boundaries. First, a meta-level component can communicate with other meta-level components on other hosts that reside at the same logical layer. Interactions among meta-level components within a layer are analogous to the interactions in the sense-compute-control paradigm. For example, a Collector on one host can report monitoring data to an Analyzer on another host, provided both are contained in the same layer. Second, a meta-level component can adapt components on other hosts that are contained in the layer below the meta-level component’s layer. For example, a Meta2 Layer component can adapt Meta Layer components residing on other hosts. 40 movement vector Robotic Application remaining energy adaptation plan Energy Optimizer Application Layer Meta Layer Admin Energy Analyzer Energy Collector Motor Actuator Robot Driver Robot State Monitor robot state Legend Admin Collector Analyzer Application Components Architecture Architectural Reference Meta Architecture Figure 2.5: Energy-aware robotics system. Energy Monitor Component Energy Requirement Energy Admin Energy Collector Robot State Monitor IPlan IRequirement Meta Architecture Energy Optimizer Robot Driver Motor Actuator iMonitor Admin Collector Architecture Robotic Application Declarative Analyzer Analyzer Energy Analyzer Abstract Implementation Figure 2.6: UML class design for the energy-aware robotics system. 2.2.4 Sample Adaptive Layered System To illustrate the design of the extended Prism-MW, I present a (limited) declarative adaptive layered system, the energy-aware robotics system, as depicted in Figure 2.5. The Robotic Application architecture performs some generic robotic activities. The Robot State Monitor collects the robots status from its embedded sensors. The Energy 41 public interface IRequirement{ public boolean isTriggered(CollectorData data); public Plan computeAdaptationPlan(IArchitecture arch); } public class EnergyRequirement implements IRequirement { private int THRESHOLD = 500; ... public boolean isTriggered(CollectorData data) { if (data.getType().equals(CollectorDataTypes.ENERGY_TYPE)){ Integer currentEnergy = (Integer) data.value(); return currentEnergy < THERESHOLD; } else { return false; } } public Plan computeAdaptationPlan(IArchitecture arch) { return DeploymentCalculator.computeOptimizedPlan (OptimizationalGoal.SAVING_ENERGY, arch); } ... } Figure 2.7: Implementations for the (top) IRequirement and the (bottom) Energy Requirement from example in Figure 2.6. Collector collects the energy status from the application layer, and notifies the Energy Analyzer. Then,EnergyAnalyzer evaluates theEnergyRequirement, and if it was vio- lated, calculates an adaptation plan and sends it to the theEnergyAdmin to process and execute. Figure 2.6 shows the UML design of the energy-aware robotics system. To support this application, I extended theAnalyzer class to create theDeclarativeAnalyzer. This meta-level component utilizes IRequirement and IPlan interfaces to provide a unified approach to specify requirements that should be satisfied by a system, and the adapta- tion plans that should be provided to an Admin component, respectively. The Energy Collector, Energy Analyzer, and Energy Admin extend the Abstract Implementation 42 public class EnergyAdmin extends AbstractImplementation { ... private void removeComponent(IComponent comp) { List<IPort> ports = comp.getPorts(); for (IPort aPort :ports) { arch.unweld(aPort, aPort.getMutualPort()); } arch.remove(comp); } public void Execute(Plan adaptationPlan) { ... } Figure 2.8: Excerpt for theEnergyAdmin implementation from example in Figure 2.5. class to provide the system-specific behavior for theCollector,DeclarativeAnalyzer, andAdmin components in theEnergyOptimizer architecture, respectively. TheDeclarativeAnalyzer requires each application-specific requirement to imple- ment the IRequirement interface depicted at the top of Figure 2.7. After receiving data from theEnergyCollector, theEnergyAnalyzer checks whether a requirement was vio- lated, and accordingly initiates the computation of an adaptation plan. For example, the EnergyRequirement depicted in Figure 2.7 evaluates the remaining energy of the robot after receiving the remaining energy measurement in a data object of type ENERGY_TYPE. If the remaining energy is below a user-specified threshold, the requirement violation evaluates to true. As a consequence, the Energy Analyzer requests an adaptation plan from theEnergyRequirement, which initiates the calculation of an optimal deployment using the technique developed in [64]. Figure 2.8 shows an excerpt of theEnergyAdmin component in Java that can execute adaptation plans provided by theEnergyAnalyzer. As one of its internal methods, this admin component contains a method to remove a component from the architecture of the 43 layer below. In Prism-MW, a component can communicate with other components and connectors only if one of its ports is welded to a port of another component or connector. Therefore, before the Energy Admin component can remove a component, it needs to unweld all ports of the component. After unwelding all ports, it removes the component from the architecture as depicted in Figure 2.8. 44 Chapter 3 iDARE Reference Architecture Software development environments are intended to augment or automate a range of critical software development activities, from requirements elicitation and negotiation, modeling, and design, through system implementation, testing, debugging, and deploy- ment, to maintenance and evolution. They also help to coordinate ideas, artifacts, and resources involved with a software system. Moreover, some development environments support Application Life-cycle Management (ALM) tools and processes, intended to co- ordinate software life-cycle activities through enforcement of processes, management of artifacts’ relationships, and reporting on development progress. Despite some notable exceptions (e.g., Interlisp [94]), a traditional view of develop- ment environments have tended to treat a system’s development-time separately from its run-time. This is useful in that it provides a clean separation between the environment in which engineers operate to construct the system (i.e., development environment), and the environment in which the system operates to help solve problems for end-users (i.e., run-time environment). 45 The view of decoupled development and run-time environments is short-sighted, however, in that the key to both environments is the system itself. In fact, when the system needs to be updated after it is in operation, the separation of the development and run-time environments requires that the system be (sometimes physically) relocated from one environment to the other, and back. Although many kinds of simpler updates can be made to the system while in operation, more sophisticated updates typically require that the system undergo careful maintenance and evolution in the development environment and then be re-deployed to the run-time environment. However, relocation of systems that are in operation is undesirable in some cases and unnecessary in oth- ers. For instance, growing numbers of systems have non-functional requirements that preclude the long turnaround time of the traditional maintenance approach. Moreover, many systems have to regularly adapt to changes in their execution contexts, while any changes to the systems themselves must be carefully planned, analyzed, and staged in their development environment, and eected in their run-time environments. Such scenarios suggest that development and run-time environments need not (and, in some cases, should not) be completely decoupled. The idea of coupling the development and run-time environments has been employed for both traditional and modern systems. Certain traditional development environments that are made to support the exploratory style of programming, such as Interlisp [94], Smalltalk [41], Cedar [89], and Rational Environment [6], are fully integrated with their accompanying run-time environments. These dynamic environments are frequently used by AI researchers and allow users to experiment with software prototypes [21]. 46 Run-time activities, such as executing and altering running programs, are supported by these environments. More recently, a class of development environments for self-adaptive software sys- tems has emerged that performs mixed development-time and run-time activities. Self- adaptive systems must adjust their structure and behavior according to changing run- time conditions and software evolution. Self-adaptive systems require run-time tools to calculate, validate, and perform adaptation. In some self-adaptive systems, such as PESOI [96], Rainbow [19], PBAAM [38], SADE [29], and ArchStudio [23], these tools are associated with both development-time and run-time activities and are implemented as development environment plug-ins. Consequently, the development and run-time environments of these systems are integrated. I call such integrated environments Self- Adaptive Life-cycle Environments (SALEs). Given the growing need for interaction between development-time and run-time as- pects of systems, it is important to understand development and run-time environments and their relationship. To this end, I have studied many environments and classified this relationship into three general levels: no interaction, limited co-ordination, and full inte- gration. I also categorized several development environments based on their supported level of this relationship, as well as on their programming paradigm. In particular, I considered traditional, aspect-oriented, multi-agent, service-oriented, and component- based programming paradigms. As a result of my study, I present iDARE, a reference architecture for integrated Development And Run-time Environments, in this section. iDARE is used to codify the characteristics of and dierentiate among existing development 47 environments. I use iDARE to codify the architectures of a number of widely used soft- ware development environments. I particularly focus on SALEs and characterize them in terms of their functional, structural, and quality properties, especially the properties specific to the SALEs’ run-time activities. I leverage my characterization of SALEs to define in detail the iDARE sub-architecture pertaining to system adaptation engines. In turn, I use iDARE to capture, dierentiate, and highlight several shortcomings of existing SALEs. The iDARE reference architecture captures a broad range of software development environments’ characteristics and consequently comprises many constructs (i.e., items in the legend of Figure 3.9). To make it easier for the reader to follow my arguments and to understand iDARE, I gradually introduce the reference architecture’s constructs as they pertain to dierent categories of development environments. The complete iDARE architecture is then presented in later sections. The rest of this section is organized as follows. Sections 3.1, 3.2, and 3.3 describe dif- ferent classes of environments based on their relationship with run-time environments. For each class, I provide the architecture of the environment in terms of the iDARE constructs sucient to describe each environment; these constructs comprise dierent subsets of the iDARE reference architecture. Section 3.4 specifically studies the design of several existing SALEs and also provides their architectures in terms of the iDARE constructs. Section 3.5 identifies the desirable structural and quality properties of SALEs that pertain to the requirements of the self-adaptive applications under their control. 48 Development Environment Run-time Environment Run-time Application Legend Environment User Interface Tool Artifact Processing Tool Tools Application Component Repository Management Tool Figure 3.1: Common architecture for standalone development environments. Based on the desirable properties identified for SALEs in Section 3.5, Section 3.6 pro- vides the complete iDARE reference architecture and uses it to identify and discuss the shortcomings in the designs of existing SALEs. 3.1 Standalone Development Environments In this class of software environments, system’s development-time and run-time activi- ties are separated into disjoint development and run-time environments. These environ- ments have no interaction after the system is deployed. Figure 3.1 shows the common architecture for environments in this class in terms of the iDARE constructs. In the case of software maintenance and evolution, the system needs to be taken o-line, relocated to the development environment, and then re-deployed back to the run-time environment. Development environments run, integrate, and coordinate tools required for software development activities. As shown in Figure 3.1, I classify development environment tools (i.e., iDARE reference architecture tools) into the following three types: 49 Repository management tools are used to manage, explore, share, and control multiple versions of software artifacts in a software system under development. Artifact processing tools provide support to analyze, validate, verify, and convert software artifacts. Code generators, compilers, and debuggers are examples of processing tools. User interface tools allow users to create, manipulate, and visualize software artifacts and control other development environment tools. More complex tools can be composed from multiple types of basic tools (e.g., the Update Interface tool in Figure 3.2). Some examples of standalone environments classified based on their programming paradigms are as follows: Traditional programming. IntegralC [84], a commercial integrated programming environment for C, is an example environment in this class. IntegralC provides an interactive environment with a syntax checking editor, a compiler, and a debug- ger. Unix/PWB [28], Istar [30], Rigi [71], OOT [66], VMX VAXset [26], PCTE [15], CAIS [72], Aspect [18], SoftBench [17], DSEE [55], Inscape [79, 80], and SLCSE [88] are other examples of traditional standalone development environments. Multi-agent system programming. AgentBuilder 1 [82, 83] is an integrated en- vironment that provides means to analyze, design, develop, debug, and deploy multi-agent systems. 1 http://www.agentBuilder.com 50 Development Environment Update Interface Feedback Interface Run-time Environment Adaptation Engine Run-time Application . . . Monitor Admin Legend Environment User Interface Tool Artifact Processing Tool Tools Run-time Roles Repository Management Tool Collector Admin Adaptation Component Application Component Figure 3.2: Common architecture for life-cycle development environments. 3.2 Life-cycle development environments In this class of software environments, although development and run-time environ- ments are disjoints, they co-operate in limited ways. Figure 3.2 depicts the common architecture of environments in this class in terms of the iDARE constructs. Develop- ment environments in this class provide specific run-time tools to deploy, run, monitor, and adapt the run-time environment. Note that these activities are not supported by the standalone environments, discussed in the previous section. I call this class of environ- ments life-cycle development environments, because they support all stages of the software life-cycle. The iDARE reference architecture classifies the run-time tools in development envi- ronments based on their roles. Run-time tools in life-cycle environments usually have following two roles: 51 Collectors gather and aggregate data about the run-time applications. This could include data pertaining to run-time application’s behavior (e.g., state of a compo- nent), quality measurements (e.g., throughput of a link), and fault monitoring data. Collectors are usually artifact processing tools. If a collector makes the monitored data available to users, it is also a user interface tool. Admins deploy, run, and adapt run-time applications. Admins are artifact process- ing tools. Additional run-time roles are introduced in Section 3.3.2, as they become relevant for the description of SALEs. The common architecture of life-cycle environments reveals that both development and run-time environments in this class provide tools to monitor and adapt the run-time application. That is, both development and run-time environments provide components in the roles of collector (i.e., the Feedback Interface and the Monitor components in Figure 3.2) and admin (i.e., the Update Interface and the Admin components in Figure 3.2). This is a direct consequence of environment separation in this class of software environments. More advanced development environments like SALEs, on the other hand, avoid this redundancy by overlapping the development and run-time environments. Some examples of life-cycle environments classified based on their programming paradigms are as follows: Traditional programming. Dynamic Modification System (DYMOS) [20] is a tra- ditional programming system capable of replacing run-time code units while the 52 application is running. Conic [60], Argus [13], and Reconfigurable PolyLith [45] are traditional development environments for distributed applications that support run-time reconfiguration and dynamic update of software modules. Aspect-oriented programming. The JBoss Developer Studio is an Eclipse-based toolset which provides development and management support for dierent JBoss platforms. JBoss AOP 2 supports design, implementation, and deployment of aspect-oriented architectures. Particularly, JBoss AOP is extended in [49] to support safe dynamic adaptation of the run-time application. Multi-agent system programming. Java Agent Development Framework (JADE) [10] provides the development support for multi-agent systems. JADE’s support for monitoring and management of the run-time applications is provided through environment agents. Multi-Agent Environment (MAGE) [86] is another environ- ment for multi-agent systems that lets the user start and kill agents in the run-time environment, send messages to the agents, etc. Zeus [77], Jason [14], and Visual Soar [57] are other life-cycle environments for multi-agent systems. Service-oriented architecture programming. IBM’s SOA Foundation Architec- ture [43], Websphere, is an environment for service-oriented architectures. It pro- vides a comprehensive set of services and tools to support the integration of diverse business services. Websphere’s monitoring tool can return the run-time informa- tion into the development suite. Microsoft Whitehorse Project [97] and JBoss 2 http://www.jboss.org/jbossaop/ 53 Development Environment Run-time Environment Run-time Application Execution Tool Legend Environment User Interface Tool Artifact Processing Tool Tools Run-time Roles Repository Management Tool Collector Admin Adaptation Component Application Component . . . Figure 3.3: Common architecture for exploratory programming environments. Developer Studio 3 (support for JBoss Enterprise SOA platform) are other life-cycle environments for service-oriented software development. Component-based software programming. Archstudio 2.0 [53] is an environment for component-based systems that provides tools to connect to a run-time environ- ment and change its architecture. 3.3 Integrated development and run-time environments In this class of software environments, development and run-time environments are fully integrated. I identify two dierent subclasses of integrated environments: environments for exploratory programming and SALEs. 3 https://devstudio.jboss.com/updates/5.0/soa-tooling/ 54 3.3.1 Environments for Exploratory Programming Style Some traditional development environments, such as Interlisp [94], Smalltalk [41], Cedar [89], and Rational Environment [6], support the exploratory style of programming. This style allows rapid generation of the eventual software application in increments, while the programmer is experimenting with the prototypes of that application. In this type of systems, the development environment and the run-time environment are one and the same. Consequently, there is no need to relocate the system from one environ- ment to the other, i.e., there is no deployment stage in the system’s life-cycle. Figure 3.3 depicts the common architecture for exploratory programming environments in terms of the iDARE constructs. 3.3.2 Self-adaptive Life-cycle Environments SALEs provide development-time and run-time tools to support all stages in the life-cycle of a self-adaptive software system. In particular, they enhance and automate software maintenance and adaptation stages. Unlike exploratory programming environments, run-time applications in SALEs run in an environment that is separate and dierent from the development environment, and therefore need to be deployed. SALEs are especially interesting as they form a growing class of emerging development environments. This section and Section 3.4 outline the outcome of my study of the architectural designs of several existing SALEs. In this section, I focus on the common design of the existing SALEs, while in the next section I provide the individual designs of a number of existing SALEs and their architectural elements. Later, in Section 3.5, I provide a number of 55 Development Environment Adaptation Engine Run-time Environment Run-time Application . . . Run-time Adaptation Component Legend Environment Repository Management Tool User Interface Tool Artifact Processing Tool Collector Adaptation Logic Evaluator Adaptation Logic Manager Architectural Model Manager Admin Tools Adaptation Component Application Component Run-time Roles Run-time Software Modules Architectural Modeling Artifacts Adaptation Logic Artifacts Figure 3.4: Common architecture for SALEs. desirable structural and quality properties of SALEs that are neglected in the designs of the existing SALEs. Subsequently, in Section 3.6, I leverage my architectural study and the desirable properties of SALEs to enhance my design of the iDARE reference architecture. Adaptation engines in SALEs are implemented as a software environment’s run- time tools. Consequently, the processes of artifact design, implementation, verification, validation, deployment, evolution, and adaptation can be orchestrated in the same en- vironment across dierent development-time and run-time tools. SALEs provide tools and user interfaces to design and control the adaptation behavior of a system. Design of 56 SALEs brings the benefits of tool integration in development environments [95] to self- adaptive systems. Figure 3.4 provides the common architecture of the existing SALEs, in terms of the iDARE constructs. I derived this architecture by studying and comparing several existing SALEs. The architecture identifies possible tools that lie at the intersec- tion of the development and run-time environments in SALEs and characterizes those tools by their type and run-time role. Beside the development-time artifacts (e.g., requirements, design, and code artifacts), SALEs manage three additional run-time artifacts: architectural models, adaptation logic, and run-time software modules. Several approaches to software self-adaptation leverage an architectural model of the run-time application, comprising a high-level view of the application’s components, connectors, and their interconnections. Architectural models may also provide parameters to manage and reflect the collected data from the run- time application. In order to separate the adaptation logic of a system from the tools that enforce that logic, SALEs utilize certain adaptation logic artifacts. These artifacts are either in the form of adaptation policies or system requirements. An adaptation policy is a set of condition-action rules that determines behavioral and structural system modifications when software adaptation is necessary. System requirements, on the other hand, determine the desirable functional and quality properties that should be achieved and maintained at all times by a self-adaptive system. Finally, SALEs manage run- time software modules as building blocks to deploy and adapt run-time applications. Adaptation engines in SALEs may update (add, remove, or replace) run-time modules in a host or ship them between hosts. 57 SALEs provide tools to create, maintain, and leverage run-time artifacts. In Figure 3.4, tools that manage the development-time aspects of run-time artifacts (e.g., editors) are depicted on the left side of the development environment. Tools that manage the run- time aspects of run-time artifacts, namely artifact repositories and adaptation engine tools, are depicted at the intersection of the environments. Finally, in addition to the admin and collector roles introduced in Section 3.2, tools in the adaptation engines of existing SALEs perform the following additional roles: Adaptation logic evaluators evaluate the adaptation logic against the monitored data and architectural models, and compute the required adaptation actions. Adapta- tion logic evaluators are artifact processing tools. Architectural model managers handle architectural model artifacts. They synchro- nize structure and parameters of application models with the run-time application. They also analyze models for consistency and compatibility with architectural constraints and styles. Model managers may also validate adaptation actions by testing them against the architectural models, before the actions are applied to the run-time applications. Architectural model managers are usually artifact process- ing tools. However, they may also be user interfaces and visualize architectural models or certain aspects of run-time adaptations. Adaptation logic managers handle the adaptation logic artifacts discussed above. They analyze the adaptation logic for consistency (e.g., check whether adaptation policies contradict or cancel each other’s eects). They also adjust the adaptation logic based on the run-time context, adaptation history, or user preferences and 58 inputs. Adaptation logic managers are usually artifact processing tools. However, they may also be user interfaces and let users alter the set of active adaptation logic artifacts. 3.4 Designs of the Existing SALEs This section highlights the key results of my extensive study of SALEs for dierent programming paradigms. Here, I outline the designs and the architectures of four SALEs out of several existing SALEs that I studied. For each system, an overview of the run-time tools and tool interactions is provided. Moreover, the types and roles of tools in each SALE are reflected in its architecture. The overall process of capturing and mapping architecture of SALEs in iDARE in- volves the following nine steps: 1. Identify software artifacts managed by the SALE. 2. Categorize software artifacts into development-time and run-time artifacts. Devel- opment-time artifacts are not directly used with the run-time application and do not aect its behavior. Software requirements, design artifacts, and code modules are development-time artifacts. Run-time artifacts, on the other hand, are executed, evaluated, and/or updated at run-time. As explained in Section 3.3.2, iDARE recognizes three categories of run-time artifacts: architectural models, adaptation logic, and run-time software modules. 3. Locate run-time repository management tools. Run-time artifacts and artifacts that are both development-time and run-time artifacts (e.g., architectural models) are 59 managed by the repository management tools. These repositories belong to the intersection of the development and run-time environments in Figure 3.4. 4. Identify user interface and software processing tools of the SALE. 5. Locate run-time user interface and software processing tools. These tools monitor, manage, update, and adapt the run-time artifacts and/or the run-time application. These tools belong to the intersection of the development environment and the adaptation engine in Figure 3.4. 6. Locate run-time tools that are not part of the development environment. These tools are usually created and deployed at run-time. These tools are marked as Run-time Adaptation Components in Figure 3.4 and may have any run-time role. 7. Assign run-time roles to the run-time tools (i.e., the tools located in the adaptation engine). The responsibilities of run-time roles in SALEs are provided in Sections 3.2 and 3.3.2. Note that a run-time tool may take more than one run-time role. 8. Determine tool interactions. 9. Validate the architecture. The correctness of the architecture can be tested by checking the interactions of the repositories with the user interface and artifact processing tools, and the interaction of adaptation engine tools with the run-time application. For example, adaptation engine tools may only interact with the run-time artifact repositories and the run-time application. To make this process clearer for the reader, I briefly explain the process in the context of RAIDE, the first environment studied in this section. 60 Probe to Gauge Mapper Run-time Environment Development Environment (Eclipse) Adaptation Engine Run-time Application . . . Architecture Layer Translation Infrastructure Strategies, Tactics Probes, Gauges, Effectors Biz Objectives (Profiles, Preferences) Architectural Models (Properties, Constraints) Rainbow Control Console Strategy Executer Gauges Stitch Editor YaML Utility Editor Legend Environment Repository Management Tool User Interface Tool Artifact Processing Tool Collector Adaptation Logic Evaluator Adaptation Logic Manager Architectural Model Manager Admin Tools Adaptation Component Application Component Run-time Roles Acme Studio Customization Bus Rainbow Delegate Host 1 Probes Probes Effectors Effectors Gauges Gauges Rainbow Delegate Host n Probes Probes Effectors Effectors Gauges Gauges Architecture Evaluator Rainbow Customizer Adaptation Manager Model Manager Adaptation Operation Mapper Figure 3.5: Architecture of RAIDE in terms of the iDARE constructs. 3.4.1 RAIDE Rainbow Adaptation Integrated Development Environment (RAIDE) [19] is a component-based SALE for the Rainbow [33] approach to software adaptation. Rainbow manages run-time applications based on their underlying architectural styles. RAIDE’s infrastructure is highly customizable and is able to handle dierent software systems in dierent execution contexts. I used the above process and captured the architecture of RAIDE in iDARE as shown in Figure 3.5. This figure depicts the identified elements, their locations, and their interactions. 61 Adaptation Engine (c2.fw Middleware) Run-time Environment Development Environment (Eclipse) Java Code Java Run-time Java Development Tooling (JDT) xDAL 2.0 Configuration Graph xDAL 2.0 Arch Constraints xDAL 2.0 Adaptation Strategies xDAL 2.0 Architectural Models Run-time Application (c2.fw Middleware) . . . Architecture Runtime Manager Architecture Constraint Manager (ACM) Architecture Adaptation Manager (AAM) Architectural Model Manager (c2.fw Middleware) Analysis and Consistency Checking (ArchLight) Graphical xDAL Editor (Archipelago) Architectural Runtime Configuration Manger (ARCM) Legend Environment Repository Management Tool User Interface Tool Artifact Processing Tool Collector Adaptation Logic Evaluator Adaptation Logic Manager Architectural Model Manager Admin Tools Adaptation Component Application Component Run-time Roles Figure 3.6: Architecture of PBAAM in terms of the iDARE constructs. The following run-time artifacts are identified, categorized, and located by the map- ping process. They reflect the run-time application’s properties and determine the adap- tation engine’s behavior. Architectural Models are both development-time and run-time artifacts. They in- clude models of components and connectors, and their (run-time) properties, rela- tionships, and constraints. In Rainbow, the run-time application and its architec- tural model are maintained synchronized. Probes and Gauges monitor the run-time application and pre-process (e.g., aggre- gate) the collected data. The collected data is used to update the properties of the architectural model. 62 Strategies and Tactics determine the adaptation conditions and adaptation actions associated with each condition. Business objects determine the end-user’s preferences on dierent quality aspects of the run-time application. The following run-time tools are identified, categorized, and located by the mapping process. These tools leverage the run-time artifacts to manage and adapt the application at run-time. Model Manager captures the architectural model of the run-time application and provides access to it. It updates the system model with the collected data from the running system. Architecture Evaluator manages the architectural constraints and the analyses that pertain to the run-time application and its architectural style. It evaluates the architectural constraints against the architectural model, and flags constraint violations. Adaptation Manager receives the constraint violations, evaluates the available adaptation strategies against them, and chooses required adaptation tactics. Strategy Executor analyzes the selected tactics, extracts the required adaptive operations, and enacts them on the run-time application. RainbowCustomizer tailors the adaptation components to the needs of a system’s style and execution context by installing reusable run-time artifacts. 63 Rainbow Control Console allows the user to perform certain run-time tasks (e.g., deploying Probes) to configure the system and monitor the activities of run-time components. I also identified and located two mapper components in theTranslationInfrastru cture. These tools belong to the adaptation engine and run independently from the development environment. YaML,StitchEditor,AcmeStudio, andUtilityEditor, on the other hand, are identified and located as development environment tools. They are not required at run-time and do not directly and automatically aect the behavior of the run-time application. 3.4.2 PBAAM Policy-Based Architectural Adaptation Management (PBAAM) [36] is a component- based SALE. Figure 3.6 depicts the architecture of PBAAM in terms of the iDARE con- structs. TheArchitectureRun-timeManager (ARM) in PBAAM monitors the run-time ap- plication and sends the monitoring data to theArchitectureAdaptationManager (AAM). AAM tests the adaptation policies against the monitored data. If any policy is triggered,AAM informs theArchitectureConstraintManager (ACM) about the proposed changes by the triggered policy. In response, ACM evaluates the proposed changes against the architec- tural constraints to ensure the consistency of the system after applying the changes. AAM sends the changes to theArchitectureModelManager (AMM), which applies the changes to the architectural model of the system and informs the ARM. ARM enacts the changes to synchronize the run-time application with the architectural model. The Architecture Run-timeConfigurationManagement (ARCM) stores all historical adaptation information 64 Run-time Environment Development Environment (Eclipse) Run-time Application Adaptation Engine Fault-Tolerant Communication Backbone . . . Dynamic Workflow Spec Service Analysis Service Monitor Validation & Verification Services Modeling Service Dynamic (Re-)Configuration Managers (Assembling & Deployment) Service Repository Architecture, Process, and Policy Model Repository Legend Environment Repository Management Tool User Interface Tool Artifact Processing Tool Collector Adaptation Logic Evaluator Adaptation Logic Manager Architectural Model Manager Admin Tools Adaptation Component Run-time Roles Application Service Application Service 1 Application Service n Figure 3.7: Architecture of PESOI in terms of the iDARE constructs. in a configuration graph model and visualizes them. ARCM lets the architect roll back or forward to dierent architecture configurations when required. 3.4.3 PESOI Process-Embedded Service-Oriented Infrastructure (PESOI) [96] is a SALE for service- oriented architectures. The architecture of PESOI captured in terms of the iDARE con- structs is provided in Figure 3.7. TheModelingService in PESOI supports modeling of processes, policies (adaptation logic), and architecture of an application. The Dynamic Configuration Manager assembles and deploys the target application based on the the system’s architectural model. The run-time application is monitored and evaluated against performance and reliability requirements. When an application policy is trig- gered, the Dynamic Workflow Specification Service modifies the architecture of the 65 Adaptation Engine Run-time Environment Development Environment (Eclipse) Run-time Application (Extended JADE) Java Development Tooling (JDT) Agent 1 . . . Agent n Software Monitor Java Run-time Strategies Java Run-time Roles Java Run-time Agents Strategy Compiler SADL Strategy Programs Software Agent Deployment Tool SADL Editor Legend Environment Repository Management Tool User Interface Tool Artifact Processing Tool Collector Adaptation Logic Evaluator Adaptation Logic Manager Architectural Model Manager Admin Tools Adaptation Component Run-time Roles Figure 3.8: Architecture of SADE in terms of the iDARE constructs. application. The system architect can also use the Dynamic Configuration Manager to manually alter the architecture. All models and model changes are verified and validated before they are reflected in the operational environment. 3.4.4 SADE Self-adaptive Agent Development Environment (SADE) [29] is a SALE for multi-agent systems. SADE agents dynamically adapt their behavior by choosing dierent roles in a multi-agent organization. SADE provides a Self-Adaptation Description Language (SADL) to describe the adaptive logic of an application in the form of adaptation strate- gies. Figure 3.8 depicts the architecture of SADE in term of the iDARE constructs. SADE provides tools to develop, compile, deploy, configure, monitor, and adapt multi-agent applications. TheStrategyCompiler compiles the SADL strategies into run-time strat- egy classes. The Deployment Tool deploys the run-time classes of roles, agents, and strategies into the run-time platform. It can also load the adaptation strategies into the 66 agents at run-time. Finally, theSoftwareMonitor reports the state and run-time data of the agents to the software maintainer. 3.5 Desirable Structural and Quality Properties of SALEs SALEs are intended to manage systems with high availability and dependability re- quirements, namely self-adaptive software systems. The development and run-time environments in existing SALEs are tightly integrated. Therefore, the availability and dependability of run-time applications in existing SALEs are highly dependent on the structural and quality properties of their development environments. For that reason, in this section, I first discuss those conditions and SALE attributes that aect application availability and dependability. Then, I identify the structural and quality properties of a SALE that contribute to the desirable quality properties of the self-adaptive application under its control. Because of the tight integration of the development and run-time environments in existing SALEs, unavailability of the development environment in a SALE essentially results in the unavailability of the application under its control. A development environ- ments in a SALE may become unavailable due to tool failures, maintenance activities, and lack of resources. First, the failure of a development environment tool may result in the failure of the entire SALE. Even if a SALE does not fail because of a constituent tool’s failure, it may still need to be restarted to recover from that failure. Moreover, the development environment in a SALE may need to be brought down for maintenance of its infrastructure or tools. In Section 3.5.2.1, I identify and classify several unanticipated 67 run-time conditions in which a SALE’s run-time tool set needs to be altered. Finally, lack of memory or computational resources may prevent the execution of the development environment in a SALE. In circumstances when the development environment and the run-time application of a SALE are distributed on dierent hosts, scarcity of the commu- nication resources may result in the unavailability of the development environment. Moreover, as Figure 3.4 shows, the operation of the run-time application in a SALE is coupled with the operation of the SALE’s adaptation-engine, and therefore with the operations of its development environment. Consequently, the dependability of the run-time application of a SALE is influenced by the attributes and design of both its adaptation engine and its development environment. The rest of this section identifies the desirable structural and quality properties of a SALE that improve the availability and dependability of its run-time application. In Section 3.6, I utilize these desirable properties to complete the design of the iDARE reference architecture. 3.5.1 Desirable Structural Properties The adaptation and application concerns of a SALE need to be separated. To achieve this, the run-time environments in SALEs need to be divided into two key components: adaptation engine and run-time application. As a result, the adaptation engine structure and behavior can be adapted without aecting the run-time application. Moreover, the coupling of development and run-time environments in SALEs should be dynamic, i.e., each environment should be runnable in the absence of the other. To achieve this, the run-time functionalities that pertain to both development and run-time environments 68 should be accessible from either of them when the environments are detached. This property would loosen the coupling of the development and run-time environments in a SALE and therefore improve the availability of the run-time application. 3.5.2 Desirable Quality Properties Although SALEs have quality requirements spanning a large number of dimensions (e.g., complexity, heterogeneity, eciency, and scalability), here I highlight the quality dimensions that pertain specifically to the dependability and availability of SALEs. In particular, I identify adaptability, fault-tolerance, and robustness as desirable quality properties of SALEs. 3.5.2.1 Adaptability. As a run-time application evolves during its life-span, adaptation activities that pertain to it also evolve. To respond to changing adaptation needs of a systems, the behavior and the structure of a SALE itself should be adaptable. Changes to the adaptation aspects of a system have dierent levels of severity. While the less severe changes can be accommodated by adjusting the adaptation artifacts, the more severe changes may actually necessitate structural adaptation of the SALE, which is usually harder and more expensive to perform. In Section 1.2.2, I distinguish five aspects of system adaptation that may change at run-time. Adaptability of a SALE contributes to its availability and dependability. On the one hand, an adaptable SALE can be updated without going down for maintenance when adaptation needs of its run-time application change. On the other hand, an adaptable 69 SALE is more dependable because its tools can be altered or restarted in unanticipated situations (such as tool failure). 3.5.2.2 Fault-tolerance. A SALE not only should respond to failures of its run-time application, but also should respond to failures of its own tools. To this end, a SALE needs to be adaptable and needs to monitor the health of its development-time and run-time tools. 3.5.2.3 Robustness. SALEs are expected to respond adequately to unanticipated run-time conditions that per- tain to, both, the run-time applications and the run-time tools. A response to the run-time conditions in a SALE should not interrupt the operation of the run-time environment. 3.6 iDARE Reference Architecture The SALEs discussed in Section 3.4 have inspired me to introduce iDARE, a refer- ence architecture for integrated Development And Run-time Environments, depicted in Figure 3.9. This architecture is useful for understanding, classifying, and studying development environments from the perspective of their interaction with run-time en- vironments. The adaptation engine in iDARE lies at the intersection of the development and run-time environments. However, the adaptation engine in iDARE is optional and a “floating” component. Consequently, iDARE can be used to express dierent classes of environments, as presented in Figures 3.1-3.4. Tools in iDARE are special components that run in development environments. I classify iDARE tools into the following three 70 Development Environment Adaptation Engine Run-time Environment Run-time Application . . . Architectural Modeling Artifacts Adaptation Logic Artifacts Legend Environment Repository Management Tool User Interface Tool Artifact Processing Tool Collector Adaptation Logic Evaluator Adaptation Logic Manager Architectural Model Manager Admin Tools Adaptation Component Application Component Detachable Tools Run-time Component Run-time Roles Adaptation Engine Manager Run-time Software Modules Figure 3.9: iDARE Reference Architecture. types (see Section 3.1): Repository Management Tools, User Interface Tools, and Artifact Processing Tools. Notice that advanced tools in iDARE can be composed from multiple simpler tools of dierent types (e.g.,SoftwareMonitor in Figure 3.8). SALEs, as a growing class of emerging development environments, are especially interesting to me. Therefore, I designed iDARE with the following two goals in mind: (1) codifying the architecture of the adaptation engine within iDARE based on the shared architectural traits of the existing SALEs, and (2) supporting the desirable structural and quality properties of SALEs, listed in Section 3.5. Subsequently, iDARE can help me to capture, dierentiate, and highlight several shortcomings of existing SALEs. To 71 support my first goal, I codified the architecture of the adaptation engine in iDARE using all five roles that I identified for run-time tools in Sections 3.2 and 3.3.2: Admin, Collector, Adaptation Logic Evaluator, Adaptation Logic Manager, and Architectural Model Manager. A complex run-time tool in iDARE may comprise several run-time roles (e.g., the Architecture Runtime Manager in Figure 3.6). Moreover, an adaptation engine may utilize multiple instances of each run-time role (e.g., two components have Architectural Model Managers role in Figure 3.6). To support the desirable properties of SALEs, i.e., my second goal, iDARE introduces Detachable Tools, Run-time Components, and the Adaptation Engine Manager tool. Detach- able Tools can separate from the development environment and run independently. Run-time Components, on the other hand, are those components that can be added, removed, or replaced at run-time. Finally, the Adaptation Engine Manager monitors, manages, and adapts the adaptation engine. Note that in order to follow the adap- tive layered architectural style, the Adaptation Engine Manager can be implemented as a meta-layer architecture. These constructs cover each of the desirable properties of SALEs discussed in Section 3.5 as follows: Structural properties. The Detachable Tools in iDARE are loosely coupled with and can separate from the development environment and run independently. Conse- quently, adaptation engine of iDARE can detach from its development environment before the development environment becomes unavailable. Several conditions may result in the unavailability of development environments, e.g., when the develop- ment environment and the run-time application are distributed on dierent hosts 72 and communication resources become unavailable. Development environments may also fail or may require downtime for maintenance purposes. Adaptability. Run-time Components are intended to make the adaptation engines themselves adaptable, and allow iDARE to respond to the changing adaptation needs of a system by changing its structure. Existence of Run-time Components combined with the ability of some development environments (e.g., Eclipse) to add and remove tools at run-time enables users to dynamically adjust the architecture of the adaptation engine. However, more automated adaptation approaches to mange adaptation engines may be desirable. Fault-tolerance. Detachable Tools, Run-time Components, and Adaptation Engine Managers in iDARE are the ingredients for the design of a fault-tolerant environ- ment. Detachable Tools allow a run-time environment to keep its operation in the absence of its development environment, e.g., when the development environment needs to restart to recover from a tool failure. Moreover, Adaptation Engine Man- ager monitors the health of the adaptation engine and reacts in the case of failure of its tools. Finally, Run-time Components can be managed and re-deployed in response to a failure. Robustness. Run-time Components in iDARE can be adapted by the Adaptation Engine Manager in response to a run-time condition in which structural changes are necessary. There are a number of advantages inherent in the design of iDARE. 73 1. iDARE supports automation of software maintenance and evolution processes. In iDARE, the process of updating software and adaptation logic artifacts and enacting the updates to the run-time system happens in a single environment. Artifact updates from the development environment can be directly provided to the adaptation engine, which is responsible to apply the changes to the run-time application. 2. The design of iDARE allows the orchestration and integration of adaptation engine tools with other tools and processes in the development environment. Services provided by an adaptation engine can co-operate with services of other tools, in a unified environment, to design, generate, validate, and test adaptation logic artifacts. 3. The operations of the adaptation engines and adaptation artifacts can be integrated with the ALM processes. This will support the integration of maintenance activities with the ALM processes, which is a desirable but missing part in ALM [51]. 4. The design of iDARE also allows providing feedback from the run-time environ- ment to the development environment through the adaptation engine. Conse- quently, the collected run-time feedback can be processed and leveraged in an integrated environment for maintenance purposes. 5. The design of iDARE supports software reuse. Instead of creating tools for a new self-adaptive system from scratch, existing development environment tools (e.g., editors and repository managers) can be reused, extended, or specialized to support artifacts (e.g., adaptation policies) and processes specific to self-adaptive systems. 74 In addition to the above benefits, iDARE is useful in studying the existing SALEs. I captured several shortcomings of the existing SALEs by studying their designs in the context of iDARE (recall Section 3.4 and Figure 3.4): Structural shortcomings. As Figure 3.4 indicates, existing SALEs do not utilize Detachable Tools. In fact, the development and run-time environments in SALEs are tightly integrated and run concurrently. Therefore, the availability of the run- time environments in the existing SALEs will degrade due to the unavailability of their development environments. Moreover, development environments in the existing SALEs are highly resource-consuming and provide tools that are not required at run-time. For instance, to run SADE (Figure 3.8) on a given host, the host would need to provide sucient resources to execute Eclipse. Consequently, SADE may not be used on a host with limited memory resources. A number of other tools provided in SADE (e.g., Strategy Compiler and JDT) are not required at run-time. Adaptability shortcomings. To provide an adaptable adaptation engine, existing SALEs separate the adaptation logic artifacts from the components that manage and enforce them. However, as mentioned in Section 3.5, to respond to some changing adaptation needs, structural changes to the adaptation engines are required. In fact, as notable in Figure 3.4, adaptation engines in existing SALEs do not utilize Run- time Components and have static structures. For instance, the Architectural Model Manager in PBAAM (Figure 3.6) cannot be updated to a newer version without stopping and restarting both the development and run-time environments. 75 Fault-tolerance shortcomings. As shown in Figure 3.4, existing SALEs do not monitor and manage their tools and do not support Detachable Tools or Run-time Com- ponents. The development and run-time environments in the existing SALEs are tightly integrated. Therefore, tool failure in a SALE results in the failure of the SALE’s run-time environment. For example, there is no way to monitor the health of the components in the adaptation engine of PESOI (Figure 3.7) and to recover its adaptation engine from potential failures. Robustness shortcomings. As shown in Figure 3.4, the existing SALEs do not support Run-time Components and have static structures. Therefore, they are not able to respond to the run-time conditions by adapting the structure of their adaptation engines. To perform such changes on the existing SALEs, their development en- vironments must be taken o-line. This decreases the robustness of the existing SALEs. For example, consider the run-time condition in which the development environment of RAIDE (Figure 3.5) needs to be restarted to recover from an internal crash. In this situation, the adaptation engine will become unavailable, and adap- tation engine’s customizations and the current state of the run-time architectural model may be lost. 76 Chapter 4 PLASMA Previous work in self-adaptive and self-managing systems can be categorized across two prevalent adaptation mechanisms: prescriptive and declarative. Policies, in the pre- scriptive approach, are sets of condition-action rules that specify how the system should be modified when a specific condition is met. On the other hand, system requirements specify the desirable attributes of the system. Declarative approaches find adaptation plans to adapt the architecture of a system in order to satisfy its requirements. Adap- tation plans are sequences of adaptation actions that should be enacted on the run-time application. Existing declarative self-adaptive software systems utilize various adaptation arti- facts to manage and adapt the behavior of a system. These artifacts are related to both the application elements that should undergo adaptation and the adaptation operations (of meta-level components) that should be enacted on the run-time application. How- ever, in the existing approaches, there is a disconnect between the adaptation artifacts and architectural models of the application and adaptation elements. This disconnect 77 limits dierent aspects of adaptability of self-adaptive systems. To demonstrated this, I provide two examples from the recent software self-adaptation approaches. Adaptation artifacts and application components in [91] are tied manually. The provided approach in [91] utilizes a Domain Model Description (DMD) of the application domain to plan for and adapt the behavior of the run-time application. This domain model description describes the state variables and actions in the application domain. However, this domain model description is manually provided by the system’s end- user. Moreover, this domain model description is manually linked to components that actually provide the actions described in the domain model description. Therefore, the changes in the availability of the application components (e.g., when a component is out of order, or a new component becomes available) may not be automatically reflected on the domain model description. This limits the self-adaptability of the approach provided in [91]. In Planit [8] the adaptation artifacts are not tied the meta-components that enact the adaptation activities on the run-time application. Planit uses a domain model description to describe the actions (e.g., connect two components) and states (e.g., a component is instantiated) in the domain of software adaptation. This domain model description is utilized to find an adaptation plan. However, the actions provided in this domain model description are not tied to the meta-components that actually provide those actions. Therefore, changes in the adaptation capabilities (e.g., by providing a new meta-level component) and requirements (e.g., need to adapt a new type of component) of a system cannot be automatically reflected on the domain model description used by Planit. This limits the self-adaptability of Planit. 78 These approaches are, thus, unable to dynamically update the adaptation artifacts required for software adaptation in response to unforeseeable events, such as new adap- tation requirements, new application-level or meta-level components, or an unexpected type of component failure. In this chapter, I introduce PLASMA, a Plan-based Layered Architecture for Software Model-driven Adaptation. PLASMA utilizes an ADL and a planning-as-model-checking technology [40] to enable adaptation of the run-time application and meta-level architec- tures. PLASMA uses planning to calculate both the behavior of the run-time application and an adaptation plan to adapt the architecture of the run-time application. PLASMA dynamically synthesizes and manages the adaptation artifacts required for planning from ADL models of the application- and meta-level components. The rest of this chapter is organized as follows. Section 4.1 describes my framework’s architecture and PLASMA’s use of domain models, component models, and planning. Section 4.2 details PLASMA’s design and implementation. 4.1 Approach In this section, I provide a high-level summary of the PLASMA approach to automated self-adaptation and self-management for software systems; the details of PLASMA’s design and implementation are then provided in Section 4.2. First, i explain the two types of domain models that are utilized in PLASMA: application domain models and adaptation domain models. Second, I describe how PLASMA leverages an adaptive layered architecture to achieve a high-degree of autonomy and a clear separations of 79 1 2 3 4 unlock lock load lock unload unlock Ø loaded locked loaded ^ locked (a) unload 1 2 3 4 unlock lock load lock unload unlock loaded ^ locked 5 adjust Ø loaded misplaced (b) locked Figure 4.1: (a) An example application domain model. (b)The example extended with an additional capability. concerns. Third, I discuss the role of architectural modeling in generation of adaptation artifacts in PLASMA. Lastly, I describe how PLASMA applies planning techniques to realize dynamic replanning in a self-adaptive system. 4.1.1 Domain Models PLASMA is based on the novel application of planning mechanisms to two dierent types of models: application domain models and adaptation domain models. Application domain models capture the possible states of application components and actions that those components may perform. Each action modifies the application state in a defined way. Analogously, adaptation domain models capture architectural states and actions: each state in the adaptation domain model corresponds to a particular architectural configuration, and actions in the adaptation domain model correspond to architectural modifications, such as the addition, removal, and replacement of components. While 80 previous work has applied planning to application domains, PLASMA is unique in its usage of adaptation domains. Both application domain models and adaptation domain models consist of the states of the domain, available actions in the domain, and the state transitions caused by those actions. Therefore, a domain model is formally defined as a 4-tuple<F,S,A,R> in which, F is a finite set of fluents which represent the state variables of the system, S 2 F is a finite set of states,A is a finite set of actions and R : SA7! S is a transition function. Figure 4.1 depicts two example application domain models. The first application domain model represents a system where an item can be loaded/unloaded to/from a container which, in turn, can belocked/unlocked. Figure 4.1(a) is a graphical presenta- tion of the domain model for this example in which loaded and locked are the fluents of the domain, circles represent the states, and arrows represent the actions as well as system transitions in the model. The label assigned to each state in this figure is the conjunction of the fluents which are true in that state. For the case where a system requirements change occurs, consider the domain model depicted in Figure 4.1(b). In this figure, a new fluent called misplaced and a new state are added to handle the case where an item may be misplaced. Figure 4.2 depicts an example adaptation domain model. In this example domain, software components can be instantiated/killed, added/removed to/from an archi- tecture, and connected/disconnected to/from another component in that architecture. The states of this adaptation domain model are the various architectural configurations involvingC1 andC2. For example, state7 corresponds to an architecture in whichC1 and C2 exist but are not connected. 81 instantiate(C1) 1 2 4 5 3 6 7 8 kill(C1) add(C1) remove(C1) kill(C2) instantiate(C2) remove(C2) add(C2) kill(C2) Instantiate(C2)i instantiat(C1) kill(C1) remove(C2) add(C2) add(C1) remove(C1) disconnect(C1,C2) connect(C1,C2) exist(C1) ^ exist(C2) Ø exist(C2) exist(C1) exist(C1) ^ exist(C2) ^ archIncludes(C2) exist(C1) ^ exist(C2) ^ archIncludes(C1) exist(C1) ^ exist(C2) ^ archIncludes(C1) ^ archIncludes(C2) exist(C1) ^ exist(C2) ^ archIncludes(C1) ^ archIncludes(C2) ^ connected(C1,C2) Figure 4.2: An example adaptation domain model. In the remainder of this section, I show how these two types of domain models are utilized for software adaptations in PLASMA. 4.1.2 Adaptive Layered Architecture In my approach, I leverage the adaptive layered architectural style which was introduced in Chapter 2. Although the adaptive layered style allows for layering of arbitrary depth, PLASMA employs three adaptive layers, as shown in Figure 4.3. Application- level components reside in the bottom Run-time Application layer. The middle layer, called the Adaptation Layer monitors, manages, and adapts components in the run- time application. The topmost Synthesis Layer manages the adaptation layer and the generation of plans based on user-supplied goals and component specifications. The plans generated by the synthesis layer define the followings: (1) the target architecture for the adaptation layer (the synthesis plan), (2) the target architecture for the run-time application (the adaptation plan), and (3) the actions to be carried out by the run-time application (the application plan). Therefore, the synthesis layer is capable of responding 82 Adaptation Layer Synthesis Layer Application DMD Run-time Application Collector Adaptation Analyzer Admin Analyzer Sensor Collector Admin Adaptation Plan Run-time Application Architecture Adaptation Layer ADL models Synthesis Plan Adaptation Layer Architecture Application Plan Executor Locker Loader Synthesis DMD (static) Adaptation Layer Model Manager ADL to NPDDL Model Parser Application Planner Adaptation Layer Architecture Manager Adaptation DMD Synthesis Planner Adaptation Dependency Analyzer Adaptation Layer Adaptation Logic Manager Adaptation Planner Application Dependency Analyzer Application Layer Model Manager ADL to NPDDL Model Parser Application Layer ADL models Application Goal Application Layer Application Logic Manager Legend Environment Adaptation Component Application Component Admin Collector Adaptation Logic Evaluator Adaptation Logic Manager Architectural Model Manager Figure 4.3: The PLASMA adaptive layered architecture. to changing system requirements or operational environments by regenerating plans. This three-layered architecture enforces a clear separation of concerns, whereby each layer in the system provides a dierent form of adaptation capability, and enables a high-degree of autonomy. In PLASMA, the only inputs provided by the system architect are (1) the application problem description, (2) component specifications written in an ADL, and (3) executable implementations of the components. The problem description consists of an initial state and a goal. The component ADL models are used by the ADL to NPDDL Model Parser components in the synthesis layer to generate application and adaptation domain model 83 descriptions, as depicted in Figure 4.3. A domain model description presents a domain model in a standard language which is required for planning. Domain model descrip- tions, along with the problem description, are provided to the Application Planner andAdaptationPlanner components depicted in the synthesis layer in Figure 4.3. Each of these two components generates a plan for one of the two bottommost layers: the ApplicationPlanner generates a plan for the run-time application which specifies how to achieve the application goal, while the Adaptation Planner generates a plan for the adaptation layer which specifies how to arrive at the target application architecture. Note that the third planner in the synthesis layer, the Synthesis Planner, receives a static synthesis domain model description and a planning problem, and generates a plan for the synthesis layer. This plan specifies how to arrive at the target architecture of the adaptation layer. Each of the layers in PLASMA contain a special component that executes the plans generated by the top layer’s planner components. The run-time application contains a special component called the Executor, which executes plans generated by the Application Planner. The Executor examines the state of application components and, based on their state and the plan received from theApplicationPlanner, invokes the functionality of application components to perform tasks. The adaptation layer con- tains anAdaptationAnalyzer that executes plans generated by theAdaptationPlanner. The Adaptation Analyzer uses the plan to determine how and under what conditions components in the run-time application should be added, removed, replaced, or oth- erwise altered. Finally, the synthesis layer contains an Analyzer that executes plans generated by the Synthesis Planner. Plans generated by this component determine 84 how to change the architecture of the adaptation layer. Adaptation layer architecture needs to be adapted when new actions (i.e., to adapt or monitor run-time application) must be employed by the adaptation layer. 4.1.3 Architectural Modeling As previously noted, components in PLASMA must be specified in an ADL and passed to the ADL to NPDDL Model Parsers in the topmost layer in Figure 4.3. ADL models are used to generate domain model descriptions which are required for planning. To be able to generate domain models from ADL models, the ADL used must carry enough information from which a 4-tuple domain model, <F,S,A,R>, can be extracted. Conse- quently, component descriptions in the selected ADL should include the ability to specify (1) attributes, (2) required and provided interfaces, and (3) pre- and post-conditions of each interface. This information is used by the ADL to NPDDL Model Parsers to generate domain model descriptions which are passed to the appropriatePlanner component. In particular, the ADL to NPDDL Model Parser will generate a domain model by mapping attributes to fluents F, interfaces to actions A and by utilizing pre- and post-conditions of interfaces to determine states S and the transition function R. Note that, Synthesis DMD and Adaptation DMD are similar and describe the domain of software adaptation. However, in contrast to theAdaptationDMD, theSynthesisDMD is not created from ADL models, because the synthesis layer uses a static set of admins and collectors and its domain model description does not change. Furthermore, instead of explicitly (and possibly rigidly) specifying the architecture topologies of the run-time application and adaptation layer, Dependency Analyzers in 85 PLASMA infer the topologies of the run-time application and adaptation layer from the plans and the component ADL models. To this end, required and provided interfaces are used to discover component dependencies and, thus, determine required components in the architecture. I should point out that any ADL that includes this information can be used with PLASMA, given the appropriateADLtoNPDDLModelParser. The use of ADL models in PLASMA results in several benefits. First, whenever application-level components are added, removed, or replaced, new plans can be auto- matically generated to achieve the goals of the system. In particular, ADL model changes result in domain model changes, which in turn, initiate replanning. Second, changes to requirements represented in changes to component model descriptions can be handled during run-time. This particular benefit is obtained because the domain models that are generated from ADL models serve as a requirements specification of the system. Third, new meta-level components can be automatically employed by PLASMA (i.e., by adapting the adaptation layer) whenever adaptation operations required by the system change. In the next section, I describe how the planners in Figure 4.3 use domain model descriptions to create plans for the run-time application, adaptation layer, and synthesis layer. 4.1.4 Planning The behaviors of all layers in PLASMA are planned in order to achieve the high level goal of the run-time application, specified by the system’s end-user. The two bottommost layers receive the plans from the synthesis layer. The synthesis layer generates dierent 86 kinds of plans for the run-time application, the adaptation layer, and itself. Each of these plans is generated from its own domain model description. The planner components in the top layer accept the domain model description and a planning problem as inputs to generate a plan. I maintain a clear separation of the application and adaptation concerns by separating planning among the three dierent kinds of planners in the synthesis layer. A planning problem is the problem of arriving at a goal from an initial state. The goal is represented by a set of conditions on the domain model fluents, and corresponds to a set of goal states where those conditions are true. The generated plan is a set of state-action rules which specify the actions to be taken from each state to reach a goal state. The plan is sucient to determine a path from any possible initial state to a goal state. The application goal is a set of conditions provided by the system end-user. The Application Planner finds an application plan that specifies how to achieve the appli- cation goal from a given current application state. Application Dependency Analyzer then derives the target architecture topology of the run-time application required to run that plan, using an algorithm specified in Section 4.2. The current architectural topology and the target architecture topology of the run-time application form the initial and goal states of the adaptation problem, respectively. Consequently, theAdaptationPlanner finds an adaptation plan that transforms the current architecture of the run-time application to the desired architecture. Similarly,AdaptationDependencyAnalyzer then derives the target architecture topology of the adaptation layer required to run the adaptation plan. This target architecture along with the current architecture of the adaptation layer form the synthesis problem. Eventually, Synthesis Planner receives the synthesis problem 87 and finds a synthesis plan to transform the current architecture of the adaptation layer to its goal architecture. The application, adaptation, and synthesis plan are executed in the following way. Recall from Chapter 2 that the adaptive layered style includes meta-level components— collectors, analyzers, and admins—that respectively monitor, analyze, and modify compo- nents in the layer below (see Figure 4.3). 1. The Collector at the synthesis layer determines the current architecture of the adaptation layer (which is initially empty). The synthesis layer Analyzer receives the synthesis plan which determines the architecture for the adaptation layer. The Analyzer executes the plan by instructing the synthesis layerAdmin to make mod- ifications to the adaptation layer architecture by instantiating meta-level compo- nents, establishing connections, etc. These meta-components are required in the adaptation layer in order to execute the adaptation plan. 2. The instantiated adaptation layer architecture will include anAdaptationAnalyzer that contains the adaptation plan and logic for executing it. The Adaptation Analyzer executes the plan by instructing the adaptation layer Admin to make modifications to the run-time application architecture by instantiating components, establishing connections, etc. Adaptation layerCollectors monitor the application architecture; if it changes unexpectedly, the Adaptation Analyzer can use the adaptation plan to return to the target application architecture. 3. The instantiated run-time application architecture will include an Executor that contains the application plan and logic for executing it and one or more Sensors. 88 Sensors monitor the current state of the system (i.e., the domain fluents) and pass this information to the Executor. The Executor uses the values of the fluents to determine the appropriate action to perform, according to the application plan. Adaptation in my approach is achieved automatically through dynamic replanning and is not pre-programmed by the application architect. Dynamic replanning can be initiated either by the system end-user or by unexpected changes to the domain models (e.g., due to component failures). Adaptation of the run-time application occurs when- ever the adaptation goal and/or adaptation domain model change. These changes could, in turn, be caused by a change to the application goal and/or the application domain model. The first case (application goal change) is initiated by the system end-user, who may provide a new application goal to the system at any time. In the second case (appli- cation domain model change), a new component becomes available (e.g., a new version is introduced by the application architect) or a component becomes unavailable (e.g., due to a failure). Adaptation of the adaptation layer, on the other hand, occurs whenever the adapta- tion plan changes. Changes in the adaptation plan result in the architectural changes to the adaptation layer, because each adaptation plan requires a dierent set of meta-level components to run. At the least, the Adaptation Analyzer should be replaced with an analyzer that runs the new adaptation plan. Moreover, new types of components and connectors in the run-time application may not be adaptable with the existing meta-level components. Chapter 5 provides dierent situations which result in the adaptation of the adaptation layer. 89 The synthesis and adaptation layers achieve a high degree of autonomy and flexibility, and also reduce the burden on the domain and application architects. The adaptation layer maintains a high degree of autonomy by utilizing automatically generated plans to adapt the run-time application. Placing the onus of automatic adaptation onto the adaptation layer reduces the burden of design on the application architect because she need not manually specify plans for each adaptation scenario. Moreover, my approach oers significant flexibility by giving the domain architect the ability to specify the adaptation requirements via ADL models of meta-components in the adaptation layer. 4.2 Design and Implementation In this section I describe the detailed design and implementation of PLASMA. In par- ticular, I discuss the middleware, ADL, and ADL tool support I utilized, as well as the tools I leveraged from the planning domain. 4.2.1 Adaptive Layered Architectures in PLASMA As mentioned in Section 4.1.2, I leveraged the adaptive layered style introduced in Chapter 2. As described in Chapter 2, I extended an architectural middleware platform called Prism-MW [65] to support adaptive layered architectures. A full description of the Prism-MW and its extended version is provided in that Chapter. Prism-MW is particularly well-suited to PLASMA because it natively supports dynamic system 90 adaptation by decoupling components via (dynamically instantiable) ports and event- based interaction. The full description of this platform is beyond the scope of the my dissertation and may be found in [65]. I evolved and extended the meta-components of the adaptive layered style, to run application and adaptation plans in PLASMA.DeclarativeAnalyzer in Figure 2.6 eval- uated the application-specific software requirements (only energy requirements) based on monitoring data and triggered limited application-specific adaptation plans when required. These plans were designed and implemented by application architects and developers and were mostly hard-coded in the Energy Analyzer. Therefore, analyzers introduced in Chapter 2 were not very flexible and did not provide a high degree of au- tomation. Furthermore, they tended to be complex, which made them time consuming and error-prone to generate. In contrast, the Adaptation Analyzers in PLASMA are an extended version of the Analyzer in Figure 2.4; it is capable of running automatically generated general plans. I also extended theCollector andAdmin components to match the interfaces of myAdaptationAnalyzer. 4.2.2 Architectural Modeling in PLASMA To support architectural modeling in PLASMA, I adapted and extended C2SADEL, an ADL introduced in [67]. I chose this language because it meets the requirements discussed in 4.1.3. Moreover, it supports system analysis and evolution. This language was originally designed to support the C2 architectural style, a layered and event-based style. Furthermore, I modified the component-based DRADEL environment [67] used to support modeling, analysis, evolution, and implementation of architectures described 91 in C2SADEL. DRADEL supports component evolution via sub-typing, architectural consistency- and type-checking, and code generation. I extended C2SADEL and created SADEL as the ADL for PLASMA. The grammar of this language is provided in Appendix B. As discussed in 4.2.1, Prism-MW supports the implementation of the layered component-based architecture of PLASMA. Therefore, I designed SADEL to support the event-based style which is the basic style supported in Prism-MW. Compared to C2, the event-based style covers a wider range of applications and provides a higher degree of flexibility in architectural design (though at the cost of some analyzability, as discussed in [93]). Just like in C2SADEL, an architectural model in SADEL has three major parts: component types, connector types and a topology. The topology defines the component and connector instances and their inter-connections. Components define state variables, interfaces, and provided and required operations. Each interface is mapped to an operation. In turn, each operation specifies the pre- and post-conditions of its invocation in terms of first-order logic expressions involving state variables. Operation definitions in SADEL specify conditional and non-deterministic post-conditions, which are required for the generation of domain models. Compo- nent models in SADEL also include version information, which allows the synthesis layer to distinguish between evolved/updated components and adapt the architecture accordingly. PLASMA utilizes SADEL to model both Application-level and meta-level components. An example SADEL specification of theLoader component (i.e., an application-level component) is given in Figure 4.4. Loader has two interfaces: load() and unload(). These interfaces are mapped to actions A in the application domain model. Loader has 92 component Loader is{ metaData{ classType : prism.secondLayerArchitecture.ComponentEnv; version : 1; } state{ loaded : Boolean; locked : Boolean; } interface{ prov loadingInterface : load(); prov unloadingInterface : unload(); } operations{ prov opLoad:{ pre (\not (loaded)) \and (\not (locked)); post (loaded); } prov opunLoad:{ pre (loaded) \and (\not (locked)); post \not (loaded); } } map{ loadingInterface -> opLoad(); unloadingInterface -> opunLoad(); } } Figure 4.4: The SADEL specification for theLoader component. two Boolean state variables called loaded and locked. These variables are mapped to fluents F in the domain model. Finally, pre- and post-conditions are specified for the load() and unload() interfaces. For example, load() has the pre-condition (\not (loaded))\and(\not(locked)) and post-condition(loaded). In addition, an example SADEL specification of an Admin component (i.e., a meta- level component) is given in Figure 4.5. Two interfaces of this component,connect and instantiate, and their related operations are shown in this example. As depicted, the 93 component Admin is{ state { connected : Component , Connector -> Boolean; exist : Component -> Boolean; ... } interface{ prov connectInterface: connect(comp:Component; conn:Connector); prov instantiateCompInterface: instantiate(comp:Component); ... } operations{ prov opConnect:{ let comp:Component; conn:Connector; pre exist(comp) \and archIncludes(comp) \and exist(conn) \and archIncluds(conn) \and (\not(connected (comp,conn))); post connected(comp,conn); } prov opInstantiate:{ let comp:Component; pre (\not(exist(comp))); post exist(comp); } ... } ... } Figure 4.5: The SADEL specification for theAdmin meta-level component. state variables and operations in this component are related to the domain of software adaptation. PLASMA provides support for modeling, analysis, evolution and implementation of components and architectures described in SADEL by enhancing DRADEL [67] and integrating it with other PLASMA components. I ported DRADEL’s components to PRISM-MW and adapted their interfaces to match PLASMA components in the syn- thesis layer. The enhanced DRADEL components integrated into PLASMA support modeling and analysis in the event-based (as opposed to C2) style and code gener- ation for PRISM-MW (as opposed to C2’s custom-built architecture implementation 94 (define (domain test) (:predicates (loaded)(locked) ) (:action load :precondition (and(not(loaded))(not(locked))) :effect (loaded) ) (:action unload :precondition (and (loaded)(not(locked))) :effect (not (loaded)) ) (:action unlock :precondition (locked) :effect (not(locked)) ) (:action lock :precondition (not(locked)) :effect (locked) ) ) Figure 4.6: An NPDDL domain model description for the example domain. framework). Incorporation of the extended DRADEL components enables PLASMA to perform consistency- and type-analysis on run-time application architectures; further explanation of DRADEL’s analysis capabilities can be found in [67]. These components also provide additional features not supported by DRADEL originally. For example, PLASMA supports component evolution via sub-typing and version control. 4.2.3 Planning in PLASMA I used the Model Based Planner (MBP), a planning tool for non-deterministic domains [11], to support planning in PLASMA. MBP implements the planning-as-model-checking technique introduced in [40]. The fundamental idea behind planning-as-model-checking is to generate plans by checking the correctness of formulas in a model. To find a plan 95 to reach a goal state in a domain, MBP uses a problem description and a domain model description specified in NPDDL, an extended planning domain description language. The problem description determines what kind of plan (Weak, Strong, Strong Cyclic, etc. [40]) is required for the application. In the rest of this section, I describe how planning occurs for dierent layers in PLASMA. More specifically, I describe how PLASMA deals with initialization of archi- tectures, topology determination, and goal or ADL model changes. 4.2.3.1 Application Planning In PLASMA, the NPDDL application problem description (initial state and goal) is provided by the end-user, while the NPDDL application domain model description is created automatically from the SADEL models of application components by the ADL to NPDDL Model Parser (recall Figure 4.3). For illustration, the NPDDL specification of the application domain model depicted in Figure 4.1(a) is shown in Figure 4.6. This NPDDL spec is derived from the SADEL models of theLoader andLocker. For example, the loaded and locked state variables of the Loader in Figure 4.4 are mapped to the loaded and locked predicates in Figure 4.6, while the load() and unload() interfaces are mapped to the load and unload actions. Similarly, the NPDDL pre-conditions and eects of these actions are mapped from the pre- and post-conditions of the respective SADEL interfaces. Once the NPDDL application domain model has been generated, it is passed, along with the NPDDL problem description, to theApplicationPlanner, which generates the application plan if there is a path from the initial state to the goal state in the application 96 domain model. If there is no such path, PLASMA notifies the application end-user so that she can modify the problem or the set of available components. In my example domain, assume an initial state in which no item is loaded in the container and the container is not locked (:loaded^:locked). This state is shown as state2 in Figure 4.1(a). Also assume that the application goal is to load an object into the container and lock it. This goal is represented as state 4 (loaded^locked) in Figure 4.1(a). The Application Planner generates a plan in the form of a set of state-action rules which should be followed to arrive at the goal. In this example, the plan contains the following pairs: ff1,unlockg f2,loadgf3,lockgg. This plan is interpreted as follows: to get to state 4 the following actions must occur—unlock action on state 1, load action in state 2 and lock action in state 3. Although this is a simple example, richer applications have much longer plans and may have multiple plans to reach a goal. PLASMA reduces the burden on the application architect by determining these plans automatically. Next, to be able to run the application plan in the run-time application, the required components for the plan and their topology must be determined. The responsibility of determining the topology of the run-time application is placed upon the Application Dependency Analyzer component. This component determines the components which are required to complete the plan by examining the actions used in the plan. The ApplicationDependencyAnalyzer computes all the components’ possible dependencies by matching their required and provided interfaces and creates a topology according to those dependencies. As a result, the application architect no longer bears the burden of specifying the topology of the system. 97 In the example domain from Figure 4.1(a), the Application Dependency Analyzer determines the target run-time application architecture in the following way. As pre- viously mentioned, to get to state 4 from state 2 the following plan P1 should be run: ff1,unlockgf2,loadgf3,lockgg. The Loader and Locker have the load(), lock(), and unlock() interfaces that match the actions of P1, so these components are included in the architecture. Recall that the run-time application always includes an Executor that runs the application plan by invoking the interfaces of application components, such as Loader andLocker. Consequently, theLoader andLocker are connected to theExecutor. Finally, theExecutor must know the values of domain fluents in order to determine the appropriate actions. Consequently aSensor is added to the architecture to monitor each fluent, and eachSensor is connected to theExecutor. This target architecture, produced by the Application Dependency Analyzer, is passed to the Adaptation Planner in the form of an adaptation problem (initial architecture and goal architecture). An application plan runs in the following manner. TheSensor component tracks the domain fluents, i.e., locked and loaded in my example. Changes to these values are pushed to the Executor. The Executor uses the values of the fluents to determine the appropriate action to run based on the plan. The actions are performed by invoking the interfaces of either the Loader or Locker components. This process is repeated until a goal state is reached. A high degree of autonomy is maintained since the plan is run by theExecutor without any involvement from the application architect. While the previous discussion describes plan execution in the case where the goal of the system remains the same, a change to the goal requires replanning. Applica- tion replanning followed by software adaptation occurs automatically in PLASMA. In 98 Figure 4.1(a), the run-time application goal can be changed from (loaded^locked) to (:loaded^ locked). This change initiates replanning which results in the following application plan: ff4,unlockgf3,unloadgf2,lockgg. The adaptation layer updates the Executor component in the run-time application to run the new plan. To reiterate, the run-time application and its key components are designed to ease the burden of design on the architect, maintain a high degree of autonomy for the software system, and handle non-deterministic domains. 4.2.3.2 Adaptation Planning Adaptation plans are generated by theAdaptationPlanner in the synthesis layer. Adap- tation plans describe how to initialize the run-time application architecture, which in- cludes the creation and connection of components. TheAdaptationPlanner requires an NPDDL adaptation problem, generated automatically by the Application Dependency Analyzer, and an NPDDL adaptation domain description, generated automatically by ADL to NPDDL Model Parser, to create an adaptation plan. Adaptation plans are also computed by MBP using the same algorithm used to compute application plans. Figure 4.2 shows an example adaptation domain model with two components. In my implementation, I utilized meta-level components,Admin andCollector, to perform the actions and monitor the fluents in the adaptation domain model. More specifically in the specific example depicted in Figure 4.2, theAdmin component performs theinstantiate, kill, add, remove, connect, and disconnect actions in the adaptation domain and the Collector detects theexist,archIncludes, andconnected fluents. 99 (define (domain AdaptationModel) (:types Component Connector ... ) (:predicates (connected ?comp - Component ?conn - Connector) (exist ?comp - Component) (archIncludes ?comp - Component) ... ) (:action instantiate :parameters (?comp - Component) :precondition (not (exist ?comp)) :effect (exist ?comp) ) (:action add :parameters (?comp - Component) :precondition (not (archIncludes ?comp)) :effect (archIncludes ?comp) ) (:action connect :parameters (?comp1 - Component ?comp2 - Component) :precondition (and (exist ?comp) (archIncludes ?comp) (exist ?conn) (archIncludes ?conn) (not (connected ?comp ?conn))) :effect (connected ?comp ?conn) ) ... ) Figure 4.7: NPDDL domain model description for the example adaptation domain. For illustration, a snippet of an adaptation domain model description is shown in Figure 4.7. This NPDDL specification is derived from the SADEL models of the Admin andCollector components. For example, theexist andconnected state variables of the Admin in Figure 4.5 are mapped to theexist andconnected predicates in Figure 4.7, while the connect and instantiate interfaces are mapped to the connect and instantiate actions. Similarly, the NPDDL pre-conditions and eects of these actions are mapped from the pre- and post-conditions of the respective SADEL interfaces. The adaptation plan is executed and managed by the Adaptation Analyzer from Figure 4.3. The Adaptation Analyzer executes an adaptation plan autonomously by 100 reading fluents from theCollector in the layer it resides in and by sending appropriate adaptation actions to be performed by the Admin. Therefore, adaptation planning and adaptation take place automatically and the domain architects only deal with the adap- tation layer requirements and design of meta-level components. In situations where a new Adaptation Analyzer is needed, e.g., in the case of an adaptation plan change, the synthesis layer instantiates a newAdaptationAnalyzer for the adaptation layer (as described in Section 4.2.3.3. An adaptation plan in my running example executes in the following manner. The run-time application is initially empty and the goal state of the application plan has a Loader, a Locker, and a Sensor whose interfaces are connected to the Executor com- ponent. Thus, the adaptation plan contains actions, such as instantiate(Locker), instantiate(Executor), instantiate(sensor), connect(Locker,Executor) to con- nect component interfaces, and so on. Figure 4.3 gives the instance of my layered architecture after the adaptation plan was run and the run-time application was set up. Once an initial run-time application architecture has been instantiated, two situations may result in adaptations to the run-time application: modifications to the component SADEL models and component failures during run-time (which may result in changes to the NPDDL domain models). PLASMA supports these dynamic adaptations through replanning. The first cause of replanning is a SADEL model change, which occurs when system requirements evolve. For example, to handle a new requirement to perform adjustments to the misplaced object in the container, a new component calledAdjuster is added to the system with an interface to perform theadjust action. Figure 4.1(b) depicts the domain 101 model description of my example with the new action. The SADEL model is changed to reflect the addition of the Adjuster component. This SADEL model change generates a new NPDDL application domain model description, which initializes replanning. A new application plan is found automatically and theApplicationDependencyAnalyzer from Figure 4.3 uses the new plan to derive a new run-time application architecture that contains theAdjuster component. At this point, a new adaptation problem is generated and passed to the Adaptation Planner. In this adaptation problem, the initial state is the current run-time application architecture and the goal is the new target architecture. Consequently, the Adaptation Planner creates a new adaptation plan which changes the architecture from the current topology to the new topology. This plan contains an action to add theAdjuster. The second cause of replanning is a failure of an application component. As an example, the Adjuster component may fail at run-time. In this case, the Executor fails to successfully run the plan and the adaptation layer detects the component failure through its Collector. The Adjuster is removed from the ADL model, resulting in a change to the NPDDL application domain model description which, in turn, initiates replanning and the deployment of a new architecture that does not rely on the failed component. However, if a component failure makes it impossible to achieve the goal, PLASMA reports the failure to the architect. PLASMA aims to reduce the burden of design placed upon application architects by preventing them from having to directly deal with architectural topology of the run-time application and adaptation plan specification. Application architects do not need to anticipate all possible adaptation scenarios or pre-program adaptation plans. 102 Adaptation Layer Run-time Application Collector Collector Collector Adaptation Analyzer StreamAdmin Admin Sensor Executor Locker Loader Adjuster Camera Stream Legend Collector Adaptation Logic Evaluator Admin Application Component Application Connector Figure 4.8: Architecture of the run-time application and the adaptation layer after both of them are adapted. 4.2.3.3 Synthesis Planning The architecture of the adaptation layer in PLASMA is dynamic and updates each time a new adaptation plan is generated. To this end, theAdaptationDependencyAnalyzer in the synthesis layer derives the architecture of the adaptation layer from the adaptation plan (as described in Section 4.1.4). Then, the Synthesis Planner uses a static domain model description of the synthesis layer, the current architecture, and the goal architec- ture of the adaptation layer to generate a synthesis plan. Synthesis plans are similar to the adaptation plans; they involve actions such as instantiate(Admin), instantiate( Adaptation Analyzer), connect(Collector,Adaptation Analyzer) to initialize and add meta-level components to the adaptation layer and to link them. At the beginning, the architecture of the adaptation layer is empty. Each time the run-time application is adapted, the architecture of the adaptation layer is also cal- culated and adapted. Note that this adaptation always involves replacement of the existing Adaptation Analyzer with a new one. The rest of the adaptation layer ar- chitecture, however, only adapts when a dierent set of meta-level components are required. To illustrate, consider the conditions in which the Adjuster component must 103 be added to the run-time application (as explained in Section 4.2.3.2). The Adjuster component operates based on an image processing algorithm and depends on aCamera component. The Camera component needs to stream the image data, using a Stream connector, to the Adjuster component. However, the Admin component in Figure 4.3 lacks the operations required to instantiate, add, and link to a Stream connector. In this scenario, a StreamAdmin meta-level component with required adaptation operations is provided to the system. The adaptation plan in this scenario includes actions such as instantiateStreamConn(Stream) that are provided by the StreamAdmin. The synthe- sis plan in this scenario includes operations such as instantiate(StreamAdmin) and connect(StreamAdmin,Adaptation Analyzer). Figure 4.8 depicts the architectures of the adaptation layer and the run-time application after adaptations in the above scenario. PLASMA is independent of the adaptation requirements and allows domain archi- tects to provide any set of meta-level components for the adaptation layer. The meta-level components in the adaptation layer can be dierent for dierent adaptation domains, which provides further flexibility for the system’s design. For example, a domain require- ment can enforce disconnection of components in a particular order to ensure minimum disturbance to the system during run-time adaptation. PLASMA is able to natively in- clude support for such a requirement. In addition, PLASMA aims to reduce the burden of design placed upon domain architects by preventing them from having to directly deal with architectural topology of the adaptation layer. PLASMA automatically calculates the architecture of the adaptation layer and adapts the adaptation layer when required. 104 Chapter 5 The 6A Approach To keep the requirements of a self-adaptive system satisfied, the declarative approach to self-adaptive software systems adjusts the topology of the run-time application in case of software or hardware failures, system updates, and changes in the environment con- ditions and system-requirements. To this end, a declarative approach usually provides a composition algorithm to adapt systems in order to deal with the above run-time situa- tions. However, there are many run-time conditions that cannot be handled with a static composition algorithm and necessitate the adaptation of the composition algorithm itself. In this chapter, I provide An Automated Adaptable Architecture Adaptation Approach (6A) to synthesize, manage, and update a composition algorithm itself at run-time. As a run-time application evolves during its life-span (e.g., evolves to stream data to a server), adaptation activities that pertain to it also evolve in various ways. Adaptation activities may need to evolve in order to utilize architectural elements of new or updated types (e.g., a client component) and new platforms, perform new adaptation actions (e.g., creating links to the server component), 105 employ adaptation actions in new, optimized ways (e.g., in a way that the adapta- tion plan take minimal time to execute), and adapt systems with new structural or quality requirements (e.g., to balance the load on a server by instantiating new servers). Recall from Section 1.2.2 that the five aspects of software adaptation that may change at run-time are (1) adaptation plans, (2) optimization criteria on adaptation plans, (3) underlying platform, (4) type and range of adaptable elements, and (5) type and range of supported adaptation logic (i.e., declarative, prescriptive, etc.). Consequently, to achieve a high-degree of availability and dependability for a declarative self-adaptive software system, its composition algorithm needs to be adaptable at run-time (i.e., without stop- ping the system or its adaptation engine). However, to the best of my knowledge, there is no declarative approach that provides such an adaptable composition algorithm. In this section, I provide an adaptation approach that address the first 4 aspects of software adaptation. My solution to create such an adaptable composition algorithm has three parts. First, I use the adaptive layered architectural style (introduced in Chapter 2) to enable adaptation of the adaptation tools. Second, I separate the adaptation logic (logic is usually implemented in an algorithm) from the algorithm which enforces it. Third, I synthesize the adaptation logic dynamically from adaptation actions, structural constraints, and quality requirements. Since AI planning techniques separate the planning algorithm from the description of the domain under planning and the planning problem, they 106 seem promising to implement the second part of my solution (i.e., the separation of the adaptation logic and the algorithm that enforces it). Hierarchical task networks (HTNs) provide a modeling notation to capture the activ- ities applicable to a software domain in a recursive fashion. Considering the hierarchical nature of the software adaptation domain, I leverage HTNs to implement the third part of my solution. Composite tasks in an HTN are high-level activities in the domain, com- posed from other composite tasks and primitive tasks. The primitive tasks, on the other hand, are low-level activities directly applicable to the domain. Activities in the domain of software adaptation can be captured in an HTN. For instance, the composite task removeaclientcomponent is composed from the primitive taskscloseconnectionto theservercomponent andfinalizetheclient. In particular, I dynamically synthesize and manage composite tasks of the adaptation logic from the primitive domain-specific adaptation tasks. In this chapter, I first provide an example of highly heterogeneous and dynamic soft- ware systems in order to clarify the need for adaptable composition algorithms for such systems. Next, in Section 5.2, I describe the domain of software adaptation in its most general form, and capture its properties by state transition and HTN modeling nota- tions. Then, in Section 5.3, I provide my approach to adaptable composition algorithms. I describe the architectural design and the planning technique used by 6A. I explain how the adaptation logic is dynamically composed from its various elements. I also provide an adaptation language that clarifies the internal presentation of the adaptation logic in 6A. Finally, in Section 5.4, I provide various adaptation artifacts required by 6A and their desired characteristics. 107 5.1 Motivating Application Domain Consider a disaster response application in which a rescue team utilizes robots in re- sponse to a disaster situation. In this scenario, the participant robots enter the disaster area to locate the injured or trapped people, map the area, and collect information. This is an extremely dynamic software application which will involve likely various software styles and platforms. Robots may need to switch between several navigation techniques (e.g., vision-, sonar-, and location-based navigation) when circumstances change (e.g., no GPS signal after entering a building, or camera failure). Robots may need to adapt their architec- tures to perform various activities at dierent times, including: (1) search for and locate trapped and injured people, (2) locate hazardous materials and situations (e.g., fire, gas leak, or power short-circuits), (3) collect data of dierent forms (e.g., video, picture, tem- perature map, and location map), and (4) transmit the collected data either by directly streaming to the rescue teams command station or by uploading to available data points (i.e., WiFi access points wired to Internet). In addition, subsets of robots may need to form teams and collaborate temporarily in dierent situations (e.g., to map the area sur- rounding an injured person). Moreover, robots may need to adjust their architectures to optimize their quality properties in order to deal with run-time situations (e.g., optimize their power consumption when running low on battery), and recover from hardware or software failures (e.g., communication link failures). The heterogeneous aspects of this problem demand a solution with heterogeneous software elements. A formal way to deal with such a heterogeneous application is to 108 employ multiple software styles. For instance, robot collaboration, communication to the command station, and robot task assignment activities may be solved by adherence to peer-to-peer, client-server, and rule-based architectural styles, respectively. Moreover, the highly dynamic nature of this application demands a self-adaptive software system that can deal with dierent software elements at dierent times. Dealing with adaptation aspects of heterogeneous software elements requires adaptation actions with dierent properties. Therefore, to deal with the heterogeneity of the involved software elements, self-adaptive systems similar to the postulated disaster response application need to provide adaptation mechanisms that can change at run-time. Figure 5.1 depicts a partial deployment view of the disaster response application’s architecture. In this snapshot Robot1 and Robot2 collaborate through their Robot Collaboration components. Robot1 utilizes an image-based navigation technique to move around. Moreover,Robot1 collects images from locations with hazardous material and uploads them to the Data Point. Components in this architecture utilize hetero- geneous interfaces and various architectural styles. Namely, the interactions of the Camera, Noise Filter, Pattern Recognition, and Navigation components follow the pipe-and-filter style, whereas theRobotCollaboration components are engaged based on the peer-to-peer style. In addition, interactions to the Data Collector follow the client-server style, while the Navigation and Robot Steering components are engaged in the implicit invocation style. Finally, the interactions of the Robot Collaboration and Navigation components in Robot1 follow the event-based style. The architecture provided in Figure 5.1 is used as a running example through out this Chapter. 109 Peer-to-Peer Connector Peer-to-Peer Connector Pipe Connector Pipe Connector Pipe Connector Pattern Recognition Pipe Connector Server Connector Client Connector Image Collector Noise Filter Filter Interface Legend Peer-to-Peer Interface Component Color Codes Pipe Interface Implicit Invocation Required Interface BLACK Provided Interface WHITE Client Interface Server Interface Connector Event Interface Navigation Robot Collaboration Event Bus Peer-to-Peer Connector Peer-to-Peer Connector Robot Collaboration Robot 2 Robot 1 Data Point Data Collector Camera Robot Steering Figure 5.1: Partial architectural view of the disaster response application. 5.2 Domain of Software Adaptation In this section I provide the general presentation of an architecture-based software system in 6A. An architecture is composed from multiple connected component and connector instances, each of which is instantiated from a component or a connector class. Components communicate and provide services to one another through their interfaces. To let two components interact, their interfaces are connected either directly or through connectors. A component may provide multiple services through multiple provided interfaces (to be used by other components), and depend on multiple services through multiple required interfaces (denoting services that must be provided by other components’ provided interfaces). To have a valid architecture, required interfaces of every component in that 110 architecture must be resolved by the provided interfaces of other components. To this end, each required interface of a component should be connected to a matching provided interface of another component. In this notation, types of the components’ interfaces determine the domain- or style-specific interaction rules between components (e.g., note the types of interfaces in the various architectural styles provided in Figure 5.1). I studied the domain of software adaptation in order to capture a general model of its commonalities and variation points. To this end, I captured some aspects of the software adaptation domain, from two dierent modeling viewpoints, in a general state transition model and a general adaptation HTN. The general state transition model determines the commonalities of states and state transitions in this domain. To keep the model applicable to a range of architecture-based self-adaptive software systems, some state transitions in this model are presented by high-level common adaptation actions, and low-level domain-specific adaptation actions are eliminated. The general adaptation HTN, on the other hand, captures the general adaptation actions required in the domain of software adaptation in a hierarchical fashion. This HTN specifies how high-level common adaptation actions are decomposed to low-level domain-specific adaptation actions. 5.2.1 General State Transition Model In this section, I provide the general state transition models for the life-cycle of compo- nents, connectors, and their instances in an architecture-based software system. The state model for the system as a whole can be composed from the state models of its individual components and connectors. Note that these models capture the general state transitions 111 ?Comp is not required to resolve component dependencies anymore or ?Comp is not available anymore Pick_Comp_Inst_or_Instantiate_for_Dependency + Resolve_ Dependencies_ and_Compose + ?Comp is not required by software requirements anymore Unweld_ Comp_Inst + Finalize_Comp_Inst Pick_a_Comp Unweld_ Comp_Inst + ?Comp is Required by software requirements (component_class ?Comp) (required_comp ?Comp) (instance_of ?Comp_Inst ?Comp) (required_instance ?Comp_Inst) (added_comp ?Comp_Inst) (depends_on ?Comp_Inst ?Comp_Inst_2 ?Interface) * (connected ?Comp_Inst ?Comp_Inst_2 ?Interface) * Add_Comp_Inst (component_class ?Comp) (required_comp ?Comp) Remove_Comp _Inst (component_class ?Comp) (component_class ?Comp) (required_comp ?Comp) (instance_of ?Comp_Inst ?Comp) (required_instance ?Comp_Inst) (component_class ?Comp) (required_comp ?Comp) (instance_of ?Comp_Inst ?Comp) (required_instance ?Comp) (added_comp ?Comp_Inst) (unresolved_interface ?Comp_Inst ?Interface) * (depends_on ?Comp_Inst ?Comp_Inst_2 ?Interface) * (connected ?Comp_Inst ?Comp_Inst_2 ?Interface) * (component_class ?Comp) (instance_of ?Comp_Inst ?Comp) (added_comp ?Comp_Inst) (component_class ?Comp) (instance_of ?Comp_Inst ?Comp) (instance_of ?Comp_Inst ?componnet_class) (added_comp ?Comp_Inst ) (connected ?Comp_Inst ?Comp_Inst_2 ?interface) * (component_class ?Comp) (scheduled_component_class ?Comp) (instance_of ?Comp_Inst ?Comp) (added_comp ?Comp_Inst ) (connected ?Comp_Inst ?Comp_Inst_2 ?Interface) * 1 2 3 4 7 5 6 8 15 16 17 18 Pick_Comp_Inst_or_ Instantiate_for_Requirements + Figure 5.2: General life-cycle state transition model of components. that are common to most of architecture-based adaptive systems. Detailed models are required to precisely capture the behavior of individual, specific self-adaptive systems. Figure 5.2 represents the general life-cycle of a component class (i.e., denoted as ?Comp variable) and one instance of it (i.e., denoted as ?Comp_Inst variable) in an architecture-based self-adaptive software system. States and state transitions (i.e., ac- tions) in this figure are represented as boxes and solid arrows, respectively. Dashed arrows, on the other hand, specify state transitions resulted from changes in the re- quirements (e.g., a component is not required anymore), events in the environment (e.g., 112 a component is not available due to a failure), or changes to the other objects in the software (e.g., a dependent component is not required anymore). States are described in predicate logic as combinations of boolean predicates using propositional operators. Each predicate provides a statement about one or more objects in the system. For in- stance, the(component_class ?Comp) predicate states that?Comp is acomponent_class, and (instance_of ?Comp_Inst ?Comp) states that ?Comp_Inst is an instance of ?Comp. Actions in this model are classified into two types: primitive and composite actions. Primitive actions are directly enacted on the run-time application, while composite ac- tions are composed from other composite and primitive actions. Composite actions in Figure 5.2 are marked by a “+” superscript. To help readers to relate dierent views of each action in the state transition models (Figures 5.2 and 5.3) and the adaptation HTN (Figure 5.5), the same actions are labeled with the same numbers in these figures. In its life-cycle, a component class may become required either by software re- quirements or to resolve other components’ dependencies. When a component class is required ((required_comp ?Comp)), it gets instantiated ((instance_of ?Comp_Inst ?Comp)). Then, the component instance gets added to the architecture of the system ((added_comp ?Comp_Inst)), and its interface dependencies ((unresolved_interface ?Comp_Interface?Comp_Inst) ) get resolved. 1 To this end, the component instance gets connected to other components ((connected?Comp_Inst?Comp_Inst_2?Interface) ). When a component is not required anymore, either because of the changes in the soft- ware requirements or because of the changes in its dependent components, its instances 1 Asterisk (“*”) indicates zero or more instances of a predicate. 113 Add_Conn_Inst Connect_Comp_Conn or Connect_Conn_Conn Disconnect_Comp_Conn or Disconnect_Conn_Conn Remove_Conn_Inst Instantiate_a_Conn (connector_class ?conn) (conn_instance_of ?Conn_Inst ?Conn) (connector_class ?conn) (connector ?Conn_Inst) (conn_instance_of ?Conn_Inst ?Conn) (added_conn ?Conn_Inst) (connected_comp_conn ?Comp_Inst ?Conn_Inst ?Interface) * (connected_conn_conn ?Conn_Inst ?Conn_Inst_2 ?Interface) * (connector_class ?Conn) (conn_instance_of ?Conn_Inst ?Conn) (added_conn ?Conn_Inst) (free ?Conn_Inst) 9 10 11 Finalize_Conn_Inst 12 19 5 6 20 Figure 5.3: General life-cycle state models for connector classes and instances in an architecture-based adaptive software system. are disconnected from the other elements in the architecture, removed from the architec- ture, and finalized. Full descriptions of the adaptation actions provided in Figure 5.2 are provided in Appendix A. Figure 5.3 depicts the general life-cycle of a connector class (i.e., denoted as ?Conn variable) and one instance of it (i.e., denoted as?Conn_Inst variable) in an architecture- based self-adaptive software system. Details of the adaptation actions provided in this figure can also be found in Appendix A. It is important to realize that the models provided in this section capture the life- cycle of components and connectors in a general way. Three steps are required to get the state transition models of a specific adaptive software system. First, the primitive ac- tions in these models, such as theAdd_Comp_Inst and theFinalize_Comp_inst, should be replaced by their domain-specific action implementations, such asAdd_Server_Inst and Finalize_Server_Inst. Second, the states in the models should be replaced by the domain-specific states (probably with additional domain-specific predicates). For instance, in the client-server application domain, an instance of a server should have 114 Connect_Server_Conn (component_class ?Client) (required_comp ?Client) (instance_of ?Client_Inst ?Client) (required_instance ?Client_Inst) (added_comp ?Client_Inst) (depends_on ?Client_Inst ?Server_Inst ?Client_Server_Interface) (has_capacity ?Server_Inst) ? (remaining_capacity ?Server_Inst ?x-1) (connected_comp_conn ?Server_Inst ?Server_Conn ?Client_Server_Interface) (connected_comp_conn ?Client_Inst ?Client_Conn ?Client_Server_Interface) (connected_conn_conn ?Client_Conn ?Server_Conn ?Client_Server_Interface) (connected_comp_com?Client_Inst ?Client_Conn ?Client_Server_Interface) (connected ?Client_Inst ?Server_Inst ?Client_Server_Interface) (component_class ?Client) (required_comp ?Client) (instance_of ?Client_Inst ?Client) (required_instance ?Client) (added_comp ?Client_Inst) (unresolved_interface ?Client_Inst ?Client_Server_Interface) (depends_on ?Client_Inst ?Server_Inst ?Client_Server_Interface) (has_capacity ?Server_Inst) (remaining_capacity ?Server_Inst ?x) (connected_comp_conn ?Server_Inst ?Server_Conn ?Client_Server_Interface) (connected_comp_conn ?Client_Inst ?Client_Conn ?Client_Server_Interface) (component_class ?Client) (required_comp ?Client) (instance_of ?Client_Inst ?Client) (required_instance ?Client) (added_comp ?Client_Inst) (unresolved_interface ?Client_Inst ?Client_Server_Interface) (depends_on ?Client_Inst ?Server_Inst ?Client_Server_Interface) (has_capacity ?Server_Inst) (remaining_capacity ?Server_Inst ?x) (connected_comp_conn ?Server_Inst ?Server_Conn ?Client_Server_Interface) Connect_Client_Conn Connect_Client_Server_Conns Connect_Server_Conn (component_class ?Client) (required_comp ?Client) (instance_of ?Client_Inst ?Client) (required_instance ?Client) (added_comp ?Client_Inst) (unresolved_interface ?Client_Inst ?Client_Server_Interface) (depends_on ?Client_Inst ?Server_Inst ?Client_Server_Interface) (has_capacity ?Server_Inst) (remaining_capacity ?Server_Inst ?x) (component_class ?Client) (required_comp ?Client) (instance_of ?Client_Inst ?Client) (required_instance ?Client) (added_comp ?Client_Inst) (unresolved_interface ?Client_Inst ?Client_Server_Interface) (depends_on ?Client_Inst ?Server_Inst ?Client_Server_Interface) (has_capacity ?Server_Inst) (remaining_capacity ?Server_Inst ?x) (connected_comp_conn ?Client_Inst ?Client_Conn ?Client_Server_Interface) Figure 5.4: Partial state model for a client in the domain of client-server applications. enough capacity to service a new client; hence, specific predicates to keep track of a server’s capacity are required in the state transition model of client-server applica- tions. Third, the composite actions, such as the Resolve_Dependencies_and_Compose, should be decomposed and replaced by the domain-specific primitive action implemen- tations. For instance, connecting a client to a server in the client-server domain (e.g., 115 the Image Collector and the Data Collector in Figure 5.1) requires two connector in- stances (e.g., the Client Connector and the Server Connector in Figure 5.1) that should be linked in a specific order. Consequently, the Resolve_Dependencies_and_Compose action should be decomposed to the following three actions: Connect_Server_Conn, Connect_Client_Conn, andConnect_Client_Server_Conns. Figure 5.4 depicts parts of the state transition model for a client component. The states and actions in this figure are extended to represent the behavior of the client- server domain. Note the specific order that must be followed to connect architectural elements in this model. The client and server connectors in this model must be connected to the client and server instances before they are connected to one another. Moreover, note the(has_capacity?Server_Inst) and(remaining_capacity?Server_Inst ?x) predicates which determine whether the?Server_Inst has any remaining capacity and ?x more clients can connect to the?Server_Inst, respectively. 5.2.2 General Adaptation HTN I captured the general actions required in the domain of software adaptation in an HTN, depicted in Figure 5.5. The composite actions (e.g., Adapt) in this HTN are composed from other composite and primitive actions (connected to the bottom of the composite actions) that should be performed in the defined order (from left to right). The actions depicted in the plain boxes determine the common composite adaptation actions in the general domain of architecture-based software adaptation, while the highlighted boxes specify adaptation actions that vary from one domain to another. As mentioned before, 116 Check for Final Constraints Delete Excessive Comp Inst Delete Excessive Conn Inst Adapt Delete Removable Components Initialize the Domain Finalize Domain Resolve Dependencies and Compose Pick or Instantiate Required Comps Delete Removable Components Unemploy Comp Inst Unweld Comp Inst Finalize Comp Inst Pick or Instantiate Required Comps Pick Comp Inst or Instantiate for Requirements Resolve Dependency of a Comp Interface Resolve Dependencies and Compose Weld Dependent Component Instances Pick a Comp Delete Excessive Comp Inst Unemploy Comp Inst Unweld Comp Inst Finalize Comp Inst Remove Comp Inst Pick Comp Inst or Instantiate for Dependency Unemploy Conn Inst Delete Excessive Connectors 1 16 4 5 18 6 8 9 10 13 Add Comp Inst 15 Add Comp Inst 3 Add Conn Inst ... Weld Comp Insts Directly Instantiate a Conn 2 17 19 ... 20 Should be performed in this order ... ... ... Weld Comp Insts Using Conns ... Remove Conn Inst 11 Finalize Conn Inst 12 Remove Comp Inst 7 Employ a New Connector Check for Global Constraints Figure 5.5: An overview of general adaptation actions in the domain of architecture- based software adaptation captured in an HTN. the number label of each action in Figure 5.5 can be used to find the state transition view of that action in Figures 5.2 or 5.3. 117 Instantiate a Conn Instantiate a Pipe Instantiate a Client Connector XOR Instantiate a Filter Instantiate a Peer- to-Peer Connector Instantiate an Event-bus Instantiate a Servre Connector 9 Figure 5.6: Decomposition of a primitive action to exclusive disjunction of domain- specific action implementations. To customize this HTN to a specific domain, each primitive variable action in this HTN is decomposed into the exclusive disjunction of all domain-specific implemen- tations of that action. For instance, the example domain in Figure 5.1 involves pipe- and-filter, client-server, implicit invocation, event-based, and peer-to-peer architectural styles. In this domain, the Instantiate_a_Conn action (labeled 9 in Figure 5.5) would be decomposed into the exclusive disjunction of the implementations of the instantiate connector actions in its sub-domains and styles, as depicted in Figure 5.6. Domain- and style-specific primitive actions, in this figure, are drawn in dashed boxes. Note that the pre-condition of only one of the actions in this exclusive disjunction would be applicable to each connector class in this domain. The variable composite actions, on the other hand, provide extra dimensions of vari- ability (compared to the variable primitive actions). They allow an arbitrary set of their primitive actions to be selected in any arbitrary order. To illustrate, the complete de- composition of the Weld_Comp_Insts_Using_Conns composite action (in Figure 5.5) is provided in Figure 5.7. This composite action welds two dependent component instances 118 Add Conn Inst Instantiate a Conn Weld Comp Insts Using Conns Employ a New Connector Connect Components Connectors Weld Comp Insts Using Conns Connect Component Connector Connect Connector Connector Pre-connect Required Disconnects Disconnect Component Connector Disconnect Connector Connector 19 20 Figure 5.7: Decomposition of a composite action. using some connectors. Each of the variable primitive actions in this figure will be de- composed to exclusive disjunction of several domain-specific action implementations (similar to the decomposition in Figure 5.6). The decomposition structure in Figure 5.7 provides an iterative structure. Namely, theWeld_Comp_Insts_Using_Conns action is de- composed to some other actions and theWeld_Comp_Insts_Using_Conns itself; therefore, this action will be repeated until the two components under adaptation are connected. In each iteration, one or more primitive actions are employed based on the system’s run-time state. To illustrate further, consider the two dierent initial states depicted in Figure 5.8, which describe two possible states of the running example before the Image Collector and Data Collector are connected. The Weld_Comp_Insts_Using_Conns, in state (a), decomposes to 1. (Instantiate_a_Client_Connector Client_Connector) 2. (Add_Client_Conn_Inst Client_Connector) 119 (a) (b) Pipe Connector Client Connector Image Collector Data Point Data Collector Pipe Connector Server Connector Image Collector Data Point Data Collector Figure 5.8: Two example initial states before Image Collector and Data Collector are welded. 3. (Connect_Client_Conn Client_Connector Image_Collector) (Weld_Comp_Insts_Using_Conns) 4. (Connect_Client_Server_Conns Client_Connector Server_Connector) (Weld_Comp_Insts_Using_Conns) , while in state (b), it decomposes to 1. (Instantiate_a_Server_Connector Server_Connector) 2. (Add_Server_Conn_Inst Server_Connector) 3. (Connect_Server_Conn Server_Connector Data_Collector) (Weld_Comp_Insts_Using_Conns) 4. (Connect_Client_Server_Conns Client_Connector Server_Connector) (Weld_Comp_Insts_Using_Conns). Note that the decomposition of the Weld_Comp_Insts_Using_Conns in both cases is stopped after the second iteration, because the components are connected at that point. As a result, when an application is composed from various architectural elements with dierent adaptation requirements, 6A’s composition algorithm chooses and enacts 120 the specific adaptation actions that are applicable to specific types of each architectural element based on the system’s state at the time of adaptation. The adaptation HTN provided in this section is able to provide any kind of software adaptation on its underlying software domain. To this end, theAdapt task in this model always decomposes to the tasks that calculate a goal architecture for the system under adaptation, compare that architecture to the current architecture of the system, and enact adaptation operations to change the system’ current architecture to its goal architecture. The resulting adaptation operations only aect parts of the architecture that must be changed, and the rest of the architecture stays intact. 5.3 Approach To create an adaptable composition algorithm, 6A employs three techniques. First, 6A employs the adaptive layered architectural style (as prescribed by PLASMA) to enable adaptation of the meta-components. Second, 6A separates the adaptation logic of the system from the tools that enforce the adaptation logic, by utilizing an AI planning tech- nique. Third, 6A synthesizes, manages, and adapts the adaptation logic (i.e., software artifacts required for the planning) at run-time. 6A’s design matches the methodology provided by PLASMA, as depicted in Fig- ure 5.3.1. PLASMA provides a three-layer architecture in which each layer monitors, manages, and adapts the layer below. 6A leverages architectural models of components to synthesize the adaptation artifacts required by PLASMA. Moreover, 6A enables the 121 Synthesis Layer of PLASMA to autonomously calculate and adapt the architecture of the Adaptation Layer. In AI planning techniques, a planner finds a sequence of actions (i.e., a plan) to achieve the high-level goal of a system. There are two classes of planners that can be used by 6A: classical/neoclassical planners, and hierarchical task network (HTN) planners. Planners in both of these classes require a description of the domain under adaptation. The description of a domain specifies the states of the world (represented by a set of atoms) and actions in the domain (described in the form of state transitions). However, these classes of planners are dierent in what they plan for and how they plan for it. Objective of classical/neoclassical planners is to reach the goal state of the system, while the objective of the HTN planners is to perform a set of high-level tasks. Moreover, a domain description for an HTN planner also includes a set of methods that prescribe how high-level tasks can be decomposed to primitive tasks in the domain (i.e., domain actions). Methods in each domain provide a way to describe how a human would solve a problem in that domain [39]. In other words, methods provide domain-specific problem- solving knowledge to HTN planners, in order to help planners to solve problems faster. The ability to use domain-specific problem-solving knowledge improves a planner’s performance dramatically. Experimental studies [9, 74, 76] shows that “hand-tailorable” planners, such as HTN planners, have solved planning problems orders of magnitude faster than “fully automated” planners that only receive domain actions as domain- specific knowledge [75]. Authors of [39] claim that HTN planners has been used for practical applications more widely than any other planning technique described in their book [39]. 122 Since the adaptation goals in the domain of software adaptation can be expressed by a general set of high-level adaptation actions (recall Section 5.2.2), the latter planning approach suites the domain of software adaptation. Particularly, 6A utilizes Simple Hi- erarchical Ordered Planner 2 (SHOP2) [76], an HTN Planner, to find a plan that performs general high-level adaptation actions whenever Run-time Application (see Figure 5.10) needs to be adapted. 2 These actions involve: taking away removable components, se- lecting appropriate components to satisfy software requirements, resolving component dependencies, inter-connecting the dependent components, etc. In addition, 6A ap- plies the same technique to adapt meta-components in the Adaptation Layer whenever adaptation requirements of the system change. To plan, SHOP2 requires a description of the available tasks in the planning domain in form of an HTN. To make 6A’s composition algorithm dynamic, I use SHOP2 in a novel way. Namely, I dynamically synthesize and maintain the HTN required by SHOP2. This HTN captures the adaptation actions, structural constraints, and optimization criteria applicable to a software system. In the rest of this section, my running example is leverages to clarify dierent aspects of the 6A approach. Assume the conditions in which theRobot1 is not collecting images. The architecture of the running example at this state is depicted in Figure 5.9. Also, assume that new requirements necessitateRobot1 to collect images and send them to the DataPoint. In section 5.3.1, I first provide an architectural view of 6A implemented in the context of PLASMA. Then, in Section 5.3.2, I provide specifications of SHOP2. Section 5.3.3 2 http://www.cs.umd.edu/projects/shop/ 123 Peer-to-Peer Connector Peer-to-Peer Connector Pipe Connector Pipe Connector Pipe Connector Pattern Recognition Server Connector Noise Filter Filter Interface Legend Peer-to-Peer Interface Component Color Codes Pipe Interface Implicit Invocation Required Interface BLACK Provided Interface WHITE Client Interface Server Interface Connector Event Interface Navigation Robot Collaboration Event Bus Peer-to-Peer Connector Peer-to-Peer Connector Robot Collaboration Robot 2 Robot 1 Data Point Data Collector Camera Robot Steering Figure 5.9: Partial architectural view of the disaster response application, after adapta- tion. describes the HTN used in 6A. Finally, in Section 5.3.4, I provide an adaptation language that presents the internal logic of 6A. 5.3.1 6A architecture Figure 5.10 depicts an architectural view of 6A, implemented in the context of PLASMA (described in Chapter 4). The 6A HTN Synthesizer leverages the architectural models of the meta-level components to synthesize a dynamic adaptation HTN (i.e., the 6A HTN) at run-time. This component updates the 6A HTN when the adaptation logic of the system changes. In my running example, an admin component to support the client-server style, the Client Server Admin, is provided to the 6A. Therefore, the 6A 124 Adaptation Layer Synthesis Layer software requirements (Run-time Application) synthesis plan Run-time Application Collector Collector Collector Adaptation Analyzer Admin Admin Admin Application Layer Logic Manager Analyzer . . . Analyzer’s behavior (Adaptation Layer) Collector Admin Application Layer Model Manager dynamic 6A HTN adaptation plan software requirements (Adaptation Layer) static adaptation HTN Adaptation Layer Architecture Manager SHOP2 Adaptation Planner Adaptation Plan Analyzer Adaptation Layer Adaptation Logic Manager SHOP2 Application Planner Adaptation Plan Analyzer Adaptation Layer Requirement Analyzer Adaptation Layer Model Manager 6A HTN Synthiszer Application Problem Domain Generator Adaptation Layer ADL models user’s quality preferences Application Layer ADL models Analyzer’s behavior (Synthesis Layer) Adaptation Problem Domain Generator Legend Adaptation Component Application Component Admin Collector Adaptation Logic Evaluator Adaptation Logic Manager Architectural Model Manager Figure 5.10: 6A in the context of PLASMA. HTN includes the adaptation operations required to manipulate architectural elements related to the client-server style. When adaptation is required, theSHOP2ApplicationPlanner calculates a new topol- ogy for the Run-time Application and an adaptation plan; in turn, the adaptation plan adapts the Run-time Application from its current topology to its new topology. This component requires the software requirements (i.e., a list of required components), the 125 ... (component_class Image_Collector_Comp) (component_type_of Image_Collector_Comp prism_mw_comp) (interface_type_of image_interface_1 client_image_interface_type) (interface_type_of image_stream_interface_1 filter_image_interface_type) (req_interface_of Image_Collector_Comp image_interface_1) (req_interface_of Image_Collector_Comp image_stream_interface_1) ... (component_class Data_Collector_Comp) (instance_of Data_Collector_Comp Data_Collector) (interface_type_of image_interface_2 server_image_interface_type) (prov_interface_of Data_Collector_Comp image_interface_2) ... (prov_interface_of Camera_Comp image_stream_interface_2) ... Figure 5.11: An excerpt of the applications’s current state of the running example. current state of the application (i.e., a description of the architectural elements both in the Run-time Application and in the system’s application repository), and the 6A HTN. In my running example, the new software requirement includes the (required_comp Image_Collector_Comp) predicate. Moreover, the current state of the system includes information on the interfaces of theImageCollector,DataCollector, andCamera. An excerpt of the system’s current state in my running example is provided in Figure 5.11. The planner in this case calculates a plan that instantiates theImageCollectorComp to create theImageCollector instance, resolves the instance’s dependencies by matching its required interfaces to the provided interfaces of theCamera andDataCollector com- ponent instances, and welds dependent interfaces using some connectors. An excerpt of the adaptation plan is provided in Figure 5.12. The generated adaptation plan is utilized in two ways. First, the Adaptation Plan Analyzer translates the adaptation plan into a form executable by the Adaptation Analyzer in the Adaptation Layer. Second, theAdaptationLayerRequirementAnalyzer 126 ... (Instantiate_a_Client Image_Collector_Comp Image_Collector) (Add_a_Client_Comp Image_Collector) (Instantiate_a_Client_Connector Client_Connector) (Add_Client_Conn_Inst Client_Connector) (Connect_Client_Conn Client_Connector Image_Collector) (Connect_Client_Server_Conns Client_Connector Server_Connector) (Instantiate_a_Pipe_Connector Pipe_Connector) ... Figure 5.12: An excerpt of the adaptation plan for the running example. extracts a list of meta-level components required to run the adaptation plan, and pro- vides it (as software requirements) to the Adaptation Layer Architecture Manager. In the case of my running example, the adaptation plan, as shown in Figure 5.12, involves actions from the Client Server Admin meta-level component. Therefore, the software requirement (for the Adaptation Layer) includes the (required_comp Client_Server_ Admin_Comp) predicate. The Adaptation Layer Architecture Manager manages and adapts the Adaptation Layer. The SHOP2 Adaptation Planner uses a static adaptation HTN, the current state of the adaptation engine (i.e., a description of the architectural elements both in the Adaptation Layer and in the system’s meta-level repository), and the software adaptation requirements (i.e., a list of required meta-level components) to find a synthesis plan to manage and adapt the architecture of the Adaptation Layer. As shown in Figure 5.10, this plan is used to generate the behavior for the Analyzer in the Synthesis Layer. This Analyzer adapts the Adaptation Layer to the changes of the system’s adaptation logic. Note that the static adaptation HTN reflects the provided adaptation actions by theAdmin component in the Synthesis Layer. An excerpt of the synthesis plan, in the case of my running example, is provided in Figure 5.13. 127 ... (Instantiate_a_Meta_Comp Client_Server_Admin_Comp Client_Server_Admin) (Add_a_Meta_Comp Client_Server_Admin) (Connect_Meta_Comps Client_Server_Admin Adaptation_Analyzer) ... Figure 5.13: An excerpt of the synthesis plan for the running example. Architectural models of the application-level components are used by the Applica- tionProblemDomainGenerator to generate the current state of an application including the architectural elements available in the system’s application repository and their properties as well as the architectural elements in the Run-time Application and their inter-connections. Figure 5.11 provides an excerpt of the current state of a system. Similarly, the Adaptation Problem Domain Generator generates a description of the current state of a system’s adaptation engine, from the architectural models of the meta- level components and the topology of the Adaptation Layer. 5.3.2 SHOP2 SHOP2 is an ecient HTN planning system with many advanced features compared to the other HTN planners [39, 75]. SHOP2 requires a description of domain actions in form of an HTN. SHOP2 HTNs provide a set of methods to decompose the high-level tasks to other high-level tasks and primitive tasks. SHOP2, finds a plan by recursively decomposing the high-level tasks of the system into subsequently smaller tasks until it reaches the primitive tasks that can be enacted on the system directly. SHOP2 receives the system’s initial state, and keeps track of the system’s state as it decomposes tasks and adds operators to the plan. 128 (:method (delete_excessive_components) There_is_excessive_component ;pre-condition ( (comp_is_added_to_arch ?comp_inst) (not(required_comp ?comp_inst) ) ;decomposition ( (un_weld ?comp_inst) (un_employ ?comp_inst) (delete_excessive_components) ) No_more_excessive_components ;pre-condition (nil) ;decomposition () ) Figure 5.14: An example method in SHOP2. SHOP2 may provide multiple methods to decompose a composite task in dierent system’s conditions. For instance, the methoddelete_excessive_components depicted in Figure 5.14 is decomposed dierently in dierent conditions. If there is a?comp_inst added to the architecture while it is not required by the system, the task will be decom- posed to Unweld and Unemploy the ?comp_inst, and delete_excessive_components. Otherwise, the task is done and will not be decomposed further. In other words, this taskUnweld andUnemploy all the excessive?comp_insts in the architecture. Primitive tasks, operators, in SHOP2 are specified by their pre- and post-conditions. Figure 5.15 provides an example operator from the domain of software adaptation. This operator connects a data consumer component to a data connector. As shown in this example, the pre- and post-conditions in SHOP2 are described in three lists of logical expressions. The first list (i.e., the pre-conditions in the figure) determines the state of the 129 (:operator (!connect_data_connector_to_data_consumer ?data_consumer ?conn_inst ?interface) ;pre-conditions ( (instance_of ?data_consumer ?comp) (component_class ?comp data_consumer_comp_class) ... (free_data_port ?data_consumer) (free ?conn_inst) (time_to_connect_to_connector ?conn_inst ?t) ) ;remove list ( (free_data_port ?data_consumer) (free ?conn_inst) ) ;add list ( (hooked_data_port ?data_consumer ?conn_inst ?interface) (connected_comp_conn ?data_consumer ?conn_inst ?interface) ) ;operator cost (?t) ) Figure 5.15: An example operator in SHOP2. system in which the operator is applicable. The second list (i.e., the remove list in the figure) describes predicates that must be removed from the system’s state. And the third list (i.e., the add list in the figure) includes the predicates that must be added to the system’s state. Logical expressions in SHOP2 may include conjunctions, disjunctions, negations, universal and existential quantifiers, implications, numerical computations, and external function calls (allows to call Lisp functions defined outside of the planning domain). SHOP2 also provides axioms to infer pre-conditions that are not explicitly asserted in the current system’s state. For instance, the following provides an axiom that infers 130 whether a component isLinked to another component either directly or through a series of components: (:- (Linked ?comp_inst1 ?comp_inst2) ;returns true if the following condition holds. ((Linked_sub_axiom ?comp_inst1 ?comp_inst2 (LIST))));(LIST) creates an empty list (:- (Linked_sub_axiom ?comp_inst1 ?comp_inst2 ?list) ;returns true if any of the two conditions below holds. directly_connected ;(condition 1) ((connected ?comp_inst1 ?comp_inst2 ?interface)) recursively_connected ;(condition 2) ((connected ?comp_inst1 ?comp_inst ?interface) (assign ?list2 (append '(?comp_inst1) ?list)) (not(eval (member '?comp_inst '?list2))) (Linked_sub_axiom ?comp_inst ?comp_inst2 '?list2))) In addition, SHOP2 is able to search for the optimized plan to solve a problem. To this end, a cost value is associated with each operator in the domain, and SHOP2 finds a plan with lowest total operator cost. When SHOP2 evaluates the pre-conditions of methods it may get several sets of variable bindings, each of which may lead to a dierent plan. SHOP2 utilizes depth-first backtracking to try all possible branchings in order to find the optimal solution. However, one may define a time value to limit this search. In this case, SHOP2 returns the best solution that can be found in the specified time limit. SHOP2’s detailed specification can be found in [75]. 5.3.3 6A Adaptation HTN 6A dynamically provides SHOP2 with the adaptation logic of a system in form of an HTN, called the 6A HTN. 6A dynamically synthesizes this HTN from three main ingredients: (1) adaptation actions, (2) structural constraints, and (3) cost functions. In this section, I explain each of these ingredients in detail. Later, in Section 5.4, I explain how these ingredients are provided to 6A as part of architectural models of a system’s elements. 131 Adaptation Actions. 6A divides actions in the domain of software adaptation into two parts: common adaptation actions and domain-specific adaptation actions. 6A provides the common adaptation activities required by composition algorithms and lets domain architects provide the domain-specific adaptation actions. For instance, all the adaptation actions provided in Figure 5.5 are common adaptation actions, while actions in the dashed boxes in Figure 5.6 are domain-specific adaptation actions. Structural Constraints. I recognize three types of structural constraints: local, global, and final. Local structural constraints are defined implicitly as pre-conditions of adapta- tion operations; while global and final structural constraints can only be enforced on the whole architecture of the system. Global structural constraints (e.g., an acyclic config- uration) are defined explicitly and are enforced each time a component is added to the configuration of the system. Finally, final structural constraints (e.g., a ring configura- tion) are defined explicitly and are enforced as the last task in the adaptation HTN. Note that final constraints can only evaluated when the whole configuration of the system is available; while global structural constraints can be also evaluated on partial config- urations (they can also be tested in the whole configuration). Later, in Section 5.5, I show that defining constraints as global where possible (instead of defining all structural constrains as final) may result in performance advantages. Consequently, 6A provides the structural constraints of a system in form of two adap- tation method, depicted as theCheck_for_Final_Constraints andCheck_for_Global_ Constraints methods in Figures 5.5 and 5.16. The pre-condition of the Check_for_ Final_Constraints is the conjunction of all final structural constraints in a system. Sim- ilarly, the pre-condition of theCheck_for_Global_Constraints is the conjunction of all 132 global structural constraints in a system. To have a valid plan, the pre-conditions of these methods must evaluate totrue, unless SHOP2 backtracks and tries other decomposition options to find a dierent plan. For instance, many architectural styles (such as C2) specify structural constraints to avoid cycles in the system’s topology. The structural constraint provided in Figure 5.16 describes that the topology should be cycle-free. The (reaches_a_loop ?comp_inst) axiom in this figure, infers whether there is a cycle in the architecture that can be reached from?comp_inst. Note that domain architect provides the structural rules and axioms in an ADL modeling language, and 6A converts the ADL models to SHOP2 language. Cost Functions. To find optimized plans, SHOP2 calculates the cost of adaptation plans by summing up the cost of individual operations. Cost functions are required by 6A to optimize either the cost of the adaptation plan (e.g., the maximum time that it takes to run the adaptation plan) or a criteria of the run-time application (e.g., the maximum delay of connectors in the run-time application). As shown in Figure 5.15, each operator in SHOP2 provides a cost value. SHOP2 compares the cost of dierent plans applicable to solve a problem and chooses the plan with the lowest cost. In 6A, this cost can be defined as a constant value or a function of the architectural elements. Complicated cost calculations (e.g., calculation of an average value) may require SHOP2 to keep track of extra variables and predicates. To handle complicated cost functions, 6A allows domain architects to define their own cost functions as separate operators. 6A autonomously groups each cost operators with it related adaptation operator and runs it immediately after its associated operators. Note that in this case the cost variable of the associated operator is set to zero. 133 (:method (check_for_global_constraints) ;Constraints come from ADL models of the domain-specific architectures. (; an example constraint (forall (?comp_inst) ((instance_of ?comp_inst ?comp_class) (required_comp ?comp_class)) ((not(reaches_a_loop ?comp_inst)))) ) ;subtasks. Do nothing if the constraints hold () ) (:- (reaches_a_loop ?comp_inst) ((reaches_a_loop_sub_axiom ?comp_inst ?comp_inst (LIST))) (:- (reaches_a_loop_sub_axiom ?comp_inst1 ?comp_inst2 ?list) loop_to_start_point ((connected ?comp_inst1 ?comp_inst2 ?interface)) loop_to_middle_of_path ((connected ?comp_inst1 ?comp_inst ?interface) (eval (member '?comp_inst ?list))) loop_starting_at_next_component ((connected ?comp_inst1 ?comp_inst ?interface) (assign ?list2 (append '(?comp_inst1) ?list)) (not(eval (member '?comp_inst '?list2))) (reaches_a_loop_sub_axiom ?comp_inst ?comp_inst2 '?list2))) Figure 5.16: The method to check the structural constraints in the 6A HTN with an example constraint. Figure 5.17 provides an example cost operator that calculates the average utility of the components added to an architecture. This function implements the approach provided in [92]. Given that the utility value of each component is proportional to the desirability of a component to the end-user, using this cost function 6A finds an architecture with the highest average value for the component utilities. As demonstrated in this example, 6A allows domain or application architects to virtually design any optimization criterion by designing appropriate cost functions for any adaptation operator in a system. Finding optimized adaptation plans may require exponential processing time. In fact, 6A can be utilized (by providing appropriate operations) to search for sub-optimal 134 (:operator (!!add_component_inst_cost ?comp_inst) ( (instance_of ?comp_inst ?comp) (component_utility ?comp ?utility) (averageUtil ?averageUtil) (totalUtil ?totalUtil) (compCount ?compCount) (currentCost ?cost) (assign ?newCompCount (call + ?compCount 1)) (assign ?newTotalUtil (call + ?totalUtil ?utility)) (assign ?newAverageUtil (call / (+ ?totalUtil ?utility) (+ ?compCount 1) )) ) ( (averageUtil ?averageUtil) (totalUtil ?totalUtil) (compCount ?compCount) ) ( (averageUtil ?newAverageUtil) (totalUtil ?newTotalUtil) (compCount ?newCompCount) ) (- (- 1 ?newAverageUtil) (- 1 ?averageUtil)) ) Figure 5.17: A customized method to calculate cost values in SHOP2. plans. In Section 5.5, I evaluate the accuracy vs. performance trade-os of 6A when it is set up to find sub-optimal plans. 5.3.4 6A Adaptation Language To guide domain architects in the design of adaptation actions for domain- or style- specific meta-components, I present the 6A HTN in form of regular expressions, as the 6A adaptation language. The 6A adaptation language is provided in Appendix A. This language defines (1) the common high-level adaptation actions (e.g., the Adapt at Line 1), (2) the variable primitive adaptation actions (e.g., the Instantiate_a_Comp at Line 90), (3) the possible 135 ; List of components to be removed (removable_comp data_stream_comp) ; List of components to be added (required_comp data_client_comp) (required_comp temperature_mapper_comp) Figure 5.18: An example of functional requirements used by 6A. orderings of the adaptation actions (e.g., theUnweld_Comp_Inst should be enacted before the Unemploy_Comp_Inst in the Delete_Excessive_Comp_Insts at Line 40), and (4) the expected input/output arguments of the adaptation actions (e.g., theUSER_INSTANTIATE_ COMP at Line 91 needs a component class,COMP, as input argument and returns a compo- nent instance,COMP_INST). This language describes relevant parts of the adaptation HTN in a human readable form. For instance, the partial task decomposition in Figure 5.7 is provided at Line 190. Domain architects must design and provide the domain-specific adaptation operations in accordance to this language. Section 5.4.4 provides all the adaptation operations required for the domain of client-server architecture. 5.4 Software Adaptation Artifacts To operate, 6A requires several software artifacts including software requirements, ar- chitectural models of application level-elements, meta-components, and architectural models of meta-components. This section describes these artifacts, their requirements, why they are required, when they are provided to 6A, and who designs and provides them. 136 5.4.1 Software Requirements In declarative approach to software self-adaptation, software requirements guide the composition algorithm to compose and adapt a software system. 6A accepts three types of requirements: functional requirements, structural constraint, and quality require- ments. Software requirements in 6A are provided and may change at run-time. Functional requirements describe a list of required and removable components in predicate logic. The required components are expected in the target architecture of a system, while the removable components are already in the system’s architecture, however they are either not required anymore or failed at run-time and must be removed. Figure 5.18 provides an example that specifies functional requirements to remove one and add two components. Note that removing or adding a component may result in removing and adding their depended-on components. Functional requirements are provided (in)directly by software end-users. For instance, PLASMA’s end-users indirectly provide functional requirements in form of application goal states, and PLASMA derives the component requirements from them. Structural constraints determine the rules that apply to the topology of a system. They are usually grouped and classified as part of an domain- or style-specific software properties. Local structural constraints are usually specified as pre-conditions of meta- components’ operations. For instance, pre-conditions of the connect operation of an admin component would not permit connection of a client component to another client component. Global structural constraints (e.g., no cycles in C2 style), on the other hand, are specified as invariants of domain- or style-specific architectures (e.g., client-server 137 architecture). Structural constraints are provided by domain or application architects. Section 5.4.2 provides more details of structural constraint specifications. Quality requirements quantify the end-user’s preferences on dierent quality aspects of a system. 6A supports two types of quality requirements. First, application quality requirements determine the end-user’s preferences on various quality aspects of the run-time application (e.g., to consume least CPU resources). This type of requirements is provided by an end-user in form of quality aspect weights (i.e., a number between 0 and 1) that determine the distribution of the end-user’s preference on each property aspect. For instant: w(minimal_cpu_usage)=.8 w(minimal_memory_usage)=.2 Note that the set of weight values must sum to 1. Second, adaptation quality requirements determine the end-user’s preferences on various aspects of adaptation actions elected in an adaptation plan (e.g., to take minimal time to execute). 5.4.2 Architectural Models for Application Elements To model application elements, 6A requires an architectural modeling notation that captures the following properties: Component quality properties. These properties are required by 6A to analyze and compare the quality properties of alternative architectural topologies. Quality properties in 6A are provided as pairs of quality aspects and their associated utility values. The utility value of each property is a real number between 0 to 1, where 1 is the most useful value. To this end, the notation and approach provided by Sykes 138 architecture C2 is{ state { C2Comps: \set C2Component; C2Conn: \set C2Connector; ...} invariant{ forall (comp_inst:Component_Inst) (((instance_of(comp_inst, comp_class)) \and (required_comp(comp_class))) \implies (\not(reaches_a_loop(comp_inst))));} operations{ axiom reaches_a_loop:{ let comp1:C2Component;compSet:\set C2Component; pre reaches_a_loop_sub_axiom(comp1,comp1,compSet);} axiom reaches_a_loop_sub_axiom:{ let comp1:C2Component; comp2:C2Component;compSet:\set C2Component;compSet2:\set C2Component; pre connected(comp1,comp2,interface); pre connected(comp1,comp3,interface) \and (comp3 \in compSet); pre (compSet2=comp1 \union compSet) \and connected(comp1,comp3,interface) \and (comp3 \not_in compSet2) \and reaches_a_loop_sub_axiom(comp,comp2,compSet2));} ... Figure 5.19: An example of ADL models of the C2 architecture. et al. [92] is adopted. For instance, CPU and memory usage of a component can be described as below: cpu_usage:0.1 memory_usage:0.9 This information and the end-user’s preferences on each quality property (i.e., quality aspect weights described in Section 5.4.1) is used by 6A to calculate a utility value for each component as: ComponentUtility = P W p U p . 139 Note that component utility values are calculated and updated based on real run- time conditions by theApplicationLayerModelManager. Management of utility values is out of the scope of this dissertation. Component adaptation quality properties. These properties are required by 6A to analyze and compare alternative adaptation plans. Adaptation quality properties are provided as pairs of adaptation quality aspects and their associated values. For instance, the architectural model of a connector may specify the time that it takes for the connector to be linked to a component: connect_time:5 Required and provided interfaces and their properties. Interface descriptions are required by 6A to resolve component dependencies. Interface properties are domain- or style-specific. For instance, in the domain of event-based systems (e.g., in DRADEL [67]), interfaces are specified by their pre- and post-conditions, while in the domain of data-flow systems (e.g., in [3]) interfaces are specifies based on data relations (data queries). Domain- or style-specific structural constraints. Architectural models of the ar- chitecture elements must capture the structural constraints in predicate logic. For example, Figure 5.19 depicts parts of the architectural model of the C2 architecture. Application component models are provided to 6A at run-time by application architects, while the architecture models are provided by the domain architects. In this dissertation, I used SADEL as the ADL modeling language 4.2.2. The grammar of this language is provided in Appendix B. 6A translates SADEL models into the SHOP2 140 language. In contrast to SHOP2, SADEL is a typed language. Consequently, 6A ignores types when it translates SADEL models to SHOP2. 5.4.3 Meta-components Admin components provided to 6A must provide adaptation actions specified as varia- tion points in Appendix A. Meta-components are usually designed by domain architects and provided to 6A at run-time. Adaptation actions that alter the run-time application (e.g., the USER_ADD_COMP in 6A language) usually depend on the operations provide by the underlying platforms and frameworks (e.g., Prism-MW provides interfaces to add and remove components to architectures). Platform architects are in charge of providing these basic operations. 5.4.4 Architectural Models of Meta-components Architectural models of meta-level elements are utilized by 6A to synthesize the 6A HTN, to determine the architecture of the adaptation layer, and to specify the cost function for adaptation actions. Therefore, to be used by 6A, an architectural modeling notation needs to capture the following properties: Required and provided interfaces and their behaviors. Interface behaviors (i.e., the behavior of their associated operations) must be provided in form of pre- and post-conditions. In the one hand, interface behaviors are used to synthesize the 6A HTN. On the other hand, they are required to resolve the component dependencies in order to calculate the architecture of the Adaptation Layer. 141 component Admin is{ state { Connected : Component_Class , Connector -> Boolean; Component_Instant_Exist : Component_Inst -> Boolean; ... } interface{ prov AddComponentToArchitectureInterface: AddComponentToArchitecture (comp_inst: Component_Inst); prov instantiateCompInterface: instantiatComponent (comp:Component_Class comp_inst:Component_Inst); ...} operations{ prov opInstantiateComponent:{ let comp:Component_Class; comp_inst:Component_Inst; pre (\not(Component_Instant_Exist(comp_inst))) \and (Time_To_Instantiat(comp,t)); post Component_Instant_Exist(comp_inst); cost t;} prov opAddComponentToArchitecture:{ let comp_inst:Component_Inst; pre (\not(added_comp(comp_inst))); post added_comp(comp_inst); cost 0;} costFun averageCompUtility:{ let comp_inst: Component_Inst; pre instance_of(comp_inst,comp) \and component_utility(comp,utility) \and averageUtil(averageUtil) \and totalUtil(totalUtil) \and compCount(compCount) \and (newCompCount=compCount + 1) \and (newTotalUtil=(totalUtil + utility) \and (newAverageUtil=(totalUtil + utility) / (compCount + 1)); post \not averageUtil(averageUtil) \and \not totalUtil(totalUtil) \and \not compCount(compCount) \and averageUtil(newAverageUtil) \and totalUtil(newTotalUtil) \and compCount(newCompCount); cost ((1 - newAverageUtil) - (1 - averageUtil));} ...} map6a{ opInstantiateComponent -> Instantiate_a_Comp (comp -> COMP, comp_inst -> COMP_INST); opAddComponentToArchitecture -> Add_Comp_Inst (comp_inst -> COMP_INST); ...} ...} Figure 5.20: An example SADEL model of an adaptation component. cost t can be replaced with cost averageCompUtility(comp_inst) for a dierent optimization be- havior. 142 Cost function for adaptation actions. These functions can either be provided as simple in-line cost functions, or separate cost operations. An example of each type is provided in Figure 5.20. Cost functions determine the type of optimization that will be employed by 6A. In the current shape, of the example, 6A searches for an adaptation plan with least required time for component instantiation. Replacing cost t with cost averageCompUtility(comp_inst) results in adaptation opti- mization to maximize the average utility value of components in the architecture. Operation to 6A language mapping. 6A synthesizes the 6A HTN by decomposing the variable actions to their domain- or style-specific implementations. To this end, domain architects needs to specify how the domain- or style-specific operations map to the actions in the 6A language. For instant, see themap6a part in Figure 5.20. ADL models for meta-components are provided and updated by domain architects at run-time. To illustrate further, in the rest of this section, I list all variation points in the 6A adaptation language and provide their style-specific implementations for an example style, client-server style. This helps readers to provide their own adaptation operations for an arbitrary domain. USER_PICK_A_COMP(TO_RESOLVE_COMP IN_COMP_CLASS TO_RESOLVE_INTERFACE) returns OUT_COMP_CLASS This operation signature is to search for a component class that resolves dependency of TO_RESOLVE_COMP component instance, which is an instance of IN_COMP_CLASS component class for one of its interfaces, TO_RESOLVE_INTERFACE. This operation 143 returns a component class,OUT_COMP_CLASS. Note that this operation only needs to be provided in the model of a meta-component and does not need an implemen- tation. That is because functionality of this operation is only useful at the time of adaptation planning. Moreover, I assume that server components in my example domain does not have required interfaces. Therefore, I only provide one operation to resolve dependencies of client components, and do not provide any operation to resolve dependencies of server components. prov pick_a_server: { let to_resolve_comp, in_comp_class, to_resolve_interface, out_comp_class: Object; sortBy utility asc; pre component_class_utility(out_comp_class, utility) \and prov_interface_of(out_comp_class, to_resolve_interface) \and \not scheduled_to_remove(out_comp_class); post ; cost 0;} SHOP2 tries all possible values forout_comp_class variable (variable bindings) to find a variable binding that satisfies the pre-condition. sortBy directive enforces the preferred ordering in which variable bindings are tested on pre-conditions in SHOP2. Therefore, (sortBy utility asc;) tells SHOP2 to consider components with higher utilities first. The above operation only considers name conformance to resolve the dependencies of two components. However, an operation could be 144 provided to resolve dependencies based on the type conformance. In this case, an axiom is required to check dependencies: prov pick_a_server: { let to_resolve_comp, in_comp_class, to_resolve_interface, out_comp_class: Object; sortBy utility asc; pre component_class_utility(out_comp_class, utility) \and prov_interface_of(out_comp_class, matching_interface) \and interface_type_of(to_resolve_interface, to_resolve_interface_type) \and interface_type_of(matching_interface, matching_interface_type) \and axiom_sub_type_of(matching_interface_type, to_resolve_interface_type) \and \not scheduled_to_remove(out_comp_class); post ; cost 0;} axiom axiom_sub_type_of:{ let interface1type, interface2type: Object; pre same(interface1Type, interface2Type); pre sub_type_of(interface1Type, interface2Type); pre sub_type_of(interface1Type, interface3Type) \and axiom_sub_type_of(interface3Type, interface2Type);} 145 Behavioral conformance can also be used to find a matching interface. DRADEL [67] provides Java functions to check whether two interfaces match based on their be- havior. As explained before, SHOP2 allows definition of predicates as external function calls. Consequently, to provide interface behavioral conformance, the USER_PICK_A_COMP operation can evaluate an external lisp function that runs Java functions. prov pick_a_server: { let to_resolve_comp, in_comp_class, to_resolve_interface, out_comp_class: Object; sortBy utility asc; pre component_class_utility(out_comp_class, utility) \and prov_interface_of(out_comp_class, matching_interface) \and interface_behavior_of(to_resolve_interface, to_resolve_interface_behavior) \and interface_behavior_of(matching_interface, matching_interface_behavior) \and (eval(has_matching_behavior(matching_interface_behavior, to_resolve_interface_behavior) \and \not scheduled_to_remove(out_comp_class))); post ; cost 0;} The eval is the keyword to call an external Lisp function. In the above model, has_matching_behavior is a lisp function that itself calls my Java code. Note that in this case the interface behaviors should be provided in the system’s current state 146 description as string. This shows that any arbitrary aspect of an interface can be provided and evaluated in order to find a matching component with a matching interface. USER_PICK_A_COMP_INST_FOR_REQUIREMENTS(COMP) return COMP_INST This operation needs to search for an existing component instance that can be used for a component class required in the run-time application. This operation does not need an implementation, because it is only useful at the time of adaptation planning. prov pick_a_client_for_requirements: { let comp, comp_inst: Object; pre same(comp, "client_component_class") \and component_class(comp) \and instance_of(comp_inst,comp); post ; cost 0;} USER_PICK_A_COMP_INST_FOR_DEPENDENCY(COMP TO_RESOLVE_COMP TO_RESOLVE _INTERFACE) returns COMP_INST This operation searches for a component instance of theCOMP component class. The COMP component class is supposed to resolve the dependency of the TO_RESOLVE_COMP component class on its TO_RESOLVE_INTERFACE interface. This operation returns theCOMP_INST component instance as the result. This operation also does not need an implementation in a meta-component. 147 prov pick_a_server_for_dependency: { let comp, to_resolve_comp, to_resolve_interface, comp_inst: Object; pre same(comp, "server_component_class") \and instance_of(comp_inst,comp) \and has_capacity(comp_inst); post ; cost 0;} The operation above does not use some of the arguments, however in dier- ent situations these arguments may be helpful to choose a component instant. has_capacity predicate determines whether a server component instance has enough capacity to accept a new client connection. USER_INSTANTIATE_COMP(COMP) returns COMP_INST Unlike the previous operations, this operation requires an implementation in a meta-component. In this case, I need to provide instantiate operations for both sever components and client components. In my domain, each server instance only accepts a limited number of clients. Therefore, I provide some predicates to keep track of number of connected clients. prov instantiate_a_server: { let comp: Component_class; comp_inst: Component_Inst; pre same(comp, "server_component_class"); post has_capacity(comp_inst) \and instance_of(comp_inst, comp) \and remaining_capacity_of(comp_inst,5); 148 cost 0;} prov instantiate_a_client: { let comp: Component_Class; comp_inst: Component_Inst; pre same(comp, "client_component_class"); post instance_of(comp_inst, comp); cost 0;} USER_INSTANTIATE_CONN(COMP_INST_1 COMP_INST_2 INTERFACE) returns CONN_INST This 6A language action is called one or more times to instantiate required connector classes to connect COMP_INST_1 and COMP_INST_2 component instances on their INTERFACE interface. Each time this action is called, it may create and return a connector instance as CONN_INST. Note that, in some domains, several connector instances may be required to connect two components. Two operations in my domain map to this 6A language action. prov instantiate_a_client_connector: { let comp_inst_1, comp_inst_2 : Component_Inst; conn_inst : Connector_Inst; intface : Interface_Inst; pre instance_of(comp_inst_1,"client_component_class") \and instance_of(comp_inst_2,"server_component_class") \and interface_type_of(intface,"client_server_int_type") \and \not connected_comp_conn(comp_inst_1, any_conn, intface) \and 149 \not \exists(any2_conn) (connector(any2_conn) \and free(any2_conn) \and connector_type_of(any2_conn, "client_conn_type")); post connector(conn_inst) \and free(conn_inst) \and connector_type_of(conn_inst, "client_conn_type"); cost 0;} prov instantiate_a_server_connector: { let comp_inst_1, comp_inst_2 : Component_Inst; conn_inst : Connector_Inst; intface : Interface_Inst; pre instance_of(comp_inst_1, "client_component_class") \and instance_of(comp_inst_2, "server_component_class") \and interface_type_of(intface, "client_server_int_type") \and \not connected_comp_conn(comp_inst_2, any_conn, intface) \and \not \exists(any2_conn) (connector(any2_conn) \and free(any2_conn) \and connector_type_of(any2_conn, "server_conn_type")); post connector(conn_inst) \and free(conn_inst) \and connector_type_of(conn_inst, "server_conn_type"); cost 0;} USER_CONNECT_COMP_CONN(COMP_INST_1 COMP_INST_2 INTERFACE) This 6A language action is called one or more times to connect component and connector instances in order to connectCOMP_INST_1 andCOMP_INST_2 component 150 instances on theirINTERFACE interface. Two operations in my domain map to this 6A language action. prov connect_server_to_server_connector: { let comp_inst_1, comp_inst_2 : Component_Inst; any_conn : Connector_Inst; intface : Interface_Inst; pre instance_of(comp_inst_1, "client_component_class") \and instance_of(comp_inst_2, "server_component_class") \and interface_type_of(intface, "client_server_int_type") \and \not connected_comp_conn(comp_inst_2, any_conn, intface) \and connector(any_conn) \and free(any_conn) \and connector_type_of(any_conn, "server_conn_type"); post connected_comp_conn(comp_inst_2, any_conn, intface) \and free(any_conn) ; cost 0;} prov connect_client_to_client_connector: { let comp_inst_1, comp_inst_2 : Component_Inst; any_conn : Connector_Inst; intface : Interface_Inst; pre instance_of(comp_inst_1, "client_component_class") \and instance_of(comp_inst_2, "server_component_class") \and interface_type_of(intface, "client_server_int_type") \and \not connected_comp_conn(comp_inst_1, any_conn, intface) \and connector(any_conn) \and free(any_conn) \and connector_type_of(any_conn, "client_conn_type"); 151 post connected_comp_conn(comp_inst_1, any_conn, intface) \and \not free(any_conn); cost 0;} USER_CONNECT_CONN_CONN(COMP_INST_1 COMP_INST_2 INTERFACE) This 6A language action is called one or more times to connect connector instances in order to connect COMP_INST_1 and COMP_INST_2 component instances on their INTERFACE interface. Note that, in some domains, several connector instances are required to connect two components. prov connect_client_and_server_connectors: { let comp_inst_1, comp_inst_2: Component_Inst; intface: Interface_Inst; pre instance_of(comp_inst_2, "client_component_class") \and instance_of(comp_inst_1, "server_component_class") \and interface_type_of(intface, "client_server_int_type") \and connected_comp_conn(comp_inst_2, client_conn, intface) \and connected_comp_conn(comp_inst_1, server_conn, intface) \and remaining_capacity_of(comp_inst_1, cap); post connected_conn_conn(client_conn, server_inst, intface) \and connected(comp_inst1, comp_inst_2, intface) \and remaining_capacity_of(comp_inst_1, cap-1); cost 0;} USER_ADD_COMP(COMP_INST) 152 This operation adds a component instance to an architecture. This operation should be implemented in a meta-component. In my domain, client and server component instances are added to the architecture with the same operation. prov add_component: { let comp_inst: Component_Inst; pre (instance_of(comp_inst, "client_component_class") \or instance_of(comp_inst, "server_component_class")) \and \not comp_added_to_arch(comp_inst); post comp_added_to_arch(comp_inst); cost 0;} USER_ADD_CONN(CONN_INST) This operation adds a connector instance to an architecture. This operation should be implemented in a meta-component. In my domain, client and server connector instances are added to the architecture with the same operation. prov add_connector: { let conn_inst: Connector_Inst; pre (connector_type_of(conn_inst, "client_conn_type") \or connector_type_of(conn_inst, "server_conn_type")) \and \not conn_added_to_arch(conn_inst); post conn_added_to_arch(conn_inst); cost 0;} USER_DISCONNECT_CONN_CONN(CONN_INST_1 CONN_INST_2 INTERFACE) 153 This operation disconnects two connector instances connected on theirINTERFACE interface. prov disconnect_server_client_connectors: { let client_conn, server_conn : Connector_Inst; intface: Interface_Inst; pre connector_type_of(client_conn, "client_conn_type") \and connector_type_of(server_conn, "server_conn_type") \and connected_conn_conn(client_conn, server_inst, intface) \and interface_type_of(intface,"client_server_int_type"); post \not connected_conn_conn(client_conn, server_inst, intface); cost 0;} USER_DISCONNECT_COMP_CONN(COMP_INST CONN_INST INTERFACE) This 6A connector disconnects COMP_INST component instance from CONN_INST connector instance connected on INTERFACE interface. prov disconnect_client_connector: { let client_inst : Component_Inst; client_conn : Connector_Inst; intface: Interface_Inst; pre connector_type_of(client_conn, "client_conn_type") \and instance_of(client_inst, "client_component_class") \and interface_type_of(intface, "client_server_int_type") \and connected_comp_conn(client_inst, client_conn, intface) \and \not connected_conn_conn(client_conn, any_conn, intface); post \not connected_comp_conn(client_inst, client_conn, intface); 154 cost 0;} prov disconnect_server_connector: { let server_inst : Component_Inst; server_conn : Connector_Inst; intface: Interface_Inst; pre connector_type_of(server_conn, "server_conn_type") \and instance_of(server_inst, "server_component_class") \and interface_type_of(intface, "client_server_int_type") \and connected_comp_conn(server_inst, server_conn, intface) \and \not connected_conn_conn(server_conn, any_conn, intface); post \not connected_comp_conn(server_inst, server_conn, intface); cost 0;} USER_FINALIZE_COMP(COMP_INST) This 6A language action is to finalize a component instance right before it is re- moved from the architecture and memory. My domain does not require this action. USER_FINALIZE_CONN(CONN_INST) This 6A language action is to finalize a connector instance right before it is removed from the architecture and memory. My domain does not require this action. USER_PRE_CONNECTION_DISCONNECT_COMP_CONN(COMP_INST_1 COMP_INST_2 INTERFACE) 155 This 6A language action is called one or more times in order to connectCOMP_INST_1 and COMP_INST_2 component instances on their INTERFACE interface. In fact, con- nection of one of these component instances to a connector may prevent these two component instances to connect. This action is not required in my domain. USER_PRE_CONNECTION_DISCONNECT_CONN_CONN(COMP_INST_1 COMP_INST_2 INTERFACE) This 6A language action is called one or more times in order to connectCOMP_INST_1 and COMP_INST_2 component instances on their INTERFACE interface. In fact, con- nection of two connector instances may prevent these two component instances to connect. prov disconnect_server_client_connectors_before_connect: { let client, server : Component_Inst; intface: Interface_Inst; pre instance_of(client, "client_component_class") \and instance_of(server, "server_component_class") \and interface_type_of(intface, "client_server_int_type") \and connected_comp_conn(client, client_conn, intface) \and connected_conn_conn(client_conn, conn, intface) \and different(conn, server_conn) \and connected_comp_conn(server, server_conn, intface); post \not connected_conn_conn(client_conn, conn, intface); cost 0;} USER_REMOVE_COMP(COMP_INST) 156 This 6A language operation is to remove a component instance from the architec- ture. prov remove_component: { let comp_inst : Component_Inst; pre (instance_of(comp_inst, "server_component_class") \or instance_of(comp_inst, "client_component_class")) \and comp_added_to_arch(comp_inst); post \not instance_of(comp_inst, comp) \and \not comp_added_to_arch(comp_inst); cost 0;} USER_REMOVE_CONN(CONN_INST) This 6A language operation is to remove a connector instance from the architecture. prov remove_connector: { let conn_inst : Connector_Inst; pre connector(conn_inst) \and free(conn_inst) \and (connector_type_of(conn_inst, "client_conn_type") \or connector_type_of(conn_inst, "server_conn_type")); post \not connector(conn_inst) \and \not free(conn_inst) \and \not connector_type_of(conn_inst, any_type) \and \not conn_added_to_arch(conn_inst); cost 0;} 157 5.5 Time Complexity In 6A the adaptation logic is separated from the algorithm that enacts the adaptation logic and is provided explicitly at run-time. To this end, 6A utilizes an AI planning technique (because AI planning techniques separate the planning algorithm from the description of the domain under planning and the planning problem). In particular, 6A utilizes a hierarchical task network planning technique, SHOP2. Therefore, the performance of 6A depends on both the structure of the adaptation HTN and SHOP2’s algorithm to decompose the adaptation HTN. I calculate the time complexity of 6A by analyzing how the adaptation HTN in 6A is decomposed by SHOP2. I confirm the results of my analysis by running empirical studies. Empirical studies confirm that SHOP2 does not add any incidental complexity to the complexity calculated based on algorithmic analysis. In the rest of this section, I first define the adaptation problem that 6A solves, in Section 5.5.1. Then, I calculate the time complexity of 6A by analyzing the structure of the adaptation HTN in Section 5.5.2. To this end, I calculate asymptotic time complexity of 6A when it is set up to solve adaptation problems with dierent combinations of software requirements (functional, structural, quality). Then, in Section 5.5.3, I provide empirical studies to confirm the calculated time complexities. In addition, in Section 5.5.4, I evaluate the performance/accuracy trade-o of 6A when it is set to find a sub-optimal solution in the case of quality preferences. Finally, I provide a summery of the time complexity of 6A in Section 5.5.5. 158 5.5.1 Adaptation Problem An adaptation problem describes a set of components that can be employed in a system, the required and provided interfaces of those components, and software requirements that should be satisfied by the run-time application. Software requirements are in the form of functional requirements, structural constraints, and quality preferences. In particular, functional requirements are described in the form of required com- ponents. Three types of structural constraints can be defined in predicate logic: local, global, and final. Local structural constraints are defined implicitly as pre-conditions of adaptation operations. Global structural constraints (e.g., an acyclic configuration) are defined explicitly and are enforced each time a component is added to the configuration of the system. Finally, final structural constraints (e.g., a ring configuration) are defined explicitly and are enforced as the last task in the adaptation HTN (Figure 5.5). A solution to the adaptation problem is a configuration of (a sub-set of) components that satisfies four conditions: (1) it includes the required components, (2) dependencies of its components are resolved, (3) the relations between its components satisfy the struc- tural constraints, and (4) it satisfies the quality preferences more than other alternative configurations (i.e., the solution is optimized based on the quality preferences). To re- solve the dependencies of a component, its required interfaces should be connected to matching provided interfaces of other components in the configuration. In fact, this problem is a combinatorial optimization problem (i.e., selection of a solution among finite set of possible solutions), that is generally an NP-hard problem [59]. 159 Resolve Dependencies and Compose Resolve Dependency of a Comp Interface Resolve Dependencies and Compose Weld Dependent Component Instances PICK A COMP Pick Comp Inst or Instantiate for Dependency ADD COMP INST ... ... ... 1 2 9 8 7 6 5 4 3 10 Figure 5.21: Resolve component dependencies in 6A Adaptation HTN. 5.5.2 Algorithmic Analysis In this section, I perform asymptotic time complexity analysis on 6A. In fact, dierent types of software requirements (i.e., functional, structural, and quality) aect the com- plexity of 6A in dierent ways. In this section, I study the eect of dierent types of software requirements, separately. This analysis enables me to determine and reason about the asymptotic upper and lower bounds on the time complexity of 6A in dierent conditions. Moreover, in this section, I provide some heuristics to decrease the time complexity of 6A in dierent settings. 5.5.2.1 Functional Requirements In this section, I analyze the time complexity of 6A when it only handles functional requirements. The logic to resolve component dependencies and generate an adaptation plan (to employ the architectural elements in the run-time application) in the adaptation 160 HTN (Figure 5.5) is provided in the resolve_dependencies_and_compose task, as de- picted in Figure 5.21. To find a plan, SHOP2 performs a depth-first decomposition on the 6A adaptation HTN. The decomposition order of the resolve_dependencies_and_ compose is provided as labels in Figure 5.21. As shown in the figure, at Step 10, this task is decomposed toresolve_dependencies_and_compose itself. In other words,resolve_ dependencies_and_compose will be decomposed iteratively, while in each iteration one interface dependency of one component is resolved. To solve the adaptation problem described in 5.5.1, this task will be decomposed at most n + 1 times, where n is the number of interfaces in the adaptation problem. At the last iteration, there is no more dependencies to resolve and the task will not be decomposed further. Now, I calculate the time required to decompose the resolve_dependencies_and_ compose task in each iteration. In each iteration, one interface dependency of one com- ponent is resolved in Step 3 of Figure 5.21. Then, the 6A adaptation HTN is decomposed to the adaptation operations that employ that interface (and its parent component) in the run-time application. Figure 5.21 depicts some of these operations. For instance, at Step 4 of each iteration a required component is instantiated (if it is not instantiated already), at Step 6 it is added to the run-time application, and in Step 7 dependent components (i.e., their dependent interfaces) are inter-connected. The decomposition and evaluation of some of these tasks (e.g., the PICK_A_COMP) requires linear time in n, while others can be decomposed in constant time. Therefore, it takes at most f n + e units of time to decompose the resolve_dependencies_and_compose task in each iteration, where f and e are constants. To make this clearer, note that, for instance, the PICK_A_COMP (i.e., 161 the operation to resolve one interface dependency) requires linear time in n to search and find a provided interface that resolves (i.e., matches to) a required interface. As explained above, the resolve_dependencies_and_compose task decomposes n times and each decomposition takes f n + e units of time, where f and e are constants. Therefore, it takes f n 2 + en to decompose this task. Therefore, the time complexity of 6A to handle functional requirements is (n 2 ). Conventionally, the notation is used to present a tight asymptotic lower and upper bound on the time complexity. Note that the above analysis only holds if all the functional requirements of an adaptation problem are satisfiable (i.e., there is no unresolvable required interface in the adaptation problem). In fact, in certain situations the decomposition of the resolve_ dependencies_and_compose task needs to be stopped and backtracked to an earlier decomposition step, because some functional requirements of a partial adaptation plan (which represents a partial component configuration) cannot be satisfied further. For instance, consider the situation that an interface dependency cannot be resolved because components in the adaptation problem does not oer a matching provided interface. I assume that all the functional requirements of all adaptation problems are satisfiable. 5.5.2.2 Structural Constraints In the presence of the structural constraints (global and final), the decomposition of the adaptation HTN is stopped and backtracked to an earlier decomposition step when- ever applying an adaptation operation (e.g., adding a component, or connecting two components) results in the violation of a global structural constraint, or the overall con- figuration violates the final structural constraints. In such situations, SHOP2 backtracks 162 and considers other alternative interfaces (and their parent components) in order to find a dierent configuration. Therefore, in the presence of the structural constraints, the analysis in Section 5.5.2.1 only provides an asymptotic lower bound on the time com- plexity of 6A, (n 2 ). Conventionally, the notation is used to present an asymptotic lower bound on the time complexity. Note that the number of alternative configurations for a system is combinatorial in the number of alternative components that oer the same provided interfaces. In the worst case, SHOP2 needs to calculate and evaluate all possible alternative configurations to find a valid architecture. Therefore, the asymptotic upper bound on the time complexity of 6A is O(mn 2 ), where m is the number of possible configurations of the system in the absence of the structural constraints. In other words, the asymptotic upper bound on the time complexity of 6A is exponential. Conventionally, O notation is used to present an asymptotic upper bound on the time complexity. Note that all global structural constraints can be defined as final structural constraints. However, it is important to realize that using global structural constraints where possible (instead of using final structural constraints) lowers the time required to find adaptation plans. Basically, global structural constraints work as a heuristic to spot partial compo- nent configurations (partial adaptation plans) that does not satisfy structural constraints. Consequently, SHOP2 can prone its search space and find adaptation plans faster. 163 5.5.2.3 Quality Preferences As described in Chapter 5, 6A allows definition of various optimization criteria based on various quality properties. To this end, a domain architect provides arbitrary cost func- tions for arbitrary adaptation operations in the adaptation HTN. Optimization criteria can be defined for two types of quality properties: additive properties and non-additive properties. When the optimization criteria is defined on non-additive properties of the final plan (e.g., the average for the utility values of the instantiated components), 6A has to calculate and compare all alternative adaptation plans (i.e., alternative configurations) in order to find the optimal one. Consequently, the time complexity of 6A in this case is (mn 2 ), where m is the number of possible configurations of the system in the absence of the structural constraints. On the other hand, if the optimization is defined on an additive quality property of the adaptation plan (e.g., the total number of components in a topology, or the total time required to run the adaptation plan), 6A can find the optimal solution faster. In fact, 6A defines some heuristics to prone some part of the search space, and increases the lower bound on the time complexity. To this end, 6A provides two heuristics. First, 6A leverages the branch-and-bound optimization feature of SHOP2 [75]. With this feature selected, SHOP2 searches for an optimal plan in a domain without comparing all existing alternative plans. To do so, SHOP2 keeps track of the best plan found, and abandon partial plans with costs higher than the cost of the current best plan (prone the search space). Second, 6A chooses components (from alternative components) in order of their quality properties. In particular, at each iteration of theresolve_dependencies_ 164 and_compose task, 6A selects components in the order of their quality properties. In other words, it tries components that result in better adaptation plans earlier. As discussed in Chapter 5, SHOP2 language directly supports this by sorting and evaluating pre- conditions based on object’s properties. My empirical study shows that 6A improves the time required to find adaptation plans by combining these two heuristics. Consequently, in the case of additive quality properties, the time complexity of 6A can be described by O(mn 2 ) and (n 2 ). Note that the above heuristics cannot be used in the case of non-additive properties to find optimum plans, because in that case the properties of partial adaptation plans does not predict the properties of the final plans. 5.5.3 Empirical Study In this section, I show the performance of 6A when it solves adaptation problems with dierent types of requirements. I demonstrate that the time complexity of 6A in action conforms to my algorithmic analysis in previous section. 5.5.3.1 Functional Requirements To show the behavior of 6A when it only accounts for functional requirements (i.e., in absence of structural constraints and quality preferences), I randomly generate a set of test cases with various number of components. Each component in a test case has 2 provided interfaces and 1 or 0 required interfaces. Moreover, each required interface in my test cases can be matched to 2 provided interfaces of 2 dierent components. Therefore, several component configurations may satisfy the functional requirements of 165 0 20 40 60 80 100 120 140 160 180 200 220 240 10 0 10 20 30 40 50 60 70 80 90 100 110 Number of Components Time in Seconds Figure 5.22: Behavior of 6A in the absence of structural constraints and quality prefer- ences. Number of component is proportional to number of interfaces. each test case, while 6A returns the first solution found. I average the results on the test cases with equal number of components (15 test case per specific number of components). Figure 5.22 shows the time required to find a software composition vs. number of components in each test case. Note that the number of interface is proportional to the number of components. Regression analysis shows that the time complexity of 6A in this case is quadratic, which confirms my algorithmic analysis. 166 5.5.3.2 Structural Constraints Structural constraints are provided to 6A as part of the application ADL models. For instance, example ADL model provided in Figure 5.19 defines acyclic structural con- straint for an architecture. 6A translates this constraint to SHOP2 language (as shown in Figure 5.16) and synthesizes it into the adaptation HTN. Structural constraints in 6A are checked inCheckforFinalConstraints andCheckforGlobalConstraints in the adaptation HTN in Figure 5.5. To demonstrate the behavior of 6A when it handles structural constraints, I apply the acyclic structural constraint to a set of randomly generated test cases with various number of components. The test cases are the same as described in the previous section. Several component configurations may satisfy the functional requirements of each test case. However, some of these configurations have cycles and do not satisfy the structural constraint. In this section, I show the lower and upper bounds on the complexity of 6A. Moreover, I demonstrate the eect of my heuristic in improving the planning time. To this end, I define the structural constraints both as global structural constraints (used as heuristic) and final structural constraints, and compare the planning time in both cases. Figure 5.23 depicts the time required to find a valid plan (or to find no plan at all) vs. the number of interfaces in each test case, when structural constraints are enforced (both as global and final). As shown in the figure, for the test cases with the same number of interfaces, 6A shows dierent behaviors. In fact, the time required to find a valid solution for a test case depends on the dependency graph of the components in the test case. In many test cases, 6A finds a solution quickly, while in some test cases it needs 167 20 30 40 50 60 70 80 90 100 110 10 1 10 0 10 1 10 2 10 3 10 4 Number of Interfaces Time in Seconds Global Structural Constraints Final Structural Constraints Figure 5.23: Behavior of 6A for acyclic configuration requirements. to invalidate many configurations before it reaches a valid solution. When there is no valid configuration at all (the worst-case), 6A needs to find and invalidate all possible configurations. As shown in the figure, in the worst case, the time required to find a plan increases exponentially with the number of interfaces. However, in the case of global structural constraints, for many of the random test cases, 6A could find a plan quickly. Moreover, Figure 5.23 shows that in the same test cases, the planning time when final structural constraints are enforced is higher (by orders of magnitude) than the planning time when the same constraints are enforced as global constraints. This shows the eect 168 of my heuristic in improving the time complexity. Note that the planning time for all test cases are not calculated in the case of final structural constraints due to exponential time growth. 5.5.3.3 Quality Preferences To account for quality preference while searching for adaptation plans, 6A utilizes the cost calculation capabilities of SHOP2. To provide optimization, 6A searches for plans with minimum costs. The cost of a plan is equal to the sum of the costs of the operations in the plan. As demonstrated in Section 5.3.3, 6A allows domain architects to define var- ious optimization criteria by designing arbitrary cost functions for arbitrary adaptation operations. Non-Additive Quality Properties To evaluate the behavior of 6A in the case of non-additive quality properties, I configure it to search for a component configuration that maximizes the average of the utility values of components in the configuration. The utility value of a component is a number between 0 and 1 that determines the desirability of the component to the end-user (1 is the most desirable). Section 5.4.2 describes how the utility value for a component is calculated. To provide the above optimization criterion, the averageCompUtility cost function in Figure 5.20 is provided to 6A. As shown in the figure, this function is called each time a component instance is added to the architecture of the system. To be synthesized in the adaptation HTN, 6A translates this function to the operator shown in Figure 5.17. 169 0 1;000 2;000 3;000 4;000 5;000 0 50 100 150 200 Number of Candidates Time in Seconds 6A configured to find the optimal plan 6A configured to find a sub-optimal plan Figure 5.24: Optimal and sub-optimal planning time in 6A for non-additive quality properties. To find an optimal solution, 6A calculates all possible adaptation plans (i.e., config- urations) and compares the cost of plans. To show that the complexity of 6A in this case is (mn 2 ), I generate random test cases with constant number of interfaces (and components),n, and show that the planning time is linear in the number of alternative configurations, m. To this end, I randomly generate a set of test cases with 27 components in each test case (27 is an arbitrary number). A random utility value is assigned to each component in a test case. Moreover, each component has 2 interfaces, and each required interface of a component matches to 2 provided interfaces of other components in the test case. There- fore, based on the component dependencies in each test case, functional requirements can be satisfied with dierent number of candidate configurations, m. 170 To find the optimum plan, 6A requires to generate and compare all candidate con- figurations for each test case. Figure 5.24 depicts the time required by 6A to select the optimal configuration among candidate configurations vs. the number of candidate configurations in each test case. As figure depicts, the time required by 6A increases linearly with the number of candidate configurations. This confirms the(mn 2 ) com- plexity of 6A in this setting. Note that the number of candidate configurations itself increases combinatorially with the number of alternative components that provide the same interfaces. Additive Quality Properties To demonstrate the time complexity of 6A in the case of additive quality properties, I test 6A when it accounts for an additive quality property. To this end, I demonstrate the complexity advantage achieved from heuristics described in Section 5.5.2.3. In this test, I assume that it takes various amount of time to instantiate dierent component classes, and it takes no time to perform other adaptation operations. The optimization criterion is to find an adaptation plan which requires the least amount of time to run. I generate several test cases with variable number of components (and interfaces). A random value is assigned to each component as its instantiation time. Moreover, each component in each test case has 2 provided interfaces and 1 or 0 required interfaces. Each required interface is provided with two dierent components. Therefore, in each test case, several candidate configurations satisfy the functional requirements of the system. Figure 5.25 depicts and compares the required time to find the optimum plan in absence and presence of my heuristics. This figure shows that in the case of additive 171 20 25 30 35 40 45 50 55 60 65 70 10 1 10 0 10 1 10 2 10 3 10 4 Number of Interfaces Time in Seconds Optimal planning with heuristics Optimal planning without heuristics Figure 5.25: Optimal planning in case of additive quality properties. quality properties, 6A can find the optimum plans without comparing all alternative adaptation plans, in much less time. 5.5.4 Complexity vs. Accuracy Trade-o 6A provides a setting to search for sub-optimal solutions in the case of quality preferences. This setting is specially helpful to handle non-additive quality properties, where the 172 complexity of 6A is (mn 2 ). I will show that the performance of 6A improves in this case, while it finds adaptation plans with high qualities. To this end, 6A selects components with better quality properties (where it can choose among alternative components) and returns the first found solution. For example, I provide a sub-optimal solution to find an adaptation plan with the highest average for the utility values of the components in the configuration. To this end, at each iteration of the resolve_dependencies_and_compose task, 6A selects the component with the highest utility value. Consequently, in this setting, the time complexity of 6A in the absence of structural constraints is (n 2 ), while in presence of the structural constraints the complexity is (n 2 ) and O(mn 2 ). My empirical studies shows that 6A with the sub-optimal setting finds solutions with qualities close to the qualities of the optimal solutions in the provided test cases. To find a sub-optimal solution, the domain-specificUSER_PICK_A_COMP operation can be set to select components with the highest utility value, when alternative components provide the same interface (see the example provided in Section 5.4.4). In this case, 6A selects the first plan that it finds in a greedy fashion (in the absence of structural constraints). Figure 5.24 also shows the behavior of 6A in the sub-optimal setting. As shown in the figure, 6A requires constant time to find a sub-optimal configuration for dierent test cases, when the number of interfaces are constant. Note that in this experiment, the structural constraints are not considered. Considering the structural constraints in the case of sub-optimal setting results in O(mn 2 ) and (n 2 ), that shows improvement comparing to the complexity of optimal setting, (mn 2 ). 173 Table 5.1: Time complexity of 6A, where n is number of interfaces and m is the number of candidate configurations in the absence of structural constraints. Functional Require- ments Structural Constraints Quality Preferences Sub- optimal Setting Asymptotic Lower Bound Asymptotic Upper Bound X n 2 n 2 X X n 2 mn 2 X Any Additive n 2 mn 2 X Any Non- additive mn 2 mn 2 X Any X n 2 n 2 X X Any X n 2 mn 2 To evaluate the quality of a found configuration (compared to the optimal configu- ration) I use the optimality measure defined by Sykes [90]: Optimality(con f iguration) = AverageUtility(con f iguration) AverageUtility(OptimalCon f iguration) 100 6A with the sub-optimal setting achieves 86-100% optimality for the test cases shown in Figure 5.24 (97.46% optimality on average). 5.5.5 Time Complexity Summary Table 5.1 provides a summery of the complexity of 6A for adaptation problems with dierent software requirements. Note that n is the number of interfaces and m is the number of candidate configurations in the absence of structural constraints. In fact, m increases combinatorially with the number of alternative provided interfaces in a system; hence mn 2 increases exponentially in the number of interfaces. 174 As Table 5.1 shows that satisfaction of structural constraints increases the upper bound on the time complexity of 6A to exponential while it does not aect the lower bound on the complexity. Moreover, non-additive quality preferences increase both upper and lower bound on the complexity of 6A to exponential; while non-additive quality preference only increase the upper bound. In addition, although the sub-optimal setting provides the tight quadratic complexity in the absence of structural constraints, it does not help the exponential upper bound in the presence of structural constrains. My empirical studies showed that, the sub-optimal setting of 6A resulted in adaptation plans with high qualities. It is important to realize that some structural constraints, such as acyclic or cyclic con- straints, increase the complexity of 6A. These are structural constraints that are globally enforced on an architecture (as opposed to local constraints). 175 Chapter 6 Implementation The 6A approach is implemented as a software environment that follows the design of iDARE reference architecture. I also call this software environment “6A”. 6A leverages Eclipse [25] as its development environment. The run-time environment in 6A is a four-layer instantiation of the adaptive layered software style, which implements the approach introduced in Chapter 5. In Section 6.1 of this chapter, I recap the architecture of Eclipse. Then in Section 6.2, I detail the special design of plug-ins that 6A contributes to the Eclipse environment. This design enables execution of the 6A components in Eclipse. Finally, Section 6.3 describes the overall architecture and building blocks in the 6A implementation. 6.1 Architecture of Eclipse Eclipse is a plug-in based development environment, which provides a common basis for creating diverse software development products and integrating them [25]. A general introduction to development environments is provided in Chapter 3. Eclipse platform 176 provides several generic functionalities that are extended and specialized to create new tools for new contents. Figure 6.1 depicts the architecture of Eclipse. Every element of the Eclipse platform (other than the Platform Run-time) is in the form of plug-ins. Through these plug-ins, Eclipse provides basic User Interface Services (e.g., editors, wizards, and viewers), Team Management Services (e.g., version control), File Management Services (e.g., resource explorer), and Task Management Services (e.g., build services and background jobs). To create new tools, users design and implement new plug-ins by extending and specializing the existing plug-ins. New tools may comprise one or several plug-ins. In addition to providing the basic services noted above, Eclipse platform also discovers plug-ins and provides them with the required infrastructure to interact. The workflow to create and interact with an application in 6A is similar to that in Eclipse. The dierence is that 6A supports the full software life-cycle, as described in Chapter 3. Generally, Eclipse plug-ins create and manage software artifacts in the context of projects. A project is a placeholder to collect all software artifacts related to an application, including design, modeling, testing, code, and run-time artifacts. Moreover, projects in Eclipse facilitate various processing tools (e.g., compilers) to manage and store their settings and state relevant to each project. Like other Eclipse based tools, my implementation comprises several plug-ins (de- scribed in Section 6.3). Figure 6.1 depicts a conceptual view of 6A. 177 Eclipse Platform Platform Run-time Workbench JFACE SWT Workspace Help Team 6A New Tool Plug-in New Tool Plug-in ... ... SADEL Editor Prism Visualizer Figure 6.1: Architecture of Eclipse. 6.2 Design of Plug-ins in 6A The architecture of 6A follows the design of the iDARE reference architecture described in Chapter 3. iDARE introduces new types of tools and repositories that belong to both run-time and development environments, and are detachable from the development environment at run-time. In addition, as described in Chapter 5, the 6A approach follows the adaptive layered software style, in which each layer monitors and adapts the layer immediately below it. Components and connectors in this approach are Prism artifacts that run on top of the Prism middleware. Consequently, the design of plug-ins in 6A should permit the following features: (1) interactions of Prism components through the Eclipse platform, (2) integration of run-time and development-time tools, and (3) detachment of tools at run-time. In the rest of this section, I show how each of these features are implemented in 6A. 178 6.2.1 Component Interactions My newly developed plug-ins for 6A run the Prism middleware at their cores. Each of these plug-ins comprise several Prism components and connectors. There are two types of communications among Prism components in 6A, inter and intra plug-in communica- tions. Using the inter plug-in communications, components in one plug-in communicate with one another using Prism events. In this case, the Prism middleware is in charge of event scheduling and delivery. On the other hand, using the intra plug-in communications, components in dierent plug-ins communicate with one another. Note that any communication between plug-ins in Eclipse must comply with the Eclipse architecture. To this end, intra plug-in commu- nications must go through the Eclipse communication services. In other words, Prism components in dierent plug-ins should not Exchange events directly. To support intra plug-in communications, I extended the Eclipse communication services to schedule and exchange wrapped Prism events through Eclipse’s communication facilities. Addition- ally, I designed and implemented a new type of Prism adaptor that interacts with Prism components and connectors on one side, and with other plug-ins (through my extended Eclipse communication service) on their other side. These adaptors are essentially Prism connectors extended to provide Eclipse conformant functionality. They integrate my plug-ins with one another and with other plug-ins in Eclipse. 179 6.2.2 Run-time Tools in Development Environment The Design of component-based plug-ins allows 6A to run components belonged to the run-time environment as part of the Eclipse platform. Adaptors described above enable the interaction of run-time and development-time plug-ins in 6A. For instance, run-time plug-ins interact with development plug-ins to obtain various run-time artifacts (such as run-time Java classes and planning artifacts), updates to run-time artifacts are sent to run-time plug-ins (this may initiate run- time software adaptation), user-interface plug-ins control the flow of the adaptation engine through run-time plug-ins, run-time plug-ins interact with end-users by sending run-time messages (such as, run-time errors) to user-interface plug-ins, and run-time plug-ins receive messages about health and status of the development environment (in turn, this may initiate detachment of development and run-time environments). 6.2.3 Detachable Tools Some of the tools, repositories, and components in 6A are detachable at run-time. The design of component-based plug-ins, Prism middleware’s capability to migrate run-time components and connectors from one host (or process) to another host (or process), and 180 the adaptive layered style of 6A allow the implementation of detachable tools. The adap- tation engine in 6A is a four-layer instantiation of the adaptive layered architectural style (see Figure 6.2). The top-most layer, the environment layer, is responsible for detaching the development- and run-time environments, while remaining layers implement the three adaptive layers of the 6A approach (see Chapter 5). The top-most layer in the adaptation engine, the environment layer, manages and adapts the synthesis layer. The Admin component in the environment layer receives unavailability notifications from end-users or from the Eclipse environment. This notifications are sent right before the Eclipse shutdown, either because Eclipse encountered a failure or for maintenance purposes. When these notifications are received, the Admin component moves the components and connectors in the synthesis layer out of the Eclipse environment and forms a limited version of the synthesis layer in the run-time environment. During this process, some parts of artifact repositories are also migrated to the new run-time environment. Conse- quently, adaptation engine can continue its operation seamlessly. Notice that there are no interactions with the development environment plug-ins in the detached context. 6.3 Architecture of 6A The software environment in 6A comprises both tools I constructed and third-party tools. In fact, this environment is open to integration of the new tools in the future. Figure 6.2 captures the architecture of 6A in terms of the iDARE constructs; Figure 6.3 depicts a screen shot of the resulting software environment. In this section, I describe 181 Java Code Adaptation Layer Synthesis Layer Run-time Application (Prism Middleware) Collector Collector Collector Adaptation Analyzer Admin Admin Admin Adaptation Engine (Prism-MW) Run-time Environment Development Environment (Eclipse) Java Development Tooling (JDT) SADEL Model Editor Analyzer Adaptation Layer Model Manager . . . Collector Admin SADEL Models Java Run-time Planning Artifacts Application Layer Model Manager (Prism Middleware) Prism Code Generator Prism Visualizer Application Layer Adaptation Logic Manager Adaptation Layer Adaptation Logic Manager Adaptation Layer Architecture Manager Legend Environment Adaptation Component Application Component Detachable Tools Run-time Component Repository Management Tool User Interface Tool Artifact Processing Tool Tools Collector Adaptation Logic Evaluator Adaptation Logic Manager Architectural Model Manager Admin Run-time Roles Environment Layer Admin 6A Project Manager Figure 6.2: Overall architecture of 6A. 182 my contributed tools as well as some of the third-party tools I leveraged. Moreover, I describe the interactions among these tools. Third-party Tools Java Development Tooling (JDT) 1 plug-ins provide support to edit, debug, test, build, and run Java code. Projects created by 6A inherit properties of JDT projects. Consequently, end-users of my software environment leverage full benefits of JDT. Subversion (SVN) Team Provider 2 is a repository management tool to provide artifact version control and sharing. 6A depends on various software artifacts like Java code, SADEL model files, domain model descriptions, and planning problems. Any of these artifacts may need to be backed up, versioned, and shared. In fact, any other team support tool such as P4Eclipse 3 or GitHub for Eclipse 4 may replace the SVN Team Provider. Newly Developed Tools Adaptation Engine shown in Figure 6.2 is the plug-in that implements the adap- tation engine in 6A. Design of this tool is provided in Section 6.2. The top-most adaptive layer in the adaptation engine manages the detachment and attachment of the development and run-time environments (see Figure 6.2). Notice that the adaptation layer is not part of the development environment and only runs when the application runs. 1 http://www.eclipse.org/jdt/ 2 https://www.eclipse.org/subversive/ 3 http://www.perforce.com/resources/tutorials/p4eclipse-plug 4 http://eclipse.github.com/ 183 Figure 6.3: A snapshot of the 6A environment. 6A Project Manager plug-in provides end-users with several menus and pop-up menus to control the flow in 6A. It also specializes Eclipse’s generic projects to 6A projects. 6A projects enforce a specific directory structure to categorize and integrate required artifacts (Java code, Java run-time classes, domain model de- scriptions, goals, plans, and application and adaptation component SADL models). The structure of a sample project is presented in the Project Explorer viewer in Figure 6.3. 184 Additionally,6A Project Manager monitors changes to the artifacts in 6A projects and sends artifact updates to the Adaptation Engine when required (this my ini- tiate software adaptation). This plug-in also monitors the state of Eclipse platform and sends unavailability notifications to the adaptation engine. Note that these no- tifications may be initiated by end-user. To this end, end-user press the provided DETACH RUN-TIME button in the Eclipse toolbar, as shown in Figure 6.3. Code Generator Tool is created by extending the DRADEL tool described in Sec- tion 4.2.2. This tool generates Java code stubs for components from the SADEL component models. SADEL Model Editor, an editor to edit the SADEL model files, is created using the Xtext framework 5 , a framework for development of programming languages and domain-specific languages. Xtext receives grammar of a language (SADEL in this case) and generates a couple of Eclipse plug-ins that implement an Eclipse editor. The properties and behavior of this editor can be further customized by providing additional details to the editor plug-ins. The SADEL editor provides syntax coloring, error highlighting, content assist (such as text auto-completion), and several other features. The SADEL editor is used to open a sample SADEL model in Figure 6.3. Prism Visualizer monitors a run-time application and visually presents the run- time application’s architecture. Architectural changes to the run-time application are reflected to the visualizer as soon as they happen. This plug-in contributes two 5 https://www.eclipse.org/Xtext/ 185 views to Eclipse: Architecture Viewer and Run-time Viewer. Run-time viewer is able to group all architectures running in one application, including architectural layers in adaptive layered style. Figure 6.3 is captured when run-time application is not running. Therefore, run-time environment only has two layers. Note that Figure 6.3 is not intended to show the details of the run-time environment. 186 Chapter 7 Evaluation This dissertation’s technique to software self-adaptation (6A) adapts the behavior and the structure of both run-time application and adaptation engine. As stated in hypotheses 1 and 2, in adaptation of the run-time application, 6A improves the self-adaptability of the system and reusability of application components, while compared to the existing state-of-the-art approach, the Sykes approach [91], it only imposes marginally higher computational cost and marginally higher software architect’s eort. To this end, I only compare 6A to the Sykes approach because it is the first and to-date lone approach that accepts high-level goals (in the form of run-time application states) and provides a higher degree of self-adaptability compared to other similar approaches [90]. Although feature-based approaches also accept high-level goals in the form of required features, they are inferior to 6A and the Sykes approach. The level of adaptability of feature-based approaches is lower and limited to the variation points. Moreover, extra adaptation artifacts (feature-models) need to be designed and provided by the architect. Section 7.1 evaluates the cost/benefit trades-os of 6A in adaptation of the run-time application. 187 On the other hand, 6A enables adaptation of the adaptation engine itself. Therefore, as stated in hypothesis 3, compared to other declarative self-adaptive approaches, 6A handles a larger number of adaptation scenarios and requires less domain architect’s eort to be set up and maintained, while it has the same (or higher) level of performance. Section 7.2 evaluates the cost/benefit trade-os of 6A in adaptation of the adaptation engine. 7.1 Adaptation of Run-time Application On the one hand, 6A utilizes ADL models of the application components to dynamically synthesize and update the domain model description of the run-time application. This results in higher self-adaptability and higher component reuse. Sections 7.1.1 and 7.1.2 evaluate these benefits, respectively. On the other hand, compared to the Sykes approach, 6A needs an extra computation step to synthesize domain model descriptions from component ADL models. Moreover, application architects in 6A should provide a dierent set of models as input. Therefore, to be successful, 6A needs to meet two criteria: (1) It should not use much more processing time to run, and (2) it should not require much more modeling eort. Sections 7.1.3 and 7.1.4 evaluate and compare the processing time and application architect’s modeling eort in 6A and its principal competitor approach, respectively. 188 7.1.1 Higher Self-Adaptability 6A handles at least all adaptation scenarios that can be handled by the Sykes approach, and it may handle more component failure adaptation scenarios depending on the do- main model description structure. The Sykes approach may encounter three adaptation scenarios: domain model description changes, goal changes, and component failures. Next, I will compare the behavior of 6A in each of these scenarios. First, changing the system’s goal in 6A and the Sykes approach results in a similar behavior. Both techniques re-plan, use the new plan to find the required actions in the system, and adapt the run- time application accordingly. Second, making changes to the domain model description in the Sykes approach, is equivalent to making changes to the set of component ADL models in 6A. In this scenario, 6A synthesizes a new domain model description equiv- alent to that in the Sykes approach. Hence, in this adaptation scenario, the behavior of 6A after synthesizing the domain model description is equivalent to the behavior of the Sykes approach. However, in the case of component failure, 6A behaves dierently. In fact, the Sykes approach cannot update the domain model description after a component failure; it can only oer to replace a failed component with another com- ponent that provides the same functionality as the failed component. 6A, in contrast, autonomously updates the domain model description when a component fails and there is no alternative component (i.e., by removing the functionality of the failed component from the domain model description), and re-plans. When re-planning based on the updated domain model description oers other solutions to achieve the system’s goal 189 (i.e., without considering the failed component), 6A can still adapt the system. Conse- quently, the number of extra component failure scenarios that can be handled with 6A depends on the structure of the domain model description. The more paths from an initial state to a goal state in a domain model description, the higher the number of extra component failure scenarios handled by 6A. In fact, domain model descriptions in many complex software systems have this property. Next, I provide a case study to evaluate this behavior. 7.1.1.1 Case Study: Automated Build System The Automated Build System (ABS) evaluates the source files in a software system and builds the targets. This system is comprised of a client, a build server, a source repository, and a build repository. Client in this system has the source files that should be built. ABS builds the targets in the client itself, or sends the sources to the build server, builds the targets there, and moves the targets to the client. ABS can also fetch the targets from the build repository, when repository has the required version of targets. In the case of broken resources, ABS replaces them with their local, older versions. ABS is also able to recover the broken resources from the sources repository, when local recovery is not available. Figure 7.1 depicts a simplified view of the domain model description that ABS synthesizes from all available components in the ABS. Each state transition in this figure is marked by the name of the operation that causes the state transition and the name of the component that provides the operation. Names of components are in parentheses. The goal of ABS is to reach the targets-in-client state. Suppose that all com- ponents are available. In such a condition, the application plan to reach the system’s 190 Figure 7.1: A simplified view of the domain model description of the ABS system, when all components are available. goal does not require theremote-calculate-build-plan,remote-build, andrequest- resource-from-repo operations. That is because the planner finds paths from all possi- ble system states to the goal state without going through state transitions related to these 191 Figure 7.2: Architecture of the run-time application when all components are available. Figure 7.3: Architecture of the run-time application after theLocal-Builder component failure. operations. The application architecture in this condition is depicted in Figure 7.2. In the rest of this section, I provide the additional adaptation scenarios that 6A handles, while the Sykes approach does not. Suppose that the build action from the Local-Builder component fails. In this condition, the ADL model of the Local-Builder component is removed from the set of inputs to the domain model description synthesizer in 6A and a new domain model description is generated. Then, the planner re-plans based on the new domain model description. The resulting application plan includes theremote-calculate-build-plan andremote-build operations. As depicted in Figure 7.3, the application architecture in this situation has an instance of theRemote-Builder component and theLocal-Builder 192 Figure 7.4: Architecture of the run-time application after theFile-Hist-Mngr component failure. Figure 7.5: Architecture of the run-time application after theBuild-Fetcher component failure. component instance is removed from the architecture. A similar situation happens when the restore-local-history operation from the File-Hist-Mngr component fails. In this condition, the domain model description is updated and a new application plan with no restore-local-history operation is found. Figure 7.4 depicts the resulting application architecture after software adaptation. In this condition, an instance of the File-Repo-Mngr component is added to the architecture, and the File-Hist-Mngr component instance is removed. In another condition, thefetch-targets-from-repo action from theBuild-Fetcher component fails. In this situation, after the domain model description is updated (similar to the above scenarios), a dierent application plan is found that does not include the 193 failed operation and still achieves the system’s goal. As shown in Figure 7.5, application architecture after this adaptation does not have theBuild-Fetcher component instance. Note that, in the above scenarios, recovering any component after its failure results in a domain model description update, application re-planning, and software adaptation. Therefore, considering all combinations of these 3 component failure scenarios, there are 2 3 = 8 software adaptation instances, resulting in 8 dierent application architectures. Any architecture in this set can be adapted to any other application architecture in the set. Therefore, there are 8 7 = 56 adaptation scenarios that can be handled by 6A. Note that the Sykes approach does not handle any of these adaptation scenarios. In the case of software failure, the Sykes approach looks for alternative components with the same ports (functionalities) as the failed components and, in this instance, finds no alternatives. 7.1.2 Improved Component Reuse There are two dierent sides to this benefit. First, 6A autonomously employs o-the- shelf components (given that they are accompanied with their proper models) in the run-time application, while this is not possible in the Sykes approach. In fact, in order to employ an o-the-shelf component in the Sykes approach, the application architect needs to manually update the domain model description to reflect the behavior of that component. Second, in 6A, with no added modeling eort, components and their ADL models created for one application can be reused in other applications. 194 7.1.3 Processing Time The extra processing time required by 6A can be evaluated based on the time complex- ity order of its domain model description synthesis algorithm. This algorithm in 6A generates the domain model description by a one-to-one mapping of the component operations to domain actions, and state variables to domain fluents. Therefore, the com- plexity of this algorithm isO (n +m), wheren andm are the number of domain actions and fluents, respectively. Given that this algorithm is of lower complexity than the exponen- tial application planning algorithm, its contribution to the overall processing time will be negligible in all cases except for very small values of n. 7.1.4 Application Architect Eort Application architect’s modeling eort comprises the required eort to model individual elements (such as variable definitions, port definitions, etc.) in the application models provided to an adaptation technique. Dierent levels of eort are required to model dierent elements in an application model. To compare the application architect’s mod- eling eort, I classify modeling elements in both techniques, provide the required level of eort to model each element class, and compare equivalent element classes in both techniques. Using this information, I determine the extra modeling eort required by 6A compared to the Sykes approach, when both techniques are applied to the same system. Table 7.1.4 provides modeling element classes in each technique, element class coun- terparts across dierent techniques, level of eort required by various modeling element 195 Table 7.1: Equivalent modeling element classes in 6A vs. the Sykes approach. Eort Level 6A Sykes Technique Comparison Low State variables (ADL) Domain fluents (NPDDL) More eort required by 6A. One domain fluent may be defined mul- tiple times in multiple components in 6A. Moderate Required/provided interfaces (ADL) Required/provided ports (ADL) Same eort. High Operations (ADL) Actions (NPDDL) Same eort. Note that each action/operation is comprised from pre- and post-conditions expressed in predicate logic. Low Operation to in- terface mappings (ADL) Action to port map- pings (action-to- port map) Same eort. Low State vari- able mappings (variable-to- variable map) Not applicable More eort required by 6A. classes, and eort required by 6A compared to that for the Sykes approach when the system is modeled in both techniques. As provided in this table, 6A uses ADL component models and a variable-to-variable map model. Modeling element classes in ADL component models are state variables, required/provided interfaces, and operations (describe the behaviors of interfaces); on the other hand, the lone modeling element class in the variable-to-variable map models is mapping among equivalent state variables in various components. Note that multiple state variables of multiple components in 6A may map to the same domain fluents. 196 Therefore, in order to specify state variables that represent the same domain fluents, a variable-to-variable map model is required. The Sykes approach, on the other hand, uses domain model descriptions, component models in a simplified ADL model (based on Darwin [61]), and action-to-port map model. Modeling element classes in domain model descriptions are the domain fluents, and domain actions; while, the modeling element classes in the component ADL models are ports. Each port either defines a required interface (capability) or a provided interface. Finally, the lone modeling element class in the action-to-port map models is the mapping from actions in domain model description to ports in component models. In fact, providing various modeling elements requires dierent levels of eort. For instance, modeling the behavior of an action or operation is apparently harder than modeling a state variable mapping. Because, the former involves reasoning about, designing, and typing pre- and post-conditions in predicate logic, while the latter mostly involves typing. The relative levels of eort for various modeling elements are provided in Table 7.1.4. To compare 6A to the Sykes approach, the modeling eort should be considered in two dierent situations: (1) when o-the-shelf components are used (given that those components are accompanied with their proper models), (2) when application compo- nents are provided by the application architect. In the case of o-the-shelf components, application architect in 6A may only provide some variable-to-variable mappings; while, in the Sykes approach, application architect provides domain model descriptions and action-to-port mappings. In this case, 6A requires a smaller number of modeling ele- ments; hence, the modeling eort is lower in 6A. 197 In the second situation, as provided in Table 7.1.4, application architects in 6A may provide more state variables (compared to the number of domain fluents) and extra state variable-to-variable mappings. Providing these extra elements only takes extra typing eort. Note that, compared to the other elements in an application model, it takes the least level of eort to create these elements. From a dierent perspective, to model the same application, architects spend most of their eort on creating the elements that are equivalent in both techniques. This can be seen in Table 7.1.4, where the elements that need the “same eort” to create are those elements that need the most of the eort to create. Consequently, I can infer that application architect’s modeling eort with 6A is only marginally higher than that with the Sykes approach. Notice that, in the best-case scenario, no domain fluent is aected by more than one component. In other words, components do not have any shared variables. Therefore, no extra eort is required by 6A in the best-case scenario. In conclusion, in the case of o-the-shelf components, 6A requires less modeling eort and is superior to the Sykes approach; while in the case of providing component models, marginally more modeling eort may be required by 6A compared to the Sykes approach. Therefore, considering benefits of 6A (reusability and higher-adaptability), the marginal extra modeling eort worth the rewards. 7.2 Adaptation of Adaptation Engine The adaptation behavior of the adaptation engine in 6A is dynamically provided and maintained. Therefore, as stated in hypothesis 3, 6A handles a larger number of software 198 adaptation scenarios compared to the existing approaches to software adaptation, while it requires less domain architect’s eort to handle and its performance is similar to (or better than) the performance of the existing adaptation approaches. In section 7.2.1, I compare the self-adaptability level of 6A to that of the existing approaches. Then, in Section 7.2.2, I evaluate and compare the performance of 6A (in terms of the time and space complexity) to the performance of the adaptation approaches that provide similar functionalities. Finally, in Section 7.2.3, I show that the required eort to provide and maintain software adaptation artifacts in 6A is lower compared to that of the existing adaptation approaches. 7.2.1 Self-adaptability In this section, I compare the self-adaptability level of 6A to that of its similar self- adaptive software systems, to show that 6A has a higher self-adaptability level. To this end, first, I provide a framework to compare self-adaptability of architecture-based self- adaptive software systems. This framework logically partitions the run-time application and adaptation engine in such systems into adaptable entities. Self-adaptability of an approach can be ranked based on the number of framework entities that are adaptable in that approach. I discuss how 6A adapts more entities in this framework compared to other similar approaches. Self-adaptability framework is depicted in Figure 7.6. This framework comprises two key layers: run-time application and adaptation engine. Each key layer in this framework is built based on a set of component and connector classes that are the soft- ware building blocks of that layer. Components and connector classes comprise the 199 bottom-most entity in self-adaptability framework. The behavior entity, on the other hand, determines the component and connector instances and their interactions in each key layer. Behavior can be separated into two elements, topology and logic. Topology determines the required component and connector instances (from component and con- nector classes) and their interconnections; on the other hand, logic determines when and how component and connector instances should interact. Topology and logic are tightly related. In systems such as 6A and Sykes’s approach, topology entity is deduced from the logic entity. The top-most entity, the goal entity, on the other hand, describes the goal of each key layer. Goals of each layer can be broken into the functional and non-functional aspects of goals. Any architecture-based self-adaptive software system can be described and evaluated based on the self-adaptability framework. However, not all the systems explicitly implement all the entities of this framework. For instance, an application or adaptation goal may only be implicitly defined in a system and may not be separated from the application or adaptation logic. Notice that any entity in a self-adaptive software system may need to change. More- over, changes to an entity may cause changes to other entities in the framework. In the rest of this section, I go through each of the entities of the run-time application and adap- tation engine, and show that 6A allows run-time adaptation of more entities compared to other self-adaptive approaches. 7.2.1.1 Run-time Application: Application Goals In 6A, when the application goal changes, adaptation engine re-plans to find a new application plan. This may also initiate adaptation re-planning and eventually software 200 Component and Connector Classes Adaptation Goals Functional / Non-Functional Behavior Topology Logic Behavior Component and Connector Classes Application Goals Functional / Non-Functional Topology Logic Run-time Application Adaptation Engine Figure 7.6: The self-adaptability framework to compare the self-adaptability level of architecture-centric self-adaptive approaches. adaptation. Other descriptive self-adaptive systems, such as Sykes’s approach, can also handle changes to the application goals. 7.2.1.2 Run-time Application: Behavior In 6A, similar to other descriptive self-adaptive approaches, the behavior of the run- time application is determined and set automatically. Changes to the system goals and component and connector classes result in changes to the behavior of the run-time application. In 6A, the high-level behavior of the run-time application is determined by application plans. 201 7.2.1.3 Run-time Application: Component and Connector Classes Software failures and software updates change the set of component and connector classes in the system’s implementation. These changes may be simple or complex. The types of component and connector classes are retained in simple changes. Therefore, the adaptation engine can still manage and adapt the updated classes. In contrast, complex changes involve the introduction of new types of component and connectors. In this condition, an adaptation engine may need to manage and adapt new types of application component and connector classes that require dierent adaptation steps to be added, updated, or removed. To this end, the behavior of the adaptation engine needs to be changed. For example, to add a data access component to an application, a data access connector should be used and the connection between the component and a database engine should be initiated. As a result, an adaptation engine with no knowledge about data access components and connectors is unable to employ a data access component. Existing declarative adaptation approaches have a static set of adaptation actions that may not be adapted at run-time. In other words, the behavior entity in their adaptation engine does not change. On the other hand, 6A is able to automatically employ new adaptation actions (to handle new adaptable elements) at run-time. Therefore, 6A is able to handle any change to the set of component and connector classes, while other approaches cannot. 7.2.1.4 Adaptation Engine: Adaptation Goals The functional goal of the adaptation engine is to find an application plan that satisfies the application goals (functional and non-functional), calculate the new behavior (i.e., 202 logic and topology) of the run-time application, and adapt the run-time application to its new topology. Adaptation engine adapts the run-time application when the application goals change, but this does not change the functional goal of the adaptation engine itself. The non-functional goals of the adaptation engine have two aspects. First, they determine the end-users’ preferred quality properties of the adaptation engine itself (e.g., resource consumption and latency). Quality properties of an adaptation engine are inherited from its component and connector instances and their interactions. Second, non-functional goals of an adaptation engine determine optimization objectives of its adaptation planner. For instance, the end-user may prefer to find adaptation plans optimized in a way that the software adaptation takes minimal time, or the utility of the run-time application after the adaptation is maximized. Adaptation engines in the existing declarative adaptation approaches have static be- haviors (topology and logic). However, to change non-functional goals of an adaptation engine its behavior needs to be altered. Therefore, the quality properties of the adapta- tion engine in these approaches may not be changed at run-time. In addition, the logic to optimize adaptation plans in the existing declarative adaptation approaches is static and cannot be changed at run-time. In contrast, the behavior of the adaptation engine in 6A is adaptable at run-time. 6A can dynamically employ adaptation component and connector classes with various quality properties at run-time. In addition, with 6A, op- timization criteria for the planner can be changed at run-time. This is possible because it dynamically deduces the optimization criteria from the cost functions in adaptation ADL models. 203 7.2.1.5 Adaptation Engine: Behavior The behavior of the adaptation engine in self-adaptable systems changes at run-time. To this end, I discuss both aspects of behavior: logic and topology. The logic of an adaptation engine determines the set of condition-actions performed by that adaptation engine. This logic has to change at run-time as the run-time application evolves and encounters new conditions. Adaptation behavior in the descriptive self-adaptive approaches is determined by their set of adaptation policies. Recent descriptive approaches allow the adaptation policies of the system to be changed at run-time. In declarative adaptation approaches, on the other hand, adaptation plans determine the adaptation behavior of the system and adaptation plans are calculated at run-time. The topology aspect of the adaptation engine defines the adaptation component and connector instances in an adaptation engine and their interconnections. The component and connector classes in an adaptation engine may need to update at run-time, to fix bugs or provide new features. Moreover, new component and connector classes may be required by the adaptation engine at run-time. For instance, as described in Section 7.2.1.2, a system may require to employ new application component and connector classes, while monitoring and adapting these new elements may require new adaptation components. Similar to other declarative self-adaptive approaches, the logic of the adaptation engine in 6A can be changed at run-time. As opposed to other declarative self-adaptive approaches, the topology of the adaptation engine in 6A can also change at run-time. It is important to realize that the dynamic topology of the adaptation engine in 6A results in higher adaptability of its logic compared to other declarative self-adaptive 204 approaches. In fact, the static topology of the existing approaches limits the extent to which their logic can be changed at run-time. For instance, some changes to the logic of an adaptation engine may require employing new adaptation actions from new adaptation components. 7.2.1.6 Adaptation Engine: Component and Connector Classes As described in Section 7.2.1.3, addition of new application component and connector classes to the run-time application may be dependent on new adaptation component classes with new adaptation capabilities. As opposed to other declarative self-adaptive approaches, 6A dynamically employs adaptation component and connector classes. Therefore, the set of adaptation component and connector classes can change at run- time. This also results in a higher adaptability level for application components and connectors in 6A. 7.2.2 Adaptation Performance In this section, I compare the performance of 6A to the performance of the existing adaptation approaches in order to show that the time complexity of 6A is similar to (and in one case better than) the time complexity of the existing adaptation approaches. Moreover, I show that compared to some adaptation approaches 6A has better space complexity. To this end, I am only interested in the declarative self-adaptive approaches. These approaches search for valid configurations of components that satisfy software requirements and calculate adaptation plans to adapt the run-time applications. 205 First, in section 7.2.2.1, I compare the (time and space) complexity of 6A to the com- plexity of a general purpose constraint solver, when it is set up to solve adaptation problems. I will show that 6A is able to leverage domain-specific knowledge to outper- form a general constraint solver. In the subsequent sections (Sections 7.2.2.2 to 7.2.2.5), I compare the complexity of 6A to the complexity of other adaptation approaches, and show that the complexity of other approaches are similar (or worse) than the complexity of 6A. Many of these approaches handle dierent types of software requirements; hence, direct and detailed comparison of their complexity is not possible. In those cases, I provide a discussion on the complexity order and the similarity of their algorithms to 6A. For cases that are more similar to 6A (Planit and Sykes, in particular), I provide detailed algorithmic analysis or empirical comparisons. 7.2.2.1 Alloy In this section, I compare the performance of 6A to the performance of a general con- straint solver to solve adaptation problems. In particular, I show that 6A leverages the domain-specific knowledge for software adaptation and outperforms the general constraint solver. Adaptation problems solved by 6A can be formalized and solved with a general object modeling and analysis tool, such as Alloy. 1 Alloy [48] provides a lightweight modeling language to describe objects, objects’ relations, and objects’ types in a system. In addition, Alloy allows definition of structural constraints in the form of first-order relational logic. 1 http://alloy.mit.edu 206 Alloy also provides an analyzer capable of finding models that satisfy constraints defined on a set of objects. To solve a problem, Alloy translates a constraint satisfaction problem to a boolean satisfiability (SAT) problem and utilizes an o-the-shelf SAT-solver to find a solution to it. In the case of software configuration problem, the underlying SAT-solver “blindly” (without considering the relation between component interfaces) examines all possible combinations of components to find a valid configuration. Consequently, the time complexity of Alloy is exponential in the number of interfaces in a system (tight asymptotic upper and lower bounds). In contrast, 6A provides a directed search algorithm that considers the relations among component interfaces to search for valid configurations. Therefore, the time complexity of 6A is lower than the Alloy analyzer. In particular, in this section, I show that the asymptotic lower bound on the time complexity of 6A (calculated in Section 5.5), (n 2 ), is lower than the time complexity of the Alloy analyzer. I will also show that, although the asymptotic upper bound of time complexity of 6A has the same complexity order (i.e., exponential) as the Alloy analyzer, 6A outperforms the Alloy analyzer in most of the test cases. In addition, I show that the space complexity of the Alloy analyzer is exponential, and state-space explosion happens quickly in my test cases. To compare the complexity of 6A to the complexity of the Alloy analyzer, when there are some structural constraints, I generate several test cases with varying number of components and interfaces. In each test case, each component has 2 provided interfaces and 0 or 1 required interfaces. Moreover, each required interface of a component can be matched to provided interfaces of 2 dierent components. Therefore, there are several 207 0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 10 1 10 0 10 1 10 2 10 3 Number of Interfaces Time in Seconds 6A Alloy Constraint Solver Figure 7.7: The time complexity of 6A vs. the Alloy analyzer, in the presence of structural constraints. configurations for each test case that satisfy the functional properties. However, several candidate configurations in each test case have cycles. Figure 7.7 depicts the amount of time required to find adaptation plans for both 6A and the Alloy analyzer, when they solve the same adaptation problems. Note that the Alloy analyzer is not able to find plans for adaptation problems with large number of interfaces, because the state-space created by the Alloy analyzer grows exponentially with the number of interfaces and explodes in the case of adaptation plans with large 208 0 50 100 150 0 100 200 300 400 Number of Interfaces Memory Usage in MB 6A Alloy Figure 7.8: Required Memory for planning vs. number of interfaces in Alloy and 6A. number of interfaces. As Figure 7.7 depicts, the Alloy analyzer has tight exponential time complexity. Moreover, the upper bound on the time complexity of 6A is exponential. However, the lower bound on the time complexity of 6A is lower than that of the Alloy analyzer. Figure 7.8 shows that the space complexity of the Alloy analyzer is exponential in the number of interfaces, while the space complexity of 6A is linear in the number of interface. 7.2.2.2 Planit Planit [8] find adaptation plans by utilizing the LPG planner [27], a temporal logic-based planner. Complexity of Planit depends on the complexity of its planner when provided with its adaptation domain model description. Since the adaptation capabilities of Planit are dierent from the adaptation capabilities of 6A, I cannot directly compare the complexity of Planit to 6A. However, I can directly compare the complexity of LPG to 6A 209 10 20 30 40 50 0 2 4 6 8 Number of Interfaces Time in Seconds 6A Planit Figure 7.9: Required time for planning vs. number of interfaces. when LPG plans to solve the same adaptation problems that 6A solves (i.e., when LPG is provided with a domain model description that has the adaptation capabilities of 6A). To this end, I provide a domain model description to LPG that is capable of planning for adaptation problems with functional requirements. To compare LPG and 6A, I randomly generated adaptation problems with variable numbers of components and interfaces. Each component in each adaptation problem has 2 interfaces (combination of provided and required) and each required interface is provided by exactly one required interface. For each number of interfaces, I generated several adaptation problems and calculated the average time required for planning. Note that, in these experiments, no structural constraints and quality preferences is enforced. As described in Section 5.5, the time complexity of 6A in this condition is(n 2 ). Figures 7.9 and 7.10 provide the results of this experiment. As these figures depict, both time and space complexity of LPG are exponential. In fact, LPG was not able to find plans for the adaptation problems with more than 46 interfaces due to state-space explosion. 210 10 20 30 40 100 200 Number of Interfaces Memory Usage in MB 6A Planit Figure 7.10: Required Memory for planning vs. number of components. 7.2.2.3 The Sykes Approach The Sykes approach to declarative software adaptation [90] receives the software re- quirements in the form of required capabilities, explicit structural constraints, and qual- ity preferences. Each capability is mapped to a set of components that provide the capability. Sykes provides a composition algorithm called the assembly process. This process searches for a valid configuration of components that satisfy the software re- quirements. To find a configuration, the assembly process performs a depth-first search over the dependency graph between required and provided interfaces of components. The assembly process keeps track of unresolved required interfaces of components in the configuration, and in each step resolves one interface by selecting a component that provides a matching interface. Required interfaces of the newly selected component are added to the list of unresolved interfaces. The assembly process repeats this until all components’ dependencies are resolved. To adapt the run-time application from its current configuration to the new configuration, the Sykes approach provides a separate 211 module that calculates the architectural dierence between the current and the new con- figuration and finds a plan to enact the changes to the system. Details of the algorithm and complexity of this module are not accessible. Structural constraints are provided to the Sykes approach in the form of first-order logic. Each time the assembly process finds a configuration, the Sykes approach invokes Prolog to validate the configuration against the structural constraints. The Sykes ap- proach is also able to consider quality preferences to choose from alternative component configurations. In particular, this approach searches for a configuration that maximizes the average of components’ utility values. Sykes provides an optimal and a sub-optimal algorithm to handle quality properties. The asymptotic lower and upper bounds on the time complexity of the Sykes ap- proach in the case of structural constraints is the same as those of 6A: O(n 2 ) and (m:n 2 ), where m is the number of alternative configurations (in the absence of structural con- straints) and n is the number of interfaces in the system. However, distinguishing final and global structural constraints results in performance advantages (see Section 5.5.3.2) for 6A, compared to the Sykes approach (since it only evaluates the structural constraints after a configuration is found). In addition, the time complexity of the optimal algorithm for quality preferences in the Sykes approach is the same as that in 6A (for non-additive preferences), (m:n 2 ). The Sykes approach only supports one type of optimization (for a non-additive property). Recall (from Section 5.5.2.3) that in the case of additive properties 6A yields better performance. 212 The logic followed by the sub-optimal setting in the 6A is similar to the logic of sub- optimal algorithm in the Sykes approach. As a result, the optimality of the sub-optimal algorithm of the Sykes approach is similar to the optimality of 6A in the sub-optimal setting. In particular, the sub-optimal algorithm in the Sykes approach achieves 90-100% optimality (98.9% optimality on average), for the provided random test cases in [90]. 6A with the sub-optimal setting achieves 86-100% optimality for the test cases shown in Figure 5.24 (97.46% optimality on average). The slight dierence in the optimalities is due to the dierences in the test conditions. 7.2.2.4 PLASMA PLASMA, a prior approach I investigated, leverages the Model-Based Planner (MBP) [11] to search for adaptation plans. However, the time and space complexity of MBP in the case of adaptation domain is exponential. Therefore, state explosion does not allow adaptation planning when the number of interfaces in the run-time application increases. In contrast, 6A utilizes HTN planning, which plans based on task decomposition, does not need to expand the state-space and does not encounter this problem. 7.2.2.5 MADAM Mobility and adaptation enabling middleware (MADAM) [68] solves adaptation prob- lems that involve calculation of component configurations for multiple applications, and allocation of resources to them, which is an NP-Hard problem. As opposed to MADAM, 6A only deals with one application and does not deal with resource allocation. MADAM 213 Table 7.2: Comparison of adaptation artifacts utilized by 6A vs. the other similar declar- ative adaptation approaches. Software Artifact 6A Similar Declarative Adap- tation Approaches Adaptation Logic ADL models of meta- components Composition algorithm Adaptation Functionality Meta-components Meta-components Structural Constraints Predicate logic Predicate logic Logic to account for Qual- ity Properties Cost functions in ADL models Composition algorithm provides a brute-force algorithm, a greedy algorithm, and a specific graph-based algo- rithm [2] to solve adaptation problems. The time complexity of the brute-force algorithm in MADAM is similar to the asymptotic upper-bound complexity of 6A. The greedy al- gorithm for MADAM is similar to the sub-optimal setting of 6A in handling quality properties. The graph-based algorithm in MADAM creates a digraph of the exponen- tial size in the number of variation points. This algorithm has polynomial run-time complexity in the existence of special resource constraints. Authors of [16] provide several heuristics to reduce the exponential complexity of algorithms to calculate component configurations for product-line software systems. This publication does not provide any data to show and compare the impact of dierent heuristics on the optimality or complexity of suggested solutions. Therefore, I am unable to directly compare 6A to these solutions. 7.2.3 Domain Architect Eort To use dierent adaptation approaches, domain architects need to provide dierent software artifacts and perform dierent activities. Activities and artifacts provided to 214 6A are dierent from those in other declarative adaptation approaches. In this section, I provide 6A’s methodology to the software adaptation life-cycle. I compare the domain architect’s activities in various life-cycle stages in 6A vs. the other declarative adaptation approaches. Finally, I show that following the methodology of 6A to provide and maintain adaptation artifacts requires less domain architect’s eort. Table 7.2 compares the equivalent software artifacts required by 6A vs. artifacts required by the other adaptation approaches. In this comparison, I only consider declar- ative adaptation approaches that handle structural constraints and quality preferences. Note that adaptation logic in these approaches is hard-coded in their composition al- gorithms. The composition algorithm receives software requirements and calculates run-time application configuration. Moreover, it finds an adaptation plan to change the run-time application configuration from its current state to its goal state. In con- trast, the adaptation logic in 6A is provided in a formal way. The adaptation logic in 6A is the aggregation of the adaptation action behaviors (expressed in ADL models of meta-components) into the 6A adaptation HTN. In 6A, an HTN planner utilizes the 6A adaptation HTN to concurrently calculate the run-time application configuration and the plan to adapt the run-time application. Moreover, the logic to account for quality proper- ties in the other declarative adaptation approaches is hard-coded into their composition algorithms, while in 6A, it is provided in the form of cost functions for adaptation actions (expressed in ADL models of meta-components). In fact, the adaptation logic and the al- gorithm that applies the adaptation logic in the other declarative adaptation approaches are the same, while in 6A the adaptation logic (6A adaptation HTN) is separated from the algorithm that applies it (HTN planner). 215 Table 7.3: Comparison of domain architect’s activities and eort to provide and maintain adaptation artifacts in 6A vs. similar declarative adaptation approaches. Domain architect activity 6A Similar declarative adaptation approaches Relative eort required by 6A Providing adapta- tion logic ADL modeling of meta-components Coding the adap- tation logic into a composition algo- rithm Less eort required by 6A. Modeling is generally easier than coding. Providing adapta- tion functionality Coding meta- components Coding meta- components Less eort required by 6A. ADL models guide/help code generation. Updating adapta- tion behavior Updating the ADL models and/or code modification on meta-components Code modification on the composition algorithm and/or meta-components Less eort required by 6A. Code mod- ification is harder than model modifi- cation. Providing logic to account for quality preferences ADL modeling of cost functions Coding the logic to handle quality properties into the composition algo- rithm Less eort required by 6A. Coding and code integration is harder than provid- ing cost functions. Updating logic to account for quality preferences Updating cost func- tions in the ADL models Code modification on the composition algorithm Less eort required by 6A. Initial and mainte- nance configuration and deployment None (Re-)configuration and (re-)deployment of the adaptation engine from meta- components and configuration algo- rithm No eort required by 6A. Providing and up- dating structural constraints Providing / updating invariants on ADL models Providing/updat- ing structural con- straints Same eort. Less domain architect eort to provide and maintain adaptation artifacts is a result of the special methodology of 6A to the adaptation engine development life-cycle. Dierent phases in this methodology are as follows: In the design and modeling phase, domain architect designs and models meta-components. To this end, architect follows the 6A 216 adaptation language described in Appendix A. Note that in this phase, domain architect also designs and models structural constraints and cost functions. 6A utilizes ADL models of meta-components to automatically synthesize an adaptation HTN, which specifies the overall adaptation logic of a system (including the structural constraints and quality preferences). In the implementation phase, meta-components are coded. Note that meta-component ADL models simplify implementation phase in my methodology and reduce the human coding mistakes. In fact, meta-component ADL models are utilized to generate code stubs for meta-component classes. Moreover, pre- and post-conditions of the adaptation operations in ADL models guide the coding of individual adaptation operations in meta-component classes. In the configuration and deployment phase, 6A automatically synthesizes the adaptation HTN from individual meta-components ADL models and automatically configures the adaptation layer architecture from individual meta-components. Therefore, this phase puts less burden on the architect and is less error-prone. Finally, in the maintenance phase software architects only require to maintain meta-components and their ADL models. In fact, ADL modeling and capability of 6A to automatically employ software updates into the adaptation engine simplify this phase. For further clarification, Table 7.3 compares the domain architect’s eort to provide and maintain adaptation artifacts in 6A vs. similar declarative adaptation approaches. As indicated in this table, less eort is required to utilize 6A. Note that providing adap- tation policies for prescriptive adaptation approaches requires more eort compared to providing adaptation logic for declarative adaptation approaches. 217 Chapter 8 Related Works At a high level, this dissertation focuses on two main topics and their relations: soft- ware adaptation and integrated software environments. Chapter 3 provides the related works for integrated software environments. Therefore, this chapter only focuses on the software adaptation aspects of my dissertation. As described in Section 1.1.6, there are two major approaches to self-adaptive soft- ware systems: prescriptive and declarative. In the prescriptive approach, adaptation logic is provided in the form of adaptation policies; while, declarative approach has a composition algorithm that calculates the adaptation plans based on the software ar- chitect’s declared requirements. Declarative approach is superior to the prescriptive approach and is followed by 6A. This chapter only provides approaches to declarative self-adaptive software systems. Readers are encouraged to read [90] for a comprehensive list of related works for declarative approaches and a comparison of these approaches to the prescriptive approaches. Each approach in this chapter is compared to 6A based on the following criteria: 218 CR1. Abstraction-level of adaptation goals: Adaptation goals are provided to adapta- tion engines in dierent levels of abstraction. Higher-level goals are more tangible to human users, while more knowledge (on the relationship between goals and application artifacts) and processing is required to translate them to adaptation artifacts. In the lowest level, adaptation goals are provided as the desirable com- ponent configuration in the run-time application. In the medium level, adaptation goals are in the form of required components of the run-time application. Finally, high-level goals are defined based on abstract objectives of the run-time applica- tion. For example, desirable state of the run-time application, desirable tasks to be done by the run-time application, and desirable features provided by the run-time application. CR2. Dynamic update of application domain description: Adaptation approaches that handle high-level goals rely on their knowledge about application artifacts to find adaptation plans. This knowledge is provided to adaptation approaches in the form of application domain descriptions. Application domain descriptions specify how high-level goals are related to application artifacts (i.e., components and con- nectors) and how high-level goals can be achieved using application artifacts. In fact, an application domain description should be updated at run-time as the ap- plication artifacts are changed (failed, updated, added, or removed). For each approach in this chapter, I specify whether the application domain description is required by the approach and whether this application domain description can be automatically updated at run-time. 219 CR3. Dynamic types for adaptable artifacts: A self-adaptive approach may need to manage and adapt new types of application components and connectors that re- quire dierent adaptation steps to be added, updated, or removed. For example, to add a data access component to an application, a data access connector should be used and the connection between the component and a database component should be initiated. As a result, an adaptation engine with no knowledge about data access components and connectors is unable to employ a data access compo- nent. For each approach in this chapter, I specify whether it can dynamically adapt new types of application artifacts at run-time. CR4. Dynamic optimization criteria: An adaptation plan for a system may be opti- mized in various ways. End-user’s preferences on the optimization criteria to calculate an adaptation plan may change at run-time. For instance, the end-user may prefer to optimize the adaptation plan in a way that system adaptation takes a minimal time, or the utility of the run-time application after adaptation is maxi- mized. Note that dierent algorithms are required to handle each of these criteria. For each approach in this chapter, I specify whether it can dynamically leverage new optimization criteria in adaptation planning. At the end of this chapter, I provide a summary and comparison of the related works discussed throughout the chapter. 220 8.1 The Sykes Approach The Sykes approach [90] to software adaptation accepts state of the run-time application as adaptation high-level goal. Goals in this approach are similar to those in 6A. This ap- proach provides a directed search algorithm (composition algorithm) on the dependency graph of application components that calculates the topology of the run-time application by analyzing and matching the required and provided component interfaces. In contrast, 6A utilizes HTN planning to find the topology of the run-time application. Similar to my approach, this approach considers the user’s preferences on non-functional properties when alternative topologies are possible. The application domain description (as defined in CR2) in this approach comprises application planning domain description and mappings from application planning do- main description to application components. This domain description is provided by the application architect and does not update dynamically with changes to application artifacts. Note that this approach measures and updates quality properties of applica- tion component models at run-time. Consequently, this approach only supports non- functional aspects of CR2. Although application domain description in 6A is similar to that in this approach, 6A dynamically synthesizes the application domain description from component ADL models. The Sykes approach utilizes an adaptation algorithm that calculates architectural dierences between the current and newly calculated run-time application topology and provides an adaptation plan to adapt the run-time application. This adaptation algorithm works based on a static set of adaptation operations. Moreover, the logic 221 of the composition algorithm is also static. Consequently, Sykes’s approach does not support CR3 and CR4. In contrast to this approach, 6A utilizes HTN planning to find adaptation plans. Section 7.2.2.3 provides more details about this approach and compares its performance to the performance of 6A. 8.2 Feature-oriented Declarative Approach In a feature-oriented declarative approach to software adaptation, adaptation engine receives desirable features (high-level goals) in the run-time application and calculates adaptation plans. Features represent both particular system capabilities and extensions of the architecture at well-defined variation points. In other words, each feature maps to the configurations of a subset of the system’s architecture. Full architecture of a system can be composed by selecting desirable features and deploying their related sub-architectures at well-defined extension points. An application domain description (as defined in CR2) in this approach is in the form of feature models. A feature model describes the eect of each feature on various system objectives (functional and non- functional requirements). In fact, each feature may satisfy or break some system objec- tives. Feature models also model the mappings from features to sub-architectures of the run-time application. This approach runs feature-oriented analyses to select a combina- tion of features that satisfies run-time application requirements. Goals and application domain descriptions in this approach are dierent from those in 6A. Goals in 6A are in the form of the desirable state of the run-time application provided in first-order logic. 222 In addition, application domain descriptions in 6A specify how run-time application components may change the state of the run-time application. Horkoshi et al. [46] and FUSION [32] are two examples of feature-oriented declarative approach. Horkoshi et al. approach only handles non-functional requirements. This approach focuses on reducing the complexity of the composition algorithm to select the combination of features. This approach also tries to optimize a system’s quality properties in presence of contradicting non-functional properties. Feature models in this approach do not change dynamically, therefore this approach does not support CR2. Moreover, composition algorithm in this approach has static logic, therefore this approach does not satisfy CR3 and CR4. FUSION, on the other hand, handles functional and quality properties. Feature specifications and mappings between features and architectural models in FUSION are manually provided by software architect and does not change dynamically. However, this approach provides a learning algorithm that dynamically adjusts the eect of features on system non-functional requirements by updating the non-functional parameters in the feature models. Therefore, this approach only satisfies non-functional aspects of CR2 and does not support CR2 completely. For instance, new features cannot be automatically added to the feature models as new application components become available. To adapt the run-time application, this approach calculates adaptation plans based on a static set of adaptation actions that do not change at run-time, therefore this approach does not support CR3. Moreover, this approach optimizes the run-time application to maximize a utility function and cannot dynamically switch to a dierent optimization criterion, therefore this approach does not support CR4. 223 8.3 Data-flow Declarative Approach Ambite et al. [3] provide a software configuration approach that calculates the topology of a data-flow architecture to fulfill the adaptation goals. The high-level goal in this approach is to fulfill data queries. Data sources and data operators in this approach are equivalent to components in 6A. This approach provides a search algorithm to analyze and match interfaces of the data sources and data operators. It is also able to dynamically create data adaptors to match the component interfaces. Here, data adaptors are equivalent to connectors in 6A. Note that 6A is not able to create new types of connectors for the run-time application. Authors have not incorporated quality preferences in their algorithm, but have left it for future work. Application domain description in this case is in the form of relational description of data. Interfaces of data sources and data operators in this approach are modeled by relational descriptions in an expressive logic language. Since this approach only configures data-flow architectures and does not adapt them, the CR2 is not applicable to this approach. Finally, as opposed to 6A, the adaptation engine in this approach is static and specific to data-flow architectures; therefore, this approach does not support CR3 and CR4. 8.4 AI-based Declarative Approach Arshad et al. [8] provide a framework called Planit for deployment and reconfiguration of distributed systems. Planit utilizes a temporal planner to find optimized adaptation plans with minimum execution time. Planit handles low-level goals defined as desirable 224 architecture of the run-time application. In contrast to Planit, the adaptation planner in 6A concurrently searches for a valid configuration and calculates an adaptation plan to reach that configuration. Moreover, 6A uses planning to find both application and adaptation plans. Planit starts, stops, and connects components and connectors but does not add, remove, and replace them. It takes to account local structural constraints. It also handles quality requirements and searches for adaptation plans with minimum execution time. In fact, CR2 is not applicable to Planit as it only handles low-level goals. Similar to 6A, Planit uses an AI planning technique to find adaptation plans, although it does not dynamically synthesizes the adaptation domain descriptions for its planner. Adaptation actions in Planit are defined as part of its static adaptation domain description and are not tied to the meta-components that actually enact the adaptation actions on the run-time application. Therefore, changes in the adaptation capabilities (e.g., by providing a new meta-level component), requirements (e.g., need to adapt a new component type), and quality objectives of a system cannot be automatically reflected on the adaptation domain description used by Planit. This means that Planit does not support CR3, CR4. Section 7.2.2.2 compares the performance of this approach to 6A. Maghraoui et al.’s approach [31] also uses an AI planning technique, Partial Order Planning (POP) [70], to plan the adaptation of a data center from its current state to its desired state. Therefore, this approach handles low-level adaptation goals and con- sequently CR2 is not applicable to this approach. This approach supports functional requirements (goal state of the data center) and structural constraints. Generated plans by this approach use the available provisioning operations in the underlying provi- sioning platform. To get higher performance, authors modified the POP based on the 225 provisioning domain properties and requirements. Finally, the planner in this approach uses a static adaptation planning domain description, therefore this approach does not support CR3 and CR4. 8.5 ArchStudio3 Archstudio3 [23] provides a solution to self-healing systems. Adaptation goals in Arch- Studio3 are low-level and are in the form of a desirable architecture of the run-time application. Therefore, CR2 is not applicable to this approach. ArchStudio3 calculates the architectural repairs and applies them to the run-time application. To this end, it uses adaptation operations provided by the underlying run-time infrastructure. In other words, to adapt a system, this approach always uses a fixed set of adaptation opera- tions in a pre-determined order. This limits the ability of Archstudio3 to respond when the adaptive behavior or the underlying run-time infrastructure should be changed. Therefore, this approach does not support CR3 and CR4. ArchStudio3 leverages xADL 2.0, an architecture description language (ADL), to model architectural elements, topologies, and architectural repairs. On the other hand, the ADL in 6A does not model architectural repairs and models component behaviors. Instead, the ADL in 6A is used to model meta-components. 8.6 Service-oriented Declarative Approach Ingstrup et al.’s [47] approach and F4Plan [5] use AI planning techniques in order to find adaptation plans for service-oriented architectures. These approaches handle low-level 226 goals in the form of a desirable topology of a run-time system. As a result, CR2 does not apply to these approaches. Authors of [5] suggest a planning framework that allows for various AI planners to be employed by the adaptation approach. To this end, they provide a set of translators to translate between dierent description languages in order to support dierent planners. The composition logic (adaptation planning domain description) in these approaches is separated from their composition algorithms (planners). However, in contrast to 6A, the adaptation actions in these systems are provided to the system in a static way and cannot be changed at run-time. Therefore, these approaches do not support CR3 and CR4. Finally, in contrast to 6A, these approaches do not consider structural constraints and are designed for a specific architectural style. 8.7 Aura Aura [35] is an architectural framework for user mobility in ubiquitous computing en- vironments. Aura provides software adaptation in order to reconfigure applications running on a system, when user requirements or environment conditions change. To this end, Aura works on a higher granularity level compared to the granularity level of 6A that configures components and connectors to form applications. High-level goals in Aura are in the form of tasks that a user performs. Application domain description in this approach is provided by the user and is in the form of task descriptions. Each task 227 is described by services required to perform the task and the preferred quality trade- os for executions of those services. As the application domain description is provided manually, this approach does not support CR2. Aura provides a configuration algorithm that configures the run-time environment by selecting and configuring appropriate suppliers (i.e., service providers) in order to perform user tasks at user preferred quality levels. Moreover, Aura reconfigures and adapts the run-time environment whenever user requirements change (e.g., new tasks or dierent quality preferences) or the environment changes (e.g., computation resources become scarce). Aura’s adaptation engine cannot be changed at run-time to adapt new types of application artifacts (i.e., suppliers). For instance, Aura may need to manage and adapt new types of suppliers that have to be monitored, configured, and adapted based on a new logic. Therefore, Aura does not support CR3. Note that Aura has a dierent solution to this problem that involves wrapping applications in order to make them conformant to Aura’s APIs. Moreover, Aura is incapable of utilizing new optimization criteria at run-time. Consequently, Aura does not support CR4. 8.8 MADAM Mobility and adaptation enabling middleware (MADAM) [2, 68] is a middleware for product-line systems. MADAM monitors the user’s requirements and system’s and environment’s context, and calculates adaptation plans to adapt component-based ap- plications running on a single device (e.g., on a mobile device). To this end, MADAM finds a component configuration for each application to satisfy functional requirements, 228 resource constraints, and quality preferences. Such a goal is a medium-level goal, because MADAM knows the components in an application and only needs to select from alterna- tive component configurations. By contrast, 6A does not support resource allocation and management. Moreover, in contrast to 6A, goals in MADAM are flexible. For instance, MADAM may choose to deploy only a sub-set of required applications in a device. Note that CR2 is only applicable to approaches with high-level goals and does not apply to MADAM. Several static composition algorithms are provided for MADAM to calculate component configurations and adaptation plans. These static algorithms cannot change at run-time; therefore, MADAM does not support CR3 and CR4. Section 7.2.2.5 compares the performance of this approach to 6A. 8.9 Goal-oriented Declarative Approach In [73], Nakagawa et al. provide a software design and development process as well as a software composition tool called Goal-Oriented Configuration Compiler (GOCC). GOCC generates architectural configurations from goal-oriented requirements descrip- tions. Authors enhanced and utilized KAOS [58], a goal-oriented requirement analysis method, to describe system goals, requirements, entities, and agents. GOCC analyzes goal models provided in KAOS and generates architecture configurations. Architectures generated by KAOS include control loops that adapt the behavior of the run-time appli- cation based on the state of the run-time application. After architecture configurations are generated, software developers need to implement software components and archi- tecture based on generated configurations and guidelines provided by this approach. 229 This approach does not make run-time architectural changes (e.g., component ad- dition or removal) to the run-time application. Moreover, changes to the run-time component are not reflected into the goal models. Consequently, CR2 is not applicable to this approach. Moreover, since this approach does not make run-time changes to the structure of the run-time application, CR3 and CR4 are not applicable to this approach. 8.10 Web-service Composition Approach provided by Bertoli et al. in [12] synthesizes composite web-services by orchestrating existing web-services. High-level goals in this approach are provided as the desirable state of a composite web-service. This approach synthesizes a controller that invokes external web-services to achieve its desirable goal state. To synthesize the controller, this approach utilizes Model Based Planner (MBP). Similar to 6A, the application planning domain description in this approach is synthesized dynamically from the descriptions of individual external web-services. To this end, this approach translates the web-service descriptions provided in WS-BPEL [50] into planning domain model descriptions. This is in contrast to 6A that configures, monitors, and adapts run- time applications, this approach only configures a composite-web service. CR2, CR3, and CR4 are not applicable to this approach. Note that there are other web-service composition approaches such as [87] with similar properties. 230 Table 8.1: Comparison of self-adaptive declarative software approaches. Approach CR1. Goal abstraction CR2. Dynamic domain description CR3. Dynamic adaptable artifacts CR4. Dynamic optimization criteria 6A High-level Yes Yes Yes Sykes approach High-level Yes (NF 1 only) No No FUSION (Feature- oriented declarative approach) High-level Yes (NF only) No No Data-flow declarative approach High-level NA 2 No No AI-based declarative approach Low-level NA No No Archstudio 3 Low-level NA No No Service-oriented declarative approach Low-level NA No No Aura High-level No No No MADAM Medium-level NA No No Goal-oriented declarative approach High-level NA NA NA Web-service composition High-level NA NA NA 8.11 Summary Table 8.1 compares related works described in this chapter to 6A based on the provided criteria. 6A, similar to the Sykes approach, accepts application states as high-level goals. High-level goals abstract away details of software components and architectures and are easier to work with. Moreover, 6A dynamically synthesizes application domain 1 Non-Functional 2 Not Applicable 231 descriptions from ADL models of application components. Consequently, 6A can up- date application domain model description when application components are changed (updated, failed, removed, or added). This increases the self-adaptability level of 6A. As Table 8.1 shows, although Sykes’s approach and FUSION (with feature-oriented declar- ative approach) support CR2 to some extent, only 6A fully supports this criterion among all other declarative approaches described in this dissertation. In additions, since HTN used by 6A is dynamically synthesized from ADL models of meta-components, 6A is able to employ new adaptation components at run-time. Consequently, new adaptation capabilities can be added to the adaptation engine of 6A by employing new meta components with new adaptation capabilities. Therefore, unlike all other approaches, 6A supports CR3. Finally, meta-component ADL models also declare cost functions that determine the optimization criterion for the adaptation engine. These cost functions are dynamically employed by HTN in 6A. As a result, in contrast to all other approaches, 6A handles CR4. 232 Chapter 9 Conclusions This dissertation provides a reference architecture for integrated self-adaptive software environments. I have designed, implemented, and integrated several architecture-centric elements to support such reference architecture. Each of these elements resolves one of the problems associated with architecture-based self-adaptive software systems, recog- nized in this dissertation. The elements of my solution are, (1) the adaptive layered software style, (2) iDARE, a reference architecture for integrated Development And Run-time Environments, (3) PLASMA, a Plan-based Layered Architecture for Software Model-driven Adaptation, and (4) 6A, An Automated Adaptable Architecture Adapta- tion Approach. The adaptive layered architectural style introduced in this dissertation distinguishes two types of components: application components and meta-components. Applica- tion components implement functionality that achieves the application goals, while meta-components are architecturally aware and facilitate adaptation and management of architectural elements (e.g., components and connectors). The adaptive layered style 233 distinguishes three distinct, specialized types of meta-level components: collectors, an- alyzers, and admins. This style allows meta-level components to themselves be moni- tored, managed, and adapted by other (higher layer) meta-components. To this end, the adaptive layered style presents a meta-layering scheme in which meta-level components at a given meta-layer monitor, manage, and adapt components at the layer below. This architectural style achieves clear separation of adaptation concerns by allowing an arbi- trary number of meta-layers and supports the design of adaptable adaptation engines. iDARE and PLASMA are designed based on this architectural style. The iDARE reference architecture is useful for understanding, classifying, and study- ing development environments in a unified manner, from the perspective of their relation to run-time environments. I categorized a wide range of development environments from dierent programming paradigms based on their level of interaction with run-time environments and studied them in the context of iDARE. Specially, I studied SALEs and, in particular, their tools, artifacts, and processes that pertain to their run-time behavior and capabilities. My study identified five possible roles that SALEs’ run-time tools may perform. I also identified the desirable structural and quality properties of SALEs that pertain to the requirements of the self-adaptive applications under their control. I in- corporated my characterizations of SALEs in the design of iDARE. iDARE is designed to loosen the tight integration of the development and run-time environments in order to improve the availability, fault-tolerance, and robustness and decrease the resource consumption in self-adaptive software environments. To this end, iDARE introduces new classes of run-time tools that can be adapted or detached from the development 234 environment at run-time. The design of iDARE leverages the adaptive layered software style. PLASMA addresses the issue of disconnected adaptation artifacts and architectural models by automatically synthesizing the key adaptation artifacts from the architectural models. PLASMA comprises three constituent elements: an AI planning technique (Model-Based Planner), architectural modeling, and the adaptive layered software style. PLASMA uses planning to calculate both application plans and adaptation plans. In PLASMA, instead of providing application planning domain descriptions, application architects provide ADL models of application components. This enables PLASMA to synthesize the application planning domain descriptions dynamically. This dissertation showed that the modeling eort (to provide ADL models, etc.) in PLASMA may only be marginally higher compared to the modeling eort (to provide planning domain de- scriptions, etc.) in its competitor approach, developed by Sykes et al. On the other hand, my technique achieved a higher self-adaptability level compared to its principal com- petitor technique. Automatic synthesis of adaptation artifacts in PLASMA is not limited to the application planning domain descriptions. In fact, PLASMA also synthesizes the adaptation planning domain descriptions from the ADL models of meta-components. Consequently, the behavior of the adaptation engine in PLASMA can be changed at run-time, in order to, for example, adapt new types of application component and con- nectors. While PLASMA sets the stage for adaptation of the adaptation engine itself, the low performance of model-based planner (MBP) to find adaptation plans and its inadequacy to handle adaptation optimization criteria make PLASMA unsatisfactory to this goal. 235 This dissertation introduced 6A to improve the performance and functionality of PLASMA in adaptation plan calculation and adaptation of the adaptation engine itself. 6A is a novel approach to synthesize, adapt, and evolve the self-adaptive behavior in the declarative approach to software self-adaptation. 6A leverages Hierarchical Task Net- works (HTNs) for adaptation logic modeling, adaptation activity modeling, and adap- tation planning. 6A synthesizes, manages, and utilizes a dynamic adaptation HTN that captures all adaptation activities and logic applicable to a run-time application. Adap- tation HTN comprises two parts: (1) common adaptation actions and logic (provided by 6A approach) and (2) domain-specific adaptation actions and logic, optimization cost functions, and structural constraints (provided by domain architects). The domain- specific elements in the adaptation HTN are extracted from the architectural models of meta-components. This dissertation showed that 6A achieves the same (or better) level of performance as the existing declarative approaches. This dissertation also provided the self-adaptability framework to compare the self-adaptability level for architecture- centric self-adaptive software systems. Using this framework, this dissertation showed that 6A provides a higher self-adaptability level compared to the existing self-adaptive software systems. This dissertation also classified the equivalent adaptation artifacts in 6A and other declarative adaptation approaches and compared the domain architect’s eort to provide and maintain them. My analysis shows that it takes less eort to provide and maintain adaptation artifacts by following the 6A’s methodology to the adaptation engine development life-cycle. Finally, this dissertation showed how 6A is implemented as a software environment that follows the design of the iDARE reference architecture. Run-time tools in 6A are 236 implemented as Eclipse plug-ins and are integrated with other development-time tools in Eclipse. The special design of plug-ins in 6A enables this integration. The resulting software environment loosely integrates the development and run-time environments as prescribed by iDARE. Moreover, the layered adaptation engine in this environment has a dynamic structure and allows adaptation of the adaptation engine at run-time. Finally, techniques provided by PLASMA and 6A provide a higher level of self-adaptability for run-time environments. 9.1 Future Research Directions PLASMA provides a novel approach to dynamically employ new application and adap- tation software artifacts at run-time. This provides new research opportunities to dy- namically access and reuse application and adaptation components through open com- ponent repositories. This would require new fast component search algorithms capable of matching components based on their interfaces and state variables. In addition, further research on 6A is required to address several of its current limita- tions. At its current state, 6A supports the logic to adapt the run-time application based on functional requirements, quality preferences, and architectural constraints. 6A can be ex- tended to natively support other adaptation specific activities such as machine-learning features for software adaptation. Moreover, adaptation behavior of a self-adaptive sys- tem is modeled in the SADEL language. This oers further research opportunities for adaptation-specific model analysis tools, to simulate, validate, and verify adaptation behavior of a self-adaptive software system. 237 The iDARE reference architecture provides a new framework and new research op- portunities to revisit and enhance existing software engineering processes, approaches, and tools. New research on software maintenance and evolution can be conducted in the context of iDARE. I believe that the flexibility oered by iDARE can be leveraged to en- hance the existing maintenance and evolution processes. For instance, although iDARE introduces Detachable Tools and Run-time Components, more research is required to find eective designs for these elements. To this end, existing development environments can be redesigned and enhanced to provide native support for Run-time Components and Detachable Tools; new environments can be designed with such support from the get-go. 238 References [1] Erlang programming language. http://www.erlang.org. [2] 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 2006: CoopIS, DOA, GADA, and ODBASE, pages 1686–1704. Springer, 2006. [3] Jos´ e Luis Ambite and Dipsy Kapoor. Automatically composing data workflows with relational descriptions and shim services. In Proceedings of the 6th interna- tional The semantic web and 2nd Asian conference on Asian semantic web conference, ISWC’07/ASWC’07, pages 15–29, Berlin, Heidelberg, 2007. Springer-Verlag. [4] Jesper Andersson, Marcus Comstedt, and Tobias Ritzau. Run-time support for dynamic java architectures. In Proceedings of the ECOOP98 workshop on Object- Oriented Software Architectures, 1998. [5] Franc ¸oise Andr´ e, Erwan Daubert, Gr´ egory Nain, Brice Morin, and Olivier Barais. F4Plan: An approach to build ecient adaptation plans. In 7th International ICST Conference on Mobile and Ubiquitous Systems (MobiQuitous), Sydney, Australia, De- cember 2010. short paper. [6] James E Jr Archer and Michael T Devlin. Rational’s experience using Ada for very large systems. In First International Conference on Ada (R) Programming Language Applications for the NASA Space Station, volume 12, pages 08–61, NASA, Lyndon B. Johnson Space Center, 1986. [7] Joe Armstrong. The development of erlang. SIGPLAN Not., 32(8):196–203, August 1997. [8] Naveed Arshad, Dennis Heimbigner, and Alexander L. Wolf. Deployment and dy- namic reconfiguration planning for distributed software systems. Software Quality Journal, 15(3):265–281, 2007. [9] Fahiem Bacchus and Froduald Kabanza. Using temporal logics to express search control knowledge for planning. Artificial Intelligence, 116(1):123–191, 2000. 239 [10] Fabio Bellifemine, Agostino Poggi, and Giovanni Rimassa. Developing multi-agent systems with JADE. In Intelligent Agents VII Agent Theories Architectures and Lan- guages, volume 1986 of Lecture Notes in Computer Science, pages 42–47. Springer Berlin / Heidelberg, 2001. [11] Piergiorgio Bertoli, Alessandro Cimatti, Marco Pistore, Marco Roveri, and Paolo Traverso. MBP: a model based planner. In Workshop on Planning under Uncertainty and Incomplete Information, 2001. [12] Piergiorgio Bertoli, Marco Pistore, and Paolo Traverso. Automated composition of web services via planning in asynchronous domains. Artificial Intelligence, 174(3):316–361, 2010. [13] T. Bloom and M. Day. Reconfiguration and module replacement in argus: theory and practice. Software Engineering Journal, 8(2):102–108, 1993. [14] Rafael Bordini, Jomi Hbner, and Renata Vieira. Jason and the golden fleece of agent-oriented programming. In Rafael Bordini, Mehdi Dastani, Jrgen Dix, Amal Fallah Seghrouchni, and Gerhard Weiss, editors, Multi-Agent Programming, vol- ume 15 of Multiagent Systems, Artificial Societies, and Simulated Organizations, pages 3–37. Springer US, 2005. Bor05. [15] Gerard Boudier, Ferdinando Gallo, Regis Minot, and Ian Thomas. An overview of PCTE and PCTE+. In Proceedings of the third ACM SIGSOFT/SIGPLAN software engineering symposium on Practical software development environments, SDE 3, pages 248–257, New York, NY, USA, 1988. ACM. [16] Gunnar Brataas and Svein Hallsteinsen. Scalability of decision models for dynamic product lines. 2007. [17] A. W. Brown, A. N. Earl, and J. A. Mcdermid. Software engineering environments: automated support for software engineering. McGraw-Hill, 1992. [18] Alan W. Brown. Integrated project support environments: the aspect project. Academic Press Professional, Inc., San Diego, CA, USA, 1991. [19] Shang-Wen Cheng. Rainbow: Cost-Eective Software Architecture-Based Self- Adaptation. PhD thesis, Carnegie Mellon University, Pittsburgh, 2008. [20] Robert P . Cook and Insup Lee. DYMOS: a dynamic modification system. In Pro- ceedings of the ACM SIGSOFT/SIGPLAN software engineering symposium on High–level debugging, SIGSOFT ’83, pages 201–202, New York, NY, USA, 1983. ACM. [21] Susan A. Dart, Robert J. Ellison, Peter H. Feiler, A. Nico Habermann, and Edited Pe- ter Fritzson. Overview of software development environments, 1992. [22] E.M. Dashofy, A. Van der Hoek, and R.N. Taylor. A highly-extensible, xml-based ar- chitecture description language. In Software Architecture, 2001. Proceedings. Working IEEE/IFIP Conference on, pages 103–112, 2001. 240 [23] Eric Dashofy. Supporting Stakeholder-Driven, Multi-View Software Architecture Model- ing. PhD thesis, University of California, Irvine, 2007. [24] Eric M. Dashofy, Andr´ e van der Hoek, and Richard N. Taylor. Towards architecture- based self-healing systems. In Proceedings of the first workshop on Self-healing systems, WOSS ’02, pages 21–26, New York, NY, USA, 2002. ACM. [25] J. Des Rivieres and J. Wiegand. Eclipse: a platform for integrating development tools. IBM Syst. J., 43:371–383, April 2004. [26] Digital Equipment Corporation. User’s introduction to V AX DEC/CMS. Digital Equip- ment Corporation, 1984. [27] Patrick Doherty and Jonas Kvarnstram. Talplanner: A temporal logic-based plan- ner. AI Magazine, 22(3):95, 2001. [28] T. A. Dolotta, R. C. Haight, and J. R. Mashey. UNIX time-sharing system: The programmer’s workbench. In D. R. Barstow, H. E. Shrobe, and E. Sandewall, edi- tors, Interactive Programming Environments, pages 353–369. McGraw-Hill, New York, 1984. [29] Menggao Dong, Xinjun Mao, Junwen Yin, Zhiming Chang, and Zhichang Qi. SADE: a development environment for adaptive multi-agent systems. In Proceedings of the 12th International Conference on Principles of Practice in Multi-Agent Systems, PRIMA ’09, pages 516–524, Berlin, Heidelberg, 2009. Springer-Verlag. [30] Mark Dowson. ISTAR—an integrated project support environment. Sigplan Notices, 22:27–33, 1987. [31] Kaoutar El Maghraoui, Alok Meghranjani, Tamar Eilam, Michael Kalantar, and Alexander V . Konstantinou. Model driven provisioning: bridging the gap be- tween declarative object models and procedural provisioning tools. In Proceedings of the ACM/IFIP/USENIX 2006 International Conference on Middleware, Middleware ’06, pages 404–423, New York, NY, USA, 2006. Springer-Verlag New York, Inc. [32] Ahmed M. Elkhodary, Naeem Esfahani, and Sam Malek. Fusion: a framework for engineering self-tuning self-adaptive software systems. In Gruia-Catalin Roman and Kevin J. Sullivan, editors, SIGSOFT FSE, pages 7–16. ACM, 2010. [33] David Garlan, Shang-Wen Cheng, An-Cheng Huang, Bradley R. Schmerl, and Peter Steenkiste. Rainbow: Architecture-based self-adaptation with reusable infrastruc- ture. IEEE Computer, 37(10):46–54, 2004. [34] David Garlan, Robert T. Monroe, and David Wile. Foundations of component-based systems. chapter Acme: architectural description of component-based systems, pages 47–67. Cambridge University Press, New York, NY, USA, 2000. 241 [35] David Garlan, Vahe Poladian, Bradley Schmerl, and Jo˜ ao Pedro Sousa. Task-based self-adaptation. In Proceedings of the 1st ACM SIGSOFT workshop on Self-managed systems, pages 54–57. ACM, 2004. [36] John C. Georgas. Supporting Architecture- and Policy-Based Self-Adaptive Software Systems. PhD thesis, University of California, Irvine, 2008. [37] John C. Georgas and R. N. Taylor. Policy-based self-adaptive architectures: A feasibility study in the robotics domain. In Int. Workshop on Software Engineering for Adaptive and Self-managing Systems, 2008. [38] John C. Georgas and Richard N. Taylor. Towards a knowledge-based approach to architectural adaptation management. In Proceedings of the 1st ACM SIGSOFT Workshop on Self-Managed Systems, WOSS 2004, Newport Beach, California, USA, pages 59–63. ACM, 2004. [39] Malik Ghallab, Dana Nau, and Paolo Traverso. Automated planning: theory & practice. Morgan Kaufmann, 2004. [40] Fausto Giunchiglia and Paolo Traverso. Planning as model checking. In Susanne Biundo and Maria Fox, editors, Recent Advances in AI Planning, volume 1809 of Lecture Notes in Computer Science, pages 1–20. Springer Berlin / Heidelberg, 2000. [41] Adele Goldberg. The influence of an object-oriented language on the programming environment. In Proceedings of the 1983 computer science conference, CSC-83, pages 35–54, New York, NY, USA, 1983. ACM. [42] Deepak Gupta, Pankaj Jalote, and Gautam Barua. A formal framework for on-line software version change. Software Engineering, IEEE Transactions on, 22(2):120–131, 1996. [43] Rob High and Stephen Kinder. IBM SOA foundation: An architectural introduction and overview, 2005. [44] G´ ısli Hj´ almt´ ysson and Robert Gray. Dynamic c++ classes: a lightweight mechanism to update code in a running program. In Proceedings of the annual conference on USENIX Annual Technical Conference, ATEC ’98, pages 6–6, Berkeley, CA, USA, 1998. USENIX Association. [45] Christine Hofmeister. Dynamic Reconfiguration. PhD thesis, Maryland Univ., College Park, 1993. [46] Hisayuki Horikoshi, Hiroyuki Nakagawa, Yasuyuki Tahara, and Akihiko Ohsuga. Dynamic reconfiguration in self-adaptive systems considering non-functional prop- erties. In Proceedings of the 27th Annual ACM Symposium on Applied Computing, SAC ’12, pages 1144–1150, New York, NY, USA, 2012. ACM. 242 [47] M. Ingstrup and K.M. Hansen. Modeling architectural change: Architectural script- ing and its applications to reconfiguration. In Software Architecture, 2009 European Conference on Software Architecture. WICSA/ECSA 2009. Joint Working IEEE/IFIP Con- ference on, pages 337 –340, sept. 2009. [48] Daniel Jackson. Alloy: a lightweight object modelling notation. ACM Transactions on Software Engineering and Methodology (TOSEM), 11(2):256–290, 2002. [49] Nico Janssens, Eddy Truyen, Frans Sanen, and Wouter Joosen. Adding dynamic reconfiguration support to jboss aop. In Proceedings of the 1st workshop on Middleware- application interaction: in conjunction with Euro-Sys 2007, MAI ’07, pages 1–8, New York, NY, USA, 2007. ACM. [50] Diane Jordan, John Evdemon, Alexandre Alves, Assaf Arkin, Sid Askary, Charlton Barreto, Ben Bloch, Francisco Curbera, Mark Ford, Yaron Goland, et al. Web services business process execution language version 2.0. OASIS standard, 11:11, 2007. [51] Jukka K¨ a¨ ari¨ ainen. Towards an Application Lifecycle Management Framework. PhD thesis, University of Oulu, 2011. [52] J.O. Kephart and D.M. Chess. The vision of autonomic computing. Computer, 36(1):41 – 50, jan 2003. [53] R. Khare, M. Guntersdorfer, P . Oreizy, N. Medvidovic, and R.N. Taylor. xADL: enabling architecture-centric tool integration with XML. In Proceedings of the 34th Annual Hawaii International Maui Conference on System Sciences, HICSS-34, Maui, Hawaii, USA. IEEE Computer Society, 2001. [54] Dongsun Kim, Sooyong Park, Youngkyun Jin, Hyeongsoo Chang, Yu-Sik Park, In- Young Ko, Kwanwoo Lee, Junhee Lee, Yeon-Chool Park, and Sukhan Lee. SHAGE: a framework for self-managed robot software. In Proceedings of the 2006 international workshop on Self-adaptation and self-managing systems, SEAMS ’06, pages 79–85. ACM, 2006. [55] David B. Leblang and Robert P . Chase, Jr. Computer-aided software engineering in a distributed workstation environment. In Proceedings of the first ACM SIGSOFT/SIG- PLAN software engineering symposium on Practical software development environments, SDE 1, pages 104–112, New York, NY, USA, 1984. ACM. [56] Insup Lee. Dymos: a dynamic modification system. PhD thesis, University of Wisconsin–Madison, 1983. [57] Jill Fain Lehman, John Laird, and Paul Rosenbloom. A gentle introduction to soar, an architecture for human cognition. In In S. Sternberg & D. Scarborough (Eds), Invitation to Cognitive Science. MIT Press, 1996. [58] Emmanuel Letier et al. Reasoning about agents in goal-oriented requirements engineering. PhD thesis, PhD thesis, Universit´ e catholique de Louvain, 2001. 243 [59] M Sh Levin. Combinatorial optimization in system configuration design. Automa- tion and Remote Control, 70(3):519–561, 2009. [60] J. Magee, J. Kramer, and M. Sloman. Constructing distributed systems in Conic. Software Engineering, IEEE Transactions on, 15(6):663 –675, jun 1989. [61] Je Magee, Naranker Dulay, Susan Eisenbach, and Je Kramer. Specifying dis- tributed software architectures. In Wilhelm Schfer and Pere Botella, editors, Soft- ware Engineering ESEC ’95, volume 989 of Lecture Notes in Computer Science, pages 137–153. Springer Berlin Heidelberg, 1995. [62] Scott Malabarba, Raju Pandey, Je Gragg, Earl Barr, and J. Fritz Barnes. Runtime support for type-safe dynamic java classes. In Proceedings of the 14th European Conference on Object-Oriented Programming, ECOOP ’00, pages 337–361, London, UK, UK, 2000. Springer-Verlag. [63] S. Malek, Chiyoung Seo, S. Ravula, B. Petrus, and N. Medvidovic. Reconceptualiz- ing a family of heterogeneous embedded systems via explicit architectural support. In Software Engineering, 2007. ICSE 2007. 29th International Conference on, pages 591– 601, May. [64] Sam Malek, Marija Mikic-Rakic, and Nenad Medvidovic. A decentralized redeploy- ment algorithm for improving the availability of distributed systems. In Proceedings of the Third international working conference on Component Deployment, CD’05, pages 99–114, Berlin, Heidelberg, 2005. Springer-Verlag. [65] Sam Malek, Marija Mikic-Rakic, and Nenad Medvidovic. A style-aware archi- tectural middleware for resource-constrained, distributed systems. IEEE Trans. Software Eng., 31(3):256–272, 2005. [66] Spiros Mancoridis, Richard C. Holt, and David A. Penny. A conceptual framework for software development. In Proceedings of the 1993 ACM conference on Computer science,Indianapolis, Indiana, USA, CSC ’93, pages 74–80, New York, NY, USA, 1993. ACM. [67] Nenad Medvidovic, David S. Rosenblum, and Richard N. Taylor. A language and environment for architecture-based software development and evolution. In ICSE, pages 44–53, 1999. [68] Marius Mikalsen, Nearchos Paspallis, Jacqueline Floch, Erlend Stav, George A. Papadopoulos, and Akis Chimaris. Distributed context management in a mobility and adaptation enabling middleware (madam). In Proceedings of the 2006 ACM symposium on Applied computing, SAC ’06, pages 733–734, New York, NY, USA, 2006. ACM. [69] Marija Mikic-Rakic and Nenad Medvidovic. Support for disconnected operation via architectural self-reconfiguration. In Autonomic Computing, 2004. Proceedings. International Conference on, pages 114–121. IEEE, 2004. 244 [70] Steven Minton, John Bresina, and Mark Drummond. Total-order and partial-order planning: a comparative analysis. J. Artif. Int. Res., 2(1):227–262, January 1995. [71] H. A. Muller and K. Klashinsky. Rigi-a system for programming-in-the-large. In Proceedings of the 10th international conference on Software engineering, ICSE ’88, pages 80–86, Los Alamitos, CA, USA, 1988. IEEE Computer Society Press. [72] Robert Munck, Patricia Oberndorf, Erhard Ploedereder, and Richard Thall. An overview of DOD-STD-1838A (proposed) the common APSE interface set: revision. Sigplan Notices, 24:235–247, 1989. [73] Hiroyuki Nakagawa, Akihiko Ohsuga, and Shinichi Honiden. GOCC: A config- uration compiler for self-adaptive systems using goal-oriented requirements de- scription. In Proceedings of the 6th International Symposium on Software Engineering for Adaptive and Self-Managing Systems, pages 40–49. ACM, 2011. [74] Dana Nau, Yue Cao, Amnon Lotem, and Hector Mu˜ noz-Avila. Shop: Simple hierarchical ordered planner. In Proceedings of the 16th international joint conference on Artificial intelligence-Volume 2, pages 968–973. Morgan Kaufmann Publishers Inc., 1999. [75] Dana Nau, Okhtay Ilghami, Ugur Kuter, J. William Murdock, Dan Wu, and Fusun Yaman. SHOP2: An htn planning system. Journal of Artificial Intelligence Research, 20:379–404, 2003. [76] Dana Nau, H´ ector Munoz-Avila, Yue Cao, Amnon Lotem, and Steven Mitchell. Total-order planning with partially ordered subtasks. In International Joint Confer- ence on Artificial Intelligence, volume 17, pages 425–430. LAWRENCE ERLBAUM ASSOCIATES LTD, 2001. [77] Hyacinth S. Nwana, Divine T. Ndumu, Lyndon C. Lee, Jaron C. Collis, and Ip- swich Ip Re. ZEUS: A toolkit for building distributed multi-agent systems. Applied Artifical Intelligence Journal, 13:129–186, 1999. [78] Peyman Oreizy, Nenad Medvidovic, and Richard N. Taylor. Architecture-based runtime software evolution. In ICSE, pages 177–186, 1998. [79] Dewayne E. Perry and Published In. The inscape environment. In In Proceedings of the 11th International Conference on Software Engineering, pages 2–12. IEEE Computer Society Press, 1989. [80] Dewayne E. Perry and Gail E. Kaiser. Infuse: A tool for automatically managing and coordinating source changes in large systems. In Proceedings of the 1987 ACM Computer Science Conference, St. Louis MO, pages 292–299, 1987. [81] J. Peterson, P . Hudak, and G. S. Ling. Principled dynamic code improvement. In USENIX Technical Conference, 1997. 245 [82] Reticular Systems. AgentBuilder - an integrated toolkit for constructing intelligence software agents, 1999. [83] Pierre-Michel Ricordel and Yves Demazeau. From analysis to deployment: A multi- agent platform survey. In Engineering Societies in the Agents World, First International Workshop, ESAW 2000, Berlin, Germany, volume 1972 of Lecture Notes in Computer Science, pages 93–105. Springer Berlin Heidelberg, 2000. [84] Graham Ross. IntegralC: a practical environment for C programming. Sigplan Notices, 22:42–48, 1987. [85] Mark E. Segal and Ophir Frieder. On-the-fly program modification: Systems for dynamic updating. Software, IEEE, 10(2):53–65, 1993. [86] Zhongzhi Shi, Haijun Zhang, Yong Cheng, Yuncheng Jiang, Qiujian Sheng, and Zhikung Zhao. MAGE: An agent-oriented programming environment. In Pro- ceedings of the 3rd IEEE International Conference on Cognitive Informatics, ICCI 2004, Victoria, Canada, pages 250–257. IEEE Computer Society, 2004. [87] Evren Sirin, Bijan Parsia, Dan Wu, James Hendler, and Dana Nau. Htn planning for web service composition using shop2. Web Semantics: Science, Services and Agents on the World Wide Web, 1(4):377–396, 2004. [88] Tom Strelich. The software life cycle support environment (SLCSE): a computer based framework for developing software systems. Sigplan Notices, 24:35–44, 1989. [89] Daniel C. Swinehart, Polle T. Zellweger, and Robert B. Hagmann. The structure of Cedar. SIGPLAN Not., 20:230–244, June 1985. [90] Daniel Sykes. Autonomous Architectural Assembly And Adaptation. PhD thesis, Impe- rial College, London, 2010. [91] Daniel Sykes, William Heaven, Je Magee, and Je Kramer. From goals to com- ponents: a combined approach to self-management. In Proceedings of the 2008 international workshop on Software engineering for adaptive and self-managing systems, SEAMS ’08, pages 1–8, New York, NY, USA, 2008. ACM. [92] Daniel Sykes, William Heaven, Je Magee, and Je Kramer. Exploiting non- functional preferences in architectural adaptation for self-managed systems. In Proceedings of the 2010 ACM Symposium on Applied Computing, SAC ’10, pages 431– 438, New York, NY, USA, 2010. ACM. [93] R. N. Taylor, N. Medvidovic, and E. M. Dashofy. Software Architecture: Foundations, Theory, and Practice. Wiley Publishing, 2009. [94] W. Teitelman and L. Masinter. The Interlisp programming environment. Computer, 14:25–33, April 1981. [95] I. Thomas and B.A. Nejmeh. Definitions of tool integration for environments. Soft- ware, IEEE, 9:29 –35, Mar 1992. 246 [96] Wei-Tek Tsai, Yinong Chen, and Chun Fan. PESOI: Process embedded service- oriented architecture. Journal of Software, 17:1470–1484, 2006. [97] Micky Williams. An overview of microsoft whitehorse, 2004. 247 Appendix A 6A Internal Language Grammar The root of the language is theAdapt task. The variability points (i.e., where the user op- erations are utilized) are provided with all capital letters, and start with “USER” prefix. In each case, the input and outputs arguments are provided. 1 Adapt: 2 Delete_Removable_Comps 3 Pick_or_Instantiate_Required_Comps 4 Resolve_Dependencies_and_Compose 5 Delete_Excessive_Comp_insts 6 Delete_Excessive_Conn_Insts 7 ; 8 9 // This user operation adds a component instance to the architecture. 10 Add_Comp_Inst: 11 USER_ADD_COMP(COMP_INST) 12 ; 13 14 // This user operation adds a connector instance to the architecture. 15 Add_Conn_Inst: 16 USER_ADD_CONN(CONN_INST) 17 ; 18 19 // This user operation connects two component instances on their INTERFACE interface. 20 Connect_Comp_Comp: 21 USER_CONNECT(COMP_INST_1 COMP_INST_2 INTERFACE) 22 ; 23 248 24 // This user operation picks an existing connector instance and connects either COMP_INST_1 or COMP_INST_2 (or both) to that connector instance in order to connect these component instances. This is to connect component instances on their INTERFACE interface. 25 Connect_Comp_Conn: 26 USER_CONNECT_COMP_CONN(COMP_INST_1 COMP_INST_2 INTERFACE) 27 ; 28 29 // This user operation picks two existing connector instances and connects them in order to connect COMP_INST_1 and COMP_INST_2 component instances. This is to connect component instances on their INTERFACE interface. 30 Connect_Conn_Conn: 31 USER_CONNECT_CONN_CONN(COMP_INST_1 COMP_INST_2 INTERFACE) 32 ; 33 34 // This composite task deletes component instances that are marked to be removed from the architecture. 35 Delete_Removable_Comps: 36 (Unweld_Comp_Inst Unemploy_Comp_Inst)* 37 ; 38 39 // This composite task deletes unused component instances from the architecture. 40 Delete_Excessive_Comp_Insts: 41 (Unweld_Comp_Inst Unemploy_Comp_Inst)* 42 ; 43 44 // This composite task deletes unused connector instances from the architecture. 45 Delete_Excessive_Conn_Insts: 46 (Unweld_Conn_Inst Unemploy_Conn_Inst)* 47 ; 48 49 // This composite task disconnects a component instance from all connector instances it is connected to. 50 Disconnect_from_Connectors: 51 (Disconnect_Comp_Conn)* 52 ; 53 54 // This composite task disconnects a component instance from all component instances it is directly or indirectly connected to. 55 Disconnect_from_Components: 56 (Disconnect_Directly_Connected | Disconnect_Comp_Comp)* 57 ; 58 59 // This user operation disconnects two connector instances. These connector instances are connected on their INTERFACE interface. 60 Disconnect_Conn_Conn: 61 USER_DISCONNECT_CONN_CONN(CONN_INST_1 CONN_INST_2 INTERFACE) 62 ; 63 64 // This user operation disconnects two connector instances or disconnects one of the component instances from a connector instance in order to disconnect the component instances. These component instances are connected on their INTERFACE interface. 65 Disconnect_Comp_Comp: 249 66 USER_DISCONNECT_COMP_COMP(COMP_INST_1 COMP_INST_2 INTERFACE) 67 ; 68 69 // This user operation disconnects a component instance from a connector instance, which are connected on their INTERFACE interface. 70 Disconnect_Comp_Conn: 71 USER_DISCONNECT_COMP_CONN(COMP_INST CONN_INST INTERFACE) 72 ; 73 74 // This user operation disconnects two component instances connected directly on their INTERFACE interface. 75 Disconnect_Directly_Connected: 76 USER_DISCONNECT_COMP_COMP(COMP_INST_1 COMP_INST_2 INTERFACE) 77 ; 78 79 // This user operation finalizes a component instance before it is removed from the architecture. 80 Finalize_Comp_Inst: 81 USER_FINALIZE_COMP(COMP_INST) 82 ; 83 84 // This user operation finalizes a connector instance before it is removed from the architecture. 85 Finalize_Conn_Inst: 86 USER_FINALIZE_CONN(CONN_INST) 87 ; 88 89 // This user operation instantiates COMP_INST from the COMP component class. 90 Instantiate_a_Comp: 91 USER_INSTANTIATE_COMP(COMP) returns COMP_INST 92 ; 93 94 // This user operation instantiates a connector instance in order to connect two component instances on their INTERFACE interface. 95 Instantiate_a_Conn: 96 USER_INSTANTIATE_CONN(COMP_INST_1 COMP_INST_2 INTERFACE) returns CONN_INST 97 ; 98 99 // This composite task finds an instance of a component class that is required in the architecture. If no component instance is found, it instantiates the component class. Moreover, it adds the component instance to the architecture if it is not already added. 100 Pick_or_Instantiate_Required_Comps: 101 (Pick_Comp_Inst_or_Instantiate_for_Requirements Add_Comp_Inst?)* 102 ; 103 104 // This composite task searches for an appropriate instance of COMP component class and returns it as COMP_INST. If an appropriate component instance does not exist, instantiates a new component instance and returns it as COMP_INST. 105 Pick_Comp_Inst_or_Instantiate_for_Requirements: 106 (Pick_a_Comp_Inst_for_Requirements | Instantiate_a_Comp) 107 ; 108 250 109 // This composite task searches for an appropriate instance of COMP component class and returns it as COMP_INST. If an appropriate component instance does not exist, instantiates a new component instance and returns it as COMP_INST. 110 Pick_Comp_Inst_or_Instantiate_for_Dependency: 111 (Pick_a_Comp_Inst_for_Dependency | Instantiate_a_Comp) 112 ; 113 114 // This user operation searches for an existing instant of a component class required in the architecture. 115 Pick_a_Comp_Inst_for_Requirements: 116 USER_PICK_A_COMP_INST_FOR_REQUIREMENTS(COMP) return COMP_INST 117 ; 118 119 // This user operation searches for an instance of COMP component class to be used to resolve the dependency TO_RESOLVE_INTERFACE interface from the TO_RESOLVE_COMP. 120 Pick_a_Comp_Inst_for_Dependency: 121 USER_PICK_A_COMP_INST_FOR_DEPENDENCY(COMP TO_RESOLVE_COMP TO_RESOLVE_INTERFACE) returns COMP_INST 122 ; 123 124 // This operation searches for a component class that resolves the dependency of a component instance (TO_RESOLVE_COMP) that is an instance of a component class (IN_COMP_CLASS) for one of its interfaces (TO_RESOLVE_INTERFACE), and returns a component class (OUT_COMP_CLASS) 125 PICK_A_COMP: 126 USER_PICK_A_COMP(TO_RESOLVE_COMP IN_COMP_CLASS TO_RESOLVE_INTERFACE) returns OUT_COMP_CLASS 127 ; 128 129 // This user operation disconnects either COMP_INST_1 or COMP_INST_2 from a connector instance, if connection to that connector instance limits the connection of COMP_INST_1 and COMP_INST_2 on their INTERFACE interface. 130 Pre_Connect_Disconnect_Comp_Conn: 131 USER_PRE_CONNECTION_DISCONNECT_COMP_CONN(COMP_INST_1 COMP_INST_2 INTERFACE) 132 ; 133 134 // This user operation disconnects two connector instances, if connection of those connector instances limits the connection of COMP_INST_1 and COMP_INST_2 on their INTERFACE interface. 135 Pre_Connect_Disconnect_Conn_Conn: 136 USER_PRE_CONNECTION_DISCONNECT_CONN_CONN(COMP_INST_1 COMP_INST_2 INTERFACE) 137 ; 138 139 // This operation disconnects COMP_INST_1 or COMP_INST_2 from another component instance, if connection to that component instance limits the connection of COMP_INST_1 and COMP_INST_2 on their INTERFACE interface. 140 Pre_Connect_Disconnect_Comp_Comp: 141 USER_PRE_CONNECT_DISCONNECT(COMP_INST_1 COMP_INST_2 INTERFACE) 142 ; 143 251 144 // This composite task resolves dependencies of all component classes required in an architecture, by adding component classes to the list of required component classes and resolving their dependencies recursively. This task also welds dependent component instances. 145 Resolve_Dependencies_and_Compose: 146 (Resolve_Dependency_of_a_Comp_Interface Weld_Dependent_Comp_Insts)* 147 ; 148 149 // This composite task resolves the dependencies of one interface of a component class, by finding a matching interface of a different component class. Then it finds a component instance of the selected component class, or instantiates one if no component instance exists. Finally, the component instance is added to the architecture if it is not already in the architecture. 150 Resolve_Dependency_of_a_Comp_Interface: 151 (Pick_a_Comp Pick_Comp_Inst_or_Instantiate_for_Dependency Add_Comp_Inst?) 152 ; 153 154 // This user operation removes a component instance from the architecture. 155 Remove_Comp_Inst: 156 USER_REMOVE_COMP(COMP_INST) 157 ; 158 159 // This user operation removes a connector instance from the architecture. 160 Remove_Conn_Inst: 161 USER_REMOVE_CONN(CONN_INST) 162 ; 163 164 // This task disconnects a component from all other component instances and connector instances. 165 Unweld_Comp_Inst: 166 Disconnect_from_Components Disconnect_from_Connectors 167 ; 168 169 // This task disconnects a connector instance from all other connector instances in the architecture. 170 Unweld_Conn_Inst: 171 Disconnect_Conn_Conn* 172 ; 173 174 // This composite task removes a connector instance that is not connected to any other artifact in the architecture. 175 Unemploy_Conn_Inst: 176 Finalize_Conn_Inst Remove_Conn_Inst 177 ; 178 179 // This composite task removes a component instance that is not connected to any other artifact in the architecture. 180 Unemploy_Comp_Inst: 181 Finalize_Comp_Inst Remove_Comp_Inst 182 ; 183 184 // This composite task welds dependent component instances, either directly, or using connector instances. 252 185 Weld_Dependent_Comp_Insts: 186 Weld_Comp_Insts_Directly | Weld_Comp_Insts_Using_Conns 187 ; 188 189 // This composite task connects two component instances using connector instances. 190 Weld_Comp_Insts_Using_Conns: 191 ((Instantiate_a_Conn Add_Conn_Inst) | Pre_Connect_Disconnect_Comp_Conn | Pre_Connect_Disconnect_Conn_Conn | 192 Connect_Comp_Conn | Connect_Conn_Conn)* 193 ; 194 195 // This composit task directly connects two component instances. 196 Weld_Comp_Insts_Directly: 197 Pre_Connect_Disconnect_Comp_Comp* Connect_Comp_Comp 198 ; 253 Appendix B SADEL Syntax Summary This section contains the complete BNF specification of SADEL. For simplicity, all literals, including single-character literals (e.g.,g or ;) are displayed in bold type. Single-character literals are displayed without quotation marks. Unless bolded, curly braces (f andg) represent repetition of the enclosed expression.f...g* represents zero or more occurrences, whilef...g+ denotes one or more occurrences. Note that values for 6a_language_task_ identifier and6a_language_type_identifier match against task and type identifiers in 6A internal language grammar (see Appendix A). arch_component_set ::= (arch_component_type)* arch_component_type ::= component identifier is arch_component_type_decl arch_component_type_decl ::= component_type_decl | virtual_comp_type arch_component_types ::= component_types { arch_component_set } arch_connector_type ::= connector identifier is { message_filter filtering_policy ; } 254 arch_connector_types ::= connector_types { (arch_connector_type)* } arch_topology ::= architectural_topology { component_inst connector_inst attachments } attachments ::= connections { (connection_decl)* } axiom_decl ::= axiom identifier : { [let_pre_decl] (pre_decl_alone)+ } basic_subtype_type ::= identifier is basic_subtype identifier ; basic_subtype_decl ::= basic_types { (basic_subtype_type)* } behavior_decl ::= operations { (operation_decl|axiom_decl|cost_function_decl)* } binary_operator ::= = | <> | + | - | * | / | ^ | \implies | \equivalent | \and | \or | \xor | \union | \intersection | \in | \not_in \greater | \less | \eqgreater | \eqless classType_decl ::= identifier[. identifier]* component_inst ::= component_instances { (instance_decl)* } component_type ::= component identifier is component_type_decl component_type_decl ::= extern_comp_type | local_comp_type connection_decl ::= [ component | connector ] identifier { top [ connection_list ] ; bottom [ connection_list ] ; } connection_list ::= identifier , connection_list | identifier 255 connector_inst ::= connector_instances { (instance_decl)* } cost_decl ::= logic_expr ; cost_function_decl ::= costFun identifier : { let_decl | pre_decl | post_decl | cost_decl } digit ::= 0 | 1 | ... | 9 dir_indicator ::= prov | req extern_comp_type ::= extern { filename ; } filtering_policy ::= no_filtering | notification_filtering | message_filtering | prioritized | message_sink function_decl ::= identifier : identifier -> identifier ; universal_expr ::= forall(identifier)(logic_expr) existential_expr ::= exists(identifier)(logic_expr) general_architecture ::= architecture identifier is { [basic_subtype_decl] arch_component_types arch_connector_types arch_topology } general_component_set ::= [basic_subtype_decl] (component_type)+ identifier ::= letter{ _ | letter | digit}* instance_decl ::= identifier : identifier ; integer ::= (digit)+ 256 interface_decl ::= interface { (interface_element_decl)* } interface_element_decl ::= dir_indicator identifier : identifier ( param_decl ) [: [\set] identifier] ; invariant_decl ::= invariant { [logic_expr ;] } let_decl ::= let_decl_alone [pre_decl | post_decl] let_decl_alone ::= let {var_decl ; }* letter ::= A | B | ... | Z | a | b | ... | z local_comp_type ::= [subtype_decl] { state_decl invariant_decl interface_decl behavior_decl map_decl [map6a_decl] } logic_expr ::= subexpr [ (\and|\xor) subexpr] map_decl ::= map { (single_map)* } map6a_decl ::= map6a { (single_map6a)* } metaData_decl ::= metaData { classType : classType_decl ; version : version_decl ; quality_decl } numeric_literal ::= [-] integer [. integer] [^ integer] operand ::= [\not | #] identifier | numeric_literal | subexpr | universal_expr | existential_expr | ( subexpr ) 257 operation_decl ::= dir_indicator identifier : { let_decl | pre_decl | post_decl | cost_decl } param_decl ::= var_decl ; param_decl | var_decl param_to_var ::= identifier -> identifier , param_to_var | identifier -> identifier param6a_to_var ::= identifier -> 6a_language_type_identifier , param6a_to_var | identifier -> 6a_language_type_identifier post_decl ::= post [post_logic_expr] ; [cost_decl] post_logic_expr ::= post_subexpr [(\and|\xor) post_subexpr] post_operand ::= [\not | #] [~] identifier | numeric_literal | post_subexpr | ( post_subexpr ) post_subexpr ::= post_operand binary_operator post_operand | \result = post_operand pre_decl ::= pre_decl_alone [post_decl] pre_decl_alone ::= [sortBy identifier (asc|des) ;] pre [logic_expr] ; quality_decl ::= identifier : ((0[. integer ]) | 1 ) SADEL_spec ::= general_architecture | general_component_set single_map ::= identifier -> identifier ( param_to_var ) ; single_map6a ::= identifier -> 6a_language_task_identifier ( param6a_to_var ) ; state_decl ::= state { (var_decl ; | function_decl ;)* } subexpr ::= operand binary_operator operand subtype_decl ::= 258 subtype identifier ( subtype_rel_expr ) subtype_rel ::= nam | int | beh | imp subtype_rel_expr ::= [\not] subtype_rel{ \and [\not] subtype_rel}* var_decl ::= identifier : [\set] identifier version_decl ::= integer [. integer]* virtual_comp_type ::= virtual { } 259

Abstract (if available)

Abstract Modern software systems are increasingly expected to satisfy high reliability and high availability requirements. During their life‐span, they need to constantly and seamlessly adapt and evolve in response to new requirements and changing circumstances. Software adaptation and evolution in modern software systems could not degrade software availability. Consequently, self‐adaptive software systems are desirable. ❧ Adaptation tools in several recent self‐adaptive software systems are implemented as development environment tools. This resulted in the tight integration of the development and run-time environments in these systems. Although integration of the development and run‐time environments has several benefits, tight integration of these environments causes several structural and quality shortcomings (e.g., availability and resource consumption) in self‐adaptive software environment. Therefore, new software environments with loosely integrated development and run‐time environments are desirable. In addition, as a software system evolves during its life‐span, adaptation activities that pertain to it also evolve. Consequently, a self‐adaptive software system should also evolve its adaptive behavior autonomously. New tools and approaches are demanded to support self‐adaptation of the adaptation tools in self‐adaptive software systems. Additionally, there is a disconnect between the modeling and the adaptation artifacts in the existing self‐adaptive software systems, which limits the self‐adaptability of those systems. New modeling techniques are required to link models and adaptation artifacts in self‐adaptive software systems. ❧ This dissertation provides a reference architecture for integrated self‐adaptive software environments that addresses several structural and quality shortcomings of the existing integrated software environments. Additionally, this dissertation provides a model‐driven software self‐adaptation technique to support adaptation of both run‐time application and adaptation tools in self‐adaptive software systems. This technique leverages architectural models in order to synthesize behavioral models of the run‐time application and the adaptation tools, at run‐time. The resulting synthesized behavioral models are used to guide the adaptation behavior of the system. Both the reference architecture and the adaptation technique provided in this dissertation are based on a new adaptive, layered, architectural style introduced in this dissertation. The resulting self‐adaptive software environment provided in this dissertation delivers higher flexibility, separation of concerns, fault‐tolerance, adaptability, and robustness compared to the existing self‐adaptive software systems.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Architectural evolution and decay in software systems

PDF

Analysis of embedded software architecture with precedent dependent aperiodic tasks

PDF

A user-centric approach for improving a distributed software system's deployment architecture

PDF

Techniques for methodically exploring software development alternatives

PDF

Software architecture recovery using text classification -- recover and RELAX

PDF

A unified framework for studying architectural decay of software systems

PDF

Proactive detection of higher-order software design conflicts

PDF

A model for estimating schedule acceleration in agile software development projects

PDF

Automated synthesis of domain-specific model interpreters

PDF

The incremental commitment spiral model process patterns for rapid-fielding projects

PDF

Design-time software quality modeling and analysis of distributed software-intensive systems

PDF

Architecture and application of an autonomous robotic software engineering technology testbed (SETT)

PDF

Domain-based effort distribution model for software cost estimation

PDF

Calculating architectural reliability via modeling and analysis

PDF

Using metrics of scattering to assess software quality

PDF

A model for estimating cross-project multitasking overhead in software development projects

PDF

Constraint-based program analysis for concurrent software

PDF

The effects of required security on software development effort

PDF

Software quality understanding by analysis of abundant data (SQUAAD): towards better understanding of life cycle software qualities

PDF

A search-based approach for technical debt prioritization

Asset Metadata

Creator Tajalli, Hossein (author)

Core Title A reference architecture for integrated self‐adaptive software environments

School Viterbi School of Engineering

Degree Doctor of Philosophy

Degree Program Computer Science (Software Engineering)

Publication Date 06/23/2014

Defense Date 05/15/2013

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag adaptation planning,integrated development environments,life‐cycle,OAI-PMH Harvest,run‐time environment,self‐adaptation,Software Architecture

Format application/pdf (imt)

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor Medvidović, Nenad (committee chair), Boehm, Barry W. (committee member), Halfond, William G. J. (committee member), Pedram, Massoud (committee member), Tambe, Milind (committee member)

Creator Email farshaad@gmail.com,tajalli@usc.edu

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c3-426323

Unique identifier UC11286661

Identifier etd-TajalliHos-2582.pdf (filename),usctheses-c3-426323 (legacy record id)

Legacy Identifier etd-TajalliHos-2582.pdf

Dmrecord 426323

Document Type Dissertation

Format application/pdf (imt)

Rights Tajalli, Hossein

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA