Sparx Systems Forum

Enterprise Architect => Suggestions and Requests => Topic started by: Paolo F Cantoni on February 21, 2007, 03:46:44 am

Title: VIT: Model<->Code Commentary & Metadata
Post by: Paolo F Cantoni on February 21, 2007, 03:46:44 am
This is a VIT - A very important Topic (in my judgement) so I thought I'd annotate it appropriately.

There have been some postings and even whole topics in the forum recently regarding the transmission of commentary between the model and code.

Our situation (here at [size=13]Ripple[/size] (http://www.Ripple-Systems.com)) is somewhat unique but it may have some interesting bearing on the nature of the problem.  We are now a pure design shop.  We create designs and others implement them.  We (as part of our software auditing and accreditation process) have to review the generated code for conformance to our design.  From the design one can produce the frameworks for the code.  The designer may provide commentary in the model (typically via the Notes property of the EAThing - EAObject or EAFeature).  The coder then adds the code and additional commentary directly related to the coding they have performed.

Many posters have noted that EA makes a decent fist of attempting to relate commentary to EAThings. However, it does make mistakes and as me more inexorably toward full Model Driven Development (MDD) this needs to be significantly improved.

However, not withstanding this problem (that of assigning commentary to EAThings) there's the additional problem of sorting out commentary that needs to be transported to/from the EAThing and the commentary that doesn't.

For example, as we refactor/fix our design, we may change the version number of the EAThing and the associated commentary.  If we synchronize the model with the code, we really need the version number to be transmitted to the code so that the coder can see that the version of the code no longer conforms to the version of the model EAThing.  There is a whole set of metadata held within the EAThing that really needs to be visible in the associated code.

Similarly, if the coder finds a problem with our design, it would be really useful for the coder to change the metadata in the code text and for the synchronization process to feed that back to model.

I have some ideas on this subject, but before I introduce them I thought I'd see what people thought, in general, about this subject.  Is it too specialised to our situation, or is it of more general applicability?

Thoughts?  Input?

Paolo