UML第十一讲统一软件开发过程概述.ppt

《UML第十一讲统一软件开发过程概述.ppt》由会员分享，可在线阅读，更多相关《UML第十一讲统一软件开发过程概述.ppt（90页珍藏版）》请在三一办公上搜索。

1、1,第十一讲 统一软件开发过程概述,（Rational Unified Process）,2,一个过程定义了为达到某个确定的目标，需要什么人在什么时间以何种方式做何种工作。对于软件工程而言，其目标是构造一个新的软件产品或完善一个旧的软件产品。一个有效的过程为有效地开发高质量的软件提供准则，它获取并提出当前技术条件下可行的最佳实践方案，因此可以降低风险并增强预见性。我们需要一个可用于指导顾客、用户、开发人员和项目经理等参与者的过程。我们需要一个广泛适用的过程，以便所有的项目相关人员都能够理解自己在所进行的开发工作中的角色。一个软件开发过程还要能随时间的推移不断地进化。在进化过程中，它能及时调整自

2、己以适应技术、工具、人员以及组织模式的变化。,软件开发过程,3,UML的创始者Booch、Jacobson和Rumbaugh在创建UML的同时，在Rational公司的支持下综合了多种软件开发过程的长处，提出一种新的面向对象的软件开发过程，称之为Rational统一过程 RUP。利用UML建模时，可遵循任何类型的建模过程。UML建模语言的作者们给出了一种推荐性的建模过程指导，即RUP。UML是一种建模语言,不是一种方法,它是软件系统开发方法的一个组成部分，UML本身没有关于开发过程概念的定义和表示符号，它独立于过程。,OO、UML、RUP的关系,4,软件开发问题可以归结为开发人员面临的将一个大

3、型软件所包含的各个部分集成为一个整体的难度。软件开发团体需要一个受控的工作方式；需要一个过程来集成软件开发的方方面面；需要通用的方法或过程来完成如下工作：指导一个群组活动的顺序。布置每个开发人员和整个群组的任务。确定开发何种制品。提出监控和测量一个项目的产品和活动的准则。具有明确定义和管理完善的过程是区分高效项目和不成功项目的关键。统一软件开发过程是30多年来经验的总结，是软件问题的一种解决方案。,统一软件开发过程,5,RUP保证了软件开发按计划、有目的、有序的进行。避免了软件开发过程中的盲目性。详细步骤在四个大阶段中是迭代的，可以有效的将软件开发过程分成许多小项目，有助于管理，有助于分割目标

4、，有助于计划的制定、实施和检查。有助于管理人员随时了解项目状态，避免各种开发过程中的风险。,RUP过程的主要目的,6,Rational Unified Process描述了如何为软件开发队伍有效的部署经过商业化验证的软件开发方法。(OO+UML+RUP)RUP被称为最佳实践不仅仅因为可以精确地量化它们的价值,而且它们被许多成功的机构普遍的应用。为使整个软件开发团队有效利用最佳实践,RUP为每个软件开发团队成员提供了必要准则模板和工具指导。,有效保证：方法、量化和准则,7,RUP是一套软件工程方法的框架，各个组织可根据自身的实际情况，以及项目规模对RUP进行裁剪和修改，以制定出合乎需要的软件工程

5、过程。RUP有九个工作流(构件)，分别有58个流程(包)和134个活动(类)，大约89个工件。RUP特别适合大中型项目的开发。,RUP是可裁剪的,8,过程,项目,产品,人员,工具,模板,自动化,结果,参与者,peopleprojectproductprocess,软件开发的四个要素（4P）,9,时间维上，为了能够方便地管理软件开发过程，监控软件开发状态，RUP把软件开发周期划分为Cycles，每个Cycle生成一个产品的新版本并依次由四个连续的阶段组成，每个阶段都应完成确定的任务。,迭代、增量式开发,10,迭代的开发软件需求管理使用基于构件的体系结构可视化软件建模验证软件质量控制软件变更,RU

6、P统一过程的特点,11,迭代的开发软件,为什么要以迭代方式开发？,12,迭代的开发软件,为了降低风险，应采用迭代方式递进开发。每次迭代完成都会发布一个可执行文件。,13,迭代式生命周期和瀑布式生命周期的风险比较,14,允许变更需求逐步集成元素 及早降低风险有助于组织学习和提高提高复用性生成性能更强壮的产品容许产品进行战术改变迭代流程自身可在进行过程中得到改进和精炼问题：迭代的保证基础是什么？,迭代式方法的优点,15,需求变更一直是给项目制造难题的主要根源，它们会导致延期交付、工期延误、客户不满意、开发人员受挫。用户会随着项目进行改变他们的想法。人的本性就是如此。强迫用户去接受他们最初所设想的那

7、种系统，是完全错误的。迭代便于您将变更需求考虑进来。需求总是会随着过程而变更。问题：为什么迭代可以适应变更？,适应变更,16,在迭代式方法中，集成可以说是连续不断的。过去在项目结束时要占到整个项目工作量 40%的那段较长的、不确定的且棘手的时期，现在分散到六至九个（很难精确计划的）集成部分中，每一部分要集成的元素都比过去少得多。集成并不只是简单的“一锤定音”-元素是被逐步集成的。问题：为什么迭代可以降低开发风险？,降低风险,17,因为相对于必须预先确定复用性而言，分部分设计和实施时更容易确定公用部分，所以可以提高复用性。确定和开发可重复使用的部分并非易事。早期迭代中的设计复审可使构架设计师确定

8、毋庸置疑的潜在复用部分，并在以后的迭代中开发和完善这些公用代码。问题：复用的设计基础是什么？,提高复用性,18,开发人员有机会在整个生命周期中边做边学，各显其能。测试员可早些开始测试，技术文档可早些开始编写迭代流程自身可在进行过程中得到改进和精炼。一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务。,组织学习,19,因为错误经过数次迭代已得到纠正，所以这样生成的构架将更强壮。在早期迭代中，随着产品逐步成熟，可以及早地发现缺陷。可以及时发现并减少性能上的瓶颈，而不是在交付前夕才发现它们。生成的是一个经过全面测试

9、的产品。关键功能因而有机会在数次迭代中经历多次测试。,提高质量,20,迭代在数量、持续时间和目标上都是按计划进行。参与者的任务和职责都已确定好。对进度进行的目标评测都将记录备查。从一次迭代到下一次迭代确实会存在返工现象，但返工也是严格按规定进行的。,规范,21,需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。需求不总是显而易见的，而且它可来自各个方面。需求并不总是能容易用文字明白无误地表达。在不同的详细级别上，需求的种类也各种各样。如果不加以控制，需求的数量将难以管理。需求之间相互关联关系，而且需求也和软件工程流程中的其他可交付工件有关。需求有唯一的特征或特征值。例如，它们的

10、重要性和容易满足的程度都各不相同。需求涉及众多相关方面，这意味着需求要由功能交叉的各组人员管理。需求会变更。,需求管理,22,构架框架或构架基础设施是可以在其上构建某种构架的构件集。软件构架设计RUP提供了一种系统化方法来设计、开发和验证一个构架。围绕多种构架视图的概念，以及构架样式、设计规则和约束的记录方式，提供了用于说明构架的模板。设计工作流程包括一些特定的活动，目的在于确定构架约束、在构架方面具有重要意义的元素以及有关如何选择构架的指南。构架主要是分析设计工作流程的结果。基于构件的开发 提供多种方法来支持基于构件的开发,基于构件的体系结构,23,用例视图：包括用例和场景，这些用例和场景包

11、括在构架方面具有重要意义的行为、类或技术风险。逻辑视图：包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包和子系统到层的组织形式。实施视图：包括实施模型及其从模块到包和层的组织形式的概览。同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。进程视图：包括所涉及任务（进程和线程）的描述，它们的交互和配置，以及将设计对象和类向任务的分配情况。配置视图：包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图）向物理节点分配的情况。,RUP“4+1 视图模型”,24,用迭代方法可以逐步确定构件，决定哪些需要开发，哪些可以复用以及哪些需要购买。软件构架的侧重点

12、清楚地说明了结构；构件以及集成它们的方法；它们相互作用的基本机制和模式。在分析设计中，使用诸如包、子系统和层次的概念来组织构件并指定接口。测试首先围绕构件展开，然后才逐渐过渡到较大的集成构件集。,基于构件的开发,25,基于构件的分层次构架,26,目前许多项目都使用面向对象编程语言来实现可重复使用的、容许变更并且稳定的系统。为实现具备这些优点的系统，在设计中使用对象技术尤为重要。统一建模语言(UML)集中体现了整个对象技术行业中的这种最佳方案。开发过程显示了对软件如何可视化建模。可视化抽象帮助你沟通软件的不同方面。确保构件模块一致于代码,保持设计和实现的一致性。,可视化软件建模,27,可视化建模

