需要再次指出的是，并非每一个系统消息都需要定义系统操作契约，我们只 需要为那些可能引起比较复杂的变化的消息定义操作契约。 5.3.1.3交互图构造 交互图可以分成顺序图和协同图，顺序图与协同图在语意上是相等的，画一 个图就可以生成另一个图，因此我们将以顺序图为例来讲解交互图的构造。 1.软件工程的原则与责任分配 在画顺序图时，从一个对象（对象A)发送一个消息给另一个对象（对象B), 其意义在于对象A请求对象B的服务，换言之，将某一个责任分配给了对象B。 那么，为什么将责任分配给对象B而不是其他对象呢？这后面的依据是软件工 程中的一个核心思想：高内聚和低耦合。高内聚和低耦合的提出能够提高软件的 可理解性和可维护性。 类的高内聚有两层意思： ● 一个类的功能应该比较单一，这可以称之为语意内聚： ● 类内部的各个方法调用可以比较多，这称之为关系内聚。 低耦合的意思是各个类之间的关系应该尽可能少。 显然高内聚、低耦合使得某一个类的修改对于别的类的影响会比较小，同时， 系统的重用性也会比较高，因为重用系统的某一个部分不会让其它的类过多地牵 涉其中。 如何进行设计才使得系统能够高内聚、低耦合呢，在分配每一个责任时，我 们都必须考虑这个原则。体现这一原则的一个做法是，每次我们分配责任时，我 们先去看哪个对象拥有完成该责任所需要的信息，谁拥有信息，谁就承担这个责 任。这显然与我们的生活常识相匹配，在办一件事情时，我们得去找拥有信息干 这件事情的人，这样最为直接，而不是绕几个圈子找其他人办事使得事情更为复 杂。 高内聚、低耦合的原则在使用时也并不是金科玉律，在某些时候，与一些类 库、提供公共服务的类如数据存储服务类的耦合是可以接受的，因为它们本身是 比较稳定的。 上述谈及的高内聚、低耦合原则似乎是针对软件设计的。我们前面又多次声 明分析阶段还是侧重于理解需求，因此分析阶段获取的类并非软件类，那么为什 么我们也强调需要运用这个原则呢？因为此处分析出来的对象模型、动态模型是需要再次指出的是，并非每一个系统消息都需要定义系统操作契约，我们只 需要为那些可能引起比较复杂的变化的消息定义操作契约。 5.3.1.3 交互图构造 交互图可以分成顺序图和协同图，顺序图与协同图在语意上是相等的，画一 个图就可以生成另一个图，因此我们将以顺序图为例来讲解交互图的构造。 1. 软件工程的原则与责任分配 在画顺序图时，从一个对象（对象 A）发送一个消息给另一个对象（对象 B）， 其意义在于对象 A 请求对象 B 的服务，换言之，将某一个责任分配给了对象 B。 那么，为什么将责任分配给对象 B 而不是其他对象呢？这后面的依据是软件工 程中的一个核心思想：高内聚和低耦合。高内聚和低耦合的提出能够提高软件的 可理解性和可维护性。 类的高内聚有两层意思：  一个类的功能应该比较单一，这可以称之为语意内聚；  类内部的各个方法调用可以比较多，这称之为关系内聚。 低耦合的意思是各个类之间的关系应该尽可能少。 显然高内聚、低耦合使得某一个类的修改对于别的类的影响会比较小，同时， 系统的重用性也会比较高，因为重用系统的某一个部分不会让其它的类过多地牵 涉其中。 如何进行设计才使得系统能够高内聚、低耦合呢，在分配每一个责任时，我 们都必须考虑这个原则。体现这一原则的一个做法是，每次我们分配责任时，我 们先去看哪个对象拥有完成该责任所需要的信息，谁拥有信息，谁就承担这个责 任。这显然与我们的生活常识相匹配，在办一件事情时，我们得去找拥有信息干 这件事情的人，这样最为直接，而不是绕几个圈子找其他人办事使得事情更为复 杂。 高内聚、低耦合的原则在使用时也并不是金科玉律，在某些时候，与一些类 库、提供公共服务的类如数据存储服务类的耦合是可以接受的，因为它们本身是 比较稳定的。 上述谈及的高内聚、低耦合原则似乎是针对软件设计的。我们前面又多次声 明分析阶段还是侧重于理解需求，因此分析阶段获取的类并非软件类，那么为什 么我们也强调需要运用这个原则呢？因为此处分析出来的对象模型、动态模型是