J. M. Atlee and J. Gannon. State-based model checking of event-driven systems requirements. IEEE Transactions on Software Engineering, 19(1):24--40, Jan. 1993.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....functionalities (e.g. a new input language, past operators, enhanced simulator) has been crucial for its effective application to the analysis of FT specification. Formal analysis is often used to verify correctness of specifications, but, it is usually applied in later phases. For instance, in [1, 12] formal verification techniques were used for the analysis of specifications expressed in the SCR formalism, and in [7] NUSMV is used for the verification of RSML specifications. The works that are most relevant to ours are Alcoa Alloy [14, 13] KAOS [15] and the work on Topoi Diagrams [17] ....

J. M. Atlee and J. Gannon. State-based model checking of event-driven systems requirements. IEEE Transactions on Software Engineering, 19(1):24--40, Jan. 1993.

....model checking has led to an interest in lightweight formal techniques [4] that can be applied at different levels of abstraction, and during any stage of the development process. Model checkers have become popular debugging tools and have been used to reason about system requirements [5], software architectures [6] program behaviour [7 9] hardware and circuit designs [10] communication protocols [11] and even user interfaces [12] Because model checking can be used to analyse abstract behavioural models, it has a number of natural applications in requirements engineering. A ....

....showing why the property is not satisfied. 3. Model checking can be applied to partial models, so it is not necessary to fully specify a system nor all its properties before analysing its correctness. Model checking was first applied to requirements engineering in the work of Atlee and Gannon [5]. In requirements engineering, the state machine typically represents an abstract description of the behaviour of some portion of the system to be specified, or its environment. The properties to be checked typically represent high level requirements including safety properties (some undesirable ....

Atlee JM, Gannon J. State-based model checking of event-driven system requirements. IEEE Trans Software Eng 1993;19(1):22-- 40

....logic) and determines whether or not the model satisfies the property [CES86] i.e. it returns the value of the predicate M #. Model checking has been effectively applied to reasoning about correctness of hardware [CGH 93] communication protocols [Hol91] and software requirements [AG93] A number of classical model checkers are currently used for industrial applications, including SPIN [Hol97] SMV [McM93] and Mur# [Dil96] Multi valued model checking, i.e. reasoning with values other than TRUE and FALSE, is a generalization of classical model checking [CEP01, CDE 01, ....

J.M. Atlee and J. Gannon. "State-Based Model Checking of Event-Driven System Requirements". IEEE Transactions on Software Engineering, 19(1):22--40, January 1993.

....variables, whose states are modes and whose transitions, called mode transitions, are triggered by changes on the monitored variables. Mode transition tables represent mode classes and their respective transitions in a tabular format. The mode transition table for our case study, taken from [3], is given in Table 1. It is for an automobile cruise control system. Note that the table already reflects basic properties of monitored variables. For example, the two transitions from Inactive to Cruise take into account the environmental property that in any state a cruise control lever is ....

....property that in any state a cruise control lever is in exactly one of the three positions Activate , Deactivate or Resume . So, for example, whenever Activate changes to true, either Deactivate or Resume changes to false. For a more detailed description of this case study see [3]. Mode transition events occur when one or more monitored variables change their values. Events are of two types: T(C) when a condition C changes from false to true, and F(C) when C changes from true to false. C is called a triggered condition. For example, in the automobile cruise control ....

Atlee, J. M, and Gannon, J. (1993). State-Based Model Checking of Event-Driven System Requirements. IEEE Transaction on Software Engineering, 19(1): 24-40.

....class ri. Each entity ri defined by a table is associated with exactly one mode class, Mj, 1 j N. To represent T is a partial function because not all input events can occur in a given state. For example, in the control system, Block cannot change to On if Block is already On. 4Reference [2] presents an alternate definition of a conditioned event, namely, T(c) WHEN d = c A c A d A d . When c and d define independent input variables, definition (1) and the One Input Assumption imply this alternate definition. Although we prefer definition (1) because the alternate definition makes ....

