RE: a few questions

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

Peter,

Thanks for your great respond.

>
> I'm not yet sold on marrying CSP with OO.  JCSP and CTJ do a fine job and,
> so long as the world remains sold on OO, that's definitely a good line
> to peddle (I'm afraid it's the only line to peddle).  But deep down,
> I'm not happy with OO :-(

I agree with you!

Speaking about peddling, this sounds more like paddling:
The OO people are a floating community that doesn?t know the exact direction
they should paddle to get concurrency right. They are not lost on the open
sea, but they don?t know how to efficiently avoid the thunderstorms
(deadlock, liveness, ..) by paddling around them. They have to row with the
paddles they have got. We can offer them a compass (or guidelines) and a
turbo-jet motor on their not-ideal but popular boat :-).

(snip)

> So, I think those primary UML forms of diagram expose flaws in
> the concepts
> of OO.  OO systems are networks of global interactions - anything can
> interact with anything they can see and, usually, that's a lot more than
> the documentation tells us.  We have to stare at the source code to really
> find out.  OO "abstractions" hide these extended interactions - and that's
> definitely not the kind of information that needs to be hidden from the
> system builder trying to use the object.


I am not entirely pessimistic about the UML. The UML is considered to be a
third-generation modelling language providing common notations and a
rigorous semantic framework for writing software blueprints. The UML may be
used to visualize, specify, construct, and document the artefacts (analysis,
design, and implementation) of a software intensive system.
In the UML one can describe aspects of the software that cannot be described
by data-flow diagrams. For example, describing database-oriented programs in
the UML seems to be very effective using entity relation diagrams. Also,
data-flow diagrams can describe concurrency more efficiently than the UML.
Concurrency in the UML is a mess.

IMHO, software development starts with the analysis of task domains that
operate concurrently. This result in a network of communicating processes,
thus, a data-flow diagrams. THEN I might be interested in the objects I can
use to implement these processes. The UML can help me structuring the
sequential nodes in the network.

There are many problems with the UML. For example, in the UML design process
you start with classes or use cases. These more or less eliminate
concurrency from the start. We should use data-flow diagrams from the start
in the UML process.

Some applications are more concurrent than others. Your examples are highly
concurrent consisting of many small sequential processes in parallel.
Windows programs often contain few concurrent processes that are largely
sequential. A data-flow diagram shows use the degree of parallelism, which
the UML cannot do so easily.

>
> So, I don't want the Sequence diagrams to help me trace the run-time
> interactions between objects.  I want to understand an object in isolation
> and I can't.

Sequence diagrams should not be compared with data-flow diagrams. A sequence
diagram shows simple patterns of sequential interactions between objects.
You can show when methods call other methods on objects. For example, you
can describe the semantics of a channel when process objects call write or
read methods on the channel object. I don?t use sequence diagrams very
often, instead, reading the code is much more effective. Nevertheless, the
UML provides this facility.

(snip)
>
> I don't want class diagrams telling me about "has" and "uses"
> relationships!
> The former tells us nothing about the ways the objects we "have"
> fit together
> ... and the latter (which refer to external objects) shouldn't be there in
> the first place!  OO languages (like Java) give us no distinction anyway
> between these forms of relationship.

>From a process point of view you could be right, but from a (passive) object
point of view these relationships can be helpful. For example, multiplicity
and role-names tell something about the amount of objects involved and which
role they play in the relationship.

Question: Does a parallel/sequence construct (process) has a ?has?
relationship with its child processes?

I guess the answer is yes!

In the UML you could specify a ?uses? relationship between processes and for
example shared memory or a shared channel they use.

WARNING: please, don?t jump to the ceiling while you are reading this :-)?

Currently, a data-flow diagram shows communication between processes. It
shows the data dependencies between processes and the roles of the
processes, that?s all. Conceptually data-flow diagrams say nothing about
concurrency! You must specify or agree on what these processes (bubbles)
mean in relation to each other. Generally, we agree that they are in
parallel (default). But how do we specify alternative behaviour, sequential
behaviour, or prioritised behaviour in a data-flow diagram? So what we
exactly mean by a data-flow diagram should be specified.

We can do this and the UML can help us!

An extension to the UML/CSP model, which I haven't mentioned yet, allows us
to write the CSP process model, almost entirely graphically, in a data-flow
diagram. Thus, we can express PAR, ALT, SEQ, PRIPAR, and PRIALT in a
data-flow diagram in terms of relationships. This translates to the
mathematical CSP algebra.

For example, we can express (P ; ((R || S) [] (T |<| Q))) in a data-flow
diagram; where (T |<| Q) means process T has lower priority than process Q.
The relationships between the processes are the CSP operators and the
brackets().

I have talked with Jeremy about this at the WoTUG conference and he told me
contact the people of Formal Systems. They are looking for such a graphical
language. I would like to, but finishing my thesis has a higher priority
:-(.

The UML/CSP process model is (almost) independent of the class structure of
JCSP or CTJ :-). JCSP or CTJ can be used for their implementations. This
model allows mapping of the UML on data-flow diagrams and reverse. Also, the
model improves (fixes!) concurrency in the UML by providing consistencies
between the diagrams in the UML.

This stuff can be used for building tools. Erik Volkerink showed us an
example of a browser/folding concept that he presented at the last WoTUG
conference. Erik Volkerink provided great help.

As you see, this development is a breakthrough for the OO community -- in
particular the UML and Real-Time UML.

Gerald.