Michael,
Good point about the multiplicity inconsistency – that’s a quirk
of the tool that was used to produce the diagram. Indeed, the intent is for the
diagram to explicitly show everything that is in the model, even for defaults.
Rules about what should and should not appear in a diagram don’t
really exist, since, per the specification, lots of information can be elided
from a diagram if a modeler so chooses. All that exists are conventions, and
each tool seems to adopt its own. This fact introduces many challenges in
trying to achieve real interoperability, as the working group is discovering.
Some (including me) have tried to suggest that the semantic elements (XMI) be
the “normative” definition of what’s being exchanged in this exercise, but it
appears even harder to get agreement on what the XMI should look like than it
is, what the diagram should. ;)
Thanks,
Kenn
Hussey
Program Manager, Modeling and Design Solutions
![[Embarcadero Technologies Logo]](jpg8rK4eOjgJZ.jpg)
Embarcadero Technologies, Inc. | www.embarcadero.com
82 Peter Street, Second Floor | Toronto, ON
M5V 2G5
Kenn.Hussey@xxxxxxxxxxxxxxx
Office: 416-593-1585 x9296 Mobile: 613-301-9105
From:
mdt-uml2tools.dev-bounces@xxxxxxxxxxx
[mailto:mdt-uml2tools.dev-bounces@xxxxxxxxxxx] On Behalf Of Borlander
Sent: Friday, March 20, 2009 12:30 PM
To: MDT UML2 Tools mailing list
Subject: Re: [mdt-uml2tools.dev] Model Interchange
Hello,
Originally answered in person by mistake, copying to list
Excuse me,
Michael
Subject: Re: [mdt-uml2tools.dev] Model Interchange
To: Kenn Hussey <Kenn.Hussey@xxxxxxxxxxxxxxx>
Hello,
Sure, I will prepare the diagrams today.
Just one question, all of the test diagrams I seen so far consistently contains
the multiplicity of [1] for association ends (see class3_2),
but at the same time doesn't contain the implied multiplicity of [1] for
properties inside properties compartments (see attribute2).
I have checked in the your xmi that both properties don't have upper/lower
value specs, so they are semantically identical.
Don't you think its an inconsistency?
In UML2Tools the multiplicity of [1] (well, of [1..1]) is considered as default
(even if it is explictly set), and is not shown at the diagram.
May be its wrong, but at least we do it consistently for both attribute
notation and association end notation.
If we made it wrong, could you please advice what are the desired rules here
(reference to some spec which is better that 07-02-03 would also probably
help).
Regards,
Michael
On Fri, Mar 20, 2009 at 2:49 PM, Kenn Hussey <Kenn.Hussey@xxxxxxxxxxxxxxx>
wrote:
Michael,
Could you provide me with an
updated model based on a newer version of the test case diagram (attached)?
I’ve also attached the “reference” XMI for this test case…
Thanks,
Kenn Hussey
Program Manager, Modeling and Design Solutions
Embarcadero Technologies,
Inc. | www.embarcadero.com
Michael,
Thanks for putting these
together. I can look into producing the necessary XMI, but longer term this has
to be possible via the tool itself (according to the “rules of engagement” for
the working group).
1. I’ll take a look and offer some
suggestions. My initial thought would be to change the diagram creation wizard
to be similar to that of Ecore Tools (see below), with the addition of a ‘Root
Element’ field that would allow you to select Model, Package, or Profile.
2. OK, but the type have to import first
for both approaches? Note that import relationships are not required to be able
to reference/use a type…
3. You’re right, this is not required by
the specification…. but it’s used in the specification, so some users have come
to expect it. ;)
4. This can be done from the tree editor by
saving as a file with ‘.xmi’ as an extension; mind you, the tree editor is only
meant to serve as an example. An export option where the user could choose the
target format/version may make more sense. The functionality to import/open a
model using “standard” XMI should be trivial, however, since all of the support
you need is in UML2. We use this capability, for example, to support
“non-native” UML models in the EMF Project/Model Wizard, for example, and of
course the sample tree editor can be opened on any file that contains valid
UML…
5. OK, I’ll think about this. It’s a minor
issue anyway; I’ve just never seen the need to show the icon for a class (for
example) in the class shape, as it seems redundant.
6. Agreed, the specification says nothing
about color, but the objective is to produce a diagram that looks as close to
the reference diagram as possible, and this will be noted (rightly or not) as a
difference.
Cheers,
Kenn Hussey
Program Manager, Modeling and Design Solutions
Embarcadero Technologies,
Inc. | www.embarcadero.com
82 Peter Street, Second Floor | Toronto, ON M5V 2G5
Kenn.Hussey@xxxxxxxxxxxxxxx
Office: 416-593-1585 x9296 Mobile: 613-301-9105
Hello,
I have created the diagram. Attached please find, as a separate archives the
following:
a) diagram and uml semantic models
b) SVG screenshots (results of the GMF SVG export, has a few problems with line
colors etc)
c) actual screenshots as PNG images.
Note that diagram file contains 2 diagrams at once - for the top
"testSuite1" package and for an inner "package1" package.
Diagram editor will show the "default" top one after reopening. In
order to see the inner one, someone may double click on the
"package1".
Regarding to your comments:
1) Yes, thats a bug, I have submitted <a href=""
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=268252" target="_blank">https://bugs.eclipse.org/bugs/show_bug.cgi?id=268252">Bug
#268252</a> for that. If you have any ideas about UI for this selection,
please provide comment there.
2) There are actually 2 ways to set the attribute type to UML::Boolean or
UML::String.
First, someone can add the element import into the diagram header (see
screenshots) and then just type "attribute1:String" in the property
inplace.
Second, someone can select the attribute and use U2T specifc JDT-like selector
dialog invoked from the property sheet (for property type).
3) Yes, that is a probably a missed feature, also I belive that specification
does not require this.
4) Yes, there are no ways to run save/export for diagram semantic model from
the diagram editor. Personally I don't know how to do that from UML2
tree-editor as well. I believe that this kind of functionality is related
rather to UML2 component then to U2T. If this already implemented in UML2, (I
think so, but not sure), we easily can and will provide a UI for invoking that
from diagram view.
5) Yes, right now there are no ways to block images. In fact, we have recently
added images for inner elements inside list compartments (<a href=""
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=265764" target="_blank">https://bugs.eclipse.org/bugs/show_bug.cgi?id=265764">bug
#265764</a>). In this scr I have already mentioned that :
<quote>
Probably we can provide an additional way to switch some/all labels off via
preferences, but it would be a scope of different request.
</quote>
but right now it is not planned, at least for M6. If you have any suggestions
on that, please don't hesitate to bugzilla it.
6) Yes, there are no ways to make associations black. However, in the whole
chapter 7.3.3 Associations (2007-02-03 OMG Superstructure spec) I can't find
single word "black", and personally I believe that blue color a) is
convenient, at least for Borland user base b) allows easily visually
distinguish associations from other possible kind of links at ClassD.
Regards,
Michael
On Wed, Mar 11, 2009 at 10:29 PM, Kenn Hussey <Kenn.Hussey@xxxxxxxxxxxxxxx>
wrote:
Thanks, Michael. I'm happy hear that you are interested in this initiative.
In anticipation of your interest, I've already tried the first test case
(diagram image attached) using UML2 Tools (0.9 M5) and have run into the
following stumbling blocks:
1. It's not possible to specify the type of the root element that's created for
a new class diagram (the test case uses Model).
2. I couldn't find a way to set the type of an attribute to UML::Boolean or
UML::String.
3. I couldn't find a way to show the qualified names in the class shapes.
4. I couldn't find a way to save/export the semantic elements as
"standard" UML 2.1.1 XMI.
5. I couldn't find a way to hide the icons in the shapes (minor).
6. I couldn't find a way to make the associations black instead of blue
(minor).
Let me know whether you'd like me to open bugs for these. Given the progress of
the working group (and the kinds of problems we've already encountered, even
with the most popular/successful tools), I doubt we'll get as far as sequence
diagrams (let alone more complex class diagrams) before the Galileo release. ;)
Cheers,
Kenn Hussey
Program Manager, Modeling and Design Solutions
Office: 416-593-1585 x9296 Mobile: 613-301-9105
-----Original Message-----
From: Michael Golubev [mailto:Michael.Golubev@xxxxxxxxxxx]
Sent: Wednesday, March 11, 2009 4:01 PM
To: MDT UML2 Tools mailing list
Cc: Richard Gronback; Kenn Hussey
Subject: RE: [mdt-uml2tools.dev] Model Interchange
Hello,
We are definitely interested in the 1) and I am certainly going to participate
in this.
To be honest we are interested in 2) also, but right now UML2Tools has no
actual code that may support importing of the diagram information from any
other tool. But as we don't have any objections to write importing components
in future, we definitely would like to at least try to participate in part 2)
as well.
We will consider all issues that will be (I am sure on this) found under this
activity as a high priority issues.
Finally, for some kind of elements (especially at SequenceD that will be
delivered in U2T before API-freeze in M6), it would very convenient to have
'canonical' semantic models because there are a lot of possible ways to
represent some diagram notions in semantic models.
Regards,
Michael
-----Original Message-----
From: mdt-uml2tools.dev-bounces@xxxxxxxxxxx
on behalf of Kenn Hussey
Sent: Wed 3/11/2009 8:32 PM
To: MDT UML2 Tools mailing list; Papyrus Project list
Cc: MDT UML2 mailing list
Subject: [mdt-uml2tools.dev] Model Interchange
Teams,
There is an initiative underway at the OMG to try to successfully demonstrate
interchange between different products/tools that support UML modeling. To
date, I have been involved the working group that is pursuing this, by helping
prepare test cases. The basic idea is that, for each test case, a reference
diagram and XMI serialization are provided (so far by me) and each
participating vendor/tool is to 1) attempt to create the diagram from scratch
using their tool and save/export the corresponding XMI and 2) attempt to
open/import the XMI produced by the other vendors/tools and report on the
results.
I think it should be important to us that tools based on the reference open
source implementation of UML (like UML2 Tools and Papyrus) participate in this
initiative. I would be happy to represent you in this initiative, but first I
would need an _expression_ of interest from you (e.g. from your component/project
lead) and a general commitment to fixing any issues that are identified. What
do you think?
Please let me know if you have any questions and/or concerns.
Thanks,
Kenn Hussey
Program Manager, Modeling and Design Solutions
<http://www.embarcadero.com/>
Embarcadero Technologies, Inc. | www.embarcadero.com <http://www.embarcadero.com/>
82 Peter Street, Second Floor | Toronto, ON M5V 2G5 Kenn.Hussey@xxxxxxxxxxxxxxx
<mailto:Kenn.Hussey@xxxxxxxxxxxxxxx>
Office: 416-593-1585 x9296 Mobile: 613-301-9105
_______________________________________________
mdt-uml2tools.dev mailing list
mdt-uml2tools.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-uml2tools.dev
|
