A Game of Attribute Decomposition for Software Architecture Design

08/12/2015 ∙ by Jiamou Liu, et al. ∙ Auckland University of Technology 0

Attribute-driven software architecture design aims to provide decision support by taking into account the quality attributes of softwares. A central question in this process is: What architecture design best fulfills the desirable software requirements? To answer this question, a system designer needs to make tradeoffs among several potentially conflicting quality attributes. Such decisions are normally ad-hoc and rely heavily on experiences. We propose a mathematical approach to tackle this problem. Game theory naturally provides the basic language: Players represent requirements, and strategies involve setting up coalitions among the players. In this way we propose a novel model, called decomposition game, for attribute-driven design. We present its solution concept based on the notion of cohesion and expansion-freedom and prove that a solution always exists. We then investigate the computational complexity of obtaining a solution. The game model and the algorithms may serve as a general framework for providing useful guidance for software architecture design. We present our results through running examples and a case study on a real-life software project.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Computational game theory studies the algorithmic nature of conflicting entities and establishes equilibria: A state of balance that minimises the negative effects among players. The field has attracted much attention in the recent 10-15 years due to applications in multi-agent systems, electronic markets and social networks [9, 10, 11]. In this paper, we investigate the problem of software architecture design from a game theory perspective. In particular, we provide a novel model, called decomposition game, which captures interactions among software requirements and derives a software architecture through equilibria.

The architecture of a software system lays out its basic composition. For softwares become larger, quality attributes such as performance, reliability, usability and security, play an increasingly important role. It has been a common belief that architecture design heavily influences the quality attributes such as performance, reliability, usability and security of a software system [2]. A major objective of architecture design is therefore the assurance of non-functional requirements through compositional decisions. In other words, we need to answer the following question: What architecture best fulfills the desirable software requirements?

There is, however, usually no “perfect” architecture that fulfills every requirement. For example, performance and security are both key non-functional requirements, which may demand fast response time to the users, and the application of a sophisticated encryption algorithm, respectively. These two requirements are in intrinsic conflict, as a strong focus of one will negatively impact the fulfilment of the other. A main task of the software architect, therefore, is to balance such “interactions” among requirements, and decide on appropriate tradeoffs among such conflicting requirements.

While it is a common practice to decide on software architecture designs through the designers’ experiences and intuition, formal approaches for architecture design are desirable as they facilitate standardisation and automation of this process, providing rigorous guidelines, allowing automatic analysis and verifications [6]. Notable formal methods in software architecture include a large number of formal architecture description languages (ADL), which are useful tools in communicating and modeling architectures. However, as argued by [14]

, industry adoptions of ADL are rare due to limitations in usability and formality. Other algorithmic methods for software architecture design include employing hierarchical clustering algorithms to decompose components based on their common attributes

[8], as well as quantifying tradeoffs between requirements [1].

In this paper, we propose to use computational game theory as a mathematical foundation for conceptualising software architecture designs from requirements. Our motivation comes from the following two lines of research:

(1). Attribute driven design (ADD)

: ADD is a systematic method for software architecture design. The method was invented by Bass, Klein and Bachmann in [4] and subsequently updated and improved through a sequence of works [3, 13]. The goal is to assist designers to analyse quality attribute tradeoffs and provide design suggestions and guidance. Inputs to ADD are functional and non-functional requirements, as well as design constraints; outputs to ADD are conceptual architectures which outline coarse-grained system compositions. The method involves a sequence of well-defined steps that recursively decompose a system to components, subcomponents, and so on. These steps are not algorithmic: They are meant to be followed by system designers based on their experience and understanding of design principles. As mentioned by the authors in [4], an ongoing effort is to investigate rigorous approaches in producing conceptual architectures from requirements, hence enabling automated design recommendation under the ADD framework. To this end, we initiate a game-theoretic study to formulate the interactions among software requirements so that a conceptual architecture can be obtained in an algorithmic way.

(2). Coalition game theory

: A coalition game is one where players exercise collaborative strategies, and competition takes place among coalitions of players rather than individuals. In ADD, we can imagine each requirement is “handled” by a player, whose goal is to set up a coalition with others to maximise the collective payoff. The set of coalitions then defines components in a system decomposition which entails a software architecture. This fits into the language of coalition games. However, the usual axioms in coalition games specify super-additivity and monotonicity, that is, the combination of two coalitions is always more beneficial than each separate coalition, and the payoff increases as a coalition grows in size. Such assumptions are not suitable in this context as combination of two conflicting requirements may result in a lower payoff. Hence a new game model is necessary to reflect the conflicting nature of requirements. In this respect, we propose that our model also enriches the theory of coalition games.

Our contribution.

We provide a formal framework which, following the ADD paradigm [4], recursively decomposes a system into sub-systems; the final decomposition reveals design elements in a software architecture. The basis of the framework is an algorithmic realisation of ADD. A crucial task in this algorithmic realisation is system decomposition, which derives a rational decomposition of an attribute primitive.

We model system decomposition using a game, which we call decomposition game. The game takes into account interactions between requirements, which express the positive (enhancement) or negative (canceling) effects they act on each other. A solution concept (equilibrium) defines a rational decomposition, which is based on the notions of cohesion and expansion-freedom.

We demonstrate that any such game has a solution, and a solution may not be unique. We also investigate algorithms that compute solutions for the decomposition game. Finding cohesive coalitions with maximal payoff turns out to be NP-hard (Thm. 4.1). Hence we propose a relaxed notion of -cohesion for , and present a polynomial time algorithm for finding a -cohesive solution of the game (Thm. 4.2). To demonstrate the practical significance our the framework, we implement the framework and perform a case study on a real-world Cafeteria Ordering System.

Paper organisation.

Section 2 introduces the formal ADD framework. Section 3 discusses decomposition game and its solution concept. Section 4 presents algorithms for solving decomposition games. Section 5 presents the case study. Section 6 discusses related works and finally Section 7 concludes with future works.

2 Algorithmic Attribute Driven Design (ADD) Process

ADD is a general framework for transforming software requirements into a conceptual software architecture. Pioneers of this approach introduced it through several well-formed, but informally-defined concepts and steps [4, 13]. A natural question arises whether it can be made more algorithmic, which provides unbiased, mathematically-grounded outputs. To answer this question, one would first need to translate the original informal descriptions to a mathematical language.

2.1 Software Requirements and Constraints

Functional requirements.

Functional requirements are specifications of what tasks the system perform (e.g. “the system must notify the user once a new email arrives”).A functional requirement does not stand alone; often, it acts with other functional requirements to express certain combined functionality (e.g. “the user should log in before making a booking”). Thus, a functionality may depend on other functionalities. We use a partial ordering to denote the functional requirements where each is a functional requirement, and denotes that depends on . Note that is a transitive relation.

Non-functional requirements.

Non-functional requirements specify the desired quality attributes; ADD uses general scenarios and scenarios as their standard representations. A general scenario is a high-level description on what it means to achieve a non-functional requirement [4]. For example, the general scenario “A failure occurs and the system notifies the user; the system continues to perform in a degraded manner” refers to the availability attribute. There has been an effort to document all common general scenarios; a rather full list is given in [3]. Note that a general scenario is vaguely-phrased and is meant to serve as a template for more concrete “instantiations” of quality attributes. Such “instantiations” are called scenarios. More abstractly, we use a pair to denote the non-functional requirements where is a set of scenarios and is an equivalence relation on , denoting the general scenario relation: means that and instantiates the same general scenario.

Design constraints.

Design constraints are factors that must be taken into account and enforce certain design outcomes. A design constraint may affect both functional and non-functional requirements. More abstractly, we use a collection of sets to denote the set of design constraints, where each set is a design constraint. Intuitively, if two requirements belong to the same , then they are constrained by the same design constraint .

Derived Functionalities.

The enforcement of certain quality attributes may lead to additional functionalities. For example, to ensure availability, it may be necessary to add extra functionalities to detect failure and automatically bypass failed modules. Hence we introduce a derivation relation such that means the functional requirement is derived from the scenario .

2.2 Attribute Primitives

Figure 1: Example 1: The requirements, constraints and their relations.

The intentional outcome of ADD describes the design elements, i.e., subsystems, components or connectors. It is important to note that the goal of ADD is not the complete automation of the design process, but rather, to provide useful guidance. Thus, the conceptual view reveals only the organisational structure but not the concrete design.

An attribute primitive is a set of design elements that collaboratively perform certain functionalities and meet one or more quality requirements; it is also the minimal combination with respect to these goals [4]. Examples of attribute primitives include data router, firewall, virtual machine, interpreter and so on. ADD prescribes a list of attribute primitives together with descriptions of their properties and side effects (such as in [3]). Hence, ADD essentially can be viewed as assigning the right attribute primitives to the right requirement combinations. Note also that an attribute primitive may be broken down further.

