D. L. Parnas and J. Madey. Functional documentation for computer systems engineering, vol. 2. Technical Report Technical Report CRL 237, McMaster University, Hamilton, Ontario, Sept 1991.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... University by Lawford et al. 6] Using a similar case study, their work concentrates on veri cation of the re nement of the requirements in the SRS into design elements, also expressed in SCR, in the software design description (SDD) They use an extension of the 4 variable model of Parnas [7] into a relational setting, and claim that their approach is more intuitive for system engineers. Our goal in the present work is essentially the same to develop easier to use veri cation approaches for application to the earlier part of the software development process. Another approach for ....

D. Parnas and J. Madey, \Functional documentation for computer systems engineering, " Technical Report CRL No. 273, Telecommunications Research Institute of Ontario, McMaster University, 1991.

....explicitly captures the limits of the required behavior. REQ describes the required system behavior by defining the relation that the system must maintain between the monitored and the controlled quantities. There are also three relations, IN, OUT, and SOF, which are related with the controller [Parnas 90] To meet the proposition (1) five relations, NAT, REQ, IN, OUT, SOF, need to satisfy the following proposition: NAT(M) # OUT(SOF(IN(M) REQ(M) 2) This proposition is compatible with the software acceptability condition in [Parnas 90] When the Four variable model was used in specifying ....

.... OUT, and SOF, which are related with the controller [Parnas 90] To meet the proposition (1) five relations, NAT, REQ, IN, OUT, SOF, need to satisfy the following proposition: NAT(M) # OUT(SOF(IN(M) REQ(M) 2) This proposition is compatible with the software acceptability condition in [Parnas 90] When the Four variable model was used in specifying and verifying the software requirements specification (SRS) and the software design description (SDD) of the shutdown system of Wolsong nuclear power plant, the condition, OUT(SOF(IN(M) REQ(M) was demonstrated to verify the correctness ....

Parnas D.L., Madey, J., "Functional Documentation for Computer Systems Engineering," Technical Report 90-287, Queen's University, TRIO, Sep. 1990.

.... a Formal Semantics of Tabular Expressions Ryszard Janicki Ridha Khedri Department of Computing and Software McMaster University Hamilton, Ontario, Canada L8S 4K1 fjanicki,khedrig mcmaster.ca Abstract In [24, 35, 38, 39] Parnas et al. advocate the use of relational model for documenting the intended behaviour of programs. In this method, tabular expressions (or tables) are used to improve readability so that formal documentation can replace conventional documentation. Parnas [36] describes several classes of ....

....table (input vector type) The multi dimensional tabular notation makes it easier to consider every case separately while writing or reading a design document. The key ideas of a tabular notation, one of the cornerstones of the relational model for documenting the intended behaviour of programs [24, 35, 38, 39], were rst developed in work for the U.S. Navy and applied to the A 7E aircraft [9, 15, 16, 42] The ideas were picked up by Grumman, the U.S. Air Force, Bell Laboratories and many others. Recently the tabular notations have been applied by Ontario Hydro in Darlington Nuclear Plant [4, 33, 34] ....

[Article contains additional citation context not shown here]

D. L. Parnas, J. Madey, Functional Documentation for Computer Systems Engineering, Science of Computer Programming, 25, 1 (1995), 41-61.

.... Expressions and Their Relational Semantics Ryszard Janicki Department of Computing and Software McMaster University Hamilton, Ontario, Canada L8S 4K1 janicki mcmaster.ca Abstract Tabular expressions (Parnas et al. [17, 23, 25, 26]) are means to represent the complex relations that are used to specify or document software systems. A formal model and a semantics for tabular expressions are presented. The model covers all known types of tables used in Software Engineering. 1 Introduction In the classical engineering ....

....of all the R i s. In principle, tabular expressions are generalization of plain two dimentional tables that are known from the beginnings of civilization. The key ideas of a tabular notation, one of the cornerstones of the relational model for documenting the intended behaviour of programs [17, 23, 25, 26], were rst developed in work for the U.S. Navy and applied to the A 7E aircraft [11, 10, 4, 29] The ideas were picked up by Grumman, the U.S. Air Force, Bell Laboratories and many others. Recently the tabular notations have been applied by Ontario Hydro in Darlington Nuclear Plant [3, 21, 22] ....

D. L. Parnas, J. Madey, Functional Documentation for Computer Systems Engineering, Science of Computer Programming, 25, 1 (1995), 41-61.

