Software Adaptation in an Open Environment

A Software Architecture Perspective

Yu Zhou, Taolue Chen

• Éditeur: Auerbach Publications
• Année: 2017
• ISBN:
  9781351723039
• Édition: 1
• Sujet: Informatik
• Sous-sujet: Informationstechnologie

The book is about a very active research field in software engineering. In modern society, the fact of the world's high reliance on software requires the system's robustness, i.e., continual availability and satisfactory service quality. This requirement gives rise to the popularity of the research on the self-adaptive software in open environment. There are some academic conferences dedicated to this field. But there is a lack of monographs about the topic. We believe such need is unmet in marketplace. By publishing the book, it can help bridge the gap and bring benefits to readers thereof.

Key Features:

• The topic is well-motivated, interesting and actively studied worldwide
  
  

• The research represents as the state-of-the-art in the field
  
  

• The technical part of the book is rigidly evaluated
  
  

• The theoretical part of the book is sound and proved
  
  

• The organization and presentation of the book will be double-checked by professional scholars
  
  

III FORMAL MODELING AND ANALYSIS

Chapter 7

Adaptation Rules Conflict Detection

CONTENTS

7.1 Introduction

7.2 Reconfiguration Modeling and Analysis

7.2.1 Critical pair and dependency

7.2.2 Architectural reconfiguration analysis

7.3 Case Study

7.4 Discussion

7.5 Related Work

7.6 Summary

7.1 Introduction

Architecture-based runtime adaptation has been proposed as an effective way to ensure the continuous availability of component-based software systems in an uncertain environment [136, 137]. Generally, such systems have embedded sensors to probe the context information and can propagate the changes to the rule management modules and direct the corresponding dynamic architectural reconfigurations accordingly.

In decentralized and distributed settings, interesting context changes might be reported from place to place, thus, it is highly possible that multiple architectural reconfiguration rules are applicable at the same time. These rules usually address different aspects of concerns, either functional or non-functional, and are not necessarily independent of each other. So, applying one rule may disable another one. Therefore, in this case, how to detect the potential conflicts between the reconfigurations becomes an important issue for efficient adaptation management.

To formalize the problem, given a set of reconfigurations: S_r = {r₁,r₂,...,r_n}, we need to find the tuple sets:

{(r_i,r_j) | r_i,r_j ∈ S_r ^ (DEP(r_i,r_j) = TRUE ∨ CONFLICTS(r_i,r_j) = TRUE)}.

For example, in a component-based software system, the trust management module reports a fraud behavior of a third-party component and the adaptation rule indicates its removal from the system. Meanwhile, a performance monitor reports a low-performance event of another component and the adaptation rule implies an addition of a new back-up component. If the new component relies on the functions of the third-party component stated above, a conflict would happen between these two reconfigurations. Manually assigning each rule with an application-specific priority as commonly adopted leads to an ad-hoc solution which only partly addresses the problem, as the developer may still be unaware of the potential conflicts or the dependency relations between the involved reconfiguration possibilities. Besides, this mechanism lacks formal treatment of such problems.

Graph notations have been widely applied to software architecture modeling [18, 28, 115] due to their unique characteristics. Firstly, graph representation has the advantage of an intuitive visual correspondence to the common practice of box-line notation of software architecture; secondly, the widely recognized importance of the connector as a first-class entity can be well captured by the notion of edge attributes; thirdly, by production, the graph rewriting techniques can be employed to describe the evolution and to check some interesting properties, such as confluence, conflicts, etc. formally.

In this chapter, we will focus on the third point listed above and inspect the applicability of in the domain of dynamic software architectural reconfigurations. We leverage the theories from the critical pair analysis, inspect the relations between the reconfiguration rules such as dependence and confluence, and present a formal approach to analyze the potential conflicts of multiple reconfigurations. The rest of the chapter is organized as follows. Section 7.2 introduces some basic notions relevant to the formalism of conflict analysis and then outlines our approach. To illustrate its application and feasibility, a case study is presented with tool support in Section 7.3, followed by some discussions on the lessons learned and the limitations of our approach in Section 7.4. Section 7.5 reviews some related work. Section 7.6 summarizes this chapter.

7.2 Reconfiguration Modeling and Analysis

For architecture-based self-adaptation rules, basically, they have a spectrum of two layers as in [110], i.e., goal management layer and change management layer. The first handles the context changes which are usually reflected in the condition part of the rule. It is on the application level. The second deals with the reconfiguration actions which are on the architecture level. For example, a load-balancing rule specifies that when the workload of a component reaches a certain threshold, a backup component will be added dynamically to the system. As the condition part depends on the concrete requirements, it varies across applications. In contrast to this, the architectural reconfigurations are manipulated at the level of constituent components and connectors, which can be specified as the graph transformation rule [184]. With such considerations, we will focus on the architecture level rule modeling. It fits in the change actions management layer in [110]. To detect reconfiguration dependency and conflicts of dynamic software architecture, their independent relations need to be modeled and analyzed. In this section, we will first introduce some basic concepts, and then present our approach.

7.2.1 Critical pair and dependency

Critical pair analysis originated from term rewriting and later was generalized to graph transformation to check whether the transformation system is confluent [143]. Given a graph G, a production p : L ⇒ R and a match m : L ⇒ G, the transformation from G to H is specified as t:G⇒p,mH. A critical pair is a pair of transformations (p₁, p₂) in which t1:G⇒p1,m1H1andt2:G⇒p2,m2H2 have potential conflicts with the minimal G = m₁(L₁) ∪ [m₂(L₂) to ensure that the critical pair sets for two rules are finite. Intuitively, for two rules both ap...