Exploring Viable Algorithmic Options for Automatically Creating and Reconfiguring Component-based Software Systems: A Computational Complexity Approach (Full Version)

Component-Based Development (CBD) is a popular approach to mitigating the costs of creating software systems. However, it is not clear to what extent the core component selection and adaptation activities of CBD can be implemented to operate automatically in an efficient and reliable manner or in what situations (if any) CBD is preferable to other approaches to software development. In this paper, we use computational complexity analysis to determine and compare the computational characteristics of fully automatic component-based software system creation and reconfiguration 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 efficiently and reliably in a fully automatic manner either in general or relative to a number of restrictions on software systems, system requirements, components, and component adaptation. We also give restrictions under which all of these approaches can be implemented to operate both efficiently and reliably. As such, this paper illustrates how different types of computational complexity analysis (in particular, parameterized complexity analysis) can be used to systematically explore the algorithmic options for implementing automatic activities in software engineering.

READ FULL TEXT VIEW PDF

page 1

page 2

page 3

page 4

05/12/2022

Viable Algorithmic Options for Creating and Adapting Emergent Software Systems

Given the complexity of modern software systems, it is of great importan...
05/10/2022

Exploring Viable Algorithmic Options for Learning from Demonstration (LfD): A Parameterized Complexity Approach

The key to reconciling the polynomial-time intractability of many machin...
04/08/2019

Software Engineering in Civic Tech: A Case Study about Code for Ireland

Civic grassroots have proven their ability to create useful and scalable...
08/12/2021

Operationalizing Human Values in Software Engineering: A Survey

Human values, such as inclusion and diversity, are defined as what an in...
02/01/2018

Digitalization of Swedish Government Agencies - A Perspective Through the Lens of a Software Development Census

Software engineering is at the core of the digitalization of society. Il...
03/14/2021

The entrepreneurial logic of startup software development: A study of 40 software startups

Context: Software startups are an essential source of innovation and sof...
06/03/2019

Software Adaptation and Generalization of Physically-Constrained Games

In this paper we provide a case study of the use of relatively sophistic...

1 Introduction

Since its proposal by McIlroy in 1968 [1], Component-Based Development (CBD) has been a popular approach to mitigating the monetary and time costs of creating and maintaining software systems [2, 3, 4, 5, 6]. In CBD, previously-developed software modules called components are connected together (possibly with some adaptation of the component code and architecture) to generate new software systems from given requirements. In this process, components, software systems, and the manners in which components can be used to create these system are specified using standardized models of components, component-based architectures, and component composition. 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 [3, 7, 6].

There are two ongoing issues of great importance in the CBD community: (1) the desire to (in the case of ubiquitous and autonomic computing systems [8, 9], fully) automate core CBD activities such as component selection and adaptation [2, 7] and (2) the circumstances (if any) in which the cost of developing software systems by selecting and adapting components is less than that of designing systems from scratch, i.e., de novo [10, 11]. The second issue is of particular importance because “[e]conomic considerations, and cost/benefit analyses in general, must be at the center of any discussion of software reuse” [11, page 557]. In addition to these general issues, there are also computational conjectures about specific CBD activities based on empirical observations that need to verified, e.g., whether increases in the computational effort required to adapt components is due to increases in the size of the code being modified and/or the number of code modifications increases [11, Page 537].

To address all of these issues and questions, it would be most useful to know the range of possible methods for implementing efficient and reliable automated CBD as well as the circumstances (if any) in which these methods outperform other approaches to software development. This is best done using computational complexity analysis [12, 13]. Such analyses determine whether or not there is an efficient algorithm for a given problem, i.e., whether that problem is tractable or intractable. So-called classical complexity analysis [12] establishes whether a problem can be solved efficiently in general, i.e., for all inputs. If this is not the case, parameterized complexity analysis [13] establishes relative to which sets of input and output restrictions the problem can and cannot be solved efficiently. Parameterized analyses thus allow the systematic exploration of viable algorithmic options for solving an intractable problem [14], cf. the piecemeal situation-by-situation manner in which algorithms for a problem are typically derived. In order to have the greatest possible applicability, both of these types of analyses are typically performed relative to simplified versions of problems that are special cases of the actual problems of interest. This is because, as an efficient algorithm for the general case can also efficiently solve special cases of that general case, intractability results for special cases also imply intractability for all more general cases (see Section 5 for details).

In this paper, we address the issues above by completing and extending initial work reported (without almost all proofs of results) in [15] (subsequently reprinted as [16]). We first use computational complexity analysis to show that neither creating nor reconfiguring software systems either by de novo design, component selection, or component selection with adaptation are tractable in general by either deterministic or probabilistic algorithms. We then use parameterized complexity analysis to give restrictions under which all of these activities are tractable and prove that surprisingly few restrictions on either the structure of software systems, system requirements, and components or the allowable degree of adaptation render these activities tractable. Taken together, these sets of results give the first objective comparison of the effort involved in both creating and reconfiguring software systems by de novo design, component selection, and component selection with adaptation. Our intent is to derive results that have the greatest possible applicability to component-based software system development. Hence, by the logic in the previous paragraph, our results are derived relative to simple models of software systems, system requirements, components, and adaptation (namely, purely reactive two-level systems that satisfy specified functional requirements and whose whitebox procedure-components are adapted by changes to their code) which are special cases of a broad range of more realistic models.

1.1 Previous Work

A number of problems in software engineering are known to be undecidable, i.e., do not have any algorithm that works correctly for all inputs. This is a consequence of Rice’s Theorem [17, Section 9.3.3].111 We thank an anonymous reviewer of an earlier version of this paper for pointing this out. One such result is that there is no algorithm which, given a software system and a set of requirements, can correctly decide whether or not that system satisfies those requirements. That being said, it is also known that Rice’s Theorem only applies to the most general statements of such problems [17, Section 9.3.4], and that special cases of these problems (such as those examined in this paper) may still have correct and even efficient algorithms.

Computational complexity analyses have been done previously for component selection [18, 19] and component selection with adaptation [20], with [20, 19] having the additional requirement that that number of components in the resulting software system be minimized. Given the intractability of all of these problems, subsequent work has focused on efficient approximation algorithms for component selection. Though it has been shown that efficient algorithms that produce software systems whose number of components is within a constant multiplicative factor of optimal are not possible in general [21], efficient approximation algorithms are known for a number of special cases [22, 23, 21].

All of these analyses use atomic blackbox formalizations of system requirements, components, and (in the case of [20]) component adaptation. While this is consistent with component selection as typically employed in both academia and industry [24, 25, 26], none of these formalizations include specifications of the internal structure of software systems, system requirements, and components (and hence component adaptation as well) that are detailed enough to allow investigation of restrictions on these aspects that could make component selection or component selection with adaptation tractable. Moreover, all work to date has focused on component selection and adaptation in the context of system creation and has not considered subsequent modification to a system over that system’s lifetime.