.... a Formal Semantics of Tabular Expressions Ryszard Janicki Department of Computer Science and Systems McMaster University Hamilton, Ontario, Canada L8S 4K1 janicki mcmaster.ca Abstract In [15, 22, 25, 26] Parnas et al. advocate the use of relational model for documenting the intended behaviour of programs. In this method, tabular expressions (or tables) are used to improve readability so that formal documentation can replace conventional documentation. Parnas [23] describes several classes of ....

....while writing or reading a design document. It turns out that using tables helps to make mathematics more practical for computing systems applications [15] The key ideas of a tabular notation, one of the cornerstones of the relational model for documenting the intended behaviour of programs [15, 22, 25, 26], were first developed in work for the U.S. Navy and applied to the A 7E aircraft [10, 9, 4, 28] The ideas were picked up by Grumman, the U.S. Air Force, Bell Laboratories and many others. Recently the tabular notations have been applied by Ontario Hydro in Darlington Nuclear Plant [3, 20, 21] ....

[Article contains additional citation context not shown here]

D. L. Parnas, J. Madey, Functional Documentation for Computer Systems Engineering, Science of Computer Programming, 25, 1 (1995), 41-61.

....system is its documentation, particularly if subsequentchanges are made. Formalizing the documentation leads to less ambiguity and thus less likelihood of errors. In the case of safety critical systems, timing issues become significant and methods for documenting these are especially important [115]. Formal methods provide a precise and unambiguous way of recording expected delivered system functionality and can therefore be used as a powerful documentation aid. The normal expectation would be that the system documentation contains both the requirements and the system specification in a ....

PARNAS, D.L., and MADEY, J.: `Functional documentation for computer systems engineering '. Version 2, CRL Report No. 237, TRIO, Communications Research Laboratory, Faculty of Engineering, McMaster University, Hamilton, Ontario, Canada L8S 4K1, September 1991

....system is its documentation, particularly if subsequentchanges are made. Formalizing the documentation leads to less ambiguity and thus less likelihood of errors. In the case of safety critical systems, timing issues become significant and methods for documenting these are especially important [97]. Formal methods provide a precise and unambiguous way of recording expected delivered system functionality and can therefore be used as a powerful documentation aid. The normal expectation would be that the system documentation contains both the requirements and the system specification in a ....

PARNAS, D.L., and MADEY, J.: `Functional documentation for computer systems engineering '. Version 2, CRL Report No. 237, TRIO, Communications Research Laboratory, Faculty of Engineering, McMaster University, Hamilton, Ontario, Canada L8S 4K1, September 1991 33

.... in the Software Design Description (SDD) comparing them against the requirements described in the Software Requirements Speci cation (SRS) In this work we review how this functional veri cation has been done in practice [3] We rst describe how a functional version of the 4 variable model of [9] can be decomposed to facilitate tool support and to reduce the manual e ort required to perform and document the speci cation and veri cation tasks. An example from [3] is then used to motivate a straight forward extension to a relational model. The relational model is necessary to rigorously ....

....of the SDV process is to verify, using mathematical techniques or rigorous arguments, that the behavior of every output de ned in the SDD, is in compliance with the requirements for the behavior of that output as speci ed in the SRS. It is based upon a variation of the four variable model of [9] that veri es the functional equivalence of the SRS and SDD by comparing their respective one step transition functions. The resulting proof obligation in this special case: REQ = OUT SOF IN (1) is illustrated in the commutative diagram of Figure 2. Here REQ represents the SRS state transition ....

[Article contains additional citation context not shown here]

D. Parnas and J. Madey. Functional documentation for computer systems engineering. Technical Report CRL No. 273, Telecommunications Research Institute of Ontario, McMaster University, September 1991.

....is usually the first document to describe the required behavior of a system under development. If errors in this document are propagated to the design phase (or, worse, to the implementation) they are more difficult and expensive to correct than if detected during the requirements phase [21]. Designers need techniques to analyze requirements before system design begins. The requirements specification is a behavioral specification of the system s activities, that describes the system s modes of operation and specifies the events that cause the system to change modes. The ....

Parnas, D. and J. Madey. "Functional Documentation for Computer Systems Engineering." Tech. Rep. TR-90-287, Queen's University, Kingston, Ontario, September 1990.

....relation of a set of mode classes is the conjunction of the classes transition relations. 2.2 Environmental Assumptions An SCR requirements document also specifies any assumptions of the behavior of the environment. Similar to the NAT relation in Parnas s 4 variable model of system requirements [31], an assumption specifies dependencies among the environmental conditions, imposed either by laws of nature or by other mode classes in the system. An example of an environmental assumption is the relationship between thermostat conditions TooCold, TempOk, and TooHot: exactly one of these ....

