About this Journal Submit a Manuscript Table of Contents
Advances in Software Engineering
Volume 2011 (2011), Article ID 869182, 13 pages
http://dx.doi.org/10.1155/2011/869182
Research Article

Towards Support for Software Model Checking: Improving the Efficiency of Formal Specifications

1Department of Electrical, Computer, Software, and Systems Engineering, Embry-Riddle Aeronautical University (ERAU), Daytona Beach, FL 32114, USA
2Department of Computer Science, University of Texas at El Paso (UTEP), El Paso, TX 79968, USA

Received 10 December 2010; Accepted 3 March 2011

Academic Editor: Phillip Laplante

Copyright © 2011 Salamah Salamah et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract

The Property Specification (Prospec) tool uses patterns and scopes defined by Dwyer et al., to generate formal specifications in Linear Temporal Logic (LTL) and other languages. The work presented in this paper provides improved LTL specifications for patterns and scopes over those originally provided by Prospec. This improvement comes in the efficiency of the LTL formulas as measured in terms of the number of states in the Büchi automaton generated for the formula. Minimizing the size of the Büchi automata for an LTL specification provides a significant improvement for model checking software systems using such tools as the highly acclaimed Spin model checker.

1. Introduction

The process of model checking a system consists of developing a model of the system to be verified and writing specifications in a temporal logic such as Linear Temporal Logic (LTL) [1] or Computational Tree Logic (CTL) [2]. In automata-based model checking, both the model and the complement of the temporal specification are represented by a special type of state machine called a Büchi Automaton (BA) [3]. To check the consistency of with , the model checker calculates the intersection of and where is the complement of . If the intersection is empty, then is consistent with . In other words, if and each represent a set of specifications and if , then the system satisfies the specification; otherwise, the system is inconsistent with the specification and a counter-example is returned.

The process of writing formal specifications is not easy because of the required mathematical sophistication and depth of knowledge in the specification language. For this reason, tools that simplify the creation of formal specifications in logics such as LTL are of interest to the model checking community and others. In the case of automata-based model checkers such as Spin [4], it is important that these tools generate efficient formulas, since the model checker complements the formulas, translates the result into a BA, and intersects the BA with the automaton of the system. The size of the automaton that results from the intersection of two automata has as its upper bound the product of the number of states in each of the two. One way to avoid the classical problem of state space explosion is to minimize the number of states generated by the negation of the specification. This will reduce the number of states generated by the automaton of the intersection, and as a result, it will reduce the time required to model check a software system.

The Property Specification (Prospec) [57] builds on the Property Specification Patterns system (SPS) [8, 9], and it uses property pattern and scope to assist in the specification of formal properties in LTL as well as other languages. Patterns are high-level abstractions that provide descriptions of common properties, and scopes describe the extent of program execution over which the property holds. Prospec also introduces the notion of composite propositions to allow for the definition of more complex behavior to represent the behaviors for patterns and scopes.

This paper introduces more efficient LTL formulas for patterns and scopes than those originally generated by Prospec. In defining the new formulas, we tried to limit the number of temporal operators in a formula because we believe this reduces the number of states in the never-claim. The formulas are compared in terms of the number of states in the never-claim generated by the negation of these formulas since it is actually the complement of a formula that the model checker uses. To generate Büchi automata, we used the model checker SPIN, and the LTL to BA translators: LTL2BA [10], the Temporal Message Parlor [11], and LTL2NBA [12], all of which efficiently convert LTL specifications into BAs. Notice that some of these tools produce a BA in the form of a never-claim, which is a specific representation of BA used by the model checker Spin. In this article we use the terms Büchi automata and never-claims interchangeably. This paper also shows an approach for proving the equivalence of different LTL formulas. Finally, this paper describes the impact that more efficient formulas have when using composite propositions [6] to define pattern and scope limits.

The paper first presents a background on LTL and Büchi automata (BA), including the semantics of the languages. The Prospec tool is introduced in Section 3. Section 4 describes the new formulas and the process used to verify the semantic equivalence of the two sets of formulas. Section 4 also provides the results of the comparisons of the formulas. Finally, the impact of the work on composite propositions is presented in Section 5 followed by brief discussion and references.

2. Background

2.1. Linear Temporal Logic

This section briefly describes Linear Temporal Logic (LTL) and its semantics. A more detailed description of LTL can be found in Manna [13].

