[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: a few questions
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
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! :-).