第十章 OOA
?OOA的基本过程
?需求陈述
?建立对象模型
?建立动态模型
?建立功能模型
?定义服务
OOA过程
? OOA就是抽取和整理用户需求并建
立问题域精确模型的过程。该过程
可以分为三个步骤：
– 需求获取
– 抽象和整理用户需求
– 建立问题域的精确模型
对象的三要素（三个子模型）
? 静态结构 ——对象模型 ——WHO
? 交互次序 ——动态模型 ——WHEN
? 数据变换 ——功能模型 ——WHAT
对象建模的五个层次
? 主题层
? 类与对象层
? 结构层
? 属性层
? 服务层
对象建模的步骤
? 确定类与对象
– 对问题域概念的抽象
– 从需求陈述、招标书等中获取
? 标识结构，确定类和对象的关系
– 继承关系 ——整体与部分
– 聚合关系 ——一般与特殊（泛化与特化）
? 确定属性
– 识别类与对象所保存的信息
– 给出各个类与对象之间的实体连接（一对一、一对多等）
? 定义服务
– 即识别操作，并根据功能给出各个操作之间的消息连接
? 划分主题
– 即识别系统的高层模块或子系统
需求陈述
? 需求陈述往往是非形式化的、不完整的、不准确的。
? 需求陈述的内容
–,做什么”
– 问题范围、功能和性能要求、应用环境及假设条件
等。
? 书写需求陈述的要点
– 语法正确，语义清晰
– 认识本质，强调重点
– 完整、准确、有效
? 例子（ P209）
– 自动取款机（ ATM）系统
OOA—建立对象模型
? 建立 OO模型的一般过程：
– 确定类和对象
– 确定关联
– 划分主题
– 确定属性
– 识别继承关系
– 反复修改和复审
确定类与对象
? 类与对象的发现原则
– 可感知的物理实体，设备
– 人、组织角色或组织单元，如医生、财务处
– 需要记忆的事件，如飞行、演出、访问
– 对象间的相互作用和操作过程，如购买、纳税等
– 需要说明的概念，如政策、法规
– 发挥的作用、地点等
? 一种非正式的分析方法
– 把陈述中的名词作为类与对象的候选者
– 形容词作为确定属性的线索
– 动词作为服务的候选者
? 注意需求陈述中隐含的类与对象
确定类与对象（续）
? 自动取款机（ ATM）系统所确定的
“类与对象”见 P211。
? 注意需求隐含的类与对象“通讯链路”、
“事务日志”
确定类和对象（续）
? 剔除原则
– 冗余的
– 无关的
– 笼统的
– 有些名词实际上描述的是其它对象的属性
– 区分操作、公共服务与类定义的名词和动词
– 暂缓考虑设计阶段的内容
确定类和对象（续）
? 类和对象的进一步调整
– 属性不适合于该类
? 如汽车有乘客数量属性
– 属性和服务相同的类
– 属性和服务相似的类
– 对同一事物的重复描述
? 人员和身份证
? 类的命名
– 使用标准术语
– 使用具有确切含义的名词
– 必要时用名词短语作名词
确定关联
? 初步确定（ P213）
– 直接提取动词短语得出关联
– 确定隐含的关联
– 根据问题域知识确定关联
? 筛选 （ P214）
– 已删除的类之间的关联
– 与问题无关或应在实现阶段才考虑的关联
– 瞬时事件
– 三元关联
– 派生关联
? 进一步完善（ P215）
– 正名 ——分解 ——补充 ——表明阶数
划分主题
? 定义
– 主题是一组具有较强联系的类组织在一起而
得到的类的集合。
? 目的
– 控制复杂性
– 易读
主题的表示
主题名称
划分主题（续）
? 主题的划分的依据
– 不同主题内的对象间的依赖和交互最小原则。
– 注意：不是用功能分解方法来确定主题。
? 对于小型系统可能无须引入主题层。
? 对于中型系统，由于它所含有的对象较多，一般
先识别类与对象和关联，然后再划分主题。
? 对于大型系统，先由高级分析员粗略地识别类与
对象和关联，并初步划分主题，但随着对系统的
逐步认识和了解，须进一步修改和精练主题。
? ATM系统的主题划分（ P216图 10.4）
确定属性
? 初选（分析需求陈述）
– 需求陈述中的名词词组
– 形容词表示可枚举的具体属性
– 根据问题域和实现任务确定属性，请教领域专家。
? 选择
– 误把对象当作属性
– 误把链属性当作属性
– 误把限定当作属性
– 误把对象的内部状态当作属性
– 过于细化
– 存在不一致的属性
? ATM对象模型中的属性（ P218）
识别继承关系
? 目的
– 利用继承机制共享公共性质
– 根据归纳关系（一般与特殊）对系统中的类加以
组织
? 建立继承关系的两种方式
– 自底向上
? 归纳过程
– 自顶向下
? 演绎过程
? 带有继承关系的 ATM对象模型（ P219）
反复修改
? 建模的反复过程
– 建模过程是一个反复修改、逐步完善的过程。
– 建模步骤次序因人而异，与经验、能力和实践有关。
– 与问题规模有关。复杂问题需要领域专家的帮助。
? 对 ATM对象模型的修改
– 由类“现金兑换卡”分解为“卡权限”和“现金兑
换卡”
–,事务”由“更新”组成
– 把“分行”与“分行计算机”合并
? 修改后的 ATM对象模型（ P221）
OOA—建立动态模型
? 编写脚本（ Script)
? 设想用户界面
? 画事件跟踪图
? 画状态图
? 审查动态模型
编写脚本
? 脚本（场景 Scenarios、情景）
– 指系统在某一执行期间的事件序列。
– 描述用户、外部设备等与系统间的典型交
互过程。
? 编写脚本的目的
– 对目标系统的行为有更具体的认识
– 防止对重要的交互步骤的遗漏
– 保证交互过程的正确性和清晰性
编写脚本所注意的问题
? 脚本编写过程实质上是分析系统交互行为的
过程。
? 基于需求陈述，多与 用户和领域专家交流。
? 先考虑正常情况，再特殊、出错和异常情况。
? 指明触发事件、接受事件的对象和相应事件
的参数。
? ATM系统中正常和异常情况脚本（ P222）
设想用户界面（ User Interface)
? 考虑两种交互行为
– 应用逻辑
? 内在的、本质的内容，如系统内的信息流和控制流。
– 用户界面
? 系统的外在的表现形式。
? 用户界面的要求：美观、方便、效率高。
? 为获得用户的认同，快速建立用户界面原型。
? ATM界面设想（ P223）
画事件跟踪图
? 确定事件
– 事件包括系统与用户和外部设备交互的所有信号、
输入、输出、中断、动作等
– 传递信息的对象的动作也是事件
? 画事件跟踪图
– 事件跟踪图实际上是扩充的脚本
– 事件跟踪图的表示
? 竖线代表一个类对象
? 水平箭头线代表事件，箭头方向从事件的发送对象指向
接受对象。
? 水平箭头线在垂直方向的相应位置表示事件发生的先后。
? ATM系统正常情况脚本的事件跟踪图（ P225）
画状态图
? 状态图三要素：事件、状态、行为
? 依据事件跟踪图画状态图
– 先确定类对象（事件跟踪图中的一条竖线，图 10.9）
– 仅考虑与所确定对象有关的事件
? 事件跟踪图中指向该对象的水平箭头线，作为状态图中
的有向边，代表这个对象所接受的 事件 。
– 通常事件会改变相关对象的 状态,为状态赋予一个
意义明显的名字。
– 事件跟踪图中背向该对象的水平箭头线，代表这个
对象达到某个状态时所做的 行为 。
– 合并状态图（考虑分支点）应覆盖所有脚本。
? ATM 系统中几个类的状态图（ P226）
OOA—建立功能模型
? 画出基本系统模型图
– 包含若干个数据源点 /终点，代表系统与外部的
联系。
– 仅含一个处理框，代表系统加工、数据变换的
整体功能。
– 指明了目标系统的边界。
? 画功能级数据流图（ P228，图 10.14）
? 描述处理框功能
– 描述每个处理框代表的功能，不是具体的实现
算法
– ATM系统中对“更新帐户”的描述（ P229）
ATM的基本系统模型图
帐户卡
储户
ATM系统 储户
卡号，
分行代码
密码，金额，
事务类型
结算信息
OOA—定义服务
? 定义常规行为
– 最基本的或公认的操作，如读、写类属性的操作，
在分析阶段对这些操作无须显式说明。
? 从事件导出的操作
– 接受事件的对象会根据其状态采取相应的行为，
即操作。
– ATM对象接受事件“终止”后启动“打印帐单”。
? 与数据流图中处理框对应的操作
– 数据流图中的每个处理框都与一个或多个对象上
的操作对应。
? 利用继承减少冗余操作
作业
习题十第 4题
?OOA的基本过程
?需求陈述
?建立对象模型
?建立动态模型
?建立功能模型
?定义服务
OOA过程
? OOA就是抽取和整理用户需求并建
立问题域精确模型的过程。该过程
可以分为三个步骤：
– 需求获取
– 抽象和整理用户需求
– 建立问题域的精确模型
对象的三要素（三个子模型）
? 静态结构 ——对象模型 ——WHO
? 交互次序 ——动态模型 ——WHEN
? 数据变换 ——功能模型 ——WHAT
对象建模的五个层次
? 主题层
? 类与对象层
? 结构层
? 属性层
? 服务层
对象建模的步骤
? 确定类与对象
– 对问题域概念的抽象
– 从需求陈述、招标书等中获取
? 标识结构，确定类和对象的关系
– 继承关系 ——整体与部分
– 聚合关系 ——一般与特殊（泛化与特化）
? 确定属性
– 识别类与对象所保存的信息
– 给出各个类与对象之间的实体连接（一对一、一对多等）
? 定义服务
– 即识别操作，并根据功能给出各个操作之间的消息连接
? 划分主题
– 即识别系统的高层模块或子系统
需求陈述
? 需求陈述往往是非形式化的、不完整的、不准确的。
? 需求陈述的内容
–,做什么”
– 问题范围、功能和性能要求、应用环境及假设条件
等。
? 书写需求陈述的要点
– 语法正确，语义清晰
– 认识本质，强调重点
– 完整、准确、有效
? 例子（ P209）
– 自动取款机（ ATM）系统
OOA—建立对象模型
? 建立 OO模型的一般过程：
– 确定类和对象
– 确定关联
– 划分主题
– 确定属性
– 识别继承关系
– 反复修改和复审
确定类与对象
? 类与对象的发现原则
– 可感知的物理实体，设备
– 人、组织角色或组织单元，如医生、财务处
– 需要记忆的事件，如飞行、演出、访问
– 对象间的相互作用和操作过程，如购买、纳税等
– 需要说明的概念，如政策、法规
– 发挥的作用、地点等
? 一种非正式的分析方法
– 把陈述中的名词作为类与对象的候选者
– 形容词作为确定属性的线索
– 动词作为服务的候选者
? 注意需求陈述中隐含的类与对象
确定类与对象（续）
? 自动取款机（ ATM）系统所确定的
“类与对象”见 P211。
? 注意需求隐含的类与对象“通讯链路”、
“事务日志”
确定类和对象（续）
? 剔除原则
– 冗余的
– 无关的
– 笼统的
– 有些名词实际上描述的是其它对象的属性
– 区分操作、公共服务与类定义的名词和动词
– 暂缓考虑设计阶段的内容
确定类和对象（续）
? 类和对象的进一步调整
– 属性不适合于该类
? 如汽车有乘客数量属性
– 属性和服务相同的类
– 属性和服务相似的类
– 对同一事物的重复描述
? 人员和身份证
? 类的命名
– 使用标准术语
– 使用具有确切含义的名词
– 必要时用名词短语作名词
确定关联
? 初步确定（ P213）
– 直接提取动词短语得出关联
– 确定隐含的关联
– 根据问题域知识确定关联
? 筛选 （ P214）
– 已删除的类之间的关联
– 与问题无关或应在实现阶段才考虑的关联
– 瞬时事件
– 三元关联
– 派生关联
? 进一步完善（ P215）
– 正名 ——分解 ——补充 ——表明阶数
划分主题
? 定义
– 主题是一组具有较强联系的类组织在一起而
得到的类的集合。
? 目的
– 控制复杂性
– 易读
主题的表示
主题名称
划分主题（续）
? 主题的划分的依据
– 不同主题内的对象间的依赖和交互最小原则。
– 注意：不是用功能分解方法来确定主题。
? 对于小型系统可能无须引入主题层。
? 对于中型系统，由于它所含有的对象较多，一般
先识别类与对象和关联，然后再划分主题。
? 对于大型系统，先由高级分析员粗略地识别类与
对象和关联，并初步划分主题，但随着对系统的
逐步认识和了解，须进一步修改和精练主题。
? ATM系统的主题划分（ P216图 10.4）
确定属性
? 初选（分析需求陈述）
– 需求陈述中的名词词组
– 形容词表示可枚举的具体属性
– 根据问题域和实现任务确定属性，请教领域专家。
? 选择
– 误把对象当作属性
– 误把链属性当作属性
– 误把限定当作属性
– 误把对象的内部状态当作属性
– 过于细化
– 存在不一致的属性
? ATM对象模型中的属性（ P218）
识别继承关系
? 目的
– 利用继承机制共享公共性质
– 根据归纳关系（一般与特殊）对系统中的类加以
组织
? 建立继承关系的两种方式
– 自底向上
? 归纳过程
– 自顶向下
? 演绎过程
? 带有继承关系的 ATM对象模型（ P219）
反复修改
? 建模的反复过程
– 建模过程是一个反复修改、逐步完善的过程。
– 建模步骤次序因人而异，与经验、能力和实践有关。
– 与问题规模有关。复杂问题需要领域专家的帮助。
? 对 ATM对象模型的修改
– 由类“现金兑换卡”分解为“卡权限”和“现金兑
换卡”
–,事务”由“更新”组成
– 把“分行”与“分行计算机”合并
? 修改后的 ATM对象模型（ P221）
OOA—建立动态模型
? 编写脚本（ Script)
? 设想用户界面
? 画事件跟踪图
? 画状态图
? 审查动态模型
编写脚本
? 脚本（场景 Scenarios、情景）
– 指系统在某一执行期间的事件序列。
– 描述用户、外部设备等与系统间的典型交
互过程。
? 编写脚本的目的
– 对目标系统的行为有更具体的认识
– 防止对重要的交互步骤的遗漏
– 保证交互过程的正确性和清晰性
编写脚本所注意的问题
? 脚本编写过程实质上是分析系统交互行为的
过程。
? 基于需求陈述，多与 用户和领域专家交流。
? 先考虑正常情况，再特殊、出错和异常情况。
? 指明触发事件、接受事件的对象和相应事件
的参数。
? ATM系统中正常和异常情况脚本（ P222）
设想用户界面（ User Interface)
? 考虑两种交互行为
– 应用逻辑
? 内在的、本质的内容，如系统内的信息流和控制流。
– 用户界面
? 系统的外在的表现形式。
? 用户界面的要求：美观、方便、效率高。
? 为获得用户的认同，快速建立用户界面原型。
? ATM界面设想（ P223）
画事件跟踪图
? 确定事件
– 事件包括系统与用户和外部设备交互的所有信号、
输入、输出、中断、动作等
– 传递信息的对象的动作也是事件
? 画事件跟踪图
– 事件跟踪图实际上是扩充的脚本
– 事件跟踪图的表示
? 竖线代表一个类对象
? 水平箭头线代表事件，箭头方向从事件的发送对象指向
接受对象。
? 水平箭头线在垂直方向的相应位置表示事件发生的先后。
? ATM系统正常情况脚本的事件跟踪图（ P225）
画状态图
? 状态图三要素：事件、状态、行为
? 依据事件跟踪图画状态图
– 先确定类对象（事件跟踪图中的一条竖线，图 10.9）
– 仅考虑与所确定对象有关的事件
? 事件跟踪图中指向该对象的水平箭头线，作为状态图中
的有向边，代表这个对象所接受的 事件 。
– 通常事件会改变相关对象的 状态,为状态赋予一个
意义明显的名字。
– 事件跟踪图中背向该对象的水平箭头线，代表这个
对象达到某个状态时所做的 行为 。
– 合并状态图（考虑分支点）应覆盖所有脚本。
? ATM 系统中几个类的状态图（ P226）
OOA—建立功能模型
? 画出基本系统模型图
– 包含若干个数据源点 /终点，代表系统与外部的
联系。
– 仅含一个处理框，代表系统加工、数据变换的
整体功能。
– 指明了目标系统的边界。
? 画功能级数据流图（ P228，图 10.14）
? 描述处理框功能
– 描述每个处理框代表的功能，不是具体的实现
算法
– ATM系统中对“更新帐户”的描述（ P229）
ATM的基本系统模型图
帐户卡
储户
ATM系统 储户
卡号，
分行代码
密码，金额，
事务类型
结算信息
OOA—定义服务
? 定义常规行为
– 最基本的或公认的操作，如读、写类属性的操作，
在分析阶段对这些操作无须显式说明。
? 从事件导出的操作
– 接受事件的对象会根据其状态采取相应的行为，
即操作。
– ATM对象接受事件“终止”后启动“打印帐单”。
? 与数据流图中处理框对应的操作
– 数据流图中的每个处理框都与一个或多个对象上
的操作对应。
? 利用继承减少冗余操作
作业
习题十第 4题
