| R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Trans. Softw. Eng., 12(1):157--171, 1986. |
....of traditional types therefore limits the set of properties that they can express. It is therefore desirable to develop abstractions that change as the properties of objects change. A typestate is a system where types of objects change over time. A simple typestate system was introduced in [34]; more recent examples include [8 11,14,21,33,36] Similarly to [13] these typestate systems are a step towards the highly automated static checking of complex properties of objects. One of the di#culties in specifying properties of objects in the presence of linked data structures is that a ....
Robert E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, January 1986.
....Such a subtle error is very difficult is reproduce and correct. By using the interrupt level to guard data in paged memory, the Vault type checker finds such errors at compile time. 5. RELATED WORK Our work is inspired in part by the typestate approach provided in the programming language NIL [17, 16]. In NIL, states are attached to objects along with their types. NIL does not allow any aliasing of objects, thus severely restricting the class of programs that can be expressed in NIL. The work involving the calculus of capabilities by Crary, Walker, Smith, and Morrisett [3, 19, 15, 20] shows ....
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. tose, SE-12(1):157--171, Jan. 1986.
....command. We can represent these constraints as a nite state machine (FSM) as shown in Figure 1. Constraints such as these are very common in APIs. There has been a good deal of recent work that deals with modeling objects with nite state machines. Previous systems like Vault[7] NIL and Hermes[23] provide programmers with linguistic constructs to specify the state of the variables in a program, and a compiler is used to ensure that the object is always in the correct state. The advantage of this approach is that code written in this way is guaranteed to conform to the nite state models. ....
....in dicult corner cases[13] Using nite state machine models to model program behavior is quite common. The Metal system[5, 8] and the SLAM toolkit[2] have been very successful in applying FSM models statically to operating system code. Programming languages such as Vault[7] NIL, and Hermes[23] encode these machines directly into the source code. Systems such as PRE x also contain models that can be represented as FSMs[3] The Metal system uses a simple global FSM model to track changes in state[5, 8] It uses a metalevel compilation step to statically identify locations in the code ....
[Article contains additional citation context not shown here]
R. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. Software Engineering, 12(1):157-171, 1986.
....properties of objects in the program. In an imperative language properties of objects change over time. It is therefore desirable that types capture changing properties of objects. A typestate system is a system where types of objects change over time. A simple typestate system was introduced in [25], more recent examples include [14, 23, 28, 5] We view typestate as a step towards statically checking properties of objects [17, 8] One of the diculties with de ning object properties in object oriented languages is that a property of an object may depend on properties of other objects in the ....
.... over the domain of heaps it follows that maintaining an invariant expressed as a regular graph constraint is undecidable, even across a simple assignment statement such as (11) 4 Related Work The idea of typestate as system for statically verifying changing properties of objects was proposed in [25] and extended in [24] The original typestate system as well as the more recent work in the context object oriented programming [6] do not support constraints over dynamically allocated objects, which is the focus of our paper. Several recent systems support tree like dynamically allocated data ....
Robert E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, January 1986.
....paper will be specified using regular expressions or finite state automata which define the set of valid sequences of operations that can be performed on a single object. Previous work on finite state verification has included approaches that use special type systems or program annotations, e.g. [19, 18, 6, 7, 10, 9, 12], and techniques that are purely analytical, e.g. 14, 4, 2, 1] Note that a number of these approaches address verification problems not expressible in terms of finite state machines, in addition to those that are. Our goal in this paper is to develop an initial understanding of Submitted to ....
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Trans. Software Eng., 12(1):157 171, 1986.
....8 Related Work The concept of role models as a generalization of the static class system has been present in the object modelling community for some time [13] but usually with no formal relationship with program code. The idea of static analysis of types whichchange at run time was explored in [17], but without any treatment of relationships between objects in the heap. A system for object reclassi cation is presented in [3] but the class changes are designed to be transparentto aliasing; in our approach, the roles change when the aliases change, whichisa requirement for reasoning about ....
Robert E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. #### ############ ## ######## ###########, January 1986.
....governing proper interaction with that interface must be gleaned from the component s documentation or, as is often the case, learned from local folklore. These rules, which we call the interface protocol, govern the order in which the interface s functions may be called and its data accessed [14]. As a familiar example, a file system s interface protocol typically has the following rules: a file must be opened before it is read or written; a file may be read or written until it is closed; and every file that is opened must eventually be closed. In the context of the Vault programming ....
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. tose, SE-12(1):157--171, Jan. 1986.
....command. We can represent these constraints as a nite state machine (FSM) as shown in Figure 1. Constraints such as these are very common in APIs. There has been a good deal of recent work that deals with modeling objects with nite state machines. Previous systems like Vault[7] NIL and Hermes [23] provide programmers linguistic constructs to specify the state of the variables in a program, and a compiler is used to ensure that the object is always in the correct state. The advantage of this approach is that code written in this way is guaranteed to conform to the nite state models. This, ....
....bugs in dicult corner cases. Using nite state machine models to model program behavior is quite common. The Metal system [5, 8] and the SLAM toolkit [2] have been very successful in applying FSM models statically to operating system code. Programming languages such as Vault [7] NIL, and Hermes [23] encode these machines directly into the source code. Systems such as PRE x [3] also contain models that can be represented as FSMs. The Metal system uses a simple global FSM model to track changes in state [5, 8] It uses a metalevel compilation step to statically identify locations in the code ....
[Article contains additional citation context not shown here]
R. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. Software Engineering, 12(1):157-171, 1986.
....bugs on a daily basis than any other automatic approach. However, many program restrictions especially temporal or context dependent restrictions are too rich for an underlying type system or are simply not expressed in it. While there has been some work on richer frameworks such as TypeState [15], Vault [5] and aspect oriented programming [10] these still miss many systems relations and require programmer participation. Further, from a tool perspective, all language approaches require invasive, strenuous rewrites to get results. In contrast, our approach can precisely check properties ....
R E Strom and S Yemini. TypeState a programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, 1:157-- 171, January 1986.
....strong updates, even for example, when the program manipulates a cyclic list. The power Deutsch s method is the ability to precisely handle recursive traversal of linked data structures. Our approach for analyzing program manipulating ADTs is similar to the 53 typestate approach introduced in [Str83, SY86]. A typestate represents the set of runtime states of a variable at each program point, and nite state machines to represent the e ect of procedure calls (and operations) on the variable state. However, they do not handle aliasing between variables and require runtime checks at program points ....
R.E. Strom and S.A. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, SE-12(1):157-171, 1986.
....programmers to annotate their programs with types. In contrast, we propose a simpler and less expressive monomorphic type system that is designed for ecient type inference. Our system incorporates e ect inference [LG88, Wri92] to gain a measure of polymorphism. The type state system of NIL [SY86] is one of the earliest to incorporate ow sensitive type checking. Xu et al. [XRM01] use a ow sensitive analysis to check type safety of machine code. Type systems developed for Java byte code [SA98, O C99] also incorporate ow sensitivity to check for initialization before use and to allow ....
Robert E. Strom and Shaula Yemini. Typestate: A Programming Language Concept for Enhancing Software Reliability. IEEE Transactions on Software Engineering, 12(1):157-171, January 1986.
....cases, properties that do change are as important as properties that do not. Recognizing the bene t of capturing these changes, researchers have developed systems in which the type of the object changes as the values stored in its elds change or as the program invokes operations on the object [45, 44, 10, 51, 52, 6, 18, 11]. These systems integrate the concept of changing object states into the type system. The fundamental idea in this paper is that the type of each object should also depend on the data structures in which it participates. Our type system therefore captures the referencing relationships that ....
....the linked list operation does not modify the tree references, our analysis preserves the information about the tree edges across the procedure call. 8. RELATED WORK Typestate, as a type system extension for statically verifying dynamically changing object properties, was originally proposed in [45, 44]. In this system, the state of an object depends only on its initialization status. In general, aliasing causes problems for typestate based systems because the declared typestates of all aliases must change whenever the state of the referred object changes. Because of this problem, the original ....
Robert E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, January 1986.
....cases, properties that do change are as important as properties that do not. Recognizing the bene t of capturing these changes, researchers have developed systems in which the type of the object changes as the values stored in its elds change or as the program invokes operations on the object [84, 83, 20, 91, 92, 11, 40, 26]. These systems integrate the concept of changing object states into the type system. The fundamental idea in this work is that the state of each object also depends on the data structures in which it participates. Our type system therefore captures the referencing relationships that determine ....
....[36] and parametric shape analysis [78] We brie y relate our approach to some other interprocedural analyses and examine our work in the context of program veri cation. 7. 1 Typestate Systems A typestate system for statically verifying initialization properties of values was proposed in [84, 83]. The type state checking was based on a linear two pass typestate checking algorithm. In this typestate system, the state of an object depends only on its initialization status. This system did not support aliasing of dynamically allocated structures. Aliasing causes problems for typestate based ....
[Article contains additional citation context not shown here]
Robert E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, January 1986.
....nd more bugs on a daily basis than any other approach. However, many program restrictions especially temporal or context dependent restrictions are too rich for an underlying type system or are simply not expressed in it. While there has been some work on richer frameworks such as TypeState [23], Vault [6] and aspectoriented programming [17] these still miss many systems relations and require programmer participation. Further, from a tool perspective, all language approaches require invasive, strenuous rewrites to get results. In contrast, our approach transparently infers richer, ....
R E Strom and S Yemini. Typestate a programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, 1:157-171, January 1986.
No context found.
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Trans. Softw. Eng., 12(1):157--171, 1986.
No context found.
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, 12:157--171, 1986.
No context found.
R. E. Strom, S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Trans. Software Engineering 12(1):157-171, January 1986.
No context found.
R.E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Trans. Software Engineering, 12(1):157--171, 1986.
No context found.
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE TSE, January 1986.
No context found.
Robert E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, January 1986.
No context found.
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE TSE, January 1986.
No context found.
R. Strom and S. Yemini. Typestate: A programming language concept for enh ancing software reliability. IEEE Transactions on Software Engineering, 12(1), Jan. 1986.
No context found.
Robert E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, January 1986.
No context found.
Robert E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, January 1986.
No context found.
R. Strom and S. Yemini. Typestate: A Programming Language Concept for Enhancing Software Reliability. IEEE Transactions on Software Engineering, 12(1):157--171, 1986.
No context found.
Robert E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, January 1986.
No context found.
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Trans. Software Eng., 12(1):157--171, 1986.
No context found.
R. E. Strom and S.Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Trans. Software Eng., 12(1):157--171, 1986.
No context found.
R. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, 12(1):157--171, 1986.
No context found.
Robert E. Strom and Shaula Yemini. Typestate: A Programming Language Concept for Enhancing Software Reliability. IEEE Transactions on Software Engineering, 12(1):157--171, January 1986.
No context found.
R. Strom and S. Yemini. Typestate: A programming language concept for enh ancing software reliability. IEEE Transactions on Software Engineering, 12(1), Jan. 1986.
No context found.
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE TOSE, SE-12(1):157--171, Jan. 1986. 22
No context found.
Robert. E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE TSE, 12(1):157--171, January 1986.
No context found.
R. Strom and S. Yemini. Typestate: A programming language concept for enh ancing software reliability. IEEE Transactions on Software Engineering, 12(1), Jan. 1986.
No context found.
Rob Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliabiity. IEEE Transactions on Software Engineering, 12(1):157--171, 1986.
No context found.
Strom, R.E., Yemini, S.: Typestate: A programming language concept for enhancing software reliability. IEEE TSE 12 (1986) 157--171 24
No context found.
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, January 1986.
No context found.
Robert E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, January 1986.
No context found.
Rob Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliabiity. IEEE Transactions on Software Engineering, 12(1):157--171, January 1986.
No context found.
R. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliabiity. IEEE Transactions on Software Engineering, 12(1):157--171, 1986.
No context found.
Robert E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, January 1986.
No context found.
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, SE-12(1):157--171, Jan. 1986.
No context found.
Robert E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, January 1986.
No context found.
R. Strom, and S. Yemini. Typestate: A Programming Language Concept for Enhancing Software Reliability. IEEE Transactions on Software Engineering 12, 1 (January 1986).
No context found.
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Trans. Software Eng., 12(1):157--171, 1986.
No context found.
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Trans. Softw. Eng., 12(1):157--171, 1986.
No context found.
Robert E. Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Transactions on Software Engineering, January 1986.
No context found.
Rob Strom and Shaula Yemini. Typestate: A programming language concept for enhancing software reliabiity. IEEE Transactions on Software Engineering, 12(1):157-- 171, 1986.
No context found.
R. E. Strom and S. Yemini. Typestate: A Programming Language Concept for Enhancing Software Reliability. IEEE Transactions on Software Engineering, 12(1):157--171, Jan. 1986.
No context found.
R. E. Strom and S. A. Yemini, `Typestate: A programming language concept for enhancing software reliability', IEEE Transactions on Software Engineering, SE-12, 157--171 (1986).
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