Incremental Realization of Safety Requirements: Non-determinism vs. Modularity

. This paper investigates the impact of non-determinism and modularity on the complexity of incremental incorporation of safety requirements while preserving liveness (a.k.a. the problem of incremental synthesis ). Previous work shows that realizing safety in non-deterministic programs under limited observability is an NP-complete problem (in the state space of the program), where limited observability imposes read restrictions on program components with respect to the local state of other components. In this paper, we present a surprising result that synthesizing safety remains an NP-complete problem even for deterministic programs! The results of this paper imply that non-determinism is not the source of the hardness of synthesizing safety in concurrent programs; instead, limited observability has a major impact on the complexity of realizing safety. We also provide a roadmap for future research on exploiting the beneﬁts of modularization while keeping the complexity of incremental synthesis manageable.


Introduction
Understanding the complexity of realizing new (safety/liveness) properties is of paramount importance since today's systems often have to adapt to new requirements while preserving some existing functionalities. Safety stipulates that nothing bad ever happens (e.g., at most one process/thread accesses shared resources at any moment), and liveness states that something good will eventually occur (e.g., each process eventually gets access to shared resources). New requirements are raised due to changes in platform, environmental faults, design flaws, new user requirements (e.g., non-functional concerns), porting, etc. Thus, it is important to enhance our understanding of what complicates behavioral changes. Towards this end, this paper investigates the complexity of redesigning finite-state programs towards capturing new safety requirements while preserving liveness, called the problem of incremental synthesis.
Several approaches exist for capturing safety most of which lack a thorough complexity analysis. For example, aspect-oriented approaches [5,17,16,10,13,6] provide a method for capturing and verifying cross-cutting functionalities. Control-theoretic techniques [25,12] realize new safety requirements by generating controllers that implement safety in different components of a system. Techniques based on transformation automata [24] enforce safety and/or security policies. Our previous work [7,3] shows that incremental synthesis for non-deterministic programs can be done in polynomial time (in the size of program state space) if we consider unlimited observability, where program components/processes can atomically read the state of other processes. Nonetheless, the authors of [4] demonstrate that incremental synthesis of safety in nondeterministic programs under limited observability is NP-complete (in the size of the program state space). Limited observability imposes restrictions on processes with regard to reading the state of other processes. Vechev et al. [27] present an exponential algorithm for synthesizing synchronization mechanisms under limited observability, but they provide no results on the general case hardness of synthesizing synchronization mechanisms. Now, the open questions are: What role do non-determinism and observability/modularization play in the complexity of incremental synthesis? Is incremental synthesis of safety easier for deterministic programs?
In this paper, we prove that non-determinism is not the major source of the complexity of incremental synthesis; rather it is modularization constraints that complicate the incremental synthesis of safety properties. We consider Alpern and Schneider's [1] definition of safety/liveness properties, where a property is a set of sequences of states. Their definition of a safety property P can be represented as a set of finite sequences that cannot be extended to be in P, which we call them bad sequences. We also investigate a special case of safety properties that can be specified as a set of Bad Transitions (BT) (introduced in [18]). The BT model is more general than the usual notion of Bad States (BS) in that every transition reaching a bad state is considered to be a bad transition, whereas not every bad transition reaches a bad state [20]. Previous work [7,3] shows that incremental synthesis of safety (for deterministic and non-deterministic programs) can be done in polynomial time (in the size of the state space) under unlimited observability. Nonetheless, we show that under limited observability the general case complexity of synthesizing safety in deterministic programs increases to NP-complete! Our results imply that limited observability has a major impact on the complexity of incremental synthesis of safety (see Figure 1) regardless of non-determinism/determinism. While modularity is a powerful design concept, design for change [22] is also an important goal. To achieve this goal, research should be focused on identifying the kind of modularization techniques that facilitate incremental synthesis.
Organization. Section 2 presents preliminary concepts. Section 3 formulates the problem of incremental synthesis of safety. Section 4 shows that the general case complexity of incremental synthesis of safety in deterministic programs increases to NP-complete if we assume limited observability. Finally, in Section 5, we make concluding remarks and present a roadmap for future research.

