EA Extension Best CM Practices

[Uffe]

Hi all,


I'm wondering if anyone's got any best practices to share on how to CM EA extensions. I'm talking primarily about UML profiles, Code and Transformation Templates, and also code written against the Automation Interface.

I'm thinking that Automation Interface code can be handled in the regular CM system, as can the UML profiles since they're modelled. But what about the Templates?

And how are these things best distributed to users? Turned into Add-Ins and sent out as essentially binary installation packs?

Any thoughts appreciated. I'm not actually a toolsmith myself, nor a CM dude, and the company I work for doesn't have a great deal of UML experience. In other words, don't be afraid to give me even the really obvious stuff, hokay?

Cheers,


/Uffe

[Krzysztof Swiatkowski]

If you have UML Profiles, Code templates and transformation templates then perhaps it would be best if you combine them into single MDG Technology. This gives you a xml file that can be distributed via URL (Settings>MDG Technologies>>[Advanced...]) so you can CM the MDG xml file and also changes to it will be available to all that configured the xml next time they load the file.

HTH
Kris

[Uffe]

Hi again,


Thanks for that. A problem I've got is that the individual parts of an MDG Technology seem to reside within an EA project itself, rather than in a model.
This in turn means that they're outside the normal version control system in EA. I'm talking about MDA Transform and Code Generation templates, etc - in fact, I think only UML Profiles are modelled.
Also, if you import an MDG Technology, the UML Profiles aren't available as a UML model (which means you can't make changes to the Profiles), and the "no change" markers on the MDA / Code Templates will be in reference to the version you've imported, not to the defaults in EA.
Both these are what you want in deployment, but not in development of the MDG Technology.
At the same time, the UML models for a set of Profiles within an MDG Technology tend to be very small, and will typically have dependencies to other parts of the MDG Technology and so should not be version-controlled in isolation from those other parts.

So I'm currently looking at something along the following lines:

• An MDG Technology is maintained within a dedicated project (.EAP file)
• An MDG Technology is version-controlled by checking in/out its .EAP file only (possibly the .MTS file as well)
• The individual XML files for the Profiles are not version-controlled separately
• The XML file for the MDG Technology is not version-controlled separately
• MDG Technology XML files are deployed to a company-wide file area where EA is configured to look for them at startup
• Version identities within the MDG Technology XML file (as specified when generating the MDG Technology file) must be maintained manually; there is no support for connecting them to the CM system

This sound about right?


/Uffe