D. Parnas, "On a 'buzzword': hierarchical structure", in Proc. Information Processing 74".  Home/Search   Document Not in Database   Summary   Related Articles   Check

....an encapsulation of a design decision, hiding the implementation of the decision while making available to others the services the module provides. While modules and classes are closely related, it is important not to insist that each module be implemented as a single class and vice versa [23]. Most modules are implemented as a few closely related classes; sometimes a class contains code from more than one module. We specify the module structure in a document called a Module Guide. The Module Guide serves two main purposes: 1. Provide an annotated inventory of the source code. The ....

D.L. Parnas. On a `buzzword': Hierarchical structure. In Proc. IFIP Congress

....systems of hundreds of thousands or even millions of lines of code were becoming commonplace. Clearly the foundations of the ideas underlying the field that is today called software architecture were laid by Parnas, Brooks, Dijkstra and others in the 1960s through the 1980s ( 4] 11] 13] [32], 33] but what changed is that by the 1990s such large systems were becoming common. The pervasiveness of such huge systems meant that they needed to be understood and managed by ordinary skilled engineers. These systems were no longer solely the province of a select few virtuosos [39] ....

Parnas, D., "On a `buzzword': hierarchical structure," Proceedings IFIP Congress 74, 336-3390, 1974.

....and B in sequence will illustrate our ideas. The components must be functional, that is, must not communicate through global state. A is given the system input, and invokes B, passing its output as B s input; B s output is the system output. A must invoke rather than use B, in the sense of Parnas [buzz]. The system developer has a profile vector for the system, and the data sheets for A and B. Using the system profile (which is input to A) A s reliability mapping can be used to calculate RA , the reliability of A alone. The subdomains of the system are projected onto the subdomains of A s data ....

David Parnas, On a `buzzword': hierarchical structure, Proc. IFIP Congress `74, North Holland, 1974, pp 336339.

....knowledge, no previous work has been done on specification matching, where specifications capture formally the semantics of the objects they describe, e.g. in the form of pre and post condition predicates. Tangentially related to our work on search is the reliance on dependency [3] hierarchy [15], and or inheritance relations [6] among software components to browse through libraries. Specific examples include literate programming systems [8] where users attach informal documentation to code, and hypertext systems [2, 19] where users make explicit links between document parts. They focus ....

D. L. Parnas. On a `Buzzword': Hierarchical Structure, pages 336--339. North-Holland Publishing Company, 1974. 18

....and B in sequence will illustrate our ideas. The components must be functional, that is, must not communicate through global state. A is given the system input, and invokes B, passing its output as B s input; B s output is the system output. A must invoke rather than use B, in the sense of Parnas [buzz]. The system developer has a profile vector for the system, and the data sheets for A and B. Using the system profile (which is input to A) A s reliability mapping can be used to calculate R# , the reliability of A alone. The subdomains of the system are projected onto the subdomains of A s data ....

David Parnas, On a `buzzword': hierarchical structure, Proc. IFIP Congress `74, North Holland, 1974, pp 336339.

....STL1 incorporates all the rules of ordinary logic, such as modus ponens . A similar extension to the argument shows that Modus Ponens does not follow from the Lattice Rule in combination with STL1 STL6. 6 To go about proving code correct is a task which can be structured into levels (e.g. [Par72, Par74, Wen78]) One separates the business of proving the architecture correct (i.e. that the machine implements the semantics of its machine code) from the business of proving the assembler correct (i.e. that the semantics of the assembler instructions are correct with respect to the machine code and its ....

D.L. Parnas. On a `buzzword': Hierarchical structure. In Information Processing 1974 (Proc. IFIP Congress), pages 336--339. 1974.

....Dijkstra pointed out the elegant conceptual integrity exhibited by such an organization, with the resulting gains in development and maintenance ease. David Parnas pressed this line of observation with his contributions concerning information hiding modules [Parnas 72] software structures [Parnas 74] and program families [Parnas 76] A program family is a set of programs (not all of which necessarily have been or will ever be constructed) for which it is profitable or useful to consider as a group. This avoids ambiguous concepts such as similar functionality that sometimes arise when ....

Parnas, D. "On a 'Buzzword': Hierarchical Structure." 3363390. Proceedings IFIP Congress 74. North Holland Publishing Company, 1974.

....may be analysed into more complex actions, or more complex logical combinations of more refined state predicates, called a lowerlevel . The methodology of specification and verification using hierarchical decomposition was pioneered by Dijkstra [Dij68] and extensively developed by Parnas [Par72, Par74] Milestone systems to use this approach were SRI s PSOS [NBF 80] and SIFT [Wen78] See [Neu86] for a recent contribution to this area. We use state of the art logical methods, the predicate action diagrams of Lamport [Lam94b] which despite having a logically rigorous meaning concerning the ....

D.L. Parnas. On a `buzzword': Hierarchical structure. In Information Processing 1974 (Proc. IFIP Congress), pages 336--339. 1974.

.... 68] David Parnas pressed this line of observation with his contributions concerning information hiding modules, software structures, and program families, all of which stressed qualities of software measurable in terms of economies to the development and maintenance processes [Parnas 72, Parnas 74, Parnas 76] All of the work in the field of software architecture can be seen as evolving toward a paradigm of software development based on principles of large scale, componentbased system construction, and for exactly the same reasons given by Dijkstra and Parnas: structure matters. Choosing ....

