XMI Export

General Questions/Discussions
61

Hello Ellen,

I’ve received our file. Will investigate the reported problems.

Best regards,
Jick

62

Hello Ellen,

As I know most of the reported problems have been fixed. We will send you a patch on Monday. If you need the fix urgently, I could arrange a patch for you (which contains most fixes).

Best regards,
Jick

63

Jick,

Wonderful! Monday is completely fine with me. Thanks!

  • Ellen
64

Hi Ellen,

Here is the patch download URL:
http://files3.visual-paradigm.com/200711/Patch/sp1_20071116b/VP_Suite_Windows_3_1_sp1_20071116b.exe

Here is the information about the fixes:

Fixed

Datatypes.Class is the “PrmitiveType” of TextLexUnconstrained (because “DataType” of TextLexUnconstrained is imported first, so “DataType”'s name is correct),
ref to the above task, please ask user delete DataType.

Regarding "TextLexUnconstrained ", in the package “Datatypes”, there are 2 elements named “TextLexUnconstrained”. They are:


one is “DataType”, another one is “PrimitiveType”.

However, after import to VP-UML, both become “Class”. and Class does not allow duplicate name. So one of the model’s name become "Class"
By checking the xmi, no element is referencing:

Therefore, we suggest you delete it first.

And for the stereotype "BasicType, since the “BasicType” stereotype’s baseType is “PrimitiveType” in XMI, we have fixed to read the baseType as “Class” insteadof “PrimitiveType”

Regarding “Attribute”, it is the same as the “PrimitiveType” issue reported under problem 2, and should be read as “Class”.

Since we do not have “Property”, we will create 2 stereotypes if the baseType is “Property” (one for “Attribute”, one for “AssociationEnd”, both stereotypess have the taggedValues if exists in xmi)

Fixed

Hope this helps.

Best regards,
Jick

65

Jick,

Thanks! I’m checking it out now.

In the meantime, we observed a problem with Association End multiplicity with a different file. There was an association for which both ends had [0…1] multiplicity. In the Eclipse UML2 file, both the Lower and Upper bounds for multiplicity are assumed to be 1 if they are not set otherwise. This meant that in our file, each Property defining one of the association ends had a single “child”, a " 0", for the lower bound of 0.

When I imported the file into VP-UML, I noticed that the multiplicity for both association ends was getting set to 0. I wonder if the “0” lower bound is getting picked up by VP-UML and used for the total multiplicity, and the implied “1” upper bound is getting ignored.

I hesitate to send you the UML file because I and my group do not “own” it, but if necessary I can come up with a simple one to send you for testing.

Thanks again!

  • Ellen
66

Hi Ellen,

We will check the problem and get back to you a.s.a.p. Meanwhile, please have a try to the 4 reported problems. If you have question, feel free to let me know.

Best regards,
Jick

67

Hello Ellen,

Sorry, problem 4 has not yet been fixed. I will send you a patch again a.s.a.p. Sorry once again.

Best regards,
Jick

68

Hello Ellen,

Please try again with this hotfix:
http://files3.visual-paradigm.com/200711/Patch/sp1_20071119/VP_Suite_Windows_3_1_sp1_20071119.exe

Hope this helps.

Best regards,
Jick

69

Jick,

Sorry I have not responded in quite some time-- I was pulled away to work on another aspect of our project. In the meantime, however, our licenses for VP-UML came through, so waiting paid off! I’m now back looking at our Eclipse exports and VP-UML imports, and would like to do some more troubleshooting of this process with you.

One of the things I have done is to significantly improve the UML2 Profile we are using in Eclipse, including fixing some things I was doing improperly before (and which, no doubt, contributed to some of the problems I was having moving files back-and-forth between Eclipse and VP-UML). The profile is now much more stable and I now have a better handle on what needs to happen in Eclipse and VP-UML in the translation process, so hopefully I can provide better descriptions of any issues as they occur.

Using our new profile and Eclipse UML2 utility, I’ve imported our UML2 file into VP-UML and have begun checking it. Things are looking very good overall, but there are still some issues. The file is large so I would prefer to send it to you via email rather than posting it here (this will also enable me to send both the original *.uml file and the VP-UML project I created from importing it).

The following are the initial things I have observed when importing our new Profile:

  1. Tagged values attached to the stereotypes (which now have proper lower-case names!) are not getting imported. Within the Profile Application portion of our *.uml file, I have noticed that these tagged values are getting set correctly. The stereotypes do look good and extend the correct base classes.

  2. Comments are showing up in the base of the model, instead of attached to the model element they are supposed to be attached to. For example, in the “ISO 19100::ISO/TS 19103 Conceptual Schema Language::Basic Types - Primitive - Numerics” package, the “Vector” has a constraint with an OCL body and a Comment describing the constraint: “The value of the ‘dimension’ is determined by the length of the ‘ordinates’ number-array.” In the VP-UML project, the Constraint (the OCL) is properly attached to the Vector . However, the Comment shows up in the root of the model, along with all other similar comments.

  3. I have noticed when importing a UML2 file which has an applied profile containing stereotypes that the stereotype definitions remain within VP-UML after that project/model is closed. This previously caused me some confusion as I was testing out different versions of our profile, because I ended up with multiple stereotypes with identical names which had different tagged values and definitions. Sometimes it seemed that the wrong “version” of the stereotype was getting applied to a model element. Anyway, I would be interested to know whether or not this is by design. It would seem to me that since stereotypes are defined in a profile, they should be restricted to models with that particular profile applied…If you could please explain some of the philosophy behind this, I’d appreciate it!

Thanks for your continued help!

70

Jick,

Have you and the support team had a chance to look at the above issues and the files yet?

Thanks!