31 Songs by Nick Hornby

In February 2003 I broke my ankle while taking a short cut across the Inner Distribution Road in Reading and was off work for two months.  After the first week of agony, the pain subsided and my life then became a battle against boredom and the wasting away of my leg muscles.  To combat the the latter I would lie on my back and waggle my legs in the air as if I was walking; to combat boredom I would listen to the radio.  

One of the highlights of that time was a Radio 4 serialization of readings by Nick Hornby from his book 31 Songs.  This was broadcast in the mornings, just after my wife and daughter had left the flat.  I would get dressed, stagger through to the kitchen to make myself a cup of coffee (a non-trivial operation on crutches), lean my crutches against the wall and sit down at the table with my ankle propped up on a stool.  And then, because it had taken so much effort, I would sit there for the next hour or so listening to the radio.  And during one week, each morning this down-beat sounding middle-aged man would come on and talk for 15 minutes about some pop song that he liked.  Most of the songs he talked about I had not heard of but, in spite of that, I began to look forward to hearing him.  There is a fascination in listening to someone enthuse knowledgeably about something, no matter how trivial that something might be.

Well, in time my ankle mended, I learned to walk again, went back to work and my life returned to normal.  Then, a few months ago, I was wandering through Waterstone's one Saturday morning when the cover of 31 Songs caught my eye.  I bought a copy there and then, and read it over the next few days.  And yes, it was enjoyable, but not as enjoyable as listening to the radio programs when I was stuck in our flat with nothing else to do.  And no, I have not bought any CD's as a result of reading this book, but  I did use Google to find a free downloadable copy of Royksopp's Night Out.


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.



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.


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.


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).