On the Computational Complexity of Designing and Reconﬁguring Component-based Software Systems

Though Component-Based Development (CBD) is a popular approach to mitigating the costs of creating software systems, it is not clear to what extent CBD is preferable to other approaches to software engineering or to what extent the core component selection and adaptation activities of CBD can be implemented to operate without human intervention in an eﬃcient and reliable manner. In this paper, we use computational complexity analysis to compare the computational characteristics of software system design and reconﬁguration by de novo design, component selection, and component selection with adaptation. Our results show that none of these approaches can be implemented to operate both eﬃciently and reliably either in general or relative to a surprisingly large number of restrictions on software system, component, and component library structure. We also give the ﬁrst restrictions under which all of these approaches can be implemented to operate both eﬃciently and reliably.


INTRODUCTION
Component-based development (CBD) is a popular approach to mitigating the monetary and time costs of creating and maintaining software systems [1,3,12].In CBD, previouslydeveloped software modules called components are stored in libraries and connected together (possibly with some adaptation of the component code and architecture) as needed to generate new software systems from given requirements.Over the last 20 years, a number of technologies have been implemented to assist human programmers in creating component-based systems, e.g., CORBA, CCM, EJB, COM+, and much effort has been put into automating the key CBD activities of component selection and adaptation.
There are two ongoing issues of great importance in the CBD community: (1) the circumstances (if any) under which the cost of selecting and adapting components is less than the cost of developing software systems from scratch, i.e., de novo [10] and (2) the need for CBD to operate fully automatically and efficiently to accommodate ubiquitous and autonomic computing systems which need to create and reconfigure software without or with minimal human intervention at runtime [7,13].To address these issues, it would be most useful to know if efficient and reliable methods are available for selecting and adapting components in CBD and, if so, under what circumstances these methods outperform other approaches to software engineering.
In this paper, we present results addressing both of these questions.First, using computational complexity analysis [8], we show that both creating and reconfiguring software systems either by de novo design, component selection, or component selection with adaptation are all N P -hard and thus intractable in general.Second, using parameterized complexity analysis [5], we give restrictions under which all of these activities are tractable and prove that surprisingly few restrictions on either software system structure or the allowable degree of adaptation render these activities tractable.Though these results are derived relative to basic models of software systems and components, we show that they also apply to more realistic models.
The remainder of this paper is organized as follows.In Section 2, we present our software system, component, and component library models and formalize the problems of de novo and component-based software system design and reconfiguration relative to these models.Section 3 demonstrates the intractability of all of these problems in general.Section 4 describes a methodology for identifying conditions for tractability, which is then applied in Section 5 to identify such conditions for our problems.In order to accommodate conference page limits and focus in the main text on the implications of our results for CBD, proofs of selected results are given in Appendix A. Finally, our conclusions and directions for future work are given in Section 6.

Related Work
Computational complexity analyses of the component selection problem have been done previously [2,16,17].However, the formalizations used in these analyses focused on the satisfaction of sets of desired system objectives, and did not include specifications of software system and component structure that are detailed enough to investigate the conditions under which restrictions on these structures would make component selection tractable.They also did not address the issue of component adaptation.

FORMALIZING COMPONENT-BASED DESIGN AND RECONFIGURATION
Our goal in this paper is to assess whether or not componentbased development has advantages over conventional software engineering relative to different activities in the software life cycle.This assessment can be stated most simply along two dimensions: 1. Software design mode: creating software using only components drawn from component libraries versus creating software by adapting components drawn from component libraries or creating software de novo that is organized in a specified component-like fashion.
2. Software lifecycle activity: designing the initial version of a software system relative to a set of requirements versus reconfiguring an existing system to accommodate one or more changes to the requirements.
The possibilities implicit in these dimensions result in the following six informal computational problems:

Software Design
Input: Software requirements R, software-structure specification X Output: A software system S whose structure is consistent with X and whose operation satisfies R.

Software Design from Adapted Components
Input: Software requirements R, a set of software-component libraries C = {C1, C2, . . ., C |C| }.Output: A software system S whose structure consists of connected components derived from components drawn from the libraries in C and whose operation satisfies R.
Output: A software system S whose structure consists of connected components drawn from the libraries in C and whose operation satisfies R.

