Chap10-2面向对象.pptxVIP

第十章面向对象（2） 2 第十章内容概要 面向对象方法学概述 UML基础 面向对象的需求提取 面向对象分析 面向对象设计的准则 启发规则 软件重用 面向对象系统设计 面向对象对象设计 ★ 3 Use Case的引出（Why Use Case？） 了解需求→分析典型用例→ 不自觉、随意、潦草→ Jacobson提出Use Case分析法→ OO技术进入第二代； Use Case是什么： 本质上，一个Use Case是用户与计算机之间为达到某个目的的一次典型交互作用； 作为结果，Use Case代表的是系统的一个完整功能。 Use Case 4 Actor： Actor是与系统交互的外部实体； Actor是具有构造型Actor的类，所以谈论Actor时考虑的是其角色，而非角色的实例； Use Case总是由Actor启动的； Actor与Use Case间是多对多的关系。 Use Case ★ 5 Actor有助于获取Use Case 先找出各Actor，再通过他们得到Use Case。 处理Actor与Use Case的关系 一般不必过分关注Actor的细节； 若需对系统分析优化，应了解Actor细节； 对每个用户，提供一张Actor列表，指明其可以扮演的角色，即可以执行的Use Case，有助于协调需求冲突、制定安全策略。 Use Case 6 Use Case的描述： Use Case的名字：唯一标识 参与的Actor(s)：标出其中的主动Actor 入口条件：Use Case启动前需要的条件 事件流：Use Case的动作序列 出口条件：完成后应满足的条件 特殊需求：非功能性需求 Use Case ★ 7 Use Case示例： 要编写“报告紧急情况”Use Case 8 9 场景（Scenario）： 场景是Use Case的真实例子； 场景通过举例说明情况，帮助理解问题域，进而归纳Use Case； 具体执行一次Use Case，得到一个场景； 场景重在可理解性，Use Case重在完整性。 场景示例： 注意：场景是Use Case的实例，因此其名字带有下划线（对象） 10 11 Use Case间的关系：包含、扩展、泛化 包含：两个Use Case，如果其中一个在其事件流中包含了另一个，那么它们间就有包含关系。 扩展：将常规动作放在一个基本Use Case中，将非常规动作放在其扩展Use Case中。 泛化：对一般性Use Case做特殊化、细化。 包含与扩展的区别 ★ 12 Use Case的获取分两步： 要获取Actor，请对用户／客户提问： 谁使用系统的主要功能（Primary Actor）？ 谁需要系统支持他们的日常工作？ 谁来维护、管理系统（Secondary Actor）？ 系统需要控制哪些硬件？ 系统需要与其他哪些系统交互？ 对系统产生的结果感兴趣的是哪些人或事物？ Use Case 13 要获取Use Case，请对Actor提问： Actor要做的是什么、要求系统提供哪些功能？ Actor需要读、产生、删除、修改或存储系统中的信息有哪些类型？ 必须提醒Actor的系统事件有哪些？ Actor必须提醒系统的事件有哪些？怎样把这些事件表示成Use Case中的功能？ Use Case 14 还可以考虑两个问题： 系统需要何种输入输出？它们从哪里来往哪里去？ 现存的系统究竟有什么主要问题，以至于要换掉它？ 若直接总结Use Case有困难，用场景帮忙： 基于场景和Use Case的需求提取：现实场景→想象场景→快速、小型原型→系统描述→ Use Case形式的需求定义。 Use Case 15 确定Actor （确定场景） 确定Use Case 改进Use Case：错误、异常→ 全面完整 确定Use Cases间的关系：减少复杂性 确定参与对象：从Use Case迈向对象 确定非功能性需求 基于Use Case的需求提取活动 16 确定每个Use Case的参与对象； 参与对象对应于问题空间的主要概念→形成术语表； 参与对象的确定产生了最初的分析模型： 对象的描述、属性可由用户评审； 作为整个分析模型与用户／客户衔接的部分，通常不会用完整的分析模型“烦恼”用户。 确定参与对象 17 开发人员或用户为理解Use Case所必须阐明的术语； Use Case中的常用名词（如，事件）； 系统需要跟踪的现实世界实体（如，现场工作人员、资源）； 系统需要跟踪的现实世界过程（如，紧急操作计划）； Use Case本身（如，报告紧急情况）； 数据来源或数据接受器（如，打印机）； 接口产品（如，工作站）； 总要使用的应用域的术语。 确定参与对象的试探法 18 针对前面举例的事故管理系统中的“报告紧急情况”用例，最初