Sparx Systems Forum

Enterprise Architect => Uml Process => Topic started by: derek73 on January 03, 2007, 03:00:22 am

Title: If it's not aggregation or comp., who owns it?
Post by: derek73 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

Title: Re: If it's not aggregation or comp., who owns it?
Post by: jeshaw2 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.

Title: Re: If it's not aggregation or comp., who owns it?
Post by: «Midnight» 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