D. Parnas and J. Madey. Functional Documentation for Computer Systems Engineering (Version 2). Technical Report CRL Report 237, Department of Electrical and Computer Engineering, McMaster University, 1991.

....conversation making it a 3 Way call. The specification for Call Waiting was presented earlier in the paper; the specification for 3 Way Calling appears in Figures 12 and 13. The agent indicates his choices by initiating an event. Each possible event can be mapped to one of several input signals [11, 15]. On a simple telephone the events to initiate the second call and to merge it with the first might be mapped to the flashhook. Similarly, the signal to accept an incoming call when Call Waiting has been activated might be mapped to the flashhook. In this case the features will interact. For this ....

D. Parnas and J. Madey. Functional Documentation for Computer Systems Engineering (Version 2). Technical Report CRL Report 237, Department of Electrical and Computer Engineering, McMaster University, 1991.

....and the system goals they are meant to ensure. 2.1 Behavioral Requirements An SCR requirements specification models a system as a set of event driven, state transition machines. The machines environment is abstracted as a set of monitored state variables and controlled state variables [26, 29]. Changes to monitored variables may cause the system to change its mode or to alter the values of its controlled variables. The input language of each machine is a set of conditioned events. A condition is a predicate on monitored or mode class variables, an event when the value of a condition ....

....PumpOn = True False Initial: False Table 2: Event table for controlled variable PumpOn. 2.2 Environmental Assumptions An SCR requirements document also specifies assumptions of the behavior of the environment. Similar to the NAT relation in Parnas s 4 variable model of system requirements [26], an assumption specifies constraints on the values of conditions, imposed either by laws of nature or by other mode classes in the system. As such, assumptions are invariant constraints that must hold in all system states. The syntax and semantics of assumption specifications are described in ....

D. Parnas and J. Madey. "Functional Documentation for Computer Systems Engineering (Version 2)". Technical Report CRL Report 237, McMaster University, Department of Electrical and Computer Engineering, 1991.

....not be guaranteed to be accurate to the machine precision. Suppose we are to specify a function Zeroin(a; b; F ) which nds a zero of a continuous function F (x) given an interval [a; b] such that F (a)F (b) 0. In this example, we use the tabular notation in documentation introduced by Parnas [9, 10, 6]. The documentation includes a description of the environment that identi es a set of quantities of concern to software users and associates each one with a mathematical variable. Table 1 shows the environment variables of the function Zeroin(a; b; F ) The notations in Table 1: x : x is a ....

D.L. Parnas and J. Madey. Functional documentation for computer systems enginerring (version 2). CRL Report 237, Mcmaster University, TRIO (Telecommunications Research Institute of Ontario), Sept. 1991

....requirements only. 2.1 SCR Behavioral Requirements An SCR requirements specification models a systemto be developed as a set of conditioned event driven, state transition machines. The machines environment is abstracted as a set of monitored state variables and controlled state variables [16, 17]. Monitored variables model environment phenomena that affect the behavior of the machines, whereas controlled variables model environment phenomena that are controlled (i.e. modified) by the machines. For example, a thermostat that regulates the air temperature of a room would have monitored ....

....The resultant composite is called the reachability graph of the original specification. 2.2 Environmental Assumptions An SCR requirements document also specifies any assumptions of the behavior of the environment. Similar to the NAT relation in Parnas s 4 variable model of system requirements [16], an assumption specifies constraints on the values of conditions, imposed by laws of nature or by other mode classes in the system. As such, assumptions are invariant constraints that hold in all states of the specification s reachability graph. The syntax and semantics of assumption ....

D. Parnas and J. Madey. Functional Documentation for Computer Systems Engineering (Version 2). Technical Report CRL Report 237, Department of Electrical and Computer Engineering, McMaster University, 1991.

.... a Formal Semantics of Tabular Expressions Ryszard Janicki Ridha Khedri Department of Computing and Software McMaster University Hamilton, Ontario, Canada L8S 4K1 fjanicki,khedrig mcmaster.ca Abstract In [24, 35, 38, 39] Parnas et al. advocate the use of relational model for documenting the intended behaviour of programs. In this method, tabular expressions (or tables) are used to improve readability so that formal documentation can replace conventional documentation. Parnas [36] describes several classes of ....

....table (input vector type) The multi dimensional tabular notation makes it easier to consider every case separately while writing or reading a design document. The key ideas of a tabular notation, one of the cornerstones of the relational model for documenting the intended behaviour of programs [24, 35, 38, 39], were rst developed in work for the U.S. Navy and applied to the A 7E aircraft [9, 15, 16, 42] The ideas were picked up by Grumman, the U.S. Air Force, Bell Laboratories and many others. Recently the tabular notations have been applied by Ontario Hydro in Darlington Nuclear Plant [4, 33, 34] ....

