D.L. Parnas. A technique for software module specification with examples. Communications of the ACM, 15(5):330--336, May 1972.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....requires prior specific permission and or a fee. ICFP 02, October 4 6, 2002, Pittsburgh, Pennsylvania, USA. Copyright 2002 ACM 1 58113 487 8 02 0010 . 5. 00 1 Introduction Dynamically enforced pre and post condition contracts have been widely used in procedural and object oriented languages [11, 14, 17, 20, 21, 22, 25, 31]. As Rosenblum [27] has shown, for example, these contracts have great practical value in improving the robustness of systems in procedural languages. Eiffel [22] even developed an entire philosophy of system design based on contracts ( Design by Contract ) Although Java [12] does not support ....

Parnas, D. L. A technique for software module specification with examples. Communications of the ACM, 15(5):330--336, May 1972.

....fails, the developer who wrote the method or procedure itself is blamed. Properly assigned blame enables developers to quickly ascertain which component is faulty and then either fix the problem or replace the faulty component. Run time enforcement of behavioral contracts has been widely studied [1, 36, 40, 41, 44] and has a standard interpretation. Each method or procedure is annotated with a precondition and a post condition. These conditions are effect free program fragments that are evaluated when a method or procedure is called and when it returns. A pre condition is evaluated when a method or ....

....and proves that the implementation matches the calculus. Chapter 6 concludes with a discussion of the dissertation s contributions and future work. Behavioral Subtyping and Related Work Run time enforced behavioral contracts have been studied extensively in the context of procedural languages [22, 37, 44, 47]. Rosenblum [47] in particular, makes the case for the use of assertions in C and describes the most useful classes of assertions. Contract checking has also been added to many object oriented languages [9, 19, 24, 28, 29, 38, 41, 45] Even though these languages all support type hierarchies, ....

Parnas, D. L. A technique for software module specification with examples. Communications of the ACM, 15(5):330--336, May 1972.

....of the state machine. A module behavior satisfies such a specification if the module behavior contains only acceptable observations. The idea of describing module behavior with the help of state machines is not new, having already been proposed in various forms by other authors, e.g. Parnas72, Yonezawa77, Lainport83] However, previous work seems to be concerned primarily with how to write module specifications, and how to use proof rules to prove the correctness of implementations. The important issues pf what constitutes the meaning of a specification, and what it means for an ....

Parnas, D.L., "A Technique for Software Module Specification with Examples," CACM 15, 5(May, 1972), pp. 330.336.

....are the most prominent example here. In this paper, we discuss a situation in which these approaches are unsatisfactory and suggest to draw on the theory of program refinement and to use abstract programs as specification formalism. 1 Already modular programming introduced by Parnas in 1972 [45, 44] includes information hiding or encapsulation to separate concerns between implementing and using a module. This simplifies the analysis of complex software systems, because software using a specific module M can be described without explaining M s implementation details. As a further consequence, ....

David Lorge Parnas. A technique for software module specification with examples. Communications of the ACM, 15(5):330--336, May 1972.

....enjoyed using the method and believe that it is not reserved to experts [3] The B method is a mature synthesis of 30 years of software engineering research. Among the acknowledged sources are Floyd s initial work on proof obligations [7] Hoare s calculus [10] Parnas specification modules [14], Dijkstra s weakest precondition [5] Gries program development approach [8] as well as refinement theories of He and Hoare s [9] Morgan [13] Backhouse [2] and Jones [11] This article is a followup to an invited presentation of the B formal method at LOPSTR 99. There already exist a number ....

D.L. Parnas. A technique for software module specification with examples. CACM, 15(5):330--336, May 1972.

....these tools also require training in logic that most programmers do not possess. Because of these difficulties, we focus on tools that monitor the correctness of contracts at run time. Run time enforced behavioral contracts have been studied extensively in the context of procedural languages [11, 17, 23, 25]. Rosenblum [25] in particular, makes the case for the use of assertions in C and describes the most useful classes of assertions. Adding behavioral contracts to an object oriented language, however, poses subtle and complex problems. In particular, the contracts on overriding methods are ....

Parnas, D. L. A technique for software module specification with examples. Communications of the ACM, 15(5):330--336, May 1972.

....terms of the procedure s specification alone, independent of the procedure s implementation. When making use of such a methodology, it seems prudent also to enforce the methodology, which is done by checking that every procedure implementation meets its specification. This old and fundamental idea [33] too often seems to be forgotten. Making use of programming methodology overcomes the impossibility of designing a formal semantics, but the task may still seem unwieldy. To manage this complexity, we have found it convenient to translate the source language into a small intermediate language ....

D. L. Parnas. A technique for software module specification with examples. Communications of the ACM, 15(5):330--336, May 1972.

