[Ed Thompson]

Right now it looks like I can have one(?) umr file to hold all my UML digrams for a project. Is there a way for me to delegate the modeling to another developer, then export/import their diagram inot on umr file?

ALso, is umr a standard format, or one unique to MyEclipse?

[Ed Thompson]

I see that I can have multiple umr files in a project. just limits sharing between diagrams to those in the same umr.

And it looks like XMI is the prefered import export format.

Is there a recommended strategy for sharing the modelling task with another developer?

[Duffy Gillman]

I have the same problem. I’ve just purchased two renewal MyEclipse Professional licenses so that I and another developer can use the UML tool. Not only am I finding it impossible to share the .umr files via source control (because they are binary and do not allow diff’ing), but I am finding that the XMI import/export does not work – I have exported a sequence diagram from one model, but importing in a second fails to do ANYTHING!

Can someone from MyEclipse/Genuitec please respond to this issue? It appears this thread is a couple of days old.

Thanks,

Duffy

[Kapil Kapre]

but I am finding that the XMI import/export does not work – I have exported a sequence diagram from one model, but importing in a second fails to do ANYTHING!

Duffy,
The XMI is for exporting all the elements contained in the UMR-model (not diagrams). An XMI import would then re-create the model in a fresh UMR allowing the user to drag and drop the elements into new diagrams. As things are there isnt any easy way to collaborate using CVS. The only way could be to unzip the umr (they are just zip files) and check in the contents (bunch of xml data) into CVS. Other users would have to check out the contents and zip them into a .umr again. This isnt practical for day to day use but could be useful if you need to say tag and check in a monthly/weekly backup into CVS. Note that even if the editor supported opening pre-unzipped UMR’s diffing the XML data would be a huge task as they often run into thousands of pages and are not necessarily serialized. So the real solution for allowing collaboration is to have a graphical diff tool that works with UMR files.

[Duffy Gillman]

Kapil,

Thank you. I see that I assumed too much about the intent of the use of XMI.

I am certain you are aware of the benefit derived from being able to version and collaboratively edit files. CVS or SVN support does not sound ‘doable’ – supposing the umr were unzipped, how would you resolve conflicts between versions of the diagrams? You are correct, some sort of tool support is needed.

What you are hearing is the frustration of folks who work on software teams who are struggling to make use of UML tools. By their very nature UML diagrams require collaboration. The biggest benefit to diagramming (IMHO) is to share designs with a team after all. It seems that this is a very critical piece in supporting a UML tool – supporting the processes that developers use for editting and sharing UML diagrams.

I am not writing this to beat up on you or MyEclipse. It really is an excellent tool and it integrates a lot of features/plugins that would not play well together without a company spending the effort to bundle them. I am suggesting, though, that better collaboration support is a necessity for MyUML to support complex projects effectively. I would love to see some work on this in future versions of MyEclipse. I can see several levels of support:

– a “compare UMRs”/merge tool that will show the changes to the model and diagram and allow accept/reject (sort of like M$ Office compare documents feature)

– a “track changes” feature

– integration with the Eclipse CVS and/or SVN plugins
– this would require umrs to be unzipped
– theoritically it would trigger a “compare UMRs” process when a conflict was detected

Anyway, thanks for the response. Please consider this “request for features” for future MyEclipse work.

Thanks,

Duffy

[Kapil Kapre]

Duffy,
Thank you for your detailed response. Yes, we certainly will take your comments into consideration for future versions. However please note that a graphical diff tool is not very high on our TODO list.
Thanks,
Kapil

[Author]

Posts