[Uml-devel] What the hell are uni-associations?

[Andrew Sutton]

On Thursday 05 February 2004 10:28 am, Brian Thomas wrote:
> 	Hi Andrew,
> 
> 	Ok, this explaination is helpfull, and fits with what I already 'know'
> 	about the associations. It would appear to me then that we dont
> 	want to have a separate association called "uni". But a clarification:
> 	(or two :) when you mean that this type of association
> 
> 		"can be set and unset to point to different objects"
> 
> 	you are meaning objects of the same class no? Thats no different
> 	from an aggregation, as I understand it. If it isnt, can you explain how
> 	the pointer types differ? In an aggregation, perhaps, I cannot
> dereference
 one class from another, but if one object on one end of the
> association 'dies' the other continues to live, and can be re-associated
> with other classes. Is that the difference?

i think so... i'm kinda beat this morning and haven't had my coffee quota :) 
what follows is my interpretation of how this stuff probably works... it 
might help with semantics of lifecycle and other code generation stuff 
regarding associations.

just remember, all associations can be represented by a single line. the 
diamonds and arrows are notational devices used to convey the values of 
certain attributes. for example, the empty diamond denotes "aggregation" or 
"shared" references. The closed diamond represents "composition" or a whole/
part type thingy. No diamond probably means none. the diamonds don't actually 
have any meaning in terms of multiplicity. some people think that the 
diamonds mean contains 1..*, but it just means that it's a reference to 
another object.

as for lifecycle... here's my translation on the standards.

none:  this is your basic pointer. we don't care if it lives or dies, just 
that it can be set and unset.

aggregate: the end (the one with the open diamond and named at the opposite 
end of the line) is a shared reference. the other end can be contained in 
other aggregations. the other end must have a "none" aggregation value... in 
other words, you can't have two classes that aggregate each other.

composition: the end (also the one with the closed diamond) is strongly owned 
by the class that it starts at (the class attached to the diamond). it can't 
be in any other compositions, but it can be in aggregations. the other end 
must be none - you can't have two objects strongly owning eachother.


> 	Are all aggregations/compositions by default bidirectional then? I 
> 	had always assumed that the "arrow" was optional.

associations have three distinct parts: the association object itself and two 
association ends. the association end defines a feature "isNavigable". this 
is probably set to true by default. so yes... associations are by default 
bidrectional. the arrow is an alternative notation when you want to 
explicitly denote navagability.

just keep in mind that if an end is not navigable, then the class "pointing in 
that direction" won't have a pointer. for example:

A->B

is an association from A to B where A->B is navigable and B->A is not. code 
could be generated as such:

struct A { B *b; };
struct B {};

or something like that.

hope that helps

andy