UML依赖关系

3

我找不到我的问题的答案。两个类之间的依赖关系是否有限制?一般情况下,UML类图不能在两个类之间具有相同类型的多个关系,但它们可以具有不同类型的2个或更多关系(例如,它们可能具有组合和泛化关系)。

3个回答

3

两个类之间可以有多个关联,也可以有多个依赖。您应该使用构造型来区分这些依赖。


谢谢您的回答,这些规则适用于聚合、组合和泛化关系吗?我可以有两个类之间同时存在组合和泛化关系吗? - Macieyerk
当然。您需要使用“类型刻板印象”来区分概括,因为使用多个没有意义。 - Jim L.
最后一个问题,我可以在两个类之间混合使用不受限制的不同关系,例如聚合+组合、组合+泛化或依赖+关联+聚合+组合+泛化吗? - Macieyerk
我已经点赞了,但由于我的声望较低,它不会显示。 - Macieyerk
谢谢。是的,您可以拥有许多关联,每个关联都有一种聚合或组合。就像我所说的,您可以有许多泛化和许多依赖项,但除非您使用原型对它们进行区分,否则它们没有意义。原型可以将“线”变成更具体的UML依赖或泛化的实例。你为什么会问这样奇怪的问题呢? - Jim L.
谢谢回答,我在考试中遇到了类似的问题,但是我失败了,我想知道答案,因为老师没有解释。 - Macieyerk

2
一般来说,UML规范不限制同一类之间特定类型的关系数量,但由于关系的逻辑和含义,你可以假设一些限制。
1. 泛化、实现具有意义,如果两个类之间存在这种关系,它直接暗示了一些后果。重复第二次相同的关系将没有进一步的影响,因此毫无意义。通过构造型难以进一步专门化这些关系。
2. 简单依赖关系提供了一些信息,再次建立下一个依赖关系就不能“重复”了。然而,构造型依赖关系可以带来更多的价值和信息,因此您可以拥有多个不同构造型的依赖关系。一旦您有了一个特定构造型的依赖关系,重复相同的依赖关系就不会提供额外的价值,但是使用不同构造型的另一个依赖关系是完全可以理解和合理的情况。理论上,相同的依赖关系可以在两个不同的方向上应用两次,但我会深入调查-通常这表明项目存在问题。
3. 两个类之间的关联(包括聚合-共享和组合)可能具有许多不同的含义。它们应该通过关联名称、关联角色、构造型或通过混合这些方法进行区分。因此,您可以在同两个类之间拥有多个相同“类型”的关联,并且它们将具有重要的含义。因此,在同一类之间拥有许多关联是完全可以接受的,这是一个典型的情况。
4. 混合不同的关系也是完全可以的,但有时一个关系意味着其他关系。通常,任何(或几乎任何)关系都暗示非构造型依赖关系(在相同方向上),因此明确使用它不会提供任何额外的信息或效果。

1

两个类之间的依赖关系数量没有限制。但是您必须考虑几个重要的时刻。在首席架构师Vaughn Vernon的网站https://vaughnvernon.co上,我发现了有关使用UML依赖关系的有趣评论:

虽然依赖关系可能有广泛的含义,但最好不要过度使用依赖关系。在分析模型类图(例如领域模型图)中,您可能会想传达所有类都相互依赖的信息。然而,有趣的是,统一过程(RUP)规定,在分析模型中应该使用的一般类关系是关联,而不是依赖关系。因此,即使您正在建模更高级别的概念,最好也不要松散地使用依赖关系。它太模糊了。
此外,除非您以受限制的方式使用依赖关系,否则您的模型使用者(您自己或其他开发人员)将仅对其含义有过于广泛的解释。通常,在项目中担任架构师和设计师角色的人员旨在为经验较少的开发人员提供指导。因此,依赖关系应用于从架构师和设计师向开发人员传达特定类型的指导。
那么依赖关系应该表示什么?在上面的UML示例中,依赖关系意味着类A使用类B,但类A不包含类B的实例作为其自身状态的一部分。这还意味着如果类B的接口发生更改,它很可能会影响类A并要求其进行更改。我建议您将对依赖关系的使用限制在与状态无关的问题上。例如,您可以使用依赖关系来指示类A至少有一个方法接收类B的实例作为参数。您还可以使用依赖关系来指示类A在其方法之一中创建了类B的实例。但是,您不应使用依赖关系来指示类A声明了类B的实例变量,因为这将表示与状态相关的问题。再次强调,使用关联来完成这项工作。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接