....the proofs are based on very simple logic. What is noteworthy about the PVS experiment is that the theorems were proven automatically. Model Checking. Atlee and Gannon have demonstrated the utility of model checking [7] for detecting application dependent errors in SCR requirements specifications [2]. However, where our consistency checker tests all tables and other definitions (e.g. definitions of types, constants, etc. in an SCR specifi cation, their tool analyzes properties of the mode transition tables only. Detecting Errors by Inspection. A recent experiment [46] compares the ....

ATLEE, J. M., AND GANNON, J. State-based model checking of event-driven system requirements. IEEE Tcans. Softw. Eng. 19, I (Jan. 1993), 24 40.

.... adopted widely outside academia their cost saving benefits were doubtful, they lacked tool support, and were perceived difficult to apply [27] Recently, the tools for proving properties of finitestate models are becoming increasingly available and are often used for analyzing requirements, e.g. [2, 3, 10, 4]. These tools typically require the users to spec ify properties using temporal logics and to describe models of systems using some finite state transition representation. The tools are based on a variety of verification techniques. For example, SPIN [16] and SMV [22] are based on state space ....

J.M. Atlee and J. Gannon. "State-Based Model Checking of Event-Driven System Requirements". IEEE Trasactios o Software Egmeermg, pages 22 40, January 1993.

....based on state transition methods with advanced capability for simulation. A state transition formalism with two graphical notations is used: activity charts, a form of functional decomposition and statecharts, a representation of finite state machines. The State based model checking technique [AG93] defines a state based formulation of a problem using mode transition tables. Modes are collection of states. In the remaining architectural design styles, state transition formalisms are used as secondary views meaning that they are used as supporting tools in the design process [Shaw95] 2.2.2 ....

Atlee J. and Gannon J., "State-Based Model Checking of Event-Driven System Requirements", IEEE Trans. Software Eng., IEEE, pp.24-40, Jan. 1993

....a two valued boolean logic, then a # view reduces to a standard Kripke structure. By adopting Kripke structures as our underlying formalism, we gain generality and analytical power but lose some expressive power. However, many modeling languages can be translated into Kripke structures (e.g. SCR [Atlee and Gannon, 1993 ] and we plan to eventually adopt a richer specification language as a front end to our framework. Central to a symbolic model checking algorithm is the computation of partitions of the state space w.r.t. a variable # using # ## # : ##2 # . A partition has the following properties: ## # ## ....

J.M. Atlee and J. Gannon. "StateBased Model Checking of Event-Driven System Requirements ". IEEE Transactions on Software Engineering, pages 22--40, January 1993.

....and analytical power but lose some 4 In this paper we use TRUE and FALSE to refer to the top of the lattice, #, and the bottom of the lattice, #, respectively. expressive power. However, many standard state machine specification languages can be translated into Kripke structures (e.g. SCR [1]) and we plan to eventually adopt a richer specification language as a front end to our framework. Also, # views do not have an explicit representation of time, although we plan to add this in the future. 5 Merging and Analyzing # views 5.1 Signature and Value Maps Given a set of # views, we ....

J. Atlee and J. Gannon. "State-Based Model Checking of Event-Driven System Requirements". IEEE Trans. on Software Engineering, pages 22--40, January 1993.

....constraint. Recent work in symbolic model checking[21] utilizes an efficient representation of finite state spaces to make the checking of large models (on the order of 10 20 states) feasible. Model checking has been used to validate many types of software specifications. Atlee and Gannon[8] verify safety properties of requirements expressed in the SCR notation. Their approach maps a finite subset of SCR onto a state machine which is then fed into the model checker. Jackson[53] has investigated using model checking to validate properties of Z and VDM specifications. Since these ....

Joanne Atlee and John Gannon. State-based model checking of event driven systems requirements. IEEE Transactions on Software Engineering, 19(3), January 1993.

.... capability for more popular, graphical software engineering notations (e.g. SCR [20] RSML [27] and even OMT [35] and UML [6] In fact, the last decade has witnessed a flurry of attempts to translate traditional modeling notations into forms that can be analyzed by these automatic tools (e.g. [1, 38, 10]) While conceptually these tools are black boxes, in practice, a standalone tool is difficult to efficiently integrate into a larger software development environment. This paper explores the issues involved in packaging analysis and verification capability into lightweight components that are ....

....artifactual decisions through lightweight analysis components. Note that while artifactual changes are to be discouraged, we are not trying to forestall effectual changes, which are quite useful and form the basis for much of the work in formalizing popular software engineering notations (e.g. [1, 38, 10]) On the other hand, effectual decisions are often coupled with artifactual decisions. Using lightweight components, this coupling is not necessary. 2.2. Integration by artifactual change When integrating a stand alone tool into a larger environment, we consider the tool to be a black box ....

J. Atlee and J. Gannon. State-based model checking of event driven systems requirements. IEEE Transactions on Software Engineering, 19(3), January 1993.

....variables, whose states are modes and whose transitions, called mode transitions, are triggered by changes on the monitored variables. Mode transition tables represent mode classes and their respective transitions in a tabular format. The mode transition table for our case study, taken from [4], is given in Table 1. It is for an automobile cruise control system. Note that the table already reflects basic properties of monitored variables. For example, the two transitions from Inactive to Cruise take into account the environmental property that in any state a cruise control lever is ....

....in any state a cruise control lever is in exactly one of the three positions Activate , Deactivate or Resume . So, for example, whenever Activate changes to true, either Deactivate or Resume changes to false. For a more detailed description of this case study, the reader is referred to [4]. 15 Mode transition events occur when one or more monitored variables change their values. Events are of two types: T(C) when a condition C changes from false to true, and F(C) when a condition C changes from true to false. C is called a triggered condition. For example, in the automobile ....

[Article contains additional citation context not shown here]

Atlee, J. M., and Gannon, J. (1993). State-Based Model Checking of Event-Driven System Requirements. IEEE Transactions on Software Engineering, 19(1): 24-40.

....systems, distributed systems, reactive systems, embedded systems, protocols. In such cases model checking can be a very e ective way to detect errors in the earlier phases of the design cycle. Thus meeting formal methods goals of reducing time to market and increasing design quality. e.g. see [37, 36, 1, 16, 5, 4, 8, 31, 11, 35]. 1 This research has been partially supported by MURST project TOSCA 2 Area Informatica, Universit a di L Aquila, Coppito 67100, L Aquila, Italy 3 Dip. di Scienze dell Informazione, Universit a di Roma La Sapienza , Via Salaria 113, 00198 Roma, Italy 4 ....

.... Universit a di Roma La Sapienza , Via Salaria 113, 00198 Roma, Italy 4 ftronci,gdellape,intrigilg univaq.it http: univaq.it tronci 5 zilli dsi.uniroma1.it For concurrent systems the properties to be veri ed are typically stated as state invariants or as safety properties (e.g. [1, 4]) Here we focus on such a kind of properties. Checking validity of a property for a concurrent system S in our context comes down to Reachability Analysis (State Space Exploration) That is, to the computation (visit) of the set of all states (reach able states) that S can reach starting from ....

J.M. Atlee and J.D. Gannon. State-based model checking of event-driven system requirements. IEEE Trans. on Software Engineering, 19(1):24-40, January 1993.

....semantics. Each sentence written in the notation has exactly one meaning. Formal notations eliminate ambiguities and make it possible to analyse specifications automatically. Research has already shown that automated analysis techniques, such as model checking, can aid in requirements analysis [AG93, ABB 96, HL96, HJL96, DJJ96] Many organisations and individuals use different notations for expressing require1 CHAPTER 1. INTRODUCTION 2 ments for different aspects of a system. We use the term language to describe a set of notations used in a specification. The methodology of structured ....

....notations. For example, an invariant may depend on the reachability of states in a state transition diagram. The transition guards may be expressed by decision tables. Translation into the input notation of an existing analysis tool is a common approach to analysis of either single language ( AG93, AB96, BH97a] or multi notation ( ZJ93, ACD97, PY97] specifications. Translation bridges the gap between notations developed for their readability and understandability, and notations developed because they can be analysed. There are three disadvantages to the translation approach. First, there ....

[Article contains additional citation context not shown here]

Joanne M. Atlee and John Gannon. State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering, 19(1):24-- 289 BIBLIOGRAPHY 290 40, January 1993.

....a major problem is verifying if a given e commerce protocol satisfies these properties, specially in the presence of network and site failures. In this paper we address the problem of protocol verification using existing software verification techniques. In particular, we use model checking [1, 9, 13, 14] to the modeny atomicity, goods atomicity and validated receipt properties of the secure e commerce protocol proposed in [16] In [16] the authors have informally shown that, in the absence of failures, their protocol has the money atomicity, goods atomicity and validated receipt properties. The ....

J. M. Atlee and J. D. Gannon. State-based Model Checking of Event Driven Systems Requirements. IEEE Transactions on Software Engineering, 19(1):13--23, January 1993.

....we use the B Toolkit to verify safety properties with respect to an example SCR mode transition table. The research in automated checking of SCR specifications includes the consistency checker of Heitmeyer, Jeffords, and Labaw [HJL96] and the model checking approaches first developed by Atlee [AG93, Atl94, AB96, ORS95] The consistency checker [HJL96] analyzes application independent properties such as syntax, type mismatch, missing cases, circular dependencies and so on, but not application dependent properties such as safety and security. Atlee [AG93, Atl94, AB96] addresses the ....

....approaches first developed by Atlee [AG93, Atl94, AB96, ORS95] The consistency checker [HJL96] analyzes application independent properties such as syntax, type mismatch, missing cases, circular dependencies and so on, but not application dependent properties such as safety and security. Atlee [AG93, Atl94, AB96] addresses the application dependent property of safety in SCR mode transition tables by expressing an SCR mode transition table as a logic model, expressing the safety properties of the specification as logic formulae, and using a model checker to determine if the formulae hold in ....

[Article contains additional citation context not shown here]

J. M. Atlee and J. Gannon. State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering, 19(1):24--40, January 1993. 22

....which was constructed from an event table, and the invariant mentioned in footnote 6, were generated by hand. The GROUP algorithm has not yet been implemented. 6. Related Work Our KEEP and GROUP algorithms for generating invariants from SCR specifications extend work by Atlee and Gannon [3, 4], who used mode invariants to analyze SCR specifications with the MCB model checker. However, their automated technique only addressed a special case of our KEEP algorithm and did not cover the GROUP technique. Their work provided the inspiration for our research on mode invariant generation. Mode ....

J. M. Atlee and J. Gannon. State-based model checking of event-driven system requirements. IEEE Trans. Softw. Eng., 19(1):24--40, Jan. 1993.

....can require significant and tedious reorganization of the formal description. Using formal specification languages facilitates the early evaluation of a software design and verification of its implementation through the use of formal reasoning techniques [5, 6, 9, 8] or static analysis techniques [10, 11, 12]. A formal specification can be rigorously manipulated to allow the designer to assess the consistency, completeness, and robustness of a design before it is implemented. Each step in the development process can be supported by mathematical proof, thus reducing the number of errors due to ....

J. Atlee and J. Gannon, "State-based model checking of event-driven system requirements," in Proceedings of the ACM SIGSOFT '91 Conference on Software for Critical Systems. Software Engineering Notes. Volume 16 Number 5, 1991.

....to software systems. It is well known that software defects are less costly the earlier they are removed in the development process. Towards this end, a number of researchers have worked on applying model checking to artifacts that appear throughout the software life cycle, such as requirements [2], architectures [23] designs [16] and source code [7] Source code, of course, is not a monolithic entity that is developed at one time. Source code evolves over time with di#erent components, or units, reaching maturity at di#erent points. Software units come in many di#erent types. In ....

J. Atlee and J. Gannon. State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering, 19(1):24-40, June 1993.

....of the Automotive Cruise Control has to be given. This can be done by defining the set of transitions T between the different USOM seen above. Here, a transition is considered as a disjunction of conjunctions of boolean terms. So, it is easy to verify the determinism of the transition graph (Atlee and Gannon, 1993). Furthermore, the connexity analysis of the graph and the lack of deadlock allow us to ensure its vivacity (Gondran and Minoux, 1990) The obtained deterministic automata is given below (Fig. 7) with the set T of transitions between modes. In the transitions, the symbols used are logical and the ....

Atlee, J.M., and J. Gannon J. (1993). State-Based Model Checking of Event-Driven System Requirements., IEEE Transactions on Software Engineering, Vol. 19 n1, pp. 24-40.

....backward image, equivalence check, etc. There have been other studies which use different symbolic representations together. In [CABN97] Chan et al. present a technique in which (both linear and non linear) constraints are mapped to BDD variables (similar representations were also used in [AB96,AG93] and a constraint solver is used during model checking computations (in conjunction with SMV) to prune infeasible combinations of these constraints. Although this technique is capable of handling non linear constraints, it is restricted to systems where transitions are either data memoryless ....

J. M. Atlee and J. Gannon. State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering, 19(1):24-- 40, January 1993.

....a hypothetical automobile cruise control system with collision avoidance. The idea is that when the automobile is too close to the vehicle in front, the cruise control system will automatically deactivate itself. In addition to TCAS, the example was influenced by the one used by Atlee and Gannon [AG93] Three inputs to the system are s o , the velocity of the vehicle; s f , the velocity of the front vehicle; and d 0, the distance between the vehicles. In reality, s f may be estimated from the current and previous values of s o and d. The closeness of the two vehicles is based on time ....

J. M. Atlee and J. Gannon. State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering, SE19 (1):24--40, January 1993.

....define preconditions on transitions, which are values that specific variables must have for the transition to be enabled, and triggering events, which are changes in variable values that cause the transition to be taken. A trigger event triggers the change in state. For example, SCR [18, 3] calls these WHEN conditions and triggering events. The values the triggering events have before the transition are sometimes called before values, and the values after the transition are sometimes called after values. The state immediately preceding the transition is the pre state, and the ....

J. M. Atlee and J. Gannon. State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering, 19(1):24--40, January 1993.

....an view reduces to a standard Kripke structure. By adopting Kripke structures as our underlying formalism, we gain generality and analytical power but lose some expressive power. However, as many standard state machine specification languages can be translated into Kripke structures (e.g. SCR [1]) it would be fairly straightforward to adopt a richer specification language as a front end to our framework. Also, views do not have an explicit representation of time, although we plan to add this in the future. Example views are given in Figures 4(a) 4(b) and 4(e) Merging Viewpoints ....

J. Atlee and J. Gannon. "State-Based Model Checking of Event-Driven System Requirements". IEEE Transactions on Software Engineering, pages 22--40, January 1993.

....in IOGs) and the value of a widget attribute of some enumerated type. At least for those states which represent the widget when the user is not manipulating it, it would be desirable to verify that the attribute value could be guaranteed. This property is a form of the state invariant described in (Atlee Gannon 1993). If idle states represent the widget when the user is not manipulating it, state invariance for idle states is closely related to the usability concept of observability of underlying system state. Forgetting a data arc is one common cause of this error. Other properties to check could include ....

Atlee, J. & Gannon, J. (1993) State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering, 19(1), pp. 24-40.

....of a formula on one side of the line is equivalent to its negation on the other, and this structural rule is used to eliminate top level negations. Names with embedded characters are Skolem constants derived from variables with the same root name. 9 6 decisiontableTCC2.1 : [1] ACAlt 1 400 [2] AltCaptHold 1 [3] ACAlt 1 = AccAlt 1 Unproven sequents such as this, with no formulas above the line, indicate the failure to select an operational procedure when all the formulas below the line are false. This one, for example, identifies the failure to consider the case ....

Joanne M. Atlee and John Gannon. State-based model checking of event-driven system requirements. In SIGSOFT '91: Software for Critical Systems, pages 16-- 28, New Orleans, LA, December 1991. Published as ACM SIGSOFT Engineering Notes, Volume 16, Number 5. 15

....the paper. 1 2 Related work Although in this paper we focus on animation, this is not the only way to validate a formal speci cation. Other methods for validating formal speci cations include prototyping [13, 24] speci cation based testing [21, 8] theorem proving [14, 11] and model checking [6, 2]. Most formal speci cation languages are not directly executable. However, several researchers have reported success in animating subsets of model oriented speci cations, typically by translating schemas into Prolog or into a functional language, and then transforming the resulting programs to ....

J.M. Atlee and J.D. Gannon. State-based model checking of event-driven systems requirements. IEEE Transactions on Software Engineering, 1993.

....Systems Company s C 130J aircraft program [12] The primary approach used to provide integration with other tools for the SCR method has been one of translation. The researchers at the NRL have developed a translation from the SCR notation to the state machine notation of a model checker [2, 3, 4, 5], as well as to a testing tool [8] The primary problems with any translationtype approach are the following: Error reports from the destination tool might be dicult to translate to errors within the source SCR speci cation. Notations must be compatible to some degree or other; otherwise, ....

J.M. Atlee and J. Gannon. State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering, 19(1):24-40, January 1993.

....Systems Company s C 130J aircraft program [12] The primary approach used to provide integration with other tools for the SCR method has been one of translation. The researchers at the NRL have developed a translation from the SCR notation to the state machine notation of a model checker [2, 3, 4, 5], as well as to a testing tool [8] The primary problems with any translationtype approach are the following: Error reports from the destination tool might be dicult to translate to errors within the source SCR speci cation. Notations must be compatible to some degree or other; otherwise, ....

J. Atlee and J. Gannon. State-based model checking of event-driven system requirements. In Proceedings of the ACM SIGSOFT '91 Conference on Software for Critical Systems. Software Engineering Notes. Volume 16 Number 5, 1991.

....to more sophisticated functional safety requirements. 28 8.1. 3 Model Checking Model checking is a verification technique that has traditionally been used for rigorous hardware verification [18] The success of hardware model checking has lead to increased application to software verification [19] [20] 21] The aim of model checking is to systematically explore the behaviour of an operational system model for satisfaction of a set of desired functional properties. It suffers the same general problems noted for animation above, but can be more efficient in certain domains. A number of ....

J. M. Atlee and J. Gannon, "State-Based Model Checking of Event-Driven System Requirements," IEEE Transactions on Software Engineering, vol. 19, pp. 24-40, 1993.

....on a number of examples. 2 Related work Although we focus on animation, this is not the only way to validate a formal specification. Other methods for validating formal specifications include prototyping [13, 27] specification based testing [24, 8] theorem proving [11, 15] model checking [2, 6], and counter example detection [16] Most formal specification languages are not directly executable. However, several researchers have reported success in animating subsets of model oriented specifications, typically by translating schemas into Prolog or into a functional language, and then ....

J.M. Atlee and J.D. Gannon. State-based model checking of event-driven systems requirements. IEEE Transactions on Software Engineering, 1993.

.... Heitmeyer et al., 1998) An early application of model checking to SCR requirements specifications was reported in 1993 by Atlee and Gannon, who used the model checker MCB (Clarke, Emerson and Sistla, 1986) to analyze properties of individual mode transition tables taken from SCR specifications (Atlee and Gannon, 1993). More recently, Sreemani and Atlee (Sreemani and Atlee, 1996) used the symbolic model checker SMV (McMillan, 1993) to determine whether the mode transition tables in the original A 7 requirements document satisfied assertions about combinations of modes. The latter experiment demonstrates that ....

