问UML类图-太多的关联？

EN

关联的数量没有具体的限制，但是如果所有的东西都和其他的东西联系在一起，那么设计可能有问题，而且实现起来也会很糟糕。

随着设计的发展，大多数链接应该是单向的，并且大多数应该是更具体的，而不仅仅是关联。常见的链接类型是a“是”B(继承)，a“有”B(包含)和A“使用”B(简单关联)。

一旦大多数链接都是单向的，就可以将图表重新绘制为一个很好的层次结构，没有循环依赖关系或箭头“走错了方向”。

您应该将所需的所有类和关联放入类图中，而不管需要多少类和关联。但不是更多。

所以让我来挑战一下你的图表：

1. 您真的会有一个具有属性和方法的类PerformanceFile吗？或者该文件只是一个Calculator在调用它的方法时创建的伪文件(例如，savePerformanceFile(filename) )？
2. 入口和出口条件有什么不同？这些条件(e.g.temperature，湿度，压力，.)是一样的吗？但是有不同的来源(例如输入和输出)？
3. Calculator与它所使用的计算条件之间是否有结构关系？还是仅仅访问由AirConditionner度量的条件？

假设1)No，2)不同，3)不，1单元的计算器，我会看到一个关系更少的图表：

我

为了澄清类的责任，我详细介绍了一些属性和方法。但是如果你只保留这些类，你就会得到一个简单得多的图表。

注意事项:如果计算器测量条件，条件将连接到计算器，而不是空调单元。在这种情况下，如果计算器可以控制多个airco单元，则有必要将这些条件与计算器和单元连接起来：