Carroll Morgan. Programming from Specifications (2nd ed.). Prentice-Hall, Inc., 1994.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....Semantics It was decided to develop semantics that would support proofs at the program text level, with use being made of so called laws of programming or sourcelanguage transformation rules. For the C like language we explored the use of Hoare triples [HJ98] and weakest precondition [Mor94] and finally settled on the Hoare triples as a proof methodology. For the functional languages, we simply built a collection of re write rules neccessary to perform the proofs, rather than giving a complete set. In all three cases, we integrated the I O model with the semantics being developed. ....

Carroll Morgan. Programming from Specifications. Series in Computer Science. Prentice-Hall International, London, 2nd. edition, 1994.

....# = #f Proposition 19 Let s be positively conjunctive transformer. Then s # is an idempotent may e#ect. Proof. Clearly, s # is a may e#ect because it is a demonic choice with skip. For idempotence, show s # s ; s # and then use induction and lattice properties. 17 7 Related Work [1] and [18] contain a systematic introduction to the refinement calculus. 5, 19] present applications of the refinement calculus to program derivation. To the best of our knowledge, we are the first to introduce the notion of in place refinement into the refinement calculus. In this paper we have shown ....

Carroll Morgan. Programming from Specifications (2nd ed.). Prentice-Hall, Inc., 1994. 7

....Universidade Federal de Pernambuco e mail: fphmb,acasg cin.ufpe.br 1. Introduction The laws of imperative programming are well established and have been useful both for assisting software development and for providing precise axiomatic programming language semantic definitions [Het al..87, Mor94] In fact, besides being used as guidelines to informal programming practices, programming laws establish a sound basis for formal and rigorous software development methods. Moreover, axiomatic semantic definitions are an important tool for the design of correct compilers and code optimizers ....

....rool is an object oriented language based on Java, but with a copy semantics rather than a reference semantics. It has been specially designed to allow reasoning about object oriented programs and specifications, hence it mixes both kinds of constructs in the style of Morgan s refinement calculus [Mor94] A program in rool consists of a main command and a set of class declarations. Classes are declared as in the following example: class Client extends Object meth setStreet b = val s : string ffl add :setStreet(s) end; new b = add : new Address end; where subclassing and single inheritance ....

[Article contains additional citation context not shown here]

Carroll Morgan. Programming from Specifications. Prentice Hall, second edition, 1994.

....languages permit precise documentation, but they also provide the grounds for the formal analysis and transformation of specifications. Formal arguments are most often conducted within a proof system (rather than by direct application of a model theory) For example, in the Refinement Calculus [15], one can make use of refinement laws (which can be used as proof rules) to establish the correctness of an implementation with respect to its specification. As a consequence of the identified referential opacity, we note that laws, such as the strengthen postcondition law, do not hold for LCL ....

Carroll Morgan. Programming from Specifications. Computer Science Series. Prentice Hall International, 1990.

....to design a complete fault tolerant system and only then attempt verification [5, 12] It is more promising to carry out design where verification is done along the way. This correctness by construction is well studied for building systems from specification (no faults taken into account) e.g. [14]. Methods to overcome to some extent the effects of state explosion are also known. In contrast, building fault tolerant systems from specification ( faulttolerance by construction ) has so far not received much attention. This may be partly due to indirect verification of fault tolerance which ....

Carroll Morgan. Programming from Specifications. Prentice Hall, 1990.

