File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Class relationships Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Class relationships" Watch "Class relationships" New topic
Author

Class relationships

Donald R. Cossitt
buckaroo
Ranch Hand

Joined: Jan 31, 2003
Posts: 401
As an example:
In a CustomerOrder schema with the following core components:
Account
Item
Order
RushOrder

It is obvious that
RushOrder "Is-a" Order (Inheritance)
Order "Has-a" Item (Aggregation)

However, it is not obvious whether
Order "Uses-a" Account (Dependence)
Account "Has-a" Order (Aggregation)
Account "Uses-a" Order (Dependence)

Inheritance and Aggregation are somewhat straightforward. But Dependence is a bit vague; and what of Association?


doco
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
"uses-a" is a nice description. This kind of thing is discussed heavily down in the OO and OO & UML forum. Drop in and READ a bunch of posts on relationships, then see if you have more to ask about.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20538
    ∞

Is the ocean blue? Or is it green?
How you choose to build your application is up to you. You're struggling with the answers to these questions thinking "Am I dumb to not see what appears obvious to everybody else?" The answer is that everybody else struggles too. Because you are able to ask the question so consisely, you are closer to the solution than many people that call themselves software architects.
A modern approach, which is an excellent approach for beginners, is an agile approach. XP or something like it. You sit down and look at the program you are about to write. You know that you will have something sort of functioning in, say, three hours. What sort of stuff will that thing do? Focus only on the next few hours. Don't worry about six months from now at this moment. Get something going. Once you have something going, it will be clearer whether a "has a" relationship is better than a "uses a" relationship. Changes are easy to make.
Some people think the answers to these questions are obvious. Probably because they struggled with them in the past and came up with answers that satisfied them. Be careful with these people! Often times, they found that a hammer solved a problem in the past, so they try to use a hammer for everything! And sometimes what they insist is a "hammer" is actually a rock (and they call it "The Model/View/Controller Pattern").
Your questions are healthy. Keep asking them.


permaculture Wood Burning Stoves 2.0 - 4-DVD set
Surasak Leenapongpanit
Ranch Hand

Joined: May 10, 2002
Posts: 341
Usually association relation is the first choice, after that refine them.
Jacquie Barker
author
Ranch Hand

Joined: Dec 20, 2000
Posts: 201
When it comes to translating the various relationships into code, aggregation and association relationships are implemented in exactly the same fashion; in fact, one could argue that aggregation could be left out of the UML without any significant loss, since an association could certainly be labeled "has a".


Author of Beginning Java Objects, Beginning C# Objects, and Taming the Technology Tidal Wave
Donald R. Cossitt
buckaroo
Ranch Hand

Joined: Jan 31, 2003
Posts: 401
Excellent! Thanks all and especially Paul - your comments take the edge off of the process.
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
When it comes to translating the various relationships into code, aggregation and association relationships are implemented in exactly the same fashion; in fact, one could argue that aggregation could be left out of the UML without any significant loss, since an association could certainly be labeled "has a".
I do think that distinguishing between aggregation and assiciation is useful in a few situations, including when trying to understand a developing solution design and discovering what design patters might fit well.
Sometimes it's just useful to know whether something uses another thing or whether it actually is composed of it. For instance, a car and a road both interact with car tires. At times, it's useful to distinguish that the car is partly composed of the tires and the road just interacts with them. I don't think I'd like to say the road "has a" car tire in this relationship.
The lil' thing that just kinda bugs me about UML is the distinction between aggregation and composition. At the moment I don't recall what the big deal is all about that these need to be distinguished.
But we can spend days stumbling over semantics and such over in the OO, Patterns and UML forum...
[ October 16, 2003: Message edited by: Dirk Schreckmann ]

