[Uml-devel] Re: class UMLAssociation

[Oliver Kellogg]

Andy,

Thanks for your reply.

Please make sure to use the patch that I posted today to
the uml-devel list, and discard the "sneak preview" patch.

You make some valid points on the associations.
For now, I have made them such that they are only
added at one side - at the A role for generalizations,
at the B role for aggregations and compositions.
BTW, the new class currently only supports those three
association types. This is because my effort has been
driven by what is currently used in the code generators.

This is only the first step.
Now that we have the class UMLAssociation we can start
reasoning on what it should really look like.

Oliver

Andrew Sutton wrote:
> On Tuesday 31 December 2002 5:42 pm, Oliver Kellogg wrote:
> > Here is the first sneak preview.
> >
> > There is still one bug which I've not hunted down yet -
> > an association is added to *both* participtaing concepts
> > where it should only be added at the role-B concept.
> >
> > If you have any hints as to this bug, I'd be grateful.
> > (For the moment I suspect some kind of memory management
> > problem in my added/changed code.)
> >
> > Happy 2003 (whoa, gettin' darn close now :)
>
> i don't think that's a bug. the uml standards seem to indicate that an 
> association is simultaneously a feature of both classifiers (classes). a 
> program should be able to navigate from one end to the next regardless. 
> there's a navigability attribute on each association end that would be used 
> (per se) during code generation to determine if the association shows up as a 
> member of a class or not.
>
> consider the DOM specifications, for example. a DOMElement contains an
>  ordered 
> list of child elements. each DOMElement also has a reference to the parent 
> element. this can be described in a single association between the elements - 
> actually, this is a little bit off, but its still a good example.
>
> role A
> -------
> aggregationKind = aggregate
> visibilityKind = public
> name = "childNodes"
>
> role B
> ------
> aggregationKind = none
> visibilityKind = public
> name = "parent"
>
> i haven't tested it, but i don't think this is a bug within your patch.
>
> andy