Temporal Logic has been used to verify concurrent systems. There are three well used types of temporal Logic: Linear Temporal Logic (LTL), Computational Tree Logic (CTL), and CTL* [3]. Both LTL and CTL are subsets of CTL*. While CTL allows for branching type of behavior (i.e., semantically, formulas are defined both using the universal and existential quantifiers), LTL formulas describe specific path behavior (i.e., semantically, formulas are defined only using the universal quantifier). Formulas in this paper deal only with LTL.

LTL is used in various model checkers such as SPIN [4], NUSMV [14], and Java Path-Finder [15] and is also used in runtime verification of Java programs [16].

In LTL, a temporal formula is constructed inductively from a set of propositions by applying Boolean connectives and and temporal operators next ( ) and until ( ) as follows. (i)A proposition is a temporal formula.(ii)If and are temporal formulas, then the followings are also temporal formulas: (i) , (ii) , (iii) , (iv) .

A temporal formula that makes use only of Boolean connectives and is called a state formula, whereas a formula that makes use of temporal operators and is called a temporal formula.

Let be a set of propositions; let be an infinite sequence of states or computation, denoted by : , let be a set of states; let be an interpretation such that for all , specifies the propositions that are true in state . For a state formula, the satisfaction relation is defined as follows: for a state and a proposition in , satisfies , denoted , if and only if . In addition, an inductive definition for the notion that a computation satisfies formula at , denoted , follows [1, 13]: (i) if and only if , where is a state formula, (ii) if and only if , (iii) if and only if or , (iv) if and only if , (vi) if and only if for some , and for all .

Additionally, the temporal operators (eventually, always, and weak-until) are derived as follows: (i) , (ii) , (iii) .

2.2. Büchi Automata

Classical LTL model checking is based on a variation of the classic theory of finite automata [4]. While a finite automaton accepts only terminating executions, model checking requires a different type of machines that can handle executions that might not terminate. Such machines are necessary to model nonterminating systems such as operating systems, traffic lights, or ATMs. One such machine is a Büchi automaton. A Büchi automaton (BA) is a tuple ( , , , , ), where (i) is a finite set of states, (ii) is a set of initial states, (iii) is an alphabet, (iv) is a transition function, (v) is a set of accepting states.

An execution is a sequence , where for all and for all , . A finite execution is an accepting execution if it terminates in a final state . An infinite execution, also called an -execution or -run, is accepting if it passes through a state infinitely often. An empty BA (accepts no words) is one that either terminates in a state that is not an accepting state or has no accepting state that is reachable from the initial state and that is visited infinitely often. The set of executions accepted by a BA is called the language of the BA.

Languages of BAs represent a superset of those of LTL; every LTL formula can be represented by a BA. When a BA is generated from an LTL formula, the language of the BA represents only the traces accepted by the LTL formula. For example, the BA in Figure 1 represents the language accepted by the LTL formula ( ). This formula specifies that holds in the initial state of the computation, or holds until holds. The language of the BA in Figure 1 accepts the set of traces {b…, ab…, aab…, …, aaab}. Notice that each of these traces passes through the accepting state Final. This state is both reachable from the initial state and is visited infinitely often (by virtue of the self-transition marked 1).

869182.fig.001
Figure 1: BA for “ ”.

Various work has been done on the translation of LTL to BA to reduce the number of states in the resulting BA and to speed up the process of the BA generation. This paper compares three LTL to BA translators (along with the SPIN model checker) in the number of states in the BA generated from those LTL formulas for patterns and scopes. (i)Temporal Message Parlor (TMP) [11] is the work of Kousha Etessami at Lucent Technologies. (ii)LTL2BA [10] is the work of Denis Oddoux and Paul Gastin at the University of Paris 7, France. (iii)LTL2NBA [12] is the work of Carsten Fritz of the Department of Computer Science at Christian-Albrechts University.

3. Prospec

The Property Specification tool (Prospec) [57] builds on the Specification Patterns System (SPS) [8, 9] by facilitating the identification of SPS patterns and scopes as well as validation of specifications. SPS defines patterns and scopes to assist the practitioner in formally specifying software properties. Patterns capture the expertise of developers by describing solutions to recurrent problems [17]. Each pattern describes the structure of specific behavior, defines the pattern's relationship with other patterns, and defines the scope over which the property holds.

