M. Frappier, A. Mili, and J. Desharnais. Program construction by parts. In B. Moller, editor, Mathematics of Program Construction: Third International Conference, volume 947 of Lecture Notes in Computer Science, pages 257--281. Springer-Verlag, 1995.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....a state should result that satisfies the corresponding postcondition. Such an operation unification is also described by Ainsworth et al. 1] there called union, although they do not mention that the union may not exist. In the more abstract setting of binary relations used by Frappier et al. [25] the same construct appears as the demonic join. Definition 27 (Operation unification) The candidate least unification of operation schemas AdOp 1 and AdOp 2 , both operating on the same state and having the same collection of inputs and outputs Decls, is given by 8 UnOp Decls ; DeltaD pre ....

....as the basis of correspondence relations. This yields all the advantages of view composition and data refinement, often without introducing their disadvantages. A formal justification of this can be found in [10] 33 7. 3 Demonic join and feature interaction Desharnais, Frappier, Mili and others [11, 25, 26] study a calculus (lattice) of binary relations with a refinement relation which has great similarities to operation refinement in Z. In their framework, our operation unification appears as demonic join , which is only defined if a consistency condition (our operation consistency) holds. They ....

[Article contains additional citation context not shown here]

M. Frappier, A. Mili, and J. Desharnais. Program construction by parts. In B. Moller, editor, Mathematics of Program Construction: Third International Conference, volume 947 of Lecture Notes in Computer Science, pages 257--281. Springer-Verlag, 1995.

....under the form f(t; t 0 ) j q(t; t 0 )g, where q is a predicate. In [13] it is shown that if unrestricted predicates are allowed, then the de nedness condition is undecidable. The readers can nd more details on the use of the demonic meet operator for merging separate description 2 in [18]. 2.2 Scenarios The following part of DECwindows Tutorial [16] on the topic of Using the Mouse is an example of informal scenario. Using the Mouse The mouse is a hand held pointing device that is attached to your workstation. The mouse has three buttons. The left most button is called MB1, the ....

....has three buttons. The left most button is called MB1, the middle button is called MB2, and the right most button is called MB3. To move the pointer, move your mouse. The pointer moves in the same direction as the mouse. You also choose commands from menus by pressing the mouse buttons. 2 In [18] authors use the term speci cation. According to the distinction made in [35] between the terms speci cation and description we nd that the term description is more suitable June 10, 1999 CRL Report No. 374 Sequential Scenarios Veri cation and Integration using Tabular Expressions 6 Clicking ....

M. Frappier, A. Mili, and J. Desharnais. Program construction by parts. Sci. Comput. Programming, 26(13):237254, May 1996.

....( amalgamation ) of Z viewpoints, using an extended notion of refinement ( co refinement ) Daniel Jackson s work on specification by views, also in Z, uses a syntactical notion of view composition, which does not always coincide with our, more semantical, one. The approach by Frappier et al. [15] is similar to ours in the more abstract setting of homogeneous binary relations. Most of the cited papers contain small to medium examples of consistency checks within one formal method. There are also a large number of viewpoint specification research groups in the area of requirements ....

M. Frappier, A. Mili, and J. Desharnais. Program construction by parts. In B. Moller, editor, Mathematics of Program Construction: Third International Conference, volume 947 of Lecture Notes in Computer Science, pages 257--281. Springer-Verlag, 1995.

....there is also a transition from s to every post state. This healthiness condition would lead to a calculus quite different from Dijkstra s [8] This model is explored in [10] and is the traditional model for relational program semantics. Other applications of a join operator can be traced from [9], which uses yet another relational model. For example, the miraculous statement w : true; false] is not modeled. 7.4. Program development The join of two specification statements w : P ; Q ] and w : P 0 ; Q 0 ] results in the weakest (conjunctive) specification that is a refinement of both ....