....ofrecursi[ i the language necessary i troduces also the possiB6z[ y of non termizz#S[ oftacti programs, forwhi h we define theatomi tacti ab or . Thi i s di8S66 t from mere fai#fi6 of atacti to apply, andi s typizBfi[ not somethi[ one would ever wri i atacti program, but (followil Morgan [Mor94] we findi conveni# t to be able to reason about i[ We can extend ouri nterpretati to cover recursi[ as follows. We define a type of vari #S names: type Var = String andi ntroduce three new constructors for termsi n thetacti language: data Tactic = Mu Var Tactic Var Var ....

Carroll Morgan. Programming from Specifications. Series in Computer Science. Prentice-Hall International, second edition, 1994.

....perform the same overall changes to the local state, and return the same value. If the specification is nondeterministic, then the call sequence, local state transformation, and return value of the implementation must correspond to one choice in the specification. The refinement calculus [3, 6, 40] provides a formal base, but not yet any rules, to prove this conformance. In this section we first clear the field by discussing a number of critical issues surrounding greybox refinement and then formalize the latter. We end the section with two theorems on the refinement of systems with ....

....properties (1) 3) but not the crucial properties (4) and (5) hold. Additional minor differences include them not handling additional methods and equaling non termination with abortion. Refinement calculi. As exemplified by our own proposal, the refinement calculi of Back [3, 6] and Morgan [40] with their abstract statement notation can be used to specify external calls. However, their refinement rules only take the state transformations, but not the calls, into account. The semantics of method calls is defined by reduction, which is inappropriate for the problem at hand. Contracts of ....

Carroll Morgan. Programming from Specifications. Prentice Hall, second edition, 1994.

....ConForm, and this resulted in some redesign of the back end. 4 OOT is an object oriented programming language similar to Modula3 and C [Hol93, MHG94] 5 Metamorphic programming is similar to the idea of refinement reification familiar to users of Z and similar specification languages [Jon90, Mor90] However, refinement reification emphasizes the formal mapping of an abstract representation of a program component to a more concrete one. We use the term metamorphic programming to emphasize that essentially we are engaged in programming an evolving system: the intent is to make it easy to ....

Carroll Morgan. Programming from Specifications. Prentice Hall International, 1990.

....Semantics It was decided to develop semantics that would support proofs at the program text level, with use being made of so called laws of programming or sourcelanguage transformation rules. For the C like language we explored the use of Hoare triples [HJ98] and weakest precondition [Mor94] and finally settled on the Hoare triples as a proof methodology. For the functional languages, we simply built a collection of re write rules neccessary to perform the proofs, rather than giving a complete set. In all three cases, we integrated the I O model with the semantics being developed. ....

Carroll Morgan. Programming from Specifications. Series in Computer Science. Prentice-Hall International, London, 2nd. edition, 1994.

....(Editors) Proceedings of the 6th Refinement Workshop, London, 5 7 January 1994, Springer Verlag, 1994. Software Verification Research Centre, University of Queensland, Brisbane, Australia. Email: nickson cs.uq.oz.au. y Email: lindsay comp.vuw.ac.nz. 1 Introduction The refinement calculus [1, 2, 3] provides a set of rules for deriving programs from formal specifications. Each rule defines a small step from specification to program; by building an appropriate sequence of rule applications, we can develop programs hand in hand with their proofs, with the confidence that the whole proof is ....

....larger example illustrating both techniques the derivation of an algorithm for calculating the least common multiple. 2 Refinement In this section, we describe the refinement calculus in a little more detail, and present the derivation of a simple program using refinement rules from [1] and [3], instantiating them fully before application. This serves to introduce the traditional style of development in the calculus, and shows how the goal directed strategies we wish to use sometimes conflict with the disciplines of this style. Specifications are written in the wide spectrum language ....

[Article contains additional citation context not shown here]

Carroll Morgan. Programming from Specifications. Prentice Hall, 1990.

....it is often useful to write the specification as A ) E, where A captures the assumptions about the environment of the specified system, and E expresses the effects of the system, such as the outputs that it must produce. Note that this gives the usual refinement ordering over specifications [BvW98, Mor90, Heh93]: a specification can 1 be refined (improved) by either weakening its assumptions (thus making it usable in more environments) or by strengthening its effects (being more precise about outputs) It is good specification style to specify just the essential or interesting properties of the outputs, ....

Carroll Morgan. Programming from Specifications. Prentice Hall, 1990.

....methods are strong candidates to the use of program transformation as well, since refinement laws can be easily described as program transformations satisfying preconditions that guarantee the soundness of the refinement. This is the case for imperative languages, as in the refinement calculus [14], but also for objectoriented languages [4, 5] In both cases, algebraic laws for programming languages can be viewed and implemented as program transformations. Those applications of program transformation show its importance, but its use in practical, large scale, projects is not possible ....

Carroll Morgan. Programming from Specifications. Prentice-Hall, 1994.

