UML 关系-虚线与实线

小开

这个网页说得够多了，我想下面的文本来自它，但应该足以理解其中的差异。

所以基本上实线是一种关联，虚线/虚线是一种依赖关系。

关联也可以是单向的，只有一个类知道其他类和关系，但其他类没有。这样的关联需要一个开放的箭头来指向是已知的，并且只有已知的类可以具有角色名和在本例中，Customer 类知道任何购买的产品数量，但 Product 类对此一无所知多重性“0. . *”意味着0或更多。

依赖项是两个类之间的弱关系，它是在这个例子中，有一个依赖项点和线段之间，因为线段的绘制()操作使用 Point 类。它表示 LineSegment 必须知道点，即使它没有该类型的属性说明了如何使用类图来关注在上下文中很重要，因为你通常不会想要显示这样的所有类操作的详细依赖项。

由于我的声誉只有8，我不能把图片本身，但他们仍然可以在网页上找到我在开始提到。

[编辑]

我这里没有代码示例，但是我个人将如何解释它就像汽车和门一样简单。

当一辆汽车有门(或更多)时，它就只是一辆汽车

Car --- has a --> Door

但是，当你有一个门 可以打开的门类将有一个功能，如

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

要使用汽车上方的功能，必须创建一个门的实例

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


door1.open();
}

通过这种方式，您已经创建了一个依赖项。

所以实线只是把一个对象(1)指向另一个对象(2) ，但是当你开始使用对象(1)时，它就变成了一个依赖项。

小开

好吧，既然你不接受第一个答案，让我试试。

箭头1: 一个正态关联

enter image description here

UML 有不同类型的线和箭头。上面是一个简单的关联箭头，这意味着一个类可以有到另一个类的链接。下面我将解释每种类型的 WITHcode 示例。

在第一个示例中，您可以看到没有真正指定谁知道谁(谁是关系的所有者)。动物认识人类，人类认识动物。它没有指定，因此对程序员没有真正的帮助。
在第二个例子中，艺术家可以有一把吉他。因为有一个箭头，没有一个在另一边，我们知道吉他 不知道的艺术家。吉他是一个物体，完全可以独立存在和不需要任何人。
在第三个例子中，你看到一段婚姻。很简单，丈夫认识妻子，妻子认识丈夫。在我们的情况下，丈夫只有一个妻子，反之亦然。

我们如何在代码中实现这个通常？

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);
}
}

So, that's how we accomplish this in code (most of the time!). You won't usually need different types of lines and arrows if you are new to programming. Keep it simple.

箭头2: 依赖

好的，我们知道了常规关联，我们大部分时间都会用到它。但是我们什么时候使用“依赖”箭头呢？那么，让我们定义一个依赖关系(wikipedia) :

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.

如果有一个连接、关系、关联等需要存在，那么到 class A 就可以工作; 它是一个依赖项。例句: 丈夫需求妻子的存在。一辆汽车需求一个轮子是一辆汽车(和驾驶)。一个汽车工厂需求一个汽车类，使一个对象从它。您的 RSSNewsItem 类需求和 XMLReader 类可以执行任何操作。

什么时候用哪个？

嗯，这是我眼中唯一有效的问题，因为谷歌显示了很多有效的答案，你的问题。尽量不要在类图中使用依赖项，因为这通常意味着您不够具体。始终以联想、实现等为目标。只有在需要使用其他类而不需要维护关系的情况下才使用实现(在我看来)。实用程序类(如 XMLReader)。

如果您在阅读完整的解释后有任何问题，请随时提问。 : -)

小开

虚线表示实现(接口) 固体方法扩展(基类)

小开

我试图给出这两种类型的行的简单示例。

在第一张图中，实线表示一种联系:

PlantUML diagram of a directed association

如果这些类是用 Java 声明的，那么就像 ClassA将对 ClassB的引用存储为一个属性(它可以传递给构造函数，创建等等)。所以，你可能会看到这样的东西:

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

在第二个图中，它显示了一个依赖关系:

PlantUML diagram of dependency

依赖关系比关联关系要弱得多。引用 UML 提取的结果:

对于类，依赖关系的存在有多种原因: 一个类向另一个类发送消息; 一个类将另一个类作为其数据的一部分; 类提到另一个作为操作的参数。[ ... ]使用依赖项当您想要显示一个元素中的更改如何改变其他元素时。

同样，使用 Java，有两个例子: 一个类型为 ClassB的参数被传递给一个方法，或者一个方法声明一个类型为 ClassB的局部变量:

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

其他方法 ClassA可以 取决于在 ClassB上没有关联(不是详尽的列表) :

ClassB有一个 ClassA调用的静态方法
ClassA捕获 ClassB类型的异常
每当修改 ClassB时，也必须修改 ClassA(例如，一些逻辑是共享的)

小开

虚线表示对(箭头方向)的依赖。假设您已经将源代码整齐地组装到每个类的单独文件和头中代码中包含了 # include ClassB.h 这一行。

然而事实上，所有的类关系(泛化、实现、合成、聚合、关联等)都继承了依赖关系。因此，在编写代码文档时，我从不使用虚线箭头。在可能的情况下，我的目标是用更具体的术语来记录这种关系，例如方块、三角形等。如果我不知道确切的关系，我的起点是一条带箭头的实线(一个关联，带(隐式)依赖)。

尽管如此，虚线箭头符号在 UML 建模的其他方面还是很有用的，例如，在用例分析中显示需求的依赖关系。注意思想警察会让我们通过使用接口(纯虚拟类)来减少类之间的耦合和依赖。

虽然纯粹的虚拟类提供了所有类之间尽可能多重继承和最紧密耦合的前景。接口类的优势在于它们完全由暗物质构成，因此警察完全看不见它们。考虑到这一点，编写 c + + 代码显然可以在类之间实现零耦合——他们喜欢这一点，因为他们从来没有真正理解所有这些看起来有趣的符号。

小开

你的问题给了我一个很好的机会来了解自己，这是我发现-

关联 : 另一种类型的所有权(例如，‘ A’拥有‘ B’)

//@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);
}

这是我找到的一个干净的裁判联想与依赖