65 citations found. Retrieving documents...
R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE Trans. Softw. Eng., 12(1):157--171, 1986.

 Home/Search   Document Not in Database   Summary   Related Articles   Check  

This paper is cited in the following contexts:

First 50 documents  Next 50

Existential Heap Abstraction Entailment is Undecidable - Kuncak, Rinard (2003)   (1 citation)  (Correct)

....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.


Enforcing High-Level Protocols in Low-Level Software - DeLine, Fahndrich (2001)   (131 citations)  (Correct)

....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.


Automatic Extraction of Object-Oriented Component Interfaces - Whaley, Martin, Lam (2002)   (8 citations)  (Correct)

....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.


Typestate Checking and Regular Graph Constraints - Kuncak, Rinard (2002)   (Correct)

....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.


Shallow Finite State Verification - Field, Goyal, Yahav, Ramalingam (2002)   (Correct)

....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.


A Language for Role Specifications - Kuncak, Lam, Rinard (2001)   (Correct)

....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.


Adoption and Focus: Practical Linear Types for Imperative.. - Fahndrich, DeLine (2002)   (37 citations)  (Correct)

....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.


Automatic Extraction of Object-Oriented Component Interfaces - Whaley, Martin, Lam (2002)   (8 citations)  (Correct)

....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.


Using Programmer-Written Compiler Extensions to Catch.. - Ashcraft, Engler (2002)   (40 citations)  (Correct)

....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.


Interprocedural Shape Analysis - Rinetzky   (Correct)

....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.


Flow-Sensitive Type Qualifiers - Foster, Terauchi, Aiken (2002)   (43 citations)  (Correct)

....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.


Role Analysis - Kuncak, Lam, Rinard (2002)   (20 citations)  (Correct)

....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.


Designing an Algorithm for Role Analysis - Kuncak (2001)   (Correct)

....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.


Bugs as Deviant Behavior: A General Approach to.. - Engler, Chen.. (2001)   (52 citations)  (Correct)

....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.


Jungloid Mining: Helping to Navigate the API Jungle - David Mandelin Lin   (Correct)

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.


Lightweight Object Specification with Typestates - Bierhoff, Aldrich (2005)   (Correct)

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.


EGO: Controlling the Power of Simplicity - Bejleri, Aldrich, Bierhoff (2006)   (Correct)

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.


The BLAST Query Language for Software Verification - Beyer, Chlipala, Henzinger, .. (2004)   (Correct)

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.


An Overview of the Jahob Analysis System - Project Goals and.. - Kuncak, Rinard   (Correct)

No context found.

R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE TSE, January 1986.


On Modular Pluggable Analyses Using Set Interfaces - Lam, Kuncak, Rinard (2003)   (Correct)

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.


Modular Pluggable Analyses for Data Structure Consistency - Kuncak, Lam, Zee, Rinard   (Correct)

No context found.

R. E. Strom and S. Yemini. Typestate: A programming language concept for enhancing software reliability. IEEE TSE, January 1986.


Generalized Typestate Checking Using Set Interfaces and.. - Patrick Lam Viktor (2004)   (Correct)

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.


On Generalized Records and Spatial Conjunction in Role Logic - Kuncak, Rinard (2004)   (Correct)

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.


On Modular Pluggable Analyses Using Set Interfaces - Lam, Kuncak, Rinard (2003)   (Correct)

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.


PSE: Explaining Program Failures via Postmortem.. - Manevich, Sridharan, .. (2004)   (Correct)

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.


On Generalized Records and Spatial Conjunction in Role Logic - Kuncak, Rinard (2004)   (Correct)

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.


Verifying Safety Properties using Separation and - Heterogeneous Ions Eran   (Correct)

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.


Typestate Verification: Abstraction Techniques and.. - Field, Goyal.. (2004)   (2 citations)  (Correct)

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.


ESP: Path-Sensitive Program Verification in Polynomial Time - Das, Lerner, Seigle (2002)   (46 citations)  (Correct)

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.


Type Qualifiers: Lightweight Specifications to Improve Software.. - Foster (2002)   (6 citations)  (Correct)

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.


Generalized Typestate Checking Using Set Interfaces and.. - Lam, Kuncak, Rinard (2004)   (Correct)

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.


The Fugue protocol checker: Is your software Baroque? - DeLine, Fähndrich (2004)   (1 citation)  (Correct)

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


Proceedings of the First International Workshop on Aliasing.. - (ed.) (2003)   (Correct)

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.


Generalized Typestate Checking Using Set Interfaces and.. - Lam, Kuncak, Rinard (2004)   (Correct)

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.


Broadway: A Compiler for Exploiting the Domain-Specific.. - Guyer, Lin (2004)   (Correct)

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.


Typestates for Objects - Deline, Fahndrich (2004)   (10 citations)  (Correct)

No context found.

Strom, R.E., Yemini, S.: Typestate: A programming language concept for enhancing software reliability. IEEE TSE 12 (1986) 157--171 24


Automatic Detection and Repair of Errors in Data - Structures Brian Demsky   (Correct)

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.


Existential Heap Abstraction Entailment is Undecidable - Kuncak, Rinard (2003)   (1 citation)  (Correct)

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.


Detecting Security Vulnerabilities in C code with Type Checking - Extended Ferm (2003)   (Correct)

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.


Error Checking with Client-Driven Pointer Analysis - Guyer, Lin (2003)   (Correct)

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.


A Language for Role Specifications - Kuncak, Lam, Rinard (2001)   (Correct)

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.


A Practical Type System and Language for Reference Immutability - Birka, Ernst (2004)   (1 citation)  (Correct)

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.


On Generalized Records and Spatial Conjunction in Role Logic - Kuncak, Rinard (2004)   (Correct)

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.


Safety-Checking of Machine Code - Xu (2001)   (25 citations)  (Correct)

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).


Verifying Safety Properties using Separation and - Heterogeneous Ions Eran   (Correct)

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.


A Direct Approach to Control-Flow Sensitive Region-Based.. - Henglein, Makholm, Niss (2001)   (8 citations)  (Correct)

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.


On Modular Pluggable Analyses Using Set Interfaces - Lam, Kuncak, Rinard (2003)   (Correct)

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.


Incorporating Domain-Specific Information into the Compilation.. - Guyer (2003)   (Correct)

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.


Flow-Sensitive Type Qualifiers - Foster, Terauchi, Aiken (2002)   (43 citations)  (Correct)

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.


Hermes Language Experiences - Korfhage, P. (1995)   (Correct)

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