UML第5章.pptVIP

-*- 寻找实体对象-Record Time 正常事件流： 雇员查看当前时间段之前输入的数据； 雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的； 雇员从当前的时间段选择一个日期； 雇员输入以正整数表示的工时； 系统在视图中显示这个数据，并在以后的视图中看到这个数据。 备选事件流1：雇员更改他的时间 雇员查看当前时间之前输入的数据； 雇员选择一个已有的条目； 雇员改变工时和/或支付号码； 在视图中更新这个信息，并在以后的视图中都可以看到。 备选事件流1：雇员提交考勤卡 …… 雇员 已有条目 收费代码 客户 项目 工时 考勤卡 -*- 检查实体对象 雇员 已有条目 收费项目代码 客户 项目 工时 考勤卡 管理员用户 -*- 步骤2：边界对象 边界对象（boundary object）描述系统将如何用参与者交互 通过检查在用例图中的参与者与用例之间的关系，可以识别出边界对象 在分析模型中，每一对参与者/用例都构成了一个边界对象 边界对象可分为两种： 用户界面：允许系统与人交互 系统接口：允许系统与其他系统交互 识别边界对象检查表（checklist-3） -*- 识别边界对象检查表checklist-3 用户界面类是否描述了必须显示的信息以及必须提供的服务？ 用户界面类是否可以推迟所有的接口设计细节？ 系统接口是否描述了与外部系统的交互？ 系统接口是否推迟所有的协议细节？ -*- 寻找边界对象 -*- 步骤3：控制对象 控制对象（control object）为其他对象提供工作流和会话服务 在边界对象访问实体对象的时候，控制对象将一系列复杂的请求封装成通用的工作流，使这种访问变得简单 从边界对象发出的高级的消息将被转换成一系列从控制对象发往实体对象的消息 通常，每一个用例都应该有一种控制对象 识别控制对象检查表（checklist-4） -*- 识别控制对象检查表checklist-4 控制对象是否对用例的作用或者工作流逻辑进行建模？ 控制对象是否将真正的业务逻辑提交给实体对象？ -*- 寻找控制对象 -*- 步骤4：对象生命周期类 对象生命周期类（object lifecycle classes）跟踪实体对象 对象的创建、定位，以及销毁 控制对象或者实体对象需要根据不同的准则来定位一个实体对象 常见的生命周期对象有factory、container等，当然这些名字不适合分析模型 识别生命周期类检查表（checklist-5） -*- 识别生命周期类检查表checklist-5 生命周期类是否定位、创建和销毁实体对象？ 生命周期类是否只专用于一类实体对象？ -*- 2. 描述对象间的交互 描述对象间的交互，从而寻找对象行为 寻找对象行为的准则 确保方法之间的内聚性 采用清楚明确的方法名 完全满足用例要求 保持简单 描述行为的步骤 将以识别的参与对象加到顺序图中 从参与者开始，一步步寻找行为 验证行为序列 -*- 描述行为检查表checklist-6 是否每一个方法都有清楚的目标？ 是否每一个方法的命名都是名词和动词的强组合？ 是否避免采用模棱两可的名字？ 是否从调用对象的角度来清楚地命名每一个方法？ 对其他开发人员来说，这些名字是否是明确的？ 方法的名字是否表明了它的返回类型？ 在每一个类中的方法，它们之间是否存在密切关系？ 是否每一个类中的方法都符合这个类所声明的职责？ 是否每一个类仍然还保持一个具体的目标？ -*- 描述对象交互 正常事件流： 雇员查看当前时间段之前输入的数据； 雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的； 雇员从当前的时间段选择一个日期； 雇员输入以正整数表示的工时； 系统在视图中显示这个数据，并在以后的视图中看到这个数据。 备选事件流2：雇员提交考勤卡 雇员看到当前时间段之前输入的数据； 雇员选择提交考勤卡； 系统要求雇员确认他的选择，并提醒他将不能再编辑这些条目； 考勤卡被提交，再也不能对它进行编辑。 -*- 顺序图Sequence Diagram 描述对象之间的动态交互关系，着重体现对象间消息传递的时间顺序 对象（Object）：对象、对象的生命线、激活的对象和对象的删除 消息（Message）：简单消息、同步消息、异步消息、返回消息 条件（Condition）、注释体和注释连接 -*- 顺序图-推荐的使用场合 顺序图是一种交互图，交互图主要用于 描述对象之间的动态协作关系（协作图）以及协作过程中的行为次序（顺序图） 常常用来描述一个用例的行为，显示该用例中所涉及的对象以及这些对象之间的消息传递情况 -*- 3. 描述类 顺序图描述了用例中对象间的交互关系；而对象间的交互要用到类的方法以及类之间的关系 描述类的准则 完整 保持简单 维持类的一致性 描述类的步骤