UML图详细介绍及软件开发过程ch10_RUP开发过程.pptVIP

UML图详细介绍及软件开发过程ch10_RUP开发过程.ppt

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
本章内容 10.1 RUP模型与特点 10.2 RUP模型元素 10.3 RUP迭代开发 10.4 以架构为中心的过程 10.5 用例驱动的过程 增量是指系统中一个较小的可管理的部分,它们可作为系统构建时可分解功能构造块,每次迭代时可至少产生一个这样的功能构造块。 RUP的解决办法:将多次迭代组织为增量迭代,并分四个阶段和里程碑进行控制。 RUP迭代过程可以组织为如下四个阶段,如下图所示。但这些阶段不同于瀑布方法中的步骤,并不是指需求分析、设计、编码、集成和测试等传统的顺序阶段,这些阶段与传统的阶段互不相关。这里的每个阶段以一个重要里程碑结束。 让我们更详细地研究这4个阶段。 初始阶段 详细说明最终产品的构想及其业务用例并定义项目范围。初始阶段以生命周期目标里程碑结束。 细化阶段 计划必需的活动和需要的资源;详细说明产品特性并设计架构。细化阶段以生命周期架构里程碑结束。 构造阶段 构造产品,逐步完善构想、架构和计划,直到产品已完全准备好移交给它的用户群为止。构造阶段以最初运作能力里程碑结束。 移交阶段 移交产品给用户,这个阶段包括制造、交付、培训、支持及维护产品,直至用户满意为止。移交阶段以产品发布里程碑结束,也是整个周期的结束。 在不同开发阶段中工作流的重点 10.4 以架构为中心的过程 一、什么是架构 RUP有很大一部分内容是关注系统建模。模型帮助我们理解问题并确定解决问题的办法。模型是对现实的简化,它能帮助我们把握整体上不易理解的大型复杂系统。选择用什么模型以及用哪项技术来表示它们,对于我们考虑问题和确定解决方案有着至关重要的影响。但没有任何一个模型能涵盖软件开发的各个方面,所以需要多个模型来表示系统不同的方面。这些模型一定要仔细协调,以确保一致性和无冗余。 光有多个模型表示系统不同的方面是不够的。这好比寓言中的盲人摸象。它们各自都不能把握系统的总体。因此,需要有一个在多个模型基础上的视图来对系统进行总体描述。这样的视图称为架构(或称体系结构) 二、为什么需要架构? 理解系统 组织开发 重用系统 进化系统 三、RUP中的软件架构 与建筑物类似,软件系统需要有多个模型视图(即架构)来描述将构造的系统。下图给出了RUP软件架构的“4+1”视图。 1.逻辑视图 这个架构视图着重描述系统的功能性需求,换句话说,就是描述这个系统能为最终用户做些什么。逻辑视图是设计模型的抽象,确定了主要的设计包、子系统和类。 2.实现视图 这个视图从打包、分层、配置管理(所有权、版本策略等)的角度描述了处于开发环境中的静态软件模块(源代码、数据文件、组件、可执行程序和其他相关的制品)的组织。实现视图着重讨论了如何使开发工作更简易,以及如何管理软件资产、重用、转包合同和现成的组件。 3.进程视图 这个视图表述了系统在运行时的并发性任务、线程、过程及它们之间的交互作用。进程视图讨论了并发性和并行性、系统启动和关机、容错性和对象分布等问题,处理了如死锁、响应时间、吞吐量以及功能和故障的隔离问题等。它主要关注系统的可伸缩性。 4.部署视图 这个视图展示了不同的可执行程序和其他运行时组件是如何映射到底层平台或计算节点上的。这里融合了软件工程和系统工程,讨论了如部署、安装和性能等问题。 5.用例视图 这个视图在架构中扮演了一个很特殊的角色。它包含几个关键场景或者用例。最初,在初始和细化阶段用它们来驱动架构的挖掘和设计,但是后来用它们来验证不同的视图。这几个场景用于说明在软件架构文档中其他视图是如何工作的。 四、模型与架构视图之间的关系 模型是系统的完整表达,而架构视图只关注对于架构来说重要的方面。架构视图好像是从不同模型中切下来的薄片。 对架构来说,重要的元素包括: 主要业务实体类 类的架构机制,如持续性机制和通信机制 模式和框架 层和子系统 接口 主要的过程或控制的线程 五、以架构为中心的过程 当一个团队已经一致认可了一个适合于解决手头问题的架构的表示,那么接下来的问题就是把握架构设计过程。 RUP定义了两个关于架构的主要制品: 软件架构描述,它描述了与项目有关的架构视图。 架构原型,它用于验证架构并作为剩余部分开发的基线。 其他三个制品是: 设计指南,由所做的架构选择决定,反映了模式和习惯用语的使用。 在开发环境中的产品结构,它建立在实现视图的基础之上。 基于实现视图结构的开发团队结构。 RUP定义了一个角色:软件架构师,他负责该架构。但是架构师并不是唯一关心架构的人,大多数开发团队的成员都参与了架构的定义和实现(尤其是在细化

文档评论(0)

好文精选 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档