RE: Java Live | January 9, 2001

["Gerald H. Hilderink" <g.h.hilderink@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: P.H.Welch [mailto:P.H.Welch@xxxxxxxxx]
> Sent: Friday 26 January 2001 19:46 PM
> To: g.h.hilderink@xxxxxxxxxxxxx
> Subject: RE: Java Live | January 9, 2001
>
>
>
> Hi Gerald,
>
> > I am working on a UML/CSP model, which clarifies the ideas behind
> > the occam/CSP model in their own way of thinking. The result of
> this work
> > is astonishing, it improves concurrency in the UML in an elegant way,
> > it also formalises concurrency in the UML, and code-generation becomes
> > very straightforward. This takes at least three flies in one strke :-).
> > Oh yes, it also shows that the concepts of CSP are very very OO.
> > Oops, another fly killed! :-).
>
> Excellent!  I've also been pretty puzzled by UML.  Its diagrams never
> tell me the key things I need.  For occam/CSP/JCSP/CTJ, all I've ever
> drawn are the data-flow network diagrams - layers of them.  It shows us
> all the players in the system and how they relate to each other.  And it
> maps 1-1 with the CSP code structures we write - in whatever language.
>
> Is it those diagrams you are adding into UML?  An excellent trick!  Next
> time I show such things, I shall claim that they're just UML and all the
> OO people will sit up nicely ;-)
>
> Thanks,
>
> Peter.

Hi Peter,

The UML does not really capture data-flow modelling. In fact, the UML
totally moved away from data-flow modelling. The reason is that data-flow
does not easily match with method-calls, inheritance, polymorphism, and the
other OO stuff.

One could create classes in the UML in order to build data-flow elements.
JCSP and CTJ packages provide such classes. The UML can be used to describe
these packages. These packages could be used to model data-flow oriented
software in the UML. This may result in a good design, but this does not
really improve concurrency in the UML.

The UML specifies certain concurrency elements, such as forks, joins,
signals and events. The semantics of these elements are defined in such a
way that makes designing concurrent software clumsy and makes understanding
of the behaviour of the software hard. These elements introduce unnecessary
complexity in the UML. Another important problem I experience with the UML
is that these concurrency elements provide poor consistency between the
various dynamic diagrams.

The semantics of events in the UML is defined as an occurrence in time and
space. Events are represented by method-calls, conditions, or signals. The
effect is that the semantics of synchronization on these events are all
different. In fact, an event in the UML does NOT capture occurrence in time
and space, but instead, an event is represented as a message as a result of
the occurrence. Messages are checked in space separate from the real
occurrence in time. This is not really an event, is it? The notion of events
as defined in the CSP is most close to the reality.

I have modified the semantics of events in the UML that introduce:
termination events, communication events, timeout events, exception events,
barrier events, which involves processes. These events are traceable and
observable.

Furthermore, I have found an elegant way to introduce the CSP(P) operators
in the UML, such as the PAR, SEQ, ALT, PRI ALT (or ALT PRI), the PRI PAR (or
PAR PRI). New is the CSP interrupt operator for interrupting processes on
the occurrence of exceptions (this models throw-try-catch constructs, which
the UML cannot :-)). Symbols for channel communication, call-channel
communication, and barrier synchronization are described based on existing
symbols in the UML.

All the constructs and symbols are (almost) independent of the packages JCSP
and CTJ. JCSP and CTJ can be used to implement the constructs and symbols.

This work improves the concurrency model in the UML in the following ways:
- CSP provides a sound foundation with rules and guidelines that can be
applied to the UML;
- the notions of events now provide consistency all over the diagrams
  (static and dynamic) in the UML;
- the UML now instantly captures priorities, timeouts, and exceptions;
- data-flow network diagrams can be mapped on the UML and reverse;
- the CSP symbols and constructs provide sufficient information for
  identifying processes during forward and reverse engineering;
- code generation of parallel programs is clean and straightforward;
- the CSP/UML model its elegant, simple, reliable, efficient, fast AND
  real-time.

Oh man, I love the CSP paradigm!

Extending the UML was necessary in order to get the best results. The
challenge (or problem) would be acceptance by the OMG people. We could
submit this work for the upcoming UML 2.0. Unfortunately, I don?t have the
time and money to do this on my own :-(. Suggestions?

Or a chapter in the book!

I can make a draft of the CSP/UML model available for discussion. It's
called "The UML in the light of CSP".

Oh, Øyvind, this proposal may glue with XML and SDL.

Gerald.