Code Engineering - File Organization Questions

[erwin_glassee]

Hi,

I'm an experienced CASE-tool user (Rose, MEGA, ...) but a novice to EA. Probably these are two simple questions for you guys.

1) If I create a model with a few packages and classes, then generate code with the "include all child packages" option from the top package, the classes don't appear in the dialog and nothing can be generated. If I transform to Java first within EA, then generate the code, I do see the classes and the code generates OK. Where's the difference in the class or package properties of both parts of the model and what do I have to do to generate the code directly from my model without the transformation step ?

2) I've read through the documentation and find that the code generator is designed around the common properties of the languages supported. Suppose I want to define a new language (I do, BTW), that has a different file and directory structure to its source code (in this case: a whole package structure including classes goes into a single file), how do I define the directories and files to be generated using the CTF, or is that not possible ? What alternatives do I have to get this done (perhaps using the document generator ? I'm willing to spend some effort, as this is a really important language for me) ? For information, reverse engineering is not needed, but forward engineering should be incremental (i.e. not overwrite any additions made to the generated code. It's OK to overwrite the previously generated code parts, though)

Thanks for any answers.

Erwin.

[Eve]

1) If I create a model with a few packages and classes, then generate code with the "include all child packages" option from the top package, the classes don't appear in the dialog and nothing can be generated. If I transform to Java first within EA, then generate the code, I do see the classes and the code generates OK. Where's the difference in the class or package properties of both parts of the model and what do I have to do to generate the code directly from my model without the transformation step ?

I'm guessing that there is no language defined for the classes in your model.  As a result EA doesn't add them to the list because it can't generate anything for them.  If this is the case you have two things that you will want to do.  Firstly, set the default language to your target language.  Second, reset the language of all your existing classes to the language you want to generate in.

Suppose I want to define a new language (I do, BTW), that has a different file and directory structure to its source code (in this case: a whole package structure including classes goes into a single file), how do I define the directories and files to be generated using the CTF, or is that not possible ? What alternatives do I have to get this done (perhaps using the document generator ? I'm willing to spend some effort, as this is a really important language for me) ?

The code tempates themselves can't specify the filenames/directory structure, the generate package will always create a file for every class.  (If you let it choose the filenames)  I've recommended to someone else who had a similar requirement of package to a file that the easiest thing to do would be write an addin.  If you're willing to put in the effort you could actually write an MDG addin so that it can can take control of code generation of a package and can provide filenames whenever a generation is done.

For information, reverse engineering is not needed, but forward engineering should be incremental (i.e. not overwrite any additions made to the generated code. It's OK to overwrite the previously generated code parts, though)

Here's a slight problem.  For languages that don't have a parser defined (and parsers currently can't be made by users) synchronisation can't be done.  The file is always completely overwritten.  Depending on the nature of your target language though you may be able to preserve the existing contents of the file using your addin.

[erwin_glassee]

Thanks Simon, for the swift and to the point answer.

[mikewhit]

Looks like you could have a post-EA step (Perl ...) to consolidate/merge the EA-generated files into the required framework.
That would also avoid EA overwrites since you are in charge of what happens to your result file(s).

Probably easier than writing an addin ... Paolo ?

[Eve]

Except that my answer to that last requirement wasn't very clear, a post-EA step is actually what I was suggesting.  I suggested an addin so that it could handle the MDG_PreGenerate and MDG_PostGenerate so that you don't have to remember to call something else.