Parnas, D. "On a `Buzzword': Hierarchical Structure," 335-342. Programming Methodology, Berlin, West Germany: Springer-Verlag, 1978.

....in this chapter. The Table Holder, Info and General Table Semantics (GTS) module sets are included. Design In this chapter, the necessary simplifying assumptions and special conventions required to define the scope of the problem are set down. Design contains the Module Guide, the Uses Hierarchy [10], and the informal Module Interface Specifications for the tool. Since the tool is to use both Normal and Vector Function Tables, conversion algorithms are described. The chapter finishes with some implementation issues that arise from the use of other modules, outside the tool. Testing Tools ....

D. L. Parnas, "On a 'buzzword': Hierarchical structure," in Proceedings of IFIP World Congress 1974, pp. 354--359, North Holland, 1974.

....(CLIC) 4.1.1 Chaining Layered Integrity Checks Complex systems typically use structured decomposition to provide different levels of abstraction with increased functionality at succeeding levels. These decompositions induce a depends upon for correctness dependency relation between the levels [Par74] In secure systems, this form of decomposition serves to reduce the size and number of the objects that require verification, e.g. assurance of the object s proper operation. This is important because the verification process is typically difficult and expensive. Once a system of this type has ....

D. L. Parnas. On a 'buzzword': Hierarchical structure. In Proc. of the IFIP Congress, pages 336--339. NorthHolland, 1974.

....flow, class, calls, communicates with, synchronizeswith, and many others. Each represents a distinct view of the system that abstracts away a class of details, leaving a structure that is useful for a particular kind of analysis or understanding. Each is a view of the system s architecture. Parnas [9] counsels us that when confronted with software that claims to be hierarchically structured, it is incumbent upon us to ask (a) what do the nodes in the structure represent and (b) what is the relationship that is implied when two nodes are connected We extend that valuable lesson to software ....

Parnas, "On a `Buzzword': Hierarchical Structure," Proc. IFIP Congress 74, pp. 3363390, 1974.

....data types. The programming process would then continue until the problem of implementing all assumed abstract data types was solved only in terms of concrete types. The programming methodology outlined above leads to programs which are structured into a hierarchy of modules [Parnas72a] Parnas74] where each module implements some instance of an abstract data type. Visually, such a hierarchy may be represented by an acyclic graph as in Figure 6. Modules are represented by nodes. An arrow from a node N to a node M means that N is a user of M, that is, the successful completion of (at ....

D. Parnas, "On a Buzzword: Hierarchical Structure", in Proceedings IFIP Congress 1974, North Holland Publ. Co, 1974.

....a set of modules using the information hiding principle [9] The module uses relation is used to illustrate the system design of TLT. Module A is said to use Module B if at least one access program in Module A relies on the correct behavior of some programs in Module B to accomplish its task [10]. The top level module uses relation of TLT is shown in Figure 4.1. Key: Module A uses Module B Note: Every module uses the Status Reporting Module Module B Cell Holder User Interface Table Layout Expression Info Expression Conversion Expression Traverse LaTex Related Figure 4.1: TLT Top ....

Parnas, D.L., "On a `Buzzword': Hierarchical Structure," Proceedings of the IFIP Congress 1974.

....OnCircle OnCircle.m = K (b OnCircle.x OnCircle.y) OnCircle.m = K b OnCircle.y Rest (Rest.m = 1.0) Rest.y c) Rest.m 2.5) Rest.x c) An example table is given below after the four aliases are replaced by the substructures that they represent. Suppose p = 6 (p can be very large) and A[6] = ff1, 2, 3.8g, f2, 3, 4.1g, f3, 4, 5.2g, f4, 5, 6.3g, f3, 0, 7.4g, f4, 3, 0.5gg. The evaluation results of aliases are listed below: All A = fA[0] A[1] A[2] A[3] A[4] A[5]g OnPara = fg OnCircle = fA[2] A[5]g Rest = fA[0] A[1] A[3] A[4]g The replacement result of function PointFunc ....

....Module A uses Module B Module B Module A Evaluation Data Structure Alias Usage Value Alias Definition Alias Evaluation Figure 4.3: First Level Decomposition Module Uses Relation Figure 4. 3 illustrates the Module Uses Relation (derived from the program uses relation as described in [6]) Module A is said to use Module B if some programs in Module A rely on the correct behavior of some programs in Module B to accomplish their task. Table 4.1 gives the detailed Module Uses relation for all the modules developed for the Alias Table Tool. Table 4.1 Module Uses Relation Module ....

D. L.Parnas, "On a `Buzzword': Hierarchical Structure", Proceedings of the IFIP Congress 1974.