[Article contains additional citation context not shown here]

D. L. Parnas, J. Madey, Functional Documentation for Computer Systems Engineering, Science of Computer Programming, 25, 1 (1995), 41-61.

....ffi [72] This refinement forms a link to the architecture given by the SL specification in section 3. 2. 4 Related work The development of requirements for a model of a dynamic system presented above is similar in spirit although not in the chosen formalism to work by Leveson [40, 34] and Parnas [64]. The Duration Calculus builds on Moszkowski s interval temporal logic [53, 54, 75] Time may also be handled explicitly as in TLA [38, 39] or within a conventional temporal logic [36, 65, 30] In a proof assistant, model checking [20, 7] might be very useful. The refinement approach outlined ....

D. L. Parnas and J. Madey. Functional documentation for computer systems engineering (version 2). Technical Report CRL 237, TRIO, McMaster University, Hamilton, Canada, September 1991.

.... Expressions and Their Relational Semantics Ryszard Janicki Department of Computing and Software McMaster University Hamilton, Ontario, Canada L8S 4K1 janicki mcmaster.ca Abstract Tabular expressions (Parnas et al. [17, 23, 25, 26]) are means to represent the complex relations that are used to specify or document software systems. A formal model and a semantics for tabular expressions are presented. The model covers all known types of tables used in Software Engineering. 1 Introduction In the classical engineering elds, ....

....of all the R i s. In principle, tabular expressions are generalization of plain two dimentional tables that are known from the beginnings of civilization. The key ideas of a tabular notation, one of the cornerstones of the relational model for documenting the intended behaviour of programs [17, 23, 25, 26], were rst developed in work for the U.S. Navy and applied to the A 7E aircraft [11, 10, 4, 29] The ideas were picked up by Grumman, the U.S. Air Force, Bell Laboratories and many others. Recently the tabular notations have been applied by Ontario Hydro in Darlington Nuclear Plant [3, 21, 22] ....

D. L. Parnas, J. Madey, Functional Documentation for Computer Systems Engineering, Science of Computer Programming, 25, 1 (1995), 41-61.

