Re: 'withing' problem [code generation]

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

Mark Johnson <Mark_H_Johnson@Raytheon.com> writes:

> Matthew Heaney wrote:
> 
> > "Simon Wright" <simon@pushface.org> wrote in message
> > news:x7vd72gi0zm.fsf@smaug.pushface.org...
> > > If there is a real-world circularity between doctor and patient, and
> > > our software engineering tools can't cope with it, it's the tools that
> > > have failed and not the real world!
> > [snip]
> > Simon argued that my solution was inadequate, because there was no simple
> > way to a automatically generate my code from the UML diagram.
> 
> Having done code generation from diagrams before - I guess I don't understand
> why there is no "simple way to automatically generate code" in this case. I see
> at least two "simple solutions" that are not mutually exclusive:
>  - annotate the drawing to "break the circular dependency here"

This is not "automatic", it's "manual". That's the point.

>  - recognize patterns of circular dependencies and generate code
> that automatically generates the new packages (and report such
> changes to the user)

This may be possible. The problem is that the automatic recogition of
patterns may be unstable; small changes in the UML model may make
large changes in the new packages. 

For example, assume your UML model has the Doctor -> Patient
circularity. The first time you generate code, it may decide to break
the circularity by using a forward declaration for Doctor. Now you
tweak the model a bit, and it decides to forward declare Patient. Not
a Good Thing!

The point here is that extending Ada with "with type" allows some
"circularities" to be directly represented, without any user or tool
interaction.

> We were taking data flow and control flow diagrams to generate the
> code for an aircraft simulator. Loops appeared all over the place as
> systems interact with each other. However, we had to "pick one" to
> run first (on a single CPU). The code generator sorted the blocks
> based on how "close" the block was to an external input. Direct
> connections were "1", blocks connected to "1's" were "2", and so on.
> The precise order the blocks executed was deferred to run time - we
> ran all blocks directly connected to inputs that *changed* first,
> then all blocks connected to first level outputs, and so on using
> the order described above. That tended to minimize latency in our
> system - which we considered a *good thing*.

This sounds like it could be a stable algorithm, as long as there are
not parallel paths from the first block to the nth block.

-- 
-- Stephe