Unlimited Observability Limited Observability Deterministic Programs
P NP-complete * Non-Deterministic Programs P NP-complete Fig. 1. The impact of non-determinism and limited observability on the complexity of incremental synthesis ( * depicts the contribution of this paper).

Preliminaries
In this section, we present formal definitions of finite-state programs, program components 1 , computations and safety specifications. The definition of specification is adapted from Alpern and Schneider [1]. We use a read/write model from [2,19]. Programs. A program p = V p , C p , I p , F p is a tuple of a finite set V p of variables and a finite set C p of computing components . I p denotes a finite set of initial states, and F p represents a finite set of accepting/final states. For a variable v and a state s, v(s) denotes the value of v in s. The state space S p is the set of all possible states of p and |S p | denotes the size of S p . A state predicate is a subset of S p . A transition is an ordered pair (s, s ), where s and s are program states. A component C j is a triple δ j , r j , w j , where 1 ≤ j ≤ k and δ j ⊆ S p × S p denotes the set of transitions of C j . We shall define r j and w j below. The set of transitions of a program p, denoted δ p , is the union of the sets of transitions of its components; i.e., δ p = k j=1 δ j . A program p is non-deterministic iff (if and only if) the transition function δ p is defined as S p → 2 Sp . A deterministic program is a special case where from each state there is at most one outgoing transition. That is, the set δ p defines a partial (transition) function from S p to S p . Thus, given a state s ∈ S p , δ p returns at most one state s ∈ S p . This is a property that each δ j inherits from δ p . Notation. For simplicity, we shall misuse p and δ p interchangeably. Read/Write Model. In order to model the access rights of each component C j (1 ≤ j ≤ k) with respect to program variables, we define a set of variables that C j is allowed to read, denoted r j , and a set of variables that C j can write, denoted w j . Notice that, if a variable v of some component C i is read/written through the interface of C i , then v is considered readable/writable for the component that invokes the interface of C i . We assume that w j ⊆ r j ; i.e., a component cannot blindly write a variable it cannot read. The write restrictions of a component C j identify a set of transitions {(s, s ) | ∃v : v / ∈ w j : v(s) = v(s )} that δ j excludes, where v denotes a variable. For example, consider a program p r with two components C 1 and C 2 and two binary variables v 1 and v 2 . The component C 1 (respectively, C 2 ) can read and write the variable v 1 (respectively, v 2 ), but it cannot read (or write) v 2 (respectively, v 1 ). Let v 1 , v 2 denote the state of the program p r . A transition t 1 , represented as ( 0, 0 , 1, 1 ), does not belong to C 1 because v 2 / ∈ w 1 and the value of v 2 is being updated. For similar reasons, t 1 does not belong to C 2 either.
The effect of read restrictions is that, during the synthesis of safety, δ j of a component C j includes (respectively, excludes) a transition t iff a group of transitions associated with t is included (respectively, excluded) in δ j [19,2]. In the aforementioned example, consider the transition t 2 as ( 0, 0 , 1, 0 ). If C 1 includes only t 2 , then the execution of t 2 can be interpreted as the atomic execution of the following if statement: 'if (v 1 = 0) ∧ (v 2 = 0) then v 1 := 1'; i.e., C 1 needs to read v 2 . Including both transitions ( 0, 0 , 1, 0 ) and ( 0, 1 , 1, 1 ) makes the value of v 2 irrelevant, thereby eliminating the need for reading v 2 by C 1 . Thus, the component C 1 must either include or exclude both transitions as a group. Formally, a component C j can include a transition (s, s ) if and only if C j also includes any transition (s g , s g ) such that for all variables v ∈ r j , we have v(s) = v(s g ) and v(s ) = v(s g ), and for all variables u / ∈ r j , we have u(s) = u(s ) and u(s g ) = u(s g ).

