《软件工程实践与项目管理》课件第8章

8.1RUP概述 8.2RUP的生命周期8.3RUP的工作流程

8.4RUP开发案例第8章RUP开发方法8.1RUP概述

RUP(RationalUnifiedProcess)是统一开发过程的英文简写，它是一个面向对象的软件开发方法。

RUP开发方法于1998年由Jacobson等人提出。该方法根据螺旋模型和渐增模型软件开发原理进行软件开发，且每一次的迭代均产出一个可运行的系统版本，并对每一次迭代周期进行风险评估，以尽早发现问题。

1. RUP的特点

RUP有如下6个显著的特点：

(1)迭代式开发。软件开发的过程是一个迭代和递进的过程。迭代式开发模型允许在每次迭代过程中需求发生变化，开发人员可以通过不断对需求的细化加深对问题的理解。每个迭代过程都会产生一个可以执行的版本，这样可以降低项目的风险。

(2)需求管理。RUP通过文档对需求进行管理。

(3)基于组件的体系结构。因为组件具有独立性、可替换性、模块化等特点。软件使用组件体系结构有助于提高软件的重用率。RUP可以描述适应需求变化的、易于理解的、有助于重用的软件体系结构。

(4)可视化建模。RUP是和UML联系在一起的，它可以利用可视化的软件系统进行系统建模。

(5)软件质量验证。在RUP中软件质量评估不再是事后进行或小组单独进行的活动，而是贯穿在软件开发过程的所有活动中，这样可以及早发现软件的缺陷。

(6)控制软件变更。RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。

2. RUP的优点和不足

RUP开发方法具有很多优点，例如：

(1)提高了团队生产力。RUP开发方法针对所有关键的开发活动为每个开发人员都提供了必要的准则、模板和工具指导。

(2)它建立了简洁和清晰的软件结构。通过业务建模和系统分析与设计完成了软件架构设计，这样为开发过程提供了较好的通用性。RUP非常适合系统分析和设计师在开发过程的上游阶段设计系统架构。虽然RUP是开发应用的一个非常好的方法，但是RUP开发方法缺少关于软件运行和维护等方面的内容。在实际应用中可以根据需要结合结构化方法的优点对其进行改进。8.2RUP的生命周期

RUP的生命周期分成四个阶段，分别是：初始(Inception)、细化(Elaboration)、构造(Construction)与交付(Transition)，这四个阶段构成一个周期，可反复进行。图8-1给出了一个外包项目的RUP的生命周期。图8-1一个外包项目的RUP的生命周期

1．初始阶段初始阶段的目标是需求分析，即了解项目范围，建立企业个案，取得有关人员对推展该项目的认同。这个阶段的主要工作是确定系统的业务用例，获得项目范围、关键风险等需求，并且决定是否进入细化阶段。

2．细化阶段细化阶段的目标是迭代地构建系统的核心体系结构并解决技术风险。构建系统的体系结构意味着真正的编程、集成及测试，淘汰项目中的最高风险的元素，主要有以下过程：

(1)确定构架。确保系统构架和系统需求，充分减少风险，从而能够有预见性地确定开发所需的成本和开发进度。

(2)制定构建计划。为构建阶段制定详细的过程计划并为其建立基线。

(3)建立支持环境。支持环境包括开发环境、开发流程、支持工具(包括自动化/半自动化工具)。

(4)阶段技术评审。阶段技术评审是对软件开发过程中的需求分析阶段、系统设计阶段等进行技术评审。评审技术包括桌面检查、走查、小组评审等方法，评审过程包括制定评审计划、评审角色、召开评审会议和验证分析等过程。

(5)撰写设计文档。设计文档包括：系统概要设计报告(包括系统接口设计、运行设计、数据库设计、数据字典设计等)，系统详细设计报告(包括类图、时序图、状态图和部署图等)。

3．构造阶段构造阶段的目标是建构与演化可运作的系统版本。这个阶段完成细化阶段没有完成的任务以及系统的集成和部署。大部分需求的不稳定性已经在细化阶段澄清，所以在这个阶段需求的变化较少。