Various metrics measuring the relative costs and hence benefits of developing software systems by de novo design, component selection, and component selection with adaption have been proposed (see [11, Section 3]

and references). Problems associated with subjectively estimating certain cost-variables within these metrics, e.g., adapting components and developing reusable components, led Mili et al in 1995 to conclude that “…we will guesstimate …[the] relative effectiveness [of various software engineering methods] but we will not,

and cannot, go any further [11, page 540] (emphasis added). The situation has not improved significantly in the last 20 years, as both Frakes and Kang in 2005 [2, Section 4] and Vale et al in 2016 [6, Page 143] concluded that the lack of metrics related to CBD was still a notable gap in CBD research. This has been mitigated by the several hundred studies and experiments done over the last several decades to validate proposed CBD methods and evaluate their effectiveness in various situations [6, Section 3.5]. However, to our knowledge, there has been no objective mathematically-based assessment to date of the relative computational effort required to create let alone reconfigure software systems by de novo design, component selection, and component selection with adaptation.

1.2 Organization of Paper

Our paper is organized as follows. In Section 2, we present our models of software system requirements, component-based architectures, components, component composition, and component adaptation and formalize the problems of de novo and component-based software system creation and reconfiguration relative to these models. Section 3 demonstrates the intractability of all of these problems in general and Section 4 establishes several basic sets of restrictions under which our problems are and are not tractable. In order to focus in the main text on the implications of our results for CBD, proofs of all results are given in an appendix. The generality and implications of our results are discussed in Sections 5 and 6, respectively. Finally, our conclusions and directions for future work are given in Section 7.

2 Formalizing Component-based Software System
      Creation and Reconfiguration

2.1 Issues addressed in our formalizations

One of our goals in this paper is to assess whether or not component-based development has advantages over other types of software development 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 selected components versus creating software by adapting selected components versus creating software de novo that is organized in a specified component-like fashion.

  2. Software lifecycle activity: Creating 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.222 Note that these creation and reconfiguration activities are invoked in implementing the self-configuration and self-healing properties of autonomic systems [9] as well as the automatic synthesis of appropriate applications for selected tasks in ubiquitous computing [8].

The possibilities implicit in these dimensions result in the following six informal computational problems:

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

Software Creation from Components
Input: Software requirements , a set of software-component libraries .
Output: A software system whose structure consists of components drawn from the libraries in and whose operation satisfies .

Software Creation from Adapted Components
Input: Software requirements , a set of software-component libraries .
Output: A software system whose structure consists of components derived from components drawn from the libraries in and whose operation satisfies .

Software Reconfiguration
Input: A software system whose structure is consistent with specification and whose operation satisfies requirements , new software requirements .
Output: A software system derived from whose structure is consistent with and whose operation satisfies .

Software Reconfiguration from Components
Input: A software system whose structure consists of components from a set of software-component libraries and whose operation satisfies requirements , new software requirements .
Output: A software system derived from whose structure consists of components drawn from the libraries in and whose operation satisfies .

Software Reconfiguration from Adapted Components
Input: A software system whose structure consists of components from a set of software-component libraries and whose operation satisfies requirements , new software requirements .
Output: A software system derived from whose structure consists of components derived from components drawn from the libraries in and whose operation satisfies .

We want to be able to assess the effects of as many characteristics of the software system specifications, requirements, and structure as possible on the computational difficulty of the creation and reconfiguration processes. This requires that explicit and detailed representations of these entities be included in our problems. This is very different from the more abstract atomic blackbox perspective adopted by previous computational complexity analyses of CBD when defining their problems (see Section 1.1). However, as we will see later in this paper, this will allow our complexity analyses (in particular, our parameterized complexity analyses) to build on and extend the results derived in those previous complexity analyses.

2.2 Formalizations of problem entities

To assess the general computational difficulty of and (if necessary) explore algorithmic options under restrictions for efficiently solving the problems sketched in Section 2.1, we need formalizations of all of the entities comprising these problems. There is a vast existing literature on various models of software system requirements, component-based architectures, components, component composition, component libraries, and component adaptation [3, 4, 7]. We want to avoid introducing spurious computational difficulty due to powerful formalisms, as this would complicate the interpretation of our results; we also want our results to have the greatest possible applicability in the sense described in Sections 1 and 5. Hence, we shall choose the following basic formalizations:333 These formalizations are based on those developed in [27] and [28] (see also [29]) to analyze the computational complexity of the adaptive toolbox theory of human decision-making [30].

  • Software system requirements: The requirements will be a set of situation-action pairs where each pair consists of a situation defined by a particular set of truth-values , , relative to each of the Boolean variables in set and an action from set . As such, these are functional requirements describing wanted system behaviors.

  • Component-based architecture model: We will here consider a two-level software system architecture consisting of a top-level multiple IF-THEN-ELSE statement block (a selector) whose branches are in turn lower-level IF-THEN-ELSE statement blocks (procedures) whose branches execute actions from . Each selector and procedure IF-THEN condition is a Boolean formula that is either a variable from e.g., , or its negation, e.g., . Each selector and 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 in all cases (the default selector) and a procedure may consist of a single executed action; such selectors and procedures have no associated conditions.

  • Component, component composition, and component library models: Two-level software systems of the form above consist of two types of components, selectors and procedures. The code for each component is available, i.e., they are whitebox components, and the behavior of a component is specified by its code. Components are composed into software systems using only simple procedure calls that do not either have input parameters or return values at procedure termination, These components are stored in libraries and , 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 ( and ), the maximum number of conditions allowed in the selector () and the maximum number of conditions allowed in any procedure (). Note that the maximum possible size of such a system (described in terms of the number of lines of code in the system) is captured by the expression .

  • Software system adaptation: We will here consider two types of adaptation: (1) changes to the system code: changing the condition in or action executed by any IF-THEN-ELSE statement (component adaptation) and (2) changes to the system component-set: using a different selector-component from or changing any used procedure-component to another from (system adaptation). Note in the case of a selector-component change of type (2), 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. As such, these adaptations are invasive and at the code level (though, in a limited sense, adaptations of type (2) can be seen as operating at the architecture level).

req. action
T T T T T
T F F F T
F F F F F
F F F F F
T T T F T

(a)
procedure p1: procedure p2
  if then   if then
  elsif then   elsif then
  elsif then   els
  else
procedure p3: procedure p4:
  if then  
  else
(b)
selector s1: selector s2:
  if then ???   if * then ???
  elsif then ???
  else ???
(c)
system S1: system S2:
  if then call p1   if * then call p2
  elsif then call p3
  else call p4
(d)
Figure 1: Example Requirements, Procedures, Selectors, and Software Systems. (a) Software requirements defined on situation-variables and action-set . (b) Four procedures. (c) Two selectors as they would appear in a selector-component library with blank procedure calls, where is the default selector. (d) Two software systems created by instantiating the procedure-calls in the selectors from part (c) with procedures from part (b).

