[Uml-devel] UML question
Andrew Sutton
asutton at cs.kent.edu
Tue May 27 08:12:04 UTC 2003
On Sunday 25 May 2003 10:06 pm, P. Fleury wrote:
> Hi Anthony,
>
> I also think that an aggregation give an information about the relations
> of the life-time of the related objects. Hence the filled and unfilled
> diamonds in some relations (aggregation is filled). The 1..* relation
> does not indicate any life-time issue, and my understanding of UML is
> that you can use it for things which can be dynamically associated. This
> also matches your car+wheel+people example.
we're getting closer :)
> >What I mean is, there is a definate distinction between relationships and
> >aggregations. Relationships have straight lines and aggregations are the
> > same but with diamonds on the end. So given that, what's the difference
> > between a 1 to many relationship and a 1 to many aggregation. I think the
> > answer is that a class exists in it's own right when a 1 to many
> > relationship is used, but when an aggregation is used, it means the class
> > is _comprised_ of that aggregate too.
> >
> >I think, a car would have a 1...* aggregation of wheels, but not a 1...*
> >aggregation of persons.
first, the "relationship" you're talking about is an "association". an
association has different forms of aggregation: none, shared, and composite.
each defines different lifecycle semantics for related or associated objects.
an association with no diamond means that there is non-aggregate association.
one object uses 1..* of another object, but is neither responsible for
creating or deleting them.
an association with a hollow diamond is shared aggregration. in otherwords,
something else is the actual owner, but this uses them too. i'm not sure that
this is really so different than non-aggregate associations.
the filled in diamond represents a composite aggregation. that's strong
ownership. any composites are created when the owning class is created and
destroyed when the owning class is destroyed.
at least that's how i think it works...
andy
More information about the umbrello-devel
mailing list