820 likes | 1.02k Views
面向对象的分析设计之 RUP 基础及用例建模 出家如初 , 成佛有余 http://www.yeeach.com. 2008 年 12 月. 面向对象的分析设计培训大纲. 目 录. RUP 基础 业务建模 需求分析 编写有效用例. 什么是 Rational Unified Process. Rational Unified Process (简称 RUP )是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程。 RUP 为在开发组织中分配任务和职责提供了一种规范方法。其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。
E N D
面向对象的分析设计之RUP基础及用例建模出家如初,成佛有余http://www.yeeach.com面向对象的分析设计之RUP基础及用例建模出家如初,成佛有余http://www.yeeach.com 2008年12月
目 录 RUP基础 业务建模 需求分析 编写有效用例
什么是Rational Unified Process • Rational Unified Process(简称RUP)是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程。RUP 为在开发组织中分配任务和职责提供了一种规范方法。其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。 • RUP又是一套软件工程方法的框架,各个组织可根据自身的实际情况,以及项目规模对RUP进行裁剪和修改,以制定出合乎需要的软件工程过程。
RUP是最佳软件开发经验的总结 • 迭代式开发(develop software iteratively) • 管理需求(manage requirements) • 使用基于构件的体系结构(use component-based architectures) • 可视化软件建模(visually model software) • 验证软件质量(verify model quality) • 控制软件变更(control changes to software)
RUP的核心思想 • 尽早并且持续的化解重大风险,否则带来很多麻烦风险列表是不断变化的,要持续不断的化解风险。 • 用例驱动,确保满足客户需求用例的主要优势是使团队成员在设计、实现、测试和最终编写用户手册的过程中紧紧的以用户需求为中心。 • 把注意力放在可执行软件上可执行软件使项目进度的最好体现。对项目进度评估时,尽可能以正在编写以及正在运行的代码和通过测试的用例为标准。
RUP的核心思想(续) • 尽早在项目中适应变化RUP要求在初识阶段结束时达成对系统总体外貌的共识,在细化阶段结束时候建立系统构架的基线(设计、实现、测试的构架),在构造阶段结束时候完成“特性冻结”。 • 在早期确定一个可执行的构架(architectural)确立了系统的构架,就识别出了在创建系统时候会遇到的许多最复杂的困难。
RUP的核心特点 • 用例驱动 • 以架构为中心 • 迭代和增量开发
End-user • Functionality • LogicalView • Implementation View • Analysts/Designers • Programmers • Software management • Structure • Use-Case View • Process View • Deployment View • System Engineering • System Integrators • System topology • Delivery, installation • communication • Performance • Scalability • Throughput “4+1”视图
RUP主要的建模元素 • 开发流程定义了“谁”“何时”“如何”做“某事” • 四种主要的建模元素被用来表达RUP • 角色(Workers):谁 • 活动(Activities):如何 • 产物(Artifacts):某事 • 工作流(Workflows):何时
RUP的核心工作流 • 6个核心工程工作流 • 商业建模工作流 • 需求工作流 • 分析和设计工作流 • 实现工作流 • 测试工作流 • 分发工作流 • 3个核心支持工作流 • 项目管理工作流 • 配置和变更控制工作流 • 环境工作流
RUP开发过程阶段-初始阶段 • 主要目标: • 建立项目的软件规模和边界条件,包括运作前景、验收标准以及希望产品中包括和不包括的内容 • 识别系统的关键用例 • 对比一些主要场景,展示至少一个备选构架 • 评估整个项目的总体成本和进度 • 评估潜在的风险(源于各种不可预测因素) • 准备项目的支持环境
RUP开发过程阶段-细化阶段 • 主要目标 • 确保构架、需求和计划足够稳定,充分减少风险,从而能够有预见性地确定完成开发所需的成本和进度 • 处理在构架方面具有重要意义的所有项目风险 • 建立一个已确定基线的构架 • 制作产品质量构件的演进式原型 • 证明已建立基线的构架将在适当时间、以合理的成本支持系统需求 • 建立支持环境(创建开发案例、创建模板和指南、安装工具)
RUP开发过程阶段-构建阶段 • 主要目标 • 完成所有所需功能的分析、开发和测试 • 迭代式、递增式地开发 • 为部署应用程序作好准备
RUP开发过程阶段-移交阶段 • 主要目标 • 确保最终用户可以使用软件 • 培训用户和维护人员 • 根据产品的完整前景和验收标准,对部署基线进行的评估
面向对象开发过程 • 业务建模 • 需求 • 分析 • 设计 • 构建 • 测试 • 部署
目 录 RUP基础 业务建模 需求分析 编写有效用例
业务建模的目的 • 目的: • 了解目标组织(将要在其中部署系统的组织)的结构及机制。 • 了解目标组织中当前存在的问题并确定改进的可能性。 • 确保客户、最终用户和开发人员就目标组织达成共识。 • 导出支持目标组织所需的系统需求。 • 为实现这些目标,业务建模工作流程说明了如何拟定新目标组织的前景,并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。 • 作为对这些模型的补充,还编写了以下文档: • 补充业务规约 • 词汇表
业务建模成果 • 组织结构视图 • 概述业务中的关键角色和职责以及他们的分组情况。 • 业务流程视图 • 包括业务的关键业务流程并对其进行概述,这些流程是业务存在的原因。 • 文化视图 • 表述对组织文化前景的设想,并定义为促进该文化而应用的机制。 • 人力资源状况视图 • 讨论为维持和发展公司职员的技能而应用的机制。 • 领域视图(可选) • 对于处理结构复杂信息的组织,通常需要定义应用于这些信息结构的关键机制和模式。在简单的情况下,组织结构视图中可能已经清楚地表示了领域视图。
目 录 RUP基础 业务建模 需求分析 编写有效用例
什么是需求 • 需求是指系统必须符合的条件或具备的功能 • 功能性:系统无需考虑物理约束而必须能够执行的动作 • 非功能性 • 可用性 • 可靠性 • 性能 • 可支持性 • 设计约束 • 实施需求 • 接口需求 • 物理需求
需求工作流程的目的 • 与客户和其他涉众在系统的工作内容方面达成并保持一致。 • 定义系统的用户界面,重点是用户的需要和目标 • 使系统开发人员能够更清楚地了解系统需求。 • 定义系统边界(限定) • 为计划迭代的技术内容提供基础。 • 为估算开发系统所需成本和时间提供基础。
目 录 RUP基础 业务建模 需求分析 编写有效用例
用例(Use Case)建模 • 用例(Use Case)是一种描述系统需求的方法,使用用例的方法来描述系统需求的过程就是用例建模。 • 用例建模技术,用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型用例的分析,使开发者能够有效地了解用户的需求。 • 整个RUP流程都是"用例驱动"(Use-Case Driven)的,各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件,用例模型奠定了整个系统软件开发的基础。
用例模型(Use case model) • 用例模型描述外部执行者(Actor)所理解的系统功能。即待开发系统的功能需求。 • 用例模型驱动了需求分析之后各阶段的开发工作,还被用于验证和检测所开发的系统, 影响了 UML 的各个模型。 • 用例模型由若干个用例图构成,用例图中主要描述执行者和用例之间的关系。在UML中,构成用例图的主要元素是用例和执行者及其它们之间的联系。
用例模型核心元素 • 参与者(Actor) 参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统,他们代表的是系统的使用者或使用环境。 • 用例(Use Case) 用例用于表示系统所提供的服务,它定义了系统是如何被参与者所使用的,它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。 • 通讯关联(Communication Association) 通讯关联用于表示参与者和用例之间的对应关系,它表示参与者使用了系统中的哪些服务(用例),或者说系统所提供的服务(用例)是被哪些参与者所使用的。
用例分析流程 • 识别系统边界和参与者 • 列出事件 • 识别用例 • 编写用例规约(Use Case Specification) • 识别用例的关系 • 对用例进行优先级排序
参与者Actor • 参与者实例是指在系统外部与系统进行交互的人或物。 • 参与者类定义一个参与者实例集,其中的各个参与者实例在系统中都担任同一角色。
查找参与者Actor • 与系统交互的用户 • 与系统交互的外部系统 • 与系统交互的外部硬件 • 特别注意:有些时候时间触发器也可看作参与者
记录参与者Actor • 名称 应明确表示参与者的角色,确保在以后不会对参与者的名称产生混淆。 • 简要说明 所代表的对象,为何需要,在系统中能获得哪些利益 • 特征 职责、数量、环境、使用系统的频率、领域知识水平、计算机水平、使用的其它应用程序
Actor 参与者的UML表示
学生 • 读者 • 教师 参与者之间的关系 • 泛化关系
用户与参与者之间的关系 • 一个用户可以抽象为多个参与者 张三 教师 & 学生 • 一个参与者可以包含多个用户 教师 张三 & 李四
管理员 参与者与系统边界的关系 • 管理员 • 图书馆管理信息系统
学籍系统 • 学生 • 读者 • 教师 图书馆管理信息系统中的参与者
用例分析流程 • 识别系统边界和参与者 • 列出事件 • 识别用例 • 编写用例规约(Use Case Specification) • 识别用例的关系 • 对用例进行优先级排序
列出事件 • 系统必须响应的外部事件和内部事件 • 外部事件:来自系统外部 • 顾客+下定单 • 内部事件:来自系统内部 • 和时间有关:每天晚上检查账户 • 事件描述语法:“主语+动词(+宾语)” • 主语:Actor的候选,例如:乘客,顾客,店员。 • 动词:表示行为。例如:买,发送,修改… • 宾语:动词所代表行为的目标
列出事件-例子 • 零件销售系统事件表格
用例分析流程 • 识别系统边界和参与者 • 列出事件 • 识别用例 • 编写用例规约(Use Case Specification) • 识别用例的关系 • 对用例进行优先级排序
用例名称 用例Use Case • 用例实例是系统执行的一系列动作,这些动作将生成特定参与者可观测的结果值。 • 一个用例定义一组用例实例。 • 用例的UML表示: