D. L. Parnas and J. Madey, "Functional documents for computer systems," Science of Computer Programming, vol. 25, pp. 41--61, 1995.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....the SDV process is to verify, using mathematical techniques, that the behaviour of every output defined in the SDD, is in compliance with the requirements for the behaviour of that output as specified in the SRS. The process employed in [6] is based upon a variation of the four variable model of [13] that verifies the functional equivalence of the SRS and SDD by comparing their respective one step transition functions. The resulting proof obligation: REQ = OUT IN (1) is illustrated by the solid lines in the commutative diagram of Figure 1. Here REQ represents the SRS state transition ....

....output variables represented by the statespace O. The mapping IN relates the specification s monitored variables to the implementation s input variables while the mapping OUT relates the implementation s output variables to the specification s controlled variables. In the 4 variable model of [13], each of the 4 variable state spaces M, I, O, and C is a set functions of a single real valued argument t (time) that return a vector of values one value for each of the quantities or variables associated with a particular dimension of the statespace at time t. Thus the relations ....

D. L. Parnas and J. Madey, "Functional documents for computer systems," Science of Computer Programming, vol. 25, pp. 41--61, Oct. 1995.

.... the goal PumpSwitchOnWhenHighWaterDetected that was declared to be subgoal of the goal PumpOnWhenHighWater; it might be specified as follows: This goal might be assigned to the PumpController agent provided the latter has sufficient monitoring and control capabilities to realize the goal [39, 16, 33]; the agent must be able to monitor the quantity denoted by c.HighWaterFlag and to control the quantity denoted by c.PumpSwitch . Such monitoring and control links define the agent s interface in the agent model: Agent PumpController Monitors PumpController.HighWaterFlag, Controls ....

D.L. Parnas and J. Madey, "Functional Documents for Computer Systems", Science of Computer Programming, Vol. 25, 1995, pp. 41-61.

....operations. Each model has a separate semantics, and is related to the others through intermodel consistency rules [Dar93, Let01] Our focus in this section is on the semantic foundation for the agent model. Our agent framework extends Feather s notion of agent [Fea87] Parnas 4 variable model [Par95] and Jackson s principle of shared phenomena [Jac95] An agent is characterized by the following items: an interface which declares two disjoint sets of state variables: a set of variables that the agent monitors and a set of variables that the agent controls; a transition system composed ....

....at most one agent. If a variable needs to be controlled by more than one agent, one can split the variable into several variables, each controlled by a single agent. A single variable can be monitored by several agents. The agent interface component in our framework extends the 4 variable model [Par95] to a 2N variable model; instead of one single software agent with one pair of input output devices we consider N agents; some of them are software agents, others are sensors or actuators, others are humans, etc. In the KAOS language, agent interfaces can be represented by context diagrams in the ....

[Article contains additional citation context not shown here]

D.L. Parnas and J. Madey, "Functional Documents for Computer Systems", Science of Computer Programming, Vol. 25, 1995, 41-61.

....event is a sufficient condition for the corresponding transition to take place (unlike a precondition, it captures an obligation) necessary preconditions may also be specified to guard the transition. Languages such as Statecharts [Har87] PROMELA [Hol91] STeP SPL [Man92] RSML [Lev94] or SCR [Par95, Heit96] rely on this paradigm. Functional specification The principle here is to specify a system as a structured collection of mathematical functions. Two approaches may be distinguished. Algebraic specification. The functions are grouped by object types that appear in their domain or codomain, ....

....and check them. This criterion depends on the previous ones (notably, the closeness between the specification and its corresponding natural language formulation) and on the external format the specification may take. It explains the popularity of techniques that support tabular formats [Hen80, Lev94, Par95, Cro95, Heit96] and diagrammatic notations [Har87, Lev94] Powerful and efficient analysis. The effectiveness of a formal specification technique depends on the degree of satis faction of the various objectives mentioned in Section 1. In particular, there is no much sense writing formal specifications without ....

D.L. Parnas and J. Madey, "Functional Documents for Computer Systems", Science of Computer Programming, Vol. 25, 1995, 41-61.

