目录
第一节 RUP的特点
第二节 核心工作流
第一节 RUP的特点
以用况驱动的、以体系结构为中心的迭代、增量式开发。
- 用况驱动
（1） 用况是能够向用户提供有价值结果的系统中的一种功能
（2） 用况获取的是功能需求
在系统的生存周期中，以用况作为基础，驱动系统有关人员对所要建立系统的功能需求进行交流，驱动系统分析、设计、实现和测试等活动，包括制定计划、分配任务、监控执行和进行测试等，并将它们有机地组织在一起，使各个阶段中都可以回溯到用户的实际需求。 - 以体系结构为中心
系统体系结构：是对系统语义的概括描述，对所有项目有关人员都是可以理解的。 - 迭代与增量
（1） 迭代是重复的部分
（2） 增量是增加的部分
一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。
二维开发模型：
RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle）、阶段（Phase）、迭代（Iteration）和里程碑(Milestone）；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动（Activity）、产物（Artifact）、工作者（Worker）和工作流（Workflow）。如图1：
RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。每个阶段结束于一个主要的里程碑（Major Milestones）；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。
（1） 初始阶段
初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。初始阶段结束时是第一个重要的里程碑：生命周期目标（Lifecycle Objective）里程碑。生命周期目标里程碑评价项目基本的生存能力。
（2） 细化阶段
细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。细化阶段结束时第二个重要的里程碑：生命周期结构（Lifecycle Architecture）里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。
（3）构造阶段
在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。构建阶段结束时是第三个重要的里程碑：初始功能（Initial Operational）里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。
（4）交付阶段
交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。在交付阶段的终点是第四个里程碑：产品发布（Product Release）里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。
第二节 核心工作流
RUP中有9个核心工作流，分为6个核心过程工作流（Core Process Workflows）和3个核心支持工作流（Core Supporting Workflows）。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。
（1）商业建模
商业建模（Business Modeling）工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用况模型和商业对象模型中定义组织的过程，角色和责任。
（2）需求
需求（Requirement）工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。
（3）分析和设计
分析和设计（Analysis & Design）工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包（Package）和设计子系统（Subsystem），而描述则体现了类的对象如何协同工作实现用况的功能。设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。
（4）实现
实现（Implementation）工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式（源文件、二进制文件、可执行文件）实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。
（5）测试
测试（Test）工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现，识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。
（6）部署
部署（Deployment）工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。
（7）配置和变更管理
配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。
（8）项目管理
软件项目管理（Project Management）平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。
（9）环境
环境（Environment）工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。
- 需求获取
RUP运用用况（Use Case）技术来获取需求。
（1） 列出候选的需求：特征列表
（2） 理解系统语境：领域模型或业务模型
（3） 捕获功能需求：用况模型
（4） 捕获非功能需求：补充需求或针对一些特定的用况
特征：是一个新的项（Item）及其简要描述。
领域模型：类图
(1) 业务对象
(2) 实在对象
(3) 事件
业务对象模型：交互图、活动图
（1） 工作人员
（2） 业务实体
（3） 工作单元
创建系统用况模型的活动和任务：
（1） 发现并描述参与者
（2） 发现并描述用况
（3） 确定用况的优先级
（4） 精化用况
（5） 构造用户界面原型
（6） 用况模型的结构化 - 需求分析
在系统用况模型的基础上，创建系统分析模型以及在该分析模型视角下的体系结构描述。
分析类：是类的一种衍型，很少有操作和特征标记，而用责任来定义其行为，并且其属性和关系也是概念性的。
存在三种不同类型的类：实体类、边界类和控制类。
（1）实体类
实体类描述要保存到持久存储体中的信息。如：数据库、各种形式的数据文件中的信息。包括：
活动者类。活动者类代表出现在用况模型中的活动者。活动者是现实世界中与系统交互的人和/或机构。例如，订单处理系统中客户是一个活动者类。
业务类描述业务的地点、物品、概念和事件。例如订单处理系统中的订单、商品等都是业务类。
（2）边界类
也称界面类（UI类），是组成系统用户界面的屏幕显示、菜单和报表。例如，订单处理系统中客户登录系统的界面、显示和编辑订单的屏幕等都属于UI类。
边界类位于系统与外界的交界处。如：窗体类、报表类、描述通信协议的类、直接与外设交互的类、直接与外部系统交互的类。
（3）控制类
控制类是主要负责其它类工作的类。如：主程序类、主窗体类。
分析包:
分析包体现了“局部化”、“问题分离”等软件设计原理。
分析包把一些变化限制到一个业务过程、一个参与者的行为或一组紧密相关的用况，形成一些不同的分析包。
服务包和共享包。
用况细化：
（2）分析模型的表达
（3）分析的主要活动
活动1：体系结构分析
活动2：用况分析 - 设计层
定义满足需求规约所需要的软件结构。
RUP的设计目标：定义满足系统/产品分析模型所规约需求的软件结构。
4个术语：
（1） 设计类
（2） 用况细化
（3） 设计子系统
（4） 接口
两个角度：
（1） 系统设计模型
（2） 表达物理分布的系统部署模型 - 设计层的术语
（1） 设计类：是对系统实现中一个类或类似构造的一个无缝抽象。
了解设计类的主要特征：操作、属性、关系、方法、实现需求、是否为主动类。
（2） 用况细化：描述一个特定用况是如何予以细化的。
（3） 设计子系统
（4） 接口 - 设计模型、部署模型、体系结构描述
（1） 设计模型
（2） 部署模型
（3） 体系结构描述 - 设计的主要活动
活动1：体系结构设计
（1） 标识节点和它们的网络配置
（2） 标识子系统和它们的接口
（3） 标识在体系结构方面有意义的设计类和它们的接口
（4） 标识一般性的设计机制
活动2：用况的设计
（1） 标识参与用况细化的设计类
（2） 标识参与用况细化的子系统和接口
活动3：类的设计
（1） 概括描述设计类
（2） 标识操作
（3） 标识属性
（4） 标识关联和聚合
（5） 标识泛化
（6） 描述方法
（7） 描述状态
活动4：子系统设计
（1） 维护子系统依赖
（2） 维护子系统所提供的接口
（3） 维护子系统内容 - RUP的实现
RUP实现的目标：
（1）基于设计类和子系统生成构件
（2）对构成进行单元测试
（3）进行集成和连接
（4）把可执行的构件映射到部署模型
RUP实现的主要活动：
（1） 实现体系结构
（2） 集成系统
（3） 实现子系统
（4） 实现类
（5） 完成单元测试 - RUP的测试
包括：内部测试、中间测试和最终测试。
RUP测试包括的主要活动：
（1） 计划测试
（2） 设计测试
（3） 实现测试
（4） 执行集成测试
（5） 执行系统测试
（6） 评价测试
6301
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