The main patterns defined by SPS are universality, absence, existence, precedence, and response. Universality states that property is true at every point of the execution; absence states that is never true during the execution; existence states that is true at some point in the execution; precedence states that holds before holds; response states that if holds, then must hold at a future state. Response properties represent a temporal relation called cause-effect between two propositions. Prospec displays traces of computation to illustrate the subtle issues that exist within the different patterns and scopes, and it displays a decision tree to guide the user through a series of decisions in selecting the appropriate pattern and/or scope. Given a computation represented as a sequence of states, and a finite set of events , a trace of computation is a list indicating, for each moment of time , which events from the set occur at . Figure 2 shows the Prospec window for selecting a pattern and the traces of computation that are given to elucidate each pattern. Prospec enhances the definition of patterns and scope characteristics provided in the SPS website [18] by explicitly defining the relationships among the proposition that define a pattern and/or a scope and the boundaries defined by each scope. Tables 1 and 2 give those characteristics for pattern and scope, respectively, as they appear in the Prospec tool. These are the characteristics that were used by Salamah et al. [19] to verify the correctness of the LTL formulas for patterns and scopes. Prospec extends SPS by introducing a classification for defining sequential and concurrent behavior. This is accomplished by including composite propositions (CPs) as shown in Figure 3. Section 4 discusses composite propositions in more detail. While Prospec builds on SPS in defining the mapping of patterns and scopes into LTL, it makes some changes to those LTL formulas for patterns and scopes defined in SPS. (Comparing the new formulas in Section 4 with the original SPS formulas showed that the new formulas were at least as efficient in all cases with the exception of the case of the Response pattern within the After Until scope in which SPS formula produced one fewer state in the never-claim as produced by LTL2BA, LTL2NBA, and TMP). Salamah et al. [19] provide a listing of those modifications and the justification behind the changes. Table 3 presents Prospec's LTL mappings for each pattern and scope combination. These formulas along with the ones defined in Section 3 are the ones being compared in this paper.

tab1
Table 1: Summary of characteristics for patterns in Prospec.
tab2
Table 2: Summary of characteristics for scopes in Prospec.
tab3
Table 3: Prospec's original LTL formulas for pattern and scope.
869182.fig.002
Figure 2: Prospec's pattern screen.
869182.fig.003
Figure 3: Prospec's composite proposition screen.

Note that Prospec added the definition of strict precedence, which is not available in SPS. This pattern describes the situation where strictly precedes , where and are events or conditions. Unlike the regular precedence pattern, and cannot hold at the same state in this pattern. Use of Strict Precedence enforces that and cannot hold at the same state.

4. New Pattern Formulas

The goal of the work presented by this paper is to improve the efficiency of the LTL specifications generated by Prospec. The efficiency is measured by the number of states in the BA corresponding to the negation of LTL specification. The BAs were produced using the SPIN model checker Version 4.2.7, and the LTL to BA translation tools LTL2BA, LTL2NBA, and the Temporal Message Parlor (TMP), all of which are available at a website maintained by Carsten Fritz [20].

In order to reduce the number of states in the BA, our goal is to reduce the number of temporal operators within each formula. We were able to achieve this in 17 out of 30 formulas originally defined by Prospec. Table 4 lists the new improved formulas, and Table 5 lists the results of the comparison between Prospec's original formulas and the new ones. In all the cases where we were able to reduce the number of temporal operators, the BAs generated by SPIN contained fewer states. Only in the case of the Response pattern with an After Until scope did the new formula generate more states when used by the three BA generators. All the translation tools produced BAs with the same number of states for each new formula except in the case of the strict precedence with the after until scope. In this case, the generated BAs by LTL2BA, TMP, and LTL2NBA produced one fewer state than the one generated by SPIN. This is significant, as it allows SPIN users to use the new formulas without having to use the other translators to produce never-claims that have to be inserted into the Promela code.

tab4
Table 4: Prospec's new LTL formulas.
tab5
Table 5: Comparison results 1.
4.1. Equivalence of LTL Formulas

An approach to demonstrating the equivalence of two LTL formulas is to compare the languages of the BAs generated from them. If the languages are identical, then the two LTL formulas are equivalent. To show this, we show that the first language is a subset of the second, and that the second is a subset of the first.

Given two LTL formulas and , let be the BA for and let be the BA for . Label each transition in and with the names of the propositions that are true in the state entered by the transition. Let be the union of all the transition labels in and . Let be the language accepted by and let be the language accepted by . To show that and are equivalent, we show that . (Since is empty, must not contain any element of . Since and are both subsets of , must contain every element of . Thus, . Similarly, . Thus, . and are equivalent if they accept the same language, thus , and .)

