About This Unit

Welcome | Unit Context | Objectives for the Unit | Evaluation | Previous News Items

Welcome

Welcome to CSE4213! This home page should be your first port of call for any information specific to this subject. If the information you seek is not here, drop me a note and I'll endeavour to fix it for you.

This subject has a Handbook Entry on the web. It also has an Anonymous Feedback Page.

Please note that this page will be regularly updated throughout the semester. You are encouraged to bookmark it in your browser, and visit it at least once per week.

Unit Context

The Handbook Entry for CSE4213

The Undergraduate Handbook itself is at: http://www.monash.edu.au/pubs/handbooks/undergrad/

Prerequisite knowledge

Completion of CSE2303, MAT1830 or MTH1112 or MAT1077

A thorough knowledge of set theory is required, and students should also be familiar with first order predicate calculus. The Infotech Unit Avatar entry lists CSE2201 as an additional prerequisite, however, this prerequisite has not yet been approved by faculty.

Relationship to following units

There are no units that follow up material in this unit.

Objectives for the Unit

The unit has the following objectives (adapted from the unit description in the Infotech Unit Avatar)

1. an understanding of the Fundamentals of the B Method
2. an awareness of the Applications of the B Method
3. A reading knowledge of B specifications
4. The use of Software Testing in the discrete domain
5. The role of proof obligations and consistent specifications
6. How to extract a Determination of Proof Obligation
7. an understanding of the role of refinement in developing formal specifications
8. An appreciation of the professional need to establish formal properties of software
9. A belief that formal specifications can improve the quality of software
10. Skills in using the B notation to develop and prove software specifications
11. The ability to install a B Toolkit on a Unix/Linux platform
12. The ability to write basic B specifications
13. The ability to refine and extend more advanced B specifications

Evaluation

The unit evaluation from 2006 is available here.

Previous News Items

20070528:144048

Lecture 26 is cancelled. John Hurst will be available in building 63, room 123, if any student wishes to discuss any topic relating to this unit.

20070523:185111

The deadline for submission of Assignment 3 has been extended to 12noon, Friday 25 May.

20070507:093109

A message from Professor Merran Evans, Acting Deputy Vice-Chancellor (Education)

Power shortage at Clayton Campus - effect on teaching

Due to the disruption caused by the cancellation of classes on 16-18 April on the Clayton campus, teaching staff will be allowed to cover new material and to schedule assessment submission deadlines in the first two and a half days of Week Thirteen of this semester, where it is not possible to otherwise make up for the lost time. This special arrangement is limited to the units affected by the cancellation of classes, and teaching staff should make use of it only when absolutely necessary.

If Week Thirteen is being used in this way students must be notified by email and/or through MUSO by the end of Week 10 (week commencing Monday May 7).

(John Hurst): Note that the lecture (but not assessment) schedule below reflects this special arrangement.

20070501:141003

A complete Library implementation, as discussed in lectures 17 and 18, can be found in the examples directory.

20070426:192752

Assignment 3 is available.

20070426:192752

A draft version of Assignment 3 is available.

20070426:192322

ITS appears to be blocking mail to csse from student accounts. Please make sure that if you want email me, that you use the address john.hurst at infotech dot monash dot edu dot au (The old csse address still works from outside the university.)

20070425:123531

For Assignment 2, please make sure that you submit either

1. a tar or zip file containing your submitted files. The file must be named <your student id>.{tar.zip}; or
2. A single pdf file containing all your work. The file must be named <your student id>.pdf.

It is important your file be labelled correctly: there is a danger that your work will get lost or incorrectly attributed otherwise!

Note that the submission date for assignment 2 has been extended to Friday, 27 Apr 2007 (at 12noon).

20070404:111440

Assignment 2 is now available.

20070404:083746

Note that John Hurst has now moved offices, vacating building 75, and now residing in building 63, room 123

20070403:160935

