RE: a few questions

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

Lawrence and all,

> Peter and all,
>    Bravo, Peter! The fact that OO hides necessary information
> means that, in the long run, it should be moved away from
> design toward accounting and marketing. Perhaps the CSP-OO
> hybrids should be seen as necessary accounting, marketing,
> documentation tools. After all, OO means "give the first
> formal parameter a new name - object" and organizing API
> listings according to their objects is very useful in tables
> of contents. It is also great in accounting to keep track of
> who is working on what, and people are used to the (false)
> 1-1 relationship, like "Excel is the program that works on
> .XLS files".
>    But (as I've seen recently looking at people's resumes
> at work) CS departments are unanimous in pretending that
> this is a DESIGN tool, which it isn't. Design means
> something that works, which requires ALL of Peter's
> component behavior, especially avoidance of "crosstalk".

I agree with you!

> Data flow diagrams are really STATE diagrams, with state
> changing ONLY when defined. Control-flow diagrams are
> GOTO's.

A control-flow diagram is a state machine with unlabeled (goto's) or labeled
(branches) transitions between states. Transitions are triggered by
expressions being true. A data-flow diagram represents a number of state
machines in parallel. Transitions may be triggered by events. Events can be
labeled as channel input, channel output, barrier sync, etc. This is part of
the UML/CSP model that we should publish.

>    I'm very encouraged by the discussed progress made using
> the hybrid tools. When everything that is an "atom" in a
> legitimate data flow diagram is well-defined and easy to
> understand, we will have won.
>    Larry Dickson

Our ?atom? is CSP that is well-defined ? so we should win! :-).

Gerald.