[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Dirk Schreckmann:
When it comes to translating the various relationships into code, aggregation and association relationships are implemented in exactly the same fashion; in fact, one could argue that aggregation could be left out of the UML without any significant loss, since an association could certainly be labeled "has a".
I do think that distinguishing between aggregation and assiciation is useful in a few situations, including when trying to understand a developing solution design and discovering what design patters might fit well.
Sometimes it's just useful to know whether something uses another thing or whether it actually is composed of it. For instance, a car and a road both interact with car tires. At times, it's useful to distinguish that the car is partly composed of the tires and the road just interacts with them. I don't think I'd like to say the road "has a" car tire in this relationship.

But would you really *code* it differently?

The lil' thing that just kinda bugs me about UML is the distinction between aggregation and composition. At the moment I don't recall what the big deal is all about that these need to be distinguished.

That's probably because you are programming in Java, where the lifetime of an object is mostly handled by the GC. For C++ programmers it's much more interesting, because Composition shows them who is responsible for calling the destructor.
But we can spend days stumbling over semantics and such over in the OO, Patterns and UML forum...

And we actually *like to*!


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Rufus BugleWeed
Ranch Hand

Joined: Feb 22, 2002
Posts: 1551
I been reading the copy of Uncle Bob's book that I won in this forum.
He claims the hollow diiamond is going away in UML 2. Like Ilja he says the black diamond is important to C++.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rufus BugleWeed:
He claims the hollow diiamond is going away in UML 2. Like Ilja he says the black diamond is important to C++.

That info is outdated - aggregation made it into UML 2 in the last minute... :roll:
william kane
Ranch Hand

Joined: Nov 21, 2000
Posts: 260
Originally posted by Ilja Preuss:

But would you really *code* it differently?

I did not get what you are trying to say here Ilja Are u saying that because one may not implement association and aggregation diffently in terms of code one need not model it diffently???
Please clarify


Help me!Help you!!!
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by william kane:

I did not get what you are trying to say here Ilja Are u saying that because one may not implement association and aggregation diffently in terms of code one need not model it diffently???
Please clarify

I am not totally sure. What do we model for?
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
Originally posted by Ilja Preuss:

I am not totally sure. What do we model for?

In many large corporations, we model to apease the beancounters who insisted on implementing a "solid" (meaning expensive, timeconsuming, ISO compliant, etc. etc.) development process.
When left to their own devices, we model to get an idea of how to best implement something, and in such cases there is no need for different words to mean the same thing (indeed, there often is no need for words at all, a bit of mental exercise is often enough to envision the structure that's best suited to a subproblem and only highlevel diagrams need be comitted to some permanent storage).


42
william kane
Ranch Hand

Joined: Nov 21, 2000
Posts: 260
Originally posted by Ilja Preuss:

I am not totally sure. What do we model for?

In my opinion we model something to express what we have in our minds.During analysis I model(may be on a piece of paper) my understanding of the problem statement.The use of diferent relationships in my class diagram expresses what i understand abt the problem.
In my opinion modelling 'uses a' relationship different from a 'has a' relationship is useful in better expressing the problem and therefore better solving the problem.At this point i dont think abt how i implement the realtionships.
Please correct if i am wrong
william kane
Ranch Hand

Joined: Nov 21, 2000
Posts: 260
Originally posted by Ilja Preuss:

I am not totally sure. What do we model for?

In my opinion we model something to express what we have in our minds.During analysis I model(may be on a piece of paper) my understanding of the problem statement.The use of diferent relationships in my class diagram expresses what i understand abt the problem.
In my opinion modelling 'uses a' relationship different from a 'has a' relationship is useful in better expressing the problem and therefore better solving the problem.At this point i dont think abt how i implement the realtionships.
Please correct if i am wrong
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by william kane:
In my opinion modelling 'uses a' relationship different from a 'has a' relationship is useful in better expressing the problem and therefore better solving the problem.At this point i dont think abt how i implement the realtionships.

Yes, I agree. So in an analysis diagram, the use of aggregation and composition makes sense.
What about a design diagram for a Java application?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Class relationships