13、加深了抽象的程度,28,质量应该基于可靠性,功能性,应用和系统性能根据需求来进行验证。帮助计划,设计,实现,执行和评估这些测试类型。质量评估被内建于过程。所有的活动,包括全体成员,使用客观的度量和标准,并且不是事后型的或单独小组进行的分离活动。,验证软件质量,29,部署之后又发现软件问题再进行修复，这通常要多花 100 到 1000 倍的成本,要在特定时间达到既定目标，在整个项目生命周期内不断对质量进行检验和管理必不可少。,验证软件质量,30,管理变更的能力:确定每个修改是可接受的,能被跟踪的。开发过程描述了如何控制,跟踪和监控修改以确保成功的迭代开发。描述如何进行自动化集成和建立管理使小组如

14、同单个单元来工作。,控制软件的变更,31,控制变更不仅仅是检入和检出文件。它包括对工作区、并行开发、集成以及工作版本的管理。,控制软件的变更,32,配置与变更请求管理,33,需求变更工作流程已明确定义，并可重复执行。变更请求使交流更具条理性。隔离的各个工作区减少了同时工作的团队成员间的相互干扰。变更率统计为客观地评估项目状况提供了一个良好的指标。工作区中包含所有的工件，这有利于保持一致性。可以评估和控制对变更的传播。变更可以保留在一个强壮的可定制的系统中。,控制软件变更,34,时间：把软件开发的生命周期划分为若干阶段和一系列的循环重复。过程：过程是指良好定义的开发活动。历经这些活动，可以获得规

15、定的软件开发产物。,二维结构的软件开发过程,35,RUP二维结构,36,软件生命周期被分解为周期,每一个周期工作在产品新的一代上周期又划分为四个连续的阶段为，(每个阶段都有自已的目标，在阶段结束时要达到里程碑所要求的状态)。每个阶段迭代的执行九个工作流(其中有六个核心工作流和三个核心支持工作流)。每个不同的工作流由若干个流程组成。而每个流程由若干个活动构成。每个活动由一系列的步骤来完成，进一步，每个步骤由一些文字来进行说明。活动是RUP软件开发过程的基本单元。活动由指定的角色完成，并对执行活动而产生的产品负责。产品是软件开发过程中的所有文挡、程序。产品应是可测试或评审的。产品的最终形式是交付给

16、满足用户需求的可执行的软件系统。,RUP二维结构,37,时间,消亡,产生,一个版本所包括的循环,统一过程是在重复一系列组成系统生命周期的循环，每次循环都以向用户提供一个产品版本作为终结。,RUP的循环,38,初始,细化,构造,移交,第1次迭代,第2次迭代,第n-1次迭代,第n次迭代,版本,每次循环都包括四个阶段：初始、细化、构造和移交。每个阶段又进一步细分为多次迭代过程。,四个阶段,39,统一过程模型,40,从管理的观点来说，RUP 的软件生命周期随着时间分为四个依次进行的阶段，每个阶段的开始有一个主要目标，结束时有一个主要里程碑；实质上，每个阶段就是两个主要里程碑之间的时间跨度。在每个阶段结

17、束时进行评估，以确定是否实现了此阶段的目标。良好的评估可使项目顺利进入下一阶段。,项目的阶段和里程碑,41,初始阶段,为项目建立一个业务案例本阶段确定所设立的项目是否可行 对需求有一个大概的了解，明确地说明项目规模。确定系统中的大多数角色和用例。计划和准备商业理由。综合考虑备选构架，对给出的系统体系结构的概貌，细化到主要子系统即可。识别影响项目可行性的风险。考虑时间、经费、技术、项目规模和效益等因素。关注业务情况，制订出开发计划。准备项目的环境。,42,建立工程计划和合理的体系结构目标是建立系统构架的基线，以便为构造阶段的主要设计和实施工作提供一个稳定的基础。识别出剩余的大多数用例。对当前迭代

18、的每个用例进行细化，分析用例的处理流程、状态细节以及可能发生的状态改变。细化流程时，可以使用程序框图和合作图，还可以使用活动图、类图分析用例。对风险的处理。,细化阶段,43,培育这个系统构建阶段的目标是阐明剩余的需求，并基于已建立基线的构架完成系统开发。构建阶段从某种意义上来说是一个制造过程，在此过程中，重点在于管理资源和控制操作，以便优化成本、进度和质量。建立类图、交互图和配置图；如一个类具有复杂的生命周期，可绘制状态图；如算法特别复杂，可绘制活动图。每一次迭代开发都针对用例进行分析、设计、编码、测试和集成过程。,构造阶段,44,把这个系统提供给最终用户产品化阶段的重点是确保最终用户可以使用

19、软件,产品化阶段可跨越几个迭代。完成最后的软件产品和最后的验收测试，并完成用户文档编制以及用户培训等工作。获得用户反馈,基于反馈调整产品。使最终用户可以使用产品。,移交阶段,45,经过四个主要阶段的一个历程被称作一个开发周期，它导致一个软件的生成。第一次经历四个阶段称为初始开发周期。陈非产品的生命结束，否则一个现存的产品将以相同的顺序重复初始、细化、构造、和移交阶段，而演化到下一代产品。,开周发期,46,每个阶段都有详细制定的目标。为达到及实现这些目标，规定了要进行的活动及活动产生的产品，产品由里程碑的评估标准及产品状态进行评审。,阶段目标,47,如果项目无法达到该里程碑，则它可能中途失败或需

20、要进行相当多的重新考虑。通过完成的工件和里程碑状态进行评价。初始阶段:生命周期目标里程碑。细化阶段:生命周期构架里程碑。构造阶段:最初的操作性能里程碑。移交阶段:产品发布里程碑。,里程碑,48,目标评估标准工件工件的里程碑状态,里程碑内容,49,1.业务建模 2.需求 3.分析设计 4.实施 5.测试 6.部署 7.环境 8.项目管理 9.配置与变更管理,工作流,50,流程是为实现某个目标而设定的一系列次序相对固定的步骤。一个工作流程就是一系列活动，这些活动产生的结果是可见的价值。按 UML 术语，工作流程可以表现为序列图、协作图或活动图。RUP中使用活动图的形式，对于每个核心工作流程，都显示

21、一个活动图。RUP中有9个核心工作流,代表了所有角色和活动的逻辑分组情核心工作流分为6个核心工程工作流和3个核心支持工作流,工作流程,51,核心工作流程是在整个项目中与主要“关注领域”相关的活动的集合。将活动划分出核心工作流程主要是帮助从“传统的”瀑布式开发角度了解项目。将活动分成不同的核心工作流程使活动更容易理解，但会使时间安排变得比较困难。核心工程工作流：业务建模、需求分析、系统分析与设计、实现、测试 和系统配置。,核心工作流程,52,每个核心工作流程都与特定的模型集相关,53,业务建模工作流程明细,54,工作流程明细：评估业务状态,55,目的：定义可用于业务的所有文本说明，尤其是可用于业

22、务用例说明的常用词汇。步骤：1.查找常用术语 2.评估结果 步骤实施方法:输入工件:1.业务前景 2.前景 3.涉众请求生成工件:业务词汇表角色：业务流程分析员,活动：获取常用业务词汇,56,对将来使用系统的组织机构或企业进行评估，理解它们的需要以及未来系统要解决的问题。业务建模的结果是建立一个业务Use Case模型和业务对象模型。,业务建模的任务,57,需求分析工作流程明细,58,需求分析的任务是采集和评价系统的需求，重点是系统的实用性。需求分析的结果可以用一个Use Case模型表达，模型中的活动者代表外部的与系统交互的单元，Use Case代表交互的事务序列，它为活动者提供可度量的结果

23、值。,需求分析的任务,59,系统分析与设计工作流程明细,60,系统分析与设计的任务是研究欲采用的实现环境和系统构建的效用，结果是产生一个对象模型、即设计模型。设计模型包含了的实现，可以表现对象是如何相互通信和运作实现Use Case流的。在设计模型中可能包含对象类和子系统的接口定义,规定它们提供操作服务的责任。,系统分析与设计的任务,61,实现工作流程明细,62,实现的任务是在预定的环境中实现系统，生成系统的源代码、可执行程序和相应的软件文档，建立一个可执行的系统。,实现的任务,63,测试工作流程明细,64,测试的任务是对系统进行测试和排错，保证系统符合预定的要求，获得一个无错误的系统实现。测

24、试的结果将确认所完成的系统可以交付使用。,测试的任务,65,部署工作流程明细,66,配置与变更管理工作流程明细,67,项目管理工作流程明细,68,环境工作流程明细,69,一个工作流程就是一系列活动，这些活动产生的结果是可见的价值。RUP给出了每一个活动的目的、方法、内容、和实施步骤。活动概述显示工作流程中的所有活动和执行这些活动的参与者活动与工件密切相关：工件提供活动的输入和输出，并提供活动之间的通信机制。,活动,70,目的：每个活动有定义好的目的。步骤：活动由一系列的更细的步骤组成。工件：活动产生工件,工件是软件开发过程中的所有文挡、程序。工件应是可测试或评审的。输入工件：活动有自已的输入工

25、件。生成工件：活动产生新的或更新工件。参与者：活动一定由某个参与者角色执行。,活动,71,业务建模：活动概述,72,分析员:从事需求获取和研究的各种角色。开发人员:主要从事软件设计与开发的各种角色。测试员:从事软件测试的各种角色。经理:从事软件工程流程的管理与配置的各种角色。其他:从事项目支持或负责其他职能的各种角色。,RUP参与者,73,工件是项目期间生成并使用的最终或中间产物。RUP过程工件是软件开发的成果，每一个RUP活动都有相应的工件，工件是本活动的产品，又是下一个活动的输入和依据。RUP最终产物是最后提交的可执行的软件系统和相应的软件文挡。RUP过程工件包括两大类：模型和文挡。最重要

26、的工件是每个核心工作流程产生的模型：用例模型、设计模型、实施模型和测试模型。,RUP过程工件,74,业务模型：对问题领域中的组织机构的一个抽象。领域模型：表达系统的上下文。用例模型：表达系统的功能需求。分析模型：处理基本的功能需求和问题领域中的对象。设计模型：给出功能需求和对象问题的具体解决方案。过程模型：表达系统的并发和同步机制。配置模型：表达系统硬件拓朴及软件系统在硬件上的配置。实现模型：表达用于组装物理系统的各个软部件。测试模型：表达验证系统的途径。,RUP的九种模型,75,包括技术文挡和管理文挡技术文挡(四个主要集合)需求集合：系描述统必须做什么。设计集合：描述系统是如何被构造的。实现

27、集合：描述已开发的软件构件的装配。实施集合：可交付的配置的全部数据。管理文挡风险列表、软件开发计划、配置、测试计划,RUP的文档,76,RUP的主要工件及这些工件间的信息流,77,工件概述图显示工作流程中涉及的所有工件和参与者。工件分为输入工件和输出工件。工件是流程的工作产品参与者使用工件执行活动，并在执行活动的过程中生成工件。工件是单个参与者的职责,工件概述图,78,业务建模工件概述图,79,可视化建模工具Rational Rose需求管理工具Requisite Pro版本管理工具Clear Case文档生成SoDa测试工具SQA 和Perfomence 等。,RUP的工具支持,80,需求分

28、析 概要设计 详细设计 编码 集成、测试 验收交付 按阶段进行一个阶段实际上只存在一个工作流 不同阶段之间不能进行迭代,每个工作流都要历经初始、细化、构造、移交四个阶段 每个阶段迭代的执行所有的工作流。每个阶段有明确的目标和里程碑 最终的结果是迭代渐进的,两种开发方法的比较,81,调研访谈了解业务 计划 需求说明书 数据流图DFD 实体关系E/R图 部门/功能U/C图 功能/数据U/C图 子系统划分模块划分,建立系统的静态模型 发现对象，建立对象类。类结构图 定义对象的属性与服务。定义结构与连接。,需求分析,82,数据字典 活动功能描述 N-S盒图(流程图)输入处理输出设计描述(IPO1)判定

29、表 过程设计语言PDL,建立系统的动态建模 找出对象之间的事件编写脚本 用户界面 活动图、状态图、顺序图,概要设计,83,活动功能详细设计 输入处理输出设计描述(IPO2)N-S盒图(流程图)判定表 过程设计语言PDL,操作的设计算法 优化数据访问路径 外部交互控制 调整类结构优化关联封装为模块,详细设计,84,分模块编码 相互依赖性较大 形成连续产品的人为因素大,分类编码 相互依赖性较小 易分配人力(RUP开发区域管理),编码,85,模块测试 功能测试 集成测试 相互依赖性较大 效率较低 测试重复大,对象类测试 相互依赖性较小 第三者可参加测试,测试,86,RUP的静态视图,87,RUP的工

30、作流程视图,88,软件开发组织 三要素,软件开发技术,软件开发方法,软件开发管理,软件开发组织的三要素,89,自从1968 年提出“软件工程”这一术语以来，研究软件工程的专家学者们陆续提出了100 多条关于软件工程的准则和信条。美国著名的软件工程专家 Boehm 综合这些专家的意见，并总结了TRW 公司多年的软件开发经验，于1983 年提出了软件工程的七条基本原理。这七条原理是确保软件产品质量和开发效率的原理的最小集合。它们是相互独立的，是缺一不可的最小集合；同时，它们又是相当完备的。,软件工程的七条基本原理,90,1.用分阶段的生命周期计划严格管理2.坚持进行阶段评审3.实行严格的产品控制4.采纳现代程序设计技术5.结果应能清楚地审查6.开发小组的人员应少而精7.承认不断改进软件工程实践的必要性,软件工程的七条基本原理,