UML依赖关系
UML dependency reliationship
我找不到我的问题的答案。两个 classes 之间的依赖关系有多少限制？一般而言，UML class 图在两个 class 之间不能有超过一个相同类型的关系，但它们可以有 2 个或更多不同类型的关系（例如在两个 class是的，它们都可以具有组合和泛化依赖关系？
两个 类 之间可以有很多关联，也可以有很多依赖关系。您应该对这些依赖关系进行刻板印象以区分它们。
一般来说，UML 规范不限制相同类型之间可以有多少个特定类型的关系 类，但是由于关系的逻辑和含义，您可以假设一些限制。
- 泛化、实现是有意义的，如果两者之间存在这种关系类，它直接暗示了一些后果。第二次重复相同的关系不会产生进一步的影响，因此没有任何意义。也很难通过刻板印象进一步专门化这些关系。
- 简单依赖提供了一些信息，这些信息不能通过下一个依赖再次 "repeated"。然而，刻板的依赖可以带来更多的价值和信息，因此您可以拥有不止一种依赖但具有不同的刻板印象。一旦您拥有特定刻板印象的一个依赖项，重复相同的刻板印象不会提供额外的价值，而另一个不同刻板印象的依赖项是完全可以理解和合理的情况。理论上，相同的依赖项可以在两个不同的方向应用两次，但我会深入调查 - 它通常表明项目存在问题。
- 两个 类 之间的关联（包括聚合 - 共享和复合）可以有许多不同的含义。它们应该通过关联名称、关联角色、刻板印象或通过混合这些方法来区分。所以你可以在相同的两个 类 之间有多个相同 "type" 的关联，它们将具有重要意义。同一个类有这么多关联是绝对没问题的，也是典型的情况
- 混合不同的关系也完全可以，但有时一种关系意味着另一种关系。一般来说，任何（或几乎任何）关系都意味着 non-stereotyped 依赖（在同一方向），因此明确使用它不会提供任何额外的信息或效果。
两个 类 之间的依赖项数量没有限制。但是你必须考虑几个重要的时刻。在首席架构师 Vaughn Vernon 的网站 https://vaughnvernon.co 上，我发现了有关 UML 依赖项用法的有趣评论：
While dependency may have a broad meaning, it is best not to overuse
the dependency relationship. In an analysis model class diagram such
as a domain model diagram, you may be tempted to convey that all the
classes just depend on each other. Interestingly, however, the
Rational Unified Process (RUP) specifies that the general class
relationship that should be used in the analysis model is association,
and not dependency. Therefore, even when you are modeling higher-level
concepts it is best not to use the dependency relationship loosely. It
is just too nebulous.
Further, unless you use the dependency relationship in a constrained
manner your model consumers (yourself or other developers) will simply
have too broad an interpretation of its meaning. Generally those
filling architect and designer roles in a project are there to give
guidance to less experienced developers. Thus the dependency
relationship should be used to convey a specific kind of guidance from
architects and designers to developers.
So what should a dependency relationship represent? In our UML example
above the dependency means that class A uses class B, but that class A
does not contain an instance of class B as part of its own state. It
also means that if class B’s interface changes it will likely impact
class A and require it to change. I suggest that you constrain your
use of dependency relationships to non-state related concerns. You
would use dependency to indicate that, for example, class A receives
an instance of class B as a parameter to at least one of its methods.
You would also use dependency to indicate that class A creates an
instance of class B local to one of its methods. You
would not, however, use dependency to indicate that class A declares
an instance variable of class B, as that would indicate a
state-related concern. Again, use association to do that.
我找不到我的问题的答案。两个 classes 之间的依赖关系有多少限制？一般而言，UML class 图在两个 class 之间不能有超过一个相同类型的关系，但它们可以有 2 个或更多不同类型的关系（例如在两个 class是的，它们都可以具有组合和泛化依赖关系？
两个 类 之间可以有很多关联，也可以有很多依赖关系。您应该对这些依赖关系进行刻板印象以区分它们。
一般来说，UML 规范不限制相同类型之间可以有多少个特定类型的关系 类，但是由于关系的逻辑和含义，您可以假设一些限制。
- 泛化、实现是有意义的，如果两者之间存在这种关系类，它直接暗示了一些后果。第二次重复相同的关系不会产生进一步的影响，因此没有任何意义。也很难通过刻板印象进一步专门化这些关系。
- 简单依赖提供了一些信息，这些信息不能通过下一个依赖再次 "repeated"。然而，刻板的依赖可以带来更多的价值和信息，因此您可以拥有不止一种依赖但具有不同的刻板印象。一旦您拥有特定刻板印象的一个依赖项，重复相同的刻板印象不会提供额外的价值，而另一个不同刻板印象的依赖项是完全可以理解和合理的情况。理论上，相同的依赖项可以在两个不同的方向应用两次，但我会深入调查 - 它通常表明项目存在问题。
- 两个 类 之间的关联（包括聚合 - 共享和复合）可以有许多不同的含义。它们应该通过关联名称、关联角色、刻板印象或通过混合这些方法来区分。所以你可以在相同的两个 类 之间有多个相同 "type" 的关联，它们将具有重要意义。同一个类有这么多关联是绝对没问题的，也是典型的情况
- 混合不同的关系也完全可以，但有时一种关系意味着另一种关系。一般来说，任何（或几乎任何）关系都意味着 non-stereotyped 依赖（在同一方向），因此明确使用它不会提供任何额外的信息或效果。
两个 类 之间的依赖项数量没有限制。但是你必须考虑几个重要的时刻。在首席架构师 Vaughn Vernon 的网站 https://vaughnvernon.co 上，我发现了有关 UML 依赖项用法的有趣评论：
While dependency may have a broad meaning, it is best not to overuse the dependency relationship. In an analysis model class diagram such as a domain model diagram, you may be tempted to convey that all the classes just depend on each other. Interestingly, however, the Rational Unified Process (RUP) specifies that the general class relationship that should be used in the analysis model is association, and not dependency. Therefore, even when you are modeling higher-level concepts it is best not to use the dependency relationship loosely. It is just too nebulous.
Further, unless you use the dependency relationship in a constrained manner your model consumers (yourself or other developers) will simply have too broad an interpretation of its meaning. Generally those filling architect and designer roles in a project are there to give guidance to less experienced developers. Thus the dependency relationship should be used to convey a specific kind of guidance from architects and designers to developers.
So what should a dependency relationship represent? In our UML example above the dependency means that class A uses class B, but that class A does not contain an instance of class B as part of its own state. It also means that if class B’s interface changes it will likely impact class A and require it to change. I suggest that you constrain your use of dependency relationships to non-state related concerns. You would use dependency to indicate that, for example, class A receives an instance of class B as a parameter to at least one of its methods. You would also use dependency to indicate that class A creates an instance of class B local to one of its methods. You would not, however, use dependency to indicate that class A declares an instance variable of class B, as that would indicate a state-related concern. Again, use association to do that.