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: Sr = {r1,r2,...,rn}, we need to find the tuple sets:
{(ri,rj) | ri,rj ∈ Sr ^ (DEP(ri,rj) = TRUE ∨ CONFLICTS(ri,rj) = 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 . A critical pair is a pair of transformations (p1, p2) in which have potential conflicts with the minimal G = m1(L1) ∪ [m2(L2) to ensure that the critical pair sets for two rules are finite. Intuitively, for two rules both ap...