uml项目计划--基于rup的软件开发过程规范(编辑修改稿)

uml项目计划--基于rup的软件开发过程规范(编辑修改稿)内容摘要：

timistic SavingDepositOptimistic SavingWithdrawOptimistic Deposit and Withdraw 正常 /中等 CheckingDepositNormal CheckingWithdrawNormal SavingDepositNormal 基于 RUP 的软件开发过程规范 Draft 1 SavingWithdrawNormal Deposit and Withdraw 悲观 /复杂 CheckingDepositPessimistic CheckingWithdrawPessimistic SavingDepositPessimistic SavingWithdrawPessimistic Inquiries and Transfers Checking Inquiry， Checking Transfer， Saving Inquiry， Saving Transfer Inquiries and Transfers 乐观 /简单 CheckingInquiryOptimistic CheckingTransferOptimistic SavingInquiryOptimistic SavingTransferOptimistic Inquiries and Transfers 正常 /中等 CheckingInquiryNormal CheckingTransferNormal SavingInquiryNormal SavingTransferNormal Inquiries and Transfers 悲观 /复杂 CheckingInquiryPessimistic CheckingTransferPessimistic SavingInquiryPessimistic SavingTransferPessimistic Overdrafts CheckingOverdraft， SavingOverdraft Overdraft 乐观 /简单 CheckingOverdraftOptimistic SavingOverdraftOptimistic Overdraft 正常 /中等 CheckingOverdraftOptimistic SavingOverdraftNormal Overdraft 悲观 /复杂 CheckingOverdraftOptimistic SavingOverdraftPessimistic 对每个 Build/Release 迭代，下面是计划和监控表。 UML 模型是当前模型的位置，例如 XYZ\F:UMLModels\. OO 项目 进度状态表 迭代 1乐观 /简单 迭代 2正常 /中等 迭代 3悲观 /复杂 UML 模型 计划开始日期 修订的开始日期 实际开始日期 计划完成日期 修订的完成日期 实际完成 /复查日期 目前完成百分比（ %） 模型复审日期 构造批准日期 备注 UML 模型的复审每两周进行一次或在每个迭代结束时进行。 周期性的，我们可以计划基于 RUP 的软件开发过程规范 Draft 1 安排在一个迭代内部对需求、分析、设计和实现进行 复审。 所有 UML 视图和规格说明应被放置在姓名目录中，并且使所有项目复审和评论人员可以获得。 每个迭代的源代码和测试结果也应使所有项目复审和评论人员可以获得。 模型复审应包含对主要的 UML 视图和问题的简要评述。 使用 Use Case 增量和 build/release 迭代的好处有：  支持有效的计划和决策，“一点一点”而不是“一次完成”的方式  降低 项目风险 ，因为客户可以看见切实的结果  支持有效的变更管理  支持创建分阶段交付的一个质量系统 Use Case 需求规格说明 Use Case 规格说明是 OO 项目 需求的主要规格 说明文档之一。 每个 OO 项目 Use Case要收集以下信息：名称、发起者、输入参数、输出返回值、前提条件 /异常情况、后置条件/异常情况、基本 /乐观的场景、替代 /悲观场景、业务规则、测试用例。 WithdrawFromCheckingAccount Use Case 的 Use Case 规格说明 Use Case 名称 WithdrawFromCheckingAccount 触发用例 WithdrawFromCheckingAccount 输入参数 sAcctNum， nWithdraw 输出返回 SText 前提条件 ValidAccount = true and nWithdraw = nCurrentBalance 引发异常的前提条件 To be determined 描述 /变换 nCurrentBalance = nCurrentBalance–nWithdraw 后置条件 nCurrentBalance nOldBalance 异常的后置条件 None 基本 /乐观的场景 文本 –待确定；图形 见 WithdrawFromCheckingAccount–Optimistic Scenario 序列图 替代 /悲观的场景 文本 –待确定；图形 –见 WithdrawFromCheckingAccount 活动图 业务规则 ValidAccountRule， AdequateBalanceRule 测试用例 1–Optimistic:  Inputs:  sAcctNum–BGates001  nWithdraw–100  nCurrentBalance–1000  Conditions: None  Output: BGates001 withdraw $100 OK and recorded， 2 … To be determined 输入 /输出表单 见 下面 Input/Output Forms for WithdrawFromCheckingAccount Use Case 基于 RUP 的软件开发过程规范 Draft 1 Withdraw Request Form Customer Account Number __________ Withdraw Amount __________ ButtonSubmit ButtonClear Withdraw Response Form Customer Account Number __________ Withdraw Amount __________ Status ________________________ ButtonOK 使用良好定义的 Use Case 规格说明的好处是：  支持 Use Case 建模的一致性  支持完整性，尤其对识别前提条件、后置条件和业务规则  对与行业专家的交流很有用 在构建阶段的 RUP模型 在构建阶段，我们创建主要的 UML 视图和规格说明。 基于 RUP 的软件开发过程规范 Draft 1 项目视图/ 软件需求规约包视图包含所有用例的用例视图为每个U s e C a s e C o u r s e 绘制序列图为每个U s e C a s e s 所有C o u r s e 绘制活动图序列图和/ 或协作图活动图和状态图Activity StateActivity StateActivity StateActivity StateStateState第四步：实现流程环境( 软件和硬件)组件图/ 部署图和代码第三步：设计流程环境( 软件和硬件)更新类图/ 包图/ 序列图/ 协作图/ 活动图/ 状态图系统/ 子系统/ 组件第一步：需求包/ 类/ 对象第二步：分析类模型第五步：测试和部署测试模型构造 配置模型配置模型基于 RUP 的软件开发过程规范 Draft 1 这些模型在 RUP 中的关键部分如下表所示。 关键是对每个 build/release 迭代 (34 星期 )创建所有这些模型。 需求模型 分析模型 设计模型 实现模型 测试模型 关 键 的UML 元素 系统，行动者，Use Case， 迭代 业务包 ，类，对象，消息 硬件和软件配置， 包，类，对象，消息 组件，节点， 代码 测试计划 和 测试用例 工作要点 将 系统 看成黑盒进行建模 在问题域对业务元素建模，不涉及实现细节 为根据一个特定的实现（如 硬件和软件配置 ）更新分析模型中的视图和规格说明 为发布环境的物理元素建模， 代码 满足所有需求 单元 (类 /操作 ) 测试 ， 集成 /系统 /验收测试 目标 元素之间弱偶合 强内聚 所有 Use Case 和场景都有充分的信息，所有增量 /迭代已计划 满足需求的最简单的业务 /问题域模型 有充分的信息可以生成代码或手工编码 优化 组件体系结构 –网络友好， 代码 满足所有需求 充分的测试保证 代码 满足所有需求 静态 /结构性视图 方块图和 Use Case 图 包 图 /类 图 包 图 /类 图 组件 图 /部署图 /逆向工程 类 图 动态 /时间相关的视图 Use Case 图 ， 为每个 Use Case 的每个 Use Case 场景 绘制 序列图 为每个 Use Case场景 绘制 序列图 ，为每个基于状态的类绘制 状态图，为每个复杂的操作绘制 活动图 为每个 Use Case 场景 绘制 序列图 ，为每个基于状态的类绘制 状态图， 为每个复杂的操作绘制活动图 根据需要更新 序列图 来显示分布式 消息 工具 ROSE ， 需求 跟踪 ， 配置管理 ROSE， 需求跟踪 ，配置管理 ROSE， 需求跟踪 ，配置管理 ROSE， 需求跟踪 ， 配置管理，测试 配置管理，测试 关键角色 业务 /系统分析员 业务 /系统分析员 程序员 体系结构师，程序员 程序员 /测试员 模型结束 项目经理 ， 体系结构师，客户 /用户 项目经理，体系结构师，客户 /用户 项目经理 ，体系结构师。