Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. MIT Electrical Engineering and Computer Science Series. MIT Press, 1986.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....object type. In this paper, we propose providing more than one type for every declared class, so that expressions that may yield null can be identified. Type systems where one can distinguish special values like null from proper values exist. The tagged unions in the object centered language CLU [9] are a good example, because CLU requires their use in order to introduce null in the first place. For any type T , one can declare a T or null type NT as follows: NT = oneof [ None: null Value: T ] where None and Value are user defined tags, and where null , in CLU, denotes a ....

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. MIT Electrical Engineering and Computer Science Series. MIT Press, 1986.

....a trend towards increased built in language support for advanced requirements of data intensive applications. In addition to elementary access primitives (get, insert, delete, update and scan) for bulk structures, many DBPLs recognize the need to provide iteration abstractions like iterators [LG86] query expressions [BCD89] set operators [Mer84] or data deduction mechanisms in rule oriented systems [NT89, ERMS91] The rationale behind such declarative access specifications is to provide concise and optimizable notations for complex data selection and data construction tasks. For example, ....

B. Liskov and J. Guttag. Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series. MIT Press, 1986.

....f is an object field, is then defined only when the static type of the expression E is a non null object type. An expression of a may be null type can be cast to the corresponding non null type; the cast fails (dynamically) if the expression evaluates to null. May be null types were used in CLU [25], but they seem mostly to have been forgotten since. Another possible measure for increasing the strength of program invariants enforced by a programming language is to augment the type system with dependent types (see, e.g. 2, 39] These are essentially record, map, array, or object types ....

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. MIT Electrical Engineering and Computer Science Series. MIT Press, 1986.

....present paper did not arise, or were ignored in the semi formal treatments in the literature. These treatments include Milner s definition of simulation [37] Hoare s classic treatment of abstraction functions [18] and the influential work of Liskov and Guttag and the rest of the CLU community [35]. The first programming language to support information hiding in the way our units do was Mesa [38] with its definition modules and implementation modules. The Mesa designers appear to have been influenced by Parnas s classic paper on decomposing systems into modules [46] Mesa in turn ....

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. MIT Electrical Engineering and Computer Science Series. MIT Press, 1986.

....for object oriented design [36] More recently, graphs have been used to model object oriented data bases in [16, 12, 3] Class dictionary graphs focus only on part of and inheritance relations between classes. One notably absent relation is the uses relation between class operations (see e.g. [29]) The call relationships between classes describe important design information, e.g. for checking the Law of Demeter [25] We call a class S a supplier class to a class C, if in C we use the functions of class S. The part classes of a class C are one important kind of supplier classes of C. If ....

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series. MIT Press, McGraw-Hill Book Company, 1986.

....spatial ones is a problem generally acknowledged by the software industry [1] Software engineering provides di#erent 1 techniques and tools for structuring the software development process into di#erent phases. Thereby, one of the most important phases (and products) is the specification [2, 3]. It structures a task at hand into single actions, describes the restrictions of the actions, and captures which results are expected. However, the specification does not go into detail about how the actions are executed. Specifications are the core of standardization e#orts since a ....

B. Liskov and J. Guttag, Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series, Cambridge, MA: MIT Press, 1986.

....is a high level concept which does not reveal implementation detail; the parts might be implemented by operations. Class dictionary graphs focus only on part of and inheritance relations between classes. One notably absent relation is the uses relation between class operations (see e.g. LG86] The call relationships between classes describe important design information, e.g. for checking the Law of Demeter [LHR88] However, we find that class dictionary graphs as presented here, are a useful design abstraction which can be debugged independently. Only in later design stages, we ....

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series. MIT Press, McGraw-Hill Book Company, 1986.

....be easily discovered in a formal description. 3 ALGEBRAIC SPECIFICATIONS There is a growing consensus that formal specification methods are necessary for projects of some complexity; however, it is often unclear what method to choose. Algebraic specifications [Guttag, Horowitz, and Musser, 1978; Liskov and Guttag, 1986] combine the advantages of data abstraction (supporting object oriented modeling) with an axiomatic method (abstracting from particular execution models) and a functional style (offering clean semantics) In addition, they are easier to learn, read, and write than most other styles. An algebraic ....

....or lists) Note that the variables used in the axioms are implicitly universally quantified, i.e. the above equations hold for all possible stacks and items. There are informal rules for generating axioms which are easy to follow and achieve sufficient completeness and consistency in the sense of [Liskov and Guttag, 1986]. 4 FUNCTIONAL PROGRAMMING LANGUAGES In functional programming languages, everything is a function returning a value. LISP is the oldest and probably most often used functional language, but APL and ML are other well known examples. One distinguishes pure functional languages, where functions are ....

Liskov, B., and Guttag, J. Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series, Cambridge, MA: The MIT Press, 1986.

