Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » UML2 Composite Association Bug?
UML2 Composite Association Bug? [message #471655] Sat, 17 March 2007 05:30 Go to next message
Eclipse UserFriend
Originally posted by: nikos.swen.uwaterloo.ca

Hi all,
I have started to implement a metamodel using the Eclipse UML2 editor. When
I create a composite association between a concrete class (source) and an
abstract class (target) and then set the target cardinality to * and
try to validate my model it returns that it is invalid and that the target
cardinality of a composite association should not be greater than 1!!! Is
that a bug? (message: "The multiplicity of composite aggregation
'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
has an upper bound greater than 1.")
Furthermore when I try to convert my UML2 model to Ecore my valid composite
associations are not shown in my Ecore model..Another bug perhaps or am I
doing something wrong?
Thanks,
Nikos
Re: UML2 Composite Association Bug? [message #471722 is a reply to message #471655] Mon, 19 March 2007 16:06 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Nikos,

It sounds like you are modifying the cardinality to * of the wrong end. I
had a look at the implementation of the constraint on PropertyOperations()
and it seems ok.
The constraint in the spec is in section 7.3.43 : [2] A multiplicity on an
aggregate end of a composite aggregation must not have an upper bound
greater than 1. isComposite implies (upperBound()->isEmpty() or upperBound()
<= 1)
Kenn mentioned that there was a change from the old implementation as to how
the multiplicities are treated, but the constraint implentation and the
constraint itself seem fine.

Regards,

- James.



"Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
news:C220F522.19CD%nikos@swen.uwaterloo.ca...
> Hi all,
> I have started to implement a metamodel using the Eclipse UML2 editor.
When
> I create a composite association between a concrete class (source) and an
> abstract class (target) and then set the target cardinality to * and
> try to validate my model it returns that it is invalid and that the target
> cardinality of a composite association should not be greater than 1!!! Is
> that a bug? (message: "The multiplicity of composite aggregation
>
'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
> has an upper bound greater than 1.")
> Furthermore when I try to convert my UML2 model to Ecore my valid
composite
> associations are not shown in my Ecore model..Another bug perhaps or am I
> doing something wrong?
> Thanks,
> Nikos
>
Re: UML2 Composite Association Bug? [message #471723 is a reply to message #471722] Mon, 19 March 2007 16:31 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: nikos.swen.uwaterloo.ca

Hi James,
I attached a snapshot of the association I'm trying to implement..Is this
invalid?
The error I get is "The multiplicity of composite aggregation '<Property>
dst : Class1 [0..*]' has an upper bound greater than 1."
Why is this invalid? Is there another way to implement it?
Regards,
Nikos

"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:etmce4$rup$2@utils.eclipse.org...
> Hi Nikos,
>
> It sounds like you are modifying the cardinality to * of the wrong end. I
> had a look at the implementation of the constraint on PropertyOperations()
> and it seems ok.
> The constraint in the spec is in section 7.3.43 : [2] A multiplicity on an
> aggregate end of a composite aggregation must not have an upper bound
> greater than 1. isComposite implies (upperBound()->isEmpty() or
> upperBound()
> <= 1)
> Kenn mentioned that there was a change from the old implementation as to
> how
> the multiplicities are treated, but the constraint implentation and the
> constraint itself seem fine.
>
> Regards,
>
> - James.
>
>
>
> "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> news:C220F522.19CD%nikos@swen.uwaterloo.ca...
>> Hi all,
>> I have started to implement a metamodel using the Eclipse UML2 editor.
> When
>> I create a composite association between a concrete class (source) and
>> an
>> abstract class (target) and then set the target cardinality to * and
>> try to validate my model it returns that it is invalid and that the
>> target
>> cardinality of a composite association should not be greater than 1!!! Is
>> that a bug? (message: "The multiplicity of composite aggregation
>>
> 'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
>> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
>> has an upper bound greater than 1.")
>> Furthermore when I try to convert my UML2 model to Ecore my valid
> composite
>> associations are not shown in my Ecore model..Another bug perhaps or am I
>> doing something wrong?
>> Thanks,
>> Nikos
>>
>
>


  • Attachment: default.gif
    (Size: 2.44KB, Downloaded 183 times)
Re: UML2 Composite Association Bug? [message #471724 is a reply to message #471723] Mon, 19 March 2007 17:18 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Nikos,

If the multiplicity of src is 1 then this is a valid diagram. The
isComposite of dst should be true and the isComposite of src should be
false.
Can you verify that?

You might have a display issue? If the multiplicity of src was * and the
composition was the other way, then I would expect that error.

Can you post your model and I'll give it a look over.

Regards,

- James.



"Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
news:etmdtu$vup$1@utils.eclipse.org...
> Hi James,
> I attached a snapshot of the association I'm trying to implement..Is this
> invalid?
> The error I get is "The multiplicity of composite aggregation '<Property>
> dst : Class1 [0..*]' has an upper bound greater than 1."
> Why is this invalid? Is there another way to implement it?
> Regards,
> Nikos
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:etmce4$rup$2@utils.eclipse.org...
> > Hi Nikos,
> >
> > It sounds like you are modifying the cardinality to * of the wrong end.
I
> > had a look at the implementation of the constraint on
PropertyOperations()
> > and it seems ok.
> > The constraint in the spec is in section 7.3.43 : [2] A multiplicity on
an
> > aggregate end of a composite aggregation must not have an upper bound
> > greater than 1. isComposite implies (upperBound()->isEmpty() or
> > upperBound()
> > <= 1)
> > Kenn mentioned that there was a change from the old implementation as to
> > how
> > the multiplicities are treated, but the constraint implentation and the
> > constraint itself seem fine.
> >
> > Regards,
> >
> > - James.
> >
> >
> >
> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> > news:C220F522.19CD%nikos@swen.uwaterloo.ca...
> >> Hi all,
> >> I have started to implement a metamodel using the Eclipse UML2 editor.
> > When
> >> I create a composite association between a concrete class (source) and
> >> an
> >> abstract class (target) and then set the target cardinality to * and
> >> try to validate my model it returns that it is invalid and that the
> >> target
> >> cardinality of a composite association should not be greater than 1!!!
Is
> >> that a bug? (message: "The multiplicity of composite aggregation
> >>
> >
'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
> >> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
> >> has an upper bound greater than 1.")
> >> Furthermore when I try to convert my UML2 model to Ecore my valid
> > composite
> >> associations are not shown in my Ecore model..Another bug perhaps or am
I
> >> doing something wrong?
> >> Thanks,
> >> Nikos
> >>
> >
> >
>
>
>
Re: UML2 Composite Association Bug? [message #471725 is a reply to message #471724] Mon, 19 March 2007 17:28 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: nikos.swen.uwaterloo.ca

Hi James,

The multiplicity of src is 1. I couldn't find the isComposite attribute on
either dst or src.
I use Eclipse Version 3.3.0, Build id I20070222-0951 and UML2 v.2.1M5.
I attach both the UML2 model and the corresponding diagram.

Ragards,
Nikos

"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:etmgle$6qb$2@utils.eclipse.org...
> Hi Nikos,
>
> If the multiplicity of src is 1 then this is a valid diagram. The
> isComposite of dst should be true and the isComposite of src should be
> false.
> Can you verify that?
>
> You might have a display issue? If the multiplicity of src was * and the
> composition was the other way, then I would expect that error.
>
> Can you post your model and I'll give it a look over.
>
> Regards,
>
> - James.
>
>
>
> "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> news:etmdtu$vup$1@utils.eclipse.org...
>> Hi James,
>> I attached a snapshot of the association I'm trying to implement..Is this
>> invalid?
>> The error I get is "The multiplicity of composite aggregation '<Property>
>> dst : Class1 [0..*]' has an upper bound greater than 1."
>> Why is this invalid? Is there another way to implement it?
>> Regards,
>> Nikos
>>
>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> news:etmce4$rup$2@utils.eclipse.org...
>> > Hi Nikos,
>> >
>> > It sounds like you are modifying the cardinality to * of the wrong end.
> I
>> > had a look at the implementation of the constraint on
> PropertyOperations()
>> > and it seems ok.
>> > The constraint in the spec is in section 7.3.43 : [2] A multiplicity on
> an
>> > aggregate end of a composite aggregation must not have an upper bound
>> > greater than 1. isComposite implies (upperBound()->isEmpty() or
>> > upperBound()
>> > <= 1)
>> > Kenn mentioned that there was a change from the old implementation as
>> > to
>> > how
>> > the multiplicities are treated, but the constraint implentation and the
>> > constraint itself seem fine.
>> >
>> > Regards,
>> >
>> > - James.
>> >
>> >
>> >
>> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
>> > news:C220F522.19CD%nikos@swen.uwaterloo.ca...
>> >> Hi all,
>> >> I have started to implement a metamodel using the Eclipse UML2 editor.
>> > When
>> >> I create a composite association between a concrete class (source)
>> >> and
>> >> an
>> >> abstract class (target) and then set the target cardinality to * and
>> >> try to validate my model it returns that it is invalid and that the
>> >> target
>> >> cardinality of a composite association should not be greater than 1!!!
> Is
>> >> that a bug? (message: "The multiplicity of composite aggregation
>> >>
>> >
> 'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
>> >> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
>> >> has an upper bound greater than 1.")
>> >> Furthermore when I try to convert my UML2 model to Ecore my valid
>> > composite
>> >> associations are not shown in my Ecore model..Another bug perhaps or
>> >> am
> I
>> >> doing something wrong?
>> >> Thanks,
>> >> Nikos
>> >>
>> >
>> >
>>
>>
>>
>
>



Re: UML2 Composite Association Bug? [message #471727 is a reply to message #471725] Mon, 19 March 2007 18:26 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Nikos,

I just had a look at the serialized version. Looks like your composite
aggregation is on the wrong side. ... ie, your picture does not reflect
what you have in the serialized version.

Have a look at src, aggregation=composite. That should be on the dst
side... (the isComposite is derived so it is not serialized out but you
could use the API).

You can simply try to cut and paste that attribute over and it should
validate fine :)


Regards,

- James.



"Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
news:etmh8g$81s$1@utils.eclipse.org...
> Hi James,
>
> The multiplicity of src is 1. I couldn't find the isComposite attribute on
> either dst or src.
> I use Eclipse Version 3.3.0, Build id I20070222-0951 and UML2 v.2.1M5.
> I attach both the UML2 model and the corresponding diagram.
>
> Ragards,
> Nikos
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:etmgle$6qb$2@utils.eclipse.org...
> > Hi Nikos,
> >
> > If the multiplicity of src is 1 then this is a valid diagram. The
> > isComposite of dst should be true and the isComposite of src should be
> > false.
> > Can you verify that?
> >
> > You might have a display issue? If the multiplicity of src was * and
the
> > composition was the other way, then I would expect that error.
> >
> > Can you post your model and I'll give it a look over.
> >
> > Regards,
> >
> > - James.
> >
> >
> >
> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> > news:etmdtu$vup$1@utils.eclipse.org...
> >> Hi James,
> >> I attached a snapshot of the association I'm trying to implement..Is
this
> >> invalid?
> >> The error I get is "The multiplicity of composite aggregation
'<Property>
> >> dst : Class1 [0..*]' has an upper bound greater than 1."
> >> Why is this invalid? Is there another way to implement it?
> >> Regards,
> >> Nikos
> >>
> >> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> >> news:etmce4$rup$2@utils.eclipse.org...
> >> > Hi Nikos,
> >> >
> >> > It sounds like you are modifying the cardinality to * of the wrong
end.
> > I
> >> > had a look at the implementation of the constraint on
> > PropertyOperations()
> >> > and it seems ok.
> >> > The constraint in the spec is in section 7.3.43 : [2] A multiplicity
on
> > an
> >> > aggregate end of a composite aggregation must not have an upper bound
> >> > greater than 1. isComposite implies (upperBound()->isEmpty() or
> >> > upperBound()
> >> > <= 1)
> >> > Kenn mentioned that there was a change from the old implementation as
> >> > to
> >> > how
> >> > the multiplicities are treated, but the constraint implentation and
the
> >> > constraint itself seem fine.
> >> >
> >> > Regards,
> >> >
> >> > - James.
> >> >
> >> >
> >> >
> >> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> >> > news:C220F522.19CD%nikos@swen.uwaterloo.ca...
> >> >> Hi all,
> >> >> I have started to implement a metamodel using the Eclipse UML2
editor.
> >> > When
> >> >> I create a composite association between a concrete class (source)
> >> >> and
> >> >> an
> >> >> abstract class (target) and then set the target cardinality to * and
> >> >> try to validate my model it returns that it is invalid and that the
> >> >> target
> >> >> cardinality of a composite association should not be greater than
1!!!
> > Is
> >> >> that a bug? (message: "The multiplicity of composite aggregation
> >> >>
> >> >
> >
'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
> >> >> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
> >> >> has an upper bound greater than 1.")
> >> >> Furthermore when I try to convert my UML2 model to Ecore my valid
> >> > composite
> >> >> associations are not shown in my Ecore model..Another bug perhaps or
> >> >> am
> > I
> >> >> doing something wrong?
> >> >> Thanks,
> >> >> Nikos
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >
> >
>
>
>
Re: UML2 Composite Association Bug? [message #471728 is a reply to message #471727] Mon, 19 March 2007 18:38 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: nikos.swen.uwaterloo.ca

Hi James,

I did what you suggested but then the diagram looks like the one I attached,
but this in not what I want. The diamond of the composition should be on the
src side but instead it is shown in the dst side. All I want to implement is
an aggregation (from src to dst) which will have cardinality 1 at the src
side and 0..* at the dst side. Could you create one and send me the model
and the .umlclass_diagram plz? I still think there is a problem. I use the
uml2tools to implement the diagrams.

Regards,
Nikos

"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:etmkkd$hjd$2@utils.eclipse.org...
> Hi Nikos,
>
> I just had a look at the serialized version. Looks like your composite
> aggregation is on the wrong side. ... ie, your picture does not reflect
> what you have in the serialized version.
>
> Have a look at src, aggregation=composite. That should be on the dst
> side... (the isComposite is derived so it is not serialized out but you
> could use the API).
>
> You can simply try to cut and paste that attribute over and it should
> validate fine :)
>
>
> Regards,
>
> - James.
>
>
>
> "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> news:etmh8g$81s$1@utils.eclipse.org...
>> Hi James,
>>
>> The multiplicity of src is 1. I couldn't find the isComposite attribute
>> on
>> either dst or src.
>> I use Eclipse Version 3.3.0, Build id I20070222-0951 and UML2 v.2.1M5.
>> I attach both the UML2 model and the corresponding diagram.
>>
>> Ragards,
>> Nikos
>>
>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> news:etmgle$6qb$2@utils.eclipse.org...
>> > Hi Nikos,
>> >
>> > If the multiplicity of src is 1 then this is a valid diagram. The
>> > isComposite of dst should be true and the isComposite of src should be
>> > false.
>> > Can you verify that?
>> >
>> > You might have a display issue? If the multiplicity of src was * and
> the
>> > composition was the other way, then I would expect that error.
>> >
>> > Can you post your model and I'll give it a look over.
>> >
>> > Regards,
>> >
>> > - James.
>> >
>> >
>> >
>> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
>> > news:etmdtu$vup$1@utils.eclipse.org...
>> >> Hi James,
>> >> I attached a snapshot of the association I'm trying to implement..Is
> this
>> >> invalid?
>> >> The error I get is "The multiplicity of composite aggregation
> '<Property>
>> >> dst : Class1 [0..*]' has an upper bound greater than 1."
>> >> Why is this invalid? Is there another way to implement it?
>> >> Regards,
>> >> Nikos
>> >>
>> >> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> >> news:etmce4$rup$2@utils.eclipse.org...
>> >> > Hi Nikos,
>> >> >
>> >> > It sounds like you are modifying the cardinality to * of the wrong
> end.
>> > I
>> >> > had a look at the implementation of the constraint on
>> > PropertyOperations()
>> >> > and it seems ok.
>> >> > The constraint in the spec is in section 7.3.43 : [2] A multiplicity
> on
>> > an
>> >> > aggregate end of a composite aggregation must not have an upper
>> >> > bound
>> >> > greater than 1. isComposite implies (upperBound()->isEmpty() or
>> >> > upperBound()
>> >> > <= 1)
>> >> > Kenn mentioned that there was a change from the old implementation
>> >> > as
>> >> > to
>> >> > how
>> >> > the multiplicities are treated, but the constraint implentation and
> the
>> >> > constraint itself seem fine.
>> >> >
>> >> > Regards,
>> >> >
>> >> > - James.
>> >> >
>> >> >
>> >> >
>> >> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
>> >> > news:C220F522.19CD%nikos@swen.uwaterloo.ca...
>> >> >> Hi all,
>> >> >> I have started to implement a metamodel using the Eclipse UML2
> editor.
>> >> > When
>> >> >> I create a composite association between a concrete class (source)
>> >> >> and
>> >> >> an
>> >> >> abstract class (target) and then set the target cardinality to *
>> >> >> and
>> >> >> try to validate my model it returns that it is invalid and that the
>> >> >> target
>> >> >> cardinality of a composite association should not be greater than
> 1!!!
>> > Is
>> >> >> that a bug? (message: "The multiplicity of composite aggregation
>> >> >>
>> >> >
>> >
> 'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
>> >> >> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
>> >> >> has an upper bound greater than 1.")
>> >> >> Furthermore when I try to convert my UML2 model to Ecore my valid
>> >> > composite
>> >> >> associations are not shown in my Ecore model..Another bug perhaps
>> >> >> or
>> >> >> am
>> > I
>> >> >> doing something wrong?
>> >> >> Thanks,
>> >> >> Nikos
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>


  • Attachment: default.gif
    (Size: 2.44KB, Downloaded 189 times)
Re: UML2 Composite Association Bug? [message #471729 is a reply to message #471728] Mon, 19 March 2007 19:27 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Nikos,

There is a bug in uml2tools in how it displays these things ... the diamond
is on the wrong side :) Please raise a bugzilla on them to get that fixed.

Regards,

By the way, in general "Class" should also probably own the composed
property ( not the association ) as your serialized version shows.

- James.


"Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
news:etmlb9$n4l$1@utils.eclipse.org...
> Hi James,
>
> I did what you suggested but then the diagram looks like the one I
attached,
> but this in not what I want. The diamond of the composition should be on
the
> src side but instead it is shown in the dst side. All I want to implement
is
> an aggregation (from src to dst) which will have cardinality 1 at the src
> side and 0..* at the dst side. Could you create one and send me the model
> and the .umlclass_diagram plz? I still think there is a problem. I use the
> uml2tools to implement the diagrams.
>
> Regards,
> Nikos
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:etmkkd$hjd$2@utils.eclipse.org...
> > Hi Nikos,
> >
> > I just had a look at the serialized version. Looks like your composite
> > aggregation is on the wrong side. ... ie, your picture does not reflect
> > what you have in the serialized version.
> >
> > Have a look at src, aggregation=composite. That should be on the dst
> > side... (the isComposite is derived so it is not serialized out but you
> > could use the API).
> >
> > You can simply try to cut and paste that attribute over and it should
> > validate fine :)
> >
> >
> > Regards,
> >
> > - James.
> >
> >
> >
> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> > news:etmh8g$81s$1@utils.eclipse.org...
> >> Hi James,
> >>
> >> The multiplicity of src is 1. I couldn't find the isComposite attribute
> >> on
> >> either dst or src.
> >> I use Eclipse Version 3.3.0, Build id I20070222-0951 and UML2 v.2.1M5.
> >> I attach both the UML2 model and the corresponding diagram.
> >>
> >> Ragards,
> >> Nikos
> >>
> >> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> >> news:etmgle$6qb$2@utils.eclipse.org...
> >> > Hi Nikos,
> >> >
> >> > If the multiplicity of src is 1 then this is a valid diagram. The
> >> > isComposite of dst should be true and the isComposite of src should
be
> >> > false.
> >> > Can you verify that?
> >> >
> >> > You might have a display issue? If the multiplicity of src was *
and
> > the
> >> > composition was the other way, then I would expect that error.
> >> >
> >> > Can you post your model and I'll give it a look over.
> >> >
> >> > Regards,
> >> >
> >> > - James.
> >> >
> >> >
> >> >
> >> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> >> > news:etmdtu$vup$1@utils.eclipse.org...
> >> >> Hi James,
> >> >> I attached a snapshot of the association I'm trying to implement..Is
> > this
> >> >> invalid?
> >> >> The error I get is "The multiplicity of composite aggregation
> > '<Property>
> >> >> dst : Class1 [0..*]' has an upper bound greater than 1."
> >> >> Why is this invalid? Is there another way to implement it?
> >> >> Regards,
> >> >> Nikos
> >> >>
> >> >> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> >> >> news:etmce4$rup$2@utils.eclipse.org...
> >> >> > Hi Nikos,
> >> >> >
> >> >> > It sounds like you are modifying the cardinality to * of the wrong
> > end.
> >> > I
> >> >> > had a look at the implementation of the constraint on
> >> > PropertyOperations()
> >> >> > and it seems ok.
> >> >> > The constraint in the spec is in section 7.3.43 : [2] A
multiplicity
> > on
> >> > an
> >> >> > aggregate end of a composite aggregation must not have an upper
> >> >> > bound
> >> >> > greater than 1. isComposite implies (upperBound()->isEmpty() or
> >> >> > upperBound()
> >> >> > <= 1)
> >> >> > Kenn mentioned that there was a change from the old implementation
> >> >> > as
> >> >> > to
> >> >> > how
> >> >> > the multiplicities are treated, but the constraint implentation
and
> > the
> >> >> > constraint itself seem fine.
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > - James.
> >> >> >
> >> >> >
> >> >> >
> >> >> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> >> >> > news:C220F522.19CD%nikos@swen.uwaterloo.ca...
> >> >> >> Hi all,
> >> >> >> I have started to implement a metamodel using the Eclipse UML2
> > editor.
> >> >> > When
> >> >> >> I create a composite association between a concrete class
(source)
> >> >> >> and
> >> >> >> an
> >> >> >> abstract class (target) and then set the target cardinality to *
> >> >> >> and
> >> >> >> try to validate my model it returns that it is invalid and that
the
> >> >> >> target
> >> >> >> cardinality of a composite association should not be greater than
> > 1!!!
> >> > Is
> >> >> >> that a bug? (message: "The multiplicity of composite aggregation
> >> >> >>
> >> >> >
> >> >
> >
'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
> >> >> >> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
> >> >> >> has an upper bound greater than 1.")
> >> >> >> Furthermore when I try to convert my UML2 model to Ecore my valid
> >> >> > composite
> >> >> >> associations are not shown in my Ecore model..Another bug perhaps
> >> >> >> or
> >> >> >> am
> >> > I
> >> >> >> doing something wrong?
> >> >> >> Thanks,
> >> >> >> Nikos
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >
> >
>
>
>
Re: UML2 Composite Association Bug? [message #471730 is a reply to message #471729] Mon, 19 March 2007 19:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: nikos.swen.uwaterloo.ca

Thank you for your time James. Since the uml2tools contains bugs could you
suggest a tool (freeware of course) in which you can graphically create
efficiently UML2 diagrams? I need to create UML2 diagrams and then transform
them (the models) to ecore files and finally create EMF editors for those.

Thank you,
Nikos

"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:etmo6v$tsu$2@utils.eclipse.org...
> Hi Nikos,
>
> There is a bug in uml2tools in how it displays these things ... the
> diamond
> is on the wrong side :) Please raise a bugzilla on them to get that
> fixed.
>
> Regards,
>
> By the way, in general "Class" should also probably own the composed
> property ( not the association ) as your serialized version shows.
>
> - James.
>
>
> "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> news:etmlb9$n4l$1@utils.eclipse.org...
>> Hi James,
>>
>> I did what you suggested but then the diagram looks like the one I
> attached,
>> but this in not what I want. The diamond of the composition should be on
> the
>> src side but instead it is shown in the dst side. All I want to implement
> is
>> an aggregation (from src to dst) which will have cardinality 1 at the src
>> side and 0..* at the dst side. Could you create one and send me the model
>> and the .umlclass_diagram plz? I still think there is a problem. I use
>> the
>> uml2tools to implement the diagrams.
>>
>> Regards,
>> Nikos
>>
>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> news:etmkkd$hjd$2@utils.eclipse.org...
>> > Hi Nikos,
>> >
>> > I just had a look at the serialized version. Looks like your
>> > composite
>> > aggregation is on the wrong side. ... ie, your picture does not
>> > reflect
>> > what you have in the serialized version.
>> >
>> > Have a look at src, aggregation=composite. That should be on the
>> > dst
>> > side... (the isComposite is derived so it is not serialized out but you
>> > could use the API).
>> >
>> > You can simply try to cut and paste that attribute over and it should
>> > validate fine :)
>> >
>> >
>> > Regards,
>> >
>> > - James.
>> >
>> >
>> >
>> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
>> > news:etmh8g$81s$1@utils.eclipse.org...
>> >> Hi James,
>> >>
>> >> The multiplicity of src is 1. I couldn't find the isComposite
>> >> attribute
>> >> on
>> >> either dst or src.
>> >> I use Eclipse Version 3.3.0, Build id I20070222-0951 and UML2 v.2.1M5.
>> >> I attach both the UML2 model and the corresponding diagram.
>> >>
>> >> Ragards,
>> >> Nikos
>> >>
>> >> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> >> news:etmgle$6qb$2@utils.eclipse.org...
>> >> > Hi Nikos,
>> >> >
>> >> > If the multiplicity of src is 1 then this is a valid diagram. The
>> >> > isComposite of dst should be true and the isComposite of src should
> be
>> >> > false.
>> >> > Can you verify that?
>> >> >
>> >> > You might have a display issue? If the multiplicity of src was *
> and
>> > the
>> >> > composition was the other way, then I would expect that error.
>> >> >
>> >> > Can you post your model and I'll give it a look over.
>> >> >
>> >> > Regards,
>> >> >
>> >> > - James.
>> >> >
>> >> >
>> >> >
>> >> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
>> >> > news:etmdtu$vup$1@utils.eclipse.org...
>> >> >> Hi James,
>> >> >> I attached a snapshot of the association I'm trying to
>> >> >> implement..Is
>> > this
>> >> >> invalid?
>> >> >> The error I get is "The multiplicity of composite aggregation
>> > '<Property>
>> >> >> dst : Class1 [0..*]' has an upper bound greater than 1."
>> >> >> Why is this invalid? Is there another way to implement it?
>> >> >> Regards,
>> >> >> Nikos
>> >> >>
>> >> >> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> >> >> news:etmce4$rup$2@utils.eclipse.org...
>> >> >> > Hi Nikos,
>> >> >> >
>> >> >> > It sounds like you are modifying the cardinality to * of the
>> >> >> > wrong
>> > end.
>> >> > I
>> >> >> > had a look at the implementation of the constraint on
>> >> > PropertyOperations()
>> >> >> > and it seems ok.
>> >> >> > The constraint in the spec is in section 7.3.43 : [2] A
> multiplicity
>> > on
>> >> > an
>> >> >> > aggregate end of a composite aggregation must not have an upper
>> >> >> > bound
>> >> >> > greater than 1. isComposite implies (upperBound()->isEmpty() or
>> >> >> > upperBound()
>> >> >> > <= 1)
>> >> >> > Kenn mentioned that there was a change from the old
>> >> >> > implementation
>> >> >> > as
>> >> >> > to
>> >> >> > how
>> >> >> > the multiplicities are treated, but the constraint implentation
> and
>> > the
>> >> >> > constraint itself seem fine.
>> >> >> >
>> >> >> > Regards,
>> >> >> >
>> >> >> > - James.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
>> >> >> > news:C220F522.19CD%nikos@swen.uwaterloo.ca...
>> >> >> >> Hi all,
>> >> >> >> I have started to implement a metamodel using the Eclipse UML2
>> > editor.
>> >> >> > When
>> >> >> >> I create a composite association between a concrete class
> (source)
>> >> >> >> and
>> >> >> >> an
>> >> >> >> abstract class (target) and then set the target cardinality to *
>> >> >> >> and
>> >> >> >> try to validate my model it returns that it is invalid and that
> the
>> >> >> >> target
>> >> >> >> cardinality of a composite association should not be greater
>> >> >> >> than
>> > 1!!!
>> >> > Is
>> >> >> >> that a bug? (message: "The multiplicity of composite aggregation
>> >> >> >>
>> >> >> >
>> >> >
>> >
> 'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
>> >> >> >> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
>> >> >> >> has an upper bound greater than 1.")
>> >> >> >> Furthermore when I try to convert my UML2 model to Ecore my
>> >> >> >> valid
>> >> >> > composite
>> >> >> >> associations are not shown in my Ecore model..Another bug
>> >> >> >> perhaps
>> >> >> >> or
>> >> >> >> am
>> >> > I
>> >> >> >> doing something wrong?
>> >> >> >> Thanks,
>> >> >> >> Nikos
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
Re: UML2 Composite Association Bug? [message #472099 is a reply to message #471730] Mon, 02 April 2007 06:34 Go to previous messageGo to next message
Dennis Wagelaar is currently offline Dennis WagelaarFriend
Messages: 147
Registered: July 2009
Senior Member
Nikos Giannopoulos schreef:
> Thank you for your time James. Since the uml2tools contains bugs could you
> suggest a tool (freeware of course) in which you can graphically create
> efficiently UML2 diagrams? I need to create UML2 diagrams and then transform
> them (the models) to ecore files and finally create EMF editors for those.
>
> Thank you,
> Nikos
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:etmo6v$tsu$2@utils.eclipse.org...
>> Hi Nikos,
>>
>> There is a bug in uml2tools in how it displays these things ... the
>> diamond
>> is on the wrong side :) Please raise a bugzilla on them to get that
>> fixed.
>>
>> Regards,
>>
>> By the way, in general "Class" should also probably own the composed
>> property ( not the association ) as your serialized version shows.
>>
>> - James.
>>
>>

The TopCased UML editor (www.topcased.org) has the same behaviour as
uml2tools. I'm getting suspicious...

Aggregration=Composite is now on the src side, where src points to the
"owner" classifier in the association. In UML 1.4, this is similar:
association ends that point to the "owner" classifier are marked as
ak_composite. Poseidon for UML implemented it this way.

> The constraint in the spec is in section 7.3.43 : [2] A multiplicity on an
> aggregate end of a composite aggregation must not have an upper bound
> greater than 1. isComposite implies (upperBound()->isEmpty() or upperBound()
> <= 1)

Ah, natural language... I interpret:

aggregate end of a composite aggregation = src

The multiplicity of src is indeed 1, since there should only be one
owner for any object. So, src->isComposite() must be true.

It is feasible for the src classifier to own multiple instances of the
dst classifier. Hence, the multiplicity of dst may be greater than 1.
Given the constraint from the UML spec, dst->isComposite() must be false.

Looks like UML2 intended the same semantics for Property elements as UML
1.4 did for AssociationEnd elements. Can you verify this please? It
would mean that Nikos was right.

--
Regards,
Dennis
Re: UML2 Composite Association Bug? [message #472103 is a reply to message #472099] Mon, 02 April 2007 21:41 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Dennis,

.... let me try to convince you ... :)

Take just about any figure in the UML spec illustrating the UML metamodel.
For instance, from the 07-02-05 version take figure 12.22 for structured
nodes.
Notice the composition association between ConditionalNode and OutputPin.
ConditionalNode has a part called "result" of multiplicity [*]. "result"
is shown on the end that is opposite the diamond along with the [*]
multiplicity. Also, on the end with the diamond we have the multiplicity
[0..1]. The isComposite() of "result" would be true in that case and is
shown on the dst end.
If what you are implying is correct then I think that means that all the
diagrams in the spec are backwards.

I agree that the constraint from the spec that is quoted below does seem to
be worded imprecisely.

.... are you convinced ?.... :)

p.41 of the spec describes the notation.

Regards,

- James.


"Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
news:euq864$cue$1@build.eclipse.org...
> Nikos Giannopoulos schreef:
> > Thank you for your time James. Since the uml2tools contains bugs could
you
> > suggest a tool (freeware of course) in which you can graphically create
> > efficiently UML2 diagrams? I need to create UML2 diagrams and then
transform
> > them (the models) to ecore files and finally create EMF editors for
those.
> >
> > Thank you,
> > Nikos
> >
> > "James Bruck" <jbruck@ca.ibm.com> wrote in message
> > news:etmo6v$tsu$2@utils.eclipse.org...
> >> Hi Nikos,
> >>
> >> There is a bug in uml2tools in how it displays these things ... the
> >> diamond
> >> is on the wrong side :) Please raise a bugzilla on them to get that
> >> fixed.
> >>
> >> Regards,
> >>
> >> By the way, in general "Class" should also probably own the composed
> >> property ( not the association ) as your serialized version shows.
> >>
> >> - James.
> >>
> >>
>
> The TopCased UML editor (www.topcased.org) has the same behaviour as
> uml2tools. I'm getting suspicious...
>
> Aggregration=Composite is now on the src side, where src points to the
> "owner" classifier in the association. In UML 1.4, this is similar:
> association ends that point to the "owner" classifier are marked as
> ak_composite. Poseidon for UML implemented it this way.
>
> > The constraint in the spec is in section 7.3.43 : [2] A multiplicity on
an
> > aggregate end of a composite aggregation must not have an upper bound
> > greater than 1. isComposite implies (upperBound()->isEmpty() or
upperBound()
> > <= 1)
>
> Ah, natural language... I interpret:
>
> aggregate end of a composite aggregation = src
>
> The multiplicity of src is indeed 1, since there should only be one
> owner for any object. So, src->isComposite() must be true.
>
> It is feasible for the src classifier to own multiple instances of the
> dst classifier. Hence, the multiplicity of dst may be greater than 1.
> Given the constraint from the UML spec, dst->isComposite() must be false.
>
> Looks like UML2 intended the same semantics for Property elements as UML
> 1.4 did for AssociationEnd elements. Can you verify this please? It
> would mean that Nikos was right.
>
> --
> Regards,
> Dennis
Re: UML2 Composite Association Bug? [message #472104 is a reply to message #472103] Mon, 02 April 2007 22:05 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Dennis,,

After re-reading that constraint ... I can really understand the confusion
about this point. I just spoke to Bran Selic ( chair of OMG ) to clarify
that for me and there does seem to be an issue there that should be cleaned
up. He mentioned that there were long debates over this point but the way
the UML API implements this constraint is correct. Have a look at the
PropertyOperations.validateMultiplicityOfComposite() for the proper
implementation.

When I come across the RTF (defect number) for that issue I will post it
here.

.... so I still stick to the original response that I gave :)

I hope that helps.

Regards,

- James.




"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:eurtb8$vbj$2@build.eclipse.org...
> Hi Dennis,
>
> ... let me try to convince you ... :)
>
> Take just about any figure in the UML spec illustrating the UML metamodel.
> For instance, from the 07-02-05 version take figure 12.22 for structured
> nodes.
> Notice the composition association between ConditionalNode and OutputPin.
> ConditionalNode has a part called "result" of multiplicity [*].
"result"
> is shown on the end that is opposite the diamond along with the [*]
> multiplicity. Also, on the end with the diamond we have the multiplicity
> [0..1]. The isComposite() of "result" would be true in that case and is
> shown on the dst end.
> If what you are implying is correct then I think that means that all the
> diagrams in the spec are backwards.
>
> I agree that the constraint from the spec that is quoted below does seem
to
> be worded imprecisely.
>
> ... are you convinced ?.... :)
>
> p.41 of the spec describes the notation.
>
> Regards,
>
> - James.
>
>
> "Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
> news:euq864$cue$1@build.eclipse.org...
> > Nikos Giannopoulos schreef:
> > > Thank you for your time James. Since the uml2tools contains bugs could
> you
> > > suggest a tool (freeware of course) in which you can graphically
create
> > > efficiently UML2 diagrams? I need to create UML2 diagrams and then
> transform
> > > them (the models) to ecore files and finally create EMF editors for
> those.
> > >
> > > Thank you,
> > > Nikos
> > >
> > > "James Bruck" <jbruck@ca.ibm.com> wrote in message
> > > news:etmo6v$tsu$2@utils.eclipse.org...
> > >> Hi Nikos,
> > >>
> > >> There is a bug in uml2tools in how it displays these things ... the
> > >> diamond
> > >> is on the wrong side :) Please raise a bugzilla on them to get that
> > >> fixed.
> > >>
> > >> Regards,
> > >>
> > >> By the way, in general "Class" should also probably own the
composed
> > >> property ( not the association ) as your serialized version shows.
> > >>
> > >> - James.
> > >>
> > >>
> >
> > The TopCased UML editor (www.topcased.org) has the same behaviour as
> > uml2tools. I'm getting suspicious...
> >
> > Aggregration=Composite is now on the src side, where src points to the
> > "owner" classifier in the association. In UML 1.4, this is similar:
> > association ends that point to the "owner" classifier are marked as
> > ak_composite. Poseidon for UML implemented it this way.
> >
> > > The constraint in the spec is in section 7.3.43 : [2] A multiplicity
on
> an
> > > aggregate end of a composite aggregation must not have an upper bound
> > > greater than 1. isComposite implies (upperBound()->isEmpty() or
> upperBound()
> > > <= 1)
> >
> > Ah, natural language... I interpret:
> >
> > aggregate end of a composite aggregation = src
> >
> > The multiplicity of src is indeed 1, since there should only be one
> > owner for any object. So, src->isComposite() must be true.
> >
> > It is feasible for the src classifier to own multiple instances of the
> > dst classifier. Hence, the multiplicity of dst may be greater than 1.
> > Given the constraint from the UML spec, dst->isComposite() must be
false.
> >
> > Looks like UML2 intended the same semantics for Property elements as UML
> > 1.4 did for AssociationEnd elements. Can you verify this please? It
> > would mean that Nikos was right.
> >
> > --
> > Regards,
> > Dennis
>
>
Re: UML2 Composite Association Bug? [message #472209 is a reply to message #472104] Tue, 03 April 2007 12:32 Go to previous messageGo to next message
Dennis Wagelaar is currently offline Dennis WagelaarFriend
Messages: 147
Registered: July 2009
Senior Member
Hi James,

Thank you very much for the elaborate explanation :-). I really
appreciate you taking the time to dig into this issue. I've looked at
several things now:

UML 2.1.1 Superstructure:
- Notation specification on p.42
- Example composition association in Fig.12.22, p.308
- Abstract syntax/meta-model of Association in Fig.7.12, p.32
- Constraint [2] on p.124

The implementation of PropertyOperations.validateMultiplicityOfComposite():
http://dev.eclipse.org/viewcvs/indextools.cgi/org.eclipse.um l2/plugins/org.eclipse.uml2/src/org/eclipse/uml2/internal/op eration/PropertyOperations.java?revision=1.21&view=marku p

As far as I understand Constraint [2], the "aggregate end" of a
composite aggregation is the one that has limits on its upper bound.
That implies that the context of the accompanying OCL statement must be
the "aggregate end":

let property = "aggregate end" in
property.isComposite implies
(property.upperBound()->isEmpty() or property.upperBound() <= 1)

Now I look at the code of
PropertyOperations.validateMultiplicityOfComposite():

boolean result = true;

if (property.isComposite()) {
Property otherEnd = property.getOtherEnd();

if (null != otherEnd) {
int upperBound = otherEnd.upperBound();

if (MultiplicityElement.UNLIMITED_UPPER_BOUND == upperBound
|| 1 < upperBound) {

result = false;

if (null != diagnostics) {
diagnostics
.add(new BasicDiagnostic(
Diagnostic.WARNING,
UML2Validator.DIAGNOSTIC_SOURCE,
UML2Validator.PROPERTY__MULTIPLICITY_OF_COMPOSITE,
UML2Plugin.INSTANCE
.getString(
"_UI_Property_MultiplicityOfComposite_diagnostic",
//$NON-NLS-1$
getMessageSubstitutions(context,
property)), new Object[]{property,
new Integer(upperBound)}));
}
}
}
}

return result;

So, the code checks if "property.isComposite()" is true. It then goes on
to check the multiplicity of the *other* end, instead of the
multiplicity of "property". That is inconsistent with the OCL
specification of Constraint [2]. I will for now ignore the fact that
only binary associations have an "other end".

Since you said the code is correct, I'll assume that the OCL
specification is incorrect and has to be adapted to:

let property = "aggregate end" in
property.otherEnd.isComposite implies
(property.upperBound()->isEmpty() or property.upperBound() <= 1)

N.B. The "aggregate end" remains the end with limits on its upper bound.
The definition of "otherEnd" is according to the UML API code. Now I
look at the specification of the notation on p.42:

"An association with aggregationKind = shared differs in notation from
binary associations in adding a hollow diamond as a terminal adornment
at the aggregate end of the association line. The diamond shall be
noticeably smaller than the diamond notation for associations. An
association with aggregationKind = composite likewise has a diamond at
the aggregate end, but differs in having the diamond filled in."

The "adornment" is added at the "aggregate end". It follows that in
Fig.12.22, the composition association between ConditionalNode and
OutputPin has its aggregate end drawn at the top according to the spec.
The other end of the "aggregate end" ("result") should have isComposite
= true according to the *new* OCL statement, which is what you said earlier.

So, the real question here is whether:
(1) property = "aggregate end" iff property.isComposite (original OCL
statement), or
(2) property = "aggregate end" iff property.otherEnd.isComposite (new
OCL statement).

Note that in case (2), Constraint [2] is only defined if "otherEnd" is
defined. According to the code, "otherEnd" is defined only for binary
associations. There is no equivalent of "otherEnd" in the UML 2.1.1
Superstructure specification ("opposite" from Constraint [1] resembles
it, but is different).

Is case (2) really what you mean?

--
Regards,
Dennis

James Bruck schreef:
> Hi Dennis,,
>
> After re-reading that constraint ... I can really understand the confusion
> about this point. I just spoke to Bran Selic ( chair of OMG ) to clarify
> that for me and there does seem to be an issue there that should be cleaned
> up. He mentioned that there were long debates over this point but the way
> the UML API implements this constraint is correct. Have a look at the
> PropertyOperations.validateMultiplicityOfComposite() for the proper
> implementation.
>
> When I come across the RTF (defect number) for that issue I will post it
> here.
>
> ... so I still stick to the original response that I gave :)
>
> I hope that helps.
>
> Regards,
>
> - James.
>
>
>
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:eurtb8$vbj$2@build.eclipse.org...
>> Hi Dennis,
>>
>> ... let me try to convince you ... :)
>>
>> Take just about any figure in the UML spec illustrating the UML metamodel.
>> For instance, from the 07-02-05 version take figure 12.22 for structured
>> nodes.
>> Notice the composition association between ConditionalNode and OutputPin.
>> ConditionalNode has a part called "result" of multiplicity [*].
> "result"
>> is shown on the end that is opposite the diamond along with the [*]
>> multiplicity. Also, on the end with the diamond we have the multiplicity
>> [0..1]. The isComposite() of "result" would be true in that case and is
>> shown on the dst end.
>> If what you are implying is correct then I think that means that all the
>> diagrams in the spec are backwards.
>>
>> I agree that the constraint from the spec that is quoted below does seem
> to
>> be worded imprecisely.
>>
>> ... are you convinced ?.... :)
>>
>> p.41 of the spec describes the notation.
>>
>> Regards,
>>
>> - James.
>>
>>
>> "Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
>> news:euq864$cue$1@build.eclipse.org...
>>> Nikos Giannopoulos schreef:
>>>> Thank you for your time James. Since the uml2tools contains bugs could
>> you
>>>> suggest a tool (freeware of course) in which you can graphically
> create
>>>> efficiently UML2 diagrams? I need to create UML2 diagrams and then
>> transform
>>>> them (the models) to ecore files and finally create EMF editors for
>> those.
>>>> Thank you,
>>>> Nikos
>>>>
>>>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>>>> news:etmo6v$tsu$2@utils.eclipse.org...
>>>>> Hi Nikos,
>>>>>
>>>>> There is a bug in uml2tools in how it displays these things ... the
>>>>> diamond
>>>>> is on the wrong side :) Please raise a bugzilla on them to get that
>>>>> fixed.
>>>>>
>>>>> Regards,
>>>>>
>>>>> By the way, in general "Class" should also probably own the
> composed
>>>>> property ( not the association ) as your serialized version shows.
>>>>>
>>>>> - James.
>>>>>
>>>>>
>>> The TopCased UML editor (www.topcased.org) has the same behaviour as
>>> uml2tools. I'm getting suspicious...
>>>
>>> Aggregration=Composite is now on the src side, where src points to the
>>> "owner" classifier in the association. In UML 1.4, this is similar:
>>> association ends that point to the "owner" classifier are marked as
>>> ak_composite. Poseidon for UML implemented it this way.
>>>
>>>> The constraint in the spec is in section 7.3.43 : [2] A multiplicity
> on
>> an
>>>> aggregate end of a composite aggregation must not have an upper bound
>>>> greater than 1. isComposite implies (upperBound()->isEmpty() or
>> upperBound()
>>>> <= 1)
>>> Ah, natural language... I interpret:
>>>
>>> aggregate end of a composite aggregation = src
>>>
>>> The multiplicity of src is indeed 1, since there should only be one
>>> owner for any object. So, src->isComposite() must be true.
>>>
>>> It is feasible for the src classifier to own multiple instances of the
>>> dst classifier. Hence, the multiplicity of dst may be greater than 1.
>>> Given the constraint from the UML spec, dst->isComposite() must be
> false.
>>> Looks like UML2 intended the same semantics for Property elements as UML
>>> 1.4 did for AssociationEnd elements. Can you verify this please? It
>>> would mean that Nikos was right.
>>>
>>> --
>>> Regards,
>>> Dennis
>>
>
>
Re: UML2 Composite Association Bug? [message #472216 is a reply to message #472209] Tue, 03 April 2007 19:51 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Dennis,

The OCL expression for this constraint (among many, many others) in the
specification is incorrect, as you've discovered. I was sure that an issue
had been raised for this (we discovered the problem when we did the initial
UML2 implementation over four years ago), but I guess is hadn't. :(

I would contend that the "aggregate end" of an assocation is the one on
which the diamond (solid or hollow) adornment is displayed and that this
property is the opposite of the property whose aggregation is something
other than 'none'. Note that only binary associations can be aggregations,
as stated in section 7.3.3 of the specification.

Kenn

"Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
news:euthho$d7i$1@build.eclipse.org...
> Hi James,
>
> Thank you very much for the elaborate explanation :-). I really appreciate
> you taking the time to dig into this issue. I've looked at several things
> now:
>
> UML 2.1.1 Superstructure:
> - Notation specification on p.42
> - Example composition association in Fig.12.22, p.308
> - Abstract syntax/meta-model of Association in Fig.7.12, p.32
> - Constraint [2] on p.124
>
> The implementation of
> PropertyOperations.validateMultiplicityOfComposite():
> http://dev.eclipse.org/viewcvs/indextools.cgi/org.eclipse.um l2/plugins/org.eclipse.uml2/src/org/eclipse/uml2/internal/op eration/PropertyOperations.java?revision=1.21&view=marku p
>
> As far as I understand Constraint [2], the "aggregate end" of a composite
> aggregation is the one that has limits on its upper bound. That implies
> that the context of the accompanying OCL statement must be the "aggregate
> end":
>
> let property = "aggregate end" in
> property.isComposite implies
> (property.upperBound()->isEmpty() or property.upperBound() <= 1)
>
> Now I look at the code of
> PropertyOperations.validateMultiplicityOfComposite():
>
> boolean result = true;
>
> if (property.isComposite()) {
> Property otherEnd = property.getOtherEnd();
>
> if (null != otherEnd) {
> int upperBound = otherEnd.upperBound();
>
> if (MultiplicityElement.UNLIMITED_UPPER_BOUND == upperBound
> || 1 < upperBound) {
>
> result = false;
>
> if (null != diagnostics) {
> diagnostics
> .add(new BasicDiagnostic( Diagnostic.WARNING,
> UML2Validator.DIAGNOSTIC_SOURCE,
> UML2Validator.PROPERTY__MULTIPLICITY_OF_COMPOSITE,
> UML2Plugin.INSTANCE
> .getString(
> "_UI_Property_MultiplicityOfComposite_diagnostic",
> //$NON-NLS-1$
> getMessageSubstitutions(context,
> property)), new Object[]{property,
> new Integer(upperBound)}));
> }
> }
> }
> }
>
> return result;
>
> So, the code checks if "property.isComposite()" is true. It then goes on
> to check the multiplicity of the *other* end, instead of the multiplicity
> of "property". That is inconsistent with the OCL specification of
> Constraint [2]. I will for now ignore the fact that only binary
> associations have an "other end".
>
> Since you said the code is correct, I'll assume that the OCL specification
> is incorrect and has to be adapted to:
>
> let property = "aggregate end" in
> property.otherEnd.isComposite implies
> (property.upperBound()->isEmpty() or property.upperBound() <= 1)
>
> N.B. The "aggregate end" remains the end with limits on its upper bound.
> The definition of "otherEnd" is according to the UML API code. Now I look
> at the specification of the notation on p.42:
>
> "An association with aggregationKind = shared differs in notation from
> binary associations in adding a hollow diamond as a terminal adornment at
> the aggregate end of the association line. The diamond shall be noticeably
> smaller than the diamond notation for associations. An association with
> aggregationKind = composite likewise has a diamond at the aggregate end,
> but differs in having the diamond filled in."
>
> The "adornment" is added at the "aggregate end". It follows that in
> Fig.12.22, the composition association between ConditionalNode and
> OutputPin has its aggregate end drawn at the top according to the spec.
> The other end of the "aggregate end" ("result") should have isComposite =
> true according to the *new* OCL statement, which is what you said earlier.
>
> So, the real question here is whether:
> (1) property = "aggregate end" iff property.isComposite (original OCL
> statement), or
> (2) property = "aggregate end" iff property.otherEnd.isComposite (new OCL
> statement).
>
> Note that in case (2), Constraint [2] is only defined if "otherEnd" is
> defined. According to the code, "otherEnd" is defined only for binary
> associations. There is no equivalent of "otherEnd" in the UML 2.1.1
> Superstructure specification ("opposite" from Constraint [1] resembles it,
> but is different).
>
> Is case (2) really what you mean?
>
> --
> Regards,
> Dennis
>
> James Bruck schreef:
>> Hi Dennis,,
>>
>> After re-reading that constraint ... I can really understand the
>> confusion
>> about this point. I just spoke to Bran Selic ( chair of OMG ) to
>> clarify
>> that for me and there does seem to be an issue there that should be
>> cleaned
>> up. He mentioned that there were long debates over this point but the
>> way
>> the UML API implements this constraint is correct. Have a look at the
>> PropertyOperations.validateMultiplicityOfComposite() for the proper
>> implementation.
>>
>> When I come across the RTF (defect number) for that issue I will post it
>> here.
>>
>> ... so I still stick to the original response that I gave :)
>>
>> I hope that helps.
>>
>> Regards,
>>
>> - James.
>>
>>
>>
>>
>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> news:eurtb8$vbj$2@build.eclipse.org...
>>> Hi Dennis,
>>>
>>> ... let me try to convince you ... :)
>>>
>>> Take just about any figure in the UML spec illustrating the UML
>>> metamodel.
>>> For instance, from the 07-02-05 version take figure 12.22 for structured
>>> nodes.
>>> Notice the composition association between ConditionalNode and
>>> OutputPin.
>>> ConditionalNode has a part called "result" of multiplicity [*].
>> "result"
>>> is shown on the end that is opposite the diamond along with the [*]
>>> multiplicity. Also, on the end with the diamond we have the
>>> multiplicity
>>> [0..1]. The isComposite() of "result" would be true in that case and
>>> is
>>> shown on the dst end.
>>> If what you are implying is correct then I think that means that all the
>>> diagrams in the spec are backwards.
>>>
>>> I agree that the constraint from the spec that is quoted below does seem
>> to
>>> be worded imprecisely.
>>>
>>> ... are you convinced ?.... :)
>>>
>>> p.41 of the spec describes the notation.
>>>
>>> Regards,
>>>
>>> - James.
>>>
>>>
>>> "Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
>>> news:euq864$cue$1@build.eclipse.org...
>>>> Nikos Giannopoulos schreef:
>>>>> Thank you for your time James. Since the uml2tools contains bugs could
>>> you
>>>>> suggest a tool (freeware of course) in which you can graphically
>> create
>>>>> efficiently UML2 diagrams? I need to create UML2 diagrams and then
>>> transform
>>>>> them (the models) to ecore files and finally create EMF editors for
>>> those.
>>>>> Thank you,
>>>>> Nikos
>>>>>
>>>>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>>>>> news:etmo6v$tsu$2@utils.eclipse.org...
>>>>>> Hi Nikos,
>>>>>>
>>>>>> There is a bug in uml2tools in how it displays these things ... the
>>>>>> diamond
>>>>>> is on the wrong side :) Please raise a bugzilla on them to get that
>>>>>> fixed.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> By the way, in general "Class" should also probably own the
>> composed
>>>>>> property ( not the association ) as your serialized version shows.
>>>>>>
>>>>>> - James.
>>>>>>
>>>>>>
>>>> The TopCased UML editor (www.topcased.org) has the same behaviour as
>>>> uml2tools. I'm getting suspicious...
>>>>
>>>> Aggregration=Composite is now on the src side, where src points to the
>>>> "owner" classifier in the association. In UML 1.4, this is similar:
>>>> association ends that point to the "owner" classifier are marked as
>>>> ak_composite. Poseidon for UML implemented it this way.
>>>>
>>>>> The constraint in the spec is in section 7.3.43 : [2] A multiplicity
>> on
>>> an
>>>>> aggregate end of a composite aggregation must not have an upper bound
>>>>> greater than 1. isComposite implies (upperBound()->isEmpty() or
>>> upperBound()
>>>>> <= 1)
>>>> Ah, natural language... I interpret:
>>>>
>>>> aggregate end of a composite aggregation = src
>>>>
>>>> The multiplicity of src is indeed 1, since there should only be one
>>>> owner for any object. So, src->isComposite() must be true.
>>>>
>>>> It is feasible for the src classifier to own multiple instances of the
>>>> dst classifier. Hence, the multiplicity of dst may be greater than 1.
>>>> Given the constraint from the UML spec, dst->isComposite() must be
>> false.
>>>> Looks like UML2 intended the same semantics for Property elements as
>>>> UML
>>>> 1.4 did for AssociationEnd elements. Can you verify this please? It
>>>> would mean that Nikos was right.
>>>>
>>>> --
>>>> Regards,
>>>> Dennis
>>>
>>
Re: UML2 Composite Association Bug? [message #472489 is a reply to message #472216] Thu, 05 April 2007 12:10 Go to previous message
Dennis Wagelaar is currently offline Dennis WagelaarFriend
Messages: 147
Registered: July 2009
Senior Member
Hi Kenn,

That clears up the situation, thanks! Is this issue currently on the
agenda for the UML specification?

Kind regards,
Dennis

Kenn Hussey schreef:
> Dennis,
>
> The OCL expression for this constraint (among many, many others) in the
> specification is incorrect, as you've discovered. I was sure that an issue
> had been raised for this (we discovered the problem when we did the initial
> UML2 implementation over four years ago), but I guess is hadn't. :(
>
> I would contend that the "aggregate end" of an assocation is the one on
> which the diamond (solid or hollow) adornment is displayed and that this
> property is the opposite of the property whose aggregation is something
> other than 'none'. Note that only binary associations can be aggregations,
> as stated in section 7.3.3 of the specification.
>
> Kenn
>
> "Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
> news:euthho$d7i$1@build.eclipse.org...
>> Hi James,
>>
>> Thank you very much for the elaborate explanation :-). I really appreciate
>> you taking the time to dig into this issue. I've looked at several things
>> now:
>>
>> UML 2.1.1 Superstructure:
>> - Notation specification on p.42
>> - Example composition association in Fig.12.22, p.308
>> - Abstract syntax/meta-model of Association in Fig.7.12, p.32
>> - Constraint [2] on p.124
>>
>> The implementation of
>> PropertyOperations.validateMultiplicityOfComposite():
>> http://dev.eclipse.org/viewcvs/indextools.cgi/org.eclipse.um l2/plugins/org.eclipse.uml2/src/org/eclipse/uml2/internal/op eration/PropertyOperations.java?revision=1.21&view=marku p
>>
>> As far as I understand Constraint [2], the "aggregate end" of a composite
>> aggregation is the one that has limits on its upper bound. That implies
>> that the context of the accompanying OCL statement must be the "aggregate
>> end":
>>
>> let property = "aggregate end" in
>> property.isComposite implies
>> (property.upperBound()->isEmpty() or property.upperBound() <= 1)
>>
>> Now I look at the code of
>> PropertyOperations.validateMultiplicityOfComposite():
>>
>> boolean result = true;
>>
>> if (property.isComposite()) {
>> Property otherEnd = property.getOtherEnd();
>>
>> if (null != otherEnd) {
>> int upperBound = otherEnd.upperBound();
>>
>> if (MultiplicityElement.UNLIMITED_UPPER_BOUND == upperBound
>> || 1 < upperBound) {
>>
>> result = false;
>>
>> if (null != diagnostics) {
>> diagnostics
>> .add(new BasicDiagnostic( Diagnostic.WARNING,
>> UML2Validator.DIAGNOSTIC_SOURCE,
>> UML2Validator.PROPERTY__MULTIPLICITY_OF_COMPOSITE,
>> UML2Plugin.INSTANCE
>> .getString(
>> "_UI_Property_MultiplicityOfComposite_diagnostic",
>> //$NON-NLS-1$
>> getMessageSubstitutions(context,
>> property)), new Object[]{property,
>> new Integer(upperBound)}));
>> }
>> }
>> }
>> }
>>
>> return result;
>>
>> So, the code checks if "property.isComposite()" is true. It then goes on
>> to check the multiplicity of the *other* end, instead of the multiplicity
>> of "property". That is inconsistent with the OCL specification of
>> Constraint [2]. I will for now ignore the fact that only binary
>> associations have an "other end".
>>
>> Since you said the code is correct, I'll assume that the OCL specification
>> is incorrect and has to be adapted to:
>>
>> let property = "aggregate end" in
>> property.otherEnd.isComposite implies
>> (property.upperBound()->isEmpty() or property.upperBound() <= 1)
>>
>> N.B. The "aggregate end" remains the end with limits on its upper bound.
>> The definition of "otherEnd" is according to the UML API code. Now I look
>> at the specification of the notation on p.42:
>>
>> "An association with aggregationKind = shared differs in notation from
>> binary associations in adding a hollow diamond as a terminal adornment at
>> the aggregate end of the association line. The diamond shall be noticeably
>> smaller than the diamond notation for associations. An association with
>> aggregationKind = composite likewise has a diamond at the aggregate end,
>> but differs in having the diamond filled in."
>>
>> The "adornment" is added at the "aggregate end". It follows that in
>> Fig.12.22, the composition association between ConditionalNode and
>> OutputPin has its aggregate end drawn at the top according to the spec.
>> The other end of the "aggregate end" ("result") should have isComposite =
>> true according to the *new* OCL statement, which is what you said earlier.
>>
>> So, the real question here is whether:
>> (1) property = "aggregate end" iff property.isComposite (original OCL
>> statement), or
>> (2) property = "aggregate end" iff property.otherEnd.isComposite (new OCL
>> statement).
>>
>> Note that in case (2), Constraint [2] is only defined if "otherEnd" is
>> defined. According to the code, "otherEnd" is defined only for binary
>> associations. There is no equivalent of "otherEnd" in the UML 2.1.1
>> Superstructure specification ("opposite" from Constraint [1] resembles it,
>> but is different).
>>
>> Is case (2) really what you mean?
>>
>> --
>> Regards,
>> Dennis
>>
>> James Bruck schreef:
>>> Hi Dennis,,
>>>
>>> After re-reading that constraint ... I can really understand the
>>> confusion
>>> about this point. I just spoke to Bran Selic ( chair of OMG ) to
>>> clarify
>>> that for me and there does seem to be an issue there that should be
>>> cleaned
>>> up. He mentioned that there were long debates over this point but the
>>> way
>>> the UML API implements this constraint is correct. Have a look at the
>>> PropertyOperations.validateMultiplicityOfComposite() for the proper
>>> implementation.
>>>
>>> When I come across the RTF (defect number) for that issue I will post it
>>> here.
>>>
>>> ... so I still stick to the original response that I gave :)
>>>
>>> I hope that helps.
>>>
>>> Regards,
>>>
>>> - James.
>>>
>>>
>>>
>>>
>>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>>> news:eurtb8$vbj$2@build.eclipse.org...
>>>> Hi Dennis,
>>>>
>>>> ... let me try to convince you ... :)
>>>>
>>>> Take just about any figure in the UML spec illustrating the UML
>>>> metamodel.
>>>> For instance, from the 07-02-05 version take figure 12.22 for structured
>>>> nodes.
>>>> Notice the composition association between ConditionalNode and
>>>> OutputPin.
>>>> ConditionalNode has a part called "result" of multiplicity [*].
>>> "result"
>>>> is shown on the end that is opposite the diamond along with the [*]
>>>> multiplicity. Also, on the end with the diamond we have the
>>>> multiplicity
>>>> [0..1]. The isComposite() of "result" would be true in that case and
>>>> is
>>>> shown on the dst end.
>>>> If what you are implying is correct then I think that means that all the
>>>> diagrams in the spec are backwards.
>>>>
>>>> I agree that the constraint from the spec that is quoted below does seem
>>> to
>>>> be worded imprecisely.
>>>>
>>>> ... are you convinced ?.... :)
>>>>
>>>> p.41 of the spec describes the notation.
>>>>
>>>> Regards,
>>>>
>>>> - James.
>>>>
>>>>
>>>> "Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
>>>> news:euq864$cue$1@build.eclipse.org...
>>>>> Nikos Giannopoulos schreef:
>>>>>> Thank you for your time James. Since the uml2tools contains bugs could
>>>> you
>>>>>> suggest a tool (freeware of course) in which you can graphically
>>> create
>>>>>> efficiently UML2 diagrams? I need to create UML2 diagrams and then
>>>> transform
>>>>>> them (the models) to ecore files and finally create EMF editors for
>>>> those.
>>>>>> Thank you,
>>>>>> Nikos
>>>>>>
>>>>>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>>>>>> news:etmo6v$tsu$2@utils.eclipse.org...
>>>>>>> Hi Nikos,
>>>>>>>
>>>>>>> There is a bug in uml2tools in how it displays these things ... the
>>>>>>> diamond
>>>>>>> is on the wrong side :) Please raise a bugzilla on them to get that
>>>>>>> fixed.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> By the way, in general "Class" should also probably own the
>>> composed
>>>>>>> property ( not the association ) as your serialized version shows.
>>>>>>>
>>>>>>> - James.
>>>>>>>
>>>>>>>
>>>>> The TopCased UML editor (www.topcased.org) has the same behaviour as
>>>>> uml2tools. I'm getting suspicious...
>>>>>
>>>>> Aggregration=Composite is now on the src side, where src points to the
>>>>> "owner" classifier in the association. In UML 1.4, this is similar:
>>>>> association ends that point to the "owner" classifier are marked as
>>>>> ak_composite. Poseidon for UML implemented it this way.
>>>>>
>>>>>> The constraint in the spec is in section 7.3.43 : [2] A multiplicity
>>> on
>>>> an
>>>>>> aggregate end of a composite aggregation must not have an upper bound
>>>>>> greater than 1. isComposite implies (upperBound()->isEmpty() or
>>>> upperBound()
>>>>>> <= 1)
>>>>> Ah, natural language... I interpret:
>>>>>
>>>>> aggregate end of a composite aggregation = src
>>>>>
>>>>> The multiplicity of src is indeed 1, since there should only be one
>>>>> owner for any object. So, src->isComposite() must be true.
>>>>>
>>>>> It is feasible for the src classifier to own multiple instances of the
>>>>> dst classifier. Hence, the multiplicity of dst may be greater than 1.
>>>>> Given the constraint from the UML spec, dst->isComposite() must be
>>> false.
>>>>> Looks like UML2 intended the same semantics for Property elements as
>>>>> UML
>>>>> 1.4 did for AssociationEnd elements. Can you verify this please? It
>>>>> would mean that Nikos was right.
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Dennis
>
Re: UML2 Composite Association Bug? [message #599664 is a reply to message #471655] Mon, 19 March 2007 16:06 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Nikos,

It sounds like you are modifying the cardinality to * of the wrong end. I
had a look at the implementation of the constraint on PropertyOperations()
and it seems ok.
The constraint in the spec is in section 7.3.43 : [2] A multiplicity on an
aggregate end of a composite aggregation must not have an upper bound
greater than 1. isComposite implies (upperBound()->isEmpty() or upperBound()
<= 1)
Kenn mentioned that there was a change from the old implementation as to how
the multiplicities are treated, but the constraint implentation and the
constraint itself seem fine.

Regards,

- James.



"Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
news:C220F522.19CD%nikos@swen.uwaterloo.ca...
> Hi all,
> I have started to implement a metamodel using the Eclipse UML2 editor.
When
> I create a composite association between a concrete class (source) and an
> abstract class (target) and then set the target cardinality to * and
> try to validate my model it returns that it is invalid and that the target
> cardinality of a composite association should not be greater than 1!!! Is
> that a bug? (message: "The multiplicity of composite aggregation
>
'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
> has an upper bound greater than 1.")
> Furthermore when I try to convert my UML2 model to Ecore my valid
composite
> associations are not shown in my Ecore model..Another bug perhaps or am I
> doing something wrong?
> Thanks,
> Nikos
>
Re: UML2 Composite Association Bug? [message #599677 is a reply to message #471722] Mon, 19 March 2007 16:31 Go to previous message
Eclipse UserFriend
Originally posted by: nikos.swen.uwaterloo.ca

Hi James,
I attached a snapshot of the association I'm trying to implement..Is this
invalid?
The error I get is "The multiplicity of composite aggregation '<Property>
dst : Class1 [0..*]' has an upper bound greater than 1."
Why is this invalid? Is there another way to implement it?
Regards,
Nikos

"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:etmce4$rup$2@utils.eclipse.org...
> Hi Nikos,
>
> It sounds like you are modifying the cardinality to * of the wrong end. I
> had a look at the implementation of the constraint on PropertyOperations()
> and it seems ok.
> The constraint in the spec is in section 7.3.43 : [2] A multiplicity on an
> aggregate end of a composite aggregation must not have an upper bound
> greater than 1. isComposite implies (upperBound()->isEmpty() or
> upperBound()
> <= 1)
> Kenn mentioned that there was a change from the old implementation as to
> how
> the multiplicities are treated, but the constraint implentation and the
> constraint itself seem fine.
>
> Regards,
>
> - James.
>
>
>
> "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> news:C220F522.19CD%nikos@swen.uwaterloo.ca...
>> Hi all,
>> I have started to implement a metamodel using the Eclipse UML2 editor.
> When
>> I create a composite association between a concrete class (source) and
>> an
>> abstract class (target) and then set the target cardinality to * and
>> try to validate my model it returns that it is invalid and that the
>> target
>> cardinality of a composite association should not be greater than 1!!! Is
>> that a bug? (message: "The multiplicity of composite aggregation
>>
> 'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
>> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
>> has an upper bound greater than 1.")
>> Furthermore when I try to convert my UML2 model to Ecore my valid
> composite
>> associations are not shown in my Ecore model..Another bug perhaps or am I
>> doing something wrong?
>> Thanks,
>> Nikos
>>
>
>


  • Attachment: default.gif
    (Size: 2.44KB, Downloaded 182 times)
Re: UML2 Composite Association Bug? [message #599682 is a reply to message #471723] Mon, 19 March 2007 17:18 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Nikos,

If the multiplicity of src is 1 then this is a valid diagram. The
isComposite of dst should be true and the isComposite of src should be
false.
Can you verify that?

You might have a display issue? If the multiplicity of src was * and the
composition was the other way, then I would expect that error.

Can you post your model and I'll give it a look over.

Regards,

- James.



"Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
news:etmdtu$vup$1@utils.eclipse.org...
> Hi James,
> I attached a snapshot of the association I'm trying to implement..Is this
> invalid?
> The error I get is "The multiplicity of composite aggregation '<Property>
> dst : Class1 [0..*]' has an upper bound greater than 1."
> Why is this invalid? Is there another way to implement it?
> Regards,
> Nikos
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:etmce4$rup$2@utils.eclipse.org...
> > Hi Nikos,
> >
> > It sounds like you are modifying the cardinality to * of the wrong end.
I
> > had a look at the implementation of the constraint on
PropertyOperations()
> > and it seems ok.
> > The constraint in the spec is in section 7.3.43 : [2] A multiplicity on
an
> > aggregate end of a composite aggregation must not have an upper bound
> > greater than 1. isComposite implies (upperBound()->isEmpty() or
> > upperBound()
> > <= 1)
> > Kenn mentioned that there was a change from the old implementation as to
> > how
> > the multiplicities are treated, but the constraint implentation and the
> > constraint itself seem fine.
> >
> > Regards,
> >
> > - James.
> >
> >
> >
> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> > news:C220F522.19CD%nikos@swen.uwaterloo.ca...
> >> Hi all,
> >> I have started to implement a metamodel using the Eclipse UML2 editor.
> > When
> >> I create a composite association between a concrete class (source) and
> >> an
> >> abstract class (target) and then set the target cardinality to * and
> >> try to validate my model it returns that it is invalid and that the
> >> target
> >> cardinality of a composite association should not be greater than 1!!!
Is
> >> that a bug? (message: "The multiplicity of composite aggregation
> >>
> >
'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
> >> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
> >> has an upper bound greater than 1.")
> >> Furthermore when I try to convert my UML2 model to Ecore my valid
> > composite
> >> associations are not shown in my Ecore model..Another bug perhaps or am
I
> >> doing something wrong?
> >> Thanks,
> >> Nikos
> >>
> >
> >
>
>
>
Re: UML2 Composite Association Bug? [message #601771 is a reply to message #471724] Mon, 19 March 2007 17:28 Go to previous message
Eclipse UserFriend
Originally posted by: nikos.swen.uwaterloo.ca

Hi James,

The multiplicity of src is 1. I couldn't find the isComposite attribute on
either dst or src.
I use Eclipse Version 3.3.0, Build id I20070222-0951 and UML2 v.2.1M5.
I attach both the UML2 model and the corresponding diagram.

Ragards,
Nikos

"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:etmgle$6qb$2@utils.eclipse.org...
> Hi Nikos,
>
> If the multiplicity of src is 1 then this is a valid diagram. The
> isComposite of dst should be true and the isComposite of src should be
> false.
> Can you verify that?
>
> You might have a display issue? If the multiplicity of src was * and the
> composition was the other way, then I would expect that error.
>
> Can you post your model and I'll give it a look over.
>
> Regards,
>
> - James.
>
>
>
> "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> news:etmdtu$vup$1@utils.eclipse.org...
>> Hi James,
>> I attached a snapshot of the association I'm trying to implement..Is this
>> invalid?
>> The error I get is "The multiplicity of composite aggregation '<Property>
>> dst : Class1 [0..*]' has an upper bound greater than 1."
>> Why is this invalid? Is there another way to implement it?
>> Regards,
>> Nikos
>>
>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> news:etmce4$rup$2@utils.eclipse.org...
>> > Hi Nikos,
>> >
>> > It sounds like you are modifying the cardinality to * of the wrong end.
> I
>> > had a look at the implementation of the constraint on
> PropertyOperations()
>> > and it seems ok.
>> > The constraint in the spec is in section 7.3.43 : [2] A multiplicity on
> an
>> > aggregate end of a composite aggregation must not have an upper bound
>> > greater than 1. isComposite implies (upperBound()->isEmpty() or
>> > upperBound()
>> > <= 1)
>> > Kenn mentioned that there was a change from the old implementation as
>> > to
>> > how
>> > the multiplicities are treated, but the constraint implentation and the
>> > constraint itself seem fine.
>> >
>> > Regards,
>> >
>> > - James.
>> >
>> >
>> >
>> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
>> > news:C220F522.19CD%nikos@swen.uwaterloo.ca...
>> >> Hi all,
>> >> I have started to implement a metamodel using the Eclipse UML2 editor.
>> > When
>> >> I create a composite association between a concrete class (source)
>> >> and
>> >> an
>> >> abstract class (target) and then set the target cardinality to * and
>> >> try to validate my model it returns that it is invalid and that the
>> >> target
>> >> cardinality of a composite association should not be greater than 1!!!
> Is
>> >> that a bug? (message: "The multiplicity of composite aggregation
>> >>
>> >
> 'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
>> >> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
>> >> has an upper bound greater than 1.")
>> >> Furthermore when I try to convert my UML2 model to Ecore my valid
>> > composite
>> >> associations are not shown in my Ecore model..Another bug perhaps or
>> >> am
> I
>> >> doing something wrong?
>> >> Thanks,
>> >> Nikos
>> >>
>> >
>> >
>>
>>
>>
>
>



Re: UML2 Composite Association Bug? [message #601790 is a reply to message #471725] Mon, 19 March 2007 18:26 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Nikos,

I just had a look at the serialized version. Looks like your composite
aggregation is on the wrong side. ... ie, your picture does not reflect
what you have in the serialized version.

Have a look at src, aggregation=composite. That should be on the dst
side... (the isComposite is derived so it is not serialized out but you
could use the API).

You can simply try to cut and paste that attribute over and it should
validate fine :)


Regards,

- James.



"Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
news:etmh8g$81s$1@utils.eclipse.org...
> Hi James,
>
> The multiplicity of src is 1. I couldn't find the isComposite attribute on
> either dst or src.
> I use Eclipse Version 3.3.0, Build id I20070222-0951 and UML2 v.2.1M5.
> I attach both the UML2 model and the corresponding diagram.
>
> Ragards,
> Nikos
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:etmgle$6qb$2@utils.eclipse.org...
> > Hi Nikos,
> >
> > If the multiplicity of src is 1 then this is a valid diagram. The
> > isComposite of dst should be true and the isComposite of src should be
> > false.
> > Can you verify that?
> >
> > You might have a display issue? If the multiplicity of src was * and
the
> > composition was the other way, then I would expect that error.
> >
> > Can you post your model and I'll give it a look over.
> >
> > Regards,
> >
> > - James.
> >
> >
> >
> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> > news:etmdtu$vup$1@utils.eclipse.org...
> >> Hi James,
> >> I attached a snapshot of the association I'm trying to implement..Is
this
> >> invalid?
> >> The error I get is "The multiplicity of composite aggregation
'<Property>
> >> dst : Class1 [0..*]' has an upper bound greater than 1."
> >> Why is this invalid? Is there another way to implement it?
> >> Regards,
> >> Nikos
> >>
> >> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> >> news:etmce4$rup$2@utils.eclipse.org...
> >> > Hi Nikos,
> >> >
> >> > It sounds like you are modifying the cardinality to * of the wrong
end.
> > I
> >> > had a look at the implementation of the constraint on
> > PropertyOperations()
> >> > and it seems ok.
> >> > The constraint in the spec is in section 7.3.43 : [2] A multiplicity
on
> > an
> >> > aggregate end of a composite aggregation must not have an upper bound
> >> > greater than 1. isComposite implies (upperBound()->isEmpty() or
> >> > upperBound()
> >> > <= 1)
> >> > Kenn mentioned that there was a change from the old implementation as
> >> > to
> >> > how
> >> > the multiplicities are treated, but the constraint implentation and
the
> >> > constraint itself seem fine.
> >> >
> >> > Regards,
> >> >
> >> > - James.
> >> >
> >> >
> >> >
> >> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> >> > news:C220F522.19CD%nikos@swen.uwaterloo.ca...
> >> >> Hi all,
> >> >> I have started to implement a metamodel using the Eclipse UML2
editor.
> >> > When
> >> >> I create a composite association between a concrete class (source)
> >> >> and
> >> >> an
> >> >> abstract class (target) and then set the target cardinality to * and
> >> >> try to validate my model it returns that it is invalid and that the
> >> >> target
> >> >> cardinality of a composite association should not be greater than
1!!!
> > Is
> >> >> that a bug? (message: "The multiplicity of composite aggregation
> >> >>
> >> >
> >
'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
> >> >> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
> >> >> has an upper bound greater than 1.")
> >> >> Furthermore when I try to convert my UML2 model to Ecore my valid
> >> > composite
> >> >> associations are not shown in my Ecore model..Another bug perhaps or
> >> >> am
> > I
> >> >> doing something wrong?
> >> >> Thanks,
> >> >> Nikos
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >
> >
>
>
>
Re: UML2 Composite Association Bug? [message #601797 is a reply to message #471727] Mon, 19 March 2007 18:38 Go to previous message
Eclipse UserFriend
Originally posted by: nikos.swen.uwaterloo.ca

Hi James,

I did what you suggested but then the diagram looks like the one I attached,
but this in not what I want. The diamond of the composition should be on the
src side but instead it is shown in the dst side. All I want to implement is
an aggregation (from src to dst) which will have cardinality 1 at the src
side and 0..* at the dst side. Could you create one and send me the model
and the .umlclass_diagram plz? I still think there is a problem. I use the
uml2tools to implement the diagrams.

Regards,
Nikos

"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:etmkkd$hjd$2@utils.eclipse.org...
> Hi Nikos,
>
> I just had a look at the serialized version. Looks like your composite
> aggregation is on the wrong side. ... ie, your picture does not reflect
> what you have in the serialized version.
>
> Have a look at src, aggregation=composite. That should be on the dst
> side... (the isComposite is derived so it is not serialized out but you
> could use the API).
>
> You can simply try to cut and paste that attribute over and it should
> validate fine :)
>
>
> Regards,
>
> - James.
>
>
>
> "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> news:etmh8g$81s$1@utils.eclipse.org...
>> Hi James,
>>
>> The multiplicity of src is 1. I couldn't find the isComposite attribute
>> on
>> either dst or src.
>> I use Eclipse Version 3.3.0, Build id I20070222-0951 and UML2 v.2.1M5.
>> I attach both the UML2 model and the corresponding diagram.
>>
>> Ragards,
>> Nikos
>>
>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> news:etmgle$6qb$2@utils.eclipse.org...
>> > Hi Nikos,
>> >
>> > If the multiplicity of src is 1 then this is a valid diagram. The
>> > isComposite of dst should be true and the isComposite of src should be
>> > false.
>> > Can you verify that?
>> >
>> > You might have a display issue? If the multiplicity of src was * and
> the
>> > composition was the other way, then I would expect that error.
>> >
>> > Can you post your model and I'll give it a look over.
>> >
>> > Regards,
>> >
>> > - James.
>> >
>> >
>> >
>> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
>> > news:etmdtu$vup$1@utils.eclipse.org...
>> >> Hi James,
>> >> I attached a snapshot of the association I'm trying to implement..Is
> this
>> >> invalid?
>> >> The error I get is "The multiplicity of composite aggregation
> '<Property>
>> >> dst : Class1 [0..*]' has an upper bound greater than 1."
>> >> Why is this invalid? Is there another way to implement it?
>> >> Regards,
>> >> Nikos
>> >>
>> >> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> >> news:etmce4$rup$2@utils.eclipse.org...
>> >> > Hi Nikos,
>> >> >
>> >> > It sounds like you are modifying the cardinality to * of the wrong
> end.
>> > I
>> >> > had a look at the implementation of the constraint on
>> > PropertyOperations()
>> >> > and it seems ok.
>> >> > The constraint in the spec is in section 7.3.43 : [2] A multiplicity
> on
>> > an
>> >> > aggregate end of a composite aggregation must not have an upper
>> >> > bound
>> >> > greater than 1. isComposite implies (upperBound()->isEmpty() or
>> >> > upperBound()
>> >> > <= 1)
>> >> > Kenn mentioned that there was a change from the old implementation
>> >> > as
>> >> > to
>> >> > how
>> >> > the multiplicities are treated, but the constraint implentation and
> the
>> >> > constraint itself seem fine.
>> >> >
>> >> > Regards,
>> >> >
>> >> > - James.
>> >> >
>> >> >
>> >> >
>> >> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
>> >> > news:C220F522.19CD%nikos@swen.uwaterloo.ca...
>> >> >> Hi all,
>> >> >> I have started to implement a metamodel using the Eclipse UML2
> editor.
>> >> > When
>> >> >> I create a composite association between a concrete class (source)
>> >> >> and
>> >> >> an
>> >> >> abstract class (target) and then set the target cardinality to *
>> >> >> and
>> >> >> try to validate my model it returns that it is invalid and that the
>> >> >> target
>> >> >> cardinality of a composite association should not be greater than
> 1!!!
>> > Is
>> >> >> that a bug? (message: "The multiplicity of composite aggregation
>> >> >>
>> >> >
>> >
> 'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
>> >> >> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
>> >> >> has an upper bound greater than 1.")
>> >> >> Furthermore when I try to convert my UML2 model to Ecore my valid
>> >> > composite
>> >> >> associations are not shown in my Ecore model..Another bug perhaps
>> >> >> or
>> >> >> am
>> > I
>> >> >> doing something wrong?
>> >> >> Thanks,
>> >> >> Nikos
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>


  • Attachment: default.gif
    (Size: 2.44KB, Downloaded 193 times)
Re: UML2 Composite Association Bug? [message #601805 is a reply to message #471728] Mon, 19 March 2007 19:27 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Nikos,

There is a bug in uml2tools in how it displays these things ... the diamond
is on the wrong side :) Please raise a bugzilla on them to get that fixed.

Regards,

By the way, in general "Class" should also probably own the composed
property ( not the association ) as your serialized version shows.

- James.


"Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
news:etmlb9$n4l$1@utils.eclipse.org...
> Hi James,
>
> I did what you suggested but then the diagram looks like the one I
attached,
> but this in not what I want. The diamond of the composition should be on
the
> src side but instead it is shown in the dst side. All I want to implement
is
> an aggregation (from src to dst) which will have cardinality 1 at the src
> side and 0..* at the dst side. Could you create one and send me the model
> and the .umlclass_diagram plz? I still think there is a problem. I use the
> uml2tools to implement the diagrams.
>
> Regards,
> Nikos
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:etmkkd$hjd$2@utils.eclipse.org...
> > Hi Nikos,
> >
> > I just had a look at the serialized version. Looks like your composite
> > aggregation is on the wrong side. ... ie, your picture does not reflect
> > what you have in the serialized version.
> >
> > Have a look at src, aggregation=composite. That should be on the dst
> > side... (the isComposite is derived so it is not serialized out but you
> > could use the API).
> >
> > You can simply try to cut and paste that attribute over and it should
> > validate fine :)
> >
> >
> > Regards,
> >
> > - James.
> >
> >
> >
> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> > news:etmh8g$81s$1@utils.eclipse.org...
> >> Hi James,
> >>
> >> The multiplicity of src is 1. I couldn't find the isComposite attribute
> >> on
> >> either dst or src.
> >> I use Eclipse Version 3.3.0, Build id I20070222-0951 and UML2 v.2.1M5.
> >> I attach both the UML2 model and the corresponding diagram.
> >>
> >> Ragards,
> >> Nikos
> >>
> >> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> >> news:etmgle$6qb$2@utils.eclipse.org...
> >> > Hi Nikos,
> >> >
> >> > If the multiplicity of src is 1 then this is a valid diagram. The
> >> > isComposite of dst should be true and the isComposite of src should
be
> >> > false.
> >> > Can you verify that?
> >> >
> >> > You might have a display issue? If the multiplicity of src was *
and
> > the
> >> > composition was the other way, then I would expect that error.
> >> >
> >> > Can you post your model and I'll give it a look over.
> >> >
> >> > Regards,
> >> >
> >> > - James.
> >> >
> >> >
> >> >
> >> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> >> > news:etmdtu$vup$1@utils.eclipse.org...
> >> >> Hi James,
> >> >> I attached a snapshot of the association I'm trying to implement..Is
> > this
> >> >> invalid?
> >> >> The error I get is "The multiplicity of composite aggregation
> > '<Property>
> >> >> dst : Class1 [0..*]' has an upper bound greater than 1."
> >> >> Why is this invalid? Is there another way to implement it?
> >> >> Regards,
> >> >> Nikos
> >> >>
> >> >> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> >> >> news:etmce4$rup$2@utils.eclipse.org...
> >> >> > Hi Nikos,
> >> >> >
> >> >> > It sounds like you are modifying the cardinality to * of the wrong
> > end.
> >> > I
> >> >> > had a look at the implementation of the constraint on
> >> > PropertyOperations()
> >> >> > and it seems ok.
> >> >> > The constraint in the spec is in section 7.3.43 : [2] A
multiplicity
> > on
> >> > an
> >> >> > aggregate end of a composite aggregation must not have an upper
> >> >> > bound
> >> >> > greater than 1. isComposite implies (upperBound()->isEmpty() or
> >> >> > upperBound()
> >> >> > <= 1)
> >> >> > Kenn mentioned that there was a change from the old implementation
> >> >> > as
> >> >> > to
> >> >> > how
> >> >> > the multiplicities are treated, but the constraint implentation
and
> > the
> >> >> > constraint itself seem fine.
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > - James.
> >> >> >
> >> >> >
> >> >> >
> >> >> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> >> >> > news:C220F522.19CD%nikos@swen.uwaterloo.ca...
> >> >> >> Hi all,
> >> >> >> I have started to implement a metamodel using the Eclipse UML2
> > editor.
> >> >> > When
> >> >> >> I create a composite association between a concrete class
(source)
> >> >> >> and
> >> >> >> an
> >> >> >> abstract class (target) and then set the target cardinality to *
> >> >> >> and
> >> >> >> try to validate my model it returns that it is invalid and that
the
> >> >> >> target
> >> >> >> cardinality of a composite association should not be greater than
> > 1!!!
> >> > Is
> >> >> >> that a bug? (message: "The multiplicity of composite aggregation
> >> >> >>
> >> >> >
> >> >
> >
'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
> >> >> >> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
> >> >> >> has an upper bound greater than 1.")
> >> >> >> Furthermore when I try to convert my UML2 model to Ecore my valid
> >> >> > composite
> >> >> >> associations are not shown in my Ecore model..Another bug perhaps
> >> >> >> or
> >> >> >> am
> >> > I
> >> >> >> doing something wrong?
> >> >> >> Thanks,
> >> >> >> Nikos
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >
> >
>
>
>
Re: UML2 Composite Association Bug? [message #601816 is a reply to message #471729] Mon, 19 March 2007 19:35 Go to previous message
Eclipse UserFriend
Originally posted by: nikos.swen.uwaterloo.ca

Thank you for your time James. Since the uml2tools contains bugs could you
suggest a tool (freeware of course) in which you can graphically create
efficiently UML2 diagrams? I need to create UML2 diagrams and then transform
them (the models) to ecore files and finally create EMF editors for those.

Thank you,
Nikos

"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:etmo6v$tsu$2@utils.eclipse.org...
> Hi Nikos,
>
> There is a bug in uml2tools in how it displays these things ... the
> diamond
> is on the wrong side :) Please raise a bugzilla on them to get that
> fixed.
>
> Regards,
>
> By the way, in general "Class" should also probably own the composed
> property ( not the association ) as your serialized version shows.
>
> - James.
>
>
> "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
> news:etmlb9$n4l$1@utils.eclipse.org...
>> Hi James,
>>
>> I did what you suggested but then the diagram looks like the one I
> attached,
>> but this in not what I want. The diamond of the composition should be on
> the
>> src side but instead it is shown in the dst side. All I want to implement
> is
>> an aggregation (from src to dst) which will have cardinality 1 at the src
>> side and 0..* at the dst side. Could you create one and send me the model
>> and the .umlclass_diagram plz? I still think there is a problem. I use
>> the
>> uml2tools to implement the diagrams.
>>
>> Regards,
>> Nikos
>>
>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> news:etmkkd$hjd$2@utils.eclipse.org...
>> > Hi Nikos,
>> >
>> > I just had a look at the serialized version. Looks like your
>> > composite
>> > aggregation is on the wrong side. ... ie, your picture does not
>> > reflect
>> > what you have in the serialized version.
>> >
>> > Have a look at src, aggregation=composite. That should be on the
>> > dst
>> > side... (the isComposite is derived so it is not serialized out but you
>> > could use the API).
>> >
>> > You can simply try to cut and paste that attribute over and it should
>> > validate fine :)
>> >
>> >
>> > Regards,
>> >
>> > - James.
>> >
>> >
>> >
>> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
>> > news:etmh8g$81s$1@utils.eclipse.org...
>> >> Hi James,
>> >>
>> >> The multiplicity of src is 1. I couldn't find the isComposite
>> >> attribute
>> >> on
>> >> either dst or src.
>> >> I use Eclipse Version 3.3.0, Build id I20070222-0951 and UML2 v.2.1M5.
>> >> I attach both the UML2 model and the corresponding diagram.
>> >>
>> >> Ragards,
>> >> Nikos
>> >>
>> >> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> >> news:etmgle$6qb$2@utils.eclipse.org...
>> >> > Hi Nikos,
>> >> >
>> >> > If the multiplicity of src is 1 then this is a valid diagram. The
>> >> > isComposite of dst should be true and the isComposite of src should
> be
>> >> > false.
>> >> > Can you verify that?
>> >> >
>> >> > You might have a display issue? If the multiplicity of src was *
> and
>> > the
>> >> > composition was the other way, then I would expect that error.
>> >> >
>> >> > Can you post your model and I'll give it a look over.
>> >> >
>> >> > Regards,
>> >> >
>> >> > - James.
>> >> >
>> >> >
>> >> >
>> >> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
>> >> > news:etmdtu$vup$1@utils.eclipse.org...
>> >> >> Hi James,
>> >> >> I attached a snapshot of the association I'm trying to
>> >> >> implement..Is
>> > this
>> >> >> invalid?
>> >> >> The error I get is "The multiplicity of composite aggregation
>> > '<Property>
>> >> >> dst : Class1 [0..*]' has an upper bound greater than 1."
>> >> >> Why is this invalid? Is there another way to implement it?
>> >> >> Regards,
>> >> >> Nikos
>> >> >>
>> >> >> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> >> >> news:etmce4$rup$2@utils.eclipse.org...
>> >> >> > Hi Nikos,
>> >> >> >
>> >> >> > It sounds like you are modifying the cardinality to * of the
>> >> >> > wrong
>> > end.
>> >> > I
>> >> >> > had a look at the implementation of the constraint on
>> >> > PropertyOperations()
>> >> >> > and it seems ok.
>> >> >> > The constraint in the spec is in section 7.3.43 : [2] A
> multiplicity
>> > on
>> >> > an
>> >> >> > aggregate end of a composite aggregation must not have an upper
>> >> >> > bound
>> >> >> > greater than 1. isComposite implies (upperBound()->isEmpty() or
>> >> >> > upperBound()
>> >> >> > <= 1)
>> >> >> > Kenn mentioned that there was a change from the old
>> >> >> > implementation
>> >> >> > as
>> >> >> > to
>> >> >> > how
>> >> >> > the multiplicities are treated, but the constraint implentation
> and
>> > the
>> >> >> > constraint itself seem fine.
>> >> >> >
>> >> >> > Regards,
>> >> >> >
>> >> >> > - James.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > "Nikos Giannopoulos" <nikos@swen.uwaterloo.ca> wrote in message
>> >> >> > news:C220F522.19CD%nikos@swen.uwaterloo.ca...
>> >> >> >> Hi all,
>> >> >> >> I have started to implement a metamodel using the Eclipse UML2
>> > editor.
>> >> >> > When
>> >> >> >> I create a composite association between a concrete class
> (source)
>> >> >> >> and
>> >> >> >> an
>> >> >> >> abstract class (target) and then set the target cardinality to *
>> >> >> >> and
>> >> >> >> try to validate my model it returns that it is invalid and that
> the
>> >> >> >> target
>> >> >> >> cardinality of a composite association should not be greater
>> >> >> >> than
>> > 1!!!
>> >> > Is
>> >> >> >> that a bug? (message: "The multiplicity of composite aggregation
>> >> >> >>
>> >> >> >
>> >> >
>> >
> 'org.eclipse.uml2.uml.internal.impl.PropertyImpl@12b1e53{platform:/resource/
>> >> >> >> PIM_Metamodel/Models/PIM.uml#_LN8gtNPqEdu8mPPynj20BQ}'
>> >> >> >> has an upper bound greater than 1.")
>> >> >> >> Furthermore when I try to convert my UML2 model to Ecore my
>> >> >> >> valid
>> >> >> > composite
>> >> >> >> associations are not shown in my Ecore model..Another bug
>> >> >> >> perhaps
>> >> >> >> or
>> >> >> >> am
>> >> > I
>> >> >> >> doing something wrong?
>> >> >> >> Thanks,
>> >> >> >> Nikos
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
Re: UML2 Composite Association Bug? [message #604185 is a reply to message #471730] Mon, 02 April 2007 06:34 Go to previous message
Dennis Wagelaar is currently offline Dennis WagelaarFriend
Messages: 147
Registered: July 2009
Senior Member
Nikos Giannopoulos schreef:
> Thank you for your time James. Since the uml2tools contains bugs could you
> suggest a tool (freeware of course) in which you can graphically create
> efficiently UML2 diagrams? I need to create UML2 diagrams and then transform
> them (the models) to ecore files and finally create EMF editors for those.
>
> Thank you,
> Nikos
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:etmo6v$tsu$2@utils.eclipse.org...
>> Hi Nikos,
>>
>> There is a bug in uml2tools in how it displays these things ... the
>> diamond
>> is on the wrong side :) Please raise a bugzilla on them to get that
>> fixed.
>>
>> Regards,
>>
>> By the way, in general "Class" should also probably own the composed
>> property ( not the association ) as your serialized version shows.
>>
>> - James.
>>
>>

The TopCased UML editor (www.topcased.org) has the same behaviour as
uml2tools. I'm getting suspicious...

Aggregration=Composite is now on the src side, where src points to the
"owner" classifier in the association. In UML 1.4, this is similar:
association ends that point to the "owner" classifier are marked as
ak_composite. Poseidon for UML implemented it this way.

> The constraint in the spec is in section 7.3.43 : [2] A multiplicity on an
> aggregate end of a composite aggregation must not have an upper bound
> greater than 1. isComposite implies (upperBound()->isEmpty() or upperBound()
> <= 1)

Ah, natural language... I interpret:

aggregate end of a composite aggregation = src

The multiplicity of src is indeed 1, since there should only be one
owner for any object. So, src->isComposite() must be true.

It is feasible for the src classifier to own multiple instances of the
dst classifier. Hence, the multiplicity of dst may be greater than 1.
Given the constraint from the UML spec, dst->isComposite() must be false.

Looks like UML2 intended the same semantics for Property elements as UML
1.4 did for AssociationEnd elements. Can you verify this please? It
would mean that Nikos was right.

--
Regards,
Dennis
Re: UML2 Composite Association Bug? [message #604210 is a reply to message #472099] Mon, 02 April 2007 21:41 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Dennis,

.... let me try to convince you ... :)

Take just about any figure in the UML spec illustrating the UML metamodel.
For instance, from the 07-02-05 version take figure 12.22 for structured
nodes.
Notice the composition association between ConditionalNode and OutputPin.
ConditionalNode has a part called "result" of multiplicity [*]. "result"
is shown on the end that is opposite the diamond along with the [*]
multiplicity. Also, on the end with the diamond we have the multiplicity
[0..1]. The isComposite() of "result" would be true in that case and is
shown on the dst end.
If what you are implying is correct then I think that means that all the
diagrams in the spec are backwards.

I agree that the constraint from the spec that is quoted below does seem to
be worded imprecisely.

.... are you convinced ?.... :)

p.41 of the spec describes the notation.

Regards,

- James.


"Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
news:euq864$cue$1@build.eclipse.org...
> Nikos Giannopoulos schreef:
> > Thank you for your time James. Since the uml2tools contains bugs could
you
> > suggest a tool (freeware of course) in which you can graphically create
> > efficiently UML2 diagrams? I need to create UML2 diagrams and then
transform
> > them (the models) to ecore files and finally create EMF editors for
those.
> >
> > Thank you,
> > Nikos
> >
> > "James Bruck" <jbruck@ca.ibm.com> wrote in message
> > news:etmo6v$tsu$2@utils.eclipse.org...
> >> Hi Nikos,
> >>
> >> There is a bug in uml2tools in how it displays these things ... the
> >> diamond
> >> is on the wrong side :) Please raise a bugzilla on them to get that
> >> fixed.
> >>
> >> Regards,
> >>
> >> By the way, in general "Class" should also probably own the composed
> >> property ( not the association ) as your serialized version shows.
> >>
> >> - James.
> >>
> >>
>
> The TopCased UML editor (www.topcased.org) has the same behaviour as
> uml2tools. I'm getting suspicious...
>
> Aggregration=Composite is now on the src side, where src points to the
> "owner" classifier in the association. In UML 1.4, this is similar:
> association ends that point to the "owner" classifier are marked as
> ak_composite. Poseidon for UML implemented it this way.
>
> > The constraint in the spec is in section 7.3.43 : [2] A multiplicity on
an
> > aggregate end of a composite aggregation must not have an upper bound
> > greater than 1. isComposite implies (upperBound()->isEmpty() or
upperBound()
> > <= 1)
>
> Ah, natural language... I interpret:
>
> aggregate end of a composite aggregation = src
>
> The multiplicity of src is indeed 1, since there should only be one
> owner for any object. So, src->isComposite() must be true.
>
> It is feasible for the src classifier to own multiple instances of the
> dst classifier. Hence, the multiplicity of dst may be greater than 1.
> Given the constraint from the UML spec, dst->isComposite() must be false.
>
> Looks like UML2 intended the same semantics for Property elements as UML
> 1.4 did for AssociationEnd elements. Can you verify this please? It
> would mean that Nikos was right.
>
> --
> Regards,
> Dennis
Re: UML2 Composite Association Bug? [message #604215 is a reply to message #472103] Mon, 02 April 2007 22:05 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Dennis,,

After re-reading that constraint ... I can really understand the confusion
about this point. I just spoke to Bran Selic ( chair of OMG ) to clarify
that for me and there does seem to be an issue there that should be cleaned
up. He mentioned that there were long debates over this point but the way
the UML API implements this constraint is correct. Have a look at the
PropertyOperations.validateMultiplicityOfComposite() for the proper
implementation.

When I come across the RTF (defect number) for that issue I will post it
here.

.... so I still stick to the original response that I gave :)

I hope that helps.

Regards,

- James.




"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:eurtb8$vbj$2@build.eclipse.org...
> Hi Dennis,
>
> ... let me try to convince you ... :)
>
> Take just about any figure in the UML spec illustrating the UML metamodel.
> For instance, from the 07-02-05 version take figure 12.22 for structured
> nodes.
> Notice the composition association between ConditionalNode and OutputPin.
> ConditionalNode has a part called "result" of multiplicity [*].
"result"
> is shown on the end that is opposite the diamond along with the [*]
> multiplicity. Also, on the end with the diamond we have the multiplicity
> [0..1]. The isComposite() of "result" would be true in that case and is
> shown on the dst end.
> If what you are implying is correct then I think that means that all the
> diagrams in the spec are backwards.
>
> I agree that the constraint from the spec that is quoted below does seem
to
> be worded imprecisely.
>
> ... are you convinced ?.... :)
>
> p.41 of the spec describes the notation.
>
> Regards,
>
> - James.
>
>
> "Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
> news:euq864$cue$1@build.eclipse.org...
> > Nikos Giannopoulos schreef:
> > > Thank you for your time James. Since the uml2tools contains bugs could
> you
> > > suggest a tool (freeware of course) in which you can graphically
create
> > > efficiently UML2 diagrams? I need to create UML2 diagrams and then
> transform
> > > them (the models) to ecore files and finally create EMF editors for
> those.
> > >
> > > Thank you,
> > > Nikos
> > >
> > > "James Bruck" <jbruck@ca.ibm.com> wrote in message
> > > news:etmo6v$tsu$2@utils.eclipse.org...
> > >> Hi Nikos,
> > >>
> > >> There is a bug in uml2tools in how it displays these things ... the
> > >> diamond
> > >> is on the wrong side :) Please raise a bugzilla on them to get that
> > >> fixed.
> > >>
> > >> Regards,
> > >>
> > >> By the way, in general "Class" should also probably own the
composed
> > >> property ( not the association ) as your serialized version shows.
> > >>
> > >> - James.
> > >>
> > >>
> >
> > The TopCased UML editor (www.topcased.org) has the same behaviour as
> > uml2tools. I'm getting suspicious...
> >
> > Aggregration=Composite is now on the src side, where src points to the
> > "owner" classifier in the association. In UML 1.4, this is similar:
> > association ends that point to the "owner" classifier are marked as
> > ak_composite. Poseidon for UML implemented it this way.
> >
> > > The constraint in the spec is in section 7.3.43 : [2] A multiplicity
on
> an
> > > aggregate end of a composite aggregation must not have an upper bound
> > > greater than 1. isComposite implies (upperBound()->isEmpty() or
> upperBound()
> > > <= 1)
> >
> > Ah, natural language... I interpret:
> >
> > aggregate end of a composite aggregation = src
> >
> > The multiplicity of src is indeed 1, since there should only be one
> > owner for any object. So, src->isComposite() must be true.
> >
> > It is feasible for the src classifier to own multiple instances of the
> > dst classifier. Hence, the multiplicity of dst may be greater than 1.
> > Given the constraint from the UML spec, dst->isComposite() must be
false.
> >
> > Looks like UML2 intended the same semantics for Property elements as UML
> > 1.4 did for AssociationEnd elements. Can you verify this please? It
> > would mean that Nikos was right.
> >
> > --
> > Regards,
> > Dennis
>
>
Re: UML2 Composite Association Bug? [message #604239 is a reply to message #472104] Tue, 03 April 2007 12:32 Go to previous message
Dennis Wagelaar is currently offline Dennis WagelaarFriend
Messages: 147
Registered: July 2009
Senior Member
Hi James,

Thank you very much for the elaborate explanation :-). I really
appreciate you taking the time to dig into this issue. I've looked at
several things now:

UML 2.1.1 Superstructure:
- Notation specification on p.42
- Example composition association in Fig.12.22, p.308
- Abstract syntax/meta-model of Association in Fig.7.12, p.32
- Constraint [2] on p.124

The implementation of PropertyOperations.validateMultiplicityOfComposite():
http://dev.eclipse.org/viewcvs/indextools.cgi/org.eclipse.um l2/plugins/org.eclipse.uml2/src/org/eclipse/uml2/internal/op eration/PropertyOperations.java?revision=1.21&view=marku p

As far as I understand Constraint [2], the "aggregate end" of a
composite aggregation is the one that has limits on its upper bound.
That implies that the context of the accompanying OCL statement must be
the "aggregate end":

let property = "aggregate end" in
property.isComposite implies
(property.upperBound()->isEmpty() or property.upperBound() <= 1)

Now I look at the code of
PropertyOperations.validateMultiplicityOfComposite():

boolean result = true;

if (property.isComposite()) {
Property otherEnd = property.getOtherEnd();

if (null != otherEnd) {
int upperBound = otherEnd.upperBound();

if (MultiplicityElement.UNLIMITED_UPPER_BOUND == upperBound
|| 1 < upperBound) {

result = false;

if (null != diagnostics) {
diagnostics
.add(new BasicDiagnostic(
Diagnostic.WARNING,
UML2Validator.DIAGNOSTIC_SOURCE,
UML2Validator.PROPERTY__MULTIPLICITY_OF_COMPOSITE,
UML2Plugin.INSTANCE
.getString(
"_UI_Property_MultiplicityOfComposite_diagnostic",
//$NON-NLS-1$
getMessageSubstitutions(context,
property)), new Object[]{property,
new Integer(upperBound)}));
}
}
}
}

return result;

So, the code checks if "property.isComposite()" is true. It then goes on
to check the multiplicity of the *other* end, instead of the
multiplicity of "property". That is inconsistent with the OCL
specification of Constraint [2]. I will for now ignore the fact that
only binary associations have an "other end".

Since you said the code is correct, I'll assume that the OCL
specification is incorrect and has to be adapted to:

let property = "aggregate end" in
property.otherEnd.isComposite implies
(property.upperBound()->isEmpty() or property.upperBound() <= 1)

N.B. The "aggregate end" remains the end with limits on its upper bound.
The definition of "otherEnd" is according to the UML API code. Now I
look at the specification of the notation on p.42:

"An association with aggregationKind = shared differs in notation from
binary associations in adding a hollow diamond as a terminal adornment
at the aggregate end of the association line. The diamond shall be
noticeably smaller than the diamond notation for associations. An
association with aggregationKind = composite likewise has a diamond at
the aggregate end, but differs in having the diamond filled in."

The "adornment" is added at the "aggregate end". It follows that in
Fig.12.22, the composition association between ConditionalNode and
OutputPin has its aggregate end drawn at the top according to the spec.
The other end of the "aggregate end" ("result") should have isComposite
= true according to the *new* OCL statement, which is what you said earlier.

So, the real question here is whether:
(1) property = "aggregate end" iff property.isComposite (original OCL
statement), or
(2) property = "aggregate end" iff property.otherEnd.isComposite (new
OCL statement).

Note that in case (2), Constraint [2] is only defined if "otherEnd" is
defined. According to the code, "otherEnd" is defined only for binary
associations. There is no equivalent of "otherEnd" in the UML 2.1.1
Superstructure specification ("opposite" from Constraint [1] resembles
it, but is different).

Is case (2) really what you mean?

--
Regards,
Dennis

James Bruck schreef:
> Hi Dennis,,
>
> After re-reading that constraint ... I can really understand the confusion
> about this point. I just spoke to Bran Selic ( chair of OMG ) to clarify
> that for me and there does seem to be an issue there that should be cleaned
> up. He mentioned that there were long debates over this point but the way
> the UML API implements this constraint is correct. Have a look at the
> PropertyOperations.validateMultiplicityOfComposite() for the proper
> implementation.
>
> When I come across the RTF (defect number) for that issue I will post it
> here.
>
> ... so I still stick to the original response that I gave :)
>
> I hope that helps.
>
> Regards,
>
> - James.
>
>
>
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:eurtb8$vbj$2@build.eclipse.org...
>> Hi Dennis,
>>
>> ... let me try to convince you ... :)
>>
>> Take just about any figure in the UML spec illustrating the UML metamodel.
>> For instance, from the 07-02-05 version take figure 12.22 for structured
>> nodes.
>> Notice the composition association between ConditionalNode and OutputPin.
>> ConditionalNode has a part called "result" of multiplicity [*].
> "result"
>> is shown on the end that is opposite the diamond along with the [*]
>> multiplicity. Also, on the end with the diamond we have the multiplicity
>> [0..1]. The isComposite() of "result" would be true in that case and is
>> shown on the dst end.
>> If what you are implying is correct then I think that means that all the
>> diagrams in the spec are backwards.
>>
>> I agree that the constraint from the spec that is quoted below does seem
> to
>> be worded imprecisely.
>>
>> ... are you convinced ?.... :)
>>
>> p.41 of the spec describes the notation.
>>
>> Regards,
>>
>> - James.
>>
>>
>> "Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
>> news:euq864$cue$1@build.eclipse.org...
>>> Nikos Giannopoulos schreef:
>>>> Thank you for your time James. Since the uml2tools contains bugs could
>> you
>>>> suggest a tool (freeware of course) in which you can graphically
> create
>>>> efficiently UML2 diagrams? I need to create UML2 diagrams and then
>> transform
>>>> them (the models) to ecore files and finally create EMF editors for
>> those.
>>>> Thank you,
>>>> Nikos
>>>>
>>>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>>>> news:etmo6v$tsu$2@utils.eclipse.org...
>>>>> Hi Nikos,
>>>>>
>>>>> There is a bug in uml2tools in how it displays these things ... the
>>>>> diamond
>>>>> is on the wrong side :) Please raise a bugzilla on them to get that
>>>>> fixed.
>>>>>
>>>>> Regards,
>>>>>
>>>>> By the way, in general "Class" should also probably own the
> composed
>>>>> property ( not the association ) as your serialized version shows.
>>>>>
>>>>> - James.
>>>>>
>>>>>
>>> The TopCased UML editor (www.topcased.org) has the same behaviour as
>>> uml2tools. I'm getting suspicious...
>>>
>>> Aggregration=Composite is now on the src side, where src points to the
>>> "owner" classifier in the association. In UML 1.4, this is similar:
>>> association ends that point to the "owner" classifier are marked as
>>> ak_composite. Poseidon for UML implemented it this way.
>>>
>>>> The constraint in the spec is in section 7.3.43 : [2] A multiplicity
> on
>> an
>>>> aggregate end of a composite aggregation must not have an upper bound
>>>> greater than 1. isComposite implies (upperBound()->isEmpty() or
>> upperBound()
>>>> <= 1)
>>> Ah, natural language... I interpret:
>>>
>>> aggregate end of a composite aggregation = src
>>>
>>> The multiplicity of src is indeed 1, since there should only be one
>>> owner for any object. So, src->isComposite() must be true.
>>>
>>> It is feasible for the src classifier to own multiple instances of the
>>> dst classifier. Hence, the multiplicity of dst may be greater than 1.
>>> Given the constraint from the UML spec, dst->isComposite() must be
> false.
>>> Looks like UML2 intended the same semantics for Property elements as UML
>>> 1.4 did for AssociationEnd elements. Can you verify this please? It
>>> would mean that Nikos was right.
>>>
>>> --
>>> Regards,
>>> Dennis
>>
>
>
Re: UML2 Composite Association Bug? [message #605381 is a reply to message #472209] Tue, 03 April 2007 19:51 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Dennis,

The OCL expression for this constraint (among many, many others) in the
specification is incorrect, as you've discovered. I was sure that an issue
had been raised for this (we discovered the problem when we did the initial
UML2 implementation over four years ago), but I guess is hadn't. :(

I would contend that the "aggregate end" of an assocation is the one on
which the diamond (solid or hollow) adornment is displayed and that this
property is the opposite of the property whose aggregation is something
other than 'none'. Note that only binary associations can be aggregations,
as stated in section 7.3.3 of the specification.

Kenn

"Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
news:euthho$d7i$1@build.eclipse.org...
> Hi James,
>
> Thank you very much for the elaborate explanation :-). I really appreciate
> you taking the time to dig into this issue. I've looked at several things
> now:
>
> UML 2.1.1 Superstructure:
> - Notation specification on p.42
> - Example composition association in Fig.12.22, p.308
> - Abstract syntax/meta-model of Association in Fig.7.12, p.32
> - Constraint [2] on p.124
>
> The implementation of
> PropertyOperations.validateMultiplicityOfComposite():
> http://dev.eclipse.org/viewcvs/indextools.cgi/org.eclipse.um l2/plugins/org.eclipse.uml2/src/org/eclipse/uml2/internal/op eration/PropertyOperations.java?revision=1.21&view=marku p
>
> As far as I understand Constraint [2], the "aggregate end" of a composite
> aggregation is the one that has limits on its upper bound. That implies
> that the context of the accompanying OCL statement must be the "aggregate
> end":
>
> let property = "aggregate end" in
> property.isComposite implies
> (property.upperBound()->isEmpty() or property.upperBound() <= 1)
>
> Now I look at the code of
> PropertyOperations.validateMultiplicityOfComposite():
>
> boolean result = true;
>
> if (property.isComposite()) {
> Property otherEnd = property.getOtherEnd();
>
> if (null != otherEnd) {
> int upperBound = otherEnd.upperBound();
>
> if (MultiplicityElement.UNLIMITED_UPPER_BOUND == upperBound
> || 1 < upperBound) {
>
> result = false;
>
> if (null != diagnostics) {
> diagnostics
> .add(new BasicDiagnostic( Diagnostic.WARNING,
> UML2Validator.DIAGNOSTIC_SOURCE,
> UML2Validator.PROPERTY__MULTIPLICITY_OF_COMPOSITE,
> UML2Plugin.INSTANCE
> .getString(
> "_UI_Property_MultiplicityOfComposite_diagnostic",
> //$NON-NLS-1$
> getMessageSubstitutions(context,
> property)), new Object[]{property,
> new Integer(upperBound)}));
> }
> }
> }
> }
>
> return result;
>
> So, the code checks if "property.isComposite()" is true. It then goes on
> to check the multiplicity of the *other* end, instead of the multiplicity
> of "property". That is inconsistent with the OCL specification of
> Constraint [2]. I will for now ignore the fact that only binary
> associations have an "other end".
>
> Since you said the code is correct, I'll assume that the OCL specification
> is incorrect and has to be adapted to:
>
> let property = "aggregate end" in
> property.otherEnd.isComposite implies
> (property.upperBound()->isEmpty() or property.upperBound() <= 1)
>
> N.B. The "aggregate end" remains the end with limits on its upper bound.
> The definition of "otherEnd" is according to the UML API code. Now I look
> at the specification of the notation on p.42:
>
> "An association with aggregationKind = shared differs in notation from
> binary associations in adding a hollow diamond as a terminal adornment at
> the aggregate end of the association line. The diamond shall be noticeably
> smaller than the diamond notation for associations. An association with
> aggregationKind = composite likewise has a diamond at the aggregate end,
> but differs in having the diamond filled in."
>
> The "adornment" is added at the "aggregate end". It follows that in
> Fig.12.22, the composition association between ConditionalNode and
> OutputPin has its aggregate end drawn at the top according to the spec.
> The other end of the "aggregate end" ("result") should have isComposite =
> true according to the *new* OCL statement, which is what you said earlier.
>
> So, the real question here is whether:
> (1) property = "aggregate end" iff property.isComposite (original OCL
> statement), or
> (2) property = "aggregate end" iff property.otherEnd.isComposite (new OCL
> statement).
>
> Note that in case (2), Constraint [2] is only defined if "otherEnd" is
> defined. According to the code, "otherEnd" is defined only for binary
> associations. There is no equivalent of "otherEnd" in the UML 2.1.1
> Superstructure specification ("opposite" from Constraint [1] resembles it,
> but is different).
>
> Is case (2) really what you mean?
>
> --
> Regards,
> Dennis
>
> James Bruck schreef:
>> Hi Dennis,,
>>
>> After re-reading that constraint ... I can really understand the
>> confusion
>> about this point. I just spoke to Bran Selic ( chair of OMG ) to
>> clarify
>> that for me and there does seem to be an issue there that should be
>> cleaned
>> up. He mentioned that there were long debates over this point but the
>> way
>> the UML API implements this constraint is correct. Have a look at the
>> PropertyOperations.validateMultiplicityOfComposite() for the proper
>> implementation.
>>
>> When I come across the RTF (defect number) for that issue I will post it
>> here.
>>
>> ... so I still stick to the original response that I gave :)
>>
>> I hope that helps.
>>
>> Regards,
>>
>> - James.
>>
>>
>>
>>
>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>> news:eurtb8$vbj$2@build.eclipse.org...
>>> Hi Dennis,
>>>
>>> ... let me try to convince you ... :)
>>>
>>> Take just about any figure in the UML spec illustrating the UML
>>> metamodel.
>>> For instance, from the 07-02-05 version take figure 12.22 for structured
>>> nodes.
>>> Notice the composition association between ConditionalNode and
>>> OutputPin.
>>> ConditionalNode has a part called "result" of multiplicity [*].
>> "result"
>>> is shown on the end that is opposite the diamond along with the [*]
>>> multiplicity. Also, on the end with the diamond we have the
>>> multiplicity
>>> [0..1]. The isComposite() of "result" would be true in that case and
>>> is
>>> shown on the dst end.
>>> If what you are implying is correct then I think that means that all the
>>> diagrams in the spec are backwards.
>>>
>>> I agree that the constraint from the spec that is quoted below does seem
>> to
>>> be worded imprecisely.
>>>
>>> ... are you convinced ?.... :)
>>>
>>> p.41 of the spec describes the notation.
>>>
>>> Regards,
>>>
>>> - James.
>>>
>>>
>>> "Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
>>> news:euq864$cue$1@build.eclipse.org...
>>>> Nikos Giannopoulos schreef:
>>>>> Thank you for your time James. Since the uml2tools contains bugs could
>>> you
>>>>> suggest a tool (freeware of course) in which you can graphically
>> create
>>>>> efficiently UML2 diagrams? I need to create UML2 diagrams and then
>>> transform
>>>>> them (the models) to ecore files and finally create EMF editors for
>>> those.
>>>>> Thank you,
>>>>> Nikos
>>>>>
>>>>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>>>>> news:etmo6v$tsu$2@utils.eclipse.org...
>>>>>> Hi Nikos,
>>>>>>
>>>>>> There is a bug in uml2tools in how it displays these things ... the
>>>>>> diamond
>>>>>> is on the wrong side :) Please raise a bugzilla on them to get that
>>>>>> fixed.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> By the way, in general "Class" should also probably own the
>> composed
>>>>>> property ( not the association ) as your serialized version shows.
>>>>>>
>>>>>> - James.
>>>>>>
>>>>>>
>>>> The TopCased UML editor (www.topcased.org) has the same behaviour as
>>>> uml2tools. I'm getting suspicious...
>>>>
>>>> Aggregration=Composite is now on the src side, where src points to the
>>>> "owner" classifier in the association. In UML 1.4, this is similar:
>>>> association ends that point to the "owner" classifier are marked as
>>>> ak_composite. Poseidon for UML implemented it this way.
>>>>
>>>>> The constraint in the spec is in section 7.3.43 : [2] A multiplicity
>> on
>>> an
>>>>> aggregate end of a composite aggregation must not have an upper bound
>>>>> greater than 1. isComposite implies (upperBound()->isEmpty() or
>>> upperBound()
>>>>> <= 1)
>>>> Ah, natural language... I interpret:
>>>>
>>>> aggregate end of a composite aggregation = src
>>>>
>>>> The multiplicity of src is indeed 1, since there should only be one
>>>> owner for any object. So, src->isComposite() must be true.
>>>>
>>>> It is feasible for the src classifier to own multiple instances of the
>>>> dst classifier. Hence, the multiplicity of dst may be greater than 1.
>>>> Given the constraint from the UML spec, dst->isComposite() must be
>> false.
>>>> Looks like UML2 intended the same semantics for Property elements as
>>>> UML
>>>> 1.4 did for AssociationEnd elements. Can you verify this please? It
>>>> would mean that Nikos was right.
>>>>
>>>> --
>>>> Regards,
>>>> Dennis
>>>
>>
Re: UML2 Composite Association Bug? [message #605431 is a reply to message #472216] Thu, 05 April 2007 12:10 Go to previous message
Dennis Wagelaar is currently offline Dennis WagelaarFriend
Messages: 147
Registered: July 2009
Senior Member
Hi Kenn,

That clears up the situation, thanks! Is this issue currently on the
agenda for the UML specification?

Kind regards,
Dennis

Kenn Hussey schreef:
> Dennis,
>
> The OCL expression for this constraint (among many, many others) in the
> specification is incorrect, as you've discovered. I was sure that an issue
> had been raised for this (we discovered the problem when we did the initial
> UML2 implementation over four years ago), but I guess is hadn't. :(
>
> I would contend that the "aggregate end" of an assocation is the one on
> which the diamond (solid or hollow) adornment is displayed and that this
> property is the opposite of the property whose aggregation is something
> other than 'none'. Note that only binary associations can be aggregations,
> as stated in section 7.3.3 of the specification.
>
> Kenn
>
> "Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
> news:euthho$d7i$1@build.eclipse.org...
>> Hi James,
>>
>> Thank you very much for the elaborate explanation :-). I really appreciate
>> you taking the time to dig into this issue. I've looked at several things
>> now:
>>
>> UML 2.1.1 Superstructure:
>> - Notation specification on p.42
>> - Example composition association in Fig.12.22, p.308
>> - Abstract syntax/meta-model of Association in Fig.7.12, p.32
>> - Constraint [2] on p.124
>>
>> The implementation of
>> PropertyOperations.validateMultiplicityOfComposite():
>> http://dev.eclipse.org/viewcvs/indextools.cgi/org.eclipse.um l2/plugins/org.eclipse.uml2/src/org/eclipse/uml2/internal/op eration/PropertyOperations.java?revision=1.21&view=marku p
>>
>> As far as I understand Constraint [2], the "aggregate end" of a composite
>> aggregation is the one that has limits on its upper bound. That implies
>> that the context of the accompanying OCL statement must be the "aggregate
>> end":
>>
>> let property = "aggregate end" in
>> property.isComposite implies
>> (property.upperBound()->isEmpty() or property.upperBound() <= 1)
>>
>> Now I look at the code of
>> PropertyOperations.validateMultiplicityOfComposite():
>>
>> boolean result = true;
>>
>> if (property.isComposite()) {
>> Property otherEnd = property.getOtherEnd();
>>
>> if (null != otherEnd) {
>> int upperBound = otherEnd.upperBound();
>>
>> if (MultiplicityElement.UNLIMITED_UPPER_BOUND == upperBound
>> || 1 < upperBound) {
>>
>> result = false;
>>
>> if (null != diagnostics) {
>> diagnostics
>> .add(new BasicDiagnostic( Diagnostic.WARNING,
>> UML2Validator.DIAGNOSTIC_SOURCE,
>> UML2Validator.PROPERTY__MULTIPLICITY_OF_COMPOSITE,
>> UML2Plugin.INSTANCE
>> .getString(
>> "_UI_Property_MultiplicityOfComposite_diagnostic",
>> //$NON-NLS-1$
>> getMessageSubstitutions(context,
>> property)), new Object[]{property,
>> new Integer(upperBound)}));
>> }
>> }
>> }
>> }
>>
>> return result;
>>
>> So, the code checks if "property.isComposite()" is true. It then goes on
>> to check the multiplicity of the *other* end, instead of the multiplicity
>> of "property". That is inconsistent with the OCL specification of
>> Constraint [2]. I will for now ignore the fact that only binary
>> associations have an "other end".
>>
>> Since you said the code is correct, I'll assume that the OCL specification
>> is incorrect and has to be adapted to:
>>
>> let property = "aggregate end" in
>> property.otherEnd.isComposite implies
>> (property.upperBound()->isEmpty() or property.upperBound() <= 1)
>>
>> N.B. The "aggregate end" remains the end with limits on its upper bound.
>> The definition of "otherEnd" is according to the UML API code. Now I look
>> at the specification of the notation on p.42:
>>
>> "An association with aggregationKind = shared differs in notation from
>> binary associations in adding a hollow diamond as a terminal adornment at
>> the aggregate end of the association line. The diamond shall be noticeably
>> smaller than the diamond notation for associations. An association with
>> aggregationKind = composite likewise has a diamond at the aggregate end,
>> but differs in having the diamond filled in."
>>
>> The "adornment" is added at the "aggregate end". It follows that in
>> Fig.12.22, the composition association between ConditionalNode and
>> OutputPin has its aggregate end drawn at the top according to the spec.
>> The other end of the "aggregate end" ("result") should have isComposite =
>> true according to the *new* OCL statement, which is what you said earlier.
>>
>> So, the real question here is whether:
>> (1) property = "aggregate end" iff property.isComposite (original OCL
>> statement), or
>> (2) property = "aggregate end" iff property.otherEnd.isComposite (new OCL
>> statement).
>>
>> Note that in case (2), Constraint [2] is only defined if "otherEnd" is
>> defined. According to the code, "otherEnd" is defined only for binary
>> associations. There is no equivalent of "otherEnd" in the UML 2.1.1
>> Superstructure specification ("opposite" from Constraint [1] resembles it,
>> but is different).
>>
>> Is case (2) really what you mean?
>>
>> --
>> Regards,
>> Dennis
>>
>> James Bruck schreef:
>>> Hi Dennis,,
>>>
>>> After re-reading that constraint ... I can really understand the
>>> confusion
>>> about this point. I just spoke to Bran Selic ( chair of OMG ) to
>>> clarify
>>> that for me and there does seem to be an issue there that should be
>>> cleaned
>>> up. He mentioned that there were long debates over this point but the
>>> way
>>> the UML API implements this constraint is correct. Have a look at the
>>> PropertyOperations.validateMultiplicityOfComposite() for the proper
>>> implementation.
>>>
>>> When I come across the RTF (defect number) for that issue I will post it
>>> here.
>>>
>>> ... so I still stick to the original response that I gave :)
>>>
>>> I hope that helps.
>>>
>>> Regards,
>>>
>>> - James.
>>>
>>>
>>>
>>>
>>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>>> news:eurtb8$vbj$2@build.eclipse.org...
>>>> Hi Dennis,
>>>>
>>>> ... let me try to convince you ... :)
>>>>
>>>> Take just about any figure in the UML spec illustrating the UML
>>>> metamodel.
>>>> For instance, from the 07-02-05 version take figure 12.22 for structured
>>>> nodes.
>>>> Notice the composition association between ConditionalNode and
>>>> OutputPin.
>>>> ConditionalNode has a part called "result" of multiplicity [*].
>>> "result"
>>>> is shown on the end that is opposite the diamond along with the [*]
>>>> multiplicity. Also, on the end with the diamond we have the
>>>> multiplicity
>>>> [0..1]. The isComposite() of "result" would be true in that case and
>>>> is
>>>> shown on the dst end.
>>>> If what you are implying is correct then I think that means that all the
>>>> diagrams in the spec are backwards.
>>>>
>>>> I agree that the constraint from the spec that is quoted below does seem
>>> to
>>>> be worded imprecisely.
>>>>
>>>> ... are you convinced ?.... :)
>>>>
>>>> p.41 of the spec describes the notation.
>>>>
>>>> Regards,
>>>>
>>>> - James.
>>>>
>>>>
>>>> "Dennis Wagelaar" <dennis.wagelaar@vub.ac.be> wrote in message
>>>> news:euq864$cue$1@build.eclipse.org...
>>>>> Nikos Giannopoulos schreef:
>>>>>> Thank you for your time James. Since the uml2tools contains bugs could
>>>> you
>>>>>> suggest a tool (freeware of course) in which you can graphically
>>> create
>>>>>> efficiently UML2 diagrams? I need to create UML2 diagrams and then
>>>> transform
>>>>>> them (the models) to ecore files and finally create EMF editors for
>>>> those.
>>>>>> Thank you,
>>>>>> Nikos
>>>>>>
>>>>>> "James Bruck" <jbruck@ca.ibm.com> wrote in message
>>>>>> news:etmo6v$tsu$2@utils.eclipse.org...
>>>>>>> Hi Nikos,
>>>>>>>
>>>>>>> There is a bug in uml2tools in how it displays these things ... the
>>>>>>> diamond
>>>>>>> is on the wrong side :) Please raise a bugzilla on them to get that
>>>>>>> fixed.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> By the way, in general "Class" should also probably own the
>>> composed
>>>>>>> property ( not the association ) as your serialized version shows.
>>>>>>>
>>>>>>> - James.
>>>>>>>
>>>>>>>
>>>>> The TopCased UML editor (www.topcased.org) has the same behaviour as
>>>>> uml2tools. I'm getting suspicious...
>>>>>
>>>>> Aggregration=Composite is now on the src side, where src points to the
>>>>> "owner" classifier in the association. In UML 1.4, this is similar:
>>>>> association ends that point to the "owner" classifier are marked as
>>>>> ak_composite. Poseidon for UML implemented it this way.
>>>>>
>>>>>> The constraint in the spec is in section 7.3.43 : [2] A multiplicity
>>> on
>>>> an
>>>>>> aggregate end of a composite aggregation must not have an upper bound
>>>>>> greater than 1. isComposite implies (upperBound()->isEmpty() or
>>>> upperBound()
>>>>>> <= 1)
>>>>> Ah, natural language... I interpret:
>>>>>
>>>>> aggregate end of a composite aggregation = src
>>>>>
>>>>> The multiplicity of src is indeed 1, since there should only be one
>>>>> owner for any object. So, src->isComposite() must be true.
>>>>>
>>>>> It is feasible for the src classifier to own multiple instances of the
>>>>> dst classifier. Hence, the multiplicity of dst may be greater than 1.
>>>>> Given the constraint from the UML spec, dst->isComposite() must be
>>> false.
>>>>> Looks like UML2 intended the same semantics for Property elements as
>>>>> UML
>>>>> 1.4 did for AssociationEnd elements. Can you verify this please? It
>>>>> would mean that Nikos was right.
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Dennis
>
Previous Topic:Applying stereotype on Class
Next Topic:Add an association into a package
Goto Forum:
  


Current Time: Thu Mar 28 11:29:01 GMT 2024

Powered by FUDForum. Page generated in 0.07488 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top