您好,欢迎访问三七文档
当前位置:首页 > 金融/证券 > 金融资料 > UML 第9章 RUP
1第9章Rational统一过程2本章内容什么是Rational统一过程Rational统一过程的演进历史Rational统一过程的结构Rational统一过程的配置和实现3什么是Rational统一过程(RUP)Rational:Rational统一过程是由Rational公司开发并维护的,可以将RUP看成一款软件产品,并和一系列软件开发工具紧密集成;统一:Rational统一过程拥有自己的一套架构,并且这套架构是以一种大多数项目和开发组织都能够接受的形式存在;过程:Rational统一过程是一种软件开发过程,提够了如何对软件开发组织进行管理的方式,并拥有自己的目标和方法;4什么是Rational统一过程(RUP)Rational统一过程是一种软件工程过程;Rational统一过程是一个过程产品;Rational统一过程拥有一套自己的过程框架;Rational统一过程包含了许多现代软件开发中的最佳实践;5什么是Rational统一过程(RUP)RUP以一种能够被大多数项目和开发组织适应的形式建立整个过程,包含6项最佳实践:①迭代式软件开发;②需求管理;③基于构件的架构应用;④建立可视化的软件模型;⑤软件质量验证;⑥软件变更控制;6(1)迭代式软件开发软件系统在规模上、复杂性上、分布式以及重要性上的要求在不断的提高,采用线性的开发方式无法在开始就完成对系统的完整定义;迭代式软件开发能够通过一系列细化和若干个渐进的反复过程形成有效解决方案;RUP专注于处理软件生命周期中每个阶段的最高风险,通过一系列的迭代过程和风险控制极大减少了项目的风险;7(2)需求管理通过一系列系统化的方式对各种软件密集型系统或应用程序的需求进行提出、组织、交流和管理;①RUP描述如何提取、组织和文档化所需要的功能以及对这些功能的限制因素;②能跟踪和文档化项目的解决方案并对项目做出决策,有时候需要对方案和决策进行折中;③能够对商业需求进行捕获,并进行交流;8(3)基于构件的架构应用RUP是以架构为中心的,该过程在开发之前,关注开发和产生健壮的可执行的体系结构的基线,描述如何设计灵活的、可容纳修改的、直观便于理解的并且促进有效软件重用的弹性结构;RUP还为架构提供一个设计、开发、验证的系统性方法,包括模板、架构风格、设计规则、设计规约、设计过程构件和管理过程等;9(4)建立可视化的软件模型RUP的可视化建模基础是UML;RUP指导如何有效地使用UML进行建模;RUP在开发过程中开发和维护模型,帮助理解和找到解决方案;10(5)软件质量验证软件质量关注两方面质量:产品质量和过程质量;软件产品的质量应关注于可靠性、功能性、应用和系统性能等方面并根据需求进行验证;RUP帮助开发人员计划、设计、实现、执行和评估,将软件产品质量评估内驾驭所有过程和活动中;RUP还针对如何验证和客观评价软件产品能否达到预期质量提出一系列的标准;11(6)软件变更控制RUP变更管理关注软件开发组织的需求变化,是针对需求、设计和实现中的变更产生进行管理的一种系统性方法;RUP变更管理能力确定每个修改是可接受的,并且能够跟踪。RUP描述了如何控制、跟踪和监控修改确保成功的迭代开发。12RUP的演进历史RationalUnifiedProcess(RUP,统一开发过程)是一套面向对象的软件工程过程。RUP说明了如何有效地使用成熟技术开发软件。13Rational统一过程的结构传统的瀑布开发模型是一个一维的模型,开发过程被划分为多个连续的阶段。在RUP中,软件开发生命周期根据时间和RUP的核心工作流划分为二维空间。横轴表示项目的时间维,是对过程的动态描述,通过迭代式软件开发的周期、阶段、迭代和里程碑等动态信息表示;纵轴以内容来组织为自然的逻辑活动,是对过程的静态描述,通过过程的构件、活动、工作流、产物和角色等静态概念来描述系统;1415图中的阴影部分描述了不同的工作流,在不同的时间段内工作量的不同。值得注意的是,几乎所有的工作流,在所有的时间段内均有工作量,只是大小不同而已。这与瀑布过程有明显的不同。10%50%30%10%进度10%65%20%5%工作量交付构造细化初始16统一过程的静态结构:过程描述统一过程的静态结构是通过对其模型元素的定义来进行描述的。在Rational统一过程的开发流程中定义了“谁何时如何做某事”,通过9种建模元素来表达:角色:构架师、系统分析员、测试设计师等;(谁)活动:角色执行的行为;(如何)产物:被过程产生的、修改或过程所使用的一段信息,是项目有形的产品;(某事)工作流:描述产生有价值的有意义的结果的活动序列;(何时)17角色:定义了个人或由若干个人组成小组的行为和责任;角色定义了一个人应该如何完成工作,即角色的职责;所分派给角色的责任既包括一系列的活动,还包括成为一系列产物的拥有者;①架构师②系统分析员③测试设计师18角色所执行的行为用活动来表示,每个角色与一组相关的活动联系,定义了他们执行的工作;活动通常具有明确的目的,将在项目语境中产生有意义的结果,通常表现为一些产物:模型、类、计划等;每个活动分派个特定角色,活动同常占用几个小时或几天;•计划一个迭代过程,涉及角色:项目经理;•寻找用例和参与者,涉及角色:系统分析员;•审核设计,涉及角色:设计审核员;•执行性能测试,涉及角色:性能测试人员;19产物:是被过程产生的、修改或者过程所使用的一段信息。产物是项目的有形产品;产物作为角色执行某个活动的输入,同时也是该活动的输出。模型、模型的组成元素、文档、源代码、可执行文件都是产物;20工作流:描述能产生若干有价值有意义结果的活动序列,显示角色之间的交互作用;工作流能够产生具有可观察结果的活动序列;通常一个工作流使用活动图的形式来表达;RUP中有9个核心工作流,分为6个核心过程工作流(CoreProcessWorkflows)和3个核心支持工作流(CoreSupportingWorkflows)。9个核心工作流在项目中轮流被使用,在每一次迭代中以不同的重点和强度重复。211.业务建模(BusinessModeling)2.需求(Requirements)3.分析与设计(AnalysisandDesign)4.实现(Implementation)5.测试(Test)6.部署(Deployment)7.设置和变更管理(ConfigurationandChangeManagement)8.项目管理(ProjectManagement)9.环境(Environment)22业务建模工作流23业务建模工作流提供的文档与模型①商业逻辑建模(USECASE)(ROSE)②业务需求说明书(MSWORD)③专业词汇表(英汉对照)(MSWORD)④风险说明(MSWORD)⑤复审说明书24需求工作流目的了解目标组织(将要在其中部署系统的组织)的结构及机制。了解目标组织中当前存在的问题并确定改进的可能性。确保客户、最终用户和开发人员就目标组织达成共识。导出支持目标组织所需的系统需求。为实现这些目标,业务建模工作流程说明了如何拟定新目标组织的前景,并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。25分析与设计工作流1.目的将业务需求转换为未来系统的设计。逐步开发强壮的系统构架。使设计适合于实施环境,为提高性能而进行设计。2627提供的文档与模型•系统总体设计报告(MSWORD)•系统领域模型DOMAINMODEL(ROSE)•系统设计模型DESIGNMODEL(ROSE)•数据库设计模型(POWERDESIGNER)•数据字典(MSWORD)•系统详细设计报告(MSWORD)•工作量化书(MSWORD)分析与设计工作流28实施工作流实施的目的包括:对照实施子系统的分层结构定义代码结构;以构件(源文件、二进制文件、可执行文件以及其他文件等)的方式实施类和对象;对已开发的构件按单元来测试,并且将各实施员(或团队)完成的结果集成到可执行系统中实施工作流程的范围仅限于如何对各个类进行单元测试。系统测试和集成测试将在测试工作流程中进行说明。29实施工作流30实施工作流提供的文档与模型①实施总结书(MSWORD)②实施模型(ROSE)③系统集成书(MSWORD)④代码审核意见书(MSWORD)⑤源代码(MSWORD)⑥用户使用手册(MSWORD)⑦错误解决记录手册(MSWORD)⑧构件及其说明31测试工作流测试的目的在于:①核实对象之间的交互。②核实软件的所有构件是否正确集成。③核实所有需求是否已经正确实施。④确定缺陷,并确保在部署软件之前将缺陷解决。32统一过程的动态结构:迭代开发迭代生命周期:通过多次不同的开发工作流,逐步确定一部分需求分析和风险,在设计、实现并确认这部分后,再去做下一部分的需求分析、设计、实现和确认工作,依次进行下去,直至整个项目完成,这样能在逐步集成中更好的理解需求,构造一个健壮的体系结构;一个开发迭代,在某种意义上来说是在所有工作流中一次完整的经过;当一个迭代过程进入到下一个迭代过程时,需要对整个项目的进展情况进行评估,使用里程碑的方式即时根据明确的准则决定继续、取消还是改变迭代过程。33为了对迭代的特定短期目标进行分割并组织迭代开发秩序,将迭代过程划分为9个连续的阶段:①初始阶段②细化阶段③构建阶段④移交阶段每个阶段结束于一个主要的里程碑(MajorMilestones),每个阶段本质上是两个里程碑之间的时间跨度。34(1)初始阶段初始阶段的目标是为系统建立商业案例和确定项目的边界;初始阶段所要进行如下的活动:①明确说明项目规模,了解环境以及最重要的需求和约束,以便可以得出最终产品的验收标准。②计划和准备商业理由。评估风险管理、人员配备、项目计划以及成本、进度、收益折衷的备选方案。③明确区分系统的关键用例和主要的功能场景;④展现或演示至少一种符合主要场景要求的候选软件体系结构;⑤对整个项目做出最初的项目成本和日程估计;⑥估计潜在的风险;⑦准备项目的环境;35初始阶段的产品:①总体蓝图②原始用例模型③原始项目术语表④原始商业案例⑤原始的风险评估⑥一个或者多个原型初始阶段结束的里程碑:生命周期目标里程碑。需要对阶段结束进行评审;36初始阶段的评估标准如下:①出资人同意系统范围定义以及费用和进度评估。②主要用例是否符合需求。③费用和进度评估、优先级、风险以及开发过程的可信性。④任何已开发的原型的深度和广度。⑤实际开销与计划开销。初始阶段的焦点是需求和分析工作流。37(2)细化阶段细化阶段的目标:分析问题领域、建立体系结构基础、编制项目计划、淘汰项目中最高风险的元素;由细化阶段决定是否将项目提交给构建和交付阶段;细化阶段确保结构、需求、计划是足够的稳定,风险被充分的减轻,可以为开发结果预先决定成本和日程安排;细化阶段的工作量至少处理初始阶段中识别的关键用例。细化阶段的目标是一个由产品质量级别构件组成可进化的原型;38细化阶段的目标:确保软件结构、需求、计划足够稳定;确保项目风险已经降低到能预计完成整个项目的成本和日程的程度;针对项目的软件结构上的主要风险已经解决或处理完成;通过完成软件结构上的主要场景建立软件体系结构的基线;建立一个包含高质量组件的可演化的产品原型;说明基线化的软件体系结构可以保障系统的需求,可以控制在合理的成本和时间范围内;建立好产品的支持环境;39细化阶段的产品所有用例均被识别,大多数用例描述被开发;补充捕获非功能性要求和非关联与特定用例要求的需求;软件体系结构描述可执行的软件原型;经过修订的风险清单和商业案例;总体项目的开发计划,包括纹理较粗的项目计划、显示迭代过程和对应的审核标准;指明被使用过程中更新过的开发用例;用户手册的初始版本(可选);40细化阶段细化阶段的评估标准如下:①标明用例模型中的用户和参与者,
本文标题:UML 第9章 RUP
链接地址:https://www.777doc.com/doc-6132065 .html