UML关系 - 虚线与实线

问题描述 投票:40回答:6

这两种关系有什么区别?

编辑:此外,如果您可以提供一个简单的代码示例来说明差异,那将非常有用!

language-agnostic uml relationship class-diagram
6个回答
22
投票

我试图给出两种类型的线的简单例子。

在第一个图中,实线显示了一个关联:

如果类是用Java声明的,那就像ClassA存储对ClassB的引用作为属性(它可以传入构造函数,创建等)。所以,你可能会看到类似的东西:

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

在第二个图中,它显示了一个依赖项:

依赖性比关联弱得多。引用UML Distilled:

对于类,存在依赖性的原因有多种:一个类向另一个类发送消息;一个班级有另一个班级作为其数据的一部分;一个类提到另一个作为操作的参数。 [...]只要您想要显示一个元素的更改如何改变其他元素,就可以使用依赖关系。

同样,使用Java,存在几个示例:类型为ClassB的参数传递给方法,或者方法声明类型为ClassB的局部变量:

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

其他方式ClassA可能依赖于ClassB而没有关联(不是详尽的列表):

  • ClassB有一个静态方法,ClassA称之为
  • ClassA捕获了ClassB类型的例外情况
  • 每当修改ClassB时,还必须修改ClassA(例如,共享一些逻辑)

19
投票

我认为这个网页足够了:http://www.classdraw.com/help.htm以下文字来自它,但应该足以理解我认为的差异。

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

关联也可以是单向的,其中一个类知道另一个类和关系但另一个类不知道。这种关联需要一个空心箭头指向已知的类,只有已知的类可以具有角色名称和多样性。在示例中,Customer类知道购买的任何数量的产品,但Product类对任何客户一无所知。多重性“0 .. *”表示零或更多。

依赖关系是两个类之间的弱关系,用虚线表示。在该示例中,Point和LineSegment之间存在依赖关系,因为LineSegment的draw()操作使用Point类。它表明LineSegment必须知道Point,即使它没有该类型的属性。此示例还说明了如何使用类图来关注上下文中的重要内容,因为您通常不希望为所有类操作显示此类详细依赖项。

由于我的声誉只有8,我不能自己放置图像,但它们仍然可以在我刚开始提到的网页上找到。

[编辑]

我这里没有代码示例,但我个人会解释它就像汽车和门一样简单。

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

Car --- has a --> Door

但是当你有一扇可以打开的门时,门类就会有类似的功能

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

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

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

door1.open();
}

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

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

我希望这会做;)


5
投票

虚线表示对(沿箭头方向)的依赖性。假设您已将源代码整齐地组合到每个类的单独文件和标题中 - 赠送只是代码包含#include ClassB.h行。

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

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

虽然纯虚拟类提供了多个继承的前景,并且尽可能地在类之间进行最紧密的耦合。接口类的优势在于它们完全由暗物质制成,因此对警察来说完全不可见。考虑到这一点,有可能编写c ++代码,类之间显然是零耦合 - 他们喜欢这样,因为他们从来没有真正理解所有那些看起来很滑稽的符号。


5
投票

好的,既然你没有接受第一个答案;让我尝试。

箭头1:正常关联

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

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

我们如何在代码中实现这一目标?

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.

如果存在需要存在的连接,关系,关联等,则向A类工作​​;这是一种依赖。例子:丈夫需要妻子存在。汽车需要一个轮子作为汽车(和驱动器)。汽车工厂需要汽车类来制造物体。您的RSSNewsItem类需要XMLReader类来执行任何操作。

什么时候用哪个?

嗯,这是我眼中唯一有效的问题;因为谷歌显示了很多有效的问题答案。尽量不要在类图中使用依赖项,因为它通常意味着您不够具体。始终瞄准关联,实现等。如果需要使用其他类而不保持关系,则仅使用实现(在我看来)。例;实用程序类(如XMLReader)。

如果您在阅读完整说明后有任何疑问,请随时提出。 :-)


3
投票

你的问题让我有机会学习自己,这就是我发现的 -

enter image description here

协会:另一种类型的所有权(例如'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);
}

这是我发现的一个清晰的参考 - Association vs. Dependency


-5
投票

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

© www.soinside.com 2019 - 2024. All rights reserved.