.... Simultaneously, there is a debate on whether formal specification languages ought to be executable or not [14, 17, 20] However, some researchers challenge the contention that specifications ought to be (fully) formal in the first place, e.g. Balzer et al. 1, 2] Karp (in [7] and Parnas ([30, 31], and in [32] Our objective is to shed some further light onto these debates. We propose to go back to the very reasons that make the running of a program useful, i.e. the fact that its results can be straightforwardly interpreted as a statement about the real world. Starting from this simple ....

D.L. Parnas and J. Madey. Functional documentation for computer systems engineering. Science of Computer Programming 25:41--61, October 1995.

.... to describe the functional requirements of software unambiguously and concisely [13, 14] the SCR method has been extended recently to describe system, rather than simply software, requirements and to incorporate techniques for representing nonfunctional requirements, such as timing and precision [17, 21, 22]. Designed originally for use by engineers, the SCR method has been successfully applied to a variety of practical systems. These include avionic systems, such as the A 7 Operational Flight Program (OFP) 13, 1] a submarine communications system [12] and safetycritical components of two nuclear ....

....checking is an important first step in formal analysis of requirements specifications, since, as indicated above, other classes of formal analysis require a consistent specification. Although earlier requirements models, in particular, Faulk s automaton model [6] Parnas FourVariable Model [17], and the model underlying van Schouwen s specification [21, 22] define some aspects of the SCR notation, these models are too abstract to provide a formal basis for our tools. To provide a precise and detailed semantics for the SCR notation, our requirements model represents the system to be ....

[Article contains additional citation context not shown here]

D. Parnas and J. Madey. Functional documentation for computer systems engineering (Version 2). Technical Report CRL 237, Telecommunications Research Inst. of Ontario (TRIO), McMaster Univ., Hamilton, Ont., 1991.

.... module as a black box in that it does not reveal the module s secret (i.e. private data structures) It instead specifies an object by its externally observable behaviour, identifying all programs that can be called from outside the module (access programs) and describing their visible effects [5]. The module specification does not include how the module is, or should be implemented. The Table Holder module interface specification is documented using the trace assertion method. 2.2 Trace Assertion Method The trace assertion method [6] provides a means for producing a black box description ....

Parnas, D.L. and Madey, J., "Functional Documentation for Computer Systems Engineering. (Version 2)", CRL Report No. 237, Telecommunications Research Institute of Ontario (TRIO), McMaster University, Hamilton, ON, Canada, September 1991.

....Workpiece frame is to construct the Machine to perform the Operations on the Workpieces in response to the Operation Requests. 6.3 The Environment Effect Frame A final example may be called the Environment Effect frame. It has something in common with an approach described by Parnas and Madey [14]. It is suitable for an embedded system that controls an external domain. The principal parts are: Environment The domain to be controlled. It has state, and a behaviour that is partly autonomous and partly responsive to externally caused events. Connection The connection between the machine to ....

D L Parnas and J Madey; Functional Documentation for Computer Systems Engineering (Version 2); CRL Report 237, McMaster University, Hamilton Ontario, Canada, 1991.

....and tools [2] we began a new, complementary task in 1991. The new task s purpose is to construct tools supporting the formal specification and analysis of requirements based on the Software Cost Reduction (SCR) approach [8, 9] This approach, pioneered at NRL and extended recently by D. Parnas [12], emphasizes functional (rather than timing) behavior. Unlike the real time toolset, which is based on a graphical specification language, the SCR approach relies on a tabular notation. In this paper, I provide a brief overview of the two toolset efforts, describe some HCI issues we encountered in ....

D. Parnas and J. Madey, "Functional documentation for computer Systems Engineering," Rpt. CRL 237, McMaster Univ., Hamilton, ONT, 1991.

....is its documentation, particularly if subsequent changes are required. Formalizing the documentation leads to less ambiguity and thus less likelihood of errors. In the case of safety critical systems, timing issues become significant and methods for documenting these are especially important [55]. Formal methods provide a precise and unambiguous way of recording the expected and delivered system functionality, and can therefore be used as a powerful documentation aid. The normal expectation would be that the system documentation contains both the requirements and the system specification ....

Parnas, D.L. & Madey, J.: Functional Documentation for Computer Systems Engineering. Version 2, CRL Report No. 237, TRIO, Communications Research Laboratory, Faculty of Engineering, McMaster University, Hamilton, Ontario, Canada L8S 4K1, September 1991.

....of interest to industry or the military requires their balanced integration with less rigorous methods. Figure 1. 1 depicts a framework for refining an assurance argument in the context of a simple, but typical, software development process based on the Software Cost Reduction (SCR) Methodology [34, 35]. The primary levels of system refinement and documentation are shown along the left side of the figure. Along the right side are classes of specification languages and tools that contribute to the formal specification and analysis of the system. The result of integrating the use of the languages ....

D.L. Parnas and J. Madey. Functional documentation for computer systems engineering. CRL Report 237, Communications Research Laboratory, McMaster University, Ontario, Canada, 1992.

.... a Formal Semantics of Tabular Expressions Ryszard Janicki Department of Computer Science and Systems McMaster University Hamilton, Ontario, Canada L8S 4K1 janicki mcmaster.ca Abstract In [15, 22, 25, 26] Parnas et al. advocate the use of relational model for documenting the intended behaviour of programs. In this method, tabular expressions (or tables) are used to improve readability so that formal documentation can replace conventional documentation. Parnas [23] describes several classes of ....

....while writing or reading a design document. It turns out that using tables helps to make mathematics more practical for computing systems applications [15] The key ideas of a tabular notation, one of the cornerstones of the relational model for documenting the intended behaviour of programs [15, 22, 25, 26], were first developed in work for the U.S. Navy and applied to the A 7E aircraft [10, 9, 4, 28] The ideas were picked up by Grumman, the U.S. Air Force, Bell Laboratories and many others. Recently the tabular notations have been applied by Ontario Hydro in Darlington Nuclear Plant [3, 20, 21] ....

[Article contains additional citation context not shown here]

D. L. Parnas, J. Madey, Functional Documentation for Computer Systems Engineering, Science of Computer Programming, 25, 1 (1995), 41-61.

.... originally to describe the functional requirements of software precisely and unambiguously [15, 16] the SCR method has been extended recently to describe system, rather than simply software, requirements and to represent both functional and nonfunctional (e.g. timing and accuracy) requirements [21, 24]. Designed for use by engineers, the SCR method has been applied successfully to a number of practical systems, including the A 7 aircraft s Operational Flight Program [15, 1] a submarine communications system [14] and safety critical components of two nuclear power plants, the Darlington plant ....

....tabular notation, the underlying finite state machine model, and special constructs for specifying requirements, such as conditions and events, input and output data items, mode classes, and terms. Recently, a number of researchers, including Faulk [7, 8, 9] van Schouwen [24, 25] and Parnas [21], have extended and refined the original SCR method and strengthened the method s formal foundation. Faulk s thesis in 1989 [7] provided formal definitions for parts of the A 7 model. In particular, it described the condition tables as total functions and the mode classes as finite state machines ....

[Article contains additional citation context not shown here]

D. Parnas and J. Madey. Functional documentation for computer systems engineering (Version 2). Technical Report CRL 237, Telecommunications Research Inst. of Ontario (TRIO), McMaster Univ., Hamilton, Ont., 1991.

....discovering some performance bottlenecks, and solving these performance bottlenecks by either last minute changes, or making a new design, we aim at detecting performance bottlenecks as soon as possible. Therefore, we use the top down design methodology as described by Parnas as well as Randell [PaDa67,PaMa91,ZuRa68]. The idea is The investigations were partly supported by the Foundation for Computer Science in the Netherlands SION under project 612 317 025 nicknamed Starfish. that a simulation model is evolved to a real system by gradual addition of detail. The model is not only a true representation of ....

D. L. Parnas & J. Madey, "Functional Documentation for Computer Systems Engineering (version 2)," McMaster University, CRL-237, Hamilton, Ontario, Canada, September 1991.

....system is its documentation, particularly if subsequent changes are made. Formalizing the documentation leads to less ambiguity and thus less likelihood of errors. In the case of safety critical systems, timing issues become significant and methods for documenting these are especially important [97]. Formal methods provide a precise and unambiguous way of recording expected delivered system functionality and can therefore be used as a powerful documentation aid. The normal expectation would be that the system documentation contains both the requirements and the system specification in a ....

PARNAS, D.L., and MADEY, J.: `Functional documentation for computer systems engineering '. Version 2, CRL Report No. 237, TRIO, Communications Research Laboratory, Faculty of Engineering, McMaster University, Hamilton, Ontario, Canada L8S 4K1, September 1991

....system is its documentation, particularly if subsequent changes are made. Formalizing the documentation leads to less ambiguity and thus less likelihood of errors. In the case of safety critical systems, timing issues become significant and methods for documenting these are especially important [115]. Formal methods provide a precise and unambiguous way of recording expected delivered system functionality and can therefore be used as a powerful documentation aid. The normal expectation would be that the system documentation contains both the requirements and the system specification in a ....

PARNAS, D.L., and MADEY, J.: `Functional documentation for computer systems engineering '. Version 2, CRL Report No. 237, TRIO, Communications Research Laboratory, Faculty of Engineering, McMaster University, Hamilton, Ontario, Canada L8S 4K1, September 1991

....is called a concrete value of T if it represents a value of T . Values of T are called abstract values. To prove the implementation satisfies the specification of T , one needs a link between T 0 and T . This is usually characterized by a so called abstraction function 3 [Hoa72, Sha81, LG86, PM90, Par90] 4 , absF T : T 0 Gamma T which maps concrete values to abstract values. Two methods, descriptive or constructive, could be used to define abstraction functions. In the descriptive method, usually a mathematical theory is chosen to be the model of T . absF T is declaratively ....

....1 are functions of type Nat. Hoare[Hoa72] and Shaw[Sha81] use the descriptive method to define abstraction functions; Partsch[Par90] uses the constructive method; and Liskov and Guttag[LG86] mainly use the descriptive method, though they touch on the constructive method once; Parnas and Madey[PM90] do not mention how to describe abstraction functions. 3 It is called representation function in references[Hoa72, Sha81] 4 Details of how to prove the correctness of ADT implementations through abstraction functions can be found in references[Hoa72, Sha81, LG86, Par90] 5 In conventional ....

[Article contains additional citation context not shown here]

D.L. Parnas and J. Madey. Functional documentation for computer systems engineering. Technical Report 90-287, Department of Computing and Information, and TRIO, Queen's University, Kingston, Ontario, September 1990.

....can also be very expensive because they rely on large group program reading sessions. III Software Inspection Based on Program Function Tables A more effective form of inspection has been developed by combining the ideas of Fagan with those of H.D. Mills [17] and Parnas, Madey and Iglewski [21, 25]. This method was developed for application in the inspection of safety critical control programs [23] Mills showed how conventional (i.e. classical) mathematics could be used to prepare precise summaries of a program s behaviour [17] Parnas, Madey and Iglewski showed how the readability of the ....

Parnas, D.L., Madey, J., "Functional Documentation for Computer Systems Engineering". In Science of Computer Programming, (Elsevier) vol. 25, No1, October 1995, pp 41-61

.... document is a mathematical model, including a set of mathematical relations that may be described in tabular form [6, 16, 20] Assuming that each document must contain a representation of one or more binary relations, and that each relation describes a set of ordered pairs , Parnas and Madey [17], defined the contents of a number of standard documents, including requirements documents. One of these documents is considered to be complete if it contains enough information to determine whether or not any ordered pair should be included in the relation. This approach automatically answers ....

....model that better reflects the reality of forecasting tools and makes it easier to apply relational methods in practice. 3.1 The environmental variables The choice of quantities describing the system under consideration is a critical step in the development of any mathematical model. As in [17], the requirements analysis begins with identification of the environmental quantities. The environmental quantities are divided into two sets: monitored quantities, MQ, i.e. those that the user wants the computer system to observe and measure, and controlled quantities, CQ, whose values the ....

[Article contains additional citation context not shown here]

Parnas, D.L., Madey, J., "Functional Documentation for Computer Systems Engineering", in Science and Computer Programming, (Elsevier) 25 (1), October 1995, pp. 41-61

....expressions, called tables, have proven to be useful for documenting digital systems. This paper describes 10 classes of tables, giving their syntax and semantics. Several abbreviations that can be useful in tables are introduced. Simple examples are provided. 1 Introduction In earlier papers, [1,2], we have shown how the documentation required for the professional construction and use of computing systems can consist of descriptions of a set of mathematical relations. Those papers discuss the documents very abstractly; the contents of the documents are specified without restricting the ....

Parnas, D.L., Madey J., "Functional Documentation for Computer Systems Engineering (Version 2)", CRL Report 237, McMaster University, Hamilton Canada, TRIO (Telecommunications Research Institute of Ontario), September 1991, 14 pgs.

....expressions, called tables, have proven to be useful for documenting digital systems. This paper describes 10 classes of tables, giving their syntax and semantics. Several abbreviations that can be useful in tables are introduced. Simple examples are provided. 1 Introduction In earlier papers, [1,2], we have shown how the documentation required for the professional construction and use of computing systems can consist of descriptions of a set of mathematical relations. Those papers discuss the documents very abstractly; the contents of the documents are specified without restricting the ....

Parnas, D.L., Madey, J., "Functional Documentation for Computer Systems Engineering", Technical Report 90-287, Queen's University, C&IS, Telecommunications Research Institute of Ontario (TRIO), Kingston, Ontario, Canada, September 1990, 14 pp.

....documentation for computer systems. However, such documents are highly detailed and oversights and other errors are quite common. To detect the early errors in a document, one must attempt to prove certain simple theorems. This paper gives some examples of such theorems. 1 Introduction In [4], we have shown how the contents of key computer systems documents can be defined in terms of mathematical functions and relations. We also reminded our readers that (1) functions and relations can be viewed as sets of ordered pairs, 2) sets can be characterised by predicates and described by ....

