UML关系 - 虚线与实线

时间:2014-11-17 22:06:49

标签: language-agnostic uml relationship class-diagram

这两种关系有什么区别?

enter image description here

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

6 个答案:

答案 0 :(得分:22)

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

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

PlantUML diagram of a directed association

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

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

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

PlantUML diagram of dependency

依赖关系比关联弱得多。引用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(例如,共享某些逻辑)

答案 1 :(得分:19)

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

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

  

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

     

依赖是两个类之间的弱关系而且是   用虚线表示。在该示例中,存在依赖性   在Point和LineSegment之间,因为LineSegment的draw()操作   使用Point类。它表明LineSegment必须知道   点,即使它没有该类型的属性。这个例子也是   说明了如何使用类图来关注什么是   在上下文中很重要,因为你通常不想表现出来   所有类操作的详细依赖关系。

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

<强> [编辑]

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

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

Car --- has a --> Door

但是当你有一个可以打开的门 时,门类将具有类似

的功能
public void openDoor(){
this.open();
}

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

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

door1.open();
}

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

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

我希望这样做;)

答案 2 :(得分:5)

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

箭头1:正常关联

enter image description here

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.

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

何时使用?

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

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

答案 3 :(得分:5)

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

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

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

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

答案 4 :(得分:3)

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

enter image description here

协会:其他类型的所有权(例如&#39; A&#39;拥有&#39; B&#39;)

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

依赖:使用其他类型(例如&#39; C&#39;使用&#39; D&#39;)

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

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

答案 5 :(得分:-5)

点缀均值实现(接口) solid意味着扩展(基类)