Re: genesis design

Daniel Nouri wrote:

> So with pyparser.py we really have two kinds of readers: One for the UML
> model and one for Python source code:
> 
> 1) UML -> internal model
> 2) Python code -> ?
> 
> I would suggest to make the second kind of reader one that interprets
> the code and creates an internal model as well.

The current (archgenxml) approach is that the output generator just 
queries for the existence of methods in the parsed files. And for some 
protected sections.

It only makes sense to put the parsed code into the internal model if we 
don't want the output model to be able to make a choice about inclusion. 
I don't know yet.

> We need some way to
> find out if we want to keep e.g. a certain method of a class.  Currently
> in ArchGenXML this works with marker comments (##code-section).

Methods are always preserved if available. Because that's where most of 
the action is. Marker comments are for inserting an extra import 
statement in the header and so.

> 4) internal model -> UML
> 
> This is probably one of the most difficult parts, because we need to
> preserve visual properties in the XMI, like the coordinates of the UML
> elements.
> 
> However this would allow us to generate UML models from source code,
> which would rock.

And which would be bloody hard. But I agree that you've at least got a 
fighting chance with genesis' architecture ;-)

>>Not 100%. It's important to see this as a two-step process. Stereotypes
>>only *indicate* something. "This is not a normal class, this is a
>>Membrane class". The internalmodel ends up giving this item a different
>>interface.
> 
> 
> I don't see how the internal model would know which interface to apply?

That part of the code is actually implemented and working :-)

>>Step two, the behaviour, has to be handled by the
>>generator/tranformations. If there's no adapter to handle the special
>>interface, handling will just fall back to that of a normal class (for
>>instance).
> 
> If there's no adapter, this should probably raise TypeError, because I
> think this should be treated as an error, really.

No. That goes against the adaptor architecture. Say you've used a 
stereotype to get special handling in one part of the generation step. 
That does not mean that you don't want to use more generic adapters in 
other parts of the generation process. That's the great strength of the 
approach, imho.

> Could you please explain what exactly the profile configures if the
> generator doesn't even read it.

The profiles make sure the internal model spits out 
INouriSpecialClass-marked classes when desired. The generator doesn't 
care how that class got that marker interface, it just looks up the best 
possible adapter for it.

Loose coupling!

>>Jens had an idea of having just one very generic class for the internal
>>model instead of the "current" UML-like set of classes. I thought it to
>>be a bad idea, but perhaps it's not so bad after all. So it might change
>>:-) Perhaps the internal model will only be a reasonably thin adapter
>>for a suitable external UML model reader.
> 
> Well, my opinion is that the internal model should really represent OO
> programs.

It sounds too big to me. The internal model is just a tiny layer between 
what gets put into it and the transformation/generation step that pulls 
stuff out. It's the pluggable component architecture adapter magic 
that'll have to pull the most weight here. The internal model should 
remain thin. (Hey, Jens wanted a one-class internal model - which might 
be a good idea after all).

Reinout

-- 
Reinout van Rees                       r.van.rees @ zestsoftware.nl
http://vanrees.org/weblog/                  http://zestsoftware.nl/
"Military engineers build missiles. Civil engineers build targets."



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642