....should state more than the type signatures of exported and imported items. Ideally, interfaces should specify the entire behavior of a component; realistically, interfaces should at least specify essential aspects of the behavior. The earliest suggestion along those lines came from Parnas [20], who wanted correctness assertions in module interfaces. More recently, Beugnard, Jezequel, Plouzeau, and Watkins [2] proposed that components should come with four levels of interface descriptions: 1. syntactic aspects (type systems, i o dependencies) 2. behavioral guarantees (weak or strong ....

....and using it on several projects, he identifies the use of assertions as contracts for functions as critical. Furthermore, he identifies several important classes of contracts, especially, consistency checks across arguments, value dependencies, and subrange (or subset) membership of data. Parnas [20] was the first to recognize that languages for building large systems must support a linguistic mechanism for components and that components should come with contracts in the form of total correctness assertions. Anna [14] can be understood as a representative implementation of Parnas s proposal ....

Parnas, D. L. A technique for software module specification with examples. Communications of the ACM, 15(5):330--336, May 1972.

....directed intervals. In order to distinguish between specifications and subroutines for conventional interval arithmetic and their extension for directed intervals we call latter Generalized Interval Arithmetic Subroutines (GIAS) Designing GIAS specification we have kept to a specification scheme [Parnas 1972] ensuring completeness (in the sense of defining all possible uses) and correctness of the specification with no exceeding information. Although specified for floating point arithmetic and implemented in IEEE floating point environment [ANSI IEEE 1985] BIAS specification [Knueppel 1993] is not ....

Parnas, D. L.: "A Technique for software Module Specification with Examples"; Communications of the ACM, Vol. 15, No. 5 (1972), 330-336.

....directed intervals. In order to distinguish between specifications and subroutines for conventional interval arithmetic and their extension for directed intervals we call latter Generalized Interval Arithmetic Subroutines (GIAS) Designing GIAS specification we have kept to a specification scheme [Parnas 1972] ensuring completeness (in the sense of defining all possible uses) and correctness of the specification with no exceeding information. Although specified for floating point arithmetic and implemented in IEEE floating point environment [ANSI IEEE 1985] BIAS specification [Knueppel 1993] is not ....

Parnas, D. L.: "A Technique for software Module Specification with Examples"; Communications of the ACM, Vol. 15, No. 5 (1972), 330-336.

....one specification within another specification is a nightmare without the existence of any module concept. These problems should be familiar for software developers of the late 60ies or expert system developers of the late 70ies. Well known software engineering concepts like abstract data types [29] and programming in the large [9] have been invented to overcome these problems. Later on, these concepts have lead to the development of modular programming languages like Modula 2 [40] and Ada [37] the development of software design languages like HOOD [30] or EMIL [4, 24] and finally to ....

.... their own interfaces, offer more or less the concept of horizontally structuring graph data types as presented in [17] ffl Modules which export a single main node type and a number of related operations at their interfaces are our means for defining abstract data types in the classical sense [29]. All these different programming in the large styles have their own advantages and disadvantages. Even the most important software engineering principle, building abstract data types with hidden implementation details, has its severe drawbacks when it is combined with the idea of programming ....

D. Parnas. A Technique for Software Module Specifications with Examples. In Comm. of the ACM, volume 15, pages 330--336. ACM Press, 1972.

.... with the interpretations of the attribute symbols) Hence, the components (objects) that we specify are context independent in the sense that state information is localised rather than shared between components, a strategy for achieving high levels of modularity that can be traced back to [Parnas 72] Naturally, this notion of q locus does not formalise locality per se: it must be understood in conjunction with the notion of object description and of morphism between descriptions to be given in 8 J.FIADEIRO AND T.MAIBAUM section 3. Rather, our ultimate purpose is to provide a formalisation ....

D.Parnas, "A Technique for Software Module Specification with Examples", Communications ACM 15, 1972, 330-336

....3. synchronization contracts, and 4. quality of service contracts. Type systems and other syntactic contracts for components have been studied extensively in object oriented, functional, and higher order contexts [2, 10, 16] Behavioral contracts have been studied in procedural contexts [11, 19, 20, 25, 26]. Behavioral contracts have also been added to object oriented languages [4, 9, 12, 13, 14, 21, 22, 24] Adding behavioral contracts to object oriented languages, however, is subtle. Each of the referenced systems fails 1 i 1 q i 6 1 q q Figure 1: Component Interactions ....

....contracts, especially, consistency checks across arguments, value dependencies, and subrange (or subset) membership of data. Our work can be interpreted as an adaption of Rosenblum s work to Java. The adaption is complex due to our desire to deal with Java s class and interface hierarchies. Parnas [25] was the first to recognize that languages for building large systems must support a linguistic mechanism for components and that components should come with contracts in the form of total correctness assertions. Anna [20] can be understood as a representative implementation of Parnas s proposal ....

Parnas, D. L. A technique for software module specification with examples. Communications of the ACM, 15(5):330--336, May 1972.

.... showed how a formal calculus over such specifications could be used constructively to derive nondeterministic programs that meet them [Dij75] Specific techniques were also proposed to formally express intended properties for special kinds of programs, notably, datastructured programs [Par72, Lis75] and concurrent programs [Pnu77] This was the starting point for a whole new area of research aimed at specification in the large [Par77, SRS79, Abr80, Hen80] The interest in formal specifications and their multiple uses in software engineering has been growing continually since that point ....

