Enterprise Architect

[olafk]

Thomas,

I am having the exact same problem. Same version of EA, same version of AndroMDA.

Am also talking to the EA forums... and might try my luck with the EA support people.

Did ever work it out? How far did you get? And, if so, could you post please?

ciao,
Olaf.

[schmidt]

Hi Olaf,

I does not found a Andromda-Profile for EA.
I used SchemaToXMI to expand a database schema to an XMI-File and import this with references, stereotypes and tagged values into EA.
Then I defined some tagged values and stereotypes manually.

Thats all.
I dont found a way to import the Profile in EA.

Thomas

[olafk]

Well, Thomas, you're not very encouraging How can EA continue to claim they integrate with AndroMDA - when the most basic thing doesn't even quite work! Or, is andromda so MagicDraw-centric that their exported profile has some quirk in it?

Now, back to your thought on back-ending the whole thing: importing some database schema... So, you ended up with the stereotypes that you needed that way? A (pretty-much) completed set of stereotypes? Or only those that are relevant to DDL-generation?

And, more interestingly, how do they end up in EA? Probably not as a UML Profile, I assume?

At the moment I am more interested in forward-generating my services into EJB/POJO's. So, would such schema import give (say) the <<Service>> stereotype? (I'll have to worry about the persistence side-of-things at some later stage...)

Or is this what you built up manually?

[wouter.zoons]

also see following threads: http://forum.andromda.org/viewtopic.php?p=3917
http://forum.andromda.org/viewtopic.php?t=674

[schmidt]

Sorry, I cant help you. Most time I work with MagicDraw. Only one business partner used EA. He only need AndroMDA to generate a simple DAO-Interface and the Hibernate-files. That's why we need only a small set of sterotypes and tagged values. For this reason I decided for this simple way.

My advice:
1. if possible use MagicDraw
2. if EA: create the datatypes and needed sterotypes/tagged values manually in an EA-Profile (I did it)

Anybody could implements a converter from XMI to EA-Profile-XML, maybe.
I can mail you my simple AndroMDA-EA-Profile. (6 stereotypes with tagged values for the hibernate-cartridge)

BTW: I use the actual EA-Version 5.00.767. Older Versions had a bug when importing XMI.

Thomas

[wouter.zoons]

could you please create an issue in JIRA and attach that small profile to it, perhaps I'll be able to improve compatiblity, we should be able to use XSLT to generate an EA profile from the MagicDraw one .. I'll ask for a EA license in order to get the job done, if they refuse I have no legal way of ensuring compatibility

thanks

ps: file the issue in the 'Miscellaneous' subproject

[olafk]

Wouter,

Here's a link to the (hopefully public) web-pages for EA --- and how they expect their profiles to look. (Plus it gives some examples...)
http://www.sparxsystems.com.au/EAUserGuide/index.html?profilereferences.htm

And, clearly, they're using their own sweet thing. Don't know why they ever claimed they were "compatible" with AndroMDA. But there you go...

Now, it's still not clear to me how the (extra UML) datatypes can be imported in a vendor-neutral manner. They don't seem to be part of the EA profile... (maybe Thomas can comment here?)

Double whammy for me: I am somewhat new to EA as well

I'll keep trying... I have also contacted EA support. I might just be doing something obvious wrong here... Watch this space...

cheers,
-olaf.

[schmidt]

EA save datatypes in the project files (eap).

So you must define the datatypes manually in a basic eap-Project (EABase.eap) and save it under AndroMDABase.eap
At all new AndroMDA Projects you start select this AndroMDABase.eap as "Model-Project". If do not you must type the datatypes every time you made a new project.
Ideally AndroMDA should deliver a base EA project with all datatypes and a reference to AndroMDA-profile.

Thomas

[wouter.zoons]

Thomas,

can you attach such a complete EA profile to this issue in JIRA: MISC-35

that way it will be easier for me to provide it to our users, I see you already attached something, but I'm not sure if it's the same thing since it seems to be a rather small file

[olafk]

Let me add to that...

* The EA tool uses a MS Access database as it tool repository; such repositories are known as .eap files.
* Any existing repository (i.e. any .eap file) can serve as a "seed" for a new project; Thomas (and EA) terms this a "model project".
* Thomas confirmed that datatypes are not maintained as part of a profile - but are managed as integral part of the repository. However, once entered, they can be exported (into an xml file of proprietary format) --- and, therefore, be re-imported into some other EA repository.
* The EA profille Thomas attached to the JIRA issue shows the beginning of an AndroMDA profile; as mentioned previously, the complete spec for EA profiles can be found here: http://www.sparxsystems.com.au/EAUserGuide/index.html?profilereferences.htm

So, it seems, we have the following choices to provide to EA users:
1) the ea-andromda-profile.xml file --- generated by Wouter from the current (MagicDraw) profile.xml file; plus an (exported) ea-andromda-datatypes.xml file.
The datatypes file I would be happy enough to help and expand; thank you Thomas for a good start on that.
2) a "seed" EA tool repository (i.e. AndroMDA.eap) --- containing (i.e. already imported) both the set of datatypes as well as the (Wouter-generated) profile.

I would prefer choice 1) --- as it seems more flexible and allows EA users to assemble their model any which way. Also, the two files can be prepared without the need for the actual EA tool. I am happy to assist with either; in fact, I will have to do something similar for my users anyway.

Wouter, any indication as to when you might have a chance to look at generating such a profile?

[wouter.zoons]

Wouter, any indication as to when you might have a chance to look at generating such a profile?

well, I think I can manage to get it working pretty quickly; the problem is that I don't have a license for EA so I can't test it

anyway, this weekend I will download the trial edition (if they have that) if they don't want to give me a free license to add AndroMDA support for this tool

[schmidt]

EnterpriseArchitect safe the projects into a Microsoft-Access-DB?!
Therefore the project-files are so large.

Now I understand.

[olafk]

Well, I was busy yesterday (Friday) fixing up - i.e. completing - the list of datatypes which, as discussed above, need to be loaded independently into the EA repository.

The one thing I am not sure about (I don't quite know exactly what EA is up to...) is what seems to me "generalization" relationships between some of the types. The XML in andromda-profile.xml is not exactly easy to appreciate - given the uid's and all.

In two words, Wouter, what is being expressed there - are any of those datatype generalizations requisite to the proper workings of AndroMDA?

Re. testing of the profile that you generate... I have a license available (at work), I am happy to test. Except, my expertise with AndroMDA is close to zero... BUT to test whether a profile appears, whether it appears correctly and whether stereotypes, tagged values etc. are usable should be easy enough to ascertain. Certainly, I am in the middle of a project that will make a serious attempt at using generative technologies if that helps...

[wouter.zoons]

In two words, Wouter, what is being expressed there - are any of those datatype generalizations requisite to the proper workings of AndroMDA?

well, theoretically speaking not .. however in practice, if you want to make proper use of the existing facades (both the generic ones and the ones in the cartridges) you'll need to have those generalizations

for example, from these generalizations it is clear that a datatype::List generalizes datatype::Collection, so if a facade tests a type for datatype::Collection it will not agree the datatype::List types are also the same type

this might even cause validation error message: in bpm4struts a table need to be represented by a collection or array parameter type, well, if you use a list type the facade will think you have modeled neither a collection neither an array

[chad.brandon]

To give a little more information: the generalizations allow us to check whether or not something is of a given type. So taking the datatype::Collection and datatype::List example Wouter talked about above: we have an isCollectionType operation on the ClassifierFacade, this operation returns true if the type is a collection, so because datatype::List generalizes datatype::Collection, it will return true.