....in this chapter. The Table Holder, Info and General Table Semantics (GTS) module sets are included. Design In this chapter, the necessary simplifying assumptions and special conventions required to define the scope of the problem are set down. Design contains the Module Guide, the Uses Hierarchy [10], and the informal Module Interface Specifications for the tool. Since the tool is to use both Normal and Vector Function Tables, conversion algorithms are described. The chapter finishes with some implementation issues that arise from the use of other modules, outside the tool. Testing Tools ....

D. L. Parnas, "On a 'buzzword': Hierarchical structure," in Proceedings of IFIP World Congress 1974.

....section describes the modular structure of the TTS by describing the secret (hidden information) of each module in the system. Figure 2 shows a design schematic for the TTS: nested boxes represent the sub module relationship, and the vertical arrangement roughly corresponds to the uses hierarchy. [12, 15] At the first level of decomposition, the TTS is divided into three modules: kernel, infrastructure and applications, which are described in more detail below. The intended relationship between these modules is that programs in the kernel module use only other kernel programs, while programs in ....

David L. Parnas. On a `buzzword': Hierarchical structure. In Proc. IFIP Congress, pages 336--339. North Holland, 1974.

....= 1.0) Rest.y c) Rest.m 2.5) Rest.x c) H 1 G Figure 3.7: Using Aliases to Define PointFunc 3. Alias Definition and Use of Aliases 29 An example table is given below after the four aliases are replaced by the substructures that they represent. Suppose p = 6 (p can be very large) and A[6] = ff1, 2, 3.8g, f2, 3, 4.1g, f3, 4, 5.2g, f4, 5, 6.3g, f3, 0, 7.4g, f4, 3, 0.5gg. The evaluation results of aliases are listed below: All A = fA[0] A[1] A[2] A[3] A[4] A[5]g OnPara = fg OnCircle = fA[2] A[5]g Rest = fA[0] A[1] A[3] A[4]g The replacement result of function PointFunc is ....

....B Module B Module A Evaluation Data Structure Alias Usage Value Alias Definition Alias Evaluation Figure 4.3: First Level Decomposition Module Uses Relation 4. Alias Table Tool Design 35 Figure 4. 3 illustrates the Module Uses Relation (derived from the program uses relation as described in [6]) Module A is said to use Module B if some programs in Module A rely on the correct behavior of some programs in Module B to accomplish their task. Table 4.1 gives the detailed Module Uses relation for all the modules developed for the Alias Table Tool. Table 4.1 Module Uses Relation Module ....

D. L.Parnas, "On a `Buzzword': Hierarchical Structure", Proceedings of the IFIP Congress 1974, North Holland 1974, pp. 336-339.

.... information hiding principle [9] 4.2.1 Module Uses Hierarchy The module uses relation is used to illustrate the system design of TLT. Module A is said to use Module B if at least one access program in Module A relies on the correct behavior of some programs in Module B to accomplish its task [10]. The top level module uses relation of TLT is shown in Figure 4.1. Key: Module A uses Module B Note: Every module uses the Status Reporting Module Module B Module A Cell Holder User Interface Table Layout Expression Info Expression Conversion Expression Traverse LaTex Related Figure 4.1: TLT Top ....

Parnas, D.L., "On a `Buzzword': Hierarchical Structure," Proceedings of the IFIP Congress 1974, pp. 336--339, 1974.

.... 40 User SAST Interface TTS Maple Interface Status Reporting Maple Simplify SASTExpression Module A SAST Support Module B Key Module A uses Module B FIGURE 13 Uses Relation of Top Level FIGURE 13 illustrates the top level uses relation (derived from the program uses relation as described in [13]) Module A uses Module B if at least one program in Module A rely on the correct behaviour of some programs in Module B to accomplish its task. TABLE 1 gives the lower level uses relation for all the modules developed or modified for SAST. Module Level Uses User SAST Interface 9 TTS Maple Expn ....

Parnas D. L., "On a Buzzword: Hierarchical Structure", Proceedings of the IFIP Congress 1974, North Holland 1974, pp. 336-339.

....other modules. It uses the Specification interface module to read the specification from the file, the Output module to initialize the output files and Oracle Generation module to produce the oracle code. 1. Note that the module uses relation is derived from the program uses relation discussed in [24]. 40 5.2.2 Specification Interface The Specification Interface module is responsible for providing access to the PUT specification information. It is sub divided into the following sub modules. 5.2.2.1 Specification File (TOG spec.c) This module extracts the specification from a file and stores ....

Parnas, D. L., "On a `Buzzword': Hierarchical Structure", Proceedings of the IFIP Congress 1974, North Holland 1974, pp. 336-339.

No context found.

D. Parnas, "On a 'buzzword': hierarchical structure", in Proc. Information Processing 74".

No context found.

Parnas, D.L. On a 'Buzzword': Hierarchical Structure. in IFIP Congress 74. 1974: NorthHolland Publishing Company.

No context found.

Parnas D. L., On a 'Buzzword': Hierarchical Structure, in proc. IFIP Congress 74, pp. 336-339, 1974.

No context found.

Parnas, D.L., On A Buzzword: Hierarchical Structure, Proc. IFIP Congress 1974, Amsterdam, North Holland, 1974

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