D.L. Parnas, J. Madey, "Functional Documentation for Computer Systems Engineering (Version 2)", CRL Report 237, McMaster University, Hamilton Canada, TRIO (Telecommunications Research Institute of Ontario), September 1991,14 pgs.

....A black box description of the behaviour of these chips, the Chip Behaviour Specification, would serve to define the interface for both the chip designers and those who integrate the chip into the rest of the system (cf Section 4. 11) Earlier discussions of these documents were contained in [33, 34, 35]. Accepted for publication in Science of Computer Programming (Elesevier) 1995. 6 18 4.2 How can we document system requirements A critical step in documenting the requirements of a computer system is the identification of the environmental quantities to be measured or controlled and the ....

D.L. Parnas and J. Madey, "Functional Documentation for Computer Systems Engineering. (Version

....A black box description of the behaviour of these chips, the Chip Behaviour Specification, would serve to define the interface for both the chip designers and those who integrate the chip into the rest of the system (cf Section 4. 11) Earlier discussions of these documents were contained in [33, 34, 35]. Accepted for publication in Science of Computer Programming (Elesevier) 1995. 6 18 4.2 How can we document system requirements A critical step in documenting the requirements of a computer system is the identification of the environmental quantities to be measured or controlled and the ....

D.L. Parnas and J. Madey, "Functional Documentation for Computer Systems Engineering", Technical Report 90-287, Queen's University, C&IS, Telecommunications Research Institute of Ontario (TRIO), Kingston, Ontario, Canada, September 1990, 14 pp.

