> -----Original Message-----
> From: Simon Wright
> > From: [log in to unmask]
> > My interest lies in being able to generate some of the code and
> > being able to do the full round-trip engineering. We do embedded
> > systems and the capabilities of Rose for generating any code aren't
> > what we'd like.
> The main difficulty as I see it with closed code generators is that
> you need a lot of access to the internals to be able to cope with new
> generation-time options (if the model is like /this/, generate code
> like /that/).
> Rose/Ada doesn't give you a great deal of control (except through an
> amazing dialog box with more options than you could shake a stick at),
> and requires you to have a class in your model if you want a code
> package generated (so you get loads of support cruft in the design
> model, instantiations of generic containers etc). This makes reverse
> engineering difficult (even if Rose/Ada supported it) (even if it were
> a Good Thing).
Rose gives you a great deal of control, hence the dialog box with
the multitude of options.
I think the real challenge is that for any given design model there
exists many possible mappings to correct and valid source code in
a given language.
Rose/Ada as it implements one such mapping, with a variety of options
to control that mapping.
Rose also has it's own built in scripting language with complete access
to the model to permit you to write your own CG or RE tool.
The problem gets more complex when you take into account the desire
to reverse engineer source into a design model (a challenging problem).
The flexibility of most programming languages is such that it is
easy to lose information when translating back to a design langauge.
It gets more challenging when you want to round-trip code as then both
the code generator and the reverse engineering/analysis tool must be
very close and in-synch to be at all useful.