rup是什么?
统一软件开发过程,对象管理组织(OMG),所推荐有关过程的标准。基于UML的一种过程框架。定义了将用户需求转换成产品所需要的活动集。rup+uml=面向对象方法
软件开发方法学提到的构成方法:
表达基本信息的术语,如前面提到结构化需求分析的基本术语、UML基本术语等
用于组织基本信息的表达格式(UML)
在不同抽象层之间进行“映射”的过程指导,这个指的就是rup1
unified是统一的标准的意思process加工处理。合起来就是,合理的处理标准。
问题:
为什么说rup是一种过程框架呢??
rup主要是软件开发活动集,里面已经规定了开发软件的所需要的所有的活动及次序,如同一个表格,名称,活动概括都已经有了,用户要做的就是往活动概括里面填上自己项目的实际的活动内容就可以。如同rtt架构一般,时序都已经处理好了,只要填自己的项目处理逻辑就可以了。所是rup是一种框架或架构。
rup的特点??
用况驱动,以体系结构为中心,迭代和增量这样开发方式。
用况驱动
在系统生命周期中,以用况为基础,驱动系统有关人员对所要建立系统功能需求进行交流,驱动系统分析、设计、实现和测试活动。
明确需求是至关重要的,写程序时,迟迟不知道怎么写,就是没明白项目使用时的样子,也就是用况。
书中不仅给出了使用时的样子,使用时的样子,可以由分析解决,还有其他用况,如下图所示:
用况细化过程中,可以得到用况所涉及到系统功能的完整描述(也就是上面所说的项目使用时的样子),也得区分出用况的3类事物,系统与参与者之间的接口,实现接口的活动和属性。
可以说,用况驱动了整个软件开发过程,贯穿整个软件开发过程。同时要明白一个重要的事实,活动即映射
体系结构为中心
体系结构是对系统2语义的概括描述。对所有项目相关人员都是可以理解的。关注子系统、构件、接口、协作、关系和节点等重要模型元素,而忽略其他细节。
体系结构为中心的含义为:在系统生存周期中,开发的任何阶段(rup规定4个阶段,初始、细化,构造,移交阶段)都给出相关模型视角下的有关体系结构的描述。如下图所示:
单纯看定义,确实是挺绕,其实是大框架里大标题而矣,如初始阶段下,系统体系结构包含哪些活动,通过这些活动来描述系统要实现什么功能。
相关扩展详见软件考软考考点之软件体系结构知识
迭代
重复的部分
增量
增量:增加的部分
理解迭代与增量还是挺重要的,对以下工作流理解帮助很大。如下图所示:
重复需求,分析等活动,就是迭代,所以下面核心工作流也是按这个方向来的。
四个阶段
初始阶段:获得与特定用况和平台无关的系统体系结构轮廓,确定项目的边界,从业务角度指出该项目的价值
第一个里程碑,生命周期目标里程碑。
细化阶段:分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素
第二个里程碑:生命周期结构里程碑, 基本上项目计划书,就包括前两个阶段内容。
构造阶段:形成最终的系统体系结构基线,开发完整的系统,确保产品可以开始向客户交付
第三个里程碑:初始功能
交付阶段:确保软件对最终用户是可用的。基于用户反馈的少量调整
第四个里程碑:产品发布
核心工作流???
分成了两类,核心过程工作流6个和核心支持工作流3个。书上也没找到到底是哪9个,不过从别的资料找到了
核心工作流:
- 商业建模,描述了如何为新的目标组织开发一个构想,并基于这个构想在商业用况模型和商业对象模型中定义组织的过程,角色和责任
- 需求 ,描述系统应该做什么,并使开发人员和用户就这一描述达成共识。
- 分析和设计
- 实现
- 测试
- 部署,描述了那些与确保软件产品对最终用户具有可用性相关的活动,包括,软件打包,生成软件本身以外的产品,安装软件等
- 配置和变更管理,如何管理并行开发,分布式开发,如何自动化创建工程
- 项目管理,为项目管理提供框架
- 环境,向软件开发组织提供软件开发环境,包括过程和工具。
需求获取
运用用况技术来获取需求。用况模型内容,如下图所示:
包括:业务参与者和业务用况、业务用况模型各种形态(用况参与者之间关系的关联、用况之间的关系的包含和扩展,以及用于表达参与者之间关系的泛化)
用况模型是软件和客户就需求而达成的一个共识,是系统分析、设计、实现以及测试的基本输入。
基本步骤:
- 列出侯选需求:特征列表
- 理解系统语境:领域模型或业务模型
- 捕获功能需求:用况模型
- 捕获非功能需求:补充需求或针对一些特定的用况
列出候选特征:什么是特征?
是一个新的项(Item)及其简要的描述
语境:创建领域模型或业务模型
通过两个层次来抽象一个业务
业务用况模型:
每一个业务用况对应一个业务处理,每一个业务参与者对应一个客户。如下图所示:
业务对象模型:
如下图所示:
三个术语:工作人员、业务实体、工作单元
工作人员,用于表达参于业务处理的各类人员
业务实体,用于表达业务用况中所使用的某一事物。
工作单元:对最终用户而言可形成一个认知整体的实体的集合。用交互图和活动图来表达。
捕获功能需求:
发现并描述参与者
发现并描述用况
确定用况的优先级
精化用况
构造用户界面模型
用况模型的结构化
需求分析
目标:在系统用况模型的基础上,创建系统分析模型以及在该分析模型视角下的体系结构描述。
术语:
分析类:
是类的一种衍型,很少有操作和特征标记,而是用责任来定义其行为,并且其属性和关系也是概念性的。三种不同类型:实体类、边界类和控制类。
边界类
用于规约系统与参与者之间的交互。表示如下:
在应用中,可用边界类来分离不同用户接口或不同通信接口,形成一个或多个边界类
实体类
用于规约那些需要长期驻留在系统中的模型化对象以及行为相关的某些现象。表示如下:
控制类
规约基本的动作和控制流的处理与协调,涉及向其他对象(如边界类对象,实体类对象)
委派工作。表示如下:
用况细化:
是一个协作
针对一个用况,行为可以用多个分析类之间的相互作用细化,并记为用况细化。
分析包:
体现了软件设计原理,“局部化”、“问题分离”
分析包把一些变化限制到一个业务过程,一个参与者的行为或一组紧密相关的用况,形成一些不同的分析包。
体现的是“高内聚、低耦合”,表示如下:
分析模型的表达
三层,如下图所示:
分析模型是由“分析系统”来定义的
分析系统包含一组具有层次结构的包
一个包可以包含一些分析类和用况细化
分析的主要活动
体系结构分析:
标识分析包
处理分析包之间的共性
标识服务包
定义分析包的依赖
标识重要的实体类
标识分析包和重要的实体类的公共特性需求
用况分析:
标识分析类
描述分析类之间的交互
类的分析:
标识责任
标识属性
标识关联和聚合
包的分析
包的分析:
确保分析包尽可能与其他包相对独立
确保分析包实现了它的目标,即细化了某些领域类或用况
描述依赖
总结:
三个术语:分析包,分析类,用况细化
四个步骤:体系结构分析、细化用况、对类分析、对包进行分析
一个成果:分析模型
软件设计
什么是软件设计
定义满足需求规约所需要的软件结构
rup的设计目标:定义满足系统产品分析模型所规约需求的软件结构。
相关术语
设计类:
对系统实现中一个类或类似构造的一个无缝抽象。既然是类,那就包括,操作,属性,关系、方法,还有特殊的,实现需求,是否为主动类。
主动类:
它的对象维护自己的控制线程并与其他主动对象并发运行。
用况细化
是设计模型中的一个协作,其中使用设计类及其对象,描述一个特定用况是如何执行的,可以使用类图、交互图和正文事件流来表达
设计子系统
通过对设计类、用况细化,接口以及其他子系统操作来显示其功能,如下图所示:
与分析模型之间的关系:分析模型中的包结构,一般对应设计子系统的层次结构。如图示:
接口
规约设计类和设计子系统提供的操作。
设计模型、部署模型及相关视角下的体系结构(两个角度)
设计模型
如下图所示:
设计类
用况细化
设计子系统
接口
部署模型
是一个对象模型,描述了系统的物理分布,即如何把功能分布于各个节点上。
设计阶段的主要活动(任务)
体系结构设计:包括
标识节点和它们的网络配置
标识子系统和接口
标识在体系结构方面有意义的设计类和它们的接口
标识一般性的设计机制
用况的设计
标识参与用况细化的设计类
标识参与用况细化的子系统和接口
类的设计
概括描述设计类
标识操作
标识属性
标识关联和聚合
标误用泛化
描述方法
描述状态
子系统的设计
维护子系统依赖
维护子系统所提供的接口
维护子系统的内容
总结:
rup设计特点:
使用了公共的思想来思考设计并使设计可视化
给出了有关子系统、设计类和接口的需求
支持了对底层工作的分解使之成为一些可以由不同开发者可能并行工作。
rup设计方法:
给出表达设计模型的基本成分的术语
规约了设计模型的语法,指导模型的表达
给出了创建设计模型的过程以及相应的指导
rup设计模型:
设计子系统和服务子系统,以及它们的依赖、接口和内容
设计类以及它们具有的操作、属性、关系及其实现需求
用况细化
设计模型视角下的体系结构描述
部署模型:
节点的特征及连接
主动类到节点的初始的映射
rup设计对实现影响
设计子系统和服务子系统由实现子系统予以实现
设计类由文件化构件予以实现
在规划实现工作时,将要使用用况细化以产生一些“构造”
在节点上部署构件、形成分布系统时,将使用部署模型和网络配置。
rup设计模型与分析模型比较
用况模型与分析模型比较
rup实现与测试???
实现目标:
基于设计类和子系统生成构件
进行单元测试
进行集成和连接
可执行的构件映射到部署模型
主要活动:
实现体系结构
集成系统
实现子系统
实现类
完成单元测试
rup的测试:
内部测试、中间测试、最终测试
测试的主要活动:
计划测试
设计测试
实现测试
执行集成测试
执行系统测试
评价测试