UML面向对象建模chapter4交互图.pptVIP

实体类源于领域概念模型。有时也需要认真研读用例描述，从中发掘具有持久意义的信息项。 如果执行者的属性需要持久保存，也可以建立相应于执行者的实体类。 假设一个实体类A仅仅被系统中的另一个类B引用，并且系统勿需关心A的行为特征，那么，为了简化设计模型，应将A中信息项直接作为B的属性。 如果A被系统中的多个类引用，或者A具有不容忽略的行为特征，那么应将A作为独立的实体类。 一个用例通常对应一个控制类。 如果不同用例的任务有较多类似之处，也可以考虑在多个用例的实现方案中共享同一控制类，此种情况应审慎对待，不同用例所需要的控制、协调行为往往会有差异。 对于那些事件流非常简单的用例，可以不设独立的控制类，直接在边界类中设置控制、协调功能，边界类在实体类的帮助下完成用例要求的功能及行为。 构造交互图 在标识边界类、实体类和控制类之后，接下来的任务是，将分析模型中的用例描述转化成UML交互图，以交互图作为用例的精确实现方案。 用例描述中已包含事件流说明。 事件流中的事件应直接对应于交互图中的消息，而事件间的先后关系体现为交互图中的时序，对消息的响应则构成消息接收者的职责。 这种职责在后续的设计活动中将被确立为类的方法。 对于比较复杂的用例，仅仅依靠控制类、边界类和实体类会使单个控制类过于庞大、复杂，它既承担控制、协调的任务，又承担复杂的计算任务。 在设计复杂用例的实施方案时，应考虑为控制类设置一些独立的辅助类，让控制类将一些任务委托给辅助类完成。 如，在 “家庭保安系统”类图中，“系统配置管理器”和“日志管理器”就是这种意义上的辅助类。 UML顺序图的横向排列次序 用例的主动执行者 用户界面的边界类 控制类 实体类和辅助类 外部接口和环境隔离层的边界类 目标软件系统的边界之外的被动执行者 按此布局，在顺序图中不应该出现穿越控制类生命线的消息，即，主动执行者向界面类发出命令，界面类将命令进行适当转换后传送至控制类，控制类通过消息请求辅助类、实体类的帮助，协调、控制它们共同完成来自主动执行者的命令。 控制类或辅助类可以向右侧的边界类发送消息，将信息或外部处理请求由边界类传向外部系统（被动执行者）。 在用例描述中，许多用例除主事件流外，往往还包含备选事件流，以说明在某些特殊或者异常情况下的事件和响应动作序列。为易于理解，在设计模型中应该用分离的UML交互图分别表示事件流和每个备选事件流。 按照上述布局规则绘制的典型的顺序图如图所示 典型布局规则下的顺序图 例 家庭保安系统“传感器监测”用例的顺序图 例 家庭保安系统“命令处理”用例的顺序图 精化类图 在UML交互图中，对每个类的对象都规定了它必须响应的消息以及类的对象之间的消息传递通道。前者对应于类的操作，后者则对应于类之间的连接关系。因此，可以利用交互图精化分析模型中的类图，将交互图中出现的新类添加到原有类图中，并且对相关的类进行精化，定义其属性和操作。 原则上，每个类都应该有一个操作来响应交互图中指向其对象的那条消息。但是，这并不意味着消息与操作一定会一一对应，因为类的一个操作可能具有响应多条消息的能力。同理，两个类之间的一条连接关系也可以为多条消息提供传递通道。为了简化设计模型，也为了提高重用程度，设计人员应该尽量使用已有的操作来响应新消息，并尽量使用已存在的连接路径作为消息传递的通道。如果两个类之间存在明确、自然的聚合或组合关系，则可以在类图中直接用相应的UML图元符号表示类间的聚合和组成关系，这两个关系均可提供消息传递通道。 接下来讨论如何根据交互图确立类的属性。类的操作完成消息响应责任的能力，来源于两方面的知识，一是类本身具有的信息，即类的属性，二是类能够找到的其他类，通过其他类协助其完成消息响应。在综合考虑这两个因素之后，类的操作应该明确哪些子任务可通过消息传递路径委托给其他类完成，哪些子任务必须由自身完成。根据后一种子任务的需要，结合领域和业务知识即可推导出类应具有的属性。 在类图的基础上，得出“家庭保安系统”的类图如下图所示。为简洁见，仅标出控制类“监测器”和“用户命令处理器”的方法，以及实体类“异常事件”的属性。 “家庭保安系统”的精化类图 Eg：用户登录活动的顺序图。 二、通信图 描述系统对象（或活动者）如何共同协作实现用例； 通信图—组成 链： 连接器，是用来表示对象之间的语义连接，一般而言，链是关联的一个实例（包括《association》、《self》、《global》、《local》等）。不过在UML 2中已经开始弱化它们的使用，因此除非必要，无需过多地考虑它们。 消息编号： 消息的编号有两种，一种是无层次编号，它简单直观；另一种是嵌套的编号，它更易于表示消息的包含关系 迭代标记： 用*号表示，表示