Software Reconfiguration
Input: A software system S whose structure is consistent with specification X and whose operation satisfies requirements R, new software requirements Rnew.Output: A software system S ′ derived from S whose structure is consistent with X and whose operation satisfies R ∪ Rnew.

Software Reconfiguration from Adapted Components
Input: A software system S whose structure consists of connected components from a set of software-component libraries C = {C1, C2, . . ., C |C| } and whose operation satisfies requirements R, new software requirements Rnew.
Output: A software system S ′ derived from S whose structure consists of connected components derived from components drawn from the libraries in C and whose operation satisfies R ∪ Rnew.

Software Reconfiguration from Components
Input: A software system S whose structure consists of connected components from a set of software-component libraries C = {C1, C2, . . ., C |C| } and whose operation satisfies requirements R, new software requirements Rnew.
Output: A software system S ′ derived from S whose structure consists of connected components drawn from the libraries in C and whose operation satisfies R ∪ Rnew.
To assess the computational difficulty of and (if necessary) explore algorithmic options for efficiently solving these problems, we need formalizations of all of the entities comprising these problems.There is a vast existing literature on various types of software requirements, system-structures, structure specifications, and components and component libraries.We want to avoid introducing spurious computational difficulty due to powerful formalisms, as this would complicate the interpretation our results.Hence, we shall choose the simplest such formalizations1 (additional advantages gained by such a parsimonious approach are given in Section 5.2): • Software Requirements: The requirements will be a set R = {r1, r2, .procedure with one or more situation-variable conditions terminates in a final ELSE statement.In addition, the selector may consist of single special statement IF * THEN which evaluates to T rue in all cases (the default selector) and a procedure may consist of a single executed action; such selectors and procedures have no associated conditions.
• Software components and component libraries: Twolevel software systems of the form above consist of two types of components, selectors and procedures, which shall be stored in libraries L sel and Lprc, respectively.
• Software structure specification: The basic characteristics of two-level software systems of the form above are the situation-variable and action sets on which they are based (I and A), the maximum number of conditions allowed in the selector (|sel|) and the maximum number of conditions allowed in any procedure (|prc|).
Examples of these entities are given in Figure 1.
This allows us to formalize various actions and properties in the problems given above as follows: • A software system S is consistent with a structurespecification X = I, A, |sel|, |prc| if it has the twolevel structure described above where IF-THEN conditions are (un)negated members of I, all procedureexecuted actions are drawn from A, the number of conditions in the selector is at most |sel| , and the number of conditions in each procedure is at most |prc|.For example, both software-systems in Figure 1(d) are consistent with X = {{i1, i2, i3, i4, i5}, {a1, a2, a3}, 2, 3}.
• A software system S is constructed from components drawn from C = {C sel , Cprc} if the selector-component is from C sel and each procedure-component is from Cprc.Note that a member of Cprc may appear zero, one, or more times in S. For example, both software systems in Figure 1(d) are constructed from C = {{s1, s2}, {p1, p2, p3, p4}}.
• The operation of a software system S satisfies requirements R if for each situation-action pair (s, a) in R, the execution of S relative to the truth-settings in s results in the execution of a.For example, software system S1 in Figure 1(d) satisfies the requirements in Figure 1(a) but software system S2 does not (because it produces different outputs (a3, a1, a1, and a2 respectively) for requirements r1, r3, r4, and r5).
We can now state the following formal problems: Software Design (SDes-Spec)

COMPONENT-BASED DESIGN AND RE-CONFIGURATION ARE INTRACTABLE
Following general practice in Computer Science [8], we define tractability as being solvable in the worst case in time polynomially bounded in the input size.We show that a problem is not polynomial-time solvable, i.e., not in the class P of polynomial-time solvable problems, by proving it to be at least as difficult as the hardest problems in problem-class N P (see [8] for details).
Modulo the conjecture P = N P which is widely believed to be true [6], the above shows that even the basic versions of component-based design and reconfiguration considered here are not solvable in polynomial time.This N P -hardness hold for problems SRec-Spec and SRec-CompA when the new requirements consist of a single situation-action pair.
Two frequently-adopted responses to intractability are to consider poly-time algorithms which generate solutions that (1) approximate within provable bounds the wanted solutions, e.g., software systems whose structure are close to the values specified in X or which satisfy a large proportion of the requirements in R [14], or (2) are of acceptable quality most of the time, e.g., genetic or simulated annealing algorithms [11].In the remainder of this paper, we will consider a third option described in more detail in the next section.

A METHOD FOR IDENTIFYING TRACTABILITY CONDITIONS
A computational problem that is intractable for unrestricted inputs may yet be tractable for non-trivial restrictions on the input.This insight is based on the observation that some N P -hard problems can be solved by algorithms whose running time is polynomial in the overall input size and nonpolynomial only in some aspects of the input called parameters.The following states this idea more formally.
Definition 1.Let Π be a problem with parameters k1, k2, . ... Then Π is said to be fixed-parameter (fp-) tractable for parameter-set K = {k1, k2, ...} if there exists at least one algorithm that solves Π for any input of size n in time f (k1, k2, ...)n c , where f (•) is an arbitrary function and c is a constant.If no such algorithm exists then Π is said to be fixed-parameter (fp-) intractable for parameter-set K.
In other words, a problem Π is fp-tractable for a parameterset K if all superpolynomial-time complexity inherent in solving Π can be confined to the parameters in K.
There are many techniques for designing fp-tractable algorithms [4,5], and fp-intractability is established in a manner analogous to classical polynomial-time intractability by proving a parameterized problem is at least as difficult as the hardest problems in one of the problem-classes in the Whierarchy {W [1], W [2], ...} (see [5] for details).Additional results are typically implied by any given result courtesy of the following lemmas: It follows from the definition of fp-tractability that if an intractable problem Π is fp-tractable for parameter-set K, then Π can be efficiently solved even for large inputs, provided only that the values of all parameters in K are relatively small.This strategy has been successfully applied to many intractable problems (see [5,18] and references).In the next section we show how this strategy may be used to render component-based design and reconfiguration tractable.

WHAT MAKES COMPONENT-BASED DESIGN AND RECONFIGURATION TRACTABLE?
Our component-based software design and reconfiguration problems have a number of parameters whose restriction could render these problems tractable in the sense defined in Section 4.An overview of the parameters that we considered in our fp-tractability analysis is given in Table 1.These parameters can be divided into three groups: We will assess the fixed-parameter tractability of our problems relative to the parameters in Table 1 (Section 5.1), show how these results apply in more general settings (Section 5.2), and discuss the implications of these results for component-based development (Section 5.3).
Note that Results B, C, E, F, and H in combination with Lemmas 1 and 2 completely characterize the parameterized complexity of problems SDes-Spec, SDes-CompA, SRec-Spec, and SRec-CompA relative to the parameters in Table 1.

Generality of Results
Our intractability results, though defined relative to basic models of software requirements, software systems, components, and component libraries, have a broad applicability.Observe that the models for which these results hold are in fact restricted versions of more realistic alternatives, e.g., • software requirements that explicitly list all situations to which software should respond are a special case of more complex requirements which are based on compact specifications of software behaviour such as finitestate automata or statecharts and/or incorporate other required properties of software systems such as degree of reliability and response time; • two-level selector / procedure software systems that act as simple functions are a special case of more complex persistent software systems whose components invoke each other in more complex manners; • components consisting of a single condition-statement block procedure without input parameters or return values and which have no dependencies on other components are a special case of more complex components consisting of multiple data types and complex procedures which have dependencies on other components such as data-type sharing or inheritance; and • component libraries that are simply lists of components are a special case of component libraries that incorporate component behaviour-specifications and / or metadata to aid in selection and adaptation.
Intractability results for these alternatives then follow from the observation that intractability results for a problem Π also hold for any problem Π ′ that has Π as a special case (suppose Π is intractable; if Π ′ is tractable by algorithm A, then A can be used to solve Π efficiently, which contradicts the intractability of Π -hence, Π ′ must also be intractable).
Our fp-tractability results are much more fragile, as innocuous changes to software requirements, software system, component, or component library structure may in fact violate assumptions critical to the operation of the algorithms underlying these results.Hence, they may only apply to certain more complex models, and this needs to be assessed on a case-by-case basis.

Discussion
We have found that designing and reconfiguring software systems by de novo design, component selection, and component selection with adaptation are all N P -hard (Result A).This implies that it is unlikely that deterministic polynomialtime methods exist for any of these problems.It also answers the question of which of de novo design, component selection, or component selection with adaptation is best for creating software systems -computationally speaking, all three methods are equally good (or bad) in general.
This N P -hardness has interesting additional implications.It is widely believed that P = BP P [21, Section 5.2] where BP P is considered the most inclusive class of problems that can be efficiently solved using probabilistic methods (in particular, methods whose probability of correctness can be efficiently boosted to be arbitrarily close to probability one).Hence, our results also imply that unless P = N P , there are no probabilistic polynomial-time methods which correctly design or reconfigure software systems using the three approaches considered here with high probability for all inputs.
Taken together, the above constitutes the first proof that no currently-used method (including search-based methods based on evolutionary algorithms (see [11,Section 5] and references) can guarantee both efficient and correct operation for all inputs for these problems.
As described in Section 4, efficient correctness-guaranteed methods may yet exist relative to plausible restrictions on the input and output.It seems reasonable to conjecture that some restrictions relative to the parameters listed in Table 1 should render these problems tractable.However, almost none of these restrictions or indeed many possible combinations of these restrictions can yield tractability, even when the parameters involved are restricted to very small constants (Results B-G).We do have some initial fp-tractability results (Results H and I).Taken together, our fp-results paint a disconcerting picture for problems SDes-Spec, SDes-CompA, SRec-Spec, and SRec-CompA, as they suggest that making both the software systems and the degree of allowable adaptation small under the approaches encoded in these problems does not yield tractability.However, the situation for problems SDes-Comp and SRec-Comp may not be so dire.To date, we have not been able to prove fpintractability relative to a number of the individual parameters and parameter-combinations considered here for these problems.Hence, if fp-tractability holds in at least some of those cases, this would constitute proof that component selection without adaptation is tractable in a wider set of circumstances than either de novo design or component selection with adaptation.
Two valid objections to our fp-tractability results are that (1) the algorithms underlying these results are crude and rely on brute-force search and (2) the running times of these algorithms are (to be blunt, ludicrously) impractical.These objections are often true of the initial fp-algorithms derived relative to a parameter-set.However, once fp-tractability is proven, surprisingly effective fp-algorithms are often subsequently developed with greatly diminished non-polynomial terms and polynomial terms that are quadratic or even linear in the input size (see [4,5] and references).
A final very important proviso is in order -namely, as illuminating as the results given here are in demonstrating basic forms of (in)tractability for software design and reconfiguration problems relative to the three approaches considered, these results do not necessarily imply that methods currently being applied to design or reconfigure software are impractical.Differing software and component models, the particular situations in which these currently-used methods are being applied, and accepted standards by which method practicality is assessed may render the results given here irrelevant.For example, current methods may already be implicitly exploiting restrictions on the input and output such that both efficient and correct operation (or operation that is correct with probability very close to one) are guaranteed.That being said, not knowing the precise conditions under which such practicality holds could have serious consequences, e.g., drastically slowed software creation time and/or unreliable software operation, if these conditions are violated.These consequences would be particularly damaging in the case of runtime-based applications like ubiquitous and autonomic computing.Given that reliable software operation is very important and efficient software design and reconfiguration is at the very least desirable, the acquisition of such knowledge via a combination of rigorous empirical and theoretical analyses should be a priority.With respect to theoretical analyses, it is our hope that the techniques and results in this paper comprise a useful first step.

CONCLUSIONS
We have presented a formal characterization of the problems of software system design and reconfiguration by de novo design, component selection, and component selection with adaptation.Our complexity analyses reveal that, while these problems are computationally intractable in general, there are restrictions that render them tractable.Though the immediate practical utility of our tractability results is questionable given the basic models of software requirements, software systems and components relative to which they were derived, our intractability results give the first rigorous computational comparison between the three approaches to software design considered here.In particular, our results as a whole establish that all three approaches are equally computationally difficult in general but suggest that software creation by component selection may be tractable under more circumstances than the other two approaches.
There are several possible directions for future research.The first is to complete the analysis begun here to see if software creation by component selection really is fp-tractable for software systems that are small and/or created with small amounts of adaptation.The second is to extend this analysis to the more realistic models of software requirements, software systems, components, and component libraries sketched in Section 5.2.Last but certainly not least, derived tractability results should be implemented and tested in designing and reconfiguring actual software systems.Such testing will give invaluable guidance in phrasing future theoretical analyses along the lines sketched here; in turn, such analyses will hopefully help to guide future research in component-based software development.
If there is a dominating set of size at most k in the given instance of Dominating set, construct a software system consisting of a default *-condition selector and a single procedure in which the k IF-THEN statements have situationvariable conditions corresponding to the vertices in the dominating set (adding arbitrary other vertex situation-variables if the size of the dominating set is less than k) and action 1 and the final ELSE statement has action 0. Observe that this software system satisfies all situation-action pairs in R and has |sel| = 0 and |prc| = k.
Conversely, suppose that the constructed instance of SDes-Spec has a software system satisfying R with |sel| = 0 and |prc| ≤ k.The selector in this system must be the default selector as it is the only selector with |sel| = 0.As for the single procedure attached to that selector, it has two possible structures:  ).However, this implies that all situation-action pairs in R ′′ have value T rue for c, which in turn implies that the vertices corresponding to the situation-variables in C ∪{c} form a dominating set in G of size at most k.
Hence, the existence of a satisfying software system for the constructed instance of SDes-Spec implies the existence of a dominating set of size at most k for the given instance of Dominating Set.
To complete the proof, note that in the constructed instance of SDes-Spec, |A| = 2, |sel| = 1, and |prc| = k.If there is a dominating set of size at most k in the given instance of Dominating Set, construct a software system consisting of the single selector in L sel and the at most k procedures from Lprc corresponding to the vertices in the dominating set.For each of the |V |−1 IF-THEN statements in the selector, call the procedure encoding the neighbourhood of the vertex in the dominating set which dominates the vertex corresponding to the situation-variable in that statement's condition.For the ELSE statement in the selector, execute the procedure encoding the neighbourhood of the vertex in the dominating set that dominates vertex v |V | .Observe that this software system satisfies all situation-action pairs in R and has d = k + 1.
Conversely, suppose that the constructed instance SDes-Comp has a software system constructed from at most d = k + 1 distinct components from L sel and Lprc that satisfies all of the situation-action pairs in R. As the selector is constructed such that each of the first |V | situation-action pairs in R has its own associated procedure and each procedure accepts the vertices in a specific vertex-neighbourhood in G, in order for these situation-action pairs to be satisfied, the distinct procedures in the software system must correspond to a dominating set for G (note that both r |V | and r |V |+1 are satisfied by the procedure associated with the ELSE statement in the selector).As d = k + 1 and the system had to incorporate a selector from L sel , this means that there are at most k such procedures and hence a dominating set of size at most k in the given instance of Dominating Set.Proof.Follows from the W [2]-hardness of {k}-Dominating Set [5] and the reductions from Dominating Set to SDes-Spec given in Lemma 3.

Lemma 4 .
Dominating Set polynomial-time many-one reduces to SDes-Comp such that in the constructed instance of SDes-CompA, |A| = 2, |L sel | = 1, and d is a function of k in the given instance of Dominating Set.Proof.Given an instance G = (V, E), k of Dominating set, the constructed instance I, A, R, L sel , Lprc, d of SDes-Comp has I = {i1, i2, . . .i 2|V | } and A = {0, 1}.There are |V | + 1 situation-action pairs in R such that (1) for ri = (si, ai), 1 ≤ i ≤ |V |, v(ii) = T rue, v(i |V |+j ) = T rue if vj ∈ NC (vi), all other v(ij) are F alse, and ai = 1, and (2) for r |V |+1 = (s |V |+1 , a |V |+1 ), all v(ij) = F alse and a |V |+1 = 0.There is a single selector in L sel whose |V | − 1 IF-THEN statement conditions are the first |V | − 1 situationvariables in I.There are |V | procedures in Lprc such that procedure i, 1 ≤ i ≤ |V |, has an IF-THEN statement for each of the vertices in NC (vi) whose condition is the situationvariable associated with that vertex and which executes action 1 and an ELSE statement that executes action 0. Finally, let d = k+1.Note that the instance of SDes-Comp described above can be constructed in time polynomial in the size of the given instance of Dominating set.
Output: A software system S ′ derived by at most cc changes to S whose structure is consistent with X and whose operation satisfies R ∪ Rnew, if such an S ′ exists, and special symbol ⊥ otherwise.{C sel , Cprc} and whose operation satisfies requirements R, a set Rnew of new situation-action pairs based on I and A, positive integers c l , cc, d ≥ 0. Output: A software system S ′ derived from S by at most c l component-changes relative to the libraries in C and cc codechanges whose structure consist of at most d types of connected components and whose operation satisfies R ∪ Rnew, if such an S ′ exists, and special symbol ⊥ otherwise.
|sel|, |prc| , software requirements R based on sets I and A. Output: A software system S whose structure is consistent with X and whose operation satisfies R, if such an S exists, and special symbol ⊥ otherwise.SoftwareDesign from Adapted Components (SDes-CompA) Input: Software requirements R based on sets I and A, a set of software-component libraries C = {C sel , Cprc}, positive integers d, cc ≥ 0. Output: A software system S whose structure consist of connected components derived by at most cc changes to at most d components drawn from the libraries in C and whose operation satisfies R, if such an S exists, and special symbol ⊥ otherwise.Software Design from Components (SDes-Comp) Input: Software requirements R based on sets I and A, a set of software-component libraries C = {C sel , Cprc}, a positive integer d ≥ 0. Output: A software system S whose structure consist of connected components based on at most d components drawn from the libraries in C and whose operation satisfies R, if such an S exists, and special symbol ⊥ otherwise.Software Reconfiguration (SRec-Spec) Input: A software system S whose structure is consistent with specification X = I, A, |sel|, |prc| and whose operation satisfies requirements R, a set Rnew of new situationaction pairs based on I and A, a positive integer cc ≥ 0. sel , Cprc} and whose operation satisfies requirements R, a set Rnew of new situation-action pairs based on I and A, positive integers c l , d ≥ 0. Output: A software system S ′ derived from S by at most c l component-changes relative to the libraries in C whose structure consists of at most d types of connected components and whose operation satisfies R ∪ Rnew, if such an S ′ exists, and special symbol ⊥ otherwise.We have included parameter d in all component-based problems to allow control over the number of retrievals from libraries.The two types of adaptation and reconfiguration changes are: (1) changes to the system code: changing the condition in or action executed by any IF-THEN-ELSE statement (cc) and (2) changes to the system component-set: using a different selector-component from C sel or changing any used procedure-component to another from Cprc (c l ).Note in the case of a selector-change, both the original and new selector must have the same number of IF-THEN statements and the procedures called by the original selector are mapped to the corresponding positions in the new selector.

Table 1 :
Parameters for Component-based Design and Reconfiguration Problems

1 .
No negated situation-variable conditions: As r |V |+1 has no situation-variables set to T rue, it can only be processed correctly by the final ELSE-statement, which must thus execute action 0. In order to accept all other situation-pairs in R, the k conditions must then have situation-variables whose corresponding vertices form a dominating set in G of size at most k. 2. Negated situation-variables are present: Let c be the first negated situation-variable condition encountered moving down the code in the procedure, C be the set of unnegated situation-variable conditions encountered before c, and R ′ ⊆ R be the set of situation-action pairs not recognized by the situation-variables in C. As |prc| ≤ k, |C| ≤ k − 1.Moreover, as situation-action pair r |V |+1 has no situation-variable with value T rue and hence cannot be recognized by an IF-THEN statement with an unnegated situation-variable condition, r |V |+1