Examples of the first four of these entities are given in Fig. 1. The above allows us to formalize various actions and properties in the problems given in Section 2.1 as follows:

  • A software system is consistent with a software structure-specification if it has the two-level structure described above where IF-THEN conditions are members of , all procedure-executed actions are drawn from , the number of conditions in the selector is at most , and the number of conditions in each procedure is at most . Note that the default selector has (e.g., selector s4 in Fig. 1(c)) and a procedure consisting of a single action has (e.g., procedure p4 in Fig. 1(b)). For example, both software-systems in Fig. 1(d) are consistent with .

  • A software system is constructed from components drawn from if the selector-component is from and each procedure-component is from . Note that a member of may appear zero, one, or more times in . For example, both software systems in Fig. 1(d) are constructed using components drawn from .

  • A software system is derived from software system relative to if there is a sequence of component and system adaptations relative to that transforms into .

  • The operation of a software system satisfies requirements if for each situation-action pair in , the execution of relative to the truth-settings in results in the execution of . For example, software system S1 in Fig. 1(d) satisfies the requirements in Fig. 1(a) but software system S2 does not (because it produces different outputs (, , , and respectively) for requirements , , , and ).

One’s initial reaction on contemplating the above is that it is all way too simple — the radically restricted types of components and component composition considered here can produce only the most basic memoryless reactive software systems, whose computational power is far less than that required in many real-world software systems. However, by the logic described previously in Section 1 and discussed at greater length in Section 5, it is precisely the use of such simplified models in the problems we analyze that will allow many of our derived results to apply to a broad range of more realistic models of component-based software system development.

2.3 Formalizations of computational problems

We can now formalize the problems sketched in Section 2.1 as follows:

Software Creation   (SCre-Spec)
Input: Software requirements based on sets and , a software-structure specification .
Output: A software system whose structure is consistent with and whose operation satisfies , if such an exists, and special symbol otherwise.

Software Creation from Components   (SCre-Comp)
Input: Software requirements based on sets and , a set of software-component libraries , a positive integer .
Output: A software system whose structure consists of components based on at most types of components drawn from the libraries in and whose operation satisfies , if such an exists, and special symbol otherwise.

Software Creation from Adapted Components   (SCre-CompA)
Input: Software requirements based on sets and , a set of software-component libraries , positive integers .
Output: A software system whose structure consists of components derived by at most changes to at most types of components drawn from the libraries in and whose operation satisfies , if such an exists, and special symbol otherwise.

Software Reconfiguration   (SRec-Spec)
Input: A software system whose operation satisfies requirements and whose structure is consistent with specification , a set of new situation-action pairs based on and , a positive integer .
Output: A software system derived by at most code changes to whose structure is consistent with and whose operation satisfies , if such an exists, and special symbol otherwise.

Software Reconfiguration from Components   (SRec-Comp)
Input: A software system whose structure consists of components from a set of software-component libraries and whose operation satisfies requirements , a set of new situation-action pairs based on and , positive integers .
Output: A software system derived from by at most component changes relative to the libraries in whose structure consists of at most types of components and whose operation satisfies , if such an exists, and special symbol otherwise.

Software Reconfiguration from Adapted Components   (SRec-CompA)
Input: A software system whose structure consists of components from a set of software-component libraries and whose operation satisfies requirements , a set of new situation-action pairs based on and , positive integers .
Output: A software system derived from by at most component changes relative to the libraries in and code changes whose structure consists of at most types of components and whose operation satisfies , if such an exists, and special symbol otherwise.

We have included parameter in all component-based problems to allow control over and hence investigation of the computational effects of restricting the number of component retrievals from given libraries. In the case of problems SCre-Spec and SRec-Spec where is not explicitly included, (as the number of types of components in software systems created in these problems is bounded by the number of available procedure-call slots in the selector). The inclusion of parameters and in the reconfiguration problems is justified analogously.

It is important to note the following three ways in which these problems abstract away from practical aspects of CBD:

  1. the costs of searching for and accessing any component used to build a software system is constant (as all components are in and );

  2. determining whether a set of components can be integrated together into a running system (verification [11, page 552]) is trivial (as any selector from with procedure-slots is compatible with any selection of procedures from ); and

  3. determining whether a software system satisfies all of a given set of requirements (validation [11, page 552]) can be done in low-order polynomial time (as each requirement in can be run checked against a two-level system in time proportional to the number of lines of code in the system, i.e., , to see if the requested action is produced).

