第16章统一软件开发过程(RUP)课件

第16章 统一软件开发过程UP统一过程（UP）n软件开发过程描述了构造、部署以及维护软件的方式。n统一过程（Unified Process）是一种构造面向对象系统的迭代软件开发过程。其中RUP是对UP的详细精化。n98年RUP 5.0推出 6个最佳开发经验n迭代式开发n管理需求n使用基于构件的体系构架n可视化软件建模n验证软件质量n控制软件变更迭代和演化式开发n迭代和演化式开发是UP和其它方法中普遍采用的开发方法。n开发被组织成一系列固定的短期小项目（迭代，iteration），每次迭代都产生可执行的局部系统，都具有各自的需求分析、设计、实现和测试活动。迭代和演化式开发一次迭代不宜过长，否则复杂性不可控制瀑布式开发n试图在编程之前详细定义出所有的需求，创建出完整的设计（模型集），一次性完成软件系统的分析、设计、实现、测试等n现实情况往往并非如此理想化。迭代式开发更适合处理变更。迭代开发的优点n减少项目失败可能性，提高生产率，降低缺陷率n在早期（而不是晚期）缓解高风险（技术、需求、目标、可用性等）n早期可见的进展n早期反馈，用户参与调整，会更接近用户需求n可控复杂性；团队不会被长期且复杂的步骤所淹没n一次迭代中的经验可以被系统的用于改进开发过程本身，并反复进行下去n可以提出一个软件体系结构来指导开发迭代示例风险驱动和客户驱动nUP提倡风险驱动（risk-driven）和客户驱动（client-driven）相结合的迭代计划早期的迭代目标要能够识别和降低最高风险能构造出客户最关心的可视化特性n风险驱动迭代开发更为明确的包含了以架构为中心（architecture-centric）迭代开发的思想，意味着早期迭代要致力于核心架构的构造、测试和稳定，因为没有稳定的架构就会带来高风险。进化式需求与瀑布式需求n任何试图在开始就固定或者定义所有需求的方法都有本质的缺陷，例如瀑布式需求分析n在UP和进化式方法中，具有产品品质的编程和测试要远早于大多数需求的分析或规格化n结合早期时间定量的迭代开发，进行进化式的需求分析，并且引入频繁的涉众参与、评估和对局部结果的反馈需求类型和种类nFURPS+功能性（Functional）：特性、功能、安全性可用性（Usability）：人性化因素、帮助、文档可靠性（Reliability）：故障频率、可恢复性、可预测性性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率可支持性（Supportability）：适应性、可维护性、国际化、可配置性需求类型和种类n（+）实现：资源限制、语言和工具、硬件接口：强加于外部系统接口之上的约束操作：对其操作设置的系统管理包装：打包形式授权：许可证敏捷方法（agile development）n应用定量时间的迭代和演化式开发方法，提倡增量交付并包含其它敏捷性特征。n敏捷原则最高优先级：通过早期和持续交付有价值的软件来满足客户；欢迎变更需求，即使是在开发的后期提出；以两周到两月为周期，频繁的交付可运行的软件；在整个项目过程中，每一天开发人员和业务人员合作；由个体推动项目的建设，为个体提供所需的环境、支持和信任敏捷方法（agile development）开发团队中采取面对面的交谈衡量进展的重要尺度是可运行的软件不断应用先进的技术提高敏捷性简洁最重要，尽量减少工作量最佳的架构、需求来自于自组织的团队团队要定期反省如何做使工作更有效敏捷建模（agile modeling）n采用敏捷方法并不意味着不进行任何建模n建模的目的主要用于沟通和理解，而不是构建文档n不要对所有的软件设计建模和应用UMLn尽可能使用最简单的工具（白板）n坚持使用简单，常用的UML元素n多人建模n并行建模（交互图，类图）n建模和实现最好是相同的人UML草图UP的软件开发生命周期n初始（Inception）大体的构想、业务案例、范围和模糊评估n细化（Elaboration）已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数的需求和范围以及进行更为实际的评估n构造（Construction）对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署n移交（Transition）进行Beta测试和部署UP的阶段UP的软件开发生命周期1234RUP初始阶段主要成果：主要成果：n前景文档：对核心项目要求、关键性质、前景说明。前景文档：对核心项目要求、关键性质、前景说明。n初始的项目术语表。初始的项目术语表。n初始的用例模型和商业用例。初始的用例模型和商业用例。n项目规划，其中明确阶段和迭代，一个或多个原型。项目规划，其中明确阶段和迭代，一个或多个原型。n初始的风险评估和商业模型。初始的风险评估和商业模型。评估准则：评估准则：n相关共利益者对项目范围定义和成本相关共利益者对项目范围定义和成本/进度估计达成共识。进度估计达成共识。n通过主要的用例将需求无二义地表达出来。通过主要的用例将需求无二义地表达出来。n成本成本/进度估计、优先级、风险和开发过程的可信度。进度估计、优先级、风险和开发过程的可信度。n开发出来的体系结构原型的深度和广度开发出来的体系结构原型的深度和广度 RUP细化阶段成果：成果：n用例模型用例模型n可执行的体系结构原型及其描述可执行的体系结构原型及其描述n修订后的风险表和商业用例、开发用例，指定要使用的过程。修订后的风险表和商业用例、开发用例，指定要使用的过程。n整个项目的开发计划。整个项目的开发计划。评估准则：评估准则：n产品的前景是否稳定？体系结构是否稳定？产品的前景是否稳定？体系结构是否稳定？n可执行的演示是否强调了主要的风险元素并得到解决？可执行的演示是否强调了主要的风险元素并得到解决？n构造阶段规划是否已经足够详细和准确，是否有可信度的评估构造阶段规划是否已经足够详细和准确，是否有可信度的评估支持？支持？n如果用当前的计划来开发整个系统，包括使用已定义的体系结如果用当前的计划来开发整个系统，包括使用已定义的体系结构，是否所有相关共利益者对此都达成一致？构，是否所有相关共利益者对此都达成一致？RUP构造阶段版，至少应该包括：版，至少应该包括：n在特定平台上集成的软件产品。在特定平台上集成的软件产品。n用户手册和对当前版本的描述。用户手册和对当前版本的描述。评估准则是：评估准则是：n产品版本是否足够稳定和成熟，可以在用户群中发布吗？产品版本是否足够稳定和成熟，可以在用户群中发布吗？n是否所有相关共利益者都同意产品的发布？是否所有相关共利益者都同意产品的发布？n实际的资源支出和计划的支出的比值是否仍然可接受？实际的资源支出和计划的支出的比值是否仍然可接受？RUP交付阶段主要工作有：主要工作有：n测试，确认新系统达到用户的预期。测试，确认新系统达到用户的预期。n与被取代的旧系统并行操作，以及功能性数据库的转与被取代的旧系统并行操作，以及功能性数据库的转换。换。n用户和维护人员培训。用户和维护人员培训。n向市场、分销商和销售人员进行新产品的展示。向市场、分销商和销售人员进行新产品的展示。n交付阶段侧重向用户提交软件的活动，评估准则可以非常简单，也可能极其复杂。n用户是否满意？用户是否满意？n是否能够接受实际的和计划的资源支出的比？是否能够接受实际的和计划的资源支出的比？开发案例为项目选择实践和UP制品可以编写为简单文档，这称为开发案例（环境科目中的制品）尚未理解UP和迭代开发开始设计或者实现前试图定义大多数需求；编程之前花费数日或数周进行UML建模；认为初始阶段=需求阶段，细化阶段=设计阶段，构造阶段=实现阶段认为细化的目的是完整的定义模型，以能够在构造阶段将其转换为代码坚信合适的迭代时间长度为三个月，而不是三周认为采用UP就意味着要完成大量可能的活动和创建大量的文档试图从项目开始到结束制定详细计划，预测所有迭代，以及每个迭代中可能发生的事情RUP中的核心概念角色(Role)：描述某个人或一个小组的行为与职责；活动(Activity)：一个有明确目的的独立工作单元；制品(Artifact)：活动生成、创建或修改的一段信息；工作流(Workflow)：描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系；其他基本概念：工具教程(Tool Mentor)、检查点(Checkpoints)、模板(Template)、报告(Report)等。课本P184页图Use Case 驱动的、驱动的、以体系结构为中心的、以体系结构为中心的、迭代、增量的开发迭代、增量的开发.何谓何谓 USE CASE USE CASE 驱动驱动USE CASE 分分 析析输入输入 设设 计计 实实 现现跟踪跟踪输入输入跟踪跟踪输入输入跟踪跟踪输入输入输入输入 测测 试试输入输入跟踪跟踪输入输入UP特点特点从从USE CASEUSE CASE模型的视觉模型的视觉从分析模型的视觉从分析模型的视觉从设计模型的视觉从设计模型的视觉从实现模型的视觉从实现模型的视觉从部署模型的视觉从部署模型的视觉给给 出出体体 系系 结结 构构描描 述述 何谓何谓以体系结构为中心以体系结构为中心软件体系结构刻画了系统的整体设计，它去掉了细节部分，突出了系统的重软件体系结构刻画了系统的整体设计，它去掉了细节部分，突出了系统的重要特征。对于一个软件系统，不同人员所关心的内容是不一样的。要特征。对于一个软件系统，不同人员所关心的内容是不一样的。用例n用例文本形式的情节描述n说明某参与者使用系统以实现某些目标广泛应用于需求的发现和记录中示例n处理销售：顾客携带所购商品到达收银台。收银员使用POS系统记录每件商品。系统连续显示累计总额，并逐行显示细目。顾客输入支付信息，系统对支付信息进行验证和记录。系统更新库存信息。顾客从系统得到购物小票，然后携带商品离开UP制品影响力定义n参与者（actor）某些具有行为的事物，可以是人、计算机系统或组织，例如收银员n场景参与者与系统之间的一系列特定的活动或交互，也称为用例实例（use case instance）n用例（use case）一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标交替场景用例n处理退货主成功场景n顾客携带商品到收银台退货。收银员使用POS系统记录并处理每件退货.交替场景n如果客户之前用信用卡付款，而其信用卡帐户退还交易被拒绝，则告知顾客并使用现金退款n如果在系统中没有找到该商品的标识码，则提示收银员并建议手工输入标识码n如果系统检测到与外部记账系统通讯失败，则.用例和用例模型n所有书面用例的集合；n系统功能性和环境的模型。n用例模型不是唯一的需求制品。其它的还有补充性的规格说明、词汇表、设想和业务规则等等。n是文本文档，而不是图形，用例建模主要是编写文本的活动，而非制图。参与者类型n主要参与者（primary actor）具有用户目标，并通过使用系统的服务完成。例如：收银员n协助参与者（supporting actor）为系统提供服务。自动付费授权n幕后参与者在用例行为中具有影响活利益，但不是主要或协助参与者。例如：政府税收机构表示法n摘要简洁的一段式概要，通常用于主成功场景n非正式非正式的段落格式。用几个段落覆盖不同场景。n详述详细编写所以步骤及各种变化，同时具有补充部分，如前置条件和成功保证等用例编写模板n用例名称n范围n级别n主要参与者n涉众及其关注点n前置条件n后置条件n主成功场景n扩展n特殊需求n技术和数据变元表n杂项准则n无用户界面约束与界面无关n简洁删除噪音词汇n编写黑盒用例系统记录销售 VS 系统将销售信息写入数据库,系统对销售信息生成SQL INSERT语句n参与者和参与者目标的观点关注系统用户或者参与者来编写需求如何发现用例nStep1：选择系统边界POS系统是要设计的系统。任何该系统之外的事物都在边界之外。包括收银员、支付授权服务等nStep23：寻找主要参与者和目标除了明显的主要参与者和目标外，什么样的问题有助于确定可能会遗漏的参与者和目标？n谁来启动和停止系统？n谁来完成用户管理和安全管理？n系统失败时，是否存在监控进程将系统重新启动？n谁来考察系统活动或者性能？n如何发现用例-不同系统边界下的主要参与者和目标如何发现用例nStep4：定义用例为每个用户目标分别定义用例用例名称应该和用户目标类似用户名称应使用动词开头：处理销售n一个例外是：分散的CRUD（创建、提取、更新、删除）合并成一个用例，例如“管理用户”UP制品如何组织需求n需求制品（可选）用例模型n一组使用系统的典型场景。用于功能需求补充性规格说明n用例之外的所有需求，主要用于非功能性需求词汇表n以简单的形式定义重要的术语。包含数据字典设想n高阶需求业务规则n凌驾于某一软件项目的需求或政策关于事件流（关于事件流（Flow of Events）的作用）的作用：当所规约的当所规约的use caseuse case执行时，事件流规约了系统做什么。即执行时，事件流规约了系统做什么。即每一个每一个use caseuse case的事件流，可以作为的事件流，可以作为use caseuse case的动作序列的正文的动作序列的正文描述。描述。当所规约的当所规约的use caseuse case执行时，事件流还规约了系统怎样与其执行时，事件流还规约了系统怎样与其actorsactors进行交互进行交互 基本要求基本要求：从管理的角度来说，一个事件流的描述应包括一组：从管理的角度来说，一个事件流的描述应包括一组动作序列，该组动作序列适于修改、复审、设计、实现和测试，动作序列，该组动作序列适于修改、复审、设计、实现和测试，并作为用户手册的一节。并作为用户手册的一节。有效技有效技术：事件流技：事件流技术 以事件流描述以事件流描述Use Case所采用的结构所采用的结构 一个一个 use case use case 可以被认为有一个开始状态，一些中间可以被认为有一个开始状态，一些中间状态，并从一个状态转换为另一状态，如下所示：状态，并从一个状态转换为另一状态，如下所示：其中，其中，红箭头线表示基本路径，曲线是其它路径。红箭头线表示基本路径，曲线是其它路径。当被一个事件（例如一个消息）激发时，每一这样的转当被一个事件（例如一个消息）激发时，每一这样的转换是该换是该use-caseuse-case的一个实例所执行的一个动作序列。的一个实例所执行的一个动作序列。当当use case use case 描述是：描述是：可理解的；可理解的；正确的（即捕获了正确的需求）；正确的（即捕获了正确的需求）；完备的（完备的（completecomplete，例如，描述了所有可能的路径），例如，描述了所有可能的路径）;一致的一致的.我们才可以说，结束了我们才可以说，结束了use caseuse case的描述。的描述。该描述可以在需求捕获结束的复审会中，由分析员予以评估，该描述可以在需求捕获结束的复审会中，由分析员予以评估，也可以由用户和客户予以评估。但仅客户和用户才能确认该也可以由用户和客户予以评估。但仅客户和用户才能确认该use use casescases是否是正确的。是否是正确的。建造一个建造一个用户界面的原型，使用户有效地执行use casesuse cases。k步骤步骤 第一步，用户界面的逻辑设计第一步，用户界面的逻辑设计 第二步，物理用户界面的设计第二步，物理用户界面的设计 第三步，开发用户界面原型，演示为了执行该第三步，开发用户界面原型，演示为了执行该use use case case，用户怎样使用该系统。，用户怎样使用该系统。注：如何进行以上三步，可参见有关文献。注：如何进行以上三步，可参见有关文献。用用户界面的原型构造界面的原型构造2、需求分析需求分析 实际问题实际问题？需求获取模型需求获取模型形成形成？需求分析模型需求分析模型形成形成需需求求获获取取需需求求分分析析注：实现第二次抽象注：实现第二次抽象注：实现第一次抽象注：实现第一次抽象Boundary classes:内涵内涵：用于系统与其：用于系统与其actors 之间交互的建模。之间交互的建模。该交互一般涉及向用户和外部系统发出请求和从他们那里接该交互一般涉及向用户和外部系统发出请求和从他们那里接 受信息。受信息。与设计平台的关系与设计平台的关系：边界类常常是在更高的概念层上，对：边界类常常是在更高的概念层上，对windows,forms,panes,communication interfaces,printer interfaces,sensors,terminals,and APIs 等的抽象，忽略其中的一些细节，例如：等的抽象，忽略其中的一些细节，例如：every widget of a user interface，并且不需要描述该交互的物理实，并且不需要描述该交互的物理实 现（现（realize）。）。设计原理设计原理：分离用户界面或通讯界面中的变化，形成一个或：分离用户界面或通讯界面中的变化，形成一个或 多个边界类。多个边界类。概念类的种类：通常具有三种：边界类概念类的种类：通常具有三种：边界类（Boundary classes）,实体类实体类（Entity classes），），控制类控制类（Control classes）.实体类（实体类（Entity classes）:内涵内涵：用于对那些需要长期足留系统的模型化对象以及与行为相关的某些：用于对那些需要长期足留系统的模型化对象以及与行为相关的某些 现象进行建模，例如人的信息以及实际的一个事件。现象进行建模，例如人的信息以及实际的一个事件。与业务类的关系与业务类的关系：在大多数情况下，实体类对应业务模型中的业务类。其中一个主要区别在大多数情况下，实体类对应业务模型中的业务类。其中一个主要区别 是：现在所考虑的实体类，一般是要由系统处理的那些对象。是：现在所考虑的实体类，一般是要由系统处理的那些对象。与设计平台的关系与设计平台的关系：实体类一般表示一个逻辑数据结构和属性，以理解系统依赖什么信息。实体类一般表示一个逻辑数据结构和属性，以理解系统依赖什么信息。设计原理设计原理：分离一些变化，形成不同对象所表达的信息。分离一些变化，形成不同对象所表达的信息。控制类（控制类（Control Classes）：）：内涵内涵:控制类处理并协调那些主要动作（控制类处理并协调那些主要动作（actions）和控制流，并向其它对）和控制流，并向其它对 象（例如边界类对象，实体类对象）委派工作。象（例如边界类对象，实体类对象）委派工作。用途用途：控制类可以实现对系统的动态性（：控制类可以实现对系统的动态性（dynamics）建模：）建模：用于表达协同、定序、事务以及对其它对象的控制；用于表达协同、定序、事务以及对其它对象的控制；经常用于封装那些与特定经常用于封装那些与特定 use case 有关的控制；有关的控制；用于表达复杂的推导和计算，例如业务逻辑，该逻用于表达复杂的推导和计算，例如业务逻辑，该逻 辑并不与辑并不与 任意任意 存贮在系统中的特定信息有关。存贮在系统中的特定信息有关。设计原理设计原理：问题分离问题分离 控制类分离一些在控制方面、协调方面、定序方面以及复杂业务逻辑方控制类分离一些在控制方面、协调方面、定序方面以及复杂业务逻辑方面的变化，并予以封装，形成所谓的控制类，其中一般要涉及其他一些对面的变化，并予以封装，形成所谓的控制类，其中一般要涉及其他一些对象。而象。而 不能封装那些与不能封装那些与actors交互有关的问题（由边界类予以封装）。也交互有关的问题（由边界类予以封装）。也不能封装与系统处理的那些信息有关的问题（由实体类予以封装）。不能封装与系统处理的那些信息有关的问题（由实体类予以封装）。可见：可见：边界类边界类 封装了一些重要的通信接口和用户界面机制。封装了一些重要的通信接口和用户界面机制。实体类实体类 封装了问题域中的实体概念封装了问题域中的实体概念 控制类控制类 封装了一些重要的定序（封装了一些重要的定序（sequences），涉及多个），涉及多个 成分，例如协调有意义的成分，例如协调有意义的use-case细化。细化。UP制品关系逻辑架构和层n逻辑架构是软件类的宏观组织结构，它将软件类组织为包（或命名空间）、子系统和层等。n层是对类、包或子系统粗粒度的分组，具有对系统主要方面加以内聚的职责。较高层可以调用较低层的服务。UML包图所表示的层领域层与应用逻辑层n领域层，应用逻辑层包含领域对象，处理应用逻辑的层领域层和领域模型关系层和分区模型-视图分离原则n不要将非UI对象直接与UI对象连接或耦合。不要让Sale软件对象引用Java Swing JFrame窗口对象，因为窗口与某个应用相关，而非窗口对象可以在新应用中重用或者附加到新界面n不要在UI对象方法中加入应用逻辑（如税金的计算）UI对象应该只初始化UI元素、接收UI事件（鼠标点击）、将应用逻辑的请求委派到非UI对象（领域对象）模型-视图分离动机n支持内聚的模型定义，只关注领域过程，而不是用户界面n允许对模型和用户界面层分别进行开发n使界面的需求变更对领域层的影响最小化n允许新视图方便的连接到现有的领域层n允许对同一模型对象使用多个视图，例如销售信息同时具有表格和业务图表视图n允许模型层的运行不依赖于用户界面层系统操作和层p经常不断地学习,你就什么都知道。你知道得越多,你就越有力量pStudyConstantly,AndYouWillKnowEverything.TheMoreYouKnow,TheMorePowerfulYouWillBe写在最后Thank You在别人的演说中思考，在自己的故事里成长Thinking In Other PeopleS Speeches，Growing Up In Your Own Story讲师：XXXXXX XX年XX月XX日