RUP业务建模及需求分析
Shan Wu
Agenda
RUP介绍
采用RUP进行业务建模
采用RUP进行需求分析
先启、精化阶段介绍
构建阶段需求相关方面介绍
总结
RUP的发展
产生
1997年，Rational的UML(Unified Modeling Language)正式成为业界对象导向可视化塑模的标准，但我们知道它只是塑模符号的标准，代表的也只是开发过程中的产出。至于RUP (Rational Unified Process)则是 Rational 近几年大力推动的 OO开发流程。
动机
软件工程强调成功的软件开发应是技术、开发方法／流程及CASE Tool三个部分的紧密搭配。而Rational公司身为OO CASE Tool的厂商 ，当然寄望透过软件开发流程（RUP）与塑模语言标准（UML）的提出，让对象导向系统的开发更趋成熟，也让它的 CASE Tool更有发挥的空间。
定义
在软件项目进行当中，应有哪些参与人员，而他们谁应在何时、如何地做哪些工作，以共同完成软件系统的开发。
原则
让欲开发的系统中技术最复杂的、风险最高的及最重要的部分，优先解决
RUP-软件迭代开发流程
RUP各阶段介绍
先启
定出最终产品的愿景及业务。定义项目的范围，找出潜在的风险，评估资源的需求，准备项目环境。并找出主要的使用个案（Use Case），得到初始的软件架构（Architecture），制作系统雏形，以验证技术的可行性。
精化
此阶段最重要的目标是考虑大部分重要的需求（使用个案），设计出可靠的软件架构，作为后续阶段进行大量设计及建置工作的基础。所以需要调整前一阶段的软件架构，找出可能的软件组件，考虑应制作、外购或再用所需的软件组件。制作系统雏形，以验证架构的稳定性。并根据上述结果，详细规划项目必要的活动及所需的资源。
构建
根据前一阶段的软件架构，建置完成产品的所有需求，得到产品的测试版本。此阶段强调管理资源，控制项目以得到较佳的成本、时程及品质。
产品化
将软件产品移交给客户（包括包装、转移、训练、支持及维护），直到客户满意为止。
各阶段工作量与进度
业务建模
业务建模目的
目的
了解目标组织（将要在其中部署系统的组织）的结构及机制。
了解目标组织中当前存在的问题并确定改进的可能性。
确保客户、最终用户和开发人员就目标组织达成共识。
导出支持目标组织所需的系统需求。
与其他工作流程的关系
业务模型是需求工作流程的一种重要输入，用来了解对系统的需求
业务实体是分析设计工作流程的一种输入，用来确定设计模型中的实体类。
业务建模流程
业务建模流程－评估业务状态
目的
评估目标组织（要在其中部署最终系统的组织）的状态。
了解如何对项目进行分类以及采用哪种业务建模方式最合适，请参见概念：业务建模的规模）。
决定如何在当前迭代中继续工作，并概括出在随后的迭代中如何处理业务建模工件。
初步理解目标组织的目标（即业务前景），而且涉众和业务建模团队对此能达成一致意见。
业务建模流程－说明当前业务
目的
理解当前目标组织的流程及结构。
在此理解基础上，改进业务建模工作的目标。
业务建模流程－确定业务流程
目的
确定要对哪些业务用例优先进行详细说明。
概述业务用例模型。
确定术语。
业务建模流程－改进业务流程的定义
目的
详细说明业务用例的定义。
确保业务用例正确反映业务的进行方式。
业务建模流程－设计业务流程实现
目的
确定业务中的所有角色、产品、可交付工件和事件。
说明业务角色和业务实体是如何执行业务用例实现的。
业务建模流程－改进角色和职责
目的
详细说明业务实体的定义。
详细说明业务角色的职责。
正式核实业务对象建模的结果是否符合涉众对业务的看法。
业务建模流程－流程自动化研究
目的
研究业务流程中哪些部分可以而且应该自动化。
了解已有系统（通常称为遗留系统）以怎样的方式适合于组织的。
推导出系统需求。
业务建模流程－产出
需求
需求过程概述
目的
与客户和其他涉众在系统的工作内容方面达成并保持一致。
使系统开发人员能够更清楚地了解系统需求。
定义系统边界（限定）。
为计划迭代的技术内容提供基础。
为估算开发系统所需成本和时间提供基础。
定义系统的用户界面，重点是用户的需要和目标。
与其他流程关系
业务建模工作流程提供了业务规则、业务用例模型和业务对象模型，包括了领域模型和系统的组织环境。
分析设计工作流程从需求中获取主要输入（用例模型和词汇表）。在分析设计中可以发现用例模型的缺陷；随后将生成变更请求，并应用到用例模型中。
测试工作流程对系统进行测试，以便验证代码是否与用例模型一致。用例和补充规约为计划和设计测试中使用的需求提供输入。
环境工作流程用于开发和维护在需求管理和用例建模中使用的支持性工件，如用例建模指南和用户界面指南等。
管理工作流程用于制定项目计划，并制定需求管理计划及各次迭代计划（说明请参见迭代计划）。用例模型是迭代计划活动的重要输入。
需求过程主流程
需求过程－分析问题
目的
对有待解决的问题达成一致
确定涉众
定义系统边界
确定对系统强加的约束
需求过程－理解涉众需要
目的
此工作流程明细的目的是从该项目的涉众中获取信息，以便理解涉众的真实需要。
需求过程－定义系统
目的
统一项目团队对系统的认识。
对所收集的涉众请求执行高层分析。
改进前景，纳入要在系统中包含的特性以及相应的属性。
改进用例模型，纳入概要用例。
更为正式地记录模型和文档中的结果。
需求过程－管理系统规模
目的
为所选择的特性和需求（要纳入当前迭代）确定输入的优先级，并对其进行改进。
定义代表某些重要核心功能的用例（或场景）集。
定义应维护哪种需求属性及哪种可追踪性。
需求过程－改进系统定义
目的
详细说明用例的事件流。
详细说明补充规约。
如果需要更多详细信息，则制定软件需求规约,并且建立用户界面的模型并进行原型设计。
需求过程－管理需求变更
目的
评估正式提交的变更请求并确定它们对现有需求集的影响。
建立用例模型。
设置恰当的需求属性和可追踪性。
正式核实需求工作流程的结果是否符合客户对系统的看法。
需求过程－产出
先启与细化阶段 (1)
工作内容
包括初期概念形成、为作出各种项目选择进行的调查研究、需求规格化描述
产出
计划------时间进度表、资源规划、预算
初步调查报告------目标、选择、业务需求
需求规格说明------关于需求的声明型陈述
术语表------一个术语字（概念名等）和相关信息，如约束与规则
原型------创建的一个原型系统，对于问题、高风险因素和需求的辅助理解
用例------对领域过程的文字描述
用例图------展示所有用例和用例间关系
概念模型草案------一个初期粗略的概念模型，用来帮助理解领域中词汇，特别是用例和需求说明的词汇。
先启与细化阶段 (2)
产出制品的顺序
定义计划草案
编制初步调查报告
定义需求
在需求阶段应该得到如下制品：
a. 总体问题陈述
b. 顾客
c. 目标
d. 系统功能（应该做。。。）
e. 系统属性（易用、容错、响应时间、界面形式、平台等）
系统功能和系统属性是最底的需求文档，其他制品有利于正确理解系统（如假设、风险、依赖、术语表、用例、概念模型草案
4． 在术语表中记录术语（持续进行）
5． 实现原型（可选、顺序可变）
6． 定义用例（高层用例和基本用例）
用例是对过程的描述
在计划和细化过程中，应该创建所有高层用例，对最关键的和最重要的用例采用扩展格式（大篇幅的）进行描述
7． 定义概念模型草案（可延迟进行）
8． 定义系统体系结构草案（持续进行、可延迟进行、顺序可变）
先启与细化阶段 (3)
制品间依赖关系
构造阶段（1）
一个开发周期中的步骤
精化计划
同步制品
分析
设计
构造
测试
构造阶段（2）
分析阶段
定义基本用例（如前一个周期未做，则需要做）
精化用例图
精化概念模型
精化术语表（需要持续进行）
定义系统顺序图
定义操作契约
定义状态图（可选）
构造阶段（3）－定义契约
契约目的
契约通过一个系统操作被调用后系统状态的变化情况来描述系统的行为，是描述一个操作应该得到什么结果的文档。契约可以用来描述高层操作，也可以用来描述一个特定的低层操作。
契约格式
名称 EnterItem(upc:number,quantity:integer)
职责 输入（纪录）一个商品项信息，并将它记录到销售项中去
类型 系统
交叉引用 系统功能：R1.1,R1.2
用例 购买商品
注释 要使用快速数据库存取机制
异常 如果UPC无效，那么系统显示出错误信息
输出
前置条件 系统预先知道各项商品的UPC
后置条件
构造阶段（3）－定义契约
建立契约的步骤：
1． 根据系统顺序图识别出每个系统操作
2． 为每个系统操作建立该操作的契约
3． 从职责段开始书写，描述该操作的目的
4． 完成前置条件子段的内容，声明性的描述概念模型中的对象由于执行系统操作引起的状态变化
前置条件中应该书写如下两方面内容：
a. 在操作执行到某点时，那些对软件测试来说非常重要的条件
b. 不需要测试，但系统操作成功执行所需要的一些条件。
5． 最后完成后置条件段，根据以下几个类型来描述：
a. 实例创建和销毁
b. 属性修改
6.关联的形成和销毁
7.定义状态图（可选）
构造阶段（3）－制品间依赖图
构造阶段（3）－分析阶段总结
总结
分析阶段的制品 要回答的问题
用例 领域过程是什么
概念模型 领域中的概念、术语是什么
系统顺序图 系统事件和操作是什么
契约 系统操作作了什么
谢谢!
