composition issue
Hi guys i have a class diagram for a lottery Application.
I have the following classes
ball
ball container
simulator
board
draw
machine
I have a relationship between ball and ball container, in this relationship i have the dark diamond next to the ball container. So does that mean if i deleted an object of ball container that i would lose the ball ?
and i have a relationship between ball container and simulator. Here i have dark diamond by the simulator. so does this mean if i deleted the simulator the ball container would be deleted to ?
please advise
if u think there is a better way please say.
thanks
[690 byte] By [
immy12a] at [2007-9-28 19:16:59]
1) relationship between ball and ball container 2) relationship between ball container and simulator.Can you tell what 'relationship'? Is it a hierarchy or attribute ?
The filled diamond does strictly mean that the member objects are controlled completely by their aggregates, therefore the lifetime of the components will be the lifetime of the aggregate. Also the components would exist only in that aggregation. So in your case if you destroyed the ball you would destroy the container, and a ball must be in a ball container. Maybe for the application you're developing the empty diamond will be more desired (i.e. you can imagine a ball container existing without a ball) - simple aggregation?
i suppose its safer to go with aggregation rather then composition, **** it just when i thought i had identified a clear cut case for composition..thanks guys
Aggregation by value is composition where as Aggregation by reference is aggregation.
For composition you would use a solid diamond and for aggregation you would use a simple diamond.
e.g The relationship between CAR and wheel is aggregation sincethey have different lifespans so it would be denoted by a hollow diamond and the code would be something like
public class CAR
{
...
protected Wheel myWheel;
...
}
while the relationship of BodyFrame and CAR would be composition denoted by a solid diamond.
e.g
public class CAR
{
...
public class BodyFrame
{
...
public int weight;
public String color;
...
}
}
> while the relationship of BodyFrame and CAR would be
> composition denoted by a solid diamond.
>
> e.g
> > public class CAR
> {
> ...
>public class BodyFrame
>{
>...
>public int weight;
>public String color;
>...
>
>
>}
> }
>
It's deadly wrong! Provided code snippet says that the BodyFrame class is defined in scope of CAR class. It doesn't imply any relationship between instances of that classes. To implement strong aggregation you need something like this:
class Car
{
private BodyFrame frame;
public Car(/* ... */)
{
frame = new BodyFrame(/* ... */);
}
public BodyFrame getBodyFrame()
{
return frame;
}
// ...
}
> > while the relationship of BodyFrame and CAR would
> be
> > composition denoted by a solid diamond.
> >
> > e.g
> > > > public class CAR
> > {
> > ...
> >public class BodyFrame
> >{
> >...
> >public int weight;
> >public String color;
> >...
> >
> >
> >}
> > }
> >
>
> It's deadly wrong! Provided code snippet says that the
> BodyFrame class is defined in scope of CAR
> class. It doesn't imply any relationship between
> instances of that classes. To implement strong
> aggregation you need something like this:
> > class Car
> {
>private BodyFrame frame;
>
>public Car(/* ... */)
>{
>frame = new BodyFrame(/* ... */);
>}
>
>public BodyFrame getBodyFrame()
>{
>return frame;
>}
>
>// ...
> }
>
You haven't understood the question in discussion over here. Even in your answer you mentioned that the example you are stating is an aggregation case. But to remind you BodyFrame and the car don't have an aggregation relationship. Its composition since they have the same lifespan and therefore the same scope. Denoted by a solid diamond and not a hollow one. You need to revise your comcepts on composition and aggregation
nome02,
> You haven't understood the question in discussion over
> here.
I believe he has.
> Even in your answer you mentioned that the
> example you are stating is an aggregation case.
strong aggregation = composition. the overloading of terms is, in itself, confusing.
> But
> to remind you BodyFrame and the car don't have an
> aggregation relationship. Its composition since they
> have the same lifespan and therefore the same scope.
The relationship between scope and lifespan is at best obscure and at worst confusing since there are infinitely simpler examples. Someone may rightly understand by your example that to have a composite relationship, you require the part to be a nested class of the composite, which is not the case.
I do not see a main() method. Therefore, you cannot infer the relative lifespans of instances of the classes in your first example. Expanding your example into an executable _program_ would provide us with something concrete on which to reason.
> Denoted by a solid diamond and not a hollow
> one. You need to revise your comcepts on composition
> and aggregation
Hmmm, I prefer the omg definition, as stated in the UML specifications. I don't think talking about 'reference' verses 'value' helps. It is easier to explain it in terms of coincident lifetimes. Where is the 'value' relationship in your second answer? I can see that an instance of BodyFrame would have an immediately enclosing instance, but I cannot see your 'value' concept...
regards
http://www.bde.es/doctrab/docs/dt0108e.pdf
is a good site to explain the aggregation in detail.
> nome02,
>
> > You haven't understood the question in discussion
> over
> > here.
>
> I believe he has.
>
> > Even in your answer you mentioned that the
> > example you are stating is an aggregation case.
>
> strong aggregation = composition. the overloading of
> terms is, in itself, confusing.
>
> > But
> > to remind you BodyFrame and the car don't have an
> > aggregation relationship. Its composition since
> they
> > have the same lifespan and therefore the same
> scope.
>
> The relationship between scope and lifespan is at best
> obscure and at worst confusing since there are
> infinitely simpler examples. Someone may rightly
> understand by your example that to have a composite
> relationship, you require the part to be a nested
> class of the composite, which is not the case.
>
> I do not see a main() method. Therefore, you cannot
> infer the relative lifespans of instances of the
> classes in your first example. Expanding your example
> into an executable _program_ would provide us with
> something concrete on which to reason.
>
> > Denoted by a solid diamond and not a hollow
> > one. You need to revise your comcepts on
> composition
> > and aggregation
>
> Hmmm, I prefer the omg definition, as stated in the
> UML specifications. I don't think talking about
> 'reference' verses 'value' helps. It is easier to
> explain it in terms of coincident lifetimes. Where is
> the 'value' relationship in your second answer? I can
> see that an instance of BodyFrame would have an
> immediately enclosing instance, but I cannot see your
> 'value' concept...
>
> regards
> http://www.bde.es/doctrab/docs/dt0108e.pdf> > is a good site to explain the aggregation in detail.> > ;) just kidding. Was just thinking if somebody gets the point. lol
> http://www.bde.es/doctrab/docs/dt0108e.pdf> > is a good site to explain the aggregation in detail.It does not mention java, software engineering or uml. I am confused. please explain its relevance. thanks in advance.
> > http://www.bde.es/doctrab/docs/dt0108e.pdf
> >
> > is a good site to explain the aggregation in
> detail.
>
> It does not mention java, software engineering or uml.
> I am confused. please explain its relevance. thanks in
> advance.
was just thinking how many ppl actually goto a website if specified. So at least you did.
jokes aside, I would still be interested in hearing your reply to my comments.
> jokes aside, I would still be interested in hearing
> your reply to my comments.
I appreciate that. However if you look at my mails above I have gave the descriptio of aggregation and composition to the best of my knowledge.
A good website to explain the difference is (Seriously)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dniuml/html/aggregations.asp
Another good explanation of the fact was given at the following site
What is the difference between composition and aggregation?
Location: http://www.jguru.com/faq/view.jsp?EID=51520
Created: May 18, 2000 Modified: 2000-05-18 18:18:30.382
Author: John Moore (http://www.jguru.com/guru/viewbio.jsp?EID=13)
Both aggregation and composition are special kinds of associations. Aggregation is used to represent ownership or a whole/part relationship, and composition is used to represent an even stronger form of ownership. With composition, we get coincident lifetime of part with the whole. The composite object has sole responsibility for the disposition of its parts in terms of creation and destruction. In implementation terms, the composite is responsible for memory allocation and deallocation
Moreover, the multiplicity of the aggregate end may not exceed one; i.e., it is unshared. An object may be part of only one composite at a time. If the composite is destroyed, it must either destroy all its parts or else give responsibility for them to some other object. A composite object can be designed with the knowledge that no other object will destroy its parts.
Composition can be used to model by-value aggregation, which is semantically equivalent to an attribute. In fact, composition was originally called aggregation-by-value in an earlier UML draft, with 齨ormal?aggregation being thought of as aggregation-by-reference. The definitions have changed slightly, but the general ideas still apply. The distinction between aggregation and composition is more of a design concept and is not usually relevant during analysis.
Finally, a word of warning on terminology. While UML uses the terms association, aggregation, and composition with specific meanings, some object-oriented authors use one or more of these terms with slightly different interpretations. For example, it is fairly common to see all three UML relationships grouped under a single term, say composition, and then to discuss object-oriented relationships as being either inheritance (generalization) or composition.
In another website
http://www.ee.unb.ca/thesis98/ee4000u/chapter1.html
it says
"Another type of association between classes is an aggregation or "whole/part" relationship. This relationship indicates that one class contains another. This is shown by putting a diamond at the container end of the association. Aggregation can be by value or by reference. If it is by reference, the classes being contained may be shared with other containers. The parts may not be shared if they are aggregated by value. Aggregation by reference uses a white diamond while aggregation by value uses a black diamond."
Keeping all this stuff in mind I would rather stick to my original example and explanation for that makes sense to me.
In C++ to differentiate the two in code would be quite simple as in ine (aggregatio by reference) you would use pointers while the other (composition or aggregation by value) you would use values rather than pojnters.
In java however all the transfers take place as references so its hard to differentiate the two so I wouls again insist of making composite the inner class of composing one. Thats the only way of passing by value I guess, if somebody could explain howelse could he pass an object from one class to another without using references I would welcome the opinion and that would definitely be a learning experience for me as well.
> nome02,
>
> > You haven't understood the question in discussion
> over
> > here.
>
> I believe he has.
>
> > Even in your answer you mentioned that the
> > example you are stating is an aggregation case.
>
> strong aggregation = composition. the overloading of
> terms is, in itself, confusing.
>
> > But
> > to remind you BodyFrame and the car don't have an
> > aggregation relationship. Its composition since
> they
Composition is also known as aggregation by value while aggregation is aggregation by reference u could refer to booch.
> > have the same lifespan and therefore the same
> scope.
>
> The relationship between scope and lifespan is at best
> obscure and at worst confusing since there are
> infinitely simpler examples. Someone may rightly
> understand by your example that to have a composite
> relationship, you require the part to be a nested
> class of the composite, which is not the case.
>
> I do not see a main() method. Therefore, you cannot
> infer the relative lifespans of instances of the
> classes in your first example. Expanding your example
> into an executable _program_ would provide us with
> something concrete on which to reason.
>
> > Denoted by a solid diamond and not a hollow
> > one. You need to revise your comcepts on
> composition
> > and aggregation
>
> Hmmm, I prefer the omg definition, as stated in the
> UML specifications. I don't think talking about
> 'reference' verses 'value' helps. It is easier to
> explain it in terms of coincident lifetimes. Where is
> the 'value' relationship in your second answer? I can
> see that an instance of BodyFrame would have an
> immediately enclosing instance, but I cannot see your
> 'value' concept...
>
> regards
Another interesting thing I just noted. If you use rational rose to generate code, It does the following
Aggregation
aggregation relationship between A and B
public class A
{
public A()
{
B b = new B();
}
}
However for
Composition (Aggregation by value)
It would be
public class A
{
public A()
{
...
}
B b = new B();
}
interesting.
> I appreciate that. However if you look at my mails
> above I have gave the descriptio of aggregation and
> composition to the best of my knowledge.
Yes I appreciate that too.
> Keeping all this stuff in mind I would rather stick to
> my original example and explanation for that makes
> sense to me.
>
> In C++ to differentiate the two in code would be quite
> simple as in ine (aggregatio by reference) you would
> use pointers while the other (composition or
> aggregation by value) you would use values rather than
> pojnters.
>
> In java however all the transfers take place as
> references so its hard to differentiate the two so I
> wouls again insist of making composite the inner class
> of composing one. Thats the only way of passing by
> value I guess, if somebody could explain howelse could
> he pass an object from one class to another without
> using references I would welcome the opinion and that
> would definitely be a learning experience for me as
> well.
I had never heard of the aggregation by reference or value. I won't forget them in a hurry!
Your last paragraph does worry me because the focus is on trying to explain aggregation and composition in terms that are not readily compatible with Java. I agree with the detail that all transfers take place as references etc. but it does not refer to coincident lifetimes, therefore it would confuse me.
You are obviously free to use whatever terms you want! We can agree to disagree politely on that.
and thanks for the references.
> Another interesting thing I just noted. If you use
> rational rose to generate code, It does the following
>
This is interesting! (i'm not being sarcastic)
> Aggregation
> aggregation relationship between A and B
> > public class A
> {
>public A()
>{
>B b = new B();
>}
> }
>
As far as I understand associations:
- local variables in source code do not map to associations in UML (and vice versa). Because once the method ends, the local variable goes out of scope and is lost.
so, I can't understand what Rose is doing.
>
>
> However for
> Composition (Aggregation by value)
>
> It would be
>
> > public class A
> {
>public A()
>{
>...
>}
>
>B b = new B();
> }
>
>
> interesting.
Ok, but the implication here is that any default visibility instance variable represents a part of a composite, which seems to be a little bit too general. The same code would be generated by a plain uni-directional association...
It would be acceptable if Rose gave the uml designer some guidance. For example that a program that uses class A must ensure that b's lifetime starts after and ends before A's. And that the object that b references is only referenced once, by b. The second constraint could be enforced by Rose's code generator by making b private and by stating that an accessor/get method should not be implemented.
