UML-отношения - пунктирная линия против сплошной линии

В чем разница между этими двумя отношениями?

Edit: Также, если вы могли бы предоставить простой пример кода, иллюстрирующий разницу, это было бы очень полезно!

Ответ 1

Эта веб-страница говорит, что я думаю: http://www.classdraw.com/help.htm Следующий текст исходит из этого, но должно быть достаточно, чтобы понять разницу, о которой я думаю.

Таким образом, в основном сплошная линия представляет собой ассоциацию, а пунктирная линия - зависимость.

Ассоциации также могут быть однонаправленными, где один класс знает о другой класс и отношения, а другой класс - нет. Такие ассоциации требуют, чтобы открытая стрелка указывала на класс, который известен, и только известный класс может иметь имя роли и множественность. В этом примере класс Customer знает о любых количество приобретенных продуктов, но класс продукта ничего не знает о любой клиент. Кратность "0.. *" означает ноль или более.

Зависимость - это слабая связь между двумя классами и представленной пунктирной линией. В этом примере существует зависимость между Point и LineSegment, поскольку операция DrawSegment draw() использует класс Point. Это указывает, что LineSegment должен знать о Точка, даже если она не имеет атрибутов этого типа. Этот пример также иллюстрирует, как диаграммы классов используются, чтобы сосредоточиться на том, что важно в контексте, поскольку вы обычно не хотели бы показывать такие подробные зависимости для всех ваших операций класса.

Поскольку моей репутации всего 8, я не могу разместить изображения самостоятельно, но их все еще можно найти на веб-странице, о которой я упоминал в начале.

[EDIT]

У меня нет примеров кода прямо здесь, но как я лично объясню, это так же просто, как автомобиль и дверь.

Когда автомобиль имеет дверь (или больше), это просто автомобиль

Car --- has a --> Door

Но когда у вас есть дверь, которую можно открыть, класс двери будет иметь функцию типа

public void openDoor(){
this.open();
}

Чтобы использовать функцию выше, автомобиль должен будет создать экземпляр двери

Class Car(){
Door door1 = new Door();

door1.open();
}

Таким образом вы создали зависимость.

Таким образом, сплошная линия просто указывает объект (1) на другой объект (2), но когда вы начинаете использовать объект (1), он становится зависимым.

Я надеюсь, что это будет;)

Ответ 2

Я пытаюсь дать простые примеры двух типов строк.

На первой диаграмме сплошная линия показывает ассоциацию:

Если классы были объявлены в Java, это было бы как ClassA сохранение ссылки на ClassB как атрибут (его можно было бы передать конструктору, созданному и т.д.). Итак, вы можете увидеть что-то вроде:

public class ClassA {
    ClassB theClassB = ...
    ...
}

На второй диаграмме показана зависимость:

Зависимость значительно слабее, чем ассоциация. Цитата из UML Distilled:

С классами зависимости существуют по разным причинам: один класс отправляет сообщение другому; один класс имеет другую часть своих данных; один class упоминает другое как параметр для операции. [...] Вы используете зависимости когда вы хотите показать, как изменения в одном элементе могут изменять другие элементы.

Опять же, используя Java, существует несколько примеров: аргумент типа ClassB передается методу или метод объявляет локальную переменную типа ClassB:

public class ClassA {
    ...
    public void someMethod(ClassB arg1) {...}
    ...
    public void someOtherMethod() {
        ClassB localReferenceToClassB = ...
    }
    ...
}

Другие способы ClassA могут зависеть от ClassB без ассоциации (а не с исчерпывающим списком):

ClassB имеет статический метод, который ClassA вызывает
ClassA ловит исключения типа ClassB
Всякий раз, когда ClassB изменяется, ClassA также необходимо изменить (например, какая-то общая логика)

Ответ 3

Хорошо, так как вы не приняли первый ответ; Дай мне попробовать.

Стрелка 1: нормальная ассоциация

UML имеет разные типы линий и стрелок. Выше находится простая стрелка ассоциации, которая означает, что один класс может иметь ссылку на другой класс. Ниже я объясню каждый тип С примерами кода.

В первом примере вы можете видеть, что на самом деле не указано, кто знает, кто (кто является владельцем отношений). Животное может знать человека, а человек может знать животное. Это не указано и, следовательно, не очень полезно для программиста.
Во втором примере у исполнителя может быть гитара. Поскольку есть стрелка, а на другой ее нет, мы знаем, что гитара не знает исполнителя. Гитара - это объект, который может полностью существовать сам по себе и никому не нужен.
В третьем примере вы видите брак. Действительно просто; муж знает жену, а жена знает ее мужа. В нашей ситуации у мужа есть только одна жена и наоборот.

Как мы обычно выполняем это в коде?

class Husband{
    Wife bestWomanInTheWorld;

    public Husband(Wife theWife){
        this.bestWomanInTheWorld = theWife;
    }
}

Поскольку муж всегда нуждается в жене, мы устанавливаем необходимые отношения в конструкторе. Поскольку у художника может быть гитара, мы бы оставили конструктор пустым, как это:

class Artist{
    List<Guitar> guitars;

    public Artist(){
    }

    public AddGuitarToCollection(Guitar newGuitar){
        Guitars.Add(newGuitar);
    }
}

Итак, вот как мы выполняем это в коде (большую часть времени!). Обычно вам не нужны разные типы линий и стрелок, если вы новичок в программировании. Будь проще.

Стрелка 2: Зависимость

Итак, мы знаем о нормальных ассоциациях, которые мы будем использовать большую часть времени. Но когда мы будем использовать стрелку "зависимость"? Хорошо, давайте определим зависимость (википедия):

Dependency is a weaker form of bond which indicates that one class depends on 
another because it uses it at some point in time. One class depends on 
another if the independent class is a parameter variable or local variable of 
a method of the dependent class. This is different from an association, where 
an attribute of the dependent class is an instance of the independent class. 
Sometimes the relationship between two classes is very weak. They are not 
implemented with member variables at all. Rather they might be implemented as 
member function arguments.

Если есть связь, отношение, ассоциация и т.д., Которые должны присутствовать, к классу А для работы; это зависимость. Пример: мужу нужна жена, чтобы существовать. Авто нужно колесо, чтобы быть машиной (и водить). Автомобильному заводу нужен класс автомобилей, чтобы сделать из него предмет. Вашему классу RSSNewsItem нужен класс XMLReader, чтобы делать что-либо.

Когда использовать что?

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

Если у вас есть какие-либо вопросы после прочтения этого полного объяснения, не стесняйтесь спрашивать. :-)

Ответ 4

Пунктирная линия указывает зависимость от (в направлении стрелки). Предполагая, что вы аккуратно собрали исходный код в отдельные файлы и заголовки для каждого класса - раздача просто заключается в том, что код включает строку #include ClassB.h.

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

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

В то время как чистые виртуальные классы предлагают перспективу множественного наследования и максимально возможного сочетания всех между классами. Классы интерфейса имеют то преимущество, что они сделаны полностью из темной материи и настолько полностью невидимы для полиции. Имея это в виду, можно написать С++-код с явно нулевой связью между классами, которые они любят, потому что они никогда не понимали всех этих забавных символов в любом случае.

Ответ 5

Ваш вопрос дал мне хороший шанс узнать себя, вот что я нашел -

Ассоциация: право собственности другого типа (например, "А" владеет "В")

//@assoc  The Player(A) has some Dice(B)
class Player {
    Dice myDice;
}

Зависимость: использование другого типа (например, "C" использует "D")

//@dep    The Player(C) uses some Dice(D) when playing a game
class Player {
    rollYahtzee(Dice someDice);
}

Вот свежая ссылка, которую я нашел - Ассоциация против Зависимости

Ответ 6

пунктирные средние объекты (интерфейс) твердое средство расширяет (базовый класс)