第五章：面向对象的方法---RUP

分析类的种类
边界类（Boundary class） 边界类（Boundary class） 实体类（Entity class） 实体类（Entity class） 控制类（Control class） 控制类（Control class）
边界类（Boundary class） 边界类（Boundary class）
RUP的特点 RUP的特点
以体系结构为中心：在系统的生存周期中， 开发的任何阶段都要给出相关模型视角下 有关体系结构的描述 RUP规定的软件开发阶段 RUP规定的软件开发阶段 *初始阶段 *细化阶段 *构造阶段 *移交阶段
RUP的特点 RUP的特点
迭代、增量开发、各阶段的任务
阶 段 精化阶段 构造阶段
体系结构分析任务6 体系结构分析任务6--标识分析包和重要实体类的公 共特定需求
目标：依据需求分析阶段所标识的非功能 需求，针对在分析期间所标识的包和分析 类，标识它们的一些公共的特定需求，比 如：安全性，容错能力等 目的：支持以后的设计和实现，为这些特 定需求开发相应的机制
创建分析模型的主要活动1 创建分析模型的主要活动1
1.
体系结构分析(Architectural 体系结构分析(Architectural Analysis) 目标：通过标识 ⑴分析包 ⑵分析类 ⑶公共的特定需求 建立分析模型和体系结构的”骨架” 建立分析模型和体系结构的”骨架”
体系结构分析任务1---标识分析包 体系结构分析任务1---标识分析包
标识分析包 处理分析包之间的共性 标识服务包 定义分析包的依赖 通过以上的四个任务，就可以形成对体系结 构具有重要影响的分析包的层次结构
分析：系统化的使用信息对系统进行估算，用来定义系统的概念模型— 分析：系统化的使用信息对系统进行估算，用来定义系统的概念模型—有关系统的估算
体系结构分析任务5 体系结构分析任务5--标识重要的实体类
体系结构分析任务2 体系结构分析任务2--处理分析包之间的共性
方法：抽取共享类，然后把共享类放到一 个包中，并让其他报依赖该类或该类所在 的更一般化的包 类：边界类，控制类，实体类 共享类：粒度比较大、具有特定语义的
包的层次结构
体系结构分析任务3---标识服务包 体系结构分析任务3---标识服务包
标识分析包的依据---业务 标识分析包的依据---业务 依据系统用况模型中每一个用况的主要功 能，把用况分派到特定的包中(P138) 能，把用况分派到特定的包中(P138) 在分派的过程中，为了实现高内聚，注意： *一个包中的用况知否支持一个特定的业务过程 *一个包中的用况知否支持一个特定的系统actor 一个包中的用况知否支持一个特定的系统actor *一个包中的用况知否具有泛化和扩展关系
目标：标识在体系结构方面具有重要意义 的实体类
首先，基于需求捕获中标识的领域类和业务实 体，发现其中对体系结构具有意义的类，做为分 析模型中的实体类，以此形成体系结构的初始骨 架。一般情况下，即使比较大的系统，这样的类 也只在10—20个左右，并标识这些实体类之间的 也只在10—20个左右，并标识这些实体类之间的 关联 此时，不需要标识过多的类，也不必了解更多 的细节，因为后来还要对用况进行细化，标识其 中实际需要的实体类时，可能还要重复其中的工 作
实体类（Entity class） 实体类（Entity class）
内涵：用于模型化那些需要长期驻留系统 的对象的对象-例如人的信息，以及与行为相关的 某些现象— 某些现象—例如实际的一个事件 与设计平台的关系：实体类一般表示一个 具有逻辑的数据结构和属性，以理解系统 依赖什么信息 基于的设计原理：分离待处理的不同信息， 形成一些不同的对象 实际上描述的是计算的第一个要素— 实际上描述的是计算的第一个要素—计算 对象
内涵：用于模型和系统和其参与者之间的 交互。该交互一般涉及向用户和外部系统 发出请求和从他们那里接受信息 与设计平台的关系：边界类常常是在更高 的概念层上，对窗口、通信接口、打印机 接口等的抽象，忽略其中的一些细节— 接口等的抽象，忽略其中的一些细节—例 如用户窗口的宽度，并且不需要描述该交 互的物理实现 基于的设计原理：分离不同的用户界面或 者通讯界面，形成一个或者多个边界类
RUP的特点 RUP的特点
以用况为驱动的、以体系结构为中心的迭 代、增量式开发 用况驱动：指在系统的生存周期中，以用 况做为基础、驱动有关人员对所要简历系 统的功能需求进行交流，驱动系统分析、 设计、实现和测试等活动，并将它们有机 的结为一体，使各个阶段中都可以回溯到 用户的实际需求(P124, 用户的实际需求(P124, 图5-2)
初始阶段
移交阶段
分析 内 容 组 织 设计 实现 测试 需求
迭
代
RUP的核心工作流 RUP的核心工作流
需求获取 分析 设计 实现 测试
所包含的活动、活动的输入、输出 所包含的活动、活动的输入、
需求获取— 需求获取—采用用况技术
目标：使用UML中的用况、参与者以及依赖 目标：使用UML中的用况、参与者以及依赖 等术语来抽象客观实际问题，形成系统的 需求获取模型，并产生该模型视角下的体 系结构描述。即从需求的角度，来对系统 系结构描述。即从需求的角度，来对系统 进行概要描述。 进行概要描述。
提供了一种组织分析制品的手段，形成一 些可管理的部分 可包含分析类、用况细化以及其他分析包 课本P136，图5 23----分析包的内容 课本P136，图5-23----分析包的内容
分析模型的表达
分析模型是由一个分析系统定义的，是分 析包的一个层次结构，包含分析类和用况 细化 分析模型中直接包含的分析类和用况细化， 一定是在系统体系结构方面有重要意义的 分析类和用况细化
分析包
提供了一种组织分析制品的手段，形成一 些可管理的部分 可包含分析类、用况细化以及其他分析包
用况细化
内涵：一个用况细化是分析模型中的一个 写作，描述了一个特定的用况是如何运用 分析类以及分析类的交互对象进行细化和 执行 作用：用况细化是对用况模型中的一个特 定的用况提供了一种直接跟踪的方式
分析包
构造用户界面原型 用况模型的结构化
需求分析
分析：系统化的使用信息对系统进行估算， 用来定义系统的概念模型— 用来定义系统的概念模型—有关系统的估 算 目标：在用况模型的基础上，创建系统分 析模型以及在该模型视角下的体系结构描 述 需求分析层的基本术语 。分析类（Analysis class） 。分析类（Analysis class） 。用况细化 。分析包
分析类的种类
边界类（Boundary class） 边界类（Boundary class） 封装与参与者相关的问题 实体类（Entity class） 实体类（Entity class） 封装与系统处理相关的问题 控制类（Control class） 控制类（Control class） 封装不同的系统中不同的处理（即控制）
支持设计模型和实现模型的结构化
*所定义的功能，往往可以做为设计和实现的一个发布单位，因此所表
达的功能可能是系统的内嵌功能
*服务包可独立执行，对伊同一个服务的不同方面，可由系统的2个不同 服务包可独立执行，对伊同一个服务的不同方面，可由系统的2
服务包提供
*服务包之间的依赖，通常是非常受限制的36’’18“ 服务包之间的依赖，通常是非常受限制的36 18“
面向对象方法---RUP 面向对象方法---RUP ---
软件开发方法的组成
用于表达基本信息的术语 组织基本信息的表达格式 在不同抽象层进行映射的过程指导 例如：结构化方法、面向对象方法、面向数 据结构的软件开发方法等
统一软件开发过程---RUP 统一软件开发过程---RUP
RUP： RUP：Rational Unified Process 基于UML 基于UML 完整的定义了将用户需求转换成产品所需 要的活动集，提供了活动的指南以及产生 相关文档的要求
在包的层次结构中，除了考虑以上那种对”共性” 在包的层次结构中，除了考虑以上那种对”共性”的依 赖之外，时常还要考虑服务依赖， 赖之外，时常还要考虑服务依赖，即应用层的包依赖下层提 供的服务包
服务：功能上紧密相关、可被多个用况使用的 一组动作
一个服务的主要特征： *服务是不能分割的，或系统完整提供、或者不提供 服务是不能分割的，或系统完整提供、 *服务是针对客户(Customer)而言，而用况是针对 服务是针对客户(Customer)而言 而言， 用户(User)而言 即当细化一个用况时， 而言， 用户(User)而言，即当细化一个用况时，可能需要 多个服务， 多个服务，即一个用况需要多个不同服务中的动作
捕捉系统语境中的重要 领域对象类 确定用况的优先级 系统的一种概念模型， 系统的一种概念模型，是对系统功能 •业务对象 业务对象 精化用况 的抽象，包括系统参与者、 的抽象，包括系统参与者、系统用况 •实在对象 实在对象 以及他们之间的关系
•业务用况模型 业务用况模型 •业务对象模型 业务对象模型
•事件 事件
体系结构分析任务3---标识服务包 体系结构分析任务3---标识服务包
可见，服务包的引入，可用于系统的结构化 处理，即： 依据服务包所提供的服务，把它放到分析包 层次结构中的低层，以便应用包对它的引用
应用包A 应用包
《依赖》
应用包B 应用包
《依赖》
服务包
当系统功能需求得到了很好的理解并已存在 很多分析类的情况下， 很多分析类的情况下，才能有效地标识服务 包
控制类（Control class） 控制类（Control class）
实际上描述的是计算的第二个要素— 实际上描述的是计算的第二个要素—计算法则 内涵：用于模型化系统的动态性，即系统中的 处理，包括： 。用于表达协同、定序、以及对其他对象的 控制 。用于封装那些与特定用况有关的控制 。用于表达复杂的推导和计算 简言之，控制类处理并协调边界类和实体类对 象的基本动作和控制流，并向他们委派工作
体系结构分析任务3---标识服务包 体系结构分析任务3---标识服务包
服务包的概念：由服务组成的包 服务包的概念：由服务组成的包 服务包的主要特征：
*不可分离，即客户如果需要这一包，就要其中所有的类 *一般只涉及一个参与者或很少几个参与者 *可构成以后设计和实现的一个基本输入，可形成一个服务子系统，以
客观问题(系统 客观问题 系统) 系统
系统的需求获取模型
体系结构描述—用况模型 体系结构描述 用况模型
需求获取—RUP建议开展的工作 需求获取—RUP建议开展的工作
列出候选需求---相关描述 列出候选需求---相关描述 发现并描述Actors 发现并描述 理解系统语境---领域模型或业务模型 理解系统语境---领域模型或业务模型 类 图 用况图 捕获系统功能需求---创建系统用况模型 捕获系统功能需求---创建系统用况模型 发现并描述用况
标识服务包的基本方法
或依据客户对有关服务的要求 或直接将多个功能相关的分析类所提供过的服 务，标识为一个服务包 例如，当： -- 类A的一个变化，可能要求类B的一个变化 的一个变化，可能要求类B -- 把类A拿掉，使类B称为多余的 把类A拿掉，使类B -- 类A的一个对象与类B的一个对象，可能需要以 的一个对象与类B 多个不同的消息发生交互 此时，可将类A和类B 此时，可将类A和类B所提供的服务标识为一个 服务包
体系结构分析任务4-Biblioteka Baidu-标识分析包的依赖 体系结构分析任务4---标识分析包的依赖
目标：发现相对独立的包，实现包的高内 聚和低耦合 途径：通常使用特定应用包和公用包，把 分析模型分为两个层面，清晰地区分特殊 性功能和一般性功能
特定应用层
采购员发票管理
《依赖》 《依赖》
销售员发票管理
账目管理
应用共享层
分析类（Analysis class） 分析类（Analysis class）
一个分析类抽象地表达了系统设计中的一 个或者多个类和/ 个或者多个类和/或子系统 与设计和实现中的类相比，粒度比较大， 是类的一个衍型，很少有操作和特征标记， 其属性和关系也是概念性的。 分析类的基本性质 分析类关注处理功能需求，而将非功能需 求的处理延迟到以后的设计和实现活动中， 并作为类的特殊需求