Given two formulas and , where is the original Prospec formula and is the new formula, we used LTL2BA to generate a BA for ( ) and a BA for ( ). To assert that we have to check that BA and BA are both empty. To do this we developed a simple computer tool that checks the emptiness of a BA.

4.1.1. Tool for Checking Emptiness

By definition a BA is empty if it does not contain a reachable accepting state that is visited infinitely often [3]. The LTL Validation Tool is designed to ensure that a given LTL formula is valid (i.e., its BA contains at least one reachable accepting state that is visited infinitely often). In this work, the tool is used to prove the equivalence of two formulas. As discussed above we show equivalence of two LTL formulas and by checking that resulting BAs for ( ) and ( ) are both empty.

This validation tool makes use of LTL2BA’s Java interface (JLTL2BA) to translate the formulas ( ) and ( ) into the corresponding BAs. Once the BAs are available, the tool tries to assert that there are no reachable accepting states that are visited infinitely often. This is done by first finding all states reachable from every given state, then by linking these together to form cycles. Should the tool find a single acceptance cycle, that is, an acceptance state which is within a cycle then we declare that the BA is not empty.

Figure 4 shows the never-claim generated by the LTL Validation tool (through interfacing with LTL2BA) for the LTL formula “ ” and the result generated by the tool to check for the emptiness of the BA (never-claim). Obviously the BA for this formula is not empty, and as a result the tool states that the formula is Valid (i.e., there is a reachable acceptance state that is within a cycle). Figure 5, on the other hand, shows the never-claim and the tool's result for the formula . This formula is the result of ANDing the negation of Prospec's original LTL formula for Universality of within the After Until scope with the new LTL formula for the same pattern/scope combination. The result returned by the tool specify that there is no reachable acceptance state that is within a cycle (i.e., the BA is empty). Figure 6 shows the graph of the never-claim in Figure 5.

869182.fig.004
Figure 4: LTL validation tool's output for the formula .
869182.fig.005
Figure 5: LTL validation tool's output for the formula .
869182.fig.006
Figure 6: LTL2BA generated BA for .

Similarly, we used the LTL Validation tool to generate the BA for the LTL formula of ANDing Prospec's original LTL formula for Universality of within the After Until scope with the negation of new LTL formula for the same pattern/scope combination. Figure 7 shows the graph of the never-claim for the formula . This BA obviously does not contain a cycle that passes through an accepting state. The only accepting state in the BA is accept-S3. Although this state is reachable from the initial state, it is not visited infinitely often (i.e., there is no cycle that contains this state). As expected, the LTL Validation tool returned the message “There’s no reachable acceptance cycle within this BA”. Since both the BAs for ANDing the negation of Prospec's original LTL with the new LTL formula and for ANDing Prospec's original LTL formula with the negation of the new LTL formula are both empty, we conclude that both formulas are equivalent.

869182.fig.007
Figure 7: LTL2BA generated BA for .

In our work we performed the above mentioned procedure for all the new and original formulas in Tables 3 and 4, and the results showed in every case that the new formula is semantically equivalent to the original one.

5. Impact on the Use of CP

Mondragon et al. [7, 21] introduced composite propositions (CPs) classes to define the structure of multiple propositions to capture sequential and concurrent behavior. The work provided a CP taxonomy that can be used in the property elicitation and specification process. The taxonomy guides practitioners in formally specifying properties, illuminating the subtleties associated with multiple events and conditions. When relations have not been carefully analyzed, CP classes can expose incompleteness or ambiguities.

CP classes defined as conditions are used to describe concurrency, and those defined as events are used to describe activation or synchronization of processes or actions. Table 6 presents the semantics of the CP classes in LTL.

tab6
Table 6: CP semantics in LTL (subscripts C and E stand for condition and event, resp.).

CP classes can be used to define boundaries of scopes and patterns with multiple propositions. For instance, an ordered sequence can define the left boundary of an after scope, and multiple events can define the cause part of a response pattern. The naïve use of CP classes in LTL formulas can result in a state explosion when using a model checker like SPIN. It is important to start with efficient LTL formulas such as the ones presented in Table 4 and to build on them when using these CP classes; otherwise the BAs generated by the LTL formulas would be too large to handle by the model checker. For example, consider the following property of an Automated Teller Machine (ATM): “After a user selects a withdrawal transaction, user's account is updated, money is dispensed, receipt is printed, and ATM card is returned.” Assume the following symbol assignments; “ ”: withdrawal transaction is selected, “ ”: account is updated, “ ”: money is dispensed, “ ”: receipt is printed, and “ ”: card is returned.

