Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
More from chuan liang
面向对象的分析设计之RUP基础及用例建模
- 1. 面向对象的分析设计之 RUP基础及用例建模 出家如初,成佛有余 http://www.yeeach.com http://www yeeach com 2008年12月
- 2. 面向对象的分析设计培训大纲 2
- 3. 目 录 RUP基础 业务建模 需求分析 编写有效用例 有效 3
- 4. 什么是Rational Unified Process Rational Unified Process（简称RUP）是一个面向对象 软件工程的通用业务流程。它描述了一系列相关的软件工 程流程。RUP 为在开发组织中分配任务和职责提供了一种 规范方法。其目标是确保在可预计的时间安排和预算内开 发出满足最终用户需求的高品质的软件。 RUP又是一套软件工程方法的框架，各个组织可根据自身 的实际情况，以及项目规模对RUP进行裁剪和修改，以制 定出合乎需要的软件工程过程。 4
- 5. RUP是最佳软件开发经验的总结 迭代式开发（develop software iteratively） 管理需求（manage requirements） 使用基于构件的体系结构（use component-based architectures） 可视化软件建模（visually model software） 验证软件质量（verify model quality） 控制软件变更（control changes to software） 5
- 6. RUP的核心思想 尽早并且持续的化解重大风险，否则带来很多麻烦 风险列表是不断变化的，要持续不断的化解风险。 用例驱动，确保满足客户需求 用例的主要优势是使团队成员在设计、实现、测试和最终 编写用户手册的过程中紧紧的以用户需求为中心。 把注意力放在可执行软件上 可执行软件使项目进度的最好体现。对项目进度评估时， 尽可能以正在编写以及正在运行的代码和通过测试的用例 为标准。 6
- 7. RUP的核心思想(续) 尽早在项目中适应变化 RUP要求在初识阶段结束时达成对系统总体外貌的共识， 在细化阶段结束时候建立系统构架的基线（设计、实现、 测试的构架），在构造阶段结束时候完成“特性冻结”。 在早期确定一个可执行的构架（architectural） 确立了系统的构架，就识别出了在创建系统时候会遇到的 许多最复杂的困难。 7
- 8. RUP的核心特点 用例驱动 以架构为中心 迭代和增量开发 8
- 9. “4+1”视图 4+1 视图 •Logical •Implementation View View •Analysts/ •End-user End user •Programmers g Designers D i •Structure •Functionality •Software management •Use-Case View •Process •Deployment View View •System Integrators •System Engineering •Performance •System topology •Scalability •Delivery, installation •Throughput •communication
- 10. RUP基本架构 10
- 11. RUP主要的建模元素 开发流程定义了“谁”“何时”“如何”做“某事” 四种主要的建模元素被用来表达RUP 角色（Workers）：谁 活动（Activities）：如何 产物（Artifacts）：某事 工作流（Workflows）：何时 11
- 12. RUP的核心概念 12
- 13. RUP的核心工作流 6个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流 3个核心支持工作流 项目管理工作流 配置和变更控制工作流 环境工作流 13
- 14. RUP开发过程阶段-初始阶段 主要目标: 建立项目的软件规模和边界条件，包括运作前景、验 收标准以及希望产品中包括和不包括的内容 识别系统的关键用例 对比一些主要场景，展示至少一个备选构架 评估整个项目的总体成本和进度 评估潜在的风险（源于各种不可预测因素） 准备项目的支持环境
- 15. RUP开发过程阶段-细化阶段 主要目标 确保构架、需求和计划足够稳定，充分减少风险，从 而能够有预见性地确定完成开发所需的成本和进度 处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架 制作产品质量构件的演进式原型 证明已建立基线的构架将在适当时间、以合理的成本 支持系统需求 建立支持环境（创建开发案例、创建模板和指南、安 装工具）
- 16. RUP开发过程阶段-构建阶段 主要目标 完成所有所需功能的分析、开发和测试 迭代式、递增式地开发 为部署应用程序作好准备
- 17. RUP开发过程阶段-移交阶段 主要目标 确保最终用户可以使用软件 培训用户和维护人员 根据产品的完整前景和验收标准，对部署基线进行的评估
- 19. 目 录 RUP基础 业务建模 需求分析 编写有效用例 有效 19
- 20. 业务建模的目的 目的： 了解目标组织（将要在其中部署系统的组织）的结构及机制。 了解目标组织中当前存在的问题并确定改进的可能性。 确保客户、最终用户和开发人员就目标组织达成共识。 导出支持目标组织所需的系统需求。 为实现这些目标，业务建模工作流程说明了如何拟定新目 标组织的前景，并基于该前景来确定该组织在业务用例模 型和业务对象模型中的流程、角色以及职责。 作为对这些模型的补充，还编写了以下文档： 补充业务规约 词汇表
- 21. 业务建模-工作流程明细 21
- 22. 业务建模-活动概述 22
- 23. 业务建模-工件 23
- 24. 从业务模型到系统 24
- 25. 业务模型和系统Actor 25
- 26. 业务建模成果 组织结构视图 概述业务中的关键角色和职责以及他们的分组情况。 业务流程视图 包括业务的关键业务流程并对其进行概述，这些流程是业务 存在的原因。 文化视图 表述对组织文化前景的设想，并定义为促进该文化而应用的 机制。 人力资源状况视图 讨论为维持和发展公司职员的技能而应用的机制。 领域视图（可选） 对于处理结构复杂信息的组织，通常需要定义应用于这些信 息结构的关键机制和模式。在简单的情况下，组织结构视图 中可能已经清楚地表示了领域视图。
- 27. 目 录 RUP基础 业务建模 需求分析 编写有效用例 有效 27
- 28. 什么是需求 需求是指系统必须符合的条件或具备的功能 功能性：系统无需考虑物理约束而必须能够执行的动 作 非功能性 • 可用性 • 可靠性 • 性能 • 可支持性 • 设计约束 • 实施需求 • 接口需求 • 物理需求
- 30. 需求-工作流程 30
- 31. 需求-活动 31
- 32. 需求-工件 32
- 33. 目 录 RUP基础 业务建模 需求分析 编写有效用例 有效 33
- 34. 用例(Use Case)建模 用例(Use Case)是一种描述系统需求的方法，使用用例的 方法来描述系统需求的过程就是用例建模。 用例建模技术，用于描述系统的功能需求。在宏观上给出 模型的总体轮廓。通过对典型用例的分析，使开发者能够 有效地了解用户的需求。 整个RUP流程都是quot;用例驱动quot;(Use-Case Driven)的，各种 类型的开发活动包括项目管理、分析设计、测试、实现等 都是以系统用例为主要输入工件，用例模型奠定了整个系 统软件开发的基础。 34
- 35. 用例模型（Use case model） 用例模型描述外部执行者(Actor)所理解的系统功能。即 待开发系统的功能需求。 用例模型驱动了需求分析之后各阶段的开发工作,还被用 于验证和检测所开发的系统, 影响了 UML 的各个模型。 用例模型由若干个用例图构成，用例图中主要描述执行者 和用例之间的关系。在UML中,构成用例图的主要元素是用 例和执行者及其它们之间的联系。 35
- 38. 参与者Actor 参与者实例是指在系统外部与系统进行交互的人或物。 参与者类定义一个参与者实例集，其中的各个参与者实例 在系统中都担任同一角色。
- 39. 查找参与者Actor 与系统交互的用户 与系统交互的外部系统 与系统交互的外部硬件 特别注意：有些时候时间触发器也可看作参与者
- 40. 记录参与者Actor 名称 应明确表示参与者的角色，确保在以后不会对参与者的名 称产生混淆。 简要说明 所代表的对象,为何需要,在系统中能获得哪些利益 特征 职责、数量、环境、使用系统的频率、领域知识水平、计 算机水平、使用的其它应用程序
- 41. 参与者的UML表示 •Actor
- 42. 参与者之间的关系 泛化关系 •读者 •学生 •教师
- 43. 用户与参与者之间的关系 一个用户可以抽象为多个参与者 张三 教师 & 学生 一个参与者可以包含多个用户 教师 张三 & 李四
- 44. 参与者与系统边界的关系 •管理员 •管理员 •图书馆管理信息系统 图书馆管 信息系统
- 45. 图书馆管理信息系统中的参与者 •读者 •学籍系统 •学生 学 •教师
- 47. 列出事件 系统必须响应的外部事件和内部事件 外部事件：来自系统外部 • 顾客＋下定单 内部事件：来自系统内部 • 和时间有关：每天晚上检查账户 事件描述语法：“主语＋动词(＋宾语)” 主语：Actor的候选，例如：乘客，顾客，店员。 动词：表示行为。例如：买，发送，修改… 宾语：动词所代表行为的目标 47
- 48. 列出事件-例子 •零件销售系统事件表格 48
- 50. 用例Use Case 用例实例是系统执行的一系列动作，这些动作将生成特定 参与者可观测的结果值。 一个用例定义一组用例实例。 用例的UML表示： •用例名称
- 53. 识别用例-用例的粒度 常见错误： 把交互的某个步骤当作用例 把系统活动当作用例 粒度过细，陷入功能分解 四轮马车的错误（增加、删除、修改、查询） 53
- 55. 编写用例规约 用例的路径 编写用例规约--用例的路径 55
- 56. 编写用例规约-用例模板 用例编号 用例名 用例描述 参与者 前置条件 后置条件 基本路径（事件流） 1…..×××× 2……×××× 3…..×××× 扩展点 2a.×××× 2a1….××××× 补充说明
- 57. 编写用例规约--用例模板要素 Mandatory（必须） Element（要素） Phase（阶段） √ Author and date of the first version Gathering（需求收集阶段） Author and date of the latest revision Throughout（全过程） √ Actors Gathering √ Use case description Gathering 用例说明 √ Preconditions Specification（需求规格阶段） 前置条件 √ Postconditions Specification 后置条件 Priority P i it Gathering G th i √ Normal course of events Specification 主流程 Alternate courses Specification 分支流程 √ Exceptions and Issues Specification 异常 Includes Gathering Notes Throughout
- 58. 编写用例规约-前置、后置条件 前置条件：开始用例前所必需的系统及其环境的状态 后置条件：用例成功结束后系统应该具备的状态 编写前置、后置条件的意义： 某些用例依赖于其他用例 • 一个用例在离开系统时，可能是另一个用例的前置条件（例如：“ 登录”和“管理订单”） 有助于识别漏掉的用例 • 如果一个用例的前置条件不能由执行其他用例满足，可能意味着丢 失了用例（ 例如：“管理订单”却没有“登录” ）
- 59. 编写用例规约-事件流 说明用例如何开始和结束。 说明在参与者和用例之间交换的是什么数据。 说明事件流，而不只是功能，每个动作都应从“当参与 者... 时”开始。 者 只说明属于该用例的事件，而不是发生在其他用例中或 系统外部的事件。 避免不明确的术语，如“例如”、“等等”和“信息” 详细说明事件流，即回答所有包含“什么”的问题。 说明系统要做什么，而不是系统怎样做。
- 60. 编写用例规约-事件流 使用结构化的叙述格式 每个use case只描述没有大的分支的行为的单个线索。 在事件流里要对事件流进行结构化说明 基本事件流 描述每个情节的行为者:目标语句对的顺序 假设之前的每一步都是成功的 备选事件流 将失败情节作为延伸部分 对于失败中的失败，用更长的前缀标记更深一层的失败情 节
- 61. 编写用例规约-识别扩展点的思路 参与者的选择 另一条成功路线 “用支票结账” 参与者错误的操作 “没有提供Email地址” 每次系统验证时，都暗示着扩展 “系统验证账户名和密码” 系统内部出现错误 61
- 62. Actor与Use Case的交互 每当找到一个用例，就应确定哪些参与者将与之进行交互 定义一个通信关联关系，其导航方向应该与参与者和用例 之间的信号传输方向相同。
- 63. Actor与Use Case交互图 •Actor •用例名称
- 66. 识别用例的关系-用例的包含关系 包含关系是指基础用例(Base)会用到被包含用例 (Inclusion)，就是将被包含用例的事件流插入到基础 用例的事件流中 包含关系用于： 从基本用例中分解出来这种的行为：它对于了解基本用例的 主要目的不是必需的，只有它的结果才比较重要。 分解出两个或者多个用例所共有的行为。
- 67. 识别用例的关系-用例的包含关系 67
- 68. 识别用例的关系-用例的扩展关系 扩展（extend）关系是指将扩展用例(Extension)的事件流在一 定 的条件下按照相应的扩展点插入到基础用例(Base)中。基础用例 (Base)中定义有一至多个已命名的扩展点，基本用例自身应该是完 整的，即基本用例应该是可理解并且有意义的，而不必引用任何扩 展用例。但是基本用例并不独立于扩展用例，因为如果无法遵循扩 展用例，就不能执行基本用例。 扩展是有条件的，它是否执行取决于在执行基本用例时所发生的事 件。基本用例并不控件执行扩展的条件，这些条件在扩展关系中进 行说明。扩展用例可以访问和修改基本用例的属性。但是基本用例 看到到扩展用例，也无法访问它们的属性。
- 69. 识别用例的关系-用例的扩展关系 扩展的目的在于： 表明用例的某一部分是可选的（或者可能可选）的系统行为。这样，你 就可以将模型中的可选行为和必选行为分开。 表明只有在特定 条件下（有时候是异常情况下）才执行的分支流，如触 发警报 表明可能有一组行为段，其中的一个或者多个段可以在基本用例中的扩 展点处插入。所插入的 行为段（以及插入的顺序）将取决于在执行基本 用例时与主角进行的交互。 69
- 70. 识别用例的关系-用例的泛化关系 识别用例的关系 用例的泛化关系 当多个用例共同拥有一种类似的结构和行为的时候， 我们可以将它们的共性抽象成为父用例，其他的用例 作为泛化关系中的子用例。在用例的泛化关系中，子 用例是父用例的一种特殊形式，子用例继承了父用例 所有的结构、行为和关系。 父用例可以特化形成一个或者多个子用例，这些子用 例代表了父用例比较特殊的形式。尽管在大多数情况 下父用例是抽象的，但是无论是父用例还是子用例这 两者都 不要求一定抽象。子用例继承父用例的所有结 构、行为和关系。同一父用例的子用例都是该父用例 的特例。
- 71. 识别用例的关系 用例的泛化关系 识别用例的关系-用例的泛化关系 •支付 •现金支付 现金支付 •信用卡支付
- 73. 对用例进行优先级排序-排序原则 对用例进行优先级排序 排序原则 以下情况的用例优先级别最高 对类图有重要影响 包含丰富的业务过程信息和线索 有开发风险、时间紧迫或功能复杂 涉及到重要核心技术或新技术 能直接产生经济效益或降低成本 代表本系统的核心流程 73
- 74. 用例 vs. 场景（ Scenario） 场景是用例的一个实例，表示用例的一个流程，可能是主 流程，也可能是分支流程
- 75. 大量用例时的组织 按参与者分包 按主题分包 按开发团队分包 按发布情况分包 可以先按主题分包，主题内再按开发团队和发布情况分包 75
- 77. 划分用例包标准 用例包中的对象都要是直接包含在包中的对象。 划分到一个包的情况： 与同一个参与者交互的用例要划分在一个包内。 相互之间有包含和扩展关系的包。 都为可选，且由系统一起提供（或不提供）的包。 顶级包包括所有的顶级用例包、所有顶级参与者，以及所 有的顶级用例。
- 79. 用例建模之需求分析过程
- 80. 用例建模之需求的组成 Analysis Model 分析模型 Activity Diagram Use Case Model Sequence Diagram Class Diagram State Diagram 活动图 用例模型 序列图 类图 状态图 Functional User Requirement Use Case Specification Storyboard Requirement 用户需求 用例规格 用例场景 功能性需求 Nonfunctional Software Requirement Requirement Specification 非功能性需求 软件规格说明书 Interface Requirement Specification 接口规格说明书
- 81. 参考文档 编写有效用例（ Writing Effective Use Cases） UML和模式应用（Applying UML and Pattern） Rational官方文档（Rational RUP中文教程） 81
- 82. 谢 谢！ 82