Importing Together-6.0.1 UML-1.4 models and Java c

[tomte]

Dear Collegous,

I am looking for a new tool for
- full UML 2.x modelling
- Roundtrip engineering UML <--> Java (in my case only Java)
- Importing Together-6.0.1 UML-1.4 models and Java code ("LiveSource")
- Sharing the model in a online discussion group


I imported a UML&Java-Project from Together6.
But where are the Diagrams?

What I did (file menus are in German):

EA > Project > Import/Export > ImportPackageFromXMI(Strg-Atl-I): greyed


EA >
- File > New Project:
- - Speichern in: D:\workspaces\SCEA-Exam-Workspaces\SCEA-Exam-2.0-EA-6.5
- - Dateiname:    scea-sp9305599-from-TS6.0.1-UTF8-XMI1.1-UML1.4-OMG.eap
- - Dateityp:     Enterprise Architect Project (*.EAP)
- Project > Import/Export > ImportPackageFromXMI:
- - RootPackage: Model (greyed)
- - FileName:    D:\workspaces\SCEA-Exam-Workspaces\SCEA-Exam-Together-Solo-6.0.1\xmi\scea-sp9305599-TS6.0.1-UTF8-XMI1.1-UML1.4-OMG.xml
- - Options:
- - - ImportDiagrams: yes
- - - Strip GUIDs:    no
- - - Write LogFile:  yes
- - - Treat Imported Datatypes as: Code:Java
- - > Import ==> "The current Package will be overwritten?" yes ==> "Import complete"


EA > Project Browser > Model/Project/ ==> what I got here is:
- Use Case View (Package)
- com (Package)
- dozends of
- - UseCases,
- - Classes
- - - with or without packages
- - - with properties (right mouse click)
- - - but not showing any source code
- - Method names as pro-forma-classes
- - Interfaces having method bullets, but no code yet
- - many unnamed untyped Objects (probabely from sequence diagrams)
- - many named Objects (probabely from sequence diagrams), but not telling me their packages
- - Nodes from Deployment diagrams
- - Components from Component diagrams

- - BUT NOT ONE SINGLE DIAGRAM !


In http://www.sparxsystems.com.au/EAUserGuide/index.html in "Getting Started" a section "XMI-Import from Other Tools" is missing!

You only face the UML-novice who is willing to explore EA for several days.

You leave professionals alone. Their needs are:

- Importing a non-trivial / huge project from their former UML and/or Java tool via XMI to EA
- See the old Diagrams immediately, if any
- See the old source code immediately, if any
- Evaluate how much work it takes to adjust the old DIAGRAMS
- Evaluate normal work with EA (refining the model through diagrams and / or through source code)
- Generating (Java-)Code, compiling, running/debugging


So, what to do next after importing a huge project from Together 6, including dozends of diagrams and lots of .java files ("the code is the model" in Together6)?

Do I have to additionaly copy the source code from the Together6 project and then somehow synchronize it with the XMI-imported model?

E.g. via EA > Project Browser > Model/Project/ > RM > Code Engineering > Generate Source Code ...:
- Root Package: Project (greyed)
- Synchronize:  Synchronize Model and Code
- Generate: Auto Generate Files: yes (??)
- - > Ordner suchen: D:\workspaces\SCEA-Exam-Workspaces\SCEA-Exam-2.0-EA-6.5\src
- - - (==> shown in Rout Directory...)
- - Retain Existing File Paths: no (??)
- - Include all Child Packages: no (??)
- - Select Objects to Generate: is empty!
- Generate-Button ==> nothing happens ...


We do not need elaborated screen shots etc. .
But a short navigation (explaining the parameters to be entered) like the examples above
- would take you some minutes
- would spare your potential customers some days


Let me give Enterprise Architect one more chance, please.

Best regards,
Thomas

[Paolo F Cantoni]

Preface:  This is principally a user forum.  The Sparxians (as we call them) do lurk and contribute, but most of the discussion is inter-users.

I'm not really sure how to help you here Thomas, as I'm not a Together expert.  I just played with it a few years back.

I think overall you may be falling foul of the different philosophical approach of the two products.

Because Together (as you say) uses the "code is the model" approach, it may well be that the XMI export doesn't contain any usable code for EA to import.

