Monday
Aug302004

Remains of the Day by Kazuo Ishiguro

A beautiful, sad book.  I originally bought it because I liked the cover - a painting by Maeda Toshiro.  I am glad I didn't seen the film before I read the book though - I am sure it would have spoilt it for me.

Sunday
Aug292004

Cormorants

This morning I went for a walk with my daughter around the Reading University lakes and on the larger lake we saw a cormorant (Phalacrocorax carbo).  This is the first one I have ever seen on these lakes.  It was just standing in the middle of the lake, presumably on a submerged rock.  Initially it was hanging its wings out to dry --a pose characteristic of cormorants-- but later it just stood with wings folded away, looking around at any Canada geese and mallards that came near it.  It was still in the same place an hour later when we walked back along the other side of the lake. 

I have occasionally seen cormorants over  the river Kennet in Reading town centre as I walk to the railway station in the early mornings. They seemed to be patrolling up and down the river.  I have also seen them from the sea-front at Bournemouth, standing on the posts at the end of the groynes.  But the best views I have had of them have been on the lakes between Farnborough North station and Frimley as I walked to and from work.   In the spring of 2002 I used to regularly see three or four of them standing on the top of a tall tree on the Farnborough side of the largest lake.  Once I caught a glimpse of one of them swimming on one the smaller lakes, moving its head from side to side as if searching for fish.  But more often I would see them flying up from the water as if I had just disturbed them.  Flying they are similar in size to Canada geese but they seem more evenly balanced fore to aft.  Standing, swimming or flying, they are distinctly sinister looking, with their black bodies, lighter faces and long hooked beaks.  I suppose fish must think them sinister too.

Sunday
Aug292004

Object-Z is not a 'pure' Object Oriented Language

Alena Griffiths and Gordon Rose [in University of Queensland SVRC Technical Report 95-38, 1995, section 3.1.1] state:

The development of Object-Z as an extension of Z pollutes the "object-orientedness" of Object-Z insofar as it complicates the type structure with types other than classes.
By this, they presumably mean that the integers, sequences, cartesian products, and so on, of Z are not classes. Though this is rather obvious, it had not occurred to me until I read Griffiths and Rose's paper. It means that Object-Z is what Bertrand Meyer would call a hybrid 'object-based' language (like C++ and Ada) rather than a 'truly object-oriented' language like Smalltalk or Eiffel.  This then leads one to ask what a 'truly object-oriented' specification language would look like.  Presumably it would have all  the advantages of simplicity and orthogonality that Smalltalk and Eiffel have over C++ and Ada.  What we really need is a specification language in which the object oriented features arise naturally from the logic and are not cobbled on, almost as an after thought, as they are in Object-Z, Z++ and other object oriented specification languages.

Saturday
Aug282004

What do UML Class Diagrams mean?

Consider the following UML class diagram:

Class A inherits from class B.  Class A has association f directed towards class C

What does this diagram say? What does it mean?  What does it actually constrain? 

This is not just an idle philosophical question; it goes to the very root of the formal specification of software systems.  Get the answer to this wrong and you condemn yourself to being overwhelmed by unnecessary complexity when you try to reason about non-trivial systems.  Get it right and, while you will still have to deal with complexity, at least this will only be proportional to the inherent complexity of the system.

There is a lot of UML literature which purports to give a semantics to the UML.  However, these forms of semantics are either expressed in words, and are therefore ambiguous and imprecise, or else are minutely detailed mathematical models of box and arrow diagrams intended for the implementors of UML diagramming tools.  Both of these are inadequate if what you want to do is to reason about specifications.

I suggest that the semantics of the above diagram is best expressed using first-order predicate logic as follows:

∀a . a∈A ⇒ (a∈B ∧ f(a)∈C)

It would also be possible to express this in terms of the subset relationship and relational image:

A⊆B ∧ f(|A|)⊆C

However, I prefer to make the quantifier and its variable explicit (the latter is analogous to the implicit self variable in object oriented class definitions).  I also prefer to use Lamport's prefix layout for conjuctions and disjunctions.  This is the way I would normally write this specification:

∀a . a∈A ⇒
    ∧ a∈B
    ∧ f(a)∈C

Note that this does not require that any A's (or B's or C's) actually exist.  It only requires that if they do then they must be constrained in the above way (ie: they must also be members of B, and when function f is applied to them it must return a member of C).

Note also that the above specification is extendible.  The use of implication allows us to later add further constraints.  This is consistent with the idea that UML diagrams are partial views of the complete system.

Also, the specification says nothing about the value returned by the function f when it is applied to a value that is not in A.  In that case the returned value is unconstrained (for example, we cannot say whether it is in C or not in C).

Friday
Aug272004

HTML and All That

I am currently reading Designing with Web Standards by Jeffrey Zeldman (New Riders, 2003).  After reading part I of this book I feel fully justified in my long-held aversion to web programming.  Even now it is apparently only possible to get reasonably consistent results across all browsers by resorting to ugly hacks. 

The immaturity of the whole field reminds me of programming the half-baked microcomputer BASIC interpreters of the early 1980s: some things that you want to do are either impossible or else can only be done in an extremely inefficient way.  Well known principles such as "Keep each item of information in one and only one place" and "Use symbolic names for numerical constants" are just ignored.  However, I suppose this immaturity is only to be expected in a field that has gone through an exponential growth phase during which new people have been coming into the field faster than good programming principles spread.

Zeldman's book provides a good account of both the horrors and the W3C's proposed cures and gives lots of practical examples.  However, it is not an introductory book: it assumes a familiarity with HTML, XHTML and CSS.