D.L.Parnas, "A Technique for Software Module Specification With Examples", Comm. ACM Vol. 15, May 1972.

....transformation specification or programming languages in general and the language PROGRES in particular. This problem should be familiar for software developers of the late 60ies or expert system developers of the late 70ies. Well known software engineering concepts like abstract data types [39] and Programming in the Large [11] have been invented to overcome this problem. Later on, these concepts have led to the development of modular programming languages like Modula 2 and Ada [54] the development of software design languages like HOOD [41] and to the development of module ....

David Parnas. A technique for software module specifications with examples. Communications of the ACM, 15:330--336, 1972.

....state or reusing generic parts of one analysis or design document within another one is a nightmare without the existence of any module concept. These problems should be familiar for software developers of the late 60ies. Well known software engineering concepts like abstract data types (Parnas (1972)) and programming in the large (DeRemer and Kron (1976) have been invented to overcome these problems. They lead to the development of modular programming languages like Modula 2 or Ada (Wiener and Sincovec (1984) and software design languages like HOOD (Robinson (1992) or EMIL (Borstler ....

PARNAS D. (1972): A Technique for Software Module Specifications with Examples. Communications of the ACM, 15, 330-336.

....transformation specification or programming languages in general and the language PROGRES in particular. This problem should be familiar for software developers of the late 60ies or expert system developers of the late 70ies. Well known software engineering concepts like abstract data types [47] and Programming in the Large [48] have been invented to overcome this problem. Later on, these concepts have led to the development of modular programming languages like Modula 2 and Ada [49] the development of software design languages like HOOD [50] and to the development of module ....

D. Parnas. A technique for software module specifications with examples. Communications of the ACM, 15:330--336, 1972.

.... concept like those of Modula 2 [19] or Ada [17] which allows to break large specifications into smaller portions and to perform data abstraction for graph rewriting specifications [18] This approach was strongly influenced by well known software engineering concepts like Abstract Data Types [10] and Programming in the Large [4] We adopt these expressions and speak of Abstract Graph Types (AGTs) and Specification in the Large in the context of graph rewrite systems. However for graph transformation systems, in contrast to usual programming languages, it is not satisfying to ....

D. Parnas. A Technique for Software Module Specifications with Examples. In Comm. of the ACM, volume 15, pages 330--336. ACM Press, 1972.

....consistent state or reusing generic parts of one analysis design document within another one is a nightmare without the existence of any module concept. These problems should be familiar for software developers of the late 60ies. Well known software engineering concepts like abstract data types [13] and programming in the large [6] have been invented to overcome these problems. They lead to the development of modular programming languages like Modula 2 or Ada [22] and software design languages like HOOD [16] or EMIL [4] For a long time these ideas didn t have any significant impact onto ....

Parnas D.: A Technique for Software Module Specifications with Examples. Communications of the ACM, 15:330--336, 1972.

....ANN s and genetic algorithms, but it does so in a 3 D non grid based world. AS VAT Programming Maxims The following maxims apply at least to programming in AS VAT in particular, but they are perhaps more general than this. Similar maxims and programming guidelines can be found in works by Parnas [36,37] and Brooks [6, 7] In addition, though time constraints have not allowed me to reimplement my original commands according to the maxims described below, and thus, these newly proposed commands have not been tested, I am still fairly certain that changes made to the below commands according to ....

....of common real world agent behaviors to the definition of simulated agent behaviors in direct and intuitive ways. Maxim: Explicit Assumptions Make all relevant assumptions of a command explicit parameters to it in some fashion. Although it is usually wise to hide irrelevant details from users [36, 37] it is detrimental to hide relevant details of functions from them. If this occurs relevant aspects of the interface of a function that are hidden from the user can lead to unexplained or confusing behavior. The 4hood Random Move command of Figure 24 suffers from the malady of hiding relevant ....

[Article contains additional citation context not shown here]

Parnas, D.L. (1972) A Technique for Software Module Specifications with Examples. Communications of the ACM. v. 15, #5, 330-336.

....static and behavioural concerns, it will hardly be possible to find a unique formalism that will be appropriate for their specification. Instead, we will separate the different concerns and offer the most appropriate formalism for each of them. Following the principle of information hiding [Par72] the definition of a class will be divided into a public class interface and a private class specification. The class interfaces and specifications are, in turn, structured into different sections that offer different paradigms to specify the various concerns. We integrate these different ....

D. C. Parnas. A Technique for the Software Module Specification with Examples. Communications of the ACM, 15(5):330--336, 1972.

No context found.

D.L. Parnas. A technique for software module specification with examples. Communications of the ACM, 15(5):330--336, May 1972.

No context found.

D. L. Parnas. A technique for software module specification with examples. Communications of the ACM, 15(5):330--336, 1972.

No context found.

David L. Parnas. A technique for software module specification with examples. Communications of the ACM, 15(5):330--336, May 1972.

No context found.

D.L. Parnas. A technique for software module specification with examples. Communications of the ACM, 15:330--336, 1972.

First 50 documents

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