Re: Lamport and toy languages

[phw <P.H.Welch@xxxxxxxxx>]

Paddy writes:

> As I understand it Oyvind, UML is a design syntax
> without a prescribed process. You use it as you
> wish! It's trying to be "all things to all men" as
> far as I can see. I haven't really formulated a
> good reason as yet to agree or disagree with this
> approach - but the world at large seems to like it!

We have been teaching UML to our first-year students as part of their
first course on OO and Java.  I wasn't actually teaching, but helped
supervise seminar groups.  These past few weeks, I *have* been teaching
some non-trivial Java case-studies with these students.

UML -- or that part of it that I know -- has `structure' diagrams and
`sequence' diagrams.  The `structure' diagrams tell us something about
what's in classes (fields and methods) and express the relationships
between classes (who extends/contains/calls whom); and the `sequence'
diagrams outline run-time actions.  The semantics (and, indeed, the
syntax) of it all is pretty much up to you -- at least, that seems to
be my understanding ...

Neither of these diagrams give me what I want.  The `structure' diagrams
are marginally useful -- but not half as useful as the network diagrams
we draw for occam (and, now, JavaPP) that show the relationships not
between classes but between the actual (live) objects.  [The UML structure
diagram for the dining philosophers would show a Philosopher class and
a Fork class and indicate that there is a many-many relationship between
them and that a Philospher contains (and calls) two Forks.  It doesn't
show 5 Philosphers, 5 Forks and their connectivity (which would be the
first diagram we draw when designing in occam) that shows the crucial
sharing of each Fork between two Philosphers].

The `sequence' diagrams are positively harmful.  They show the dynamic
calling patterns between objects.  I don't want to know that.  I just
want to know the dynamic behaviour of each (active) object on its own
-- how it interacts with its environment (via a channel and/or event
and/or bucket interface).  If I need to draw the combined execution
behaviour of multiple objects, I get a combinatorial explosion.

This gets back to the "composition" argument.  With a channel/event/bucket
interface, we get excellent de-coupling between processes (live objects).
We reason about each object in isolation in terms of that interface.
We reason about the composition of those objects (i.e. networks) without
having to think about the implementation of those objects.  We need to
impose various contraints on the specification of objects to be able to
do this.  Some we get for free with occam (like CREW sharing of data).
Some we may have to impose (like client-server, I/O-PAR etc. or if we
want a more dynamic form of CREW sharing than occam currently allows).

Getting those contraints right for conventional languages is hard.  With
JavaPP, it might just be possible -- but the discipline must be self-imposed.
With occam, much of that discipline is already present.

Adrain mentioned that Tony Hoare advocates the use of (raw) mathematics
for reasoning about systems and said this 25 years ago.  So, also, did
Dijsktra.  And, now, Lamport.

But I'm not convinced this is practical.  There are an awful lot of
programmers out there who would not have a clue about formal reasoning.
Maybe they should not be programming/designing but that's not the real
world.  What we need is a programming language / design method that
has the good mathematics pre-engineered into it.  Then, it becomes safe
for mortals.  occam is a good start but needs developing.  Java looks
possible ... just ... but we'll have to build (design) tools on top of
it to engineer in the good mathematics.  Nothing else looks in the
running ... hence, Lamport's article?

Peter.