....from a forward and backward manipulation, respectively. 7 Related Research Back, Grundy and Wright [2] introduce hierarchical structure into the calculational format as presented in [5] and base it on natural deduction. The provisos, which we have introduced into the Morgan refinement style [13] already in [10] can be regarded as the second level of a two level hierarchy. TkWinHol [11] is also a refinement tool based on the HOL theorem prover [6] TkWinHol implements window inference which is another way to introduce transformational hierarchical reasoning [8] Whereas TkWinHol is ....

Carroll Morgan. Programming from Specifications. Prentice Hall, 1994.

....hardware, by regarding system designs as mathematical objects. System development can therefore be formalised as a process of moving, step by step, from an abstract statement of what is wanted, to an object that delivers it, in such a way that each step can actually be proved correct (e.g. see [25]) There are indeed some successful examples of this, but there are also a number of difficulties. One difficulty is that it can be a lot of work. Perhaps computer based tools can help reduce this effort; for example, syntax checkers, theorem provers, and sophisticated configuration managers ....

Carroll Morgan. Programming from Specifications. Prentice Hall, 1990.

....The problem appears to be that a formal description of a behavioural abstraction would have to describe how a behavioural abstraction changes the specification of any abstract data type with which it is composed. A promising line of attack seems to lie with the extension of the refinement calculus [Morgan1990] to object oriented programs described by Utting and Robinson in [Utting1991] Here the refinement calculus is used as the basis of a definition of the subtype relationship between types of object, and so subtype relationships are constructed by program refinements. Thus it seems possible that a ....

Carroll Morgan, "Programming from Specifications", Prentice-Hall, 1990.

....has been a guide. Morris s theory of stepwise refinement is quite close to ours [24] Our lattice is upside down with respect to his, but this is a minor notational difference. We should try to map his refinement theorems into our system. Morgan gives a detailed treatment of a refinement calculus [21]. Some useful ideas on loop refinment are included in [6] There are theoretical studies of models like ours that we should consult [3, 4, 7, 8, 25, 30] See also [9, 16, 22, 23, 28, 31, 32] ....

Carroll Morgan. Programming from Specifications. Prentice-Hall International, 1990.

....of a procedure explicit, and can be used during refinement to optimize the constructed logic program. We provide a semantics for the extended logic programming language and derive a set of refinement laws. Finally we apply these to an example derivation. 1 Introduction The refinement calculus [3, 12, 13, 14] provides a framework for the stepwise development of imperative programs from specifications. It makes use of a wide spectrum language which includes both specification and programming language constructs. That allows a specification to be refined, step by step, to program code within a single ....

.... semantics of programs can be given using the weakest assumption [7] cf. weakest precondition [6] wa:S :G b = ok :S (ef :S , G) Refinement between programs can be defined in terms of weakest assumptions similarly to the way imperative refinement is defined in terms of weakest preconditions [12]: S v T b = 8 G ffl wa:S :G ) wa:T :G) The present semantics, with ef and ok , is simpler, and the notion of refinement is close to that used in Z and VDM [25, 10] but note the , between the effects) 3.8 Refinement of procedures Given two procedures pa and pc we say that pa is refined by ....

[Article contains additional citation context not shown here]

Carroll Morgan. Programming from Specifications. Prentice Hall. Second edition, 1994.

No context found.

Carroll Morgan. Programming from Specifications (2nd ed.). Prentice-Hall, Inc., 1994.

No context found.

Carroll Morgan. Programming from Specifications. Prentice Hall, 1990.

No context found.

Carroll Morgan. Programming from Specifications (2nd ed.). Prentice-Hall, Inc., 1994.

No context found.

Carroll Morgan. Programming from Specifications (2nd ed.). Prentice-Hall, Inc., 1994.

No context found.

Carroll Morgan. Programming from Specifications, second edition (PrenticeHall, 1994).

No context found.

Carroll Morgan. Programming from Specifications, second edition (PrenticeHall, 1994).

No context found.

Carroll Morgan. Programming from Specifications. Prentice-Hall, second edition, 1994.

No context found.

Carroll Morgan. Programming from Specifications. Prentice-Hall, second edition, 1994.

First 50 documents  Next 50

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