....reduce the number of variables in the analysis from over 250 to 55, a reduction of almost 80 . 7. Related Work Our approach to model checking SCR requirements specifications is a generalization and extension of the approach originally formulated and further developed by Atlee and her colleagues (Atlee and Gannon, 1993, Atlee and Buckley, 1996, Sreemani and Atlee, 1996) The relationship between our work and Atlee s work was described earlier. Below, we describe other work in which model checking has been applied to requirements specifications. We also compare our approach to the use of abstraction in model ....

Atlee, J. M. and Gannon, J. 1993. State-based model checking of event-driven system requirements. IEEE Trans. Softw. Eng., 19(1):24--40.

.... of the specification, for user confirmation, through deductive theorem proving techniques [Owr95, Man96] to confirm that an operational specification satisfies more abstract specifications, or to generate behavioral counterexamples if not, through algorithmic model checking techniques [Que82, Cla86, Hol91, Hol97, McM93, Atl93, Man96, Hei98a, Cla99]; to generate counterexamples to claims about a declarative specification [Jac96] to generate concrete scenarios illustrating desired or undesired features about the specification [Fic92, Hal95, Hal98] or, conversely, to infer the specification inductively from such scenarios [Lam98c] ....

J.M. Atlee, State-Based Model Checking of Event-Driven System Requirements, IEEE Transactions on Software Engineering Vol. 19 No. 1, January 1993, 24-40.