....that are moni tored and or controlled by the system, # it uses terminology and notation that is familiar to, or easily understood by, the domain experts, and # it is presented in a manner that permits indepen dent review of small parts of the document. 5] As discussed in [4] [9], 12] and [13] a (relational) system requirements document describes a relation, REQ, on vector functions of time representing the environmental quantities that are monitored and controlled by the system. I intend to explore techniques for using reviewable forms of such docu mentation (i.e. ....

D. L. Parnas and J. Madey, "Functional Documenta- tion for Computer Systems Engineering", Science of Computer Programming (Elsevier), vol. 25, no. 1 (Oc- tober 1995), pp. 41--61.

....of the system. In addition, boolean) variables R1 val and R2 val record current values of these inputs. We expect events atT(x) and atF(x) where x denotes either Request1 or Request2, to occur on channel Interface. We posit that the event table specifying the monitor describes relation REQ [PM91], described by the following MeLa program: process class Monitor(chan in) f int state = Empty ; loop f : state=Empty, in atT (Request1 ) state : InUse1 ; state=Empty, in atT (Request2 ) state : InUse2 ; state=InUse1, in atF (Request1 ) R2 val = 0, state : Empty ; state=InUse1, ....

D. L. Parnas and J. Madey. Functional Documentation for Computer Systems Engineering. T.R. 237, Communications Research Laboratory, McMaster University, Hamilton, Ontario, Canada September 1991.

