1、面向对象技术 Object-Oriented Techniques,第 3章用例分析技术 Use-Case Analysis,-3-,Review: Use-Case Modeling,基于用例的需求获取过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-4-,学习线路图,References,Arri02CT Arrington, Enterprise Java with UML（马波，李雄锋译，Enterprise
2、 Java with UML中文版，机械工业出版社，2003年） Larm01, Craig Larman, Applying UML and Patterns, 2e（姚淑珍、李虎等译，UML和模式应用-面向对象分析与设计导论，机械工业出版社，2002年） DEV475, IBM Rational, Mastering Object-Oriented Analysis and Design with UML, 2003 Kruc00, Philippe Kruchten, The Rational Unified Process: An Introduction (Second Editio
3、n)（周伯生等译，Rational统一过程引论，机械工业出版社，2002.5）,-6-,如何开始？,从 用 例 开 始！,-7-,面向对象分析过程,面向对象的分析方法：用例分析技术 用例分析技术是基于用例的，在每一次迭代中针对每一个用例： 1. 寻找候选对象对象清单 2. 描述对象间的交互交互图（顺序图） 3. 描述类类图（VOPC）,-8-,1. 寻找候选对象,寻找用于解决某个用例的一组对象 寻找对象的准则 限制每一个分析类（analysis class）的职责 对类和方法采用一致的命名 保持分析类的简单 寻找对象的步骤（MVC构架） 实体（Entity） 边界（Boundary） 控制（C
4、ontrol） 生命周期（Lifecycle）,-9-,准则1：限制职责,SRP（The Single Responsibility Principle）：就一个类而言，应该仅有一个引起它变化的原因 是否每一个类都有一个清楚的目标？ 是否可以用一个文本段落清楚地描述这个目标？ 是否每一个方法都符合这个类的职责？,-10-,准则2：采用清楚一致的命名,类的名字和职责必须是清楚的和明确的 类和方法的清晰的命名可以让其他开发人员和相关人员理解并验证分析模型，并可以捕获其中的误解和错误，避免其发展到足以威胁项目的成功的地步 对象命名检查表（checklist-1）,-11-,对象命名检查表checkl
5、ist-1,对于每一个类的名字是否是一个名词？ 对那些对系统不怎么熟悉的人来说，每一个类及其方法的名字是否都是明确的？ 你是否为了得到一个能将意思描述清楚地名词而采用诸如“manager”之类的无意义的补白？ 每一个方法的名字是否是一个动词或动词与名词的组合短语？,-12-,准则3：保持简单,分析只是对高层次解决方案的第一次尝试 不要试图去确定对象之间的关系 不要命名角色或者创建详细的继承层次 没必要花太多的时间来使你的第一稿草案看起来很完美： 发现一些对象，评审一下这些结果，然后在寻找对象行为的时候再来确定它的细节,-13-,步骤1：实体对象,实体对象（entity object）对系统的业
6、务数据和业务逻辑进行封装 解决问题所需要的全部数据和行为，然后将这些数据按相关性分组 识别出重要的名词，并将它们作为实体对象，之后确定每一个实体对象包含的数据和行为 识别实体对象检查表（checklist-2）,-14-,识别实体对象检查表checklist-2,实体对象是否是某个问题中的重要名词？ 实体对象是否包含用来解决系统问题的重要的信息？ 实体对象是否包含可以解决系统问题的计算或验证逻辑？ 那些了解这个系统目标的专家是否会理解这些实体对象？,-15-,寻找实体对象-Record Time,正常事件流： 雇员查看当前时间段之前输入的数据； 雇员从已有的支付号码中选择一个，这些收费代码是按
7、客户和项目组织的； 雇员从当前的时间段选择一个日期； 雇员输入以正整数表示的工时； 系统在视图中显示这个数据，并在以后的视图中看到这个数据。 备选事件流1：雇员更改他的时间 雇员查看当前时间之前输入的数据； 雇员选择一个已有的条目； 雇员改变工时和/或支付号码； 在视图中更新这个信息，并在以后的视图中都可以看到。 备选事件流1：雇员提交考勤卡 ,雇员 已有条目 收费代码 客户 项目 工时 考勤卡,-16-,检查实体对象,雇员 已有条目 收费项目代码 客户 项目 工时 考勤卡 管理员用户,-17-,步骤2：边界对象,边界对象（boundary object）描述系统将如何用参与者交互 通过检查在
8、用例图中的参与者与用例之间的关系，可以识别出边界对象 在分析模型中，每一对参与者/用例都构成了一个边界对象 边界对象可分为两种： 用户界面：允许系统与人交互 系统接口：允许系统与其他系统交互 识别边界对象检查表（checklist-3）,-18-,识别边界对象检查表checklist-3,用户界面类是否描述了必须显示的信息以及必须提供的服务？ 用户界面类是否可以推迟所有的接口设计细节？ 系统接口是否描述了与外部系统的交互？ 系统接口是否推迟所有的协议细节？,-19-,寻找边界对象,-20-,步骤3：控制对象,控制对象（control object）为其他对象提供工作流和会话服务 在边界对象访问
9、实体对象的时候，控制对象将一系列复杂的请求封装成通用的工作流，使这种访问变得简单 从边界对象发出的高级的消息将被转换成一系列从控制对象发往实体对象的消息 通常，每一个用例都应该有一种控制对象 识别控制对象检查表（checklist-4）,-21-,识别控制对象检查表checklist-4,控制对象是否对用例的作用或者工作流逻辑进行建模？ 控制对象是否将真正的业务逻辑提交给实体对象？,-22-,寻找控制对象,-23-,步骤4：对象生命周期类,对象生命周期类（object lifecycle classes）跟踪实体对象 对象的创建、定位，以及销毁 控制对象或者实体对象需要根据不同的准则来定位一个
10、实体对象 常见的生命周期对象有factory、container等，当然这些名字不适合分析模型 识别生命周期类检查表（checklist-5）,-24-,识别生命周期类检查表checklist-5,生命周期类是否定位、创建和销毁实体对象？ 生命周期类是否只专用于一类实体对象？,-25-,2. 描述对象间的交互,描述对象间的交互，从而寻找对象行为 寻找对象行为的准则 确保方法之间的内聚性 采用清楚明确的方法名 完全满足用例要求 保持简单 描述行为的步骤 将以识别的参与对象加到顺序图中 从参与者开始，一步步寻找行为 验证行为序列,-26-,描述行为检查表checklist-6,是否每一个方法都有清
11、楚的目标？ 是否每一个方法的命名都是名词和动词的强组合？ 是否避免采用模棱两可的名字？ 是否从调用对象的角度来清楚地命名每一个方法？ 对其他开发人员来说，这些名字是否是明确的？ 方法的名字是否表明了它的返回类型？ 在每一个类中的方法，它们之间是否存在密切关系？ 是否每一个类中的方法都符合这个类所声明的职责？ 是否每一个类仍然还保持一个具体的目标？,-27-,描述对象交互,正常事件流： 雇员查看当前时间段之前输入的数据； 雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的； 雇员从当前的时间段选择一个日期； 雇员输入以正整数表示的工时； 系统在视图中显示这个数据，并在以后的视图中看
12、到这个数据。备选事件流2：雇员提交考勤卡 雇员看到当前时间段之前输入的数据； 雇员选择提交考勤卡； 系统要求雇员确认他的选择，并提醒他将不能再编辑这些条目； 考勤卡被提交，再也不能对它进行编辑。,-28-,顺序图Sequence Diagram,描述对象之间的动态交互关系，着重体现对象间消息传递的时间顺序 对象（Object）：对象、对象的生命线、激活的对象和对象的删除 消息（Message）：简单消息、同步消息、异步消息、返回消息 条件（Condition）、注释体和注释连接,-29-,顺序图-推荐的使用场合,顺序图是一种交互图，交互图主要用于 描述对象之间的动态协作关系（协作图）以及协作过
13、程中的行为次序（顺序图） 常常用来描述一个用例的行为，显示该用例中所涉及的对象以及这些对象之间的消息传递情况,-30-,3. 描述类,顺序图描述了用例中对象间的交互关系；而对象间的交互要用到类的方法以及类之间的关系 描述类的准则 完整 保持简单 维持类的一致性 描述类的步骤 将对象的行为合并到类中 重构类，使其符合规则 发现类之间的关系 完成该用例“参与类类图”（VOPC, View of Participating Classes Class Diagram）,-31-,Record Time用例中类的关系,-32-,总结：用例分析过程,评估用例，确定迭代周期 在每一次迭代中的每一个用例： 1. 寻找候选对象 获得各类对象清单：实体类、控制类、边界类 2. 描述对象间的交互-顺序图 针对每个事件流，通过顺序图演示用例的实现过程 3. 描述类-类图 完成类图，描绘类图中的关系 重构类图，构造整个系统的分析模型,
