D.L. Parnas. Information distribution aspects of design methodology. IFIP Congress (1) 1971: 339-344, 1972.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....is at the module level rather than at the class level. Also, we believe that modules should support the declaration of more than one class (examples showing the need for this are given in [26] The basic intuition about modules is that they should support the reuse or replacement of code [31]. This requires that the properties of an imported module should be preserved by its importing module: we want old classes to behave the same way in their new context as they did in their original context. In fact, this requirement is often not satis ed by code that is written in the usual object ....

David Parnas. Information distribution aspects of design methodology. Information Processing '72, 71:339-344, 1972.

....by no means limited to speci cation languages, let al..one equational languages, and indeed, a slightly more concrete version of hidden information modules have been used to greatly extend Ada generics [28, 18] There are many good reasons to hide information in modules. First, following Parnas [23], information hiding supports data abstraction, and more generally, allows replacing one module by another having the same semantics for its visible signature, but a di erent implementation, without having to worry that other modules might have used details of the implementation. Second, a classic ....

David Parnas. Information distribution aspects of design methodology. Information Processing '72, 71:339-344, 1972. Proceedings of 1972 IFIP Congress.

....it does and not how it is implemented. Any implementation that provides the needed function will do, provided it implements the function correctly and is efficient enough. Procedures are a useful abstraction mechanism, but in the early seventies some researchers realized that they were not enough [15], 16] 7] and proposed a new way of organizing programs around the connections between modules. The concept of data abstraction or abstract data type arose from these ideas [5] 12] Data abstractions provide the same benefits as procedures, but for data. Recall that the main idea is to ....

....must be encapsulated. If an implementation is encapsulated, then no other module can depend on its implementation details. Encapsulation guarantees that modules can be implemented and reimplemented independently; it is related to the principle of information hiding advocated by Parnas [15]. 2.1. Locality Abstraction when supported by specifications and encapsulation provides locality within a program. Locality allows a program to be implemented, understood, or modified one module at a time: 1. The implementer of an abstraction knows what is needed because this is described in ....

Parnas, D. Information Distribution Aspects of Design Methodology. In Proceedings of IFIP Congress, North Holland Publishing Co., 1971.