Definition 1 (Attribute primitive)

An attribute primitive is a tuple

where is a set of functional requirements, is a set of scenarios, is a set of design constraints, is the dependency relation on , is the general scenario relation of , and is a derivation relation.

Let be an attribute primitive. We also need the following definition:

  • A requirement of is an element in the set .

  • For , the dependency set of is the set .

  • For , the general scenario of is the set , i.e., the -equivalence class of .

  • For , the constraints of is the set .

  • For , the derived set of is , and for , let

Definition 2 (Design element)

A design element of is a subset . An decomposition of is a sequence of design elements where , , and each for any .

Example 1

Fig. 1 shows an attribute primitive

  • and are the requirements

  • where

  • , , , ,, , .

2.3 The ADD Procedure

Essentially ADD provides a means for system decomposition: The entire system is treated as an attribute primitive, which is the input. At each step, the procedure decomposes an attribute primitive by identifying a decomposition . The process then maps each resulting design element to an attribute primitive , which contains all elements in and may require some further requirements and constraints. Hence we require that and , , , are consistent with , , and on , resp.; in this case we say that is consistent with . Thus the attribute primitive is decomposed into attribute primitives . On each where , the designer may choose to either terminate the process, or start a new step recursively to further decompose . See Procedure 1.

1: // compute a rational decomposition of
2:for  do
3:      an primitive attribute consistent with
4:     if  needs further decomposition then
5:               
Procedure 1 (General Plan)

We point out that the ADD procedure, as presented by its original proponents, involves numerous additional stages other than the ones described above [13]. The reason we choose this over-simplified description is that we believe these are the steps that could be rigorously presented, and they abstractly capture in a way most of the steps mentioned in the original informal description.

The operation produces a rational decomposition of the input attribute primitive that satisfies the requirements of . We also note that amounts to a crucial step in the ADD process, as the decomposition determines to a large extend how well the quality attributes are met. This step is also a challenging one as interactions among quality attributes create potential conflicts. Thus, in the next section, we define a game model which allows us to automate the operation.

3 Decomposition Games

3.1 Requirement Relevance

The procedure looks for a rational decomposition that meets the requirements in as much as possible. Let be an attribute primitive. Relevance between requirements are determined by the relations and the constraint set . In the following the Jaccard index measures the similarity between two sets with

Intuitively, the relevance of a requirement to other requirements is influenced by the “links” between and the functional, the non-functional requirements, as well as design constraints.

Definition 3 (Relevance)

Two requirements are relevant if

  • , and either (derived from some common scenario), or (relevant through dependency), or (share some common design constraints).

  • , and either (instantiate the same general scenario), or (jointly derives some functionality) or .

  • , , and either ( depends on a requirement that is derived from ), or .

If two requirements are relevant, their relevance depends on overlaps between their derived sets, dependency sets and constraints. If two requirements are not relevant, then we regard them as having a negative relevance , which represents a “penalty” one pays when two irrelevant requirements get in the same design element.

Definition 4

We define the relevance index of as follows:

  1. if two functional requirements are relevant, then

  2. if two scenarios are relevant, then

  3. If and are relevant, then

  4. otherwise,

The constants are positive real numbers, that represent weights on the overlaps in ’s generated sets, dependency sets and constraints, respectively. We require .

For simplicity, we do not include these constants in expressing the function , and all subsequent notions that depend on (thus saving us from writing “”).

Example 2

Continue from in Example 1. To emphasise the non-functional requirements we give a larger weight to , setting , , . We also set . Then for any ; ; ; and relevance between any other pairs is . Fig. 2(a) illustrates the (positive) relevance in a weighted graph.

3.2 Decomposition Games

We employ notions from coalition games to define what constitutes a rational decomposition. In a coalition game, players cooperate to form coalitions which achieve certain collective payoffs [5].

Definition 5 (Coalition game)

A coalition game is a pair where is a finite set of players, and each subset is a coalition; is a payoff function associating every a real value satisfying .

This provides the set up for decompositions:  Imagine a coalition game consisting of agents as players, where each agent is in charge of a different requirement. The players form coalitions which correspond to sets of requirements, i.e., design elements. The payoff function would associate with every coalition a numerical value, which is the payoff gained by each member of the coalition. Therefore, an equilibrium of the game amounts to a decomposition with the right balance among all requirements – this would be regarded as a rational decomposition.