This property can be described using the of pattern within the After scope where is the CP class EventualC. ( might also be of type Strict EventualC depending on the specification). , and is . Using direct substitution in the original Prospec formula to specify this property the generated formula is . The negation of this formula produces a BA with (i)40 states using SPIN, (ii)9 states using LTL2NBA and TMP,(iii)17 states using LTL2BA.

On the other hand, by direct substitution in the new formula, then the generated LTL formula is . The negation of this formula produces a BA with (i)6 states using SPIN, (ii)5 states using LTL2NBA and TMP, (iii)9 states using LTL2BA.

The previous example shows that although the difference in the number of states generated by the original LTL formulas in Table 3 and those in Table 4 might seem negligible, this difference becomes more significant when using the notion of CP classes to specify properties.

To further prove this point, Table 7 provides a sample comparison of the original and new formulas when some propositions are replaced by certain CP classes. The table shows the number of states generated by SPIN, LTL2NBA, TMP, and LTL2BA for formulas of patterns and scopes using CP. Note that these values were generated running the tools on the negated formulas for the specified pattern and scope. Old indicates Prospec's original formula, and New indicates the new formula. In Table 7 only one of the propositions was replaced by a CP class at a time. In generating this sample, we only used three of the CP classes: ParallelE, EventualC, and Strict EventualC. We used these CP classes in replacing one of the propositions in four of the pattern/scope combinations; Absence of After , Existence of After , universality of After , and Responds to After . The choice of the CP classes and the pattern/scope combinations was based on the fact that direct substitution of the CP classes into the formulas for these pattern/scope formulas was possible. The CP class replacing a proposition is indicated by the subscript attached to the proposition. The number in the subscript refers to the number of the CP class in Table 6. Each CP class was comprised of two or three propositions. The goal was to include three propositions in each CP class; however in some cases some translation tools (mostly TMP and SPIN) could not generate BAs for the old Prospec formulas with CP classes containing three propositions. Those cases where CP classes were made of only two propositions are indicated with the symbol(*).

tab7
Table 7: Comparison results 2.

6. Discussion

Tools that assist in the generation of formal specifications in LTL are important to the model checking community as they relieve the user from the burden of writing specifications in a language that is hard to read and write. Without the help of tools such as Prospec, the user might create faulty specifications. These tools must generate specifications that correspond to the intent of the user. Prospec was demonstrated to provide such support [19]. It is also important that these tools generate efficient formulas, since one of the main challenges of model checking is the state explosion problem. The smaller the size of the automata an LTL formula generates, the less likely that this problem will occur. Although this might not appear significant in the basic pattern-scope formulas as generated originally by Prospec, an example and a sample comparison given in the previous section show the effect on the number of states generated when using less efficient formulas as the base formulas when incorporating CP classes. The sample comparison also shows that in some cases, some translation tools could not generate BAs for the old Prospec formulas in which one of the propositions was replaced with CP classes containing three propositions.

The new formulas provided by this work generate BAs with fewer states in almost all pattern/scope combinations regardless of LTL to BA translator used. In addition, the BAs of the new formulas generated by SPIN seem to always be comparable to those generated by the other more efficient translators. This is significant to SPIN users, since those users do not need to use different LTL to BA translators and manually insert the resulting never-claim into the Promela code.

Another result of this work is that we are able to provide the user with more than one LTL mapping to the same pattern-scope combination. In some cases we can provide the user with three LTL formulas (considering the formulas provided by SPS) for a specific pattern and scope (Absence of Before , e.g.). This, along with the detailed descriptions of patterns and scopes (such as timelines) provided by the Prospec tool, enhances a user's understanding of LTL and can be used as an educational tool. Table 8 shows the formulas generated using the original Prospec formulas while Table 9 provides those generated using the new formulas.

tab8
Table 8: LTL formulas generated using the original Prospec's formulas.
tab9
Table 9: LTL formulas generated using the New Prospec's formulas.

Acknowledgments

The authors would like to thank Gerard Holzmann for his patience and help in answering many of our questions. They also would like to thank Carsten Fritz and Bjørn Teegen for making it possible to easily visualize and compare the different LTL to BA translations through the development of the website mentioned earlier in the paper. This work was partially supported by National Science Foundation grants HRD 0734825 and CNS 1042341.