Computations.
A computation of a program p = V p , C p , I p , F p is a sequence of states σ = s 0 , s 1 , · · · , where each transition (s i , s i+1 ) in σ (i ≥ 0) belongs to some component C j , 1 ≤ j ≤ k, i.e., C j executes the transition (s i , s i+1 ), and σ is maximal. That is, either σ is infinite, or if σ is finite and terminates in a state s f , then there is no component of p that executes a transition (s f , s) for any state s. A computation prefix of p is a finite sequence σ = s 0 , s 1 , · · · , s m of states in which every transition (s i , s i+1 ), for 0 ≤ i < m, is executed by some component C j , 1 ≤ j ≤ k.
Properties and Specifications. Intuitively, a safety property/requirement states that nothing bad ever happens. Formally, we follow Alpern and Schneider [1] in defining a property as a set of sequences of states. A safety property P can be represented by a set of finite sequences of states, denoted B, that cannot be extended to be in P. Each sequence in B represents a scenario of the occurrence of something bad. For example, a safety property of a program with an integer variable x could stipulate that an increment of x must not immediately be followed by a decrement in the value of x. Such a safety property can be represented by a set of bad sequences of three states (i.e., two immediate transitions; one that increments x and the subsequent one that decrements x). In this paper, a liveness property states that something good eventually happens, including good things that occur infinitely often. Formally, a liveness property, denoted L, is a set of sequences of states, where each sequence in L either terminates in a state belonging to a state predicate F (representing the good thing that should happen), or infinitely often visits some states in F. This notion of liveness is sufficiently general to capture stutter-invariant Linear Temporal Logic (LTL) [8] properties [11,23]. Following Alpern and Schneider [1], we define a specification, denoted spec, as a set of safety and liveness properties. A computation σ = s 0 , s 1 , · · · of a program p = V p , C p , I p , F p satisfies a specification spec from I p iff (1) s 0 ∈ I p , (2) no sequence of the safety of spec, denoted B, appears in σ, and (3) if σ terminates in a state s f , then s f ∈ F p ; otherwise, some states in F p are reached infinitely often in σ. A program p satisfies its specification spec from I p iff all computations of p satisfy spec from any state in I p . Given a finite computation σ = s 0 , s 1 , · · · , s d , if no program component executes from s d and s d / ∈ F p , then σ is a deadlocked computation and s d is a deadlock state. A computation σ = s 0 , s 1 , · · · of p is a non-progress computation iff σ does not infinitely often reach some state in F p nor does it terminate in a state in F p . A deadlocked computation is an instance of a non-progress computation. Another example is the case where a computation of p includes a cycle in which no state belongs to F p , called a non-progress cycle. If a computation σ includes a sequence in B, then σ is a safety-violating computation. A computation σ of p violates spec from a state s 0 iff σ starts at s 0 and σ is either a non-progress computation or a safety-violating computation. A program p violates spec from I p iff there exists a computation of p that violates spec from some state s 0 in I p .
Notation. Whenever it is clear from the context, we abbreviate 'p satisfies spec from I p ' as 'p satisfies spec'. Bad Transitions (BT) model. Consider a special case in which safety specifications are modeled as a set of finite sequences of length 2; i.e., a sequence has only two states. That is, the safety specification rules out a set of transitions that must not appear in program computations, called bad transitions [18]. For instance, the safety specification of a program with an integer variable x may stipulate that x can be decremented only if its value is positive. Consider a state Observe that the transition (s 2 , s 0 ) is a bad transition, whereas (s 1 , s 0 ) is not. In this model, reaching s 0 does not necessarily violate safety and it depends on how s 0 is reached. Such a model of safety specification is a restricted version of the general model of safety specifications presented by Alpern and Schneider [1], but it is more general than the usual model of bad states often specified in the literature in terms of the always operator (or invariance properties) in temporal logic [8].
Remark. We investigate incremental synthesis under "no fairness".

