Я не уверен, что такое множественность между A & C, а также между B & C для следующих классов Java...
FYI: класс A и класс B могут ссылаться либо на некоторые, либо на все методы этого родового класса C.
Мое предположение:
Пожалуйста, поправьте меня, если я ошибаюсь здесь.
Еще одна вещь, когда это отношение "много-ко-многим" для обоих (1) & (2)?
class A{
//methods in Class A only involve Ball objects
methodA(){
C<Ball> newObj=new C<Ball>();
newObj.method1();
}
}
class B{
//methods in Class B only involve Tennis objects
methodB(){
C<Tennis> newObj=new C<Tennis>();
newObj.method1();
}
}
class C<T>{
method1(){
//implementation here
}
method2(){
//implementation here
}
method3(){
//implementation here
}
}
В общем, вы спрашиваете, сколько разных экземпляров X может существовать для одного экземпляра Y, и наоборот? В вашем примере совершенно не имеет смысла говорить о множественности в контексте диаграммы классов по двум причинам:
Ваш C не поддерживает ссылку на любые ассоциированные A или B. Поэтому, в лучшем случае, это однонаправленные отношения. Это нормально, если говорить о множественности, хотя и не в вашем конкретном примере (для чего множественность не имеет смысла, см. Пункт 2). Что касается множественности, то, игнорируя точку 2, A имеет ровно 1 C, B имеет ровно 1 C, а C имеет 0 A и 0 B.
Ваши отношения находятся в форме локальной переменной. Поэтому на самом деле это не отношения класса. Это соотношение исчезает, как только возвращается метод A (или B). Так что действительно не имеет смысла устанавливать диаграмму ассоциаций для этих классов. Граф звонящего/вызываемого, возможно, но общая ассоциация, нет.
Ваш пример, где A использует C локально в некоторых его методах, является примером зависимости, а не ассоциации. UML обычно использует пунктирную линию для этого (хотя некоторые варианты могут отличаться), и множественность не вступает в игру для этого (извините за низкое качество):
В вашем примере есть несколько небольших изменений, которые сделают множественность релевантной. Например, оставляя C как есть, но меняя A на:
class A {
C<Ball> c = new C<Ball>();
...
methodA(){
c.method1();
}
}
В этом случае A имеет ровно один C, а C имеет нуль A (однонаправленный). UML будет выглядеть (опять же, извините за качество):
То есть, если вы сделаете изменение выше, оно станет отношением "один к одному". Он однонаправлен, потому что C не знает о A.
Еще одна вещь, когда это отношение "много-ко-многим" для обоих (1) & (2)?
Это отношение "многие ко многим", когда A хранит ссылки на несколько C, а C хранит ссылки на несколько A. Например, студенты к курсам в университете. Каждый курс содержит несколько учеников, и каждый студент принимает несколько курсов. Например:
class Student {
Collection<Course> courses;
}
class Course {
Collection<Student> students;
}
Множественность дает вам информацию о том, сколько экземпляров определенного типа, значений атрибутов или связанных экземпляров для ссылки можно создать. Это не имеет никакого отношения к вызову операции. Если, например, множественность на конце ассоциации равна [0.. *], это означает, что к одному экземпляру, связанному с противоположной стороной ассоциации, вы можете подключить нуль или более экземпляров.
AC [0.. *] = один экземпляр A имеет от нуля до неограниченных экземпляров связности C.