4.交付阶段交付阶段的目标是建立最终版本的软件系统，并交付给客户。一般地，对于RUP开发方法，推荐迭代周期的长度为2～6周。8.3RUP的工作流程图8-1所示的每个循环阶段均包括九个工作流程：业务建模(BusinessModeling)、需求获取(Requirements)、分析与设计(Analysis&Design)、实现(Implementation)、测试(Test)、部署(Deployment)、配置与变更管理(Configuration&ChangeManagement)、项目管理(ProjectManagement)、系统运行环境(Environment)。其中，前六项是软件工程工作，而后三项是管理与支持工作。大致作如下介绍：

1．需求获取需求获取的主要工作是建立待开发系统的用例模型，并通过多次迭代来完善它，然后进行初步的界面设计。

2．分析分析阶段主要是对需求阶段的用例模型进行细化。在需求获取阶段得到的用例是用面向用户的语言表达的，在分析阶段要使用面向开发人员的语言进行描述，这个阶段也叫“概要设计”阶段。

3．设计设计阶段是对“概要设计”阶段描述的需求结合具体的程序语言、操作系统、数据库技术等对接口、用户界面进行详细设计。

4．实现实现阶段是执行上面的设计结果，通过编写代码来实现系统。

5．测试每一次的迭代都要进行测试。包括编写测试计划、编写测试用例等。图8-2给出了RUP中测试工作流相关的角色，以及角色所负责的工作。在实际工作中，RUP模式的每个循环阶段中都经过如下五个核心工作流程的多次迭代(或叫“再工程”)，如图8-3所示。图8-2测试工作流相关的角色和责任图8-3RUP模式的再工程8.4RUP开发案例下面是一个关于食堂IC卡就餐系统的项目实例，我们将结合这个实例来描述RUP的开发过程。

1.任务描述食堂IC卡就餐系统是使用现代信息技术和自动控制技术的计算机网络系统。系统通过发行IC卡，作为电子钱包和货币，从而避免了小额现金支付的不方便和避免收到假钞引起的不必要的纠纷。刷卡消费的扣款可在1秒内完成，从而极大地提高了收银速度，还因此避免了找零所浪费的时间。系统要求：

(1)数据传输采用加密、校验，提高安全性和可靠性，消费记录实时上传；

(2)故障时进入记账模式，消费记录由存储器保存，并能将数据上传到数据库；

(3)消费报表可灵活设置，可按日、旬、月、年或某个时间段、某个部门来进行查询；

(4)本消费系统对系统操作员的每项操作都有明细记录，可方便查询；

(5)对非本系统的卡以特殊提示信息显示，可靠保障系统的安全性。

2.需求分析系统的主要功能如下：

(1)系统信息管理：建立营业组档案、持卡用户档案、收款机档案；

(2)卡的管理：开户、更改、发卡、挂失解挂、注销、补卡、充值、统计等；

(3)日常操作：数据采集、终端设置、挂失名单、上传交易、上传充值等；

(4)营业汇总：自动汇总交易数据，实现金额结算，生成相应报表；

(5)查询：对每一次消费情况进行实时记录，可查询卡内余额或消费记录；

(6)系统维护：数据备份、数据恢复、端口设置、管理员设置密码和权限；

(7)统计报表：就餐卡发行、各窗口机就餐数据、黑名单汇总、明细报表等。系统的主要模块有：员工资料管理，员工就餐卡发放，员工临时卡发放，就餐卡充值，就餐卡挂失与解挂，就餐卡补卡，就餐卡补贴，就餐卡回收，消费统计，档口与业主的结算，营业报表分析(月报、周报、日报、总卡余额)，系统数据维护(数据初始化、备份、恢复、清除历史记录、日志管理等)。

1)找出角色与用例

RUP的需求分析过程主要说明这个软件是“由谁用来干什么”，即找出角色(“谁”)和用例(“干什么”)。对于食堂IC卡就餐系统，为了发现角色和用例，要从下面的需求入手，为确定系统角色和用例打下良好基础。

(1)有哪几个岗位的工作人员要使用这个系统？这个问题的目的是获取岗位名称，子系统或用例，或是某个初步的类或对象。回答：食堂售饭人员和系统管理人员。

