Re: 'withing' problem [code generation]

[Mark Johnson <Mark_H_Johnson@Raytheon.com>]

Stephen Leake wrote:

> Mark Johnson <Mark_H_Johnson@Raytheon.com> writes:
>
> > Matthew Heaney wrote:
> > [snip]
>
> >  - 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.
>

Exactly the reason I mentioned both solutions. If you *really care* about the
structure of the packages, allow the author to specify that certain rules to be
applied. The annotation I mentioned becomes a part of the standard you apply when
using UML. I don't see why you consider that "manual" - the computer does everything
based on your (now more complete) specification of the solution.

I thought about this a little last night and you have the circular dependency problem
in C if you are not careful. You get an infinite loop in the C preprocessor if
doctor.h includes patient.h and vice versa. Almost everybody codes their header files
to have some #ifundef that encloses the body of the header file. That way, each
header is expanded only once. Even with that, you could have a subtle bug due to the
different order of expansion - doctor before patient or patient before doctor. Icky,
nasty problems to find and fix..


> [snip - description of execution order algorithm]

> > 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.

Of course there were parallel paths. All the cautions you mentioned about small
changes on the drawing making big changes in the way the code executed were true. Add
a single line on a drawing and a block that was executing 4 steps later is now
executing two steps previous. Even more - based on which inputs came in, the blocks
executed in a different order.

So what. We kept focused on the problem we were trying to solve and did not care so
much on how beautiful or ugly the generated code was. A common problem in simulators
is instability in the model due to excessive latency - our system never had that
problem because the solution minimized latency in all cases.

  --Mark