....Methods for integrating two different implementations of programs have been proposed before (see, for instance [11] The join operation computed here is the basis for reasoning about the correctness of such a method. The join is also the basis for the paradigm of program construction by parts [9]. The paradigm proposes that a specification S be written as the join of specifications S 0 and S 00 , i.e. S = S 0 q S 00 . The specifications S 0 and S 00 capture partial requirements of specification S . Therefore, these component specifications are simpler, leading to a ....

[Article contains additional citation context not shown here]

M. Frappier, A. Mili, and J. Desharnais. Program Construction by Parts. In Mathematics of Program Construction: Third International Conference. Lecture Notes in Computer Science 947, pp. 257--281. Springer-Verlag, 1995.

.... like most of the other approaches, and can be grafted easily to the well established specification language Z [9, 26] Also, the end product of scenario integration, the system specification, is given as a relation; this specification can be refined using independently developed methods [2, 7, 8, 10, 19, 20, 21]. Our formal description is coupled with a diagram based, transition system like, presentation of scenarios, which is better suited to communication between clients and specifiers [11] In Section 2, we present the relational foundations of the approach. Section 3 presents the definition of ....

....Checkout from the corresponding initial states) and exploring all paths to S 6 , it is clear that the assertion r 2 Readers holds in S 6 . This assertion could be explicitly added to S 6 (and to Checkout s ) resulting in a relation with a smaller domain, thus leaving more freedom for refinement [2, 8, 10]. Thus, we have two equivalent views 2 of the Checkout scenario: the transition system view, better suited for communications between the client and the specifier, and the relation view, better suited for formal manipulations. Note that the graph in Figure 1 is bipartite: a transition from an ....

[Article contains additional citation context not shown here]

M. Frappier, A. Mili, and J. Desharnais. Program construction by parts. Sci. Comput. Programming, 26(1--3):237--254, May 1996.

.... like most of the other approaches, and can be grafted easily to the well established specification language Z [9, 26] Also, the end product of scenario integration, the system specification, is given as a relation; this specification can be refined using independently developed methods [2, 7, 8, 10, 19, 20, 21]. Our formal description is coupled with a diagram based, transition system like, presentation of scenarios, which is better suited to communication between clients and specifiers [11] In Section 2, we present the relational foundations of the approach. Section 3 presents the definition of ....

....Checkout from the corresponding initial states) and exploring all paths to S 6 , it is clear that the assertion r 2 Readers holds in S 6 . This assertion could be explicitly added to S 6 (and to Checkout s ) resulting in a relation with a smaller domain, thus leaving more freedom for refinement [2, 8, 10]. Thus, we have two equivalent views 2 of the Checkout scenario: the transition system view, better suited for communications between the client and the specifier, and the relation view, better suited for formal manipulations. Note that the graph in Figure 1 is bipartite: a transition from an ....

[Article contains additional citation context not shown here]

M. Frappier, A. Mili, and J. Desharnais. Program construction by parts. Sci. Comput. Programming, 26(1--3):237--254, May 1996.

....from the corresponding initial states) and exploring all paths to S 6 , it is clear that the assertion r 2 Readers holds in S 6 . This assertion could be explicitly added to S 6 (and to Checkout s ) resulting in a relation with a smaller domain, thus leaving more freedom for refinement [5] 12] [14]. Thus, we have two equivalent views 2 of the Checkout scenario: the transition system view, better suited for communications between the client and the specifier, and the relation view, better suited for formal manipulations. Note that the graph in Fig. 1 is bipartite: a transition from an E ....

....s and R s (by definition of u) If there is no such result, then the scenarios are contradictory and cannot be integrated. November 12, 1997 DRAFT 16 ieee transactions on software engineering More details on the use of the demonic meet operator for merging separate specifications can be found in [14]. Note that the operation Delta is commutative and associative, by definition of [ and u, and by virtue of the definition of integrated scenario. We now present the Limit reached scenario. Its informal description follows. The reader comes in. The system is in the initial state of the reader serv ....

[Article contains additional citation context not shown here]

M. Frappier, A. Mili, and J. Desharnais, "Program Construction by Parts," Sci. Comput. Programming, vol. 26, no. 1--3, pp. 237--254, May 1996.

....basis for the storage and retrieval of software components in a reuse database. Our approach is based on the formal representation of specifications, whereby candidate programs are matched against the user s specification by means of a first order theorem, which we must prove or disprove. ffl In [ 5 ] , we show how this structure can be used as a basis for program construction by parts, whereby, given a complex specification structured as an aggregate of simpler specifications, we can tackle each subspecification in turn then combine their solutions to get a solution to the overall problem. In ....

....2 ; t R prerestriction: guarding of R by condition t; t 5 preserve: condition t holds before and after execution; R 3 closure: undetermined number of iterations over R. Providing a formal definition of these operators is beyond the scope of this paper. The interested reader is referred to [ 5 ] . All operators are executable (i.e. can be automatically compiled into executable machine level code) except the lub (which cannot, with current compiler translation technology, be compiled into executable code) The main purpose of the lub operator is to structure specifications as aggregates ....

[Article contains additional citation context not shown here]

Frappier, M. Program Construction by Parts. in Mathematics of program construction : third international conference. B. Moller, ed, Kloster Irsee, July 1995, Springer-Verlag, 1995.

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