....to software systems. It is well known that software defects are less costly the earlier they are removed in the development process. Towards this end, a number of researchers have worked on applying model checking to artifacts that appear throughout the software life cycle, such as requirements [2], architectures [23] designs [16] and source code [7] Source code, of course, is not a monolithic entity that is developed at one time. Source code evolves over time with different components, or units, reaching maturity at different points. Software units come in many different types. In ....

J. Atlee and J. Gannon. State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering, 19(1):24-40, June 1993.

....possible to use automated verification techniques such as model checking in analyzing properties of specifications. The state space of a software spec ification (defined by the semantics of the specification language used) can be explored using model checking to verify or falsify its properties [2]. Model Checking Software Specifications There are two main approaches to model checking, 1) symbolic model checking based on CTL (Computation Tree Logic, a branching time temporal logic) 8] and 2) explicit state model checking based on LTL (Linear time Temporal Logic) 24] The important ....

J. M. Atlee and J. Gannon. State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering,

....control models. Shaw also bases a solution on feedback control, with other architectures used for subsystems [Shaw95] Wang and Tanik develop a dataflow solution to illustrate Process Port Analysis and XYZ E [WangTanik89] Atlee and Gannon use cruise control as the basis of a specification study [AtleeGannon93] 1.3.5 Contributors Mary Shaw organized the presentation and prepared one of the solutions. She also prepared a comparison of published solutions [Shaw94] 1.4 Conference Refereeing Professional conferences are held in order to announce and discuss new results. The core activity of ....

