amount of states of the model where the consistency checking is needed. In fact, the application example included in this paper shows these two possibilities.
Improving the Consistency Checking Process by Reusing Formal Verification Knowledge. Rebeca P. Díaz Redondo, José J. Pazos Arias, Ana Fernández Vilas, Jorge García Duque, and Alberto Gil Solla Departamento de Enxeñería Telemática. Universidade de Vigo. 36200, Vigo. Spain. Fax number: 34 986 812116 {rebeca, jose, avilas, jgd, agil}@det.uvigo.es
Abstract. At an iterative and incremental requirements capture stage, each iteration implies identifying new requirements, checking their with the current functional specification of the system, and, in many cases, modifying this global specification to satisfy them. In a totally formalized environment, these verifications are usually done applying a model checking algorithm which entails the wellknown efficiency problems to check medium-large and large systems. In order to reduce the amount of verifications and, consequently these efficiency problems, we propose reusing previously obtained formal verification results. The ARIFS methodology (Approximate Retrieval of Incomplete and Formal Specifications) supports the classification and the efficient retrieval (without formal proofs) of the verification information stored in the repository and, in this paper, we show how to carry out this proposal by using an application example.
1 Introduction Building large and complex systems, like distributed ones, increases the difficulty of specifying requirements at the beginning of the software process since: (a) these requirements continously evolve throughout the life-cycle and (b) at early phases, the designer usually has not a deep knowledge about the system. The use of incremental development techniques makes life-cycle models flexible enough to follow these inevitable and often continuous changes. Finally, combining this tendency and the use of formal methods, whose advantages are well-known, it is possible to obtain a totally formalized software process approach which is both iterative and incremental. Including software reuse in this kind of life-cycles can increase the efficiency of the development process of large and complex systems, specially if software reuse is tackled at early stages of the development process —like at the requirements specification stage. This last practice is widely accepted as a desirable aim, because of the possibility of increasing the reuse benefits [7]. However, there is little evidence in the literature to suggest that software reuse at requirements specification stage is widely practiced. The ARIFS methodology deals with these concerns supporting: (a) the reuse of incomplete specifications —obtained from transient phases of a totally formalized, iterative and incremental requirements specification process— with the aim of saving Partially supported by PGIDT01PX132203PR project (Xunta de Galicia)
specification, synthesis and formal verification efforts [4]—; and (b) the reuse of formal verification results to reduce the great computing resources needed to check the consistency of medium-large and large requirements specifications [3]. In this paper, we focus on the last goal and we show how to reuse formal verification information to improve the consistency checking process by using an application example. This proposal entails a big reduction of the formal verification necessities, because we are able to reduce the number of executions of the verification algorithm and/or to reduce the amount of states of the model where the consistency checking is needed. In fact, the application example included in this paper shows these two possibilities. This paper is organized as follows: the next section summarizes the most remarkable existing works about retrieving reusable components and about improvements in model checking techniques; Section 3 outlines the software development process where the ARIFS methodology is included; Section 4 describes the functional relationship among reusable components which allows managing the repository; in Section 5 we explain how the reuse process is tackled out; in Section 6 the application example is outlined; and, finally, a brief evaluation of the approach and future work are exposed in Section 7.
2 Related work Organizing large collections of reusable components is one of the main lacks in software reuse, because providing efficient and effective mechanisms to classify and retrieve software elements from a repository is not an easy problem. Retrieving mechanisms usually rely on the same idea: establishing a profile or a set of component’s characterizing attributes which is used to classify and retrieve them from a repository. Whenever this profile is based on formal specifications, problems derived from natural language are avoided. The typical specification matching process, which offers an exact retrieval, starts expressing the relation between two components by using a logical formula. Then, a theorem prover checks its validity, and only if the prover succeeds, the component is considered to be suitable. The vast number of proofs makes a practical implementation very hard, so in many approaches this number is usually reduced by applying other techniques like: (a) in the proposal of Zaremski and Wing [13], formal proofs are restricted to a small subset of the repository, which is previously selected by using preconditions and postconditions; (b) in REBOUND (REuse Based On UNDerstanding) tool [10] formal proofs are reduced by applying different heuristics, based on the semantic of specifications; (c) NORA/NAMMR tool [11] is basically a filter pipeline trying to ensure a plug-in compatibility, where there are used signature matching filters, rejection filters (based on model checking techniques), and, finally, confirmation filters (based on Setheo theorem prover, which does not support recursive specifications management). To sum up, current research lines focus on reusing components at latest stages of the development process, like code, and on using formal descriptions to allow an exact retrieval by applying formal proofs. On the contrary, the ARIFS methodology supports reusing formal components at the requirements specification stage, an early one, and avoiding formal proofs in the retrieval process, that is, providing an approximate retrieval based precisely in the incompleteness of the intermediate models.
On the other hand, model checking is inherently vulnerable to the rather practical problem that the number of states may exceed the amount of computer memory available, which is known as the state-space explosion problem. Several effective methods have been developed to solve this problem, although the majority of them try to reduce the state-space: (a) by a symbolic representation of state spaces using BBDs (Binary Decision Diagrams) [2]; (b) by partial-order reductions [6] which exploits the fact that for checking many properties it is not necessary to consider all possible ways in which a state space can be traversed; (c) by using equivalence and pre-order relations [8], which transforms models into equivalent, but smaller models that satisfy the same properties; and (d) by a compositional verification, that is, decomposing properties in sub-properties such that each sub-property can be checked for a part of the state space, and the combination of the sub-properties implies the required global property. Our proposal supplements the previous ones and it also try to reduce the computational necessities of model checking. The underlying idea is reusing formal verification results of the same property in other functionally similar incomplete models to the given one. Although in [5] less formalized results (simulation tests) are reused over code components (algorithms), we have not found other proposals sharing our idea of reusing formal verification information at early stages, which increases the reuse benefits.
3 Context In this section, we briefly describe the first phase of the software development process, SCTL-MUS methodology [9], where the reusing environment is going to be included. The main aim of this phase (Initial goals) is achieving a complete and consistent functional specification of the system from user’s specification (Figure 1(a)). Initial goals Requirements
SCTL New goals
MUS
Problems No
Prototype Performance
User validation
Verification SCTL−MUS
Yes Validated requirements Architectural design
Obtain initial architecture
Initial goals
Refinements and Maintenance
(a) Methodology
(b) MUS graph
Fig. 1. SCTL-MUS Methodology
In this methodology, functional requirements are specified by using the many-valued logic SCTL [9] (Simple Causal Temporal Logic). An SCTL requirement follows the syntax: Premise Consequence, which establishes a causing condition (premise); a temporal operator determining the applicability of the cause (
—referred to as simultaneously, previously and next—); and a condition which is the effect (consequence). Apart from causation, SCTL adds the concept of unspecification which is specially useful to deal with both incomplete and inconsistent information obtained by requirements capture. Although events will be true or false at the final stage, at intermediate phases of the specification process it is possible that users do not have enough information about them yet, so these events are unspecified in these phases. Therefore, it is possible specifying three different values: possible or true ( ), impossible or false () and unspecified ( ), which is the default value. SCTL requirements are automatically synthesized to obtain a model or prototype of the system by using MUS [9] (Model of Unspecified States), which allows feedback with users. MUS graphs are based on typical labeled-transitions systems, but including another facility: unspecification of its elements. This unspecification is reflected in both events and states of the graph and it is a consequence of the third value of the SCTL logic. Therefore, an event in a state of a MUS graph can be specified to be possible, to be impossible or, in its absence, to be unspecified. Consequently, a state where every single event is unspecified, is called an unspecified state. A state where it is not specified any evolution of the model is called a final state, consequently, both unspecified states and states where only false events have been specified are final states of a MUS graph. An example of these MUS graphs is shown in Figure 1(b), where the model can evolve from one state into another when an event or an action of occurs or through the special event . This special event is used whenever the user need to specify a transition, but he does not have enough information about which event is going to enable it. In the initial state of the graph 1(b), , event is specified as a possible one, that is, system evolves from this state into state whenever event occurs. System evolves from into state through an event which has not been specified yet ( ). Since is not a real event, in subsequent iterations of the requirements capture process, it will evolve to one event of , with the exception of event , because MUS graphs are deterministic ones. In state (a final state), event is an impossible one, which is denoted by , and, finally, state is a totally unspecified (and a final) state because every event in has not been specified in this state nor as a possible event neither an impossible one 1 . After the user identifies and specifies a set of new functional requirements which lead to a growth in the system functionality, it is necessary to check the consistency of the current model, that is: if the model already satisfies the new requirements; if it is not able to provide these functional requirements nor in the current iteration neither in future ones (inconsistency); or, if the system does not satisfy the requirements, but it is able to do it (incompleteness). This formal verification is made by using a model checking algorithm which provides different levels of satisfaction of an SCTL requirement in a MUS model. These levels of satisfaction are based on causal propositions: “an SCTL requirement is satisfied iff its premise is satisfied and its consequence is satisfied according to its temporal operator”. As SCTL-MUS methodology adds unspecification concept, the level of satisfaction may not be false (nor true), just as the boolean logic, in fact, it must have a
1
Because of simplicity reasons, unspecified events of a state are not represented, only of because it implies an evolution of the model.
level of satisfaction related to its unspecification (totally or partially unspecified on the MUS model). Consequently, this methodology defines six levels of satisfaction ( ), which are explained in detail in AppendixA (taken from [4]).
4 Classification of reusable components in ARIFS The ARIFS methodology enables classification, retrieval and adaptation of reusable components at the requirements specification phase of the SCTL-MUS methodology. These reusable components gather: (a) its functional specification, which is expressed by a set of SCTL requirements and modeled by the temporal evolution MUS graph; (b) verification information (Section 5) and (c) an interface or profile information, which is automatically obtained from its functional characteristics. These profiles allow classifying the reusable components according to their functional characteristics, that is, the underlying idea behind our classification mechanism is that the closer two reusable components are classified in the repository, the more functional similarities they have. Therefore, retrieval criteria must also be based on the functional similarities between reusable components and the query. In order to assess these similarities, we have defined four criteria [4] to distinguish between semantic similarities and structural ones. The most suitable criterion to reuse verification information is given by the complete and non finite traces function, denoted by . This function associates with every MUS graph a set , which is part of the interface or profile information of the component whose MUS graph is . This function is based on the traditional complete trace semantics [12] (obtaining sequences of events linked to every single evolution path of the model), being the main differences that (a) we also take into account both false events in order to differentiate them from unspecified ones, and (b) non finite evolution paths (unbounded traces and non-terminating traces) of the graph are also reflected in .
For example, figure above shows the result of applying this function to a MUS graph . In this example, has five different evolution paths: it can evolve from initial state to a final one where event is impossible through event ; from initial state to a final one through events and ; from initial state to a final one through event , an undetermined number of events (a non finite evolution path) and, finally, event ; from initial state to a final one through events , and (although trace is included in , both of them are explicitly included in because of efficient reasons in collating tasks); and from initial state through event and an infinite number of events (a non finite evolution path). 2 For , the equivalence relation is given by , and the preorder by , that
2
denotes the set of events inside the parenthesis can be repeated an undetermined number of times.
is, provides a partial order between equivalence classes or graph sets indistinguishable using -observations, so is a partially ordered set, or poset. Two graphs and are -related iff or . A subset is called a chain if every two graphs in are -related.
Fig. 2. Example of classification in ARIFS
is used to classify reusable components ( ) in the lattice after finding its correct place, like Figure 2 shows. That is, it is necessary looking for those components -related to such as is -included on them, and those components related to such as they are -included on . 3
5 What and how is verification information reused? After running the model checking algorithm, we achieve a set of levels of satisfaction of a SCTL property in every single state of a MUS graph . This information may be useful to future verifications of the same property —or a subset of it— over the same graph —or over a graph functionally close to it. However and depending on the size of the graph, the management of this amount of information may be difficult, so we also need to store it under a more manageable form. Therefore, we have defined four verification results which summarize this information:
¦ expresses that “some trace of the system satisfies eventually . of satisfaction is denoted by ¯ ¦ – £ expresses that “some trace of the system satisfies invariantly of satisfaction is denoted by ¯ £ . – ¦ expresses that “every trace of the system satisfies eventually of satisfaction is denoted by ¯ ¦ . – £ expresses that “every trace of the system satisfies invariantly . of satisfaction is denoted by ¯ £ –
” and its level
” and its level
” and its level
” and its level
To sum up, the level of satisfaction of in , denoted by ¯ , is made up of these four results: ¯ ¯ ¦ ¯ ¦ ¯ £ ¯ £ The defined classification scheme (Section 4) implies that a component is stored between reusable components whose functionalities contain or are contained by it. For
3
and are -related ( or ) iff their MUS graphs and are also -related.
instance in Figure 2, and are functional parts of , being this one a functional part of . In this situation, if we know the level of satisfaction of a property in and/or in and/or in , what is the level of satisfaction of in ? The answer of this question is stored in the deduction tables (see Appendix B, taken from [3]) and these results have been obtained after studying how to reuse verification results between two MUS graphs holding a -relationship. Whenever we need to check if an incomplete model satisfies a property , we proceed as follows: (1) retrieving the closest components to whose verification results give information about ; and (2) using the deduction tables to be able to obtain ¯ . If the available information is not enough, it is necessary to run the model checking algorithm, but this execution can be reduced depending on the recovered verification information. In fact, it is very probable that we only need to check some states of the graph and so we avoid the exhaustive analysis. ¯
¯
¯
¯
On the other hand, whenever we have new verification information of an incomplete model, we spread out this data across the lattice to improve the learning process of the repository. This expansion is done off-line, so it does not affect the efficiency of the reusing environment, for instance, figure above shows as the verification information linked to , , and is updated after is stored in the repository.
= connect = tx_msg = confirm = rx_ack
= release = t_out
= tx_ack = loss
= rx_nack = rx_msg = tx_nack = error
Table 1. MUS graphs of several reusable components of the repository
6 Applying the methodology: An application example In this section we apply the described methodology to reduce formal verification tasks at the requirements specification stage of the system modeling a stop-and-wait com-
munication protocol, where data traffic is simplex and only data frames may be damaged, but it cannot be completely lost. To sum up, the connection is stablished whenever the sender receives a confirm frame after having sent a connect frame. After that, the sender fetchs a data frame (event tx_msg) and it must wait until an acknowledgment (ack) frame arrives before looping back and fetching the next packet. If the sender receives an nacknowledgment (nack) frame, it sends the frame again, and this process would be repeated until the frame finally arrived intact. After the sender has transmitted all the data frames, the sender ends the connection transmitting the release frame.
connect
release
error
confirm error tx_msg
rx_msg error
rx_msg tx_ack
error
rx_nack
rx_msg
rx_ack
tx_nack
(b) Part of the -lattice
(a) MUS model
Fig. 3. MUS model and its correct position in the -lattice
We assume that the functionality of our communication protocol is being specified, and the MUS model of the system —which is in an intermediate iteration of the requirements specification phase— is shown in Figure 3(a). At this intermediate stage of the requirements capture process, we need to know if the incomplete model, , verifies the properties connect confirm and rx_msg error.
connect confirm expresses the following
Verification of ½ Property condition: “just after a connection request occurs, an acceptation of this connection may occurs”. Hence, we need this property is satisfied by every single possible evolution path of the system, that is, it is a safety property [1]. We retrieve from our repository (obviously, it is impossible to detail each reusable component here) the closest reusable components to storing verification information about . We have obtained (Figure 3(b)), whose MUS graphs are shown in Table 1 —where real names of every single event had been replaced by a letter to make it more legible—. Their verification results are as follows: ¯ , ¯ and ¯ . Besides that, we know that ¯ and ¯ . Therefore, after applying the results given by the deduction tables (Appendix B), we obtain the following results:
¦
1. As ¯ ¦ and ¯ ¦ , then ¯ Table 3.(a)). 2. As ¯ ¯ , then ¯ ¦
(see
(see Property 1).
From the information given by (¯ £ ), we deduce that ¯ £ (see Table 4.(a)). As ¯ £ ¯ £ , then ¯ £ .4 Finally and as consequence of the results obtained by applying the deduction tables, we know the following result:
¯
To sum up, we know, without running the model checking algorithm, that is a liveness property [1] in —this property is satisfied by every single evolution path of the model (¯ ¦ )— and, although it cannot be considered as a safety prop erty (¯ £ ), there is not any information prohibiting that if the functional specification increases, it would became true (Appendix A).
Verification of ¾ Property rx_msg error expresses that “in every state of the model where a data reception is enabled, an error must also be allowed”. This property must be satisfied by every single state of the system unless the one marked by an arrow in Figure 3(a): in this case an error must not be allowed, because the data frame has not been retransmitted. Therefore, we would like to be a liveness property, but not a safety one. As in the previous section, the following information is recovered: ¯ , ¯ and ¯ . From which the following verification information can be deduced:
¦ £ £
1. As ¯ ¦ ¯ 2. ¯ £ ¯ ble 3.(c)). 3. As ¯ £ ¯
¦ £ , then, ¯ £
, then ¯ ¯
(see Table 3.(a)). (see Ta-
(see Table 3.(d)).
On the other hand, the verification information linked to does not add more information (see Table 4). Therefore, the values of ¯ are the following ones:
¯
, where
According to these results, we know that it is not a safety property —just as we wanted, ¯ £ — and it is satisfied at least for one of the evolution paths of (¯ ¦ ) —but we need this property to be a liveness one, that is, it must be satisfied by every single evolution path of the model. However, applying the
, so to deduction tables, we do not know any information about ¯ ¦ know this result, we would need to apply the model checking algorithm. However, we will try to reduce the state-space of before running the model checker. Firstly, we need to know which of the recovered components is the closest one to according to criterion, that is, which of them need less adaptation effort —addition and/or elimination of sequence of events— to make its functionality the same to .
4
partiall ordering is defined in [4] and it is not included here because of space reasons.
With this aim, we apply the functional adaptation function 5 (see Appendix C), being the most similar to according to criterion —Figure (a) of Table 2 shows the evolution path which has to be added to to make its functionality the same to —. Therefore, there are three states of which are different from —circled in Figure (b) of Table 2—, being responsible for any difference between ¯ and ¯ .
(b) States which are different in and
(a) Functional excess of regarding
Table 2. Refining the state-space
As is totally unspecified in and in (¯ ¯ ), these two states cannot modify the values of ¯ from ¯ . However, ¯ , hence, we need to obtain the level of satisfaction of in the equivalent state of in (Figure (b) of Table 2), that is, we need to run the model checking algorithm on the state of . After that, we obtain that ¯ , hence state of does not have any influence in the verification result of in , which entails that ¯ ¯ :
¯
where it is clear that ¯ ¦ , so the property is a liveness one in the current model of the system. To conclude, we have obtained the formal verification results of the property in the model without running the model checking algorithm all over the state-space of , in fact, we only need to run the algorithm in one state of this space, that is, only the 10% of the states were formally checked.
7 Evaluation of the approach and future work The work introduced in this paper focuses on reusing verification information of incomplete models at the requirements specification stage. We believe reusing this kind 5
, where —see [4].
of information at early stages increases the reuse benefits and improves the software process. To support this assertion, we need to quantify these benefits, that is, obtaining the computational cost of reusing and comparing it with the cost of applying directly the model checking algorithm. However, quantifying the cost of reusing is not easy because it does not only depend on the complexity of the reusing algorithms and on the amount of reusable components in the repository, but also on their functional characteristics, which are more difficult to take into account. Besides that, its neccesary to assess some parameters like recall, precision and response time of the ARIFS methodology which help us to evaluate the approach. In fact, nowadays we are working in a prototype tool, ARIFS tool, to obtain these values. In order to continue this proposal, we are working on: (a) a compositional verification, that is, decomposing properties in sub-properties such that it is possible to reuse verification information about each sub-property, and the combination of the subproperties implies the required global property; (b) the possibility of reusing verification results of functionally similar properties with the given one; and (c) obtaining heuristics which enable predicting the values we need to quantify the benefits of reusing verification information in this environment.
References 1. Bowen Alpern and Ferd B. Schneider. Recognizing Safety and Liveness. Distributed Computing Journal, 2:117–126, 1987. 2. R. Bryant. Graph-based Algorithms for Boolean Function Manipulation. IEEE Transactions on Computers, 35(8):677–691, 1986. 3. Rebeca P. Díaz Redondo, José J. Pazos Arias, and Ana Fernández Vilas. Component-Based Software Quality: Methods and Techniques, volume 2693 of Lecture Notes in Computer Science (LNCS), chapter Reuse of Formal Verification Efforts of Incomplete Models at the Requirements Specification Stage, pages 326–352. Springer Verlag, 2003. 4. Rebeca P. Díaz Redondo, José J. Pazos Arias, Ana Fernández Vilas, and Belén Barragáns Martínez. ARIFS: an Environment for Incomplete and Formal Specifications Reuse. In Proc. of Workshop on Formal Methods and Component Interaction., volume 66 of Electronic Notes in Theorethical Computer Science. Elsevier Science, July 2002. 5. I. Keidar, R. Khazan, N. Lynch, and A. Shvartsman. An Inheritance-Based Technique for Building Simulation Proofs Incrementally. In 22nd International Conference on Software Engineering (ICSE), pages 478–487, Limerik, Ireland, June 2000. 6. R. Kurshan, V. Levin, M. Minea, D. Peled, and H. Yenigün. Static Partial Order Reduction. Tools for the Construction and Analysis of Systems, LNCS 1394, pages 345–357, 1998. 7. W. Lam, J. A. McDermid, and A. J. Vickers. Ten Steps Towards Systematic Requirements Reuse. Requirements Engineering, 2:102–113, 1997. Springer Verlag. 8. K. L. McMillan. A Technique of State Space Search based on Unfolding. Formal Methods in System Design, 6:45–65, 1995. 9. José J. Pazos Arias and Jorge García Duque. SCTL-MUS: A Formal Methodology for Software Development of Distributed Systems. A Case Study. Formal Aspects of Computing, 13:50–91, 2001. 10. J. Penix and P. Alexander. Efficient Specification-Based Component Retrieval. Automated Software Engineering: An International Journal, 6(2):139–170, April 1999. 11. J. Schumann and Fischer. NORA/HAMMR: Making Deduction-Based Software Component Retrieval Practical. In Proc. of the 12th ASE, pages 246–254, 1997.
12. R. J. van Glabeek. Handbook of Process Algebra, chapter The Linear Time - Branching Time Spectrum I: The Semantics of Concrete, Sequential Processes. Elsevier Science, 2001. 13. A. M. Zaremski and J. M. Wing. Specification Matching of Software Components. ACM Transactions on Software Engineering and Methodology, 6(4):333–369, October 1997.
A
Levels of satisfaction of SCTL-MUS methodology
This appendix outlines a brief description of the six levels of satisfaction of the SCTLMUS methodology and it was taken from [4]. As SCTL-MUS methodology adds unspecification concept, the level of satisfaction may not be false (nor true), just as the boolean logic, in fact, it must have a level of satisfaction related to its unspecification (totally or partially unspecified on the MUS model). Consequently, this methodology defines six different levels of satisfaction, which can be partially ordered according to a knowledge level ( ) (Figure 4) as follows:
–
are the highest knowledge levels. We know at the current stage of the
model the final level of satisfaction of the property: or true means the requirement is satisfied; or false implies the requirement is not satisfied; and or contradictory or not applicable means the requirement cannot become true or false. – are the middle knowledge levels. Although at the current stage of the model, the property is partially unspecified, we know its satisfaction tendency. That is, for the current value , in a subsequent stage of specification, the level of satisfaction cannot became (true), it will be ; and for the current value , in a subsequent stage of specification, the level of satisfaction cannot became (false), it will be . – is the lowest knowledge level. The property is totally unspecified at the current model’s stage and we do not know any information about its future behaviour, that is, it can became in a subsequent stage of specification.
Highest levels
Knowledge
Lowest level
Lowest level
Truth
Highest level
Fig. 4. Knowledge and Truth partial orderings among levels of satisfaction.
In short, the level of satisfaction of an SCTL requirement varies according to its closeness to the true (or false) level of satisfaction. According to this truth ordering (Figure 4), is a quasi-boolean lattice with the least upper bound
operator , the greatest lower bound operator , and the unary operation (defined by horizontal symmetry). The 4-tuple
has the structure of the De Morgan algebra and it is called algebra of MPU [9] (Middle Point Uncertainty).
B
Deduction tables
This appendix contains the deduction tables (Tables 3 and 4) which store how to reuse verification information between two MUS graphs holding a -relationship, and property 1, directly related to this subject. This appendix was taken from [3].
Table 3. Reusing ¯ information to know ¯ , where (a) Results obtained from ¯
¦
(b) Results obtained from ¯
¦
¯ ¦
¯ £
¯ ¦
¯ £
¯ ¦
¯ ¦
¯ ¦
¯ ¦
¯ ¦
¯ £
¯ ¦
¯ ¦
¯ ¦
¯ ¦
(c) Results obtained from ¯
£
(d) Results obtained from ¯
£
¯ £
¯ £
¯ £
¯ £
¯ £
¯ ¦
¯ £
¯ ¦
¯ £
¯ £
¯ £
¯ ¦
¯ £
¯ £
Property 1. Let be an SCTL property which is satisfied in the initial state of a MUS . graph , that is, ¯ , then we know that ¯ ¦
Proof. Since ¯ and since the initial state of a MUS graph is contained in every single trace of the graph, then ¯ ¦ . According to the information . stored in Table 3, therefore ¯ ¦
Table 4. Reusing ¯ information to know ¯ , where (a) Results obtained from ¯
¯ ¦
¯ £
¯ £ or
¯ £
£
¯ ¦
(b) Results obtained from ¯
¯ ¦
¯ ¦ ¯ ¦
¯ £
¯ £
¯ £
¯ £
¯ ¦ ¯ ¦
¯ ¦ or
¯ ¦
¯ £ ¯ £
C
¦
¯ ¦ ¯ ¦ ¯ £ ¯ £
Functional adaptation function
This appendix contains the definition of the functional adaptation function (Definition 4) which allows us to obtain the adaptation effort between two MUS graphs, that is, the amount of sequence of events that must be added and removed to make their functionality the same. It was taken from [4].
Definition 1. Let and be two reusable components, the functional consensus between them, denoted by , is defined as , where is the MUS graph linked to and the MUS graph linked to .
Definition 2. Let and be two reusable components, the functional deficit funcion of regarding , denoted by Æ , is defined as Æ , where is the MUS graph linked to and the MUS graph linked to .
Definition 3. Let and be two reusable components, the functional excess function of regarding , denoted by , is defined as , where is the MUS graph linked to and the MUS graph linked to .
Definition 4. Let and be two reusable components, the functional adaptation function between them, denoted by , is defined as Æ , where is the MUS graph linked to and the MUS graph linked to . expresses the functional characteristics that being specified by the are not specified by and viceversa.