Values
Parameter Description Applicability S1 S2
# situation-variables All 5 5
# possible actions All 3 3
Max # selector-conditions All 2 0
Max # procedure-conditions All 3 2
Max size of software system All 15 4
(
Max # component-types All 4 2
   in software system
# selector-components *-CompA, 2 2
   in selector-library *-Comp
# procedure-components *-CompA, 4 4
   in procedure-library *-Comp
# new requirements SRec-* N/A N/A
Max # code changes *-CompA, N/A N/A
   allowed SRec-Spec
Max # component changes SRec-CompA, N/A N/A
   allowed SRec-Comp
Table 1: Parameters for Component-based Software System Creation and Reconfiguration Problems. All values in the fourth and fifth columns of the table are given for the first and second solutions (namely, software systems s1 and s2) to the creation problem posed at the end of Section 2.2 relative to the requirements in part (a) of Fig. 1.

This is not to say that search, access, verification, and validation are unimportant; indeed, all four of these activities are very difficult for all but the simplest software systems and the subject of vigorous ongoing research [3, 4, 11, 6]. Rather, we choose to abstract away from them so that our analyses can focus on the computational difficulties associated with the core activities in CBD, namely, the selection and adaptation of components.

3 Component-based Software System Creation and
      Reconfiguration are Intractable

Let us revisit the first of the questions raised in the Introduction — namely, are there efficient algorithms for component-based software system creation and reconfiguration that are reliable, i.e., these algorithms operate correctly for all inputs? Following general practice in Computer Science [12], we shall say that an algorithm is efficient if that algorithm solves its associated problem in polynomial time — that is, the algorithm runs in time that is upper-bounded by where is the input size and and are constants. A problem which has a polynomial-time algorithm is (polynomial-time) tractable. Such algorithms are preferable to those whose runtimes are bounded by superpolynomial functions, e.g., , , . This is so because polynomial functions increase in value much slower than non-polynomial functions as gets large, which allows polynomial-time algorithms to solve much larger inputs in practical amounts of time than superpolynomial-time algorithms.

Desirable as polynomial-time algorithms are, they do not exist for any of our problems.444 All polynomial-time intractability results in this section hold relative to the conjecture, which is widely believed to be true [31, 12].

Result A: SCre-Spec, SCre-Comp, SCre-CompA, SRec-Spec, SRec-Comp, and SRec-CompA are not polynomial-time tractable.

This shows that even the basic versions of component-based creation and reconfiguration considered here are not solvable in polynomial time in general. A frequently-adopted response to this intractability is to relax reliability and consider probabilistic polynomial-time algorithms which generate solutions that are of acceptable quality a very high proportion of the time, e.g., genetic or simulated annealing algorithms [32, 33, 34]. Unfortunately, this is not a viable option either.555 This result holds relative to both the conjecture mentioned in Footnote 2 and the conjecture, the latter of which is also widely believed to be true [35, 36].

Result B

: SCre-Spec, SCre-Comp, SCre-CompA, SRec-Spec, SRec-Comp, and SRec-CompA are not polynomial-time tractable by probabilistic algorithms which operate correctly with probability

.

In the next section, we will consider what may be a more useful approach — namely, algorithms that are reliable and run in what is effectively polynomial time on restricted inputs encountered in practice.

4 What Makes Component-based Software
      System Creation and Reconfiguration
      Tractable?

To answer the question of what restrictions make component-based software system creation and reconfiguration tractable, we first need to define what it means to solve a problem efficiently under restrictions. Let such restrictions be phrased in terms of the values of aspects of our problem input or output; call each such aspect a parameter. An overview of the parameters that we consider here is given in Table 1. These parameters can be divided into three groups:

  1. Restrictions on software system, system requirement, and component structure (, , , , , );

  2. Restrictions on component library structure (, ); and

  3. restrictions on component adaptation (, ).

Note that parameters and relative to problem SCre-CompA are of use in addressing the conjectures mentioned previously in Section 1 about the effects of the extent and number of code modifications on the cost of adapting components.

The most popular conception of efficient solvability under restrictions phrased in terms of parameters is fixed-parameter tractability [13]. A problem is fixed-parameter (fp-) tractable relative to a set of parameters , i.e., - is fp-tractable, if there is an algorithm for whose running time is upper-bounded by for some function where is the problem input size and is a constant. Note that fixed-parameter tractability generalizes polynomial-time solvability by allowing the leading constant in the runtime upper-bound of an algorithm to be a function of rather than a constant. This allow problems to be effectively solvable in polynomial time when the values of the parameters in are small and is well-behaved, e.g., , such that the value of is a small constant. Hence, if a polynomial-time intractable problem is fixed-parameter tractable for a parameter-set when the values of the parameters in are small and is well-behaved then can be efficiently solved even for large inputs.

Our questions about efficient solvability of component-based software creation and reconfiguration problems under restrictions may now be rephrased in terms of what sets of parameters do and do not make these problems fp-tractable. We consider first what parameters do not yield fp-tractability.666 Each fp-intractability results in this section holds relative to the conjecture , which is widely believed to be true [13].

Result C: -SCre-Spec is fp-intractable.

Result D: -SCre-Comp is fp-intractable .

Result E: -SCre-CompA is fp-intractable.

Result F: -SRec-Spec is fp-intractable.

Result G: -SRec-Comp is fp-intractable.

Result H: -SRec-CompA is
fp-intractable.

These results are more powerful than they first appear, as a problem that is fp-intractable relative to a particular parameter-set is also fp-intractable relative to any subset of [14, Lemma 2.1.31]. Hence, there are in fact a number of combinations of parameters which cannot be restricted to yield fp-tractability for our problems. Courtesy of Result E, this includes parameters and relative to problem SCre-CompA.

That being said, there are restrictions that do make our problems fp-tractable.

Result I: -SCre-Spec, -SCre-Comp, -SCre-CompA, -SRec-Spec, -SRec-Comp, and -SRec-CompA are fp-tractable.

Result J: -SCre-Comp and -SRec-Comp are fp-tractable.

Again, these results are more powerful than they first appear, as a problem that is fp-tractable relative to a particular parameter-set is also fp-tractable relative to any superset of [14, Lemma 2.1.30]. Hence, any set of parameters including can be restricted to yield fp-tractability for all of our problems and any set of parameters including both and can be restricted to yield fp-tractability for SCre-Comp and SRec-Comp.

A detailed summary of our fixed-parameter intractability and tractability results is given in Table 2. Note that our fp-intractability results hold when many of the parameters in these results are restricted to small constant values. Moreover, courtesy of the parameter-set subset/superset relations noted above, Results C, E, F, H, and I completely characterize the parameterized complexity of problems SCre-Spec, SCre-CompA, SRec-Spec, and SRec-CompA relative to the parameters in Table 1.

Creation
Spec Comp CompA
C I D I J E I
@ @ @
2 2 2
0 @ 0
@ 1 @
@ @
2 @ 2
N/A N/A 1 1
N/A N/A @ 1
N/A N/A N/A N/A N/A N/A N/A
N/A N/A N/A N/A N/A @
N/A N/A N/A N/A N/A N/A N/A
Reconfiguration
Spec Comp CompA
F I G I J H I
@ @ @
3 2 3
0 @ 0
@ 1 @
@ @
2 @ 2
N/A N/A 1 1
N/A N/A @ 1
1 1
@ N/A N/A N/A @
N/A N/A 0
Table 2: A Detailed Summary of Our Fixed-Parameter Complexity Results. Each column in this table is a result for a particular problem which holds relative to the parameter-set consisting of all parameters with a -symbol in that column. If in addition a result holds when a parameter has a constant value , that is indicated by replacing . Results are grouped by problem, with fp-intractability results first and fp-tractability results (shown in bold) last.

5 Generality of Results

All of our intractability results (namely, Results A–H), though defined relative to basic models of software systems, system requirements, components, component libraries, and component adaptation, have a broad applicability. This is so because, as noted in Section 1, the models for which these results hold are special cases of more realistic models, e.g.,

  • purely functional software requirements that explicitly list all situations to which software should respond are a special case of more complex requirements based on compact specifications of software behaviour such as finite-state automata, statecharts, or statements in natural language which in addition incorporate other functional and non-functional 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 arbitrary procedure code and/or data types which have complex dependencies on other components such as data-type sharing or inheritance;

  • component composition by calls to procedures without input parameters or return values and which have no dependencies on other components is a special case of more complex types of component composition invoking complex dependencies on other components such as data-type sharing or inheritance;

  • 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; and

  • whitebox component adaptation involving single-line single-symbol code changes is a special case of whitebox component adaptation involving more complex types of code change.

More realistic versions of the six component-based software system creation and reconfiguration problems analyzed in this paper can be created by replacing any combination of simple special-case models with the more realistic models above. For example, one could define a version of SCre-Comp in which software requirements are given as natural language statements and components consist of arbitrary internal code composed with each other by complex interfaces such as those allowed in popular component models like CORBA. Courtesy of the special-case relationship, any automated system that solves such a more realistic problem can also solve the problem defined relative to the simple special-case models analyzed here. Depending on the nature of the special-case relationship, this will sometimes involve recoding problem entities, e.g., translating a software requirement in into a natural language statement “If is and is and is then execute action ”. Intractability results for must then also apply to as well as the operation of any automated system solving . To see this, suppose is intractable; if is tractable by algorithm , then can be used to solve efficiently, which contradicts the intractability of . Hence, must also be intractable.

Our various tractability results under restrictions (namely, Results I and J) are much more fragile. This is so because what may seem like innocuous changes to the problems analyzed here can violate assumptions critical to the correct operation of the algorithms underlying these results, which means that algorithms for solving simplified problems may not work for more realistic problems. Hence, our tractability results may only apply to certain more realistic problems, and this needs to be assessed on a case-by-case basis.

6 Discussion

We have found that it is very unlikely that creating and reconfiguring software systems by de novo design, component selection, and component selection with adaptation are polynomial-time solvable for even the simple component-based software systems considered here by either deterministic (Result A) or probabilistic (Result B) algorithms. This answers the long-standing 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. Results A and B also constitute the first proof that no

currently-used method (including search-based methods based on evolutionary algorithms (see

[32, Section 5] and references)) can guarantee both efficient and (even high-probability) correct operation for all inputs for these problems

As described in Section 4, efficient correctness-guaranteed methods may yet exist for these problems relative to plausible restrictions. It seems reasonable to conjecture that restrictions relative to the parameters listed in Table 1 should render our problems tractable. We have shown that many of these restrictions (either individually or in combination) do not yield fixed-parameter tractability (Results C–H), even when many of the parameters involved are restricted to very small constants (see Table 2). That being said, we do have some initial fixed-parameter tractability results (Results I and J). Taken together, these sets of results have the following immediate implications:

  • Our results fully characterize the fixed-parameter complexity of problems SCre-Spec, SCre-CompA, SRec-Spec, and SRec-CompA relative to the parameters in Table 1. It is interesting that the only parameter considered that matters with respect to fixed-parameter tractability is the environment which can be sensed by the software system ( (Result I)).

  • Our results partially characterize the fixed-parameter complexities of problems SCre-Comp and SRec-Comp. If fp-tractability holds in at least some of those uncharacterized cases, this would constitute proof that creating and reconfiguring software systems by component selection is tractable in a wider set of circumstances than (and hence may be preferable to) creating and reconfiguring software systems by either de novo design or component selection with adaptation.

  • Result E establishes that SCre-CompA is not fp-tractable relative to either parameter (which measures the amount of component code that can be modified) or parameter (which measures the number of code modifications). This suggests that explanations of good performance by human programmers in component selection by whitebox adaptation which are based on small values of these parameters [11, Page 537] are incomplete, and that other parameters must also be involved and of small value (if humans are invoking fp-tractable algorithms). This is worth resolving, both for suggesting how human programmers can do CBD more productively as well as characterizing which parameters considered here are and are not of small value with respect to real-world CBD development.

  • Results F and H show that SRec-Spec and SRec-CompA are not fixed-parameter tractable even when there is only a single new system requirement, i.e., . That it only takes one new requirement to cause intractability for these problems and that this cannot be mitigated by invoking fixed-parameter tractability relative to is unsettling. The situation, however, is still open with respect to this parameter for SRec-Comp, and may yet yield another circumstance under which software system reconfiguration by component selection is preferable to software system reconfiguration by either de novo design or component selection with adaptation.

Depending on questions of interest, other implications may also be gleaned from our results. In any case, observe that many of these implications are only possibly by virtue of using explicit and detailed formalizations of software systems, system requirements, components, and component adaptation, and hence could not have been inferred from previous complexity analyses establishing the general intractability of software system creation by both component selection [18, 19] and component selection with adaptation [20]. This demonstrates that, as promised at the end of Section 2.1, our analyses (and in particular, our parameterized analyses) do indeed build on and extend the results derived in those previous analyses.

It is important to note that the brute-force search algorithms underlying all of our tractability results are not immediately usable in real-world software engineering because (1) the problems solved by these algorithms are simplified versions of real-world problems and (2) the running times of these algorithms are (to be blunt, ludicrously) exorbitant. The first difficulty is a consequence of our complexity analysis methodology described in Section 1 and cannot be avoided. This is not so bad, as algorithms for simplified problems may still be useful guides in developing algorithms for more complex and realistic versions of those problems. The second difficulty is also not as bad as it initially seems because it is well known within the parameterized complexity research community that once fp-tractability is proven relative to a parameter-set, surprisingly effective fp-algorithms can often be subsequently developed [37, 13]. This may involve adding additional parameters to “minimal” parameter-sets that imply the greatest possible number of fp-tractability results. Such algorithms typically have runtimes with greatly diminished non-polynomial terms and polynomial terms that are are additive rather than multiplicative and linear in the input size.

The cautionary note above highlights a more general caveat — namely, that the analyses in this paper are only intended to sketch out relative to which sets of parameters efficient algorithms may and may not exist for our problems of interest and are not intended to be of immediate use in real-world CBD. Indeed, given the successes in applying CBD over the last several decades in various real-world settings, one may even argue that our results are irrelevant — if we have methods that work in practice, who needs theory? We believe such a view is short-sighted at best and dangerous at worst. Not knowing the precise conditions under which existing CBD methods work well may 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 fully automatic applications like ubiquitous and autonomic computing. Given that reliable software operation is crucial and efficient software creation 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.

7 Conclusions

We have presented a formal characterization of the problems of automatic software system creation and reconfiguration by de novo design, component selection, and component selection with adaptation. Our complexity analyses reveal that, while all of these approaches are computationally intractable in general relative to both deterministic and probabilistic algorithms, there are restrictions that render each of these approaches tractable. The results of these analyses give the first rigorous computational comparison between the three approaches to software design considered here. In particular, these results establish that all three approaches are equally computationally difficult in general but suggest that software system creation and reconfiguration by component selection may be tractable under more circumstances than software system creation and reconfiguration relative to the other two approaches.

There are several promising directions for future research:

  1. Complete the fixed-parameter analyses initiated in this paper relative to the parameters considered here.

  2. Define and analyze CBD-related problems that incorporate aspects of CBD that were abstracted away in the problems considered here, e.g., component search and component-set verification (Section 2.3).

  3. Define and analyze CBD-related problems that are not special cases of those considered here, e.g., CBD by blackbox component adaptation using adaptors [38, 7].

  4. Consider the computational complexity of CBD relative to additional types of tractability, e.g., polynomial-time approximation [39] and fixed-parameter approximation [40], probabilistic [41], and evolutionary [42] algorithms.

It is our hope that this research will, in time, be of use in both deriving the best possible implementations of fully automatic component-based software system creation and reconfiguration methods for real-world CBD and inspiring additional parameterized complexity analyses of other activities in software engineering, e.g., automatic software system (re)modularization (see [43] and references).

Acknowledgments

The authors extend most grateful thanks to Iris van Rooij and Maria Otworowska, with whom they collaborated on the formalization of the adaptive toolbox theory of human decision-making that underlies the formalizations of component-based software system creation and reconfiguration analyzed here. We also want to thank Antonina Kolokolova and Johan Kwisthout for useful discussions on Rice’s Theorem and efficient probabilistic solvability, respectively. Funding for this work was provided by a National Science and Engineering Research Council (NSERC) Discovery Grant to TW (grant # 228105-2015).

References

  • [1] D. McIlroy, “Mass produced software components,” in Software Engineering Concepts and Techniques: 1968 NATO Conference on Software Engineering, J. M. Buxton, P. Naur, and B. Randell, Eds.   New York, NY: Petrocelli/Charter, 1968, pp. 88–98.
  • [2] W. B. Frakes and K. Kang, “Software reuse research: Status and future,” IEEE transactions on Software Engineering, vol. 21, no. 7, pp. 529–536, 2005.
  • [3] D. Gruntz, S. Murer, and C. Szyperski, Component Software-Beyond Object-Oriented Programming.   Addison-Wesley, 2002.
  • [4] G. Heineman and B. Councill, Eds., Component-Based Software Engineering: Putting the Pieces Together.   Addison-Wesley, 2000.
  • [5] J.-G. Schneider and J. Han, “Components — the past, the present, and the future,” in Workshop on Component-Oriented Programming, 2004.
  • [6] T. Vale, I. Crnkovic, E. S. de Almeida, P. A. d. M. S. Neto, Y. C. Cavalcanti, and S. R. de Lemos Meira, “Twenty-eight years of component-based software engineering,” Journal of Systems and Software, vol. 111, pp. 128–148, 2016.
  • [7] S. Kell, “A survey of practical software adaptation techniques.” Journal of UIniversal Computer Science, vol. 14, no. 13, pp. 2110–2157, 2008.
  • [8] G. Banavar and A. Bernstein, “Software infrastructure and design challenges for ubiquitous computing applications,” Communications of the ACM, vol. 45, no. 12, pp. 92–96, 2002.
  • [9] J. O. Kephart and D. M. Chess, “The vision of autonomic computing,” IEEE Computer, vol. 36, no. 1, pp. 41–50, 2003.
  • [10] R. González and M. Torres, “Critical issues in component-based development,” in Proceedings of The 3rd International Conference on Computing, Communications and Control Technologies, 2005.
  • [11] H. Mili, F. Mili, and A. Mili, “Reusing software: Issues and research directions,” IEEE transactions on Software Engineering, vol. 21, no. 6, pp. 528–562, 1995.
  • [12] M. R. Garey and D. S. Johnson, Computers and Intractability.   W.H. Freeman, 1979.
  • [13] R. Downey and M. Fellows, Fundamentals of Parameterized Complexity.   Berlin: Springer, 2013.
  • [14] T. Wareham, Systematic Parameterized Complexity Analysis in Computational Phonology.   Ph.D. thesis, University of Victoria, 1999.
  • [15] T. Wareham and M. Sweers, “On the computational complexity of designing and reconfiguring component-based software systems,” in Proceedings of the 9th EAI International Conference on Bio-inspired Information and Communication Technologies (BICT 2015).   Brussels: Institute for Computer Sciences, Social-informatics, and Telecommunications Engineering (ICST), 2015, pp. 425–432.
  • [16] ——, “On the computational complexity of designing and reconfiguring component-based software systems,” EAI Endorsed Transactions on Self-Adaptive Systems, vol. 16, no. 5, p. e4, 2016.
  • [17] J. E. Hopcroft, R. Motwani, and J. Ullman, Introduction to Automata Theory, Languages, and Computation, 2nd ed.   Addison-Wesley, 2001.
  • [18] E. H. Page and J. M. Opper, “Observations on the complexity of composable simulation,” in Proceedings of the 31st Winter Conference on Simulation, vol. 1.   ACM, 1999, pp. 553–560.
  • [19] M. Petty, E. Weisel, and R. Mielke, “Computational complexity of selecting components for composition,” in Proceedings of the Fall 2003 Simulation Interoperability Workshop, 2003, pp. 14–19.
  • [20] R. G. Bartholet, D. C. Brogan, and P. F. Reynolds Jr, “The computational complexity of component selection in simulation reuse,” in Proceedings of the 2005 Winter Simulation Conference, 2005, pp. 2472–2481.
  • [21] M. Nouri and J. Habibi, “Approximating component selection with general costs,” in Advances in Computer Science and Engineering.   Springer, 2008, pp. 61–68.
  • [22] M. R. Fox, D. C. Brogan, and P. F. Reynolds Jr, “Approximating component selection,” in Proceedings of the 36th conference on Winter simulation.   Winter Simulation Conference, 2004, pp. 429–434.
  • [23] N. Haghpanah, S. Moaven, J. Habibi, M. Kargar, and S. H. Yeganeh, “Approximation algorithms for software component selection problem,” in Software Engineering Conference, 2007. APSEC 2007. 14th Asia-Pacific.   IEEE, 2007, pp. 159–166.
  • [24] C. Ayala, Ø. Hauge, R. Conradi, X. Franch, and J. Li, “Selection of third party software in off-the-shelf-based software development — an interview study with industrial practitioners,” Journal of Systems and Software, vol. 84, no. 4, pp. 620–637, 2011.
  • [25] R. Land, L. Blankers, M. Chaudron, and I. Crnković, “COTS selection best practices in literature and in industry,” in International Conference on Software Reuse.   Springer, 2008, pp. 100–111.
  • [26] A. Mohamed, G. Ruhe, and A. Eberlein, “COTS selection: past, present, and future,” in Engineering of Computer-Based Systems, 2007. ECBS’07. 14th Annual IEEE International Conference and Workshops on the.   IEEE, 2007, pp. 103–114.
  • [27] M. Otworowska, M. Sweers, R. Wellner, M. Uhlmann, T. Wareham, and I. van Rooij, “How did Homo Heuristicus become ecologically rational?” in Proceedings of the EuroAsianPacific Joint Conference on Cognitive Science, 2015, pp. 324–329.
  • [28] M. Sweers, Adapting the Adaptive Toolbox: The Computational Cost of Building Rational Behaviour.   M.Sc. thesis, Radboud University Nijmegen, 2015.
  • [29] M. Otworowska, M. Blokpoel, M. Sweers, T. Wareham, and I. van Rooij, “Demons of ecological rationality,” Cognitive Science, vol. 42, no. 3, pp. 1057–1066, 2018.
  • [30]

    G. Gigerenzer and P. Todd, “Fast and frugal heuristics: The adaptive toolbox,” in

    Simple Heuristics that Make Us Smart.   Oxford University Press, 1999, pp. 3–34.
  • [31] L. Fortnow, “The Status of the P Versus NP Problem,” Communications of the ACM, vol. 52, no. 9, pp. 78–86, 2009.
  • [32] M. Harman, S. Mansouri, and Y. Zhang, “Search-based software engineering: Trends, techniques and applications,” ACM Computing Surveys, vol. 45, no. 1, p. 11, 2012.
  • [33] L. Li, M. Harman, F. Wu, and Y. Zhang, “SBSelector: Search based component selection for budget hardware,” in International Symposium on Search Based Software Engineering.   Springer, 2015, pp. 289–294.
  • [34] A. Vescan, C. Grosan, and H. F. Pop, “Evolutionary algorithms for the component selection problem,” in Database and Expert Systems Application, 2008. DEXA’08. 19th International Workshop on.   IEEE, 2008, pp. 509–513.
  • [35] A. E. F. Clementi, J. D. P. Rolim, and L. Trevisan, “The computational complexity column: Recent advances towards proving ,” Bulletin of the European Association for Theoretical Computer Science, vol. 64, pp. 96–103, 1998.
  • [36] A. Wigderson, “P, NP and mathematics — A computational complexity perspective,” in Proceedings of ICM 2006: Volume I.   Zurich: EMS Publishing House, 2007, pp. 665–712.
  • [37] M. Cygan, F. V. Fomin, L. Kowalik, D. Lokshtanov, D. Marx, M. Pilipczuk, M. Pilipczuk, and S. Saurabh, Parameterized Algorithms.   Springer, 2015.
  • [38] B. Morel and P. Alexander, “SPARTACAS: automating component reuse and adaptation,” IEEE Transactions on Software Engineering, vol. 30, no. 9, pp. 587–600, 2004.
  • [39] G. Ausiello, P. Crescenzi, G. Gambosi, V. Kann, A. Marchetti-Spaccamela, and M. Protasi,

    Complexity and approximation: Combinatorial optimization problems and their approximability properties

    .   Springer, 1999.
  • [40] D. Marx, “Parameterized complexity and approximation algorithms,” The Computer Journal, vol. 51, no. 1, pp. 60–78, 2008.
  • [41]

    J. Kwisthout, “Tree-width and the computational complexity of MAP approximations in Bayesian networks,”

    Journal of Artificial Intelligence Research, vol. 53, pp. 699–720, 2015.
  • [42] S. Kratsch and F. Neumann, “Fixed-parameter evolutionary algorithms and the vertex cover problem,” Algorithmica, vol. 65, no. 4, pp. 754–771, 2013.
  • [43] T. Wareham, “On the computational complexity of software (re)modularization: Elaborations and opportunities,” in Proceedings of the 9th EAI International Conference on Bio-inspired Information and Communication Technologies (BICT 2015).   Brussels: Institute for Computer Sciences, Social-informatics, and Telecommunications Engineering (ICST), 2015, pp. 418–424.

Appendix A Proofs of Results

All of our intractability results will be derived using polynomial-time and parameterized reductions777 Given two problems and , a polynomial-time reduction from to is essentially a polynomial-time algorithm for transforming instances of into instances of such that any polynomial-time algorithm for can be used in conjunction with this instance transformation algorithm to create a polynomial-time algorithm for . Analogously, a parameterized reduction from - to - allows the instance transformation algorithm to run in fp-time relative and requires that for each that there is a function such that . Such an instance transformation algorithm can be used in conjunction with any fp-algorithm for - to create an fp-algorithm for -. The interested reader is referred to [13, 12] for details. from the following problem:

Dominating Set
Input: An undirected graph and an integer .
Question: Does contain a dominating set of size , i.e., is there a subset , , such that for all , either or there is a such that ?

This problem is -hard in general [12, Problem GT2] and -hard relative to parameter-set [13]. For each vertex , let the complete neighbourhood of be the set composed of and the set of all vertices in that are adjacent to by a single edge, i.e., . We assume below an arbitrary ordering on the vertices of such that .

For technical reasons, all intractability results are proved relative to decision versions of problems, i.e., problems whose solutions are either “yes” or “no”. Though none of our problems defined in Section 2.3 of the main text are decision problems, each can be made into a decision problem by asking if that problem’s requested output exists; let that decision version for a problem X be denoted by X. The following easily-proven lemma will be useful below in transferring results from decision problems to their associated non-decision problems; it follows from the observation that any algorithm for non-decision problem X can be used to solve X.

Lemma 1

If X is -hard then X is not solvable in polynomial time unless .

Lemma 2

Dominating Set polynomial-time many-one reduces to SCre- Spec such that in the constructed instance of SCre-Spec, , , and and are functions of in the given instance of Dominating Set.

Proof: Given an instance of Dominating set, the constructed instance of SCre-Spec has , i.e., there is a unique situation-variable corresponding to each vertex in , , , and . As and for this problem , . There are situation-action pairs in such that (1) for , , if and is otherwise and , and (2) for , all are and . Note that the instance of SCre-Spec described above can be constructed in time polynomial in the size of the given instance of Dominating Set.

If there is a dominating set of size at most in the given instance of Dominating Set, construct a software system consisting of a default *-condition selector and a single procedure in which the IF-THEN statements have situation-variable conditions corresponding to the vertices in and action and the final ELSE statement has action . Observe that this software system satisfies all situation-action pairs in and has and .

Conversely, suppose that the constructed instance of SCre-Spec has a software system satisfying with and . The selector in this system must be the default selector as it is the only selector with . As for the single procedure attached to that selector, it has two possible structures:

  1. No negated situation-variable conditions: As has no situation- variables set to , it can only be processed correctly by the final ELSE-statement, which must thus execute action . In order to accept all other situation-action pairs in , the remaining IF-THEN statements must both have associated executed action 1 and situation-variables whose corresponding vertices form a dominating set in of size at most .

  2. Negated situation-variables are present: Let be the first negated situation-variable condition encountered moving down the code in the procedure, be the set of unnegated situation-variable conditions encountered before , and be the set of situation-action pairs in that are not recognized by the situation-variables in . As , . As situation-action pair has no situation-variable with value and hence cannot be recognized by an IF-THEN statement with an unnegated situation-variable condition, . Moreover, as each situation-action pair in has associated action 1, all actions executed by the IF-THEN statements associated with the variables in must be 1.

    Let be such that . If is empty, then the variables in must have recognized all situation-action pairs in except , and hence the vertices corresponding to the situation-variables in form a dominating set in of size at most . If is not empty, the situation-variable in cannot have value for any of the situation-action pairs in because having either or as the action executed by the associated IF-THEN statement would result in the procedure executing the wrong action for at least one situation-action pair in (if , at least one of the situation-action pairs in ; if , ). However, this implies that all situation-action pairs in have value for the situation- variable in , which in turn implies that the vertices corresponding to the situation-variables in form a dominating set in of size at most .

Hence, the existence of a satisfying software system for the constructed instance of SCre-Spec implies the existence of a dominating set of size at most for the given instance of Dominating Set.

To complete the proof, note that in the constructed instance of SCre-Spec, , , , and .   

Lemma 3

Dominating Set polynomial-time many-one reduces to SCre-CompA such that in the constructed instance of SCre-CompA, , , , and , , and are functions of in the given instance of Dominating Set.

Proof: Given an instance of Dominating Set, the constructed instance of SCre-CompA has , , and as in the reduction in Lemma 2 above. Let consist of the default selector and consist of a single procedure whose IF-THEN statements have conditions that are arbitrarily-selected unnegated situation-variables in and execute action and whose ELSE statement executes action . Finally, set and . Note that the instance of SCre-CompA described above can be constructed in time polynomial in the size of the given instance of Dominating Set.

If there is a dominating set of size at most in the given instance of Dominating Set, construct the software system consisting of the single selector and procedure given in libraries and , respectively, and create from by modifying the first IF-THEN statements in the procedure to have situation-variable conditions corresponding to the vertices in and modifying the remaining IF-THEN statements in the procedure to have situation-variable conditions corresponding to an arbitrary subset of . Observe that satisfies all situation-action pairs in , has and , and is obtained by at most modifications to the system code of .

Conversely, suppose that the constructed instance of SCre-CompA has a software system satisfying that was obtained by at most modifications to the system code of a software system consisting of at most components drawn from and . There is exactly one such consisting of the single selector and procedure in libraries and , respectively. The modifications made to the procedure in to create result in one of the two structures described in the proof of correctness of the reduction in Lemma 2 above, both of which (as shown in that same proof) allow the derivation of dominating sets in of size at most .

To complete the proof, note that in the constructed instance of SCre-CompA, , , , , and .   

Lemma 4

Dominating Set polynomial-time many-one reduces to SCre- Comp such that in the constructed instance of SCre-Comp, , , and is a function of in the given instance of Dominating Set.

Proof: Given an instance of Dominating set, the constructed instance of SCre-Comp has and . There are situation-action pairs in such that (1) for , , , if , all other are , and , and (2) for , all and . There is a single selector in whose IF-THEN statement conditions are the first situation-variables in . There are procedures in such that procedure , , has an IF-THEN statement whose condition is situation-variable and which executes action and an ELSE statement that executes action . As such, each procedure in effectively corresponds to and encodes vertex . Finally, let . Note that the instance of SCre-Comp described above can be constructed in time polynomial in the size of the given instance of Dominating Set.

If there is a dominating set of size at most in the given instance of Dominating Set, construct a software system consisting of the single selector in and the set consisting of the procedures in corresponding to the vertices in . For the th IF-THEN statement in the selector, , execute any of the procedures in encoding a vertex in that dominates . For the ELSE statement in the selector, execute any of the procedures in encoding a vertex in that dominates vertex . Observe that satisfies all situation-action pairs in (with both and being satisfied by the procedure associated with the ELSE statement in the selector) and has .

Conversely, suppose that the constructed instance SCre-Comp has a software system constructed from at most distinct components from and that satisfies all of the situation-action pairs in . As the selector is constructed such that each of the first situation-action pairs in has its own associated procedure and each procedure accepts a specific vertex in , in order for these situation-action pairs to be satisfied, the distinct procedures in must correspond to a dominating set for (note that both and are satisfied by the procedure associated with the ELSE statement in the selector). As and had to incorporate a selector from , there are at most such procedures and hence there is a dominating set of size at most in the given instance of Dominating Set.

To complete the proof, note that in the constructed instance of SCre-Comp, , , and .   

Lemma 5

Dominating Set polynomial-time many-one reduces to SRec- Spec such that in the constructed instance of SRec-Spec, , , , , and , , and are functions of in the given instance of Dominating Set.

Proof: Given an instance of Dominating set, the constructed instance of SRec-Spec has , , , and . As and for this problem , . There are situation-action pairs in such that (1) for , , if , , all remaining are , and , and (2) for , all are and . Software system consists of the default selector and a single procedure based on conditions, in which the first IF-THEN statements have arbitrary conditions drawn from the first situation-variables in and execute action , the IF-THEN statement has condition and executes action , and the ELSE statement executes action . Note that satisfies . Set consists of a single situation-action pair with such that , all remaining are , and . Finally, let . Note that the instance of SRec-Spec described above can be constructed in time polynomial in the size of the given instance of Dominating Set.

If there is a dominating set of size at most in the given instance of Dominating Set, construct a software system consisting of a default selector and a single procedure modified from in which the last IF-THEN statement executes action when and the conditions of the remaining IF-THEN statements are the situation-variables corresponding to the vertices in (with, if , the conditions of the final IF-THEN statements corresponding to an arbitrary subset of size from ). Observe that satisfies , has and , and can be obtained by at most changes to the system code of .

Conversely, suppose that the constructed instance of SRec-Spec has a software system satisfying with and that can be created from by at most code changes. The selector in this system must be the default selector (as it is the only selector with ). Hence, all code changes are confined to the procedure. This procedure has two possible structures:

  1. No negated situation-variable conditions: As has no situation-vari-ables set to , it can only be processed correctly by the final ELSE-statement, which must thus execute associated action . As has no situation-variable set to except , it can only be processed correctly by an IF-THEN statement with condition that executes action . In order to correctly process all remaining situation-action pairs in , the remaining IF-THEN statements must both have associated executed action 1 and situation-variables whose corresponding vertices form a dominating set in of size at most .

  2. Negated situation-variables are present: Let be the first negated situation-variable condition encountered moving down the code in the procedure, be the set of unnegated situation-variable conditions encountered before , and be the set of situation-action pairs in that are not recognized by the situation-variables in . As , . Moreover, as situation-action pair has no situation-variable with value and hence cannot be recognized by an IF-THEN statement with an unnegated situation-variable condition, .

    Let be such that . There are three possibilities:

    1. : In this case, must be in in order for to be recognized prior to . However, this implies that all situation-action pairs in must have been recognized prior to the IF-THEN statement with condition (otherwise, the action 2 required to correctly recognize would have caused the wrong action to be output for at least one of these situation-action pairs). This would mean that the vertices corresponding to the situation-variables in form a dominating set in of size at most in .

    2. and , i.e., : The variables in must have recognized all situation-action pairs in except , and hence the vertices corresponding to the situation-variables in form a dominating set in of size at most in .

    3. and : Observe that the situation-variable in cannot be in as the action executed by the associated IF-THEN statement would result in the procedure executing the wrong action for at least one situation-action pair in (if , at least one of the situation-action pairs in ; if , and ; if , at least one of the situation-action pairs in ). Hence, the only situation-action variable that can safely occur negated in at this point is , whose negation recognizes only .

      Consider now the processing of in the procedure after the IF-THEN statement with condition . As all remaining unrecognized situation-action pairs have and cannot be recognized by condition , we will assume that no statement with condition is encountered. There are three possible cases:

      1. An IF-THEN statement with condition is encountered: Let be the set of unnegated situation-variable conditions encountered between and condition and be the set of situation-action pairs remaining to be processed as of condition . As , . Moreover, as , .

        As does not contain , is for all situation-action pairs in . We also know that satisfies . This implies that only has one member because if this is not so, the action executed by the IF-THEN statement with as its condition cannot be or without processing at least one member of incorrectly. However, this implies that the vertices corresponding to the situation-variables in form a dominating set in of size at most .

      2. Another IF-THEN statement with a negated situation-variable condition is encountered: Let be the situation-variable negated in , be the set of unnegated situation-variable conditions encountered between and , and be the set of situation-action pairs remaining to be processed as of condition . We may assume that as this case is covered in (i) above; hence, . Moreover, as , .

        The situation-variable cannot have value for any of the situation-action pairs in because having either