Joanne M. Atlee and John Gannon. State-Based Model Checking of Event-Driven System Requirements. IEEE Transactions on Software Engineering, vol 19, no 1, Jan 1993, pp.2440.

....6 summarizes and discusses some related issues. Conclusions are presented in Section 7. 2 Related Work SCR specification has been used to specify practical systems [HLK93] Also, research has been done to analyze requirements consistencies and to verify given system properties. Atlee and Gannon [AG93] use model checking to analyze SCR specifications specifications. Model checking of temporal logic, a sound technique used to verify safety properties in hardware systems, is used to verify a given set of safety properties for event driven systems. A model checker [Bro89] determines whether the ....

....and Labaw [HLK93] propose a consistency checker that tests all tables and definitions in an SCR specification. Mode invariant properties are not discussed in their paper. 2 3 SCR Specifications In this section, we briefly describe the SCR specifications as used in Atlee and Gannon s paper [AG93] and discuss some system properties. 3.1 SCR Constructs The SCR specifications were developed by a research group at NRL as part of a general Software Cost Reduction project [Hen80] An SCR document specifies a software system s behavior as a finite set of concurrent, event driven ....

[Article contains additional citation context not shown here]

J. M. Atlee and J. Gannon. State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering, 19(1):24--40, January 1993.

