Book a Demo

Author Topic: If it's not aggregation or comp., who owns it?  (Read 5892 times)

derek73

  • EA User
  • **
  • Posts: 22
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
If it's not aggregation or comp., who owns it?
« on: January 03, 2007, 03:00:22 am »
Today I was updating my Class and Sequence diagrams, which have evolved over a year (back when I knew nothing of UML at all). I noticed some ownership lines between classes that struck me as not quite right, so I was hoping you folks could chime in.

Take these 4 classes: Launcher, IOHookFactory, IOHook and ResultManager.  The Launcher is responsible for creating the other 3, but ownership is different.  The IOHook is passed into the ResultManager's constructor, so on my diagram I show composition between the ResultManager and IOHook (black diamond).  The ResultManager is owned by the Launcher, so a black diamond goes there, too.

However, I was staring at my white-diamond, Aggregate line between my IOHookFactory and Launcher.  The IOHookFactory is instantiated by the Launcher, but it is never kept around (goes out of scope pretty quickly).

There is an association -- but now I'm thinking it's neither composition nor aggregation.  So what kind of line do I draw?  "Uses"?

Thanks for following along!

Derek

« Last Edit: January 03, 2007, 03:02:40 am by derek73 »

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: If it's not aggregation or comp., who owns it?
« Reply #1 on: January 04, 2007, 08:31:15 pm »
Sounds like you are using Dependency Injection (AKA; Inversion of Control [IoC]) as a design strategy.  If you are, I'd use a Dependency relation.
Verbal Use Cases aren't worth the paper they are written upon.

«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: If it's not aggregation or comp., who owns it?
« Reply #2 on: January 05, 2007, 04:02:19 am »
A suggestion if I may. [And a bit off the top of my head, so please bear with me.]

Think about a parameter to an operation. Would you model this using some form of aggregation? I suspect not, unless the parameter was stored to some internal attribute.

For example, a call to a factory may include some parameter that allows the factory to determine which subclass to return (for example). However, neither the parameter nor the returned class are members of the factory.

Jim is quite correct. Depending on the context, a dependency link might well be appropriate, although perhaps not on your current diagram.

Think of other viewpoints involving the same elements. If you were looking at sequence diagrams you might see the parameter and return value being passed. If you were looking at collaboration or other views you would likely see other links with different - but still not aggregation or composition - links.

David
No, you can't have it!