Make EA<->C Code synchronization more "intelligent"?

[EAabecedarian]

To get some link between a software model and the C code, my idea is to model interfaces and classes and generate *.h and *.c files just containing the declarations and function definitions with empty bodies.
The implementation of the functions shall be done by "classic" programming using that generated skeleton plus additional information from some specification (which also could be a EA diagram or state machine or whatever).

My first experiments on this show that "synchronization" between model and code works this way that previously generated code is not touched but only additional model elements are added.
This means also that changing existing elements simply adds new code to reflect the change but keeps the already existing code.

For instance:
From the very basic model below three files "Class A.c", "Class A.h" and "Interface1.h" are generated and they look perfectly fine.


If I add a second operation "A_operation_2" to Class A, its declaration is added as expected.
Now I change "A_operation_2" to take an int parameter "a". The "Class A.h" then has two declarations for operation "A_operation_2":

void A_operation_2();
void A_operation_2(int a);

Also, the implementation of "A_operation_2(int a)" is added to "Class A.c".
What I would like: Just add the new parameter to the existing generated code.

When removing A_operation_2(int a) from "Class A" and doing a new generation, the files don't change at all.
What I would like: Remove A_operation_2(int a) declaration and definition from generated code.

I know that "Overwrite" instead of "Synchronize" would solve that problem, but this would also overwrite any implementation done e.g. in "A_operation_2"'s body after the function parameter has been added.

Is there a way to make code generation more intelligent, i.e. to check for the same name(s) and update only the function declarations and headers?
Or is there a better strategy to force the developers to stick to the model but not burden them the load of dealing with EA for every single detail in code?

Best regards,

EAabecedarian

[qwerty]

Nothing you would like to hear, but I tell it anyway: code generation is a Fata Morgana. It does not bring any value to generate code. Your coders can do that easily and adding the flesh is anyway the most costly part. If you change your model that often so a generation will pay out, then you will hardly keep your coders.

q.

[EAabecedarian]

Nothing you would like to hear, but I tell it anyway: code generation is a Fata Morgana. It does not bring any value to generate code.

q.

Thanks for your input. Maybe you are right. But what I've experienced is that once the SW design is done (if it is at all), developers don't really care any longer.
However, there usually isn't just one iteration. In the end you have a code that doesn't match the design and/or architecture because of changed parameters, added or deleted functions, etc.
Code review is tedious and nobody has really time for it.
Of course, discipline and a dedicated software architect having time to track would help.
But I thought it would be beneficial if there could be at least some automated process for all that interface stuff:
Let the code generator run, and if afterwards the build won't work anymore the developer MUST take care of updating the design - or stick to it.

BR,

EAabecedarian

[Geert Bellekens]

To key to this, in my opinion is to not keep the same information in multiple places.

There is little added value in having a model at the same abstraction level of the code. It's the exact same information, but in two places and two different formats.

What you want to model is those the information you can't get from reading the code.

- Business Models
- Logical data model
- Use Cases
- Architecture

These models are often much more stable than the code, but in order to keep things consistent, you need to check your processes.
Each change should pass through the hands of the Business/Function analyst and Architect. They have the responsibility to update their part of the model is required.
Only then the code should be changed.

All these roles could be played by the same person. You don't necessarily need different people.

Geert

[Takeshi K]

Hello EAabecedarian,

The following option might be help in your situation.

In the User Preferences, Attribute/Operations Group, enable 'On forward synch, prompt to delete code features not in model'

Since EA does not add tool-specific marks in source files, EA cannot distinguish changes from additions/deletions. By enabling this option, EA asks you when there are unknown functions in the codes. You can select changed functions, and specify them as deleted.

HTH,

[EAabecedarian]

Hi Takeshi.

In the User Preferences, Attribute/Operations Group, enable 'On forward synch, prompt to delete code features not in model'

Thanks! At the first glance this seems to solve my problem. Even existing code in the function body is kept.

Since EA does not add tool-specific marks in source files, EA cannot distinguish changes from additions/deletions.

Yes, but it could do - and when checking the option you mentioned it obviously does - some "intelligent" code parsing.

BR,

EAabecedarian

[qwerty]

One more historical remark: around 2000 I used RR to generate code. They did put a lot of tags (within comments) in the code and used that to synch changes. Of course you better left these tags untouched or you were in trouble. At that time IDEs were not that common so I edited the code within RR. That worked. Somehow. But with todays IDEs it would be just a PITA. Some of the IDEs offer UML diagram creation, but thise simply suck (if not being wrong in many places). UML tools (like EA) on the other hand are a joke when it comes to IDEs capabilities. So what I learned: there's a media break between UML (which is excellent to model customer views up to a technical design) and IDEs (which support coding in all directions like code intellisense, debugging, etc.). Give the modelers/architects a good UML tool and gibe the coders a good IDE. And the real issue to get the technical part (SDs upward) being documented by coders EASILY. EA is not the best for the latter, unfortunately. They better like to implement a new gizmo each release which usually is half baken or completely useless (rare case where they are actually useful).

Enough for today.

q.

[EAabecedarian]

So what I learned: there's a media break between UML (which is excellent to model customer views up to a technical design) and IDEs (which support coding in all directions like code intellisense, debugging, etc.). Give the modelers/architects a good UML tool and gibe the coders a good IDE. And the real issue to get the technical part (SDs upward) being documented by coders EASILY. EA is not the best for the latter, unfortunately.

I agree that UML (EA, respectively) is too often not the best way for the detailed design part, i.e. to describe how the code shall actually work.
But somehow I have to ensure "traceability" between high level requirement, architecture, design and eventually the code.
Of course, "code reviews" are one way to catch the "media break" you mentioned, and they are inevitable anyway wherever manual coding is done.
Yet I'm still not convinced that - at least for the interfaces part - code generation brings no benefit in this point (and it seems that with EA there doesn't have to be tags or other fancy stuff).
Yes, this is just a small part and can be easily done during code review, but whatever can be automated eliminates human error (unless the automation process is errorneous :-D ) .
Anyway, I appreciate your and Geert's comments and will rethink my idea :-)

BR,

EAabecedarian

[Geert Bellekens]

The world is indeed not black and white.
There are parts where code generation can be beneficial.

I've seen quite a few successes when it comes to generating XSD's.
And I know one client that successfully generates it's database structure from the model.

When this works it's often for small, strictly defined parts of the code, where 100% generation can be achieved.
The moment you can only reach 99,9% generation, and you have to do some kind of roundtrip engineering, you are setting yourself up for a world of problems.

Geert