References

  1. Z. Manna and A. Pnueli, “An anchored version of the temporal framework,” in Proceedings of the REX Workshop, vol. 354 of LNCS, Springer, Mook, The Netherlands, May 1989.
  2. F. Laroussinie and PH. Schnoebelen, “Specification in CTL + past for verification in CTL,” Information and Computation, vol. 156, no. 1-2, pp. 236–263, 2000. View at Publisher · View at Google Scholar · View at Scopus
  3. E. M. Clarke, O. Grumberg, and D. A. Peled, Model Checking, MIT Publishers, Cambridge, Mass, USA, 1999.
  4. G. J. Holzmann, The SPIN Model Checker: Primer and Reference Manual, Addison-Wesley Professional, Boston, Mass, USA, 2004.
  5. O. Mondragon, A. Q. Gates, and S. Roach, “Prospec: support for elicitation and formal specification of software properties,” in Proceedings of the Runtime Verification Workshop, O. Sokolsky and M. Viswanathan, Eds., vol. 89, ENTCS, Boulder, Colo, USA, July 2003.
  6. O. A. Mondragon and A. Q. Gates, “Supporting elicitation and specification of software properties through patterns and composite propositions,” International Journal of Software Engineering and Knowledge Engineering, vol. 14, no. 1, pp. 21–41, 2004. View at Publisher · View at Google Scholar · View at Scopus
  7. O. Mondragon, Elucidation and specification of software properties through patterns and composite propositions to support formal verification techniques, Ph.D. thesis, The University of Texas, El Paso, Tex, USA, 2004.
  8. M. B. Dwyer, G. S. Avrunin, and J. C. Corbett, “Property specification patterns for finite-state verification,” in Proceedings of the 2nd Workshop on Formal Methods in Software Practice, pp. 7–15, Clearwater Beach, Fla, USA, March 1998. View at Scopus
  9. M. B. Dwyer, G. S. Avrunin, and J. C. Corbett, “Patterns in property specifications for finite state verification,” in Proceedings of the 21st International Conference on Software Engineering, pp. 411–420, Los Angeles, Calif, USA, May 1999. View at Scopus
  10. D. Oddoux and P. Gastin, “Fast LTL to Büchi automata translation,” in Proceedings of the 13th International Conference on Computer Aided Verification (CAV '01), Paris, France, July 2001.
  11. K. Etessami and G. Holzmann, “Optimizing büchi automata,” in Proceedings of the 11th International Conference on Concurrency Theory, August 2000.
  12. C. Fritz, “Constructing büchi automata from linear temporal logicusing simulation relations for alternating büchi automata,” in Proceedings of the Eighth Conference on Implementation and Application of Automata, Santa Barbara, Calif, USA, July 2003.
  13. Z. Manna and A. Pnueli, “Completing the temporal picture,” Theoretical Computer Science, vol. 83, no. 1, pp. 97–130, 1991. View at Scopus
  14. A. Cimatti, E. M. Clarke, F. Giunchiglia, and M. Roveri, “NUSMV: a new symbolic model verifier,” in Proceedings of the International Conference on Computer Aided Verification (CAV '99), Trento, Italy, July 1999.
  15. K. Havelund and T. Pressburger, “Model checking Java programs using Java PathFinder,” In- ternational Journal on Software Tools for Technology Transfer, vol. 2, no. 4, pp. 366–381, 2000.
  16. V. Stolz and E. Bodden, “Temporal assertions using aspectJ,” in Proceedings of the Fifth Workshop on Runtime Verification, The University of Edinburgh, Scotland, UK, July 2005.
  17. E. Gamma and R. Helm, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional, Boston, Mass, USA, 1995.
  18. “Spec patterns,” December 2010, http://patterns.projects.cis.ksu.edu/.
  19. S. Salamah, A. Gates, S. Roach, and O. Mondragon, “Verifying pattern-generated LTL formulas: a case study,” in Proceedings of the 12th International SPIN Workshop, pp. 200–220, San Francisco, Calif, USA, August 2005. View at Scopus
  20. “LTL2NBA,” March 2007, http://www.ti.informatik.uni-kiel.de/ABA-Simulation/ltl.cgi.
  21. O. Mondragon, A. Gates, and S. Roach, “Composite propositions:toward support for formal specification of system properties,” in Proceedings of the 27th Annual IEEE/NASA Goddard Software Engineering Workshop, Greenbelt, Md, USA, December 2002.