It remains to define the payoff function. Naturally, the payoff of a coalition is determined by the interactions among its members. Take . If one of is a functional requirement, then their interaction is defined by their relevance index , as higher relevance means a higher level of interaction. Suppose now both are scenarios (non-functional). Then the interaction becomes more complicated, as a quality attribute may enhance or defect another quality attribute. In [12, Chapter 14], the authors identified effects acting from one quality attribute to another, which is expressed by a tradeoff matrix :

  • has dimension where is the number of general scenarios

  • For , the -entry .

Let be general scenarios. (resp. ) means has a positive (resp. negative) effect on , means no effect. E.g., the tradeoff matrix defined on six common quality attributes is:

Note that the matrix is not necessarily symmetric: The effect from to may be different from the effect from to . For example, an improvement in system performance may not affect security, but increasing security will almost always adversely impact performance. we assume that the matrix is given prior to ADD; this assumption is reasonable as there is an effective map from any general scenario to the main quality attribute it tries to capture. We use this tradeoff matrix to define the interaction between two scenarios in .

Definition 6 (Coalitional relevance)

For a coalition and , the coalitional relevance of in is the total relevance from to all other requirements in , i.e.,

Definition 7 (Effect factor)

For scenarios in the same coalition , the effect factor from to expresses the effect of towards , i.e.,

We are now ready to define the interaction between two scenarios .

Definition 8 (Interaction)

Let be requirements. The interaction between is simply the relevance if one of is functional; otherwise (both are non-functional), it is the sum of their effect factors, i.e.,

The coalition utility of any coalition is defined as the sum of interactions among all pairs of requirements in the coalition, i.e.,

Definition 9 (Decomposition games (DG))

Let be an attribute primitive. The DG is the coalition game where is the coalition utility function.

Figure 2: (a) Weights on the edges are relevance (function ) between requirements in Example 2; the diagram omits the negative weighted pairs.  (b) The decomposition is a solution with , . The coalition has
Example 3 (Coalition Utility)

Continue the setting in Example 2. Let the general scenarios be and . We assume matrix specifies and . Consider the coalition . We have:

So and .

Thus . Therefore, but ; See Fig. 2(b).

As it has turned out, despite the fact that matrix indicates will act positively to , and that have a positive (0.05) relevance, adding into the coalition of drastically decreases the coalition utility.

3.3 Solution Concept

We point out some major differences between decomposition and typical coalition games: Firstly, in coalition game theory, one normally assumes the axioms of superadditivity () and monotonicity () which would obviously not hold for decomposition as players may counteract with each other, reducing their combined utility. Secondly, the typical solution concepts in coalition games (such as Pareto optimality, and Shapely value) focus on distribution of payoffs to each individual player assuming a grand coalition consisting of all players. In decomposition such a grand coalition is normally not desirable and the focus is on the overall payoff of each coalition , rather than the individual requirements. The above differences motivate us to consider a different solution concept of DG . At any instance of the game, the players form a decomposition . We assume that the players may perform two collaborative strategies:

  1. Merge strategy: Two coalitions may choose to merge if they would obtain a higher combined payoff.

  2. Bind strategy: Players within the same coalition may form a sub-coalition if they would obtain a higher payoff.

Example 4 (A Dilemma)

We present an example demonstrating the dynamics of a DG . This example shows a real-world dilemma: As a coalition pursues higher utility through expansion (merging with others), it may be better to choose a “less-aggressive” expansion strategy over the “more-aggressive” counterpart, even though the latter clearly brings a higher payoff. Assume the following situation (which is clearly plausible in an attribute primitive):

  • where and .

  • We set , and .

  • The tradeoff matrix indicates , .

  • And, and are irrelevant, namely .

Suppose we start with the decomposition . Then . Coalition has two merge strategies:

  • For : , , . Thus .

  • For : , , . Hence

Merging with clearly results in a higher payoff for the combined coalition. However, if this merge happens, as , and would choose to bind together, hence leaving . This would be undesirable if is a critical non-functional requirement for .

Example 4 shows that a solution concept would be a decomposition where no “expansion” nor “crumbling” occur to any coalition. Formally, we define the following solution concepts:

Definition 10 (Solution)

Let be a decomposition of .

  1. A coalition is cohesive if for all , ; is cohesive if so is every .

  2. A coalition is expansion-free with respect to if ; is expansion-free if so is every .

A solution of a DG is a decomposition that is both cohesive and expansion-free.

Example 5 (Solution)