Problem Statement
In this section, we formally define the problem of incremental synthesis of safety. Let p = V p , C p , I p , F p be a program that satisfies a specification spec. Moreover, let B denote the safety of spec, and B new represent a new safety property (e.g., data race-freedom) that p does not satisfy. Our goal is to redesign p to a program p r = V r p , C r p , I r p , F r p , such that p r satisfies B ∧ B new and the liveness of spec from I r p . For simplicity, during such redesign, we do not expand the state space of p; i.e., no new variables are added to V p . Thus, we have V r p = V p and S r p = S p . Since p r must still satisfy spec from all states in I p , we should preserve all initial states of p. Thus, we require that I p = I r p . We state the problem as follows: Problem 1. Incremental Synthesis of Safety -Input: A program p = V p , C p , I p , F p with its specification spec, its set of safety properties B, a new safety property B new and a set of read/write restrictions for all components in C p .
• Input Assumptions: The program p satisfies spec from I p , but p may not satisfy B new from I p .
The number of components and the read/write restrictions of each component in C p remain the same in C r p , but δ j of each component C j may change in C r p 5. δ pr = ∅, and p r satisfies B ∧ B new from I p 6. Starting from any initial state s 0 ∈ I p , the revised program p r satisfies its liveness specifications.
We now define the decision problem of incremental synthesis in the BT model. -Debugging: Consider the debugging of concurrent programs for data races between multiple threads. That is, multiple threads access shared data where at least one of them performs a write operation. Data race-freedom is a safety property whereas ensuring that each thread eventually gains access to the shared data (i.e., makes progress) is a liveness property. Eliminating data races while preserving the progress of each thread is a clear example of synthesizing safety [27]. -Porting: Consider a scenario in which a distributed application designed to be deployed on a traditional wireless network is considered for deployment on a wireless sensor network. The sensor nodes have a power-saving mode in which a node automatically turns off its radio (i.e., sleep mode) if no network activities are detected for a specific time interval. To port an existing wireless application to this new platform, one has to revise the application considering the sleep mode. That is, some of the activities would be forbidden in the sleep mode (e.g., sending messages). This is an additional safety constraint that should be met while preserving all other safety/liveness properties.
-Composition and incremental development: While in this paper we investigate Problem 1 in the same state space (i.e., no new variables are added while synthesizing safety), we will investigate the synthesis of safety under more relaxed conditions where the redesigned program may include new variables. Such a generalized formulation of Problem 1 captures software composition. Several approaches in software engineering (e.g. aspectoriented programming [15]) rely on incremental design of software where modules/components that implement features/aspects are incrementally composed with an existing base system [15,14,26,16]. Moreover, there are numerous applications where software behaviors should evolve by composing plug-in components (e.g., Mozilla extensions) or by integrating mobile code (e.g., Java applets, composable proxy filters [21]). While some researchers have investigated type safety of compositions [26], dynamic safety properties of compositions are also of paramount importance.

Hardness of Incremental Synthesis
In this section, we illustrate that the general case complexity of synthesizing safety in deterministic programs increases significantly if program components have limited observability with respect to the state of other components. The intuition behind our complexity result lies in the difficulty of redesigning program computations towards capturing a new safety property while preserving liveness. Consider a computation σ = s 0 , · · · , s i−1 , s i , · · · , where i > 0, in a program p and a new safety property B new that forbids the execution of the transition t = (s i−1 , s i ); i.e., t must not be executed in the redesigned program. As such, we have to remove t. If s i−1 / ∈ F p , then σ becomes a deadlocked computation. To resolve the deadlock state s i−1 , we systematically synthesize a new sequence of states σ r = s 0 , · · · , s k , for k ≥ 0, that is inserted between s i−1 and s i to satisfy B new (i.e., avoid executing t). Note that while a direct transition from s i−1 to s i violates B new , there may be another sequence of states that can be traversed from s i−1 to s i without violating B new . The same argument holds about building a computation prefix between any predecessor of s i−1 and any successor of s i ; there is nothing particular about s i−1 and s i .
Additionally, the synthesized sequence σ r must not preclude the reachability of the accepting states in σ. To meet this requirement, no transition (s, s ) in σ r should be grouped with a transition (s g , s g ) such that s g is reachable in some computation of p r and the execution of the transition (s g , s g ) causes one of the following problems: (1) s g is a deadlock state, (2) (s g , s g ) is a safety-violating transition that must not be executed, and (3) s g is a predecessor state of s g in σ, thereby creating a non-progress cycle 2 . To ensure that the above cases do not occur, we should examine (i) all transitions selected to be in σ r , (ii) all transitions used to connect σ r to s i−1 and s i along with their associated transition groups, and (iii) the transitions of other computations. Intuitively, this leads to exploring an exponential number of possible combinations of the safe transitions (and their transition groups) that can potentially be selected to be in σ r . With this intuition, we prove that synthesizing safety in deterministic programs in the BT model of safety under limited observability is NP-complete (using a reduction from the 3-SAT problem [9]).

Problem 3. The 3-SAT Decision Problem
-Instance: A set of propositional variables, x 1 , x 2 , ..., x n , and a Boolean formula Φ = C 1 ∧ C 2 ∧ ... ∧ C m , where m, n > 1 and each clause C j (1 ≤ j ≤ m) is a disjunction of exactly three literals. Wlog, we assume that the literals x i and ¬x i do not simultaneously appear in the same clause (1 ≤ i ≤ n).
-Question: Does there exist an assignment of truth values to x 1 , x 2 , ..., x n such that Φ is satisfiable?
In Subsection 4.1, we present a polynomial mapping from an arbitrary instance of 3-SAT to an instance of Problem 2. In Subsection 4.2, we illustrate that the instance of 3-SAT is satisfiable iff safety can be synthesized in the instance of Problem 2.

Polynomial Mapping from 3-SAT
In this section, we illustrate how for each instance of 3-SAT, we create an instance of Problem 2, which includes a program p = V p , C p , I p , F p , and its safety specification B and the new safety property B new that should be captured by the redesigned program. We build the instance of Problem 2 by considering states and transitions corresponding to each propositional variable and each clause in the instance of 3-SAT. States and transitions. Corresponding to each propositional variable x i , where 1 ≤ i ≤ n, we consider the states a i , a i , b i , b i , c i , c i and d i (as illustrated in Figure 2). We also include an additional state a n+1 . For each variable x i , the instance of Problem 2 includes the transi- Corresponding to each clause C r = x i ∨ ¬x j ∨ x k , where 1 ≤ r ≤ m and 1 ≤ i, j, k ≤ n, program p includes 8 states z r , z ri , z ri , z rj , z rj , z rk , z rk and z r , and 7 transitions (z r , z ri ), (z ri , z ri ), (z ri , z rj ), (z rj , z rj ), (z rj , z rk ), (z rk , z rk ) and (z rk , z r ) depicted in Figure 3. Notice that the transitions in Figures 2 and 3 belong to different program components, which we shall explain later. Input program. The input program p includes the transitions (a i , d i ) and (d i , a i ), for 1 ≤ i ≤ n and the transitions (a n , a n+1 ) and (a n+1 , a 1 ) (see Figure  4). Starting from a 1 , the input program p executes transitions (a i , d i ), (d i , a i ) and (a i , a i+1 ), where 1 ≤ i ≤ n. From a n+1 , the program returns to a 1 . Initial and final states. The states a 1 and z r (1 ≤ r ≤ m) are initial states, and a n+1 is an accepting/final state. Moreover, the states z ri , z rj , z rk and z r are accepting states, where 1 ≤ r ≤ m and 1 ≤ i, j, k ≤ n. Starting from a 1 , the final state a n+1 is infinitely often reached. Further, if the program starts at z r then it will halt in the accepting state z r . Since all transitions (a i , d i ), (d i , a i ), (a i , a i+1 ) and (a n+1 , a 1 ) satisfy B, the program p satisfies its safety and liveness specifications from a 1 . In summary, we have Safety specifications. The safety specification B rules out any transition other than the transitions in Figures 2 and 3. Notice that while these transitions are permitted by the safety specification B, the input program p does not necessarily include all of them. The new safety property B new rules out the transitions (a i , d i ) and (z rk , z r ), where 1 ≤ i, k ≤ n and 1 ≤ r ≤ m. Thus, in the revised version of the instance of Problem 2, denoted p r , these transitions must not be executed. Program variables. The instance of Problem 2, denoted p, has four variables e, f, g and h. We denote a program state by e, f, g, h . Figure 2 illustrates the values of variables in the states included corresponding to each variable x i . Figure  3 presents the values of variables in the states included corresponding to each clause C r = x i ∨ ¬x j ∨ x k . As such, the domains of the variables are as follows: -The variable e has the domain {0, · · · , n} ∪ {m + n + 1, · · · , 2m + n}. -The domain of variable f is equal to {0, 1}.
Program components. The program p includes seven components C 1 -C 7 whose transitions have been depicted in Figure 5. The component C 5 includes transition (c i , a i ), which is grouped with (c i , b i ) and (z qi , z qi ), due to inability of reading h, where (z qi , z qi ) corresponds to a clause C q in which the literal ¬x i appears (see the dashed arrow (z rj , z rj ) in Figure 3). Notice that in these three transitions, the values of the readable variables e, f and g are the same in the source states (and in the destination states) and the value of h does not change during these transitions because it is not readable for C 5 . -The sixth component C 6 can read/write r 6 = w 6 = {f, g, h}, but cannot read e. Its set of transitions includes (c i , a i ), (b i , a i ) and (z ri , z ri ) (see Figures  2 and 3) that are grouped due to inability of reading e, where (z ri , z ri ) corresponds to a clause C r in which the literal x i appears.
-The component C 7 can read and write all variables and its set of transitions includes (d i , a i ), (a n+1 , a 1 ), (b i , c i ) and (c i , c i ) for 1 ≤ i ≤ n. Moreover, for each clause C r = x i ∨ ¬x j ∨ x k , where 1 ≤ r ≤ m and 1 ≤ i, j, k ≤ n, component C 7 includes the following transitions: (z r , z ri ), (z ri , z rj ), (z rj , z rk ) and (z rk , z r ) (see Figure 3).

Correctness of Reduction
In this section, we show that the instance of 3-SAT is satisfiable iff the instance of Problem 2 (created by the mapping in Section 4.1) can be redesigned to meet the safety properties B and B new while preserving its liveness.
Lemma 1. If the instance of 3-SAT is satisfiable, then the instance of Problem 2, denoted p, can be redesigned to another program p r for the safety property B new such that p r meets the requirements of Problem 1.
Proof. If the 3-SAT instance is satisfiable, then there must exist a value assignment to the propositional variables x 1 , · · · , x n such that all clauses C r , for 1 ≤ r ≤ m, evaluate to true. Corresponding to the value assignment to a variable x i , for 1 ≤ i ≤ n, we include a set of transitions in the redesigned program as follows: -If x i is assigned true, then we include transitions (a i , b i ), (b i , c i ), (c i , a i ). Thus the computation prefix is synthesized between a i and a i+1 . Since we have included the transition (c i , a i ), and transition (c i , a i ) is grouped with (z qi , z qi ), where 1 ≤ q ≤ m for any clause C q in which ¬x i appears, we must include (z qi , z qi ) as well (see the dashed arrow (z rj , z rj ) in Figure 3).
-If x i is assigned false, then we include transitions (a i , b i ), (b i , c i ), (c i , a i ), thereby synthesizing the computation prefix a i , b i , c i , a i , a i+1 between a i and a i+1 . Due to the inability of reading e, including the transition (c i , a i ) results in the inclusion of the transitions (z li , z li ), where 1 ≤ l ≤ m, for any clause C l in which x i appears (see the dotted arrows (z ri , z ri ) and (z rk , z rk ) in Figure 3).
-For each clause C r = x i ∨ ¬x j ∨ x k , the transition (z ri , z ri ) (respectively, (z rk , z rk )) is included iff x i (respectively, x k ) is assigned false. The transition (z rj , z rj ) is included iff x j is assigned true. Figure 6 depicts a partial structure of a redesigned program for the value assignment x 1 = f alse, x 2 = true and x 3 = true in an example clause C 5 = x 1 ∨ ¬x 2 ∨ x 3 . Note that the bad transition (z 53 , z 5 ) is not reached because x 3 = true and the transition (z 53 , z 53 ) is excluded. Fig. 6. A partial structure of the redesigned program corresponding to the value assignment x1 = f alse, x2 = true and x3 = true for an example clause C5 = x1 ∨ ¬x2 ∨ x3. Now, we illustrate that the redesigned program in fact meets the requirements of Problem 1. The state space remains obviously the same as no new variables have been introduced; i.e., V p = V r p . During the selection of transitions based on value assignment to propositional variables, we do not remove any initial states. Thus, we have I p = I r p . Satisfying safety properties. Since the new safety property rules out transitions (a i , d i ) and (z rk , z r ), we have to ensure that the redesigned program does not execute them. From a i , the program either transitions to b i or to b i . Thus, safety is not violated from a i . Moreover, since all clauses are satisfied, at least one literal in each clause C r = x i ∨ ¬x j ∨ x k must be true. Thus, at least one of the three transitions (z ri , z ri ), (z rj , z rj ) or (z rk , z rk ) is excluded, thereby preventing the reachability of z rk ; i.e., the safety-violating transition (z rk , z r ) will not be executed. Reachability of accepting states (satisfying liveness specifications). While the accepting state z r is no longer reachable, the redesigned program halts in one of the accepting state z ri , z rj or z rk . Moreover, the accepting state a n+1 is reached infinitely often due to the way we have synthesized the sequences of between a i and a i+1 . That is, (non-)terminating computations remains (non-)terminating. Thus, starting from any initial state, some accepting states will be visited infinitely often; i.e., F r p ⊆ F p . Therefore, if the instance of 3-SAT is satisfiable, then there exists a redesigned program for the instance of Problem 2 that satisfies the requirements of Problem 1.

Lemma 2.
If there exists a redesigned version of the instance of Problem 2 that meets the requirements of Problem 1, then the instance of 3-SAT is satisfiable.
Proof. Let p r be a redesigned version of the instance of Problem 2 that meets all the requirements of Problem 1. As such, the set of initial states I r p must be equal to the set {a 1 } ∪ {z r |1 ≤ r ≤ m}. Starting from a 1 , p r must execute a safe transition. Otherwise, we reach a contradiction; i.e., either a 1 is a deadlock state or the transition (a 1 , d 1 ), which violates the new safety specification is executed. Thus, p r either includes (a 1 , b 1 ) or (a 1 , b 1 ), but not both (because p r is a deterministic program). If p r includes (a 1 , b 1 ), then we set x 1 to true in the 3-SAT formula. If p r includes (a 1 , b 1 ), then we set x 1 to false.
We assign truth values to each x i , for 1 ≤ i ≤ n, depending on the presence of (a i , b i ) or (a i , b i ) at state a i (similar to the way we assign a value to x 1 ). Such a value assignment strategy results in a unique truth-value assigned to each variable Figure 2), but not both (because of determinism). If p r includes (b i , c i ), then, from c i , p r must include either (c i , c i ) or (c i , a i ). If p r includes (c i , a i ), then it must include (b i , a i ) since these two transitions are grouped due to inability of C 6 in reading e. As such, the two transitions (a i , b i ) and (b i , a i ) make a non-progress cycle in p r (see Figure 2), which is unacceptable as it violates liveness. Now, we show that, from c i , p r cannot include (c i , c i ) either. If p r includes (c i , c i ), then it must include (c i , a i ), which is grouped with (c i , b i ) due to inability of C 5 in reading h (see Figure 2). Thus, p r may reach b i from c i and deadlock in b i . Thus, if p r includes (a i , b i ) from a i , then it must include (b i , c i ) and (c i , a i ). In case where p r includes (a i , b i ) from a i , the transition (b i , c i ) must also be included; otherwise p r deadlocks in b i (Figure 2). From c i , p r cannot include (c i , c i ) because it has to include (c i , a i ) that is grouped with (c i , b i ), which creates a non-progress cycle. Thus, p r must include (c i , a i ) from c i .
We also illustrate that each clause in the 3-SAT formula evaluates to true. Consider a clause C r = x i ∨ ¬x j ∨ x k . Starting from the initial state z r , the transition (z r , z ri ) must be present in p r ; otherwise z r is a deadlock state. Moreover, from z r , the safety-violating transition (z rk , z r ) must not be executed. Thus, at least one of the transitions (z ri , z ri ), (z ri , z rj ), (z rj , z rj ), (z rj , z rk ) or (z rk , z rk ) (see Figure 3) must be excluded in p r . However, if one of the transitions (z r , z ri ), (z ri , z rj ), (z rj , z rk ) or (z rk , z r ) is excluded, then a reachable deadlock state could be created as their source states are not accepting states. Thus, if either z ri or z rj is reached from z r , then the corresponding transition (z ri , z rj ) or (z rj , z rk ) must be present in p r . Hence, at least one of the transitions (z ri , z ri ), (z rj , z rj ) or (z rk , z rk ) must be excluded in p r ; i.e., at least one literal in C r must be true, thereby satisfying C r . Proof. The proof of NP-hardness follows from Theorem 2. The proof of membership in NP is straightforward; given a revised program one can verify the constraints of Problem 1 (in the BT model) in polynomial time. Proof. The proof of NP-hardness works for the case where the safety specification rules out the reachability of states d i and z r in the instance of Problem 2. The proof of NP membership is straightforward.

