C Gode Generation, handling private class elements

[g.makulik]

Hi all,

IMHO the way EA renders certain UML elements to C-code representation (without using the OOP support option) is wrong:

• private (static) attributes/operations:
  private features should be really private, that means for C that they should have the 'static' keyword applied on compilation unit level. Otherwise the C compiler will warn about usage of an element defined without static but linking isn't prohibited. May be there's an intend with this implementation for enabling protected elements, but it should still be distinguished.
  
  
• public static attributes (and initialization):
  public (static) attributes should render an 'extern' declaration in the header file and a (non static!) definition including initialization arguments (from initial value) in the source.
  

I've tried to provide remedy on these flaws changing the standard C code generation templates, but failed so far.

Thoughts, opinions or workarounds anyone?

Best regards,
Günther

[g.makulik]

Bump

Doesn't really anyone have an opinion about this??

I know there must be a number of people around here that work with C language models and reverse engineering.

Regards,
Günther

[Helmut Ortmann]

Hi Günther,

I also stumbled about the problem and posted http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1357804524

I think about developing two scripts to handle the problem.

The ideas behind the two scripts are:

Generate:
Two or so changes in the template to handle extern, default, or so.

• Duplicate the attribute as private
• Run the original EA script
• Remove duplicate attribute

The idea behind it is:
The public attribute generates the *.h entry with EA standard
(extern, no default,..) generation.
The private attribute generates the *.c entry with EA standard generation.

Synchronize:

• Run the original EA script
• Remove duplicate attributes

May be SPARX provide a solution.

I appreciate any suggestion.

Kind regards,

Helmut

[g.makulik]

Hi Helmut,

When I was bumping this question I've been expecting you (amongst others) to contribute to the discussion. Nice to see this had worked so far  8-).

I'm currently writing a guide for C/C++ code generation techniques and develop an MDG technology extension and AddIn to support workarounds for the EA standard's flaws.

Amongst other stuff I've come up with a (rough) solution for this particular problem. My approach is to

• Declare a stereotype for <<extern>> attributes and operations
• Provide stereotyped code generation templates for these attributes
• Declare (common) macros for the excess UML attribute definitions generated by EA on code synchronization
• Add these macros to EA's (ignored) 'Settings>Preprocessor Macros ...' list

This approach has still some problems though with code synchronization (e.g. initialization values are lost in UML), and the overall project is far from being complete. Also I don't like the use of such macros, since they make the resulting code less readable/understandable.

UPDATE: Here are some discussions about alternatives.

But I'm willing to give you the material I have so far and would appreciate having you to participate in this project (Just as reviewer, contributor, user or whatever is your preferred role). I'll send this to the eMail address you have published in your profile.

Best regards,
Günther