UML-связь и зависимость

Ответ 1

Короткий ответ: каким образом любая конкретная конструкция исходного языка должна быть представлена ​​в UML, строго не определена. Это будет частью стандартизованного профиля UML для рассматриваемого языка, но это, к сожалению, мало и далеко. Далее следует длинный ответ.

В вашем примере, боюсь, мне придется сказать "ни", просто быть трудным. A имеет переменную-член типа B, поэтому отношение на самом деле является агрегацией или композицией... или направленной ассоциацией. В UML направленная ассоциация с именованной целевой ролью семантически эквивалентна атрибуту с соответствующим именем.

Как правило, это агрегирование, если B инициализируется в конструкторе A; это композиция, если она также уничтожается в деструкторе B (общий жизненный цикл). Если они не применяются, это атрибут/направленная ассоциация.

Если B не является переменной-членом в A, а локальная переменная B не была операционирована (на ней не были вызваны никакие методы), я бы представлял это как зависимость: A B, но у него нет атрибута этого типа.

Но f() фактически вызывает метод, определенный в B. Это для меня делает правильное отношение a <<use>>, которое является более специализированной формой зависимости.

Наконец, (неориентированная) ассоциация является самой слабой формой связи между двумя классами, и по этой причине я склонен не использовать их при описании исходных конструкций. Когда я это делаю, я обычно использую их, когда нет прямых отношений с исходным кодом, но эти два класса все равно связаны друг с другом. Примером этого может быть ситуация, когда они отвечают за разные части одного и того же более крупного алгоритма, но третий класс использует их оба.

Ответ 2

Может быть полезно увидеть этот вопрос, который я задал: имеет ли ассоциация зависимость от UML

Мое понимание:

Ассоциация

public class SchoolClass{
    /** This field, of type Bar, represents an association, a conceptual link
     *  between SchoolClass and Student. (Yes, this should probably be
     *  a List<Student>, but the array notation is clearer for the explanation)
     */
    private Student[] students;
}

Зависимость

public class SchoolClass{

    private Timetable classTimetable;

    public void generateTimetable(){
        /* 
         * Here, SchoolClass depends on TimetableGenerator to function, 
         * but this doesn't represent a conceptual relationship. It more of
         * a logical implementation detail.
         */
        TimetableGenerator timetableGen = new TimetableGenerator();

        /*
         * Timetable, however, is an association, as it is a conceptual 
         * relationship that describes some aspect of the data that the 
         * class holds (Remember OOP101? Objects consist of data and operations
         * upon that data, associations are UMLs way or representing that data)
         */
        classTimetable = timetableGen.generateTimetable();
    }

}

Ответ 3

Если вы хотите увидеть разницу на уровне кода, в ассоциации между A и B, реализация A (или B или обоих в зависимости от мощности, навигационной способности...) в OO lang будет включать атрибут типа B.

Вместо того, чтобы быть зависимым, у A, вероятно, был бы метод, в котором один из параметров имеет тип B. Таким образом, A и B не связаны, но изменение B влияет на зависимый класс A, поскольку, возможно, способ, которым метод A манипулирует объектом B больше недействителен (например, B изменил сигнатуру метода, и это вызывает ошибку компиляции в классе A)

Ответ 4

Получите это от Wiki: Dependency - более слабая форма отношения, которая указывает, что один класс зависит от другого, потому что он использует его в некоторый момент времени. Один класс зависит от другого, если последний является переменной параметра или локальной переменной метода первого. Это отличается от ассоциации, где атрибут первого является экземпляром последнего.

Итак, я считаю, что случай здесь - это ассоциация, если B - переменная параметра или локальная переменная метода A, то они являются зависимостью.

Ответ 5

На самом деле зависимость очень слабо определена. Таким образом, не было бы представления кода.

Wiki:. Зависимость - это семантическая связь, в которой изменение входящего или независимого элемента моделирования может влиять на семантику зависимого элемента моделирования. [1]

Из спецификации OMG:. Зависимость - это отношение, которое означает, что для одного или набора элементов модели требуются другие элементы модели для их спецификации или реализации. Это означает, что полная семантика зависимых элементов либо семантически, либо структурно зависит от определения элемента (ов) поставщика.