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.

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.

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