.... on consist of two parts: the representation invariant and the abstraction function (or, more properly, abstraction relation [BHKW94, Lea89] The representation invariant captures assumptions or programming conventions about the way information is recorded in the component s representation [LG86, pp. 72 74] For example, the implementation of Two Way List described in Section 2 relies on several conventions: 1. The TWL Nodes within a Two Way List are doubly connected in a single chain. 2. The pre front and pre fence pointers refer to nodes within the same chain. 3. The unconnected ....

....chain. 3. The unconnected pointers on the sentinel nodes are set to NULL. 4. The pre front pointer always refers to the sentinel node at the beginning of the chain. These conventions are stated informally here, but they could be easily formalized. Some languages, such as RESOLVE [W 94] CLU [LG86] and Eiffel [Mey88] even provide syntactic slots for expressing representation invariants. The abstraction function then relates representation values to the corresponding conceptual values they realize [LG86, pp. 70 71] It captures the intentions the implementer had in mind about the ....

[Article contains additional citation context not shown here]

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series. MIT Press, Cambridge, MA, 1986.

....for object oriented design [38] More recently, graphs have been used to model object oriented data bases in [18, 14, 5] Class dictionary graphs focus only on part of and inheritance relations between classes. One notably absent relation is the uses relation between class operations (see e.g. [31]) The call relationships between classes describe important design information, e.g. for checking the Law of Demeter [27] However, we find that class dictionary graphs as presented here, are a useful design abstraction which can be debugged independently. Only in later design stages, we augment ....

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series. MIT Press, McGraw-Hill Book Company, 1986.

....atomicity. A CLU array is a variable length array with arbitrary bounds. In addition to the normal fetch operations, an item can be appended to an array, increasing its length by one. Similarly, the last item can be removed, shrinking the array, etc. Figures 4 7 and 4 8 show a trait (adapted from [Liskov Guttag 86] that defines CLU array values and some useful operators. Most of the operators are self explanatory. The cut operator removes all elements with indices less than a given index, j, adjusting lbound, the low bound of the array, to j if j is defined in the array. The trunc operator truncates an ....

Barbara Liskov, and John Guttag. Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series. The MIT Press, McGraw Hill, Cambridge, MA, 1986.

....but borrows much of its syntax from Anna. Penelope s verification is sound across modules. However, in addition to not supporting pointer types (and Ada doesn t feature object types) Penelope does not support abstraction and thus ducks the problem altogether. 10.6. 2 CLU Abstraction in CLU (see [55]) is done under the assumption that the implementation does not share its values (so called objects) with clients of the interface. Such sharing is referred to as rep exposure. That phenomenon is easily produced, however, and then verification is no longer sound. Similar issues are treated in ....

B. Liskov and J. Guttag. Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series. MIT Press, Cambridge, MA, 1986.

....results of a computation. A specification is written such that a conforming implementation is guaranteed to produce the correct result; a specification defines a sufficient condition for correctness. There are a wealth of formal methods including model based (e.g. Z [8] algebraic (e.g. Larch [18]) and trace based (e.g. 15] methods. While these methods differ in their formal underpinnings, each is expressive enough to describe computations over unbounded data domains, such as the naturals. Thus, each is capable of specifying container data structures. In fact, specifications for stacks ....

....in their formal underpinnings, each is expressive enough to describe computations over unbounded data domains, such as the naturals. Thus, each is capable of specifying container data structures. In fact, specifications for stacks and queues are often given as examples to illustrate a method [8, 15, 18]. Trace specifications [15] are particularly relevant to the work described in this paper. These are abstract specifications of the observable interface behavior of a software component. A trace specification defines the legal sequences of calls to operations in a component s interface and the ....

B. Liskov and J. V. Guttag. Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series. MIT Press, Cambridge, MA, 1986.

....of information hiding: structure hiding. In general, the Law prevents a method from directly retrieving a subpart of an object which lies deep in that object s part of hierarchy. Instead, the programmer must use intermediate methods to traverse the part of hierarchy in controlled small steps [LG86]. In some object oriented systems, the programmer can protect some of the instance variables or methods of a class from outside access by making them private. This important feature complements the Law to increase modularity but is orthogonal to it. The Law promotes the idea that the instance ....

....above are acceptable. Our experience has been that writing programs which follow the Law of Demeter decreases the occurrences of nested message sending and decreases the complexity of the methods, but it increases the number of methods. The increase in methods is related to the problem outlined in [LG86] which is that there can be too many operations in a type. In this case the abstraction may be less comprehensible, and implementation and maintenance are more difficult. There might also be an increase in the number of arguments passed to some methods. One way of correcting this problem is to ....

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series. MIT Press, McGraw-Hill Book Company, 1986.

....is a high level concept which does not reveal implementation detail; the parts might be implemented by operations. Class dictionary graphs focus only on part of and inheritance relations between classes. One notably absent relation is the uses relation between class operations (see e.g. LG86] The call relationships between classes describe important design information, e.g. for checking the Law of Demeter [LHR88] However, we find that class dictionary graphs as presented here, are a useful design abstraction which can be debugged independently. Only in later design stages, we ....

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series. MIT Press, McGraw-Hill Book Company, 1986.

No context found.

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. MIT Electrical Engineering and Computer Science Series. MIT Press, 1986.

No context found.

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. MIT Electrical Engineering and Computer Science Series. MIT Press, 1986.

No context found.

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. MIT Electrical Engineering and Computer Science Series. MIT Press, 1986.

No context found.

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. MIT Electrical Engineering and Computer Science Series. MIT Press, 1986.

No context found.

B. Liskov and J. Guttag, Abstraction and Specification in Program Development, ser. MIT Electrical Engineering and Computer Science Series. MIT Press, 1986.

No context found.

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series. MIT Press, McGraw-Hill Book Company, 1986.

No context found.

Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series. McGraw-Hill, 1986.

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