Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[mdt-uml2.dev] Observations on QVT 1.2 UML 2.5 XMI files

Hi Kenn

I used the latest UML 2.5 tooling to produce the new models for QVT 1.2 and it all seemed to go quite well, until Pete Rivett reviewed the *.xmi models.

Rather than raise Bugzillas directly I've listed his observations below, since the difficulties are borderline between sensible Eclipse UML practice and strict OMG XMI expectations.

My *.xmi approach was to convert oppositeRoleName-EAnnotated *.ecore files into *.uml files then relocate the UMLResource.contents into corresponding XMIResource.contents to get a simple *.xmi save.

The 500 lines of Java can be seen in /org.eclipse.qvt/src/org/eclipse/qvt/tools/Ecore2UML.java in the QVTd GIT.

The Save options allowed most things to be configured. The main 'nasty' of renaming the UML namespace could be acheived by a BasicExtendedMetaData.getNamespace 'lie'.

Pete's obervations.

Don't use xsi:type: easily fixed with XMIResource.OPTION_USE_XMI_TYPE

Remove xmi:version - redundant in XMI 2.4. This seems to be a bug in XMISaveImpl, where perhaps a null xmiVersion could be used to signal no attribute. Removing this during serialisation defeated me so I have had to add a text filtering pass on the final files.

Use Package not Model at root of UML metamodels - this is a MOF rather than UML constraint so perhaps it has been overlooked. Fixed by a Ecore2UMLConverter.caseEPackage override.

Provide redundant xmi:type on root elements - a new requirement of XMI 2.4. Fixed by an override on XMISaveImpl.saveElementID.

Omit derived classifier property for EnumerationLiterals - changing to use UMLSaveImpl rather than XMISaveImpl fixed this, but I'm puzzled by the special case processing for EnumerationLiteral. It is understandable that XMISaveImpl gets this wrong since it may lack the understanding of UML EAnnotations that identify the 'duplicates'. However surely UMLSaveImpl should be detecting attributes that are derived as a consequence of a 'duplicates' EAnnotation rather than special casing the known EnumerationLiteral.classifier property?

Regards

Ed Willink


Back to the top