• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Class relationships

 
Donald R. Cossitt
buckaroo
Ranch Hand
Posts: 401
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"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.
 
paul wheaton
Trailboss
Pie
Posts: 21390
Firefox Browser IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Surasak Leenapongpanit
Ranch Hand
Posts: 341
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Usually association relation is the first choice, after that refine them.
 
Jacquie Barker
author
Ranch Hand
Posts: 201
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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".
 
Donald R. Cossitt
buckaroo
Ranch Hand
Posts: 401
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Excellent! Thanks all and especially Paul - your comments take the edge off of the process.
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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*!
 
Rufus BugleWeed
Ranch Hand
Posts: 1551
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic