I have a class which has static methods.
Those static methods containes instances of some other classes
its actually holding that instance.
I had shown those classes as in composition to the class.
Is it wrong or how to show the method variables of
static methods in the class diagram?.
I am using Enterprise Archtiect.

Please advise,
Thanks in advance
Saurav

If you have a class A which has method hello(Obj a, Obj b)which has instance of some other class, it is example of aggregation.It is whole part relationship where part can exist without whole.
If you have instantiated Obj a and Obj b inside your class A, then it would be example of composition.
Coming back to your question, its not wrong to display the method variable in class diagram.
On second thoughts , why Obj a and Obj b would be class member variable? If this class has all static methods, then you should avoid this.

Saurav, are you talking about local variables here? Those are typically not shown using associations. A uses-relationship might be appropriate, if it is important to show.

 

Originally posted by Vinay Singh:
If you have instantiated Obj a and Obj b inside your class A, then it would be example of composition.

Not necessarily. See http://faq.javaranch.com/view?AssociationVsAggregationVsComposition

thanks Ifja and Vinay for the reply.
I decided to not to show the method variables
or the local variables in the Class diagram.

Cheers,
Saurav

 

Originally posted by Ilja Preuss:


Not necessarily. See http://faq.javaranch.com/view?AssociationVsAggregationVsComposition

Ija
I had gone through this link earlier and my clarity is based on the example in one of the posts.

Aggregation

// WebServer is composed of a HttpListener and a RequestProcessor
public class WebServer {
private HttpListener listener;
private RequestProcessor processor;
public WebServer(HttpListener listener, RequestProcessor processor) {
this.listener = listener;
this.processor = processor;
}
}

Composition:
code:


// WebServer is an aggregate of HttpListener and RequestProcessor
// and controls their lifecycle
public class WebServer {
private HttpListener listener;
private RequestProcessor processor;
public WebServer() {
this.listener = new HttpListener(80);
this.processor = new RequestProcessor("/www/root");
}
}

which looks very logical to me.
Here in composition, whole has responsibility of preventing gargbage collection of part.

Else apart from definitions, how would you depict difference between the two in terms of code examples ?

There are still some circumstances where I would classify your first example as a composition, especially as it could simply be composed through dependency injection. (Whoever gave the WebServer instance the listener and processor forgets about them and after that point only the WebServer instance knows about them. The WebServer instance may still assume responsibility for management of the listener and processor during their existence even if the WebServer instance didn't construct them).

Originally posted by Vinay Singh:
Here in composition, whole has responsibility of preventing garbage collection of part.

ANY reference will prevent GC, even one from an aggregate. If you would have said:
"In a composition GC eligibility of the whole usually implies GC eligibility of its parts" (apart from any undesirable external references to the parts) - then I could see where you are going.

Composition is usually used to communicate some sort of boundary, like whole-part ownership (parts belong to exactly one composite), or containment around a cluster of objects - the association between the objects in such a cluster is perceived to be stronger than a "regular" association. Within an aggregate the associations are perceived to be "weaker" than in composition but still stronger than "regular" associations (I personally don't find �aggregates� to be all that useful in UML).

Simply stick to associations unless you need to express such a boundary around or a "stronger bond" between the objects of a cluster.

 

Originally posted by Peer Reynders:
There are still some circumstances where I would classify your first example as a composition, especially as it could simply be composed through dependency injection. (Whoever gave the WebServer instance the listener and processor forgets about them and after that point only the WebServer instance knows about them. The WebServer instance may still assume responsibility for management of the listener and processor during their existence even if the WebServer instance didn't construct them).

Very well put.

ANY reference will prevent GC, even one from an aggregate.

That's true. The difference between aggregation and composition is whether it is merely a side effect, or one of the main responsibilities of the parent object.

Admittedly, this differentiation is seldom useful in practice. In Java - and other languages with a garbage collector - composition really isn't a very important concept, as far as I can tell.