....requirements had been stated using the better specification language. In our original experiments, in which the transformation from the requirements to the CTL machine was done by hand, two intended mode invariants (those for modes Off and Cruise) were thought to be enforced by the requirements [3]; these discrepancies were not detected until the algorithm was automated. Furthermore, all of the discrepancies in the water level monitoring system involved unexpected combinations of events (e.g. the operator presses conflicting buttons at the same time, or presses the SelfTst button when the ....

J. Atlee and J. Gannon. "State-Based Model Checking of Event-Driven System Requirements". In Proceedings of the ACM SIGSOFT'91 Conference on Software for Critical Systems, pages 16--28, 1991.

....cost of its creation across several different analysis activities, and reducing the cost of analysis through automation. Our research has focused on developing techniques that use formal methods to enable automatic analysis of program artifacts at early stages of the software development life cycle[4, 6, 28, 5, 10, 11]. In this paper, we summarize our work to analyze program requirements and designs. We use model checking[14] because it can be fully automated and can check properties of large systems. Developers are more likely to understand a proof technique like model checking, which is based on search and ....

J.M. Atlee and J. Gannon. "State-Based Model Checking of Event-Driven System Requirements ". IEEE Transactions on Software Engineering, pages 22--40, January 1993.

No context found.

J. M. Atlee and J. Gannon. State-based model checking of event-driven systems requirements. IEEE Transactions on Software Engineering, 19(1):24--40, Jan. 1993.

No context found.

J. M. Atlee and J. Gannon. State-based model checking of event-driven systems requirements. IEEE Transactions on Software Engineering, 19(1):24--40, January 1993.

No context found.

J. M. Atlee and J. Gannon. State-based model checking of event-driven systems requirements. IEEE Transactions on Software Engineering, 19(1):24--40, Jan. 1993.

No context found.

J. M. Atlee and J. D. Gannon. State-based model checking of event-driven system requirements. IEEE Trans. on Software Eng., 19(1):24--40, Jan. 1993.

No context found.

J. M. Atlee and J. Gannon. State-based model checking of event-driven systems requirements. IEEE TSE, 19(1):24-40, January 1993.

No context found.

J.M. Atlee, State-Based Model Checking of Event-Driven System Requirements, IEEE Transactions on Software Engineering Vol. 19 No. 1, January 1993, 24-40.

No context found.

J. M. Atlee and J. D. Gannon. State-based model checking of event-driven system requirements. IEEE Trans. on Software Eng., 19(1):24--40, Jan. 1993.

No context found.

Atlee, J. M., and Gannon, J. D. State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering (Jan. 1993), 24--40.

No context found.

ATLEE,J.M.AND GANNON, J. 1993. State-based model checking of event-driven system requirements. IEEE Trans. Softw. Eng. 19, 1 (Jan.), 24 -- 40.

No context found.

J.M. Atlee and J. Gannon, "State-based model checking of event-driven system re uirements," IEEE Trans. Software Eng. vol.19, no.1,p.1,qSHB Jan. 1993.

No context found.

J. M. Atlee and J. Gannon, \State-based model checking of event-driven system requirements ", IEEE Tran. on Software Eng., 19(1), 1993, pp. 24-40.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC