Issue 2006-1 FACS March 2006 A

F~v1E C A AClvi l F C T . . r-:.. MET.H ODS ~> T R· se sc~ rv1 S Z A UM.·L ·IFMSI·G E E E E E

The Newsletter of the Formal Aspects of Computing Science (FACS) Specialist Group.

ISSN 0950-1231 '- I·~,

FACS FACTS Issue 2006-1 March 2006

2 FACS FACTS Issue 2006-1 March 2006

Editorial 4

On the Verified-by-Construction Approach 6

Obituary: F _X. Reid 12

.Conference Announcements 15

On the Formal Semantics of the COMEFROM Statement 18

Book Announcement 22

PhD Abstracts 23

FACS Committee 26

3 FACS FACTS Issue 2006-1 March 2006

Welcome to the first Issue of FACS FACTS of 2006. As usual we thank all of the contributors for their support - without them there would be no newsletter. Submissions are always welcome, so please do feel free to contact the editor, Paul Boca [[email protected]. . This is a somewhat sombre time for the editorial board of the newsletter, as we have recently learned that F. X. Reid [http://en.wikipedia.org/wiki/F.X.ReidJ. long-term contributor to ttie FACS newsletter, has unexpectedly passed away. An obituary, written by Victor Zemantics, appears on page 12. Reid authored several articles over the years, and has been responsible for "educating" many PhD students as a result. As a tribute to him, we will reprint some of his "gems", starting with an article on the semantics of the COME FROM statement (see page 18). On a happier note, we can report that the FACS Evening Seminars are still proving to be very popular. We began the year with a panel discussion, entitled Formal Methods in the Last 25 Years; more than 70 people attended. The event was organized together with Formal Methods Europe (FME), chaired by John Fitzgerald. We would like to thank FME and the Centre for Software Reliability, University of Newcastle upon Tyne for co-sponsoring the event with FACS. We are hoping to bring you a report on the event in the next issue of the newsletter, together with a reprint of the classic "Magic Roundabout" article. Peter Mosses gave the second seminar in the series this year, entitled Description Languages: From Scott and Strachey to Semantics Online. The seminar was attended by almost 40 people - an excellent turnout for a Friday evening. At the time of writing this editorial. we are organizing the third seminar in the series, to be given on 24 April 2006 by Cliff Jones, entitled Specifying Systems that Connect to the Physical World. We expect this to be equally successful, and once again it is an opportunity for people to hear an address from another pioneer in formal methods. The seminar programme for the rest of the year is available on the BCS­ FACS website [htlp:llwww.bcs-facs.org/events/EveningSeminars1 and in the advertisement on page 14. Slides from previous seminars are available to down load from this website too. We hope you will find the programme of interest and will be able to attend - the seminars are free of charge, funded from membership subscriptions (see page 25 for a membership form). FACS held its AGM on 3 March 2006, and a report on the meeting will appear in a future issue of the newsletter. F ACS welcomes two new committee members: John Derrick (University of Sheffield) to coordinate activities relating to refinement and Mark D'lnverno (University of Westminster) to coordinate model-based specification events (on topics such as B, VDM, Z, etc.). Please do liaise with John or Mark if you are interested in being involved with events in these areas. Unfortunately, FACS has lost two of its officers, AIi Abdallah and Kevin Lano. On behalf of all the members, we would like to thank them for all their efforts over the years. In particular, AIi organized two major and very successful events for F ACS, FASec in 2002 on formal aspects of security and CSP 25 in 2004 to celebrate a quarter of a century of FACS and

4 FACS FACTS Issue 2006-1 March 2006

Communicating Sequential Processes activities. In no small measure, these helped rejuvenate FACS and both proceedings appeared as Springer LNCS volumes. We hope you will enjoy reading the current issue and again encourage you to contribute as well. M!

5 FACS FACTS Issue 2006-1 March 2006

Introduction

At the VSTTE (Verified Software: Theories, Tools, Experiments) conference [http://vstte.inf.ethz.chD held in ETH Zurich in October 2005, Tony Hoare and Jay Misra presented a vision of an international Grand Challenge to construct a program verifier. This vision appears to be having a very powerful catalysing effect on getting researchers in all manner of formal development approaches to pool resources and work towards more common goals. This is borne out by the large gathering of top researchers at the VSTTE conference and by the subsequent establishment of working groups set up to refine the challenge further. This article is my attempt at making the case for the so-called verification-by-construction approach to formal development and the contribution it can make to the challenge of verified software.

Why verification-by-construction is important

Much discussion on the need for a powerful program verifier seems to contain the following underlying assumptions:

• That a program verifier will be used mostly to verify programs • That when verification fails it is because the program contains errors

While a powerful program verifier is a very valuable tool for programmers, it does not help them construct a verifiable program in the first place. Equally, the quality of any verification is dependent on the validity of the formal properties against which a program is checked. The verification-by-construclion approach helps developers who want to construct reliable software systems by addressing the following questions:

• How do we construct properties against which to verify our software? • How do we construct our software so that the verification will succeed?

The verification-by-construction approach is about providing design tools that help developers produce reliable software. It broadens the focus away from just being analysis of the finished product and addresses better the development process.

How can verification-by-construction be achieved?

Verification by construction can be achieved by having a formal framework in which models are constructed at multiple levels of abstraction and related by

6 FACS FACTS Issue 2006-1 March 2006 refinement1 relations_ The highest levels of abstraction are used to express the required behaviour in terms of the problem domain. The closer it is to the problem domain, the easier it is to validate against the informal requirements, i.e., ensure that it is the right specification. The lowest level of abstraction corresponds to an implementation or to a specification from which an efficient implementation can be derived automatically. Also critical in this framework are mechanisms for composing and decomposing models. Composition can be useful for building up specifications by combining models incorporating different requirements. Decomposition is important for relating system models to architectures of subsystem models and subsequent separate refinement of subsystems. Ensuring that two models, M1 and M2, are in a refinement relation may be achieved in one of two ways:

1) Posit-and-Prove: The developer provides both M1 and M2 and uses tools to verify that M1 is refined by M2. In some cases this might be possible using a model checker. Alternatively a tool will generate proof obligations which can be verified using powerful theorem provers or possibly checked using model checkers. Typically this approach requires properties such as invariants and variants to be provided by the developers.

2) Transformational Approach: The developer provides M1 and applies a transformation that automatically constructs M2 in a way that guarantees refinement. This might result in the generation of side conditions that will need to be verified but discharging these should be a lot less effort than proving that M1 is refined by M2 in the posit-and-prove way. One can immediately see how the transformational approach helps developers to construct software such that the verification will succeed. Unfortunately a fully transformational approach for a broad range of problems and solutions is far from being realised so that the posit-and-prove approach will rule for the foreseeable future. It might not appear immediately clear how the posit-and-prove approach helps developers to construct software for which the verification will succeed since the developer is expected to provide M2 as well as M1. This is where having multiple levels of abstraction is important. Typically there is a large abstraction gap between a good formal specification, i.e., one that is easy to validate against the requirements, and an efficient implementation. This gap means it is more difficult to be guided by the specification when constructing an implementation. By having smaller abstraction gaps between a model M1 and its intended refinement M2, it is more natural to be guided by M1 when constructing M2. Typically a refinement step incorporates a design decision about how some effect is achieved or represents an optimization of the design. With a small abstraction gap, the construction of M2 is driven by both M1 and the desired design decision or optimization. When the construction of M2 is guided by M1, then the verification that M2 refines M1 is more likely to succeed.

1 According 10 dictionary.com, '10 refine' means 'to reduce to a pure state'. Ironically our use of the term has the exact opposite meaning. The term 'reify' (as used by Cliff Jones and others) is perhaps more appropriate for what we do but is far less widespread. I expect we are stuck with 'refine'.

7 I I,' "

FACS FACTS Issue 2006-1 March 2006

A halfway house between transformational and posit-and-prove can be envisaged, where certain patterns of model and refinement can be captured and used in the construction of refinements. This is a more pragmatic idea than transformational refinement in that the pattem might not guarantee the correctness of the refinemenf. Instead M2 would be constructed from M1 by application of a pattem and the correctness of the refinement would be proved in the usual posit-and-prove way. Ideally the pattern should provide much of the ancillary properties (e.g., invariants, tactics) required to complete the proof.

Models versus Properties

In a refinement approach one does not necessarily distinguish between properties and models. Essentially we are working with models in a modelling language and the important property to be proved of some model M2 is that it is a refinement of some other model M 1. In doing this, we may need ancillary properties like invariants, variants and assertions. Good tools can help us discover these ancillary properties as part of the effort of trying to prove a refinement. So the answer to the question 'what properties should we prove of a model?' is 'those properties that allow us to show that it is a refinement of its abstraction'. For the most abstract models, the important property is that they satisfy the requirements of the problem domain. This is an informal check which can sometimes be aided by ancillary properties. Within a particular framework there may be differing strengths of refinement. A weaker notion might capture the preservation of safety behaviour, while stronger notions might capture preservation of liveness and/or fairness. With a refinement approach the 'creative' input in a development is a collection of explicit models at different levels of abstraction. The invention of ancillary properties is dictated by the need to prove refinement between these explicit models. From an engineering perspective, I would argue that an explicit model is a fairly natural thing to have to create because one can easily get a feeling of 'completeness' of the model (at a certain level of abstraction). When creating properties rather than models I find it is more difficult to achieve that sense of 'completeness'. In my experience, refinement is never purely top down from most to least abstract. The reason is that it is difficult to get the abstract model precisely right. One usually starts with an idealistic abstract model because that is easy to define. As refinement proceeds and more architectural and environmental details are addressed it often becomes clearer how the ideal abstract model needs to be modified to reflect reality better. Modifications to some level of abstraction will ripple up and down the refinement chain. This is not a weakness of the refinement approach per se, rather a reflection of the reality of engineering of complex systems. It goes without saying that the refinement relation should enjoy some form of transitivity. I say 'some form of transitivity' because refinement is based on comparing some notion of what can be observed about a model and it is useful to be able to modify what can be observed at different levels of abstraction. In particular, the interface to a system is usually described

2 A refinement M2 is correct with respect to some model M1 when M2 refines M1.

8 ~-,

FACS FACTS Issue 2006·1 March 2006

abstractly and may need to be made much more concrete at decomposition or implementation levels. In such cases, the observable behaviour is not directly comparable, but needs to be compared via some mapping and transitivity of refinement is via composition of mappings.

Other points in favour of verification-by-construction

The verification-by-construction approach encourages verification of designs and not just verification of programs. From an engineering perspective, it is possible that there is a greater payoff from verifying designs rather than programs. Does it not seem more likely that a design error would have a detrimental impact on system reliability than a programming error? As well as supporting verification of designs and implementations, good formal modelling languages encourage a rational design process. The use of good abstractions and simple mathematical structures in modelling can lead to cleaner, more rational system architectures that are easier to understand and evolve than architectures developed using less disciplined approaches. Being able to verify a system is not enough. It is also important to be able to test, maintain and evolve it. This is facilitated by rational design. Th~ inclusion of annotations such as invariants and assertions in programming languages (e.g., Eiffel, Spark Ada, JML, Spec#), along with associated analysis tools, provide powerful support for programmers. However, this approach is not enough on its own as these annotations are designed to specify properties about programs but do not easily allow for reasoning about the contribution an individual program makes to the overall reliability of a system. Control systems, interactive systems and distributed systems involve multiple agents (users, environments, new programs, legacy components) all of which contribute to the reliability of a system. Individually the agents may be very complex so reasoning about compositions of agents in all their gory detail may be infeasible. Instead, there is evidence that it will be feasible to reason about complex systems through good use of abstraction, refinement and decomposition. When verifying a program directly one is having to reason about a number of issues simultaneously; the problem to be solved, the data structures used in the solution and the algorithmic structures used in the solution. If these issues can be facto red out and dealt with separately as much as possible, the proof obligations can be simplified and the reasoning made more manageable. Abstraction and refinement supports this factorisation. It is often possible to model and reason about how a strategy solves a problem in an abstract way using abstract algorithmic and data structures. This abstract solution can then be optimized by introducing more concrete algorithmic and data structures through refinement. Reasoning about these optimizing refinements no longer requires reasoning about the original problem as this will have been dealt with by the earlier refinement. By keeping the models as abstract as possible at each level, we will have simpler proof obligations to discharge. At higher levels of abstraction we focus the reasoning more on the problem domain and less on the details of the particular solution.

9 , ..'

FACS FACTS Issue 2006-1 March 2006

Further questions

Which notations should be used? My own experience is that one can go a long way with set theory and logic as used, for example, in Z, VDM and B. Dealing with reactive and distributed systems in these notations requires richer notions of refinement and decomposition, but not necessarily major extensions to the notations. In cases it is appropriate to augment set theory and logic with notations such as process algebra and temporal logic.

What type of systems should we work on in the grand challenge? I am especially interested in multi-user, distributed systems and in control systems involving an environment and believe these will provide many interesting challenges.

What about the link to programming languages? To some extent, the choice of particular programming language is not so important in the verification-by-construction approach. What matters is that a sound mapping can be made between the lower level abstractions used in verification-by­ construction and the constructs of target programming languages. There is however an interesting overlap between this mapping and important research in programming language design which tries to improve programming abstractions. In particular I am thinking of:

• Declarative styles of programming • Atomicity and transactional support for concurrent programming • Abstractions for structured data (e.g., abstractions of XML messages, abstractions of pointer structures)

Clearly, better programming abstractions will make it easier to bridge the gap between models and programs.

The challenge

To a large extent the required theory to support verification-by-construction already exists. The challenge is to provide a powerful set of tools to support abstraction, refinement and decomposition. In achieving this, we should strive to achieve as much integration as possible and avoid silos. We should also exploit as much of the existing and future advances in theorem proving and model checking as possible, as well as advances in programming language design, program verification and automated program generation. As they evolve, the support tools should be applied to the development of interesting software­ based systems. No doubt interesting theoretical advances will be identified and achieved along the way as well. !ill

10 .,

FACS FACTS Issue 2006-1 March 2006

11 ,·

FACS FACTS Issue 2006-1 March 2006

The world of theoretical computer science was devastated last night by the announcement of the death of that great pioneer, teacher, raconteur, bon vivant and serial philanderer, Professor F_ X_ Reid. Speaking from Reid's villa in Marsascala, his physician, Dr. de Bono, told reporters: 'Not since the death of Jean Parisot de la Valletle have the people of Malta so moumed a resident alien. Professor Reid fought his infirmity with the implacability with which, so I'm told, he was notorious.' He was then observed to shed a small tear. 3 Tributes have been coming in from all over the world . A special mass has been announced in St Peter's in Rome and a number of prominent Anglican cathedrals have already begun a somewhat unseemly wrangle over the possession of his bones. Poet's Corner has yet to put in a bid. Details of the great man's life are not so much hard to come by as impossible to verify, or, at least, believe. Born 'in the early 1930s' in Przemsyl and christened Francis Xavier Rzyzryrd ('a bad hand at Scrabble', as he quipped later in life), he was educated privately (,Despite my name, my parents were dismissive of the Jesuits - name one Jesuit mathematician!'), before entering the University of Vienna ('at a remarkably early age'), to study philosophy. He quickly transferred to Gottingen (,Wittgenstein or somebody made a heavy pass at me.'), where he soon attracted the attention of David Hilbert, among others. At this point, the record becomes obscure. Rzyzryrd claims that his exposure to the Abstract Algebraists at Gottingen prompted him, not only to invent Universal Algebra ('a rather obvious generalization') but to see an application for it in the theory of abstract data types and algebras of processes ('My first attack on the formalization of computability preceded those of Church and Turing and was remarkably prophetic, given the later development of strongly typed procedural languages.') Unfortunately, Rzyzryrd's PhD thesis, if it ever existed, was destroyed during the firebombing of Dresden4. By this time, Rzyzryrd, who now styled himself Reid, was in Bletchley Park. Again, due to the top secret nature of the decryption work going on there, there are no records to back up his claim that: 'If it were not for me, the Bismark would still be afloat' nor his accusation that 'Alan Turing or somebody made a heavy pass at me'. It was at Bletchley that Reidfirst encountered electronic computers. I think we can discount his claim to have written a primitive version of Pacman for the Colossus machine, but it was certainly from this period that his principal research effort originates. 'My first inkling as to how recursive procedures could be implemented came in the canteen at Station X, watching trays being stacked and unstacked; anything to take my mind from Spam fritters!') His first major

3 Except Oxford, of course, where they affect not to have heard of him, or, indeed, anybody else. 4 Just why all cop'u:,s of the thesis were in Dresden has yet to be explained.

12 FACS FACTS Issue 2006·1 March 2006 discovery (unattributed), the wash-rinse cycle is said to date from his time at Bletchley ('It took weeks from the laundry to come back; fortunately I had two pairs of socks'). At the conclusion of hostilities in Europe, Reid sought to join Turing in Manchester at the ACE project, but apparently Turing 'felt nervous in my company, for some reason: Instead, Reid began a peripatetic existence, moving (and being moved on) from University to University seeking and occasionally finding academics with whom to collaborate. Karl Adam Petri, Dana Scott, Christopher Strachey, Donald Knuth, Robin Milner, Tony Hoare, Cliff Jones, David Turner and Antoni Mazurkiewicz are just some of the leading theoreticians who found an urgent need to be elsewhere when he turned up on their doorsteps. Nevertheless, he pursued his work, publishing his celebrated 'Redundant Sock Theorem' (an application of Shannon's information theory to Laundry Science) in 1949, his study of the stochastics of mis-delivered mail (a profound influence of the development of the notion of packet-switching), in 1953 and in the period from 1961 to 1985, a series of ground-breaking papers culminating in the publication of his General Theory of Generality (a marriage of Scott's recursive domains and non-standard logic). This work is still not fully understood and, indeed, probably never will be. Reid's acting career is much less widely known, probably for good reasons. While I am not convinced that he did actually stand in for William Hartnell in the first series of Dr. Who, his height (not to mention his somewhat precise mode of speech) would have made him ideal as a Dalek. His sequence of commercials for a well known brand of haemorrhoid ointment is now, thankfully, forgotten. His non-scientific writings have also been unnoticed. His first novel 'Legless in Gozo', written shortly after moving to Malta, 'to avoid the Yob culture of Hampstead and such places', remains unpublished, although Reid's literary agent, Tony Bowdler, maintains that it is 'a masterpiece - a synthesis of Proust, J. K. Rowling and the Marquis de Sade ... it is not fully understood and probably never will be.' A thinly disguised autobiography, it inevitably contains a variety of passages in which various eminent people make heavy passes at the narrator. But it is to Malta that we owe a resurgence in Reid's scientific creativity. Writing always for obscure publications, such as the FACS newsletter, FACS FACTS, he continued to extend and elaborate his work on non-Bayseian probabilistic cube-complex automata, asynchrony theory and deadlock taxonomies. His .magnum opus, the as yet unpublished Principia Informatica, a work not fully understood, etc., was produced during this period. There are rumours, some ugly, of a second novel and a concertino for oboe and string orchestra. And what of Reid's legacy? This is a difficult question to answer, or even contemplates. Was he, as he claimed, the embodiment of the Zeigeist always at the front line of the burgeoning discipline of informatics, always anticipating the

5 At least with a straight face.

13 FACS FACTS Issue 2006-1 March 2006 work of others and modestly declining to take the credit? Or was he merely the figment of a warped imagination? Time may tell, but I certainly won't. i~

14 .'

FACS FACTS Issue 2006·1 March 2006

The following are sponsored by BCS-FACS and/or considered of special interest to BCS-FACS members:

15 ..'

FACS FACTS Issue 2006-1 March 2006

16 ..

FACS FACTS Issue 2006·1 March 2006

For further conference announcements, please visit the Formal Methods Europe (FME) website [http://www-fmeurope.orgJ, the EATCS website [http://www.eatcs.orgJ and the Virtual Library Formal Methods website [http://vl.fm net. i nfo/meetingsJ.

17 !

FACS FACTS Issue 2006-1 March 2006

[Editors' note: Surprisingly, some of the early work of F. X. Reid has been almost entirely ignored and the following paper, reprinted here from the Proceedings of the Huddersfield Philosophical Society, is no exception. In his, as yet unpublished Autobiography 'Biographia Informatica', which we have been privileged (or to be more accurate, badgered) to examine, Reid writes:

I confess to have been disappointed by the reception of the Huddersfield paper. Its originality and importance can surely not be exaggerated extending as it did conventional notions of and introduCing at one blow, a combination of backtracking and non-determinism. Although developed in the spirit of the Floyd flow­ diagram paradigm, it was quite capable of an extension to the more block-structured approach. However, my paper on the while P undo S odnu construct failed to appeal to the Zeigeist and had to be withdrawn. Such was the short-sightedness of my erstwhile colleagues.

and so on. We sought permission from Huddersfield to print the following extract but learned that the Society was no longer extant, as shortly after the publication of the paper it broke up following what one sUNivor described as 'a most un-philosophical punch-up in the Rat and Feathers', adding darkly, 'publish the wretched thing - if you dare!'

Our temerity thereby challenged - here it is. We skip the introduction, as we found it somewhat verbose.] .

2 The Basic model

We consider a program in the abstract as consisting of:

1. A finite set Vof variable names. For simplicity, we assume all variables to take values from the set Z of integers.

2. A finite set N of lines and a total order R c- N x N . Write n n for the unique element of N such that n"; no all n E N and write n., for the unique element of N such that n., ,,; n all nE N. We define succ(n) to be the unique line covered by n, unless n = n., and we define succ(n.,) = n.,. 3. A labelling function A: N --+ Stat , where Stat is a set of statements. Statements have one of the following three forms.

18 ,~

FACS FACTS Issue 2006-1 March 2006

Skip Statements: There is only one of these taking the form skip,

Assignment Statements: these take the form v = E, where v E V and E is an arithmetic expression as in the programming language ,

Comefrom Statements: these take the form if B comefrom n where n E Nand B is a Boolean expression as in FORTRAN,

[Editors' note: In Reid's original paper, expressions were defined syntactically, using what he subsequently described as RBNF, The paper was, in fact, written before the publication of the ALGOL reporl, At least, it is dated before that publication,]

3 Operational Semantics

We define a configuration of the program to be a pair (n,s)ENx[V~Z~], where Z ~ = Z u {.L} , where .L represents the totally undefined value, If

er = (n,s) , then we define nff = nand Sff = s, Denote the set of all configurations by Con! '

If SE [V ~ Z ~] and E is an arithmetic expression, then we define E(s) to be the value obtain by substituting s(v) for each variable v appearing in E, If s(v) =.L for some v appearing in E, then E(s) =.L, We make analogous definitions for Boolean expressions,

If SE [V ~ Z ~], Z E Z ~ and v E V, then we define

z if v' = v &[v\z](v') = {s(v') otherwise

If er,er' E Con!, then we define er f- er' as follows,

Skip, If ,1,(nff ) is skip, then nff· = slIee(n,,) and S,,' = Sff'

Assignment. If ,1,(n,,) is v = E , then n,,' = slIcc(n,,) and S". = s,,[ v \ E(s" )],

Comefrom. If B(s) = true, then n". =slIcc(n) and s". E lIndo(c",,1,(n,,» otherwise n". = slIcc(n,,) and S,,' = s", Here undo(s" ,,1,(n» ~ Is} if ,1,(n,,) is not an assignment. Otherwise if ,1,(n,,) is v = E , then

lIndo(s",,1,(n))={s' E[V ~Z~]:E(s')=s,,},

19 FACS FACTS Issue 2006-1 March 2006

A partial execution of a program is a sequence 0", .. - 0"" such that 0", is of the form (no, c) and 0"; f-- 0";+" i = I, ---, n -I _ It is a total execution if in addition 0"" is of the form (n""c) and 0"; is not of this form I

[Editors' note: At this point, Reid explains that the program fragment

n skip n + 1 statement

n if x = 0 comcfrom n has exactly the same effect as

n + 1 statement

n if x = 0 n

'As he makes rather a meal out of this rather obvious point, we omit it, together with his remarks on what he calls the Reid-Church-Turing Thesis, which might cause distress to those of a nervous or choleric disposition_]

Programs compute relations not functions_ The relation computed by a program

is defined as follows_ (c,c-) E F if and only if there exists a total execution

0",---0"" such that 0", =(no'c) and 0"" =(n""c-)_

The following is an example program, in which V = {I,2,3,4}

1 x = I 2 y:=x 3 if x * 0 comcfrom I 4 skip

Applying the semantics, and representing a configuration by a triple (n,x,y) , we have possible executions

(1,.1,.1) H2,l,.1) H3,I,I) H2,z,l) H3,z,z) H2,O,z) H4,O,z)_

Hence ((.1,.1),(O,z» E F for all z E Z _ In other words, the program acts as a random number generator.

[Editors' note: To return to 'Biographia Informatica', Reid writes:

20 FACS FACTS Issue 2006-1 March 2006

I regret not having included a section in which I demonstrated how comefrom programs may be used to solve what are now called Sudoku puzzles. It is a simple enough matter to G6delise a Sudoku grid and to construct a primitive recursive predicate done(n) with the property that done(n) . is true if and only if n is the G6del number of a successfully completed puzzle. However, the chairman of the Society, a Mr. Bauls, convinced me (no easy task) that such puzzles would never enjoy any popularity and I reluctantly omitted the section in question. A pity.

Reid finally summaries the paper at unnecessary length, and concludes with a discussion of implementation. As this involves a detailed description of Hennitian operators on Hilbert spaces, and as life is short, we have omitted it. Of course, Reid now claims to have invented quantum computing.] I

21 FACS FACTS Issue 2006-1 March 2006

Modern Formal Methods and Applications Gabbar, Hossam A_ (Ed.) 2006, XXIII, 197 p., Hardcover ISBN: 1-4020-4222-1

Formal methods is a robusl approach for problem solving. It is based on logic and algebraic methods where problems can be formulated in a way that can help to find an appropriate solution. This book shows the concepts of formal methods and highlights modern modifications and enhancements to provide a more robust and efficient problem solving tool.

Applications are presented from different disciplines such as engineering where the operation of chemical plants is synthesized using' formal methods. Computational biology becomes easier and systematic using formal methods. Also, hardware compilation and systems can be managed using formal methods.

This book will be helpful for both beginners and experts to get insights and experience on modern formal methods by viewing real applications from different domains.

Written for:

Undergraduate and graduate students, industrial professionals in engineering systems

Keywords:

Formal approach for biological systems Formal approach for engineering systems Formal methods Language specifications Software and hardware specifications

22 .f

FACS FACTS Issue 2006-1 March 2006

Name Greg Reeve Title A Refinement Theory for IJ-Charts Supervisor Prof. Steve Reeves Institute University of Waikato Examiners Prof. Martin Henson & Prof. Jonathan Bowen Awarded December 2005 URL http://www.cs.waikato.ac.nz/pu bs/2005/pdfs/reeve-lhes is. pd! Keywords State charts, IJ-Charts, Z, Logic, Refinement

The language IJ-Charts is one of many Statechart-like languages, a family of visual languages that are used for designing reactive systems. We introduce a logic for reasoning about and constructing refinements for IJ-charts. The logic itself is interesting and important because it allows reasoning about IJ-charts in terms of partial relations rather than the more traditional traces approach. The method of derivation of the logic is also worthy of report. A Z-based model for the language IJ-Charts is constructed and the existing logic and refinement calculus of Z is used as the basis for the logic of IJ-Charts. As well as describing the logic we introduce some of the ways such a logic can be used to reason about properties of IJ-Charts and the refinement of abstract specifications into concrete realisations of reactive systems. A refinement theory for Statechart-like languages is an important contribution because it allows us to formally investigate and reason about properties of the object language IJ-Charts. In particular, we can conjecture and prove general properties required of the object language. This allows us to contrast possible language design decisions and comment on their consequences with respect to the design of Statechart-like languages. This thesis gives a comprehensive description of the IJ-Charts language and details the development of a partial relations based logic and refinement calculus for the language. The logic and refinement calculus are presented as natural deduction style proof rules that allow us to give formal proofs of language properties and provide the basis for a formal program development framework. The notion of refinement that is encoded by the refinement rules is also extensively investigated. Ni

23 FACS FACTS Issue 2006-1 March 2006

24 :

FACS membership application/renewal (2006)

Title (Prof/Dr/Mr/Ms) __ First name ______Last name' _____

Email address (required for options * below), ______

BCS membership No. (or sister society name + membership number)

Address

Postcode ______Count~ ______

I would like 10 take out membership to FACS at the following rate: o £15 (Previous member of BCS-FACS now retired, unwaged or a student) o £15 (Member of BCS or sister society with web/emailaccess)* o £30 (Non-member or member of BCS or sister society without web/email access)

ALL MEMBERS WILL RECEIVE FREE ELECTRONIC ACCESS TO THE FORMAL ASPECTS OF COMPUTING JOURNAL UNTIL THE END OF DECEMBER 2006 I would like 10 subscribe to Volume 18 of the FAC journal (paper copy) at the following rate: o £48

The total amount payable to BCS-FACS in pounds sterling is £ 15/30/63/78 (delete as appropriate). I am paying by:

o Cheque made payable to BCS-FACS (in pounds sterling) o Credit card via PayPal (instructions can be found on the BCS-FACS website) o Direct transfer (in pounds sterling) to: Bank: Lloyds TSB Bank, Langham Place, London Sort Code: 30-94-87 Account Number: 00173977 Title of Account: BCS-FACS

If a receipt is required, please tick here 0 and enclose a stamped self-addressed envelope.

Please send completed forms to: 1,,------···· .. ·.. ·.. ·· .. ·· .. ·.. ·.. ·.... ·· .... ·.. _...... -...... __ ._ ...... F~);' I>! CS' :;,~'(: ';J?!~~.; Or Paul P Boca PO BOX 32173 LONDON N44YP UK hi~~()!s: :...... FACS FACTS Issue 2006-1 March 2006

Jonathan Bowen Jawed Siddiqi FACS Chair Treasure r Paul Boca ZUG Liaison Secretary and Newsletter Editor Execu ti ve Office rs

Roger Carsley John Cooke John Fitzgerald Minutes FAC Journa l FME Liaison Secretary Lia ison SCSC Liaison

Judith Carlton Margaret West Rick Thomas Ind ustrial liaison BCS Liaison LMS Lia ison

Mark O'lnverno John Oerrick Rob Hierons Model-based Refinement Formal method s specification and lesting

26 , .

FACS FACTS Issue 2006·1 . March 2006

FACS is always interested to hear from its members and keen to recruit addilional helpers. Presently we have vacancies for officers to liaise with other specialist' groups such as the Requirements Engineering group and the European Association for Theoretical Compuler Science (EATCS). and to maintain Ihe FACS website. If. you are able to help. please contact Professor Jonathan Bowen. the FACS Chair. 'at the contact points below:

You can also contact the other officers via this email address.

Please feel free to discuss any ideas you have for FACS or voice any opinions openly on the FACS mailing list [[email protected]]. You can also use Ihis list to pose questions and to make contact with olher members working in your area. Note: only FACS members can post to the list; archives are accessible to everyone at http://www.jiscmail.ac.ukllists/facs.html.

27