N-ary association alternative

216 views
Skip to first unread message

Fabrício Cabral

unread,
Apr 11, 2013, 2:29:13 PM4/11/13
to umlf...@googlegroups.com
Hi everybody!

Let's suppose in a system, I have a n-ary association among three classes
A, B and C. The problem is the UML tool I'm using (Astah*) doesn't has a
n-ary association symbol.

So, I ask: there is an alternative to a n-ary association with the same
semantics? 

Thanks in advance!

--
--fx

Jim Logan

unread,
Apr 11, 2013, 7:46:45 PM4/11/13
to umlf...@googlegroups.com
Replace it with a class. 

ɯıɾ-

Sent from my  iPhone
--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umlforum+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

H. S. Lahman

unread,
Apr 12, 2013, 2:46:53 PM4/12/13
to umlf...@googlegroups.com
Responding to Cabral...


Let's suppose in a system, I have a n-ary association among three classes
A, B and C. The problem is the UML tool I'm using (Astah*) doesn't has a
n-ary association symbol.

You don't have to use it just because it is in UML. For example, in the methodology I use, the only relationships used are simple binary and generalization.



So, I ask: there is an alternative to a n-ary association with the same
semantics?

There is always a way to do it with binary relations. Consider the example used in the UML Reference Manual:

<pre>
           [Year]
      season | *
             |
       *     |            *
[Team] ------+------------- [Player]
       team  |   goalkeeper
             |
             |
         [Record]
         + goals for
         + goals against
         + wins
         + losses
         + ties
</pre>

where [Record] is the associative object for the ternary relationship. It is basically a god object because it is going to need a huge implementation to keep track pf all that stuff. The big clue that something is wrong with this picture is the relationship roles. Look at Season. That's clearly a class with a 'year' attribute. Look at [Player]. Assuming you are playing soccer, how interesting are goals against for a Midfielder? Maybe somebody wants to keep track of +/- for every position, but in most applications it won't be relevant. Then the relationship with a goalkeeper role would be a separate one from a relationship between [Team] and [Player] with a role of 'member'. And a role of 'team' on a relationship to a [Team] class? Get serious.

For the sake of argument, though, suppose you really are interested in only +/- for every player:

<pre>

       *                  *          *     played during *
[Team] -------------------- [Player] --------------------- [Season]
       member of  |                          |             + year
                  |                          |
                  |                          |
                  +------- [Record] ---------+
                           + goals for
                           + goals against
                           + wins
                           + losses
                           + ties
</pre>

IOW, no n-ary relationship is needed. (Note there is no rule that says associative objects can only apply to one relationship.)

If you are only interested in the statistics only for goalkeepers, then the notion of 'goalkeeper' becomes important because of its special statistics (e.g., vs. a Midfielder). Then good problem space abstraction practice says that that Player role should be a first class object and you will have more relationships. Once you have those additional classes and  <binary> relationships needed to correctly abstract the problem space for the problem in hand, you can place the associative class for statistics correctly.

-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

Imagine how much more difficult physics would be if electrons had feelings
   -- Richard Feynman

Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
software book-: Model Based Development, Addison-Wesley, 2011
geology book: The Evolution and Utilization of Marine Resources, MIT Press, 1972

Reply all
Reply to author
Forward
0 new messages