This week's book giveaway is in the Cloud/Virtualization forum.
We're giving away four copies of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds and have James Denton on-line!
See this thread for details.
Win a copy of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds this week in the Cloud/Virtualization forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

'uses' in class diagram  RSS feed

 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I have Class A which perform a service on Class B, but uses Class C to actually perform the service, how is it shown in a class diagram?

A (uses) B

or

A (uses) C and C(uses) B ?

For eg. EstateAgent evaluates Houses. So, a House object would be passed to the evaluate() method of EstateAgent. Now, if the EstateAgent uses a Evaluator class to do the actual evaluation, and passes the House to the doEvaluate() method of Evaluator, what is the relation here?

EstateAgent (uses)House
or
EstateAgent (uses)Evaluator and Evaluator (uses) House?

hope I have explained it clearly enough..

parag
 
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Parag,

looks like an example of the strategy pattern. Let different Evaluation classes inherit from an abstract EvaluationStrategy class and let them implement different evaluation algorithms. The relationship to the Evaluator is specified as being a composition by GOF.

Replace Evaluation with Pricing and you've got something fancy for your assignment

HTH,
Harbo
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by H. Hafer:
Parag,

looks like an example of the strategy pattern. Let different Evaluation classes inherit from an abstract EvaluationStrategy class and let them implement different evaluation algorithms. The relationship to the Evaluator is specified as being a composition by GOF.

Replace Evaluation with Pricing and you've got something fancy for your assignment

HTH,
Harbo



Harbo,
I didnt want to mention Pricing in my example,so I found another example to ask the same thing


Evaluator is specified as being a composition by GOF



Evaluator is composition with what? I didnt understand that line. And it also didnt answer my 'uses' question


Parag
 
H. Hafer
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Parag Doshi:
Evaluator is composition with what? I didnt understand that line. And it also didnt answer my 'uses' question



yupp, piece missing. Next try:
The EstateAgent is composed of (usually only one) object of subclasses of the abstract Pri^H^H^HEvaluator class (uh, how to integrate a little picture?)

The relationship between EstateAgent and a concrete Evaluation algorithm therefore is defined by the composition to its superclass. Since you ask to show that in a class diagram, there's nothing more to show.

HTH,
Harbo
 
Ranch Hand
Posts: 215
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do as shown in GOF pattern diagrams. Just association and inheritance.
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by H. Hafer:


yupp, piece missing. Next try:
The EstateAgent is composed of (usually only one) object of subclasses of the abstract Pri^H^H^HEvaluator class (uh, how to integrate a little picture?)

The relationship between EstateAgent and a concrete Evaluation algorithm therefore is defined by the composition to its superclass. Since you ask to show that in a class diagram, there's nothing more to show.

HTH,
Harbo



Let me explain a little further and see how this all fits in. The EstateAgent is a stateless session bean, so the question of it holding a reference to the Evaluation implementation seems a little off. The way I vision it is that the EstateAgent would ask a Evaluationfactory to give a concrete Evaluation object which would do the work for him. From the way I understand it, the evaluation object would be "used" in the SLSB's method as a local variable. So, I am not sure if association and composition would do it for me.
Again, I am more concerned about the EstateAgent and House relationship. EstateAgent is providing a service on the House (though indirectly as it uses a Evaluator to do its work), so is there a relationship if any between a House and EstateAgent? Another thing to remember is taht the House to be evaluated would be passed as a parameter to the EstateAgent SLSB business method.

hope this makes it a little bit more clearer...

Thanks,
Parag
[ September 01, 2004: Message edited by: Parag Doshi ]
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!