(2)公司的哪个部门使用系统？后勤食堂。

(3)售饭人员在售饭时，从哪里开始，经过几个步骤，最后怎样才算完成了呢？这个问题的目的是想得到子系统功能的进一步详细描述。是某子系统或整个系统数据处理的过程；可帮助得到数据流图，输入和输出信息；可以得到某功能模块名或对象名，可得到某个模块功能或某对象的动作。回答：系统中每个消费者都有一张卡，在管理中心注册缴费，卡内记录着消费者的身份及余额。使用时将卡插入刷卡机则显示卡上金额，服务员按刷卡机上数字键，刷卡机(如图8-4所示)自动计算并显示消费额及余额。管理中心监视每一笔消费，可打印出消费情况的相关统计数据。图8-4刷卡机其他问题：谁/什么从系统获得信息？谁/什么向系统提供信息？谁/什么支持、维护系统？哪些其他系统使用此系统？某岗位的工作人员用这个系统来做什么事？(这个问题的目的是想得到该岗位要做事情的具体描述，可能是与该岗位相关的子系统的功能需求，或某个用例的细化、某个类的方法功能。)某岗位的工作人员用这个系统来做什么事？(这个问题的目的是想得到该岗位要做事情的具体描述，可能是与该岗位相关的子系统的功能需求，或某个用例的细化、某个类的方法功能。)通过以上分析，发现系统的角色是：消费者(食堂就餐人员)，营业员(售饭人员、售饭机)，系统管理员。角色希望系统做的每件事成为一个用例，为了发现该用例，我们可以尝试如下问题：

(1)为什么营业员想要使用此系统？

(2)系统管理员是否要创建、保存、更改、移动或读取系统的数据？假如是，为什么？

(3)营业员在销售饭菜时，能够容忍系统做出反应所需的最长的时间？目的：得到有关速度要求的描述。

(4)系统管理员在注册IC时需要的数据是什么？目的：得到与输入有关的及与其他系统的接口描述。

(5)用户以前用过类似的系统吗？如果用过，请谈谈那些系统中最让你满意的方面和最让你不满意的方面。目的：得到用户对新系统的一些改进期望。

(6)请问你期望新系统的外貌是怎样的？新系统在哪些设备上运行？目的：可以得到用户对新系统界面的一些要求，可据此创建一个界面原型让用户感受，请用户提出进一步的建议后再确定系统界面。

2)用例描述用例过程主要是描述角色什么时候使用系统，用例什么时候发生。对于本例如表8-1所示。

3.系统建模

1)系统的用例图对于IC卡就餐系统而言，它由三个用例组成，每个用例由二元关联类的事项组成，即消费者与系统服务器之间的“卡的管理事项”，储值卡与收款机之间的“消费事项”，以及系统服务器与服务员的“经营结算事项”。整个系统的角色是：消费者、管理员和营业员。图8-5是本系统的用例图。图8-5系统的用例图从每个用例行为中找出类，以及每个类中找出属性和操作。

(1)卡的管理事项：类：注册。属性：IC卡的类型、主人、性别、单位。操作：数据记录，数据修改，数据删除。

(2)消费事项：类：消费。属性：IC卡号、消费金额。操作：插入卡，输入金额。

(3)结算事项：类：结算。属性：消费金额、饭菜名称、价格。操作：结算。

2)系统的序列图序列图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互。在IC卡就餐系统中，系统服务器处于主动位置，它管理相关的事项和其他类，从系统服务器、储值IC卡、收款机三类活动的相关对象开始进行执行路线追踪，发现系统中各种消息连接。图8-6的序列图对消费事项个案进行了更为详细的描述。图8-6系统的序列图

3)系统的部署图部署视图描述位于节点实例上的运行组件实例的安排。节点是一组运行资源，如计算机、设备或存储器等，部署视图用部署图来表达。图8-7表示系统中各组件和每个节点包含的组件。图8-7部署视图

4.系统分析与设计

1)运行环境

IC卡就餐系统的运行环境如下：平台：W