Continue from Example 3, the utilities for

  • : , ,
    , . Thus

  • : . Thus

Both and are cohesive. Furthermore, we have and . Thus . Consequently, is also expansion-free, and is thus a solution of the game.

A solution of a DG corresponds to a rational decomposition of the attribute primitive . As shown by Thm. 3.1, any attribute primitive admits a solution, and rather expectedly, a solution may not be unique.

Theorem 3.1 (Solution Existence)

There exists a solution in any DG .

Proof

We show existence of a solution by construction. Let be a longest sequence such that for any , is a minimal coalition with maximal utility in (i.e., and ).

We claim that is a solution in . Indeed, for any , any proper subset of would have payoff strictly smaller than by minimality of . Thus is cohesive. Moreover, if for some , then does not have maximal utility in . Hence is expansion-free. ∎

Proposition 1

The solution of a DG may not be unique.

Proof

Let be an attribute primitive where and . We may define in such a way that

  • For all and ,

  • For all , ,

Consider . Note that and ; is cohesive and is expansion-free as . Note also that and ; is cohesive and is expansion-free as

4 Solving Decomposition Games

Based on our game model, the operation in Procedure 1 is reduced to the following problem:

INPUT: An attribute primitive

OUTPUT: A solution of the game

Here, we measure computational complexity with respect to the number of requirements in . The proof of Theorem 3.1 already implies an algorithm for solving the problem: check all subsets of to identify a minimal set with maximal utility; remove it from and repeat. However, it is clear that this algorithm takes exponential time. We will demonstrate below that a polynomial-time algorithm for this problem is, unfortunately, unlikely to exist.

We consider the decision problem : Given and a number , is there a solution of in which the highest utility of a coalition reaches ? Recall that the payoff function of is defined assuming constants and . The theorem below holds assuming .

Theorem 4.1

The problem is NP-hard.

Proof

The proof is via a reduction from the maximal clique problem, which is a well-known NP-hard problem. Given an undirected graph , we construct an attribute primitive such that any cohesive coalition in reveals a clique in . Suppose . The requirements of consist of scenarios: . In particular, all requirements are non-functional. We define an edge relation on such that

  1. iff for some and

  2. If then for any .

  3. Any is attached to at most one edge in .

Note that such a relation exists as any node is only connected with at most other nodes in . Intuitively, a set of requirements serves as a “meta-node” and corresponds to the node in . In constructing , we may define the general scenarios in such a way that

  • for any and .

  • for any .

  • for any

  • for any but

For every and , put in a constraint . Thus the relevance between and is

Furthermore if , then for any we set . Suppose induces a complete subgraph of . We define the meta-clique coalition of as

By the above definition, for any , take such that .

Thus . Taking out any element from results in a strict decrease in utility, and hence is cohesive.

Now take any coalition that contains two requirements , such that . Let and . Note also that for any . Therefore we have

The last inequality above is by assumption that . Thus is not cohesive.

By the above argument, a coalition is cohesive in iff is the meta-clique coalition for some clique in . Furthermore, a decomposition is a solution in iff can be partitioned into sets where each is a clique, and for all . In particular, has a clique with nodes if and only if has a solution that contains a coalition whose utility reaches . This finishes the reduction.∎

Theorem 4.1 shows that, in a sense, identifying a “best” solutions in a DG is hard. The main difficulty comes from the fact that one would examine all subsets of players to find an optimal cohesive coalition. This calls for a relaxed notion of a solution that is computationally feasible. To this end we introduce the notion of -cohesive coalitions. Fix and enforce this rule: Binding can only take place on or less players. That is, a coalition is -cohesive whenever is greater than the utility of any subsets with at most players.

Definition 11

Fix . In a DG , we say a coalition is -cohesive if for all with . An decomposition is -cohesive if every coalition in is -cohesive; if is also expansion-free, then it is a -cohesive solution of the game .

Remark.

In a sense, the value in the above definition indicates a level of expected cohesion in the decomposition process. A higher value of implies less restricted binding within any coalition, which results in higher “sensitivity” of design elements to conflicts. In a software tool which performs ADD based on DG, the level may be used as an additional parameter.

1:Attribute primitive ,
2:Attribute Decomposition
3:
4:
5:while  do
6:     
7:     for ,  do
8:         if  and  then
9:               and remove from
10:                             
11:return
Procedure 2
1:Attribute primitive ,
2:Attribute Decomposition
3:,
4:while  do
5:      // compute a maximally -cohesive coalition
6:     
7: