Formal Aspects of Computing A verification-driven framework for iterative design of controllers

Controllers often are large and complex reactive software systems and thus they typically cannot be developed as monolithic products. Instead, they are usually comprised of multiple components that interact to provide the desired functionality. Components themselves can be complex and in turn be decomposed into multiple sub-components. Designing such systems is complicated and must follow systematic approaches, based on recursive decomposition strategies that yield a modular structure. This paper proposes FIDDle–a comprehensive verification-driven framework which provides support for designers during development. FIDDle supports hierarchical decomposition of components into sub-components through formal specification in terms of preand post-conditions as well as independent development, reuse and verification of sub-components. The framework allows the development of an initial, partially specified design of the controller, in which certain components, yet to be defined, are precisely identified. These components can be associated with preand post-conditions, i.e., a contract, that can be distributed to third-party developers. The framework ensures that if the components are compliant with their contracts, they can be safely integrated into the initial partial design without additional rework. As a result, FIDDle supports an iterative design process and guarantees correctness of the system at any step of development. We evaluated the effectiveness of FIDDle in supporting an iterative and incremental development of components using the K9 Mars Rover example developed at NASA Ames. This can be considered as an initial, yet substantive, validation of the approach in a realistic setting. We also assessed the scalability of FIDDle by comparing its efficiency with the classical model checkers implemented within the LTSA toolset. Results show that FIDDle scales as well as classical model checking as the number of the states of the components under development and their environments grow.


Introduction
Software systems are usually comprised of multiple components-portions of the system that provide a desired functionality. In large and complex systems, components themselves can be complex, and decomposed into multiple sub-components. Hence, especially when large systems are considered, system design must follow systematic approaches, based on recursive decomposition strategies that support the development of modular structures. A good decomposition and a careful specification should allow sub-components to be developed in isolation by different members of the development team or be delegated to third parties [Par72a,Par72b]. It should also be possible to reuse off-the-shelf components or delegate development of parts of the system to external service providers [PBKS07,PBvDL05,ABKS16,CH01]. In essence, software development can often be viewed as a distributed endeavor, where different decentralized developers (internal engineers, subcontractors, component and service providers) are coordinated by the organization responsible for the entire system. The main problems of distributed development are in the integration phase, when separately validated components are composed with the other parts of the system and checked for overall correctness. In practice, software failures in the integration phase may lead to expensive and painful changes that may affect the components, the rest of the system, and even lead to changes in the modular structure.
In this article, we focus on the iterative and incremental design of components that abstractly behave as controllers. This term is commonly used to denote components that interact with a complex environment-which may include both physical devices and humans-through events. The controller processes the events generated by the environment and generates events to control it. In particular, we focus on the provably correct iterative and incremental development of complex, modular controllers. By this we mean that that component integration is safe and does not require any rework. It guarantees overall correctness by construction.
Recently, several researchers [vBFH+14,tBRdV16] focused on synthesis as a way to obtain correct-byconstruction components. These techniques are tremendously useful for in-house development of small components or development of individual components. Yet, they are not appropriate for many real-world scenarios, due to their inability to support iterative and incremental development which becomes necessary when the problem is too large to be handled in a single step. In addition, they do not support component reuse. For these reasons, although significant advances have been made in the direction of synthesis, the fully automated approach based on synthesis is not yet (and perhaps will never be) able to produce complex components. A more viable solution is to use synthesis activities in the design process as a support to human effort [SL08,SL13]. On the other side of the spectrum, approaches presented in the literature [BG99,CDEG03,MSG16,MSG17,BMS+17] provide support for model-checking and top-down refinement of partial models with the goal of preserving correctness. However, while these techniques guarantee correctness at each development stage, they do not explicitly address the problem of decentralized development and bottom-up integration, which are needed to support iterative and incremental development of real-world components. This is the problem we tackle in this work in a detailed and actionable manner.
We believe that the complete automation of complex components development is both impossible and undesired. Rather, we envision a systematic and formally verified design process where the construction of the overall structure of a complex controller and the various development steps require insight and experience which are human, not machine characteristics [SL08]. This suggests the need for a framework that capitalizes on the synergy between humans and machines for supporting distributed incremental development, by providing tools to enhance (and verify) the human work at each step of the development. In particular, the framework should provide several types of support: S1. Modeling support for design activities performed by humans. Novel tools for software development should help humans with modeling formalisms that effectively support components design. This includes support in the contexts in which software components are produced by first creating an initial partial high-level model of a component, where portions of the system that should be later defined are clearly identified, and then developing a detailed model of the behavior of the system for the partially specified portions. The tools should support (i) the description of the environment in which the component will be deployed, (ii) the specification of its required properties, (iii) the creation of the initial (partial) structure of the component, and (iv) the design of the component behavior in the portion of the component that are left unspecified.
S2. Model analysis support. As developers produce models of their components, they require automatic support to check their designs. Such support should (j) check whether the properties of interest can be satisfied by refining unspecified parts; (jj) check whether the initial partial design satisfies a set of properties of interest. The first check allows developers to verify whether it is possible to refine unspecified parts in a way that guarantees the satisfaction of the property of interest. This is a necessary requirement for enabling distributed development. The second check is performed after the contracts of the unspecified parts are defined. It allows the verification of whether respecting the given contracts guarantees satisfaction of the properties of interest. If the answer to the latter question is negative, further information that may help the user in fixing the errors, e.g., some form of counterexamples, should be provided.
S3. Support for iterative and incremental development of unspecified parts. When complex components are considered, it is desirable to first define a high level behavior of the component, leaving some parts temporarily unspecified, and then develop the unspecified parts or reuse existing off-the-shelf sub-components, or even delegate provision of the functionality to an external service provider. To enable this type of development, there is a need for developers to precisely describe what the unspecified parts should do.
S4. Support for integrating (sub-)components. When (sub-)components associated with the unspecified parts are created and delivered, they must be integrated in the original partially specified design. Integration is a process that replaces the unspecified parts with their actual design. A desired property of the framework we aim to develop is that no work (manual or automatic) should be performed at the integration level.
In this paper, we propose a unified framework called FIDDle (a Framework for Iterative and Distributed Design of components). FIDDle provides a set of tools and techniques for iterative and incremental verificationdriven component development. The framework is not based on any specific component models, like the ones commonly adopted by industry (such as Java Beans, Microsoft's COM family, or others). It is positioned at a higher and more abstract level, and assumes components to be fragments of functionality modeled as state machines. The framework supports a formal specification of global properties, a decomposition process and a specification of component interfaces by providing a set of tools to guarantee correctness of the different artifacts produced during the process. The capability of FIDDle to approximate complex designs by contracts and to replace a prototypical implementation with a more sophisticated one at a later stage fosters decomposition of complex designs and component reuse. Specific novel contributions of FIDDle are: 1. a new formalism, called Interface Partial Labeled Transition System (IPLTS), for specifying components through a decomposition that encapsulates sub-components into unspecified black-box states; 2. an approach to specify the expected behavior of black-box states via pre-and post-conditions expressed in Fluent Linear Time Temporal Logic (FLTL); and 3. a notion of component correctness and a local verification procedure that guarantees preservation of global properties once the components are composed.
We also report on the evaluation of FIDDle on a realistic case study obtained by reverse-engineering the executive module of the Mars Rover developed at NASA [GPB02,CGP03,GPB05]. Scalability is evaluated by considering randomly-generated examples.
FIDDle was first presented in [MSCG18]. This paper extends the work in [MSCG18] in several directions: • it presents a complete formal treatment of the work, including proofs of all lemmas and theorems; • it provides a detailed description of the algorithms; • it shows how the presented approach can be applied recursively; • it provides a thorough comparison with related work; • it describes the FIDDle tool support; • it provides additional detail of our evaluation.
The rest of the paper is organized as follows. Section 2 describes our running example. Section 3 provides an overview of FIDDle. Section 4 gives the necessary background. Section 5 describes the semantics for FLTL on finite traces. Section 6 presents Interface Partial Labeled Transition Systems. Section 7 defines a set of algorithms for reasoning on partial components and describes their implementation. Section 8 reports on an evaluation of the effectiveness and scalability of the proposed approach. Section 9 compares FIDDle with related approaches, and Sect. 10 concludes the paper.
The p&d system supports furniture purchase and delivery. The system allows users to check whether certain items are present, and to order the desired product or cancel the order.
To provide this functionality, the p&d system uses two existing web services, which implement the furnituresale and the shipping. The behavior of the furniture-sale service is described in Fig. 1a through a simple state machine. The service is initially in the state 1. The transition labeled with the action prodInfoReq allows the furniture-sale component to be queried to check the presence of some furniture. The transition labeled with the action infoRcvd indicates that the information regarding the furniture is provided. Finally, transitions labeled with prodReq and prodCancel indicate that the furniture is requested or the order is canceled.
The behavior of the shipping service is described in Fig. 1b. The transition labeled with shipInfoReq allows the shipping component to be queried to check the presence of some furniture. The transition labeled with costAndTime indicates that the information regarding the cost and time of the delivery is provided. Transitions labeled with shipReq and shipCancel indicate that the shipping is being requested and that the order is canceled, respectively.
The desired interactions of the users with the yet-to-be-defined component are described in Fig. 1c. The transition labeled with userReq indicates that the user performs a request to the system. The transition labeled with offerRcvd indicates that the user receives the desired information (furniture presence and shipping information). Based on this information, the user can choose whether to accept or refuse the offer. This is represented through the transitions labeled with the actions userAck and userNack. The system then has to confirm to the the user that her choice has been correctly processed via transitions labeled with the actions respOk and reqCanc.
The goal of the development team is to design a component, referred in the following as the p&d component, which acts as a controller interacting with the user and the two services in order to satisfy the user requests. The furniture-sale, the shipping service and the user represent the environment within which the component under development should operate. The final design of the p&d component must ensure that the controller, when plugged into its environment, will satisfy a set of properties of interest, reported in Fig. 1d. For example, in the final system, ship and product info should not be provided to the user if a request has not been issued. The development team decides to adopt a top-down development approach, which first creates an initial, partial and preliminary high-level description of the system where the still-to-be-refined parts of the system are explicitly indicated. The unspecified parts of the component are refined into sub-components, whose design and implementation are delegated to third-party developers, who receive a contract that should be satisfied by the sub-component. It is strongly desired that no rework be performed during the integration phase. Thick-dashed bordered components are currently supported by the theory presented in this paper, but they are still not fully implemented. Thin-dashed bordered components are not discussed in this work

Overview
FIDDle is a verification-driven environment supporting iterative and incremental controller developments, as described in Sect. 1. A high-level view of FIDDle is shown in Fig. 2. FIDDle allows controllers to be modularly and incrementally developed in a distributed manner, through a set of development phases in which the human insight and experience are exploited to achieve a verified modular structure (rounded boxes labeled with a designer icon and a recycle symbol indicate design or reuse, respectively) and phases in which automated support is provided (squared boxes labeled with a pair of gearwheels). Automatic support is provided to verify the current state of the design, integrate synthesized or off-the-shelf components, decentralize component development to third parties, and check whether integrated components correctly fit into the overall design. FIDDle structures controller developments according to a set of phases described in the following.

Creating an initial component design
This phase is identified in Fig. 2 with the symbol 1 . FIDDle provides modeling support for design activities performed by humans and analysis support for design validation.
FIDDle provides suitable formalisms to specify requirements and to model behavior of the controller and of its (sub-)components (step S1 in Sect. 1). The development team formalizes the component's desired properties through the requirements specification language and designs an initial, high-level structure of the component. Components are modeled using a state-based formalism that can clearly identify sub-components, represented as black-box states, whose internal design is delayed to a later stage or split apart for distributed development by other parties. In the following, we refer to other (non black-box) states as "regular". Black-box states are enriched with an interface that provides information on the universe of events relevant to the black box. They are also decorated with pre-and post-conditions that allow distributed teams to develop sub-components without the need to know about the rest of the system. The contract of a black-box state consists of its interface and the pre-and post-conditions. In the p&d example, the environment (assumed as given) in which the p&d component will be deployed is composed by the furniture-sale component (Fig. 1a), the shipping component (Fig. 1b) and the user (Fig. 1c). A possible initial design for the p&d component is shown in Fig. 3b. It contains the regular states 1 and 3 and black-box states 2 and 4. State 1 is the initial state. Whenever a userReq event is detected, the component moves from the initial state 1 into the black-box state 2, which represents a sub-component in charge of managing the user request. An event offerRcvd which indicates that an offer is provided to the user labels the transition to state 3. The interface of the black-box states 2 and 4 and their pre-and post-conditions are shown in Fig. 3c. The interface indicates that events prodInfoReq, infoRcvd, shipInfoReq and costAndTime can occur while the component is in the black-box state 2. Pre-and post-conditions need to be provided by the developers. Pre-conditions specify properties that hold up to entering the corresponding black-box state and post-conditions specify properties that should be ensured by black-box states. Both of them can be used in the analysis: whether the finite behaviors reaching the black-box state guarantee satisfaction of the pre-conditions and whether the black-box state can be replaced by their post-conditions to verify the validity of properties of interest. The pre-and post-conditions are discussed in detail in this section.
FIDDle supports the designer by checking properties of the design at different stages of development (step S2 in Sect. 1). The realizability checker confirms the existence of a realizable component that can be integrated to complete a partially specified component and ensures satisfaction of the properties of interest. If such a component does not exist, the designer needs to redesign the partially-specified component. The well-formedness checker verifies that both the pre-and the post-conditions of black-box states are satisfiable. Finally, the model checker verifies whether the (partial) component (together with its contract) guarantees satisfaction of the properties of interest.
In the p&d example, the model checker identifies a problem with the partial solution sketched in Fig. 3b. No matter how the black-box state 2 is to be defined, the p&d component cannot satisfy property P4 since every time reqCanc occurs it is preceded by usrAck. This suggests a re-design of the p&d component, which may lead to a new model, shown in Fig. 3d. This model includes two regular states: state 1, in which the component waits for a new user request, and state 3, in which the component has provided the user with an offer and is waiting for an answer. The user might accept (userAck) or reject (userNack) an offer and, depending on this choice, either state 4 or 5 is entered. States 2, 4 and 5 are black-box states, to be refined later.
To support iterative and incremental development of unspecified parts, FIDDle allows designers to specify pre-and post-conditions for the black-box states (steps S3 and S4 in Sect. 1). In the p&d example, pre-and postconditions of the black-box state 2 specify that there is a pending user request, and that cost, time and product information are collected. Pre-and post-conditions of the black-box state 4 specify that infoRcvd has occurred after the user request, and both a product and shipping requests are performed. Finally, pre-and post-conditions of the black-box state 5 specify that infoRcvd has occurred after the user request and before entering the state, and both the product and the shipping requests are canceled when leaving the state. This model is checked using the verification tools; since it passes all the checks, it can be used in the next phase of the development.
The design team may choose to refine the component or distribute the development of unspecified subcomponents (represented by black box states) to other (internal or external) development teams. In both cases, the sub-component can be designed by only considering the contract of the corresponding black-box state. Each team can develop the assigned sub-component or reuse existing components.

Sub-component development
This phase is identified in Fig. 2 with the symbol 2 . During sub-component development, FIDDle provides support to the modeling activities performed by humans (step S1 in Sect. 1). In the p&d example, each team can design the assigned sub-component using any available technique, including manual design (left side), reusing of existing sub-components (right side) or synthesizing new ones from the provided specifications (center).
To support iterative and incremental development of unspecified parts and safe integration of the developed of sub-components, FIDDle requires the developed sub-components to satisfy some constraints, namely, 1. given the stated pre-condition, the sub-component has to satisfy its post-condition, and 2. the sub-component should operate in the same environment as the overall partially specified component.
Sub-component development can itself be an iterative process (see Sect. 3.4) but neither the model of the environment nor the overall properties of the system can be changed during this process. Otherwise, the resulting sub-component cannot be safely and automatically integrated into the overall system.
In the p&d example, development of the sub-component for the black-box state 2 is delegated to an external (third-party) contractor. Candidate sub-components are shown in Figs. 3e-3f. In the case of Fig 3e, the component requests shipping info details and waits until the shipping service provides the shipment cost and time. Then it queries the furniture-sale service to obtain the product info. In the case of Fig 3f, the shipping and the furniture services are queried, but the sub-component does not wait for an answer from the furniture-sale. Since these candidates are fully defined, the well-formedness check is not needed. Yet, the substitutability checking confirms that of these, only the sub-component in Fig. 3e satisfies the post-condition in Fig. 3c.

Integration of sub-components
This phase is identified in Fig. 2 with the symbol 3 . FIDDle supports integration of the development of subcomponents and guarantees that if each sub-component is developed correctly w.r.t. the contract of the corresponding black-box state, the component obtained by integrating the sub-components is also correct (step S4 in Sect. 1). In the p&d example, the sub-component in Fig. 3e passes the substitutability check and can be a valid implementation of the black-box state 2 in Fig. 3d. Integration is shown in Fig. 3j.

Recursive application of FIDDle
FIDDle can be applied recursively, allowing to distribute development of portions of the sub-components (e.g., to third-party vendors). This is indicated in Fig. 2 with the symbol 2 .
For example, Fig. 3g shows an initial partial design of the sub-component associated with state 5 of the p&d example. This partially-specified sub-component requires the system to increase the count of canceled orders, enters the black-box state 5.2, and finally cancels the order. FIDDle provides automated support for the subcomponent design. The well-formedness confirms that the pre-and the post-conditions of black-box states are satisfiable. The substitutability checking notifies the designer that the sub-component in Fig. 2 does not ensure the satisfaction of its post-condition. Indeed, there is no guarantee that shipping of the product is canceled (i.e., the ShipCancel event occurs). The post-condition for the black-box state 5.2, shown in Fig. 3h, which ensures that the shipping is performed before the black-box state 5.2 is exited by the system, guarantees that the sub-component passes the substitutability checking. In turn, the black-box state 5.2 is decomposed into the sub-component represented in Fig. 3i. This component is completely specified. Upon its entry, the counter of the canceled shipping orders is incremented and then the shipping is canceled. When it is entered, the counter of the canceled shipping orders is incremented by one. The substitutability checking confirms that the sub-component is substitutable and can be integrated within the black-box state 5.2. This iterative process can be applied for any partially specified subcomponent.
To conclude, FIDDle allows the iterative and incremental distributed development of controllers and provides the support described in Sect. 1. FIDDle relies on an extension of Labeled Transition Systems (LTS) that allows the representation of incompleteness and offers the possibility of defining an initial modular incomplete structure. It also allows distributing the design of the missing components and offers automatic support for the verification of the different parts and for substitutability analysis of components within a partially defined structure.

Background
This section contains background knowledge and definitions used in the rest of the paper. Section 4.1 introduces LTS. Section 4.2 provides a high level description of Büchi automata (BA). Section 4.3 introduces Fluent Linear Time Temporal Logic (FLTL). Finally, Sect. 4.4 outlines a procedure for verifying the satisfaction of FLTL properties on LTS.

Labeled transition systems
Labeled Transition Systems are a specific type of state machines commonly used to model software components and their environments.
A verification-driven framework for iterative design of controllers Definition 4.1 [Kel76] Let Act be the universal set of observable events and let τ be an unobservable local event.
• Q is a finite set of states, is an LTS f where the set of final states is not defined.
For example, Fig. 3e contains an LTS f with states 2.1, 2.2, 2.3, 2.4 and 2.5, where 2.1 and 2.5 are its initial and final states, respectively. Transitions specify how the LTS f evolves by firing transitions labeled with events shipInfoReq, costAndTime, prodInfoReq and infoRcvd. Fig. 1a contains an LTS for modeling a furniture-sale component. The LTS is defined over the states 1, 2 and 3, where state 1 is initial. Transitions specify how the LTS evolves by firing transitions labeled with events prodInfoReq, infoRcvd, prodCancel and prodReq.
Given a state q (of an LTS or an LTS f ), let (q) − and (q) + denote its incoming and outgoing transitions, respectively, and let (q) denote the union of the incoming and outgoing transitions of q. For example, in the LTS in Fig. 1a, (1) + {(1, prodInfoReq, 2)}. Given a transition δ (q 1 , e, q 2 ), we use δ − to indicate its source q 1 , δ + to indicate its destination q 2 , and δ e for its label e. For example, for the transition δ (2, infoRcvd, 3) of the LTS in Fig. 1a, δ − 2, δ + 3 and δ e infoRcvd.
and q n+1 ∈ Q f , is a finite execution of F , and π e 0 , e 1 , . . . , e n is a trace of F . Let L Q, q 0 , A, be an LTS. An infinite sequence q 0 , e 0 , q 1 , e 1 , . . ., such that for every i ≥ 0, (q i , e i , q i+1 ) ∈ , is an infinite execution of L, and π e 0 , e 1 , . . . is a trace of L.
Traces of an LTS f are finite and reach final states representing finite computations. For example, shipInfoReq, costAndTime, prodInfoReq, infoRcvd is the only finite trace of the LTS f in Fig. 3e. LTS traces are infinite, i.e., the system is not designed to stop. For example, prodInfoReq, infoRcv, prodReq repeated infinitely often is an infinite trace of the LTS in Fig. 1a.
In the rest of this paper, when not specified, we assume that LTS f and LTS are minimized with respect to bisimulation. Intuitively, given an LTS f (respectively, an LTS), the minimization procedure removes τ actions and generates a LTS f (respectively, an LTS) with the same behavior (for additional information about minimization, refer to [MK99]).
Parallel composition is a symmetric operator that takes two LTS f and computes a resulting one by synchronizing on shared events and interleaving the others.
where is the smallest relation that satisfies the following rules: where l ∈ A M ∪ A N ∪ {τ }, s and s are states in Q M , and t and t are states of Q N . Parallel composition of two LTS is defined identically, except that final states are excluded.
Rules (1) and (2) indicate that there is an interleaving on non-shared events and Rule (3) that there is a synchronization on shared ones.
For LTS, hiding is defined identically, except that final states are excluded.
For example, if the hiding operator is applied to the LTS in Fig. 1a w.r.t. the set {prodInfoReq}, the transition from state 1 to state 2 labeled with prodInfoReq is replaced by one labeled with τ .

Büchi automata
Büchi Automata are a reference formalism commonly used in the verification community.
Definition 4.6 [Büc90] Let AP be a finite set of atomic propositions. A Büchi automaton (BA) defined over AP is a tuple B Q, q 0 , A, , Q a such that: • Q is a finite set of states; • q 0 is the initial state; • A ⊆ AP is a finite set of atomic propositions; and there exists a state q i ∈ Q a that appears in the sequence infinitely often.
It is possible to check (using a standard procedure described in [Büc90]) whether a given BA has no infinite trace. We indicate this check by a function checkEmptiness(B ) which returns true if the automaton accepts no infinite traces and thus is empty, and false otherwise.
An LTS can be converted into a BA which accepts exactly the same traces: The BA contains the same states and transitions as the LTS and all of its states are accepting. This ensures that, if a trace of the LTS is also a trace of the BA, it will enter at least an accepting state of the BA an infinite number of times, since the set of states is finite. Every infinite trace of the BA is an infinite trace of the LTS by construction. We call LTS2BA the procedure for converting an LTS into a BA. This procedure copies all the states and transitions from the LTS to the BA and adds all the states of the LTS in the set of the accepting states of the BA. For example, the BA obtained from the LTS in Fig. 1a has the same states and transitions, and states 1, 2 and 3 are also accepting.
The intersection operator computes the synchronous product of two automata: given two BA M and N , it computes a BA whose traces are the intersection of the traces of M and N . 1. (q m , e, q m ) ∈ M and (q n , e, q n ) ∈ N ; 2. if x 0 and q m ∈ Q a,M then y 1; 3. if x 1 and q n ∈ Q a,N then y 2; 4. if x 2 then y 0; 5. otherwise, y x .
The states of the system contain all the possible combinations of the states of the automata M and N and the values {0, 1, 2}. A transition from a state q m , q n , x to a state q m , q n , y labeled with e is in the intersection if both M and N can move from q m (resp. q n ) to q m (resp. q n ) on a transition labeled with e. The third component in each state is responsible for guaranteeing that an infinite trace of the intersection automaton is present if and only if it corresponds to an infinite trace of M (resp. N ) in which an accepting state is visited infinitely often. The third component is initially 0, and changes from 0 to 1 and from 1 to 2 whenever an accepting state of M and N is entered, respectively. After an accepting state of N is visited, it is set back to 0. This construction guarantees that every infinite trace of the intersection automaton is an infinite trace of both M and N , i.e., where accepting states of M and N are visited infinitely often.

Fluent linear time temporal logic
It is often non-trivial to express LTL properties directly in terms of events, especially when the interest is to define intervals among the occurrence of different events and relationships between them. Thus, in this work, we consider FLTL [San95, CDGV02, GM03] as a logic to express properties of the system.
A fluent is a property that holds after an event occurs and ceases to hold when it is terminated by another event.
Definition 4.8 [San95] A fluent Fl is a tuple I Fl , T Fl , I nit Fl where I Fl ⊂ Act is the set of initiating events, T Fl ⊂ Act with I Fl ∩ T Fl ∅ is the set of terminating events and I nit Fl ∈ {true, false} is the initial valuation.
A fluent may be true or false. The initial value of the fluent is specified using the attribute I nit Fl [MS99]. A fluent is true if it has been initialized by an event e 1 ∈ I Fl at an earlier time point (or if I nit Fl true, i.e., it was initially true) and has not yet been terminated by another event e 2 ∈ T Fl ; otherwise, it is false. For example, the fluent PR {prodInfoReq}, {prodCancel, prodReq}, false , representing the fact that the furniture-sale component is processing a request, is initially false. It becomes true from the moment when the event prodInfoReq occurs, i.e., a request is received, until the moment in which the event prodCancel, which cancels the order request, or the event prodReq, which confirms the order request, occur.
Fluents also implicitly allow developers to specify properties on event occurrence. The occurrence of an event e ∈ Act can be considered by defining a fluent where the initial set of actions is the singleton {e} and the terminating set contains all other actions in the alphabet of the system, i.e., Act \ {e}. In the following, we use the notation F Event to indicate a fluent that is true when the event with label event occurs. Definition 4.9 Given a set of fluents , an FLTL formula φ has the following syntax: where Fl ∈ (next), (eventually), (always), U (until) and W (weak until) are the standard LTL operators.
For example, the FLTL property (PR) states that eventually the furniture-sale component will process a request. The FLTL encodings of the properties P1, P2, P3 and P4 are shown in Fig. 3a. Note that, for completeness, Definition 4.9 provides the complete syntax of FLTL formulae, including the operators (eventually), (always) and W (weak until), but all the FLTL formulae can be expressed using only the operators and U.
The semantics of FLTL formulae is given by considering infinite sequences of fluents associated with infinite traces of an LTS. We begin by constructing an FLTL interpretation of an infinite trace.

Definition 4.10 Let Act τ
Act ∪ {τ }. Given a set of fluents and an infinite trace π e 0 , e 1 , . . . over Act τ , an FLTL interpretation of π is an infinite sequence f 0 , f 1 , . . . over 2 which assigns to each index i of π the set of fluents that hold in position i . Formally, ∀ i ∈ N, ∀ Fl ∈ , Fl ∈ f i if and only if either of the following conditions hold: • I nit Fl true and (∀ k ∈ N, k ≤ i , e k ∈ T Fl ); • ∃j ∈ N such that (j ≤ i ) and (e j ∈ I Fl ) and (∀ k ∈ N, j < k ≤ i , e k ∈ T Fl ).
Consider an infinite trace of the LTS in Fig. 1a, in which the events prodInfoReq, infoRcv, prodReq are repeated infinitely often, and a set of fluents {PR}. The infinite interpretation of this trace is an infinite sequence in which the the set {PR} is assigned to each index i where events prodInfoReq or infoRcv occur and the set {} is assigned to each index j where the event prodReq occurs. In this sequence, the fluent PR holds from the time of occurence of the event prodInfoReq until occurence of prodReq (that time point itself is excluded).
The FLTL infinite semantics specifies when a formula φ is satisfied by the FLTL interpretation of an infinite trace.

Definition 4.11
Let π e 0 , e 1 , . . . be an infinite trace, ρ f 0 , f 1 , . . . be its FLTL interpretation and φ be an FLTL formula. The FLTL infinite semantics of φ over ρ is defined as follows: where ρ i indicates the infinite sub-trace of ρ starting at position i .
The semantics of (eventually), (always) and W (weak until) is not presented since it is standard and can be deduced from the semantics of the operators and U.
Given an infinite trace π and a formula φ, we say that π satisfies φ (denoted π | φ) if and only if the FLTL interpretation ρ of π satisfies φ (i.e., ρ | φ). For example, the infinite trace of the LTS in Fig. 1a in which the events prodInfoReq, infoRcv, prodReq are repeated infinitely often satisfies the FLTL property (PR). Note that since FLTL is a natural extension of LTL, it is closed under negation. The proof can be obtained, for example, by applying the procedure described in [YPA06].

Verifying FLTL properties on LTS
Verification of an FLTL property φ on an LTS L aims at checking whether φ holds on L. We first define the notion of satisfaction of an FLTL φ on an LTS L and then review a procedure for checking an FLTL φ on an LTS L.
Definition 4.12 Let L be an LTS and φ be an FLTL formula. We say that the LTS L satisfies the FLTL formula φ, i.e., L | φ, if for every infinite trace π of L, it holds that π | φ. Fig. 1a and the fluent PR. The FLTL formula PR holds on this LTS. We now recall a procedure to check an FLTL formula φ on an LTS L. Note that the infinite traces of the LTS are defined over the set of events A, while the formula is defined over the set of fluent propositions . This gap has been handled by introducing fluent automata and synchronizer automata. These automata are used in the verification procedure to bind event occurrence with the fluent satisfaction. We first present fluent automata and synchronizer automata and then describe how they are used in the verification procedure.

Consider the LTS in
A fluent automaton relates the occurrence of events with the satisfaction of a given fluent.

Definition 4.13
Let be a set of fluents and Fl= I Fl , T Fl , I nit Fl be a fluent in . Its fluent automaton is an LTS F Q, q 0 , A, , where: The automaton has two states: q t , where the fluent holds, and q f , where it does not. The automaton moves from q t (resp. q f ) to q f (resp. q t ) if an event from its initiating (resp. terminating) set occurs.  If a transition labeled with PR is fired, the fluent PR holds, while if a transition labeled with ¬ PR is fired, the fluent PR does not hold. As expected, infinite traces of the automaton indicate that PR holds only after an event prodInfoReq and before events {prodCancel, prodReq}. Furthermore, PR does not hold initially and becomes false after occurence of either of the events prodCancel, prodReq and before a transition labeled with prodInfoReq is fired.
While the fluent automaton allows taking a transition labeled with a fluent (e.g., PR in Fig. 4) or its negation (e.g., ¬PR in Fig. 4), nothing forces these transitions to actually take place. Instead, we aim to generate an automaton that is forced to alternate the execution of transitions labeled with events and fluents. This automaton is obtained by combining the fluent automaton with a special synchronizer automaton, which we define below.
Definition 4.14 Let be a set of fluents and Act be a set of events, such that for all Fl ∈ , I Fl ⊆ Act and T Fl ⊆ Act , the synchronizer automaton is an LTS Sync Q, q 0 , A, , where The synchronizer automaton has two states: q 0 and q 1 . It moves from q 0 to q 1 by firing a transition labeled with an event, and from q 1 to q 0 by firing a transition labeled with a fluent. Thus, it alternatively executes transitions labeled by events and by fluents. For example, the synchronizer automaton associated with the fluents PR and FR and the set of events A {prodInfoReq, prodCancel, prodReq} is shown in Fig. 5.
Algorithm 1 Checks an FLTL formula on an LTS.
return checkEmptiness(I) The synchronizer and the fluent automata are used to verify FLTL formulae on LTS via a procedure described in Algorithm 1, in which the classical model checking algorithm presented in [CGP99] is enriched to deal with FLTL instead of LTL and the combination of LTS and BA. The procedure takes as parameters the LTS L, the formula φ, the fluent automata F 1 , F 2 , . . . F n , and the synchronizer Sync. It returns true if the property φ is satisfied, and false and a counterexample if it is not. The algorithm translates the negation of the formula into a BA B by using a standard LTL2BA procedure [VW94] (Line 2). Then, it computes the parallel composition between the LTS L, the fluent automata F 1 , F 2 , . . . F n and the synchronizer Sync (Line 3). In the traditional automata-based approach, the next step is to compute the intersection between the BA representing the system and the BA representing the negation of the LTL property to check. Since in our case, the model is an LTS, it needs to be converted in a BA via the function LTS2BA (Line 4). Moreover, as the transitions of the obtained BA are labeled with fluents and transitions of the model obtained in Line 3 alternate fluents and events, to correctly compute the intersection between the model and the formula (Line 6), we need to add a self-loop labeled with the events in Act to all the states in B (Line 5). The reason is that the intersection that is computed in the next step of the algorithm (Line 6) synchronously fires transitions of the automata B and P . Thus, transitions labeled with events of P can only fire if the BA obtained from the property also contains transitions labeled with events. Essentially, the BA P fires its transitions depending on the behavior of the system and on the relation between events and fluents. The intersection extracts from those behaviors the ones that also satisfy the property of interest as specified by the fluent-labeled transitions present in the automaton B . The function checkEmptiness is then used to verify whether the automaton I is empty.

Fluent linear time temporal logic and finite traces
Section 4 described how FLTL formulae are evaluated on infinite traces. However, it might be necessary to evaluate satisfaction of formulae on finite traces, e.g., recall that pre-and post-conditions introduced in Sect. 3 specify properties over traces that reach unspecified components. In this section, • we define finite semantics of FLTL formulae, referred to as FLTL f (Sect. 5.1); • we present a procedure for checking FLTL f formulae on LTS f (Sect. 5.2). Our procedure reuses the algorithm for checking the satisfaction of FLTL formulae on LTS presented in Sect. 4.4; • we present a procedure for taking an FLTL f formula φ and synthesizing from it an LTS f that exhibits exactly those finite traces that satisfy φ (Sect. 5.3). This procedure forms one of the main tools used in FIDDle for providing automatic support for iterative design of components, as described in Sect. 7.

FLTL f semantics on finite traces
Interpretation of FLTL formulae on finite traces is denoted by FLTL f . FLTL f syntax is the same as FLTL and its semantics is inspired by [DGV13]. We begin by defining the interpretation of a fluent Fl on a finite trace.
Definition 5.1 Let be a set of fluents, and π e 0 , e 1 , . . . , e n be a finite trace over Act .
. . , f n over 2 which assigns to each index i of π the set of fluents that hold in position i for 0 ≤ i ≤ n, by following the same rules as specified in Definition 4.10.
Consider the finite trace shipInfoReq, costAndTime, prodInfoReq, infoRcvd of the LTS f in Fig. 3e and the fluent W {shipInfoReq, prodInfoReq}, {costAndTime, infoRcvd}, false , which is true when the system is waiting for some information. The fluent W becomes true when a request is performed by the component, i.e., a shipInfoReq or a prodInfoReq event occur, and becomes false when some information is received (costAndTime or infoRcvd occurs). The FLTL f interpretation of the trace shipInfoReq, costAndTime, prodInfoReq, infoRcvd is {W}, {}, {W}, {}.
We now use the interpretation of a finite trace to define the FLTL f semantics.

Definition 5.2
Let π e 0 , e 1 , . . . , e n be a finite trace, ρ f 0 , f 1 , . . . , f n be its FLTL f interpretation, and φ be a FLTL f formula. The FLTL f finite semantics of φ over ρ is as defined by Definition 4.11, with the exception of the operators and U defined as follows: where ρ i refers to the finite sub-trace of ρ starting at position i .
Intuitively, a formula preceded by the operator does not hold in the last position of the interpretation, since the operator forces the existence of the next position of the interpretation. A formula of the type (φ 1 ) U(φ 2 ) forces the fluent φ 2 to occur before reaching the position n of the interpretation. For example, the formula (W), where W is the fluent previously defined, does not hold on the finite trace shipInfoReq, costAndTime, prodInfoReq, infoRcvd. Given a finite trace π its FLTL f interpretation ρ and a formula φ, we say that π | φ if and only if ρ | φ.

Verifying FLTL f properties on LTS f
We begin by defining what it means for an LTS f L to satisfy an FLTL f formula, and then present a verification procedure that checks the satisfaction of an FLTL f formula φ on an LTS f L. We reduce this problem to checking an FLTL formula φ on an LTS L , where φ and L are obtained from φ and L. We begin by showing that checking whether an FLTL f formula φ holds on a finite trace π can be done by evaluating whether an equivalent FLTL formula φ holds on the infinite extension e(π ) of the trace φ.

Definition 5.3
Let π e 0 , e 1 , . . . , e n be a finite trace defined over the set of events Act τ such that end ∈ Act τ . Its infinite extension, e(π ) e 0 , e 1 , . . . , e n , {end} ω , is obtained by concatenating an infinite number of occurences of the event end to the trace π .

Definition 5.4 Let F be an LTS f and φ be an FLTL f formula. We say that the LTS
Consider the LTS f in Fig. 3e and the fluent W. The FLTL f formula W holds on this LTS f .

Definition 5.5
Let be a set of fluents defined over the alphabet Act τ , such that end ∈ Act τ , be a set of fluents defined over the alphabet Act τ ∪ {end}, φ be an FLTL f formula defined over , and φ be an FLTL formula defined over . φ is equivalent to φ if for every finite trace π , π | φ ⇔ e(π ) | φ .
We now want to define an operator FLTL f 2FLTL that, given an FLTL f formula φ, generates an equivalent FLTL formula φ .
Definition 5.6 Let be a set of fluents defined over the alphabet Act τ , such that end ∈ Act τ , END be the fluent {end }, Act τ , false , and φ be an FLTL f formula defined over . The operator FLTL f 2FLTL converts φ into an FLTL by applying the following rules: Let φ ¬W be an FLTL f formula, and π e 0 , e 1 , . . . , e n be a finite trace. We discuss the evaluation of the formula in the final position n of the trace. The formula ¬W is false in position n by Definition 5.2, as i < n is not satisfied. Let us consider the extension e(π ) of π . The FLTL f formula ((¬W) ∧ ¬END) obtained from φ by applying the function FLTL f 2FLTL is false in position n, as intended. This formula evaluates to true in position n only after adding the event end to the set of the terminating events of the fluent W.
Consider a finite trace π defined over the set of events Act τ , such that end ∈ Act τ , its infinite extension e(π ), and an FLTL f formula φ. We show that the problem of checking the satisfaction of φ can be reduced to checking its equivalent formula φ on e(π ).
Theorem 5.1 Let be a set of fluents, where END ∈ , φ be an FLTL f formula defined over the set , and φ be the formula constructed using the FLTL f 2FLTL procedure. The FLTL formula φ is equivalent to φ.
Proof Sketch We show that π | φ ⇔ e(π ) | φ holds in the base case, when φ is a fluent, and that it also holds when temporal operators are considered. C. Menghi et al. Consider the finite interpretation ρ of π e 0 , e 1 , . . . , e n and the infinite interpretation ρ of e(π ). For every Fl ∈ and position i such that i ≤ n, where n is the length of the finite trace, ρ i | Fl ⇔ ρ i | Fl by construction. Furthermore, for every Fl ∈ and position i such that i > n, ρ i | Fl and ρ i | Fl .
For operators ¬ and ∧, If i ≥ n, then, by Definition 5.2, ρ i | φ, but also ρ i | false by Definition 5.6 and the fact that END is true.
by Definition 5.6 and the fact that END is false. If i ≥ n, then, by Definition 5.2, Consider the finite trace shipInfoReq, costAndTime, prodInfoReq, infoRcvd, of the LTS f shown in Fig. 3e and its infinite extension shipInfoReq, costAndTime, prodInfoReq, infoRcvd, end ω . The satisfaction of the FLTL f formula φ (W ), where W {shipInfoReq, prodInfoReq}, {costAndTime, infoRcvd}, false , on the finite trace can now be checked by evaluating the satisfaction of the formula φ (W ∧ ¬END) on its infinite extension. We show that checking satisfaction of an FLTL f formula on LTS f can be reduced to checking the corresponding FLTL formula on an LTS.
Intuitively, F is replaced by adding a self-loop labeled with the event end to all of the final states of the LTS f . Consider for example the LTS f presented in Fig. 3e. The FLTL f formula φ (W ) can be checked by verifying that the formula φ (W ∧ ¬END) holds on the LTS obtained by an end self-loop to the state 2.5. In the rest of this paper, we refer to this procedure as CheckFLTL f onLTS f .
We now provide the proof of Theorem 5.2.
Proof Sketch The infinite traces of the LTS F are the infinite extensions of the finite traces of F ; thus, by Theorem 5.1, the proposed procedure is correct.

Synthesizing LTS f from FLTL f formulae
Given an FLTL f formula φ, we show how to construct an LTS f such that its finite traces are exactly those that satisfy formula φ.
Proof Sketch The subformula (END) forces the END fluent to eventually hold. The subformula (END → (END)) specifies that globally if the END fluent holds, it must hold in the next position. Since the set of the initiating events of the END fluent only contains the event end and the set of the terminating events is Act τ , event end must occur at some position n + 1, and in any position i ≥ n + 1.
We also define an operator that converts a BA into an LTS f and a procedure that removes τ -labeled transitions from a LTS f .
satisfies one of the following conditions: (i) e τ ; or (ii) (q i , τ, q i+1 ), (q i+1 , τ, q i+2 ), . . . (q j −2 , τ, q j −1 ), (q j −1 , e, q j ) and e τ . In essence, sequences of τ -labeled transitions that connect a state q i to a state q j −1 followed by a transition to a state q j labeled with some symbol e τ are replaced by a transition from q i to q j labeled with e. Consider, for example, the LTS in Fig. 6a. The procedure Remove τ generates the LTS in Fig. 6b. The transitions (1, τ, 2), (2, e, 3) are replaced by the single transition (1, e, 3), and (1, τ, 5), (5, e, 6) are replaced by (1, e, 6). Algorithm 2 describes a procedure for computing an LTS f model F whose finite traces satisfy the FLTL f formula φ. We discuss the steps of our algorithm using an example The algorithm then constructs a BA by conjoining the FLTL formula and the end formula φ end and applying the procedure LTL2BA (Line 3). In our example, the BA in Fig. 7a is computed from the FLTL formula (W ∧ ¬END) ∧ END ∧ (END → (END)). Then the algorithm computes the parallel composition of the BA obtained from the formula φ ∧ φ end and the BA obtained by applying the function LTS2BA to the parallel composition of the fluent and the synchronizer automata (Line 4), resulting in an automaton whose infinite traces satisfy the FLTL f formula, and interleaves the occurence of the fluents and the events. In our example, the fluent automata associated with the fluents W and END are shown in Figs. 7b and 7c, and the synchronizer is shown in Fig. 7d. A portion of the intersection between their parallel composition and the BA obtained from the FLTL formula φ ∧ φ end is shown in Fig. 7e. Then, Algorithm 2 converts the parallel composition into an LTS (see Definition 5.8) and hides transitions labeled with fluents and the event end. In our example, the transitions from 2 to 3, from 4 to 5, from 6 to 7, from 7 to 8, from 8 to 9, from 9 to 8 and from 12 to 13 in Fig. 7e are hidden, i.e., they are relabeled using the τ symbol. The final step, on Line 7, removes τ -transitions and returns. In our example, the LTS f for the FLTL formula φ (W ) is shown in Fig. 7f.
Theorem 5.3 Let φ be an FLTL f formula. Algorithm 2 generates an LTS f such that its finite traces are exactly those that satisfy the formula φ.
Proof Sketch We prove the correctness by construction. Line 3 forces each infinite trace of A to finish with an infinite sequence of END fluents (Lemma 5.1). Thus, the BA reaches an accepting state from which only transitions labeled with the END fluent can be fired. By Theorem 5.1, φ is equivalent to φ, so for every infinite trace extension e(π ), if π | φ ⇔ e(π ) | φ . Thus, the BA generated in Line 3 contains infinite traces that are extensions of finite traces π that satisfy the formula φ. Line 4 computes an automaton that interleaves fluents and events and ensures that the traces generated by the sequences of events satisfy the property φ, as described in Sect. 4.4. Then, the BA is converted into an LTS f (Line 5). Transitions labeled with fluents and the event end are hidden (Line 6). This procedure ensures, by construction, that the traces reaching the final states of the returned LTS f are exactly those traces that satisfy the formula φ.
return Remove τ (D) Fig. 8. The environment E obtained by computing the parallel composition of the LTS in Figs. 1a, 1b and 1c

Modeling notation
This section presents the modeling notation proposed in FIDDle to support the modular, distributed, and iterative development of software controllers. Section 6.1 describes how to model the environment in which the components under development will eventually be deployed. Section 6.2 describes how to provide a high-level model of the components. Section 6.3 describes how pre-and post-conditions can be added to the high level model to facilitate distributed development. Section 6.4 describes how unspecified components can be refined into sub-components by exploiting their pre-and post-conditions. In the rest of this section, we capitalize generic entities specified in a given modeling formalism and denote specific software development entities using caligraphic fonts. For example, a generic LTS can be indicated by L, while the LTS modeling the behavior of the environment is denoted by E.

Modeling the environment
The development workflow proposed in FIDDle (Sect. 3) assumes that a model of the environment is initially designed by developers (or provided by a third party) and is not changed during the iterative refinement rounds. FIDDle receives the model of the environment specified through an LTS. The LTS of the environment (E) can be obtained by composing several LTS using the parallel composition operator (Definition 4.4). Each of these LTS models is a component of the environment. For example, the LTS of the environment of the p&d example is obtained via the parallel composition of the LTS described in Figs. 1a, 1b and 1c. The complete model of the environment has 45 states and 174 transitions. A portion of the parallel composition is shown in Fig. 8. Since the alphabets of the three LTS are disjoint, all the transitions are interleaved.

Initial component design
We propose partial (finite) LTS (PLTS) as a formalism to support the high level design of a component under development. A Partial (finite) Labeled Transition System is an LTS (resp. LTS f ) where some states are "regular" and others are "black-box". Black-box states model portions of the component whose behavior still has to be specified. Each black-box state is augmented with an interface that specifies the universe of events that can occur in the black-box. Partial LTS are used to design an initial component model, partial finite LTS-to define sub-components (see Sect. 6.4).
• R is the set of regular states; • B is the set of black-box states; Let L Q, q 0 , A, be an LTS. A Partial Labeled Transition System (PLTS) is a structure P L, R, B , σ defined as above.
LTS (resp. LTS f ) are PLTS (resp. PLTS f ), where the set of black-box states is empty. For example, the initial design of a component that interacts with the furniture-sale, the shipping service and the user is represented in Fig. 3d. The interfaces of its black-box states are documented in Fig. 3c. The component is defined over the regular states 1 and 3, and the black-box states 2, 4 and 5. When a user request is received (event userReq), the black-box state 2 is entered. This black-box state represents an unspecified functionality for computing an offer to the user. The interface specifies that events prodInfoReq, infoRcvd, shipInfoReq and costAndTime can occur while the component is in the black-box state 2. The system exits this black-box state via a transition labeled with the event offerRcvd. After leaving the unspecified component, the system enters one of the black-box states: 4, if the user accepts the offer (event userAck) or 5, if it refuses it (event userNack). In turn, these black-box states represent unspecified components that are executed in response to a user request. The interfaces of the black-box states 4 and 5 specify that the events prodReq,shipReq and prodCancel, shipCancel can occur while the component is in the black-box states 4 and 5, respectively. (i) (q, e, q ) ∈ ( q, t , e, q , t ) ∈ S , and e ∈ A \ A D or e τ ; (ii) (t, e, t ) ∈ D ( q, t , e, q, t ) ∈ S , and one of the following is satisfied: (c) q ∈ B and e ∈ σ (q).
Rule (i) specifies that if the PLTS P fires the transition (q, e, q ) of and the event e does not belong to the set of events of A D or it is τ , P moves to q while the LTS D does not change its state. Rule (ii) states that the LTS D performs the transition (t, e, t ) while the PLTS P remains in state q if one of the following conditions hold: (a) the event e is not an event of P , (b) the event e is the τ event, (c) the PLTS is in a black-box state q and the event e belongs to the interface of q. Rule (iii) specifies that the PLTS P and the LTS D fire the transitions (q, e, q ) and (t, e, t ) in parallel if the event e is in the set of events of both P and D.
Consider the initial partial component design C modeled using the PLTS in Fig 3b and the interfaces of its black-box states documented in Fig. 3c. The parallel composition operator allows analyzing how C behaves when it is executed in its environment E, which, in turn, is an LTS produced by composing the LTS in Figs. 1a, 1b and 1c.

Adding pre-and post-conditions
A pre-condition is an assumption about the history of the system at the point when a given unspecified component is entered. A post-condition is a guarantee that is expected to be established by a given unspecified component. A contract of an unspecified component, represented as a black-box state in our formalism, consists of the black-box state interface and its pre-and post-conditions. Pre-and post-conditions are defined using FLTL f formulae, i.e., formulae over finite traces. Intuitively, a pre-condition pre(b) for a black-box state b must hold on any finite trace that reaches b. For example, the precondition of the state 4 of the PLTS of Fig. 3d, shown in Fig. 3c, states that globally, on the finite traces that reach state 4, if a user request has been detected, information from the user has been received. The post-condition of the black-box state 4 indicates that the sub-component that has to replace this state has to ensure that a product is requested from the furniture sale component and a shipping request is sent.
To effectively support developers in iterative design, we define what it means for a pre-and a post-condition to be satisfied by the current partial component and when a property of interest is satisfied by the current partial component. Pre-conditions specify properties that hold on finite traces of the system S that reach the blackbox state. Since the environment is fixed and does not change during the component development, semantics of pre-conditions for a black-box state b is defined by considering the parallel composition between the partial component under development C and its environment E. To reach this goal, we first define the notion of a finite trace of the parallel composition among a PLTS P and an LTS D that reaches a state q d of the PLTS, where the PLTS P represents the partial component P and the LTS D represents its environment E.
For example, considering the PLTS in Fig. 3d and the LTS in Fig. 1c, the finite trace obtained by performing a userReq event reaches the black-box state 2 of the PLTS.
We now show how to transform the LTS S C E into an LTS f S , denoted by LTS2LTS f (C, q d , L), so that S contains exactly the finite traces that reach the state q d .
Intuitively, the LTS f F is obtained from the LTS S P D by setting every state obtained by combining a state q d of P and one from the set Q D of the states of D and making it a final state of F .
Post-conditions specify which properties should be ensured by black-box states. To give their semantics, we begin by definining what it means to have traces of the system inside a black-box state.
Definition 6.6 Let L Q, q 0 , A, be an LTS, P L, R, B , σ be a PLTS with b ∈ B , and D be an LTS. Let S P D be an LTS, π e 0 , e 1 , . . . be an infinite trace of S , and q 0 , t 0 , e 0 , q 1 , t 1 , e 2 , q 2 , t 2 , . . . an infinite execution of S . We say that a sub-trace e i , e i+1 , . . . , e k of π is inside the black-box state b if the sub-sequence q i , t i , e i , q i+1 , t i+1 , . . . , q k +1 , t k +1 is a maximal sub-sequence such that q i q i+1 . . . q k +1 b and e i , e i+1 , . . . , e k ∈ σ (b). C. Menghi et al. Note that a sub-trace inside a black-box state is finite.
Let C be the p&d supervisor design (Fig. 3d) and E be the p&d environment (Figs. 1a, 1b and 1c). Let us consider the infinite trace of C E in which the sequence of events userReq, shipInfoReq,costAndTimeofferRcvd,usrAck, shipReq,respOk is repeated an infinite number of times, the sub-trace shipInfoReq,costAndTime is inside the black-box state 2.
Let C be a partial component described using an IPLTS I P , pre, post , and E be its environment, described using an LTS D. Traces of P D are valid if they satisfy both the pre-and the post-conditions of all the black-box states.
Definition 6.7 Let L Q, q 0 , A, be an LTS, P L, R, B , σ be a PLTS, I P , pre, post be an IPLTS. Let D be an LTS, and S be P D. A trace π of S satisfies the pre-conditions of a black-box state b ∈ B if for every subtrace π 1 of π that reaches a black-box state b, π 1 | pre(b). A trace π of S satisfies the post-conditions of a black-box state b ∈ B if for every sub-trace π 2 inside a black-box state b, π 2 | post(b).
In the proposed definition, a pre-condition specifies a property that must hold in a sub-trace that reaches a black-box state, while a post-condition specifies a property that must hold in a sub-trace performed inside the black-box state. Intuitively, a post-condition is defined as a constraint on the behavior of the system that must hold while the system is in the back-block state. An alternative semantics may define a post-condition as a property that must hold when the system exits the black-box state, i.e., a property that must hold in the concatination of the sub-trace that reaches the black-box state and the sub-trace obtained inside the black-box state (the "whole sub-trace"). Our semantic choice was geared towards fitting within an iterative and incremental development process while allowing distributed development of components. We believe that when a development team has to refine a black-box state, it prefers having a condition that constrains the behavior of the component under development, rather than a condition that constrains the composition of the component that has to be developed and all the components that have been executed before entering that component.
Consider the pre-condition of the black-box state 4 of the partial component C represented by the IPLTS in Fig. 3d. It requires that any finite trace of C E , where E is its environment, that reaches black-box state 4 is such that if a user requests information about a product, the system provides it. The post-condition for the black-box state 4 constrains the behavior of C E when the partial component C is inside the black-box state 4. For our example, it ensures that a product and a shipping request are performed by the furniture-sale service by C E while the partial component is inside the black-box state 4.
Let C be a partial component defined using an IPLTS and E be its environment. We say that C is well-formed when all pre-and post-conditions of its black-box states are satisfied by C E. Definition 6.8 Let L Q, q 0 , A, be an LTS, P L, R, B , σ be a PLTS, I P , pre, post be an IPLTS. Let D be an LTS, and S P D. The IPLTS I is well-formed (over D) if for every trace π of S holds that, if π satisfies the post-conditions, then it also satisfies the pre-conditions. Intuitively, Definition 6.8 specifies when pre-and post-conditions are consistent with each other. It ensures that the pre-conditions are satisfied if the post-conditions are. Consider the pre-condition (see Fig. 3c) of the black-box state 4 of the p&d supervisor design (Fig. 3d), which requires that if a user request is received, the system finally had sent information to the user. This pre-condition is satisfied if the post-condition of the black-box state 2 ensuring that information is sent to the user is also satisfied (Fig. 3c).
We now define what it means for a property φ to hold on a well-formed IPLTS.
Definition 6.9 Let L Q, q 0 , A, be an LTS, P L, R, B , σ be a PLTS, I P , pre, post be an IPLTS. Let D be an LTS, and S P D. We say that the IPLTS I satisfies an FLTL property φ if it is well-formed (over D) and for every trace π of S that satisfies the post-conditions, π | φ.
In the p&d example, the post-condition (F ProdReq) ∧ (F ShipReq) of the black-box state 4 ensures that the parallel composition of the component in Fig. 3d and its environment satisfies property P3 (Fig. 1d).

Sub-components and their integration
In this section, we describe how black-box states representing unspecified components can be refined into subcomponents and define an integration operator that replaces the black-box states of a partial component with the corresponding sub-components.
We first define the notion of a sub-component.
A sub-component R is represented as an IPLTS f such that its computation starts in its initial state and ends in one of its final states and is defined over a finite LTS with events in the set σ (b).
When the design of a sub-component is finished, it is integrated into the initial partial component design. Let C be a partial component modeled as an IPLTS and R be a sub-component (modeled as an IPLTS f ) for a black-box state b of C. The integration operator replaces b with R.
Recall that given a state q (of an LTS or an LTS f ), (q) − and (q) + denote its incoming and outgoing transitions, respectively, and (q) denotes the union of the incoming and outgoing transitions of q.  For example, integrating the sub-component R for black-box state 2 in Fig. 3e into the partial component C in Fig. 3d produces the IPLTS shown in Fig. 3j. The prefix "2." is used to identify the states obtained from R.
The contracts of black-box states 4 and 5 are the same as those in Fig. 3c. The initial state of the integration is the initial state of the C in Fig. 3d. Every incoming transition of state 2 is replaced by a transition with the same initial state and with destination being the initial state 1 of R , and every outgoing transition of 2 is replaced by a transition with the same final state and with source being the final state 5 of the sub-component R.
The integration operator allows replacing a black-box state b of the partial component C by a sub-component R and obtaining another partial component C . Definition 6.12 Let b be a black-box state, pre(b) and post(b) be its pre-conditions and post-conditions. Let I P , pre, post be an IPLTS f , where P F , R, B , σ and F Q, q 0 , A, , Q f and D be an LTS. The IPLTS f I f is substitutable for D if for every sequence π i ; π e where 1. π i e 0 , e 1 , . . . , e n where q 0 , e 0 , q 1 , e 1 , . . . , q n , e n , q n+1 is a sequence of the LTS L such that for all i , where 0 ≤ i < n, (q i , e i , q i+1 ) is a transition of the LTS D and π i | pre(b); 2. π e is a finite trace of P D, where q n+1 is considered an initial state of the LTS; we have that π e | post(b).
Intuitively, a sub-component R is substitutable if, assuming that the environment evolves in a way that respects the pre-condition pre(b), R ensures the satisfaction of the post-condition.
Correctness. To ensure the correctness of our framework, we show that replacing a substitutable IPLTS f by a well-formed IPLTS preserves satisfaction of its properties.
Intuitively, the sequential composition of F and I f is an IPLTS. All the final states of the F are connected to the initial state of the IPLTS f I f by a transition labeled with a fresh event init. An additional state q end is added to the LTS with a self-loop labeled with end. A transition from q to q end labeled with end is added for each final state q of the IPLTS f I f . Performing these steps ensures that all the infinite traces π of I are in the form π 1 ;init;π 2 ;end ω , where π 1 is generated by the LTS f F and π 2 is generated by the IPLTS f I f .
Consider for example the LTS f presented in Fig. 9a which is obtained from the LTS in Fig. 1a by considering the state 3 as a final state and the IPLTS f of Fig. 3e. The sequential composition is represented in Fig. 9b. Its initial state is the initial state of the LTS f represented in Fig. 9a. The final state of the LTS f is connected to the initial state of the IPLTS f of Fig. 3e with an init labeled transition. The final state of the IPLTS f is connected to the state q end through a transition labeled with end. A self-loop labeled with end is added to state q end .

Verification algorithms
In this section, we describe the algorithms for the analysis of partial components introduced in Sect. 3, which we have implemented on top of LTSA [MK99]. Section 7.1 describes a method for checking realizability (Algorithm 3). Section 7.2 describes a well-formedness check (Algorithm 4). Section 7.3 describes a model-checking algorithm (Algorithm 5). Finally, Sect. 7.4 describes a method for checking substitutability (Algorithm 6).

Checking realizability
Let C be a partial component, E be its environment and φ be a property of interest. The realizability checking algorithm (Algorithm 3) verifies whether there exists an integration (Definition 6.1) of C obtained by integrating sub-components (Definition 6.11) that constrain the environment E in a way that satisfies φ, i.e., there exists an integration C of C such that C E | φ and there is at least an infinite trace in C E. The algorithm removes all the black-box states and their incoming and outgoing transitions from C and stores the obtained LTS in C B (function removeBoxes on Line 2). It checks whether C B E | φ (Lines 3-4) using the classical CheckFLTLonLTS model-checking procedure (Algorithm 1). If the property ¬φ is satisfied, the component is not realizable. Otherwise, it computes C E (as specified in Definition 6.2) and model-checks it against ¬φ using the classical model-checking procedure CheckFLTLonLTS, returning the negation of the computed result (Lines 5-8). If CheckFLTLonLTS(C E, ¬φ) returns true, all the infinite behaviors satisfy the negation of the property φ, so there is no infinite trace in C E satisfying φ. Since we aim to construct an LTS obtained from C by integrating sub-components into its black-box states that contain infinite traces that satisfy φ, and no infinite traces that satisfy φ exist in C E, a value false is returned. Recall that C E allows the environment E to perform any transition while C is in one of its black-box states. If CheckFLTLonLTS(C E, ¬φ) returns false, there exists an infinite behavior that satisfies φ. The integration of the partial component C that ensures the satisfaction of the property φ can be obtained through an integration that forces the environment to only show this behavior.
For example, let C be the p&d supervisor design (Fig. 3d), E be the p&d environment (Figs. 1a, 1b and 1c) and the property P2 (Fig. 1d). The realizability checker confirms the existence of an integration that satisfies property P2.
Since the algorithm simply calls the CheckFLTLonLTS twice, its complexity is exponential in the size of the FLTL formula and linear in the size of the partial component C.

Theorem 7.1 Let C be a partial component, E be its environment and φ be a property of interest. Algorithm 3 returns false if there is no component C obtained from C by integrating sub-components, s.t. C E | φ.
Proof Sketch If C B E | φ, there exists an infinite trace of the environment which is allowed by the already specified portion of the component and which violates φ. No matter how the sub-components of the black-box states are specified, there will be an infinite trace that does not satisfy φ. Thus, the component is not realizable.
If C E | ¬φ, there does not exist an infinite trace on which φ holds. Thus, there cannot exist a component that constrains the environment to expose only traces that satisfy φ and ensures that at least one infinite trace is present in the final system.

Checking well-formedness
Let C be a partial component and E be its environment. The well-formedness checker (Algorithm 4) verifies whether the partial component C is well formed w.r.t. its environment E (Definition 6.8).
Algorithm 4 Checking well-formedness 1: function CheckWell-formed(E, C) 2: return false return true Algorithm 4 considers each black-box state b of the partial component C (Line 2). For each b, it creates a copy C of the partial-component (Line 3). For each block-box state q, different from b, it transforms its post-condition post(q) into an LTS f denoted LTS f (q) using the procedure FLTL f 2LTS f described in Algorithm 2 (Line 5). This LTS f is integrated into C (Line 6). Then, the algorithm transforms the post-condition post(b) of b into an LTS f denoted LTS f (b) (Line 7) and integrates it into C (Line 8). The operator Integrate * behaves like the usual Integrate operator (Definition 6.11) but in addition returns the initial state q 0,b of the post-condition post(b). Then, we cast the C over E w.r.t. the initial state q 0,b of the post-condition (Definition 6.5). Finally, the algorithm checks the satisfaction of the precondition pre(b) of b on the LTS f S by using the procedure CheckFLTL f onLTS f described in Sect. 5.2 (Line 10).
In the p&d example, if we remove the clause F InfoRcvd from the post-condition of the black-box state 2, the p&d component is not well-formed since the pre-condition of state 4 is violated. The counterexample shows a trace that reaches the black-box state 4 in which an event userReq is not followed by infoRcvd. Adding F InfoRcvd to the post-condition of state 2 solves the problem. Algorithm 4 calls the method CheckFLTL f onLTS f with the pre-condition pre(b) and an LTS obtained from C by integrating a set of LTS f , one for each black-box state, generated from their post-conditions. In the worst case, the size of each LTS f is exponential in the size of the corresponding post-condition. Thus, the complexity is exponential in the size of the FLTL f formula of the post-conditions and in the size of the FLTL f pre-condition, and linear in the size of the partial component C.
Theorem 7.2 Let C be a partial component and E be its environment. The well-formedness procedure returns true if and only if C is well-formed (Definition 6.8).
Proof Sketch By construction, the finite traces of LTS2LTS f (C , q 0,b , E) are exactly the finite traces that satisfy the post-conditions of the black-box states (Definition 6.8). Thus, the procedure CheckFLTL f onLTS f returns false if and only if there exists a finite trace π of C E that does not satisfy the pre-condition pre(b) (Definition 6.7).

Model checking
Let C be a well-formed partial component, E be its environment and φ be a property of interest. Model checking (Algorithm 5) verifies whether C satisfies the property of φ under the environment E (Definition 6.9).

Algorithm 5 Model checking
Algorithm 5 first creates a copy C of the partial component C (Line 2), which is then iteratively modified by the algorithm (Line 5). Specifically, the algorithm transforms all post-conditions into an LTS f (Line 4) and integrates the generated LTS f into the copy C of the partial component (Line 5). Since all of the black-box states are replaced by the corresponding LTS f , the obtained model of the partial component C is an actual LTS. Finally, the algorithm uses the CheckFLTLonLTS model-checking procedure (Algorithm 1) to verify whether C E | φ (Line 6).
If we consider the design in Fig. 3d and assume that the black-box state 2 is not associated with any postcondition, then the model checker returns a counterexample userReq, τ , offerRcvd for property P2, since the sub-component that will replace the black-box state 2 is not forced to ask to book the furniture service. Adding the post-condition in Fig. 3c solves the problem.
Algorithm 5 calls the CheckFLTLonLTS method considering the property φ and an LTS that is obtained from C by integrating a set of LTS f , one for each black-box state, that are generated from their post-conditions. The size of each of these LTS f is in the worst case exponential in the size of the corresponding post-condition. Thus, the complexity is exponential in the size of the FLTL property φ, and in the size of the post-conditions. It is linear in the size of the partial component C. Proof Sketch The model-checking procedure runs the CheckFLTLonLTS algorithm by considering the LTS C E. C is obtained from the partial component C by integrating the LTS f generated from the post-conditions of its black-box states. Thus, C E contains exactly the traces of C E that satisfy the post-conditions of the black-box states of C (Definition 6.7). Furthermore, since C is well-formed, by Definition 6.9, φ holds.

Checking substitutability
Let E be an environment, R be a sub-component for a black-box state b with interface σ (b), pre-condition pre(b) and post-condition post(b). Algorithm 6 checks whether the sub-component R is substitutable (Definition 6.12). In the p&d example, the substitutability checker does not return any counterexample for the sub-component in Fig. 3e. Thus, the sub-component can be integrated in place of the black-box state 2.

Algorithm 6 Substitutability checking
Algorithm 6 calls the CheckFLTLonLTS method considering the property λ and an LTS P E. The IPLTS P is obtained from the sub-component R by integrating a set of LTS f , one for each black-box state, that are generated from their post-conditions, and by computing the sequential composition with an LTS f generated from the pre-condition pre(b). The size of each of the integrated LTS f is in the worst case exponential in the size of the corresponding post-condition. The size of the LTS f generated from the pre-condition pre(b) is in the worst case exponential in the size of the pre-condition. Thus, the complexity is exponential in the size of the FLTL f property φ, of the post-conditions of the black-box states contained in the sub-component and of its pre-condition pre(b). It is linear in the size of the partial component C. Proof Sketch By construction, the LTS f P E contains traces of the form π i ; π e that satisfy the conditions of Definition 6.12. By checking whether λ holds on P E using the procedure CheckFLTL f onLTS f , we verify that π e | post(b).

Tool support and evaluation
This section reports on our experience evaluating the effectiveness and scalability of our approach. Specifically, we aim to answer the following questions:

RQ1:
How effective is FIDDle w.r.t. supporting an iterative, distributed development of correct controllers? (Sect. 8.2) and RQ2: How scalable is the automated part of the proposed approach? (Sect. 8.3).
We begin by describing our tool support.

Tool support
FIDDle is a Java application developed on top of LTSA to provide support for incremental distributed development of controllers. The complete implementation together with the examples and the case study presented in the next section is available at https://github.com/claudiomenghi/FIDDLE. FIDDle extends LTSA in three directions: • input language and compiler: extended to support modeling of partial components and sub-components; • graphical interface: extended to provide graphical support to users; • verification algorithms: implemented the procedures described in Sect. 7.
We describe each of these directions below.

Input language
We introduced a set of constructs within the LTSA input language that support the formalism defined in Sect. 6. These commands (see Table 1) introduce new keywords to define partial components (partial component), their black-box states (box), their pre-and post-conditions (precondition, postcondition), the environment (environment), and the sub-components (subcomponent).
A verification-driven framework for iterative design of controllers For example, the model of the environment of our motivating example presented in Fig. 1, the partial component presented in Fig. 3f and the pre-and post-conditions of the black-box state 2 presented in Fig. 3c and the sub-component presented in Fig. 3e are described using the proposed keywords given in Fig. 10.

Graphical user interface
We modified the graphical interface of LTSA (Fig. 11) in three different directions: 1. the commands described in Table 1 are integrated within the textual interface embedded within LTSA, including syntax highlighting; 2. the LTSA GUI is extended to visualize partial components and sub-components, with black-box states identified by black-colored states, as shown in Fig. 11 ( 1 ); 3. a new menu is added to the interface to enable loading of partial components, sub-components and their environments ( 2 in Fig. 11); 4. a new menu is added to allow running the checks described in Sect. 7 ( 3 in Fig. 11).

Verification algorithms
The verification algorithms presented in Sect. 7, as well as Algorithm 2 and the function FLTL f 2FLTL presented in Sect. 5 have been developed within appropriate Java classes. The implementation reused existing LTSA classes, as specified in the description of the appropriate algorithm. However, implementation was not straightforward. Reverse engineering the existing LTSA classes, which were written by different authors and that were often not completely documented, took a considerable effort. Thus, integrating the existing algorithms within the existing classes was not easy and required more than 1000 lines of Java code.

Effectiveness
In this section, we describe a case study which aims to show how the proposed approach supports developers in the initial overall design of the controller and in iterative and distributed development of (sub-)components.
To do so, we simulated forward development of an existing complex controller and analyzed FIDDle-provided support along the steps described in Sect. 3.

Experimental setup
We chose the executive module of the K9 Mars Rover, developed at NASA Ames [GPB02, CGP03, GPB05] and specified using LTS. The overall size of the LTS is10 7 states. The executive module was decomposed into the following components: Executive, ExecCondChecker, Ac-tionExecution and Database. ExecCondChecker was further decomposed into DBMonitor and Internal. A high-level description of each component is provided in Table 2.
Each of these components was associated with a shared variable (exec, conditionList, action and db) used to communicate with the other components, e.g., the exec variable was used by ExecCondChecker to communicate with Executive. Access to each shared variable was done via mutexes, documented in Table 3.
We considered two properties: Pr1: Executive performed an action only after a new plan was read from Database; Pr2: Executive got the lock over the condList variable only after obtaining the exec lock.
The FLTL formulae for the properties of interest are presented in Table 4. To specify property Pr1, we defined two fluents: EXEC ACTION, which is true while the action is under execution, and READ PLAN, which is true while the plan is read. Fluents are detailed in Table 5. The formalization of property Pr1 specifies that an action is not performed before a plan is read.
To specify property Pr2, we defined fluents, COND LIST LOCKED and EXEC LOCKED. These fluents are true after the condList and the exec are locked and until it is unlocked. The formalization of this property specifies that if the condition list is locked, the exec is also locked.
We simulated forward development of the Executive component. We considered the existing model (D3) of the Executive and abstracted portions of the complete model into black-box states to create two partial components, D1 and D2, representing partial designs. The abstracted portions are used to generate sub-components Sub1 and Sub2 for the black-box states contained in the partial design which we assumed third-party companies had to develop.  To create D2, we encapsulated three states that receive plans and prepare for plan execution into one black-box state Read Plans. The abstracted portion of the Executive leads to the sub-component Sub2. To create D1, we also designated one of the 10 states of the Executive whose corresponding LTS is in charge of executing a plan, state ExecuteTaskAction, as a black-box state. A portion of the design D1 of Executive is presented in Fig. 11. The abstracted portion of Executive leads to the sub-component Sub1. D2 can be obtained from D1 by integrating the sub-component Sub1 using the same procedure. D3 is obtained from D1 by integrating the sub-component Sub2.
We considered the (partial) designs D1, D2 and D3 and the sub-components Sub1 and Sub2 and used FIDDle to iteratively develop and check their designs. The obtained results are summarized in Table 6 which contains an incremental identifier used as a reference in the textual description (i.e., ID1, ID2, . . . , ID15), the check that has been performed, the considered partial component or sub-component, the considered property and pre-and post-conditions. For each check, we specify whether the check succeeded (✓) or fail (✗), the number of states explored by FIDDle, the memory consumption and the time needed to provide the reported results.
Creating an Initial Component Design. The realizability checker (Algorithm 3) confirmed the existence of a component obtained from D1 by integrating sub-components that satisfy the properties of interest (ID1 in Table 6). Specifically, for property Pr1, FIDDle returned a trace of D1 E that satisfies the property of interest, i.e., a trace in which EXEC ACTION does not occur before READ PLAN. For property Pr2, FIDDle returned a trace of D1 E that satisfies the property of interest, i.e., a trace in which Executive got the lock over the condList variable only after obtaining the exec lock (ID2).
The model checker (Algorithm 5) returned a counterexample for both properties of interest. For property Pr1, it returned a counterexample in which no plan was read and yet an action was performed (ID3). For property Pr2, the counterexample was where Executive got the condList lock without possessing the exec lock (ID4).
To guarantee the satisfaction of Pr1, we specified the post-condition Post1 defined in Table 4 for the black box state Read Plans (ID5). The post-condition ensures that a plan is read in the black-box state PlanBox, since the fluent EXEC ACTION can only hold after the black-box state PlanBox is left. By ensuring that a plan is read in the black-box state PlanBox, the property is satisfied.
We added the post-condition Post2 to the black box state PlanBox and the post-condition Post3 to the black box state ExecuteTaskAction (see Table 4). The post-condition Post2 specifies that if the conditionList variable is locked, the exec variable is also locked. Furthermore, it forces the exec variable to be locked when the component is exited. The post-condition Post3 specifies that if an action is under execution, the exec variable should be locked. Furthermore, it forces the exec variable to be locked when the component is exited and the action to not be under execution. The model checker confirmed that the new design guaranteed satisfaction of property Pr2 (ID6).
We added a pre-condition that specifies that an action is not under execution when the black-box state Read Plans is entered. The well-formedness checker (Algorithm 4) confirmed that the pre-condition is ensured by the current design (ID7). We additionally added a pre-condition for the black-box state PlanBox specifying that, when the black-box state is entered, the exec variable is locked, while the conditionList variable is not and the property is not violated before entering the black-box. The well-formedness checker (Algorithm 4) confirmed that the pre-condition is ensured by the current design (ID8).
Developing and Integrating the ExecuteTaskAction Sub-component. We simulated a refinement process in which pre-and post-conditions were given to third parties for sub-component development. We considered the sub-component Sub1 containing the portion of the Executive component abstracted by the black-box state ExecuteTaskAction. We ran the substitutability checker (ID9) to verify, affirmatively, whether the sub-component Sub1 ensured the post-condition Post3 given the pre-condition Pre1.
Then, we integrated the sub-component Sub1 into the partial design D1 obtaining the partial component D2. We ran the realizability checker (ID10) which confirmed the existence of a model that refines D2 and satisfies the properties of interest. Then, we ran the model checker which confirmed satisfaction of the property Pr1 (ID11) and Pr2 (ID12). This shows that the development of the sub-component Sub1 can be distributed to a third party. As formally proven in Sect. 6.4 and confirmed by the model checker, integrating a substitutable sub-component into a well-formed partial-component ensures that the satisfaction of the property of interest is preserved. Developing and Integrating the PlanBox Sub-component. We simulated the iterative refinement of the subcomponent PlanBox. Distributing pre-and post-conditions allow parallel development of the PlanBox and Exe-cuteTaskAction sub-components. We assumed that the developer team provides the design of the sub-component Sub2 abstracted from the Executive component by the black-box state PlanBox. Then, in order to verify that the sub-component Sub2 ensured the post-condition Post2 and Post3, we ran the substitutability checker (ID13). The check was affirmative showing that the proposed design can replace the black-box state PlanBox.
Then, we integrated the sub-component Sub2 into the partial design D2 obtaining the partial component D3. We ran the model checker which confirmed satisfaction of the properties Pr1 (ID14) and Pr2 (ID15). This shows that the development of the sub-component Sub2 can be distributed to a third party. and that integrating a substitutable sub-component into a well-formed partial-component ensures that the satisfaction of the property of interest is preserved, as desired.

Discussion and threats to validity
The Executive component is a realistic controller of medium size [AFT08, LMP08, BBKT04]. It has been implemented by 25K lines of C++ code, 10K of which is the main control code, and the rest define data structures needed for communication with the actual Rover [GPC04].
FIDDle was effective in analyzing partial components and helping change their design to ensure the satisfaction of the properties of interest. The experiment confirmed the possibility of distributing the design of sub-components for the black-box states. As expected, no rework at the integration level was required, i.e., integration produced components that satisfied the properties of interest. This confirmed that FIDDle supports verification-driven iterative and distributed development of components.
A threat to construct validity concerns the (manual) construction of the intermediate model produced by us by abstracting an existing component model and the design of the properties to be considered. However, the intermediate partial designs and the selected properties were based on original developer comments present in the model. Specifically, the intermediate partial designs were obtained by encapsulating states of the initial model that abstracted portions of the LTS into black-box states. In terms of the properties, the designer's interest in whether the condList is locked when actions are performed by Executive is confirmed by the presence of the following comment: AssumedByXXX = ( condList.lock that preceded an instruction in which the Executive modifies the value of a condition of the ExecCondChecker component.
The property specifying that an action is not performed before a plan is read follows from the description of the Mars Rover Executive behavior [GPB02]: The executive receives flexible plans from a Planner, which it executes according to the plan language semantics. A plan is a hierarchical structure of actions that the Rover must perform. A threat to internal validity concerns the design of the contracts (pre-and post-conditions and interfaces) for the black-box states chosen along the process. Writing pre-and post-conditions may be difficult and error-prone for practitioners. However, we envision a process in which developers use property specification patterns [DAC98] to define pre-and post-conditions. Patterns collect recurrent specification problems and can guide developers in writing meaningful contracts. Patterns also contain solutions, expressed in temporal logic, for the recurrent specification problems, which can be used as template formulae for pre-and post-conditions, thus facilitating writing correct FLTL f specifications. That was the method we used ourselves in writing pre-and post-conditions in the reported case study.
The fact that a single example has been considered is a threat to external validity. However, we believe that the presented results can be considered as representative for real case scenarios since the analyzed example is a medium-sized complex real case study [Lev87,Sof04,BBKT04].

Scalability
We studied the scalability of the procedures proposed in this work. We considered the well-formedness and the substitutability checkers since the realizability and the model checker are implemented by performing a call to a classical model checker after simple transformations of the considered models. We set up experiments Exp1 and Exp2 to evaluate the scalability of the well-formedness and the substitutability checkers, respectively. Our experiments were based on a set of randomly-generated models. Random model generation is a widespread technique to evaluate artifacts in the software engineering and formal methods communities [TV05,DWDHR06,TV07,SFG+12,FSC12a,MSG16,MSCG18,MGPT18a,MGPT18b].
Experiment Exp1. We compared performance of the well-formedness checker with the standard model checker for FLTL properties on LTS models implemented in LTSA by varying the size of the partial components and their environments. We generated an LTS model of the environment and a complete model of the component and checked the parallel composition between the component and the environment w.r.t. a property of interest using LTSA. Then we generated a partial component (by marking one of the states of the complete component as a black-box and defining pre-and post-conditions for it) and ran the well-formedness checker, comparing performance of the two. Experiment Exp2. We compared the performance of the substitutability checker with the LTSA model checkera standard model checker for FLTL properties on LTS-by varying the size of the sub-components and their environments. We generated an LTS model of the environment and a complete model for the component and checked them against a property, as described in experiment Exp1. Then we extracted a sub-component by selecting a set of component states and the transitions between them, defined the pre-and post-conditions for the sub-component, and ran the substitutability checker comparing its performance with model-checking.
We describe the experiments below.

Experimental setup
We implemented a random LTS generator (rndLTSgen) to create LTS models with a specified number of states (#States), transition density (#Tdens) i.e., transitions per state, and number of events (#events). First, an LTS with #States states and #events events is created and then transitions are added. Starting with the initial state, we visit each state of the LTS, adding #Tdens transitions to each. Each transition has state q as source, a random state of the LTS as destination, and it is labeled with an event randomly chosen among the #events events of the LTS. The random LTS generator is used to create models for the environment and the complete component. We also developed a partial component generator (prtCompGen) that creates a partial component with one black-box state. prtCompGen takes as input an LTS, a number of events (#events) of the LTS to be added to the interface of the black-box state, and its pre-and the post-conditions. prtCompGen randomly chooses one of the states of the LTS and marks it as black-box state and then randomly selects #events events among the LTS events and adds them to the interface of the black-box state. Finally, it sets the pre-and post-conditions of the interface to the values passed as its parameters.  (Q → (¬P )) Obligation Instance of the absence pattern. It specifies that P is false after Q.
We use the formulas in Table 7 to describe pre-and post-conditions and properties of interest, where fluents Q and P are true when two distinct events, randomly selected among the events of the LTS, occur. Formula K1 has been chosen since it has the same form as Pr2 of our case study. The formulae K2 and K3 are based on the commonly used property patterns and belong to two different classes of the Manna and Pnueli hierarchy [MP90].
Finally, we implemented a sub-component generator (subCompGen). subCompGen takes as input an LTS and the percentage of the number of its states (%States) to be added. subCompGen extracts %States of the states from the LTS and the transitions between them. Then it adds states q 0 and q f as the sub-component's initial and final states, respectively, and connects, via a τ -transition, q 0 with all the states of the sub-component that have, in the LTS, at least one incoming transition from a state that was not added to the sub-component. Transitions to q f are added similarly. To illustrate, consider the LTS in Fig. 12(a). Fig. 12(b) shows an extracted sub-component with 5 states. Transitions from q 0 to 2 and 4 are added since states 1 and 8 are not included in the sub-component and they had an outgoing transition reaching 2 and 4. Transitions from 5 and 6 to q f are added since states 7 and 9 are not included in the sub-component and 5 and 6 had outgoing transitions reaching those states.

Methodology and results
We now describe the methodology and results of the two experiments.
Experiment Exp1. For each combination of values #EnvStates and #CompStates reported in Table 8, we generated five different configurations by changing the pre-and post-conditions of the partial component and the property of interest. We used rndLTSgen to generate a model of the environment E and a complete component C considering the number of states (#EnvStates for the environment and #CompStates for the complete component), the transition density and the number of events specified in Table 8. We used prtCompGen to create a partial component P obtained from the complete component C considering the number of events specified in Table 8 and by randomly selecting one among the pre-and post-conditions presented in Table 7. We also randomly selected a property φ from the formulae specified in Table 7.
For each configuration, we ran a classical model checker (in our case, LTSA) by checking the satisfaction of the property φ on the parallel composition between the environment and the complete component C. Then we ran the well-formedness checker on the partial component P w.r.t. the environment E. This procedure was run on a 2 GHz Intel Core i7, with 8 GB 1600 MHz DDR3 disk, and we recorded the average time (over the five different configurations obtained by changing pre-and post-conditions) required by the well-formedness checker (T w ) and by the model checker (T m ). Table 9 contains the average ratio among T w and T m for each combination of values for #EnvStates and #ContStates.
These results show that the well-formedness checker scales as well as the classical model checker does as the size of the environment, the partial component and the sub-component grows. This means that the well-formedness checker can be used in all of the scenarios where classical model checking is already being used.  Table 8, we again generated five configurations, each obtained by varying the pre-and post-conditions of the partial component and the property of interest. Specifically, we used rndLTSgen to generate a model of the environment E and a complete component C considering the number of states (#EnvStates for the environment and #CompStates for the complete component), the transition density and the number of events specified in Table 8, and subCompGen to create a sub-component S obtained from the complete component C considering the percentage of states specified in Table 8. We randomly chose the pre-and post-conditions of S and a property φ from the ones specified in the table.
For each configuration, we used LTSA to check whether φ holds on E C and then ran the substitutability checker considering the sub-component S and the environment E on the same computer configuration as for Experiment Exp1. Table 9 contains the average ratio between the time taken by the substitutability checker (T s ) and that of the model checker (T m ) for each combination of values of #EnvStates and #ContStates.
The results show that the substitutability checker scales as well as classical model checking as the size of the environment, the partial component and the sub-component grows. This means that the substitutability checker can be used in all of the scenarios where classical model checking is already being used.

Discussion
The procedure employed to randomly generate models is a clear threat to construct validity. However, the transition density of the components was chosen based on the Mars Rover example. Specifically, we chose the value 10, which approximated the density of the Executive component (7.37) and the component run in parallel with it (14.96). Furthermore, the number of states was chosen such that the ratio between the sizes of the component and the sub-component was approximately the same as that of the Mars Rover example: the Executive had 96 states and the sum of the states of the LTS abstracted into black-box states (WaitingForPlan, PrepareExecution and ExecuteTaskAction) was 51.
The properties considered in the experiment are a threat to internal validity. However, we believe that by using properties from the patterns database, we considered properties that occur frequently, thus reducing the internal validity bias.
Considering a single black-box state is a threat to external validity. However, our goal was to evaluate how FIDDle scales with respect to the component and the environment sizes and not w.r.t. the number of blackbox states and the size of the post-conditions. Considering the scalability with respect to the component and the environment sizes when multiple black-box states are present can be reduced to the problem of considering a single black-box with a more complex post-condition. Indeed, as discussed in Sect. 7, the scalabilty of the well-formedness and the substitutability checkers depend on the size of the partial component and of the post-conditions associated with its black-box states.

Related work
The work described in this paper proposes a complete approach-from modeling to verification and synthesisfor incremental and distributed development of correct controllers in the presence of partial information. The ability to deal with incomplete models and reason about partial information is key in our approach. It becomes necessary to support modularity and incremental design, where certain design decisions are postponed or delegated to other parties. For this reason, we consider incompleteness in every part of model development as relevant to our work, namely, • modeling formalisms that support partial models (Sect. 9.1); • verification techniques that permit the verification of partial models (Sect. 9.2); • techniques to verify the pluggability of components in incomplete models or to substitute existing components (Sect. 9.3); and • techniques to synthesize correct components in incomplete models starting from a specification of the component (Sect. 9.4).
We explore these connections below.

Modeling partiality
Since many software development processes have either a hierarchical or an iterative structure, the literature includes a variety of models for incomplete and partial models, both descriptive [RNA+04] and operational.  [CBFU06]). Necessary transitions represent behavior that the system must exhibit, while possible transitions describe admissible behavior. Different operations have been defined over MTS, such as (classical) refinement, observational refinement [CBFU06], model merging (or logical conjunction) [LSW95]. A good overview of this area is given in [UABD+13]. PLTS differ from MTS because they express incompleteness via black-box states which are placeholders for (possibly partial) components, instead of via transitions. Moreover, the interfaces of black-box states can constrain the environment of the component that can be substituted for the black-box state. LTS ↑ [GPB02] are an extension of LTS, but, unlike our approach, they do not encapsulate components in a state, but rather use the ↑ operator to make unobservable those actions in the LTS of a component that are not part of its interface.
PKS [BG99] are an extension of Kripke Structures (KS) that allow the description of incomplete models. A proposition can have a value true, false or ⊥ (unknown) in a given state of the system. X KS [CDEG03] extend KS to allow assigning both propositions and transitions values from a multi-valued logic. These approaches differ from PLTS where a state can be replaced (as a whole) by another (possibly incomplete) component.
ILTS [SS13] introduce the notion of transparent states, to handle incompleteness over states. Analogously to PLTS, ILTS use states to capture incompleteness, but they are not equipped with pre-and pos-conditions and so do not natively support distributed development.
Software product lines (SPL) [PBvDL05] provide an alternative formalism to partial systems. They allow describing and reasoning about products by considering their features. Features are (user-visible) increments in product functionalities. A software product line allows differentiating between mandatory and optional features. Mandatory features must be part of every final product. Places where different features produce different behavior are called variation points. Like partial models, SPL compactly represent multiple alternatives that can be generated from them, and thus partial modeling formalisms are applicable for modeling SPL. For example, in a recent work by ter Beek et al. [tBFGM16], MTS are used to describe families of products through may and must transitions which allow an efficient and compact way of modeling the notions of alternative and mutually exclusive features. The variability-aware action-based branching time modal temporal logic (v-ACTL) [TBM14] is used to reason about families of products. Our work is complementary to those, as pre-and post-conditions can be considered as a tool for constraining the features that can be obtained by specifying the behavior of the system in a black-box state. [LT87,LT89,Jon94] allow modeling systems that continuously interact (receive inputs from and react to) with their environment. They are particularly useful for modeling components that operate asynchronously. Each component is modeled as an automaton whose transitions are labeled with actions. Those actions are instantaneous and classified into input, output or internal actions. While the internal and output actions of a component are controlled by the component itself, inputs are controlled by its environment and are instantaneously received by the component. Interface Automata [dAH01] are syntactically similar to the I/O Automata. However, while in I/O Automata the environment can perform an action at every state of the I/O Automata, in Interface Automata some input actions can be illegal in some of the states of a component.

I/O Automata
Team Automata [tBK03] provide a flexible framework for modeling collaboration between components. They are similar to I/O Automata as they allow the automata to synchronize over a subset of their actions. However, different kind of synchornizations can be defined on a per-action basis. A specific notion of compatibility for Team Automata, which enables iterative and hierarchical composition, has been proposed by Carmona and Kleijn [CK13].
Finally, Contract Automata [FDB17] are designed to orchestrate services on a contract basis. They provide a pre-defined set of the actions, that is, "make" requests, "advertize" offers, "matching" and a pair of "complementary" request/offer. A Contract Automaton specifies the assumptions and guarantees of a service in terms of those actions. Unlike these formalisms, our formalism allows developers to explicitly identify the still to be refined parts by means of black-box states and add pre-and post-conditions to black-box states enabling iterative top-down development.
Other modeling formalisms, such as Hierarchical State Machines (HSM) [AY01] and Statecharts [Har87], support the specification of a hierarchical relation among the states of the system, while others support uncertainty [FSC12a,FSC12b,FSDSC13], i.e., they can associate incomplete parts with a set of possible replacements.

Checking partial models
A number of approaches to analyze partial models have been proposed [Hut02, CDEG03, BG99, GPB02, AY01], but none of these techniques are directly applicable to the problem considered in this paper where missing subcomponents are specified using contracts, and their development is distributed across different development teams.
In [Hut02] and [CDEG03], the authors describe the model checking problem over MTS and X KS, respectively. In both cases, the proposed procedure first builds an under-approximation of the model, which is model checked against the property of interest. If the new model does not satisfy the property, the original model does not satisfy the property either. If this is not the case, an over-approximation is computed and then checked against the property of interest. A model checking approach for X KS is proposed in [CDEG03]. As in the case of MTS, this problem can be reduced to a set of executions of the classical model checking algorithm. In [BG99], the authors propose a 3-valued model checking approach, where three possible outputs can be returned: true, false, and maybe (or possibly). Even if able to verify incomplete systems, differently from our approach, neither these techniques are suitable for distributed development since they do not generate or assume any constraint on the incomplete components to support their development when the output of the verification depends on them.
In [AY01], the authors study the problem of checking HSM with respect to LTL properties. In this work, HSM are not considered as a formalism to model partiality, and thus the verification is assumed to be performed at the end of the development cycle when the final implementation of the model is provided. Finally, [GPB02] analyzes the assumption generation problem for LTS with an additional interface operator. This work is complementary to the one done in this paper and concerns the computation of an assumption that describes how the system model interacts with the environment. This problem can be integrated with the design phase of our approach to automatically generate post-conditions for the still-to-be-defined sub-components.

Substitutability checking
The goal of substitutability checking is to verify whether a (possibly partial) component can be plugged into a higher level structure without affecting its correctness. Thus, compositional reasoning, component substitutability and hierarchical model checking are related to this part of our work.
Compositional reasoning [dR01] reduces the verification effort by checking properties on individual components and inferring that these properties hold in the global system without explicitly creating it. For example, in the assume-guarantee paradigm [Jon83,AH99,Pnu85], if M guarantees φ and M guarantees ψ when it is located in an environment that satisfies φ, then M || M satisfies ψ. This approach works in a different direction from ours: we first guarantee that the properties of interest are satisfied in the initially defined partial model, and then check that later-provided components are suitable for plugging into the initial PLTS.
The work of Giannakopoulou et. al. [GPB02] is similar to our approach but focused on generating environmental restrictions. It addresses the assumption generation problem for LTS with an additional interface operator which describes how the model of the system interacts with its environment. In this approach, the claims to verify are also expressed as LTS. When the model of the system M possibly satisfies the claim , the proposed algorithm computes an assumption that describes all and only environments which guarantee the satisfaction of in M. In this sense, the procedure is similar to the supervisory control problem. Another similar approach is presented in [CT15]. The work discusses how to use a previously-developed contract refinement framework in a compositional verification setting. The procedure is based on the classical structure of a deduction proof, i.e., starting from a set of axioms, the properties of the system are obtained by iteratively applying a set of inference rules.
Several techniques ensure the substitutability between components [ZW97,BD08]. These approaches are built upon the substitution principle of Liskov [LW94] in the context of object-oriented programming. Given a system S , they check whether the interface type 1 of a component C is a subtype of interface type of the component C of S ; this would guarantee that C can replace C in S without causing behavior violations. The substitutability check is performed without plugging the component C into the system. This approach is analogous to the substitutability problem in the context of web services (e.g., [LFS+11]), where, once a web service W is considered as a substitute for a web service W in a composition Comp, the behavioral equivalence or similarity, and input and output compatibility between W and W in Comp are checked before using W in Comp. The solutions proposed in literature use different formalisms, such as finite-state machines, process algebra, and Petri nets, but they all rely on similar verification approaches.
The substitutability problem [CCSS08] can also be defined as a check that, after substituting one or more components, any updated portion of a software system continues to provide all the services offered by its earlier counterpart, and the previously established system correctness properties remain valid for the new version of the software system. In this case, substitutability is checked only after the new components are plugged in place of the old ones.
Compositional methods, e.g., Jonsson [Jon94], aim at checking whether an I/O Automaton refines another, by omitting information about some "not interesting" communication events. These techniques are similar to the one presented in this work. However, our technique is not based on information hiding but rather aims at ensuring that certain post-conditions are guaranteed by the unspecified behavior enclosed within a black-box state.
Compositionality of Team Automata has been studied by ter Beek et al., [tBK03] where the authors show how the relevant behavior of a composite automaton can be obtained from the behavior of its constituting automata, i.e., how, given one particular computation (behavior) of a team automaton, it is possible to extract the underlying behavior of one of its constituting component automata, and vice versa. The authors presented conditions that enable defining a set of operations that preserve this compositionality.
Ter Beek et al. [tBdV14] proposed a compositional verification technique for product lines. The compositional technique uses a driver module that coordinates between the feature and the behavioral domain model and abstracts the product behavior into a sub-component which is bisimilar to the product behavior, thereby enabling verification of local properties over a smaller behavioral model. Instead, our technique assumes a top-down development protocol in which sub-components are specified in terms of pre-and post-conditions described in FLTL.
Compositional verification can also be achieved using the Liskov substitutability Principle [LW94]. For example, Hähnle and Schaefer [HS12] studied how to extend this principle to verify software product families in a modular way. Specifically, in this work, a software product family is comprised of an original software product together with the contracts of its methods (pre-and post-conditions) and its possible variations (i.e., adding and removing methods and changing their contracts). This is different from our work in which we specifically address incremental development of behavioral specifications. A compositional verification technique based on feature verification has been proposed by Li et al. [LKF02]. The technique works by first verifying an individual feature using model checking, computing a preservation constraint that ensures the preservation of the model checking result; and proving that a feature ensures the preservation constraint of another feature. Thus, the proposed technique is similar to the classical assume-guarantee reasoning style [Jon83] which has been discussed previously.
The ability to approximate the implementation of a sub-component by a suitable contract and to ensure correctness via substitutability is at the core of the field of deductive software verification. AutoProof [TFNP15,PTF15] is an auto-active verifier for object-oriented programming languages. It proves functional correctness of Eiffel programs annotated with contracts that can refer to values of variables, can include boolean operators as well as and then and or else. Dafny [Lei10] allows proving code correctness by relying on a set of high-level annotations added to the code. If the code is correct, Dafny generates a proof that the code matches the annotations. KeY [BMU15] and OpenJML [Cok11] allow verification of sequencial Java programs by checking them against properties expressed in Java Modeling Language [LBR99] (JML). KeY is an interactive program verifier, based on dynamic logic [HKT01], and is suitable for verifying complex methods as users can incrementally build proofs. In constrast, OpenJML is fully automatic, and the program annotations are used to generate verification conditions exploited by a first-order theorem prover. As a result, verification is very fast for typical boilerplate methods (getters and setters) where the correct specifications can be given directly, but the technique is less suitable for incremental specification development. VCC [DMS+09] and VeriFast [JSP+11] use SMT solvers to verify correctness properties on annotated (multi-threaded) C programs. Viper [MSS16] is an infrastructure designed to support verification of program specifications. It includes an intermediate verification language that supports encoding of different programming languages, such as Scala, Java and OpenCL [BDH15], and the Viper front-end. Why3 [FP13] is a software verification platform that includes a logical language Why, a programming language WhyML and an infrastructure for translating the logical and the programming languages to existing theorem provers that solve the verification problem. Rather than verifying software programs, FIDDle verifies a behavioral model of the system.
Finally, verification of HSM [AY01,AY98] is also related to our work since HSM support iterative refinement. However, the verification procedures for HSM assume that the HSM is fully specified and does not analyze single components in isolation.

Synthesis
Program synthesis [PR89,DBPU13] aims at computing a model of the system that satisfies the properties of interest. Moreover, synthesis can be used to generate assumptions on a system's environment to make its specification realizable (e.g., [LDS11]). The realizability problem is tackled in [AMT13], where the authors showed how an unrealizable specification can be refined by adding assumptions on its environment through a counter-strategy guided synthesis approach. A similar idea is proposed in [LDS11].
Synthesis approaches for controllers have been proposed. For example, in [UBC09], the authors propose a synthesis technique to construct MTS from a combination of safety properties and scenarios. The idea is that safety properties are used to synthesize a model that represents an upper bound on the behaviors of the system, i.e., they include all the possible behaviors that the system can exhibit, while scenarios are lower bounds on its behavior, i.e., they describe less behavior than what the final system should provide. In [DBPU13], the authors propose a novel synthesis technique, extending their previous work ([ DBPU10,DBPU11]) and give methodological guidelines for automatically constructing event-based behavior models. The proposed approach works for an expressive subset of liveness properties, distinguishes between controlled and monitored actions, and differentiates system goals from environment assumptions.
Incomplete information and uncertain contexts are considered in [KV00] and [CPRT15]. The former considers the synthesis with incomplete information problem, which concerns the case in which each process can read only a part of the signals of the underling process (e.g., distributed programs), while the latter proposes an algorithm that allows to synthesize plans in uncertainty contexts, where an execution may result in one or more sequences of states. The goal is to compute plans which satisfy a reachability property, i.e., a condition on the final state of the execution of a plan. Finally, [AFFM06] presents Supremica, an integrated environment for verification, synthesis and simulation of discrete event systems. Supremica uses two main approaches: the first exploits modularity in order to divide the original problem into many smaller problems that together solve it, while the second uses an efficient data structure, a binary decision diagram, to symbolically represent the reachable states. [CBDU16] presents a fully automated synthesis procedure for highly non-trivial components of over 2000 states that works for special cases, by limiting the types of synthesizable goals and using heuristics. However, such cases might not be applicable in general.
Recent work has been done in the direction of compositional [AMT15,AMT16] and distributed [SUBK11] synthesis. In [AMT15], the authors studied the problem of compositional refinement of component specifications in the context of compositional reactive synthesis by considering a special case of only two components with specific constraints. In [AMT16], the synthesis problem for multi-agent systems is solved in a decomposed manner thanks to the assumption that the objective of the system is given in conjunctive form, and each conjunct of the global objective only refers to a small subset of agents in the system. Also, in [SUBK11], the authors propose a distribution algorithm for a deterministic subset of MTS. The algorithm under well-defined pre-conditions produces component MTS of a monolithic partial system behavior model without loss of information. We do not consider our approach to be an alternative to synthesis, but instead as a way to combine synthesis techniques with human design.

Conclusion and future work
This paper presented a verification-driven methodology, called FIDDle, to support iterative distribution of of software controllers. FIDDle enables recursive decomposition of a component into sub-components in such a way that correctness of the integrated system is ensured by construction. Development of sub-components that satisfy their specifications can then be done via independent, distributed development. FIDDle provides several types of support: modeling support for design activities performed by humans; analysis support for helping in software design; support for distributing development of unspecified parts; and support for integrating the developed sub-components.
Tool support for FIDDle was created as a Java application on top of LTSA, allowing developers to model components, iteratively develop sub-components, and perform all the checks described in this paper.
To evaluate the effectiveness of FIDDle in real cases, we abstracted parts of the K9 Mars Rover model built at NASA Ames and then simulated forward development. Our results showed that the proposed approach supports developers in the initial overall design and that the proposed analysis supports distributed development of subcomponents. We also evaluated the scalability of our model-checking and substitutability procedures developed within FIDDle on randomly generated models. Our results showed that the proposed procedures scale as well as classical model-checking as the size of the environment, the partial component and the sub-component increase.
We believe that the support provided by FIDDle for iterative and incremental controller development can positively impact the way in which future software systems will be developed. One of the main limitations of the proposed framework is that pre-and post-conditions are specified through logic formulae. This can be a time-consuming and error-prone process. In our evaluation, we used property specification patterns to support us in defining pre-and post-conditions of the unspecified components. While this was effective in our evaluation, we believe that FIDDle can benefit from additional automated support for helping define and analyze pre-and post-conditions. For example, automatic extraction of pre-and post-conditions from natural language can help users with a limited logical knowledge. We plan to enhance the implementation of FIDDle and improve its performance by integrating existing symbolic model checkers, such as NuSMV [CCG+02]. We would also be very interested in further evaluating FIDDle in real scenarios, where the approach would be used throughout software development, and in conducting a user study to assess FIDDle's usability.