.... therefore begun on inferring goal requirement specifications from scenarios in order to support more abstract, goal level reasoning [Lam98c] Back to groundwork In parallel with all the work outlined above, there has been some more fundamental work on clarifying the real nature of requirements [Jac95, Par95, Zav97]. This was motivated by a certain level of confusion and amalgam in the literature on requirements and software specifications. At about the same time, Jackson and Parnas independently made a first important distinction between domain properties (called indicative in [Jac95] and NAT in [Par95] ....

....Zav97] This was motivated by a certain level of confusion and amalgam in the literature on requirements and software specifications. At about the same time, Jackson and Parnas independently made a first important distinction between domain properties (called indicative in [Jac95] and NAT in [Par95]) and requirements (called optative in [Jac95] and REQ in [Par95] Such distinction is essential as physical laws, organizational policies, regulations, or definitions of objects or operations in the environment are by no means requirements. Surprisingly, the vast majority of specification ....

[Article contains additional citation context not shown here]

D.L. Parnas and J. Madey, "Functional Documents for Computer Systems", Science of Computer Programming, Vol. 25, 1995, 41-61.

....assignment of an agent to the operations that operationalize the terminal goal is captured in corresponding performs links. A domain property is a property about objects or operations in the environment which holds independently of the software to be. Domain properties include physical laws [Par95], regulations, constraints imposed by environmental agents [Lev95] in short, indicative statements of domain knowledge [Jac93, Zav97b] In KAOS, domain properties are captured by domain invariants attached to objects and by domain pre postconditions attached to operations. A scenario is a ....

D.L. Parnas and J. Madey, "Functional Documents for Computer Systems", Science of Computer Programming, Vol. 25, 1995, 41-61.

....the maintenance of software requirements for telephone switching systems. In previous work [Bre99c, Bre98b] see also [Bre99a, Bre99b, Bre98a] we have investi1 gated how we should structure software requirements with regard to future modifications using the Functional Documentation approach [PaMa95, vSPM93, vS92] to requirements specification, also known as Parnas tables . We presented a way to compose partial requirements specifications written in Functional Documentation. While this previous work presents an earlier version of our method, we were only able to sketch the details of the ....

....we apply it with CSP OZ. 5. 1 Modularizing Telephone Switching Requirements In previous work [Bre99c, Bre98b] see also [Bre99a, Bre99b, Bre98a] we have investigated how we should structure software requirements with regard to future modifications using the Functional Documentation approach [PaMa95, vSPM93, vS92] to requirements specification, also known as Parnas tables . One aspect of the Functional Documentation approach that facilitates maintenance is that it takes great care to avoid duplication of information in the documents, by factoring out common parts. Such duplication would ....

Parnas, D. L. and Madey, J. Functional documents for computer systems. Sci. Comput. Programming 25(1), 41--61 (Oct. 1995).

.... a requirements specification provides a black box description of the required behavior as two relations, REQ and NAT, from monitored variables, representing environmental quantities that the system monitors, to controlled variables, representing environmental quantities that the system controls [15]. NAT describes the natural constraints on the system behavior, such as constraints imposed by physical laws and the system environment. REQ describes the relation the system must maintain between the environmental quantities represented by the monitored and controlled variables. In SCR, these ....

D. L. Parnas and J. Madey. Functional documents for computer systems. Science of Computer Programming, 25(1), pp 41--62, Oct 1995.

....property must be classified as descriptive or prescriptive. A descriptive property is a property present in the subject domain regardless of the presence of the system under development. As far as the system under development is concerned, these are laws of nature. In fact, using the phrase of Parnas Madey (1995), descriptive properties of the subject domain are properties of nature or previously installed equipment. A prescriptive property is a property that someone must ensure holds in the subject domain. It describes the desired state of the subject domain. There is one property of the MSS subject ....

Parnas, D. & Madey, J. (1995), `Functional documents for computer systems', Science of Computer programming 25, 41--61.

....standard for the Intelligent Network (IN) Second, we argue that the requirements for the Plain Old Telephone Service (POTS) comprehend several different concerns, and that separate requirement concerns should be separated in the specification. We employ the Functional Documentation approach [PaMa95, vSPM93, vS92a] and investigate how it can be extended to group requirement concerns, and to cover not only one but a sequence of development contracts. Our approach is related to the standard refinement approach for software development. But when we refine a specification to introduce new ....

....any local state components, e.g. Personal Identification Number (PIN) lists, if these entities do not exist before the system is constructed. The required behaviour of a system to construct should be stated only in terms of the history of its environment s behaviour. Functional Documentation [PaMa95, vSPM93, vS92b] is a specification technique that allows formal specification of the requirements of a system in terms of environmental entities only. Furthermore it distinguishes them clearly into controlled variables and monitored variables, denoted by two vectors of time functions e c t ....

[Article contains additional citation context not shown here]

Parnas, D. L. and Madey, J. Functional documents for computer systems. Sci. Comput. Programming 25(1), 41--61 (Oct. 1995).

....work. 2 Background 2. 1 SCR Requirements Specifications In SCR, the required system behavior is described by REQ, the required relation between monitored variables, environmental quantities that the system monitors, and controlled variables, environmental quantities that the system controls [PM95]. To specify this relation concisely, the SCR approach uses four constructs modes, terms, conditions, and events. A mode class is a variable whose values are system modes (or simply modes) while a term is any function of monitored variables, modes, or other terms. A condition Old Mode Event ....

D. L. Parnas and J. Madey. "Functional documents for computer systems". Science of Computer Programming, 25(1), pp 41--62, Oct 1995.

....the first component machines. 2 Notation and Prerequisites This section can be skipped to be consulted should the necessity arise. It will help if the reader is familiar with the semantics of Abstract State Machines, defined in [Gurevich 95] We could have used also Parnas tabular notation [Parnas, Madey 95] for which a simple but rigorous semantics can be given in terms of ASMs (see [Borger 96] However what follows can be understood correctly also by reading our ASM rules as pseudo code over abstract data types. We therefore point here only to some of the basic ASM features. A distributed ASM is ....

....functions which are directly updatable by and only by the environment, i.e. which are updatable but do not appear as leftmost function in updates of M . Monitored and controlled functions are generalizations of the controlled and monitored variables in the Parnas Madey Four Variable Model (see [Parnas, Madey 95] Interaction functions are dynamic functions which are directly updatable by rules of M and by the environment. They are particularly useful for decomposing specifications of complex systems into simpler components because they allow the designer to separate the dynamic aspects he wants to ....

Parnas, D.L., Madey, J.: "Functional documents for computer systems "; Science of Computer Programming 25 (1995), 41-62.

....Maintain [LimitedAdvance] amount c. Limit The distinction between domain conditions and requirements is very important to the method presented in this paper; it is similar to the distinction between indicative and optative properties in [36] and between NAT and REQ in Parnas 4 variable model [57]. 2.2 The elaboration method Figure 1 outlines the major steps that may be followed to systematically elaborate KAOS specifications from high level goals. Section 3 will discuss how scenario based elicitation and validation enter into this process model. Goal elaboration: elaborate the goal ....

D.L. Parnas and J. Madey, "Functional Documents for Computer Systems", Science of Computer Programming, Vol. 25, 1995, 41-61.

....observable and hides details of its internal structure. The method was first formulated in [1] and since then has undergone many modifications [3, 4, 7, 9, 11, 14, 15] In recent years, there has been an increased interest in TAM, especially within the framework of the functional approach [13]. Software tools supporting practical usage of TAM are under development (e.g. 6, 15] the method is being tested on different applications (e.g. 2, 9] and its foundations are being studied (e.g. 8, 9, 15] Let us now justify our decision to study non deterministic multi object version of ....

Parnas, D.L., Madey, J., "Functional Documents for Computer Systems", Science of Computer Programming, to appear in 1995.

.... Cost Reduction project (A 7E) at the Naval Research Laboratory [3, 4, 7, 8, 19] recent involvement of Parnas in investigating of the shutdown software at the Ontario Hydro s Darlington Nuclear Power Generating Station [23, 27] and by our cooperation with Parnas, primarily in years 1990 91 [5, 13, 24, 25]. 1.1 The A 7E experience The purpose of the A 7E project was to redesign and rebuild the operational flight program for the Navy s A 7 aircraft in order to evaluate the applicability of new software engineering techniques for embedded real time systems. It gave a chance to practically verify a ....

.... confirmed most of the A 7E observations, inspired our research described in the following sections, and in particular led to the development of the Display Method (cf. Section 5) 2 Fun paradigm The project we are currently involved in (called the Fun Project, from the term functional approach [25]) is based on the premise that professional documentation for the development of computer systems containing complex software can consist of representations of certain mathematical functions and relations, often presented in a tabular notation. In the following sections some basic ideas about the ....

[Article contains additional citation context not shown here]

Parnas, D.L., Madey, J., "Functional Documents for Computer Systems", Science of Computer Programming, vol. 25, no. 1, Oct. 1995, pp. 41-61.

No context found.

D. L. Parnas and J. Madey, "Functional documents for computer systems," Science of Computer Programming, vol. 25, pp. 41--61, 1995.

No context found.

D. L. Parnas and J. Madey. Functional documents for computer systems. Sci. of Comput. Program., 25:41--62, 1995.

No context found.

Parnas, D. L. and Madey, J. (1995). Functional documents for computer systems. Science of Computer Programming, 25:41--61.

No context found.

Parnas DL, Madey J. Functional documents for computer systems. Sci Comput program 1995;25:41--61

No context found.

Parnas, D.L., Madey, J.: Functional documents for computer systems. Science of Computer Programming 25 (1995) 41-61

No context found.

Parnas, D.L., Madey, J.: Functional documents for computer systems. Science of Computer Programming 25 (1995) 41-61

No context found.

D.L. Parnas and J. Madey, "Functional Documents for Computer Systems", Science of Computer Programming, Vol. 25, 1995, pp. 41-61.

No context found.

D.L. Parnas and J. Madey, "Functional Documents for Computer Systems", Science of Computer Programming, Vol. 25, 1995, pp. 4161.

No context found.

Parnas, D.L., Madey, J.: Functional documents for computer systems. Science of Computer Programming 25 (1995) 41--61

No context found.

D.L. Parnas and J. Madey, "functional Documents for Computer Systems", Science of Computer Programming, Vol. 25, 1995, 41-61.

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