Certainly if you point EA at the code base, it will reverse engineer (to a variable extent) and will produce diagrams (though not your diagrams).

Also, although the diagrams may be in the XMI, they may not be in a form usable by EA.  We find that a lot of products have trouble producing intercompatible XMI (and the fault appears slightly more with the non EA tools).

I've managed round-tripping between Rose and EA but only when both sides had no errors.  That is I have to ensure that he validation tools on both ends showed no errors.

You'll find we users pretty much all agree that EA has a UI (Unique Interface).  However, it is still worth using.

Feel free to add any further information... The European user contingent will come on board soon, followed by the Americans (I'm on the Australian West Coast).

If they can't give you a better answer then send a formal support request to Sparx and they'll give you a reply, usually pretty promptly (Australian EDT - about UTC+8 ).

HTH,
Paolo

[Jan ´Bary´ Glas]

I am also not a Together user, but there are in some tools checkboxes for including diagrams in XMI export. This may be the case. And if the diagram (layout) is not exported it cannot be imported.

That's for Europe, let's see the Americans and Sparxians.

Does anyone know if diagram export is standard for XMI?

[«Midnight»]

It was not a part of XMI 1.x. At 1.2 there was some idea of capturing some aspects of diagrams, with the intent that tools could use the information to render similar diagrams using their own drawing paradigms. This (and the rest of XMI 1.2) never really went anywhere.

XMI 2.x was intended to (at least be able to) carry diagram information. However, in the case of EA, Sparx already had a means of capturing diagrams that worked. I think they have propagated this to XMI 2, but I'm not sure. If so they have not broken any 'rules' but you may be somewhat limited as far as porting to other tools.

Has anyone out there looked at this?

[tomte]

Dear Colleagues,

thank you very much for your detailed hints!

For my puposes I checked out Together 2006 R2 and Enterprise Architect 6.5 and Poseidon during the last days. I did it for instance for XMI export / import and tool usebility in Sequence, Class, Component and Deployment diagrams.

Yesterday I bought Sparx Enterprise Architect 6.5 Professional.

My experiences and thoughts are:

- I will miss the automatic "LiveSource" of Together very much! I tried EA's synchronize code functionality an I hope I will be able to live with it.

- I could not afford three cycles of slow click&wait just for moving an arrow in a Together 2006 R2 sequence diagram  -  and after importing even from Together Solo 6 there are a lot of arrows to move  -  EA does that much better.

- In terms of usability in Sequence diagrams EA is the direct successor of the excellent (but UML 1.4) Together 6 tool.  Together2006 R2 will have to sit out this round.

- On the other hand I would have liked to stay in the Together world because that actually would have been the only way to convert Together-6 "LiveSource" (model, diagram and code) from UML 1.4 "directly" to UML 2.0 & LiveSource  -  if the Sequence diagrams would be usable.

- XMI - horrible!: All these tools lack in supporting the inter-tool interchange of

- - model via XMI:
i.e. what diagrams and raw code should be able to be derived from. How usefull is a "successfull" XMI export / import if I can not rework diagrams nor code afterwards?

- - diagram layout via XMI-2:
the logical associations are in the model already. Only some "GridBagConstraints" are needed for interchanging the layout (thinking in Java ...).

- - source code via implicitely or separately copying it into the new project and synchronizing:
language specific types, classes, method signatures, etc.. I am pretty bent on seeing how EA will handle code synchronizing in big projects.

- I expect horrible sessions of XMI workarounds because I fear for the online discussion forum we could have to interchange with the free Poseidon Community Edition too.

Thanks again,
Thomas

[tomte]

- I could not afford three cycles of slow click&wait just for moving an arrow in a Together 2006 R2 sequence diagram  -  and after importing even from Together Solo 6 there are a lot of arrows to move ...

To be fair: Some days ago I found an upgraded version of Together 2006 R/2, dated on 2006-12-18. The behaviour cited above has been solved.

If this would have been solved earlyer then I would not have migrated to EA, because Together's LiveSource highly supercedes EA's Round Trip features that caused unusable diagrams and .java files.

On the other hand Together's Seuence diagrams still are far from the quality of those in Together 6, so I keep on waiting for a better release and using EA Professional.

Migrating is not straight forward ...
tomte

[Eve]

- I will miss the automatic "LiveSource" of Together very much! I tried EA's synchronize code functionality an I hope I will be able to live with it.

EA can automatically generate changes (See http://www.sparxsystems.com/EAUserGuide/index.html?sourcecodeconfiguration.htm)

Additionally, have a look at the MDG integration for Visual Studio or Eclipse.  Recently we've added support to those for automatically reverse engineering changes.  I'm not up with the releases of those products so I'm not sure if those updates have been released yet.

[tomte]

EA can automatically generate changes ... Additionally, have a look at the MDG ...

Two differences are:
- In EA you need to think in UML and EA internals for risky operations like code generation / merging / overwriting,
- in Together 6 you can think in UML and Java, not in tool internals for that purpose.

I believe you: If one diggs deep into the EA tool he maybe can somehow get what Together's "LiveSource" / "The code is the model" offers, but documentation of concepts is still lacking, as already stated in http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=suggestions;action=display;num=1170758957

tomte

[«Midnight»]

Still, EA is advertised as a UML modeling tool, rather than a Java modeling tool.

I think you point about documentation of concepts stands regardless. To some extent EA does this at a higher level - but only so far, which is the problem in the first place.

You could write an add-in to help with documentation, to take you beyond just adding detail to model elements. [I know, I've done it.] Still, covering the holes in your Java issues would be substantially more work, with a definite risk of failure. [Not so much from limitations in the product, but from breadth of scope and size of project versus potential returns from the number of times you yourself would likely use it.

Perhaps the best way is to isolate what you think is missing, and suggest each of those things here. See what support and refinement you get, and get the resulting package in front of Sparx as feature requests.

[sunset]

I agree with Tomte. I have been using EA for a long time as well as MDG link for Eclipse. I love EA diagramming features even though it allows some UML errors here and there.

But the most annoying feature is code generation/reverse engineering. It is soooo sloooow and wrong! I think it was better on version 4 than it is now... Now, I am really scared to generate/merge any code because even if it takes way longer than it should, it may overwrite my code ... arghh total disaster.

So using EA just for diagrams is not enough, not worth the price as free tools do better. We can live with bad looking (but correct) diagrams but wasting time redoing code is out of question.

Actually, for our next project, if Sparx keeps being silent on this issue, then we'll replace all our EA license with a real, developer oriented UML tool.

[Eve]

Hi sunset,

I'm not aware of any bug reports suggesting that the code engineering capability of EA has gone backwards.  From my point of view it has drastically improved since version 4.  Perhaps if you submit a bug report stating the problems you are experiencing we can have a look at them.

[thomaskilian]

Actually, for our next project, if Sparx keeps being silent on this issue, then we'll replace all our EA license with a real, developer oriented UML tool.

Just curious: which one should that be?

[sunset]

Hi Simon,

thanks for your offer.
Here are the main bugs we found. We have a Java project with over 500 classes (maybe 80 packages) and we'd like to reverse engineer it so to draw diagrams, update them, forward engineer the code, etc.

Everything is working fine up to forward engineer or sync with the code. At that point, EA spends 10s of minutes sync'ing even if the changes affected one or 2 classes (I don't remember this being that bad in earlier versions). But the most troubling is for methods that we changed names: the code therein is lost! More often than not, EA generates code without verifying if package names are correct (in particular those in its model!). This happened in the past though.

So basic refactoring simply doesn't work and that's probably the most useful feature of a UML tool IMHO.

[sunset]

One of the major selling point of EA is its attractive price structure. But when it comes to many developers using the tool and wasting lots of hours, even an expensive tool like Rational Rose becomes cheap. Of course, that's just an example, we are still evaluating...

[Eve]

When you're doing a forward synch, what command do you use?  It sounds like you're generating everything, and you certainly don't need to.

What is the value of the option at 'Tools' | 'Options' | 'Source Code Engineering' | 'Attribute/Operations' | 'On forward synch, prompt to delete features not in model'?  This option effects how generation after changing a method name works.  If it's false the behaviour should be the same as EA 4.0 and EA will generate a new method to the end of the class leaving the old one.  If it's true EA will bring up a dialog and you can specify the mapping between methods in the model and source.

EA doesn't generally verify that the model makes sense before generating.  This includes package names and much more.  The only time reason it checks for validity of package names is when they have spaces.  In this situation it treats them as a namespace root.