....us denote it t, to the set fth; pkgg. z The symbols in Sigma but not in Psi are local or private types, operators, variables, etc. used in axioms to describe the semantics of operators, exceptions, etc. they are not exported. This gives us an information hiding capability, in the sense of [Par72, GM97]. Let us write H(M) for the H component of M , Sigma(M ) for its signature, Psi(M ) for its visible signature, and A(M) for its axioms. We call M atomic if H(M) note that in this case, jM j = Psi(M ) Finally, we let jj(H; Sigma; Psi; A)jj = Sigma [ jHj ; and call it the working ....

Parnas, D. Information Distribution Aspects of Design Methodology. In Proceedings of 1972 IFIP Congress, pages 339--344, 1972.

....of this paper are by no means limited to speci cation languages, let al..one equational languages, and indeed, a slightly more concrete version has been used to greatly extend Ada generics [27, 17] There are several good reasons to hide information in modules. First, as emphasized by Parnas [22], information hiding supports data abstraction, and more generally, allows replacing one module by another having the same semantics for its visible signature, but a di erent implementation, without having to worry that other modules might have used details of the implementation. Second, a classic ....

David Parnas. Information distribution aspects of design methodology. Information Processing '72, 71:339-344, 1972.

....Site of mapping insert : 125 8.6 Optimized Call Sites of assignment create : 126 8. 7 Optimized Call Sites of substitution store : 127 12 Introduction Many approaches to programming emphasize the use of module interfaces (or abstractions) [37, 45]. The basic idea is to achieve a separation of concerns. The client of an interface looks at its specification and writes code that uses the interface. He need not concern himself with how the specified behavior is achieved. The implementor s job is to provide an implementation that satisfies the ....

D. L. Parnas. Information distribution aspects of design methodology. In Proceedings of the 1971.

.... TW72 connections are control transfer points, parameter passing or shared data [20] As Parnas pointed out in 1972, such a definition of connection is a highly dangerous oversimplification (sic) The connections between components are the assumptions which the components make about each other [18]. Many examples can be given to show that component assumptions can be critical at an architectural level analysis. For example, ffl Transaction servers or security supervisors usually assume that all accesses to a database server are done through them. It is not enough to check if components ....

....we discuss how existing ADLs can be extended to include the ideas presented in this paper. Finally in 5 with conclusions and future work. 2. Related work The term assumption has been used by the software engineering community in different ways. Our perspective of this term is borrowed from [18] where connections are thought of as assumptions that components make about each other, instead of control or information transfer points. Our view is that assumptions extend the idea of connection as a control or information transfer point, that interaction and assumptions can be combined to ....

D. Parnas. Information distribution aspects of design methodology. In Proceedings of the

....machines for the five principal language layers (imperative core, static classes, object oriented features, exception handling and concurrency) The third kind of structuring mechanism for ASMs we consider in this paper is of syntactical nature, dealing essentially with name spaces. Parnas [17] information hiding principle is strongly supported by the ASM concept of external functions which provides also a powerful interface mechanism (see [4] A more syntax oriented form of information hiding can be naturally incorporated into ASMs through the notion of local machine state, of ....

D. L. Parnas. Information distribution aspects of design methodology. In Information Processing 71, pages 339--344. North Holland Publishing Company, 1972.

....machines for the ve principal language layers (imperative core, static classes, object oriented features, exception handling and concurrency) The third kind of structuring mechanism for ASMs we consider in this paper is of syntactical nature, dealing essentially with name spaces. Parnas [17] information hiding principle is strongly supported by the ASM concept of external functions which provides also a powerful interface mechanism (see [4] A more syntax oriented form of information hiding can be naturally incorporated into 3 ASMs through the notion of local machine state, of ....

D. L. Parnas. Information distribution aspects of design methodology. In Information Processing 71, pages 339-344. North Holland Publishing Company, 1972.

....modules to see and use. It also is echoed in the using module, in a similar list which specifies the subset of these names that it will use. The rest of the names within the supplying module, not to mention all the code, are hidden from other modules. This hiding is central to data abstraction [Par71] because it prevents any exploitation of the supplying module except through the interface, including uses that take advantage of special features of the implementation. Such modules are called abstract data types. It has been argued [AM84] that special syntax is not needed for these modules, ....

D. L. Parnas. Information distribution aspects of design methodology. In Proceedings of the 1971 IFIP Congress, pages 339--44, Amsterdam, 1971. North-Holland Publ. Co. 12

....for equational logic, propositional dynamic logic, infinitary logic (L 1 ) monadic second order logic, etc. 3.1 Information Hiding Information Hiding is an important and well known technique in both conventional programming and formal specification design. Already in the early 70 s, Parnas [34, 33] had emphasised the importance of hiding implementation details within a module. This is accomplished by allowing access to the data representation of a specification only through operations exported by its module. In a somewhat similar spirit, Bergstra and Tucker [1] had shown that any recursive ....

D. Parnas. Information distribution aspects of design methodology. In Information Processing'72, volume 71, pages 339--344, 1972. Proceedings of 1972 IFIP Congress.

....classical and intuitionistic weak second order logics with predicate variables of all arities. 3.4 Information Hiding Information Hiding [13, 17, 19] is an important and well known technique in both conventional programming and formal specification and design. Already in the early 70 s, Parnas [27, 26] had emphasised the importance of hiding implementation details within a module. This is accomplished by allowing access to the data representation of a specification only through operations exported by its module. As far as logical specification is concerned, the theory of a Sigma R module is ....

D. Parnas. Information distribution aspects of design methodology. In Information Processing'72, volume 71, pages 339--344, 1972. Proceedings of 1972 IFIP Congress.

....here was to recognize that operations should be associated with data representations; this is exactly the same insight that advanced algebra from mere sets to algebras, which are sets with their associated operations. In software engineering this insight seems to have been due to David Parnas [83], and in algebra to Emmy Noether [98] its systematisation was pioneered by Garrett Birkho [7] but see also [100] It turns out that although abstraction as isomorphism is enough for algebras representing data values (numbers, vectors, etc. other important problems in software engineering ....

David Parnas. Information distribution aspects of design methodology. Information Processing '72 , 71:339-344, 1972. Proceedings of 1972 IFIP Congress.

....languages support some form of modularisation, and most mathematical results about modules have appeared in the context of formal software engineering, particularly specification languages. 2 1.1. 1 Some history The earliest work on software modules with which we are familiar is by Parnas [36, 37, 38]. Program modules differ from earlier program structuring mechanisms such as subroutines, procedures and blocks, in that they may include a number of procedure and data definitions, may be parameterized, may import other modules, and may hide certain elements. A major motivation for modules in ....

David Parnas. Information distribution aspects of design methodology. Information Processing '72, 71:339--344, 1972. Proceedings of 1972 IFIP Congress.

....foundations. The theory of algebraic specification has been implemented in many computing systems, and is also an important technique in Software Engineering methodologies. While the insight that operations should be associated with data representations seems to have been due to David Parnas [77], the legendary group ADJ 5 made a decisive step forward by using initiality (a category theoretic concept) as a characterisation for the notion of standard model [44] Many sorted equational logic became the main logical system underlying the theory of algebraic specifications and abstract data ....

....substitution is an answer for a query iff the query satisfies the substitution. The only inference rule defining the entailment relation encodes the translation of substitutions along module imports. 5.0. 4 Some History The earliest work on software modules with which we are familiar is by Parnas [77, 78, 79]. Program modules differ from earlier program structuring mechanisms such as subroutines, procedures and blocks, in that they may include a number of procedure and data definitions, may be parameterised, may import other modules, and may hide certain elements. A major motivation for modules in ....

David Parnas. Information distribution aspects of design methodology. Information Processing '72, 71:339--344, 1972. Proceedings of 1972 IFIP Congress. 109

....is at the module level rather than at the class level. Also, we believe that modules should support the declaration of more than one class (examples showing the need for this are given in [25] The basic intuition about modules is that they should support the reuse or replacement of code [30]. This requires that the properties of an imported module should be preserved by its importing module: we want old classes to behave the same way in their new context as they did in their original context. In fact, this requirement is often not satisfied by code that is written in the usual object ....

David Parnas. Information distribution aspects of design methodology. Information Processing '72, 71:339--344, 1972. Proceedings of 1972 IFIP Congress.

....variables of a single instance of X (namely the variables of the current object) whereas in other languages, such as CLU[Lis81] or C [Str87] for example, in X there can be access to variables of all instances of X . 38 For reasons of simplicity, in A1 we use the first policy. 34 See. e.g. Par71, Par72, LG86, Mey88] 35 The earliest such language was Simula 67[DN66, DH72] 36 cf. e.g. BDMN73, GR83, Mey88, Str87] 37 These are called, for example, instance variables in Smalltalk[GR83] and attributes in Eiffel[Mey92] The more general terminology in Eiffel is used to distinguish ....

D. Parnas. Information Distribution Aspects of Design Methodology. In Proceedings of IFIP Congress. North Holland Publishing Co., 1971.

....is desirable to decompose the software construction task into a set of smaller programming assignments. Each assignment is to produce a group of programs (cf. Section 4.8) which we call a module. In this section, we assume that the modules have been designed using the information hiding principle [23, 24]. The division of the software into modules is described informally in a Software Module Guide, which states the responsibilities of each module [4, 41] However, one must specify the behaviour of these modules precisely to allow the module implementors to work independently with a reasonable ....

D.L. Parnas, "Information Distributions Aspects of Design Methodology", in: Proceedings of the IFIP Congress'71, Booklet TA-3, 1971, pp. 26-30.

No context found.

D.L. Parnas. Information distribution aspects of design methodology. IFIP Congress (1) 1971: 339-344, 1972.

No context found.

D. Parnas. Information distribution aspects of design methodology. Information Processing, 71:339--344, 1972.

No context found.

D. Parnas. Information distribution aspects of design methodology. Information Processing, 71:339--344, 1972.

No context found.

David Parnas. Information distribution aspects of design methodology. Information Processing '72, 71:339--344, 1972.

No context found.

D. L. Parnas, "Information distribution aspects of design methodology," in Information Processing 71, vol. 1, C. V. Freiman, J. E. Griffith, and J. L. Rosenfeld, Eds. North-Holland: Elsevier, 1971, pp. 339-344.

No context found.

D.L. Parnas. Information distribution aspects of design methodology. IFIP Congress (1) 1971: 339-344, 1972.

No context found.

D. L. Parnas. Information Distribution Aspects of Design Methodology. IFIP Congress Preprints. 1971.

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