Какова кратность

Question

Какова кратность

1

Я не уверен, что такое множественность между A & C, а также между B & C для следующих классов Java...

FYI: класс A и класс B могут ссылаться либо на некоторые, либо на все методы этого родового класса C.

Мое предположение:

Класс A (1) -----Class C (*)
Класс B (1) -----Class 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
    }
}

user614454 23 нояб. 2014, в 17:20

Источник

0

См. UML Надстройка, раздел Классы. Есть детали, которые вам нужно знать.
Vladimir 23 нояб. 2014, в 16:20

Теги:

java

uml

2 ответа

2

Множественность дает вам информацию о том, сколько экземпляров определенного типа, значений атрибутов или связанных экземпляров для ссылки можно создать. Это не имеет никакого отношения к вызову операции. Если, например, множественность на конце ассоциации равна [0.. *], это означает, что к одному экземпляру, связанному с противоположной стороной ассоциации, вы можете подключить нуль или более экземпляров.

AC [0.. *] = один экземпляр A имеет от нуля до неограниченных экземпляров связности C.

Vladimir 23 нояб. 2014, в 14:23

0

Итак, если у каждого метода в классе A или классе B есть экземпляр класса C, то это C [1 .. *]?
user614454 23 нояб. 2014, в 15:58
0

И если, допустим, только некоторые методы класса A / B имеют экземпляры класса C, то это C [0 .. *]?
user614454 23 нояб. 2014, в 16:02
0

Это был пример, как понять множественность. Методы не имеют экземпляра, потому что определять множественность метода не имеет смысла. Только определение кратности в методе (операции) находится в параметрах.
Vladimir 23 нояб. 2014, в 16:23
0

@ user614454 Нет, это не совсем верно. Наличие у локальных экземпляров класса C отдельных методов A / B не связано с множественностью. Кратность описывает отношения на уровне класса ; то есть экземпляр A поддерживает ноль, одну или несколько ссылок на экземпляр C в течение своей жизни.
Jason C 23 нояб. 2014, в 16:25

Показать ещё 2 комментария

Ещё вопросы

См. UML Надстройка, раздел Классы. Есть детали, которые вам нужно знать.
Итак, если у каждого метода в классе A или классе B есть экземпляр класса C, то это C [1 .. *]?
И если, допустим, только некоторые методы класса A / B имеют экземпляры класса C, то это C [0 .. *]?
Это был пример, как понять множественность. Методы не имеют экземпляра, потому что определять множественность метода не имеет смысла. Только определение кратности в методе (операции) находится в параметрах.
@ user614454 Нет, это не совсем верно. Наличие у локальных экземпляров класса C отдельных методов A / B не связано с множественностью. Кратность описывает отношения на уровне класса ; то есть экземпляр A поддерживает ноль, одну или несколько ссылок на экземпляр C в течение своей жизни.

Jason C · Accepted Answer · 2014-11-23T13-32-00.000Z

В общем, вы спрашиваете, сколько разных экземпляров 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;
}

Для однонаправленных я видел некоторые сайты, использующие пунктирную стрелку с той же стрелкой, что и у вас. Означает ли это то же самое, что и ваша диаграмма выше?
@ user614454 Нет, обычно нет. Пунктирная линия обычно указывает на зависимость (которая может быть однонаправленной и обычно есть, но не является ассоциацией), а не на уровне класса. Пунктирная линия была бы более точной для вашего исходного примера, поскольку A зависит от C, даже если он не поддерживает связь с C. Я обновлю свой ответ, чтобы включить это, так как это важно.
Исходя из вашего объяснения, это правильно, если я не знаю количество экземпляров из класса C ... например, в ситуациях, когда это зависит от пользовательского ввода (и я никогда не объявляю ранее в разделе атрибутов кода, как вы показали) ... это значит, что я должен использовать пунктирную версию ??
@ user614454 Пользовательский ввод не имеет значения. Даже если вы не знаете, сколько их будет , если их может быть больше одного, это «много». Но вы бы использовали пунктирную линию не из-за ввода пользователя или чего-то еще, вы бы использовали его, потому что на самом деле вы не поддерживаете ссылку, у вас просто есть локальный экземпляр в методе . Упрощенные правила: если у вас есть поле члена, которое является просто ссылочным типом, это «один». Если это коллекция, это «много». Если нет никакого поля участника вообще, это - ноль или не ассоциация. То, что вы делаете с локальными переменными в методах, не имеет значения.
Независимо от этого, если вы делаете вещи только с локальными экземплярами (например, с вашим примером), но не со ссылками в полях-членах, то это не что иное, как зависимость (которая на самом деле является просто «более слабой» формой ассоциации). «А имеет С» - это ассоциация с множественностью. «Метод A использует C, но A не имеет C» - это просто зависимость, множественность здесь не имеет значения.
@JasonC: обратите внимание, что стрелка навигации, которую вы использовали для своей линии связи на вышеприведенной схеме, устарела. В UML 2.5 предлагается указывать ссылочное свойство (например, A::c в вашем примере) с помощью точки, как описано в stackoverflow.com/questions/21321446/…
Спасибо @gwag! Я буду обновлять диаграммы, как только смогу.