ch03_交互图.ppt

建模工具允许自动映射到类 责任分配？ 每天凌晨4:30，农夫Jones都要起床，到牛栏去挤奶 怎样用OO方法表达这个挤奶过程？ 面向过程的奶牛挤奶 定义函数Milk() --float Milk(struct cow,float amount); 挤奶(使奶离开奶牛)的过程： 面向过程的问题 “挤奶”操作是孤立的 没有对挤奶农夫的需求 Milk()必须告诉那头牛来挤奶 Milk()直接访问结构的内部 Milk()和结构形成耦合 面向对象的挤奶 涉及的实体 农夫、奶牛 涉及的关系 农夫是奶牛的主人 农夫挤奶牛的奶？ 但这样行得通吗？ 牛奶在奶牛那里，不在农夫那里！ Farmer.Milk不得不访问Cow内部的行为 Farmer.Milk要调用Cow的哪些操作？ 另一种责任分配方法 另一种方法－把Milk()放在Cow中 为了挤奶，Farmer调用Cow.milk()操作 所有的“结构”信息（数据）隐藏在Cow中 在OO模型中，Farmer不是直接从Cow中取奶，而是请求Cow自己挤奶 考虑 谁知道奶牛有奶？ 谁知道在请求挤奶时是否有奶可挤？ 如果农夫请求挤３升但奶牛只有２升可以提供。谁来决定应该提供２，１还是０升？ 信息专家——奶牛 基于责任分配原则 系统顺序图 什么是系统顺序图 系统顺序图(SSD)是阐述与所讨论系统相关的输入和输出事件而快速、简单创建的制品（顺序图）。 对于用例的一个特定场景，SSD展示了直接与系统交互的外部参与者对系统（作为黑盒）发起的系统事件以及其（系统事件）顺序。 系统被视为黑盒，该图强调的是从参与者到系统的跨越系统边界的事件。 系统顺序图是操作契约（第11章）和（最重要的）对象设计的输入。 * * 准则：应为每个用例的主成功场景，以及频繁发生或者复杂的替代场景绘制SSD。 动机：为什么绘制SSD 基本上，软件系统要对以下三种事件进行响应 来自于参与者的外部事件（系统事件） 时间事件 错误或异常 系统事件需要系统操作（系统行为）对它进行处理 * * UP制品示例的相互影响 SSD和用例之间的关系 * 图10-3 SSD由用例导出，表示了一个场景 如何为系统事件和操作命名 * 图10-4 在抽象级别上选择事件和操作的名称 系统事件应在意图的抽象级别而非物理的输入设备级别来表达 SSD的哪些信息要放入词汇表 SSD中的元素(操作名称、参数和返回的数据)是简洁的。应在词汇表中详细描述这些元素。 如：在UP词汇表中加入“票据”条目，显示票据样本（可以是数据图片）、详细内容和布局。 准则：对大多数制品来说，一般在词汇表中描述其细节。 * 过程：迭代和进化式SSD 不用为所有场景创建SSD，只需为下次迭代所用的场景绘制SSD。 不需要花太长时间绘制SSD，用几分钟或半个小时即可 当需要了解现有系统的接口和协作时，SSD也是十分有效的。 SSD是用例模型的一部分，将用例场景可视化。 虽然SSDs 非常有用但在UP中没有明确地提及 初始阶段一般不画 SSDs，大部分SSD在细化阶段创建，用来明确必须被设计和处理的系统操作。 * 实践-为以下用例画系统顺序图 用例名称：发送天气信息主要参与者：时间代理 协作参与者：运营商网关系统主成功场景： 1、时间代理自动请求系统发送天气信息 2、系统读取定制了天气预报业务的用户手机号。 3、系统读取当天的天气信息。 4、系统按照指定的格式将包含了用户手机号和天气信息的短信发送到运营商网关系统。 5、运营商网关系统成功返回下发的状态信息。 重复4-5步骤 6、系统显示发送结束。 UML顺序图中的图框 * 图15-12 UML图框的示例 常见的图框操作符见P168表 有条件消息 * 图15-13 有条件消息 互斥的有条件消息 * 图15-15 互斥的有条件消息 对集合的迭代 * 图15-16 使用相对直接的表示法对集合进行遍历 可能的Java代码实现见下页 图15-6 可能的Java代码实现 public class Sale{ private ListSalesLineItem lineItems= new ArrayListSalesLineItem(); public Money getTotal(){ Money total=new Money(); Money subtotal=null; for(SalesLineItem lineItem:lineItems){ subtotal=lineItem.getSubtotal(); total.add(subtotal); } return total; } //…… } * 隐含地表示对集合的迭代 * 图15-17 隐含地表示对集