....hear developers arguing about whether or not a certain fact should have been included in some document. Often information is included in several documents or not found in any. The first step in improving the quality of documentation is to agree on definitions of the contents of key documents. In [8] Parnas and Madey proposed that definitions of the contents of a number of common documents can be given by stating that each document must contain a representation of one or more binary relations (sets of ordered pairs) If the document contains enough information to determine whether or not any ....

D.L. Parnas , J. Madey, "Functional Documentation for Computer Systems Engineering", Science of Computer Programming (Elsevier) 25 (1995), pp 41-61.

....program is formally documented it is possible to use the specification to determine the success or failure of a test execution, as in [1] for example. This thesis discusses the development of a prototype tool that automatically generates a test oracle from formal program documentation. In [25] [27] and [28] Parnas et al. advocate the use of a relational model for documenting the intended behaviour of programs. In this method, tabular expressions are used to improve readability so that formal documentation can replace conventional documentation. Relations are described by giving their ....

....i.e. it describes the intended behaviour of a program in terms of its effect on the actual data structure. This is distinct from module interface documentation which describes the externally observable behaviour of a module without reference to the data structure used in their implementation (see [27], 28] and [38] A module is a group of programs which are designed and implemented as a single work assignment. Typically they implement an abstract data type or encapsulate a design decision, e.g. algorithm or external device interface. This chapter describes the program documentation method ....

Parnas, D.L. & Madey, J., "Functional Documentation for Computer Systems Engineering (Version 2)", CRL Report No. 237, Telecommunications Research Institute of Ontario (TRIO), September 1991, 14 pgs.

....the table format are more dramatic. More extensive discussions of these tables can be found in [4,7] Tables of this sort were used in the inspection of safety critical software for the Darlington Nuclear Power Generation Station as described in [2, 6, 1] The theory behind their use is given in [3, 5]. They are useful whenever a very careful and disciplined inspection of software is required. 7 Conclusions Classically educated engineers know that they must apply science and mathematics in their work. Unfortunately, most programmers have not received an appropriate professional education and ....

Parnas, D.L., Madey, J., "Functional Documentation for Computer Systems Engineering" published in Science of Computer Programming (Elsevier) vol. 25, number 1, October 1995, pp 41-61.

No context found.

D. L. Parnas and J. Madey. Functional documentation for computer systems engineering, vol. 2. Technical Report Technical Report CRL 237, McMaster University, Hamilton, Ontario, Sept 1991.

No context found.

Parnas, D.L., Madey, J., \Functional Documentation for Computer Systems Engineering" in Science of Computer Programming (Elsevier) vol.25, number 1, October 1995.

No context found.

D. L. Parnas, J. Madey. Functional Documentation for Computer Systems Engineering. T.R. 237, Communications Research Laboratory, McMaster University, Hamilton, Ontario, Canada September 1991.

No context found.

D. L. Parnas and J. Madey, "Functional Documentation for Computer Systems Engineering (version 2)," McMaster University, Hamilton, Ontario, Canada, CRL-237, Sept. 1991.

No context found.

D. L. Parnas and J. Madey. Functional Documentation for Computer Systems Engineering. T.R. 237, Communications Research Laboratory, McMaster University, Hamilton, Ontario, Canada September 1991.

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