There appears to be a bug in version 5.1.12 of the BToolkit, in that the assertions in the animation fail where they should not. Version 5.1.4 (used to develop the animation) does not have this problem. I apologise for the inconsistency. Just make a comment on your output noting the bug, and that the assertion can be seen to be correction by inspection.

20070327:163318

The source text of various specifications used in lectures and tutorials are being made available on the Resources Page

20070326:154825

The following comment is reproduced from the Anonymous Feedback Forum from 2005, and was offered as an insight into the nature of weakest preconditions. (Incidentally, I think I may have got 'weak' and 'strong' on the wrong side in my tutorial discussion this morning, in case you are reconciling this diagram with that. My apologies!) You should also now get a better idea of what I was trying to say with the discussion about starting and ending states, and the predicate transform required to move from one to the other.

>In lecture note "Precondition & Guard", what does "there is a weakest>precondition - necessary and sufficient" mean?  Is there any>necessary weakest precondition or sufficient weakest precondition?>By the way, what's the definition of "weakest precondition"?Think of it like this.  There is a spectrum of "weakness" forpreconditions, from the weakest (true) to the strongest (false).Everything satisfies the weakest precondition, nothing satisfies thestrongest precondition.  That's effectively what we mean by"weakness", where it is on this spectrum.:  true <--------------+------------------------>false:                      ^:    make weaker <--   |   --> make stronger:                      +-- arbitrary program preconditionIdeally, all programs should have the weakest precondition aspossible.  That means they behave themselves in any circumstance.  Inpractice, that's not realistic.  So we seek the weakest possiblepreconditions *necessary* to guarantee behaviour.  By "behaviour", wemean that the program satisfies a predicate (the "goal") uponcompletion.P => [G] R    (P is precondition, G is the program "substitution", R is the goal predicate)In practice, you can always strengthen the preconditions.  In theextreme, false is sufficient to guarantee any behaviour (remember the"miracle programs" and "pink elephants"?).  However, we cannot workmiracles, so we look for weaker preconditions *sufficient* that stillguarantee the behaviour, without becoming so weak that the programmust behave itself under broader circumstances than really required(necessary).HTH

20070312:155417

The move of lectures will not happen. The issue was one of cost, but it subsequently proved that the tutorial time was not available in the new location, so rather than disrupt anything, we are staying with the existing arrangements.

20070306:093129

The Anonymous Feedback Page is working again

20070305:150330

The Anonymous Feedback page is not working at the moment, as the site has been hacked, and is down pending repairs. In the meantime, please use the MUSO discussion board.

20070301:133730

It has been suggested that lectures might move from R6/S1 to the seminar room, building 75 (rm G55). I'd be interested in reactions to this suggestion. Discussion to the Anonymous Feedback Page please!

20070223:153132

Lecture number 3 (5 Mar) is cancelled, due to unavailability of the lecturer.

20070227:155302

Note that the tutorial immediately after (and the Thursday one) are also cancelled. Lecture 4 on Tuesday, 6 Mar 2007 will be held.

20060227:151347

These web pages are in transition, and there may be errors in them, particularly in things like links. If you notice any link not pointing to the right place, please let me know, and I can fix it.

20050404:080817

In assignment 1, if you find proof obligations that the Auto Prover will not discharge, that means one of two things: a) your specification is inconsistent. or b) the Auto Prover does not have enough built-in theory to prove the obligation.

In the first case, you will need to rewrite your specification.

In the latter case, the way forward is to introduce a lemma, (use the "BProver" for this), and then prove the lemma off-line (by hand). Make sure you include your proof in your submission.

20050317:175949

Instructions for installing the BToolkit on your home Linux machine are now available

20050311:151831

The Coffee Club machine specifications used in lecture 4 have been added to the resources page (or see the lecture timetable)

Document History

This page maintained by John Hurst. Copyright Monash University Copyright Policy
Generated at 20090708:1404 from an XML file modified on 20070601:1125 Maintainer use only; not generally accessible: Local ServerWork ServerCSSE Server

845 accesses since 25 Feb 2007, HTML cache rendered at 20120210:1544