Conclusions and Future Work
This paper investigates the problem of capturing new safety requirements/properties while preserving existing safety and liveness properties, called the problem of incremental synthesis. Previous work [7,3] shows that incremental synthesis for non-deterministic programs can be done in polynomial time (in the size of program state space) under unlimited observability. Moreover, it is known [4] that the complexity of incremental synthesis of safety for nondeterministic programs would increase to NP-complete under limited observability. In this paper, we illustrated that even for deterministic programs the complexity of incremental synthesis of safety is NP-complete (in program state space). Our NP-hardness proof illustrates that the read inabilities of each component with respect to the local state of other components is a major cause of complexity. Such read inabilities are mainly created because of encapsulation/modularization of functionalities at early stages of design. On one hand, encapsulation/modularity enables designers to create good abstractions while capturing different functionalities. On the other hand, encapsulation exacerbates the complexity of behavioral changes [22] when new crosscutting requirements have to be realized across the components of an existing program. To facilitate change while reaping the benefits of modularization in design, we will extend the work presented in this paper in the following directions: -Sound polynomial-time heuristics. We will concentrate on devising polynomial-time heuristics that reduce the complexity of synthesizing safety at the expense of completeness. That is, if heuristics succeed in generating a redesigned program, then the generated program will capture the new safety property while preserving liveness. However, such heuristics may fail to generate a redesigned program while one exists.
-Sufficient conditions. We will identify conditions under which safety can be synthesized in polynomial time. Specifically, we would like to address the following questions: (i) What kinds of inter-component topologies (i.e., read/write restrictions) should a program have such that a new safety requirement can be captured in it efficiently? (ii) For which types of programs and safety specifications the complexity of synthesizing safety is polynomial? -Backtracking. We will implement a backtracking algorithm for synthesizing safety under limited observability. While we showed that it is unlikely that safety can efficiently be synthesized under limited observability, in many practical contexts the worst case exponential complexity may not be experienced. Thus, we expect that a backtracking algorithm can explore the entire state space in a reasonable amount of time. Moreover, we will implement a parallel version of the backtracking algorithm that will benefit from randomization for search diversification. -An extensible software framework. We will develop a framework that provides automated assistance in synthesizing safety. Such a framework will include a repository of reusable heuristics that facilitate the synthesis of safety in an automated fashion. Two categories of users can benefit from our extensible framework, namely, (1) developers of heuristics who will focus on designing new heuristics and integrating them into our framework, and (2) mainstream programmers who will use the built-in heuristics to capture new safety properties in programs.