第十八讲 面向对象分析建模过程

对象建模的五个层次

主题层：它相当于高层的模块或子系统 类与对象层：是对问题域概念的抽象，可以从用户 需求或其它规格说明书中找到。 结构层：描述类之间的整体与部分、一般与特殊 的关系。 属性层：它们是类所保存的信息，同时要给出各 个类之间的实例连接。 服务层：它们是类可提供的操作，同时要根据需 要的功能给出各个操作之间的消息连接。

确定属性
通过分析需求陈述初选属性 需求陈述中的名词词组 形容词表示可枚举的具体属性 根据问题域和实现任务确定属性，请教领域专家
选择属性所要注意的问题 误把对象当作属性 误把链属性当作属性 误把限定当作属性 误把对象的内部状态当作属性 过于细化 存在不一致的属性 ATM对象模型中的属性（P235）
三、建立对象模型的一般过程
1.
2. 3. 4. 5. 6.
确定类和对象 确定关联 划分主题 确定属性

可感知的物理实体，设备
人、组织角色或组织单元，如医生、财 务处 需要记忆的事件，如飞行、演出、访问 对象间的相互作用和操作过程，如购买、 纳税等 需要说明的概念，如政策、法规 发挥的作用、地点等
ATM系统正常情况脚本的事件跟踪图（P242）
画状态图
状态图三要素：事件、状态、行为 依据事件跟踪图画状态图 先确定类对象（事件跟踪图中的一条竖线） 仅考虑与所确定对象有关的事件
• 事件跟踪图中指向该对象的水平箭头线，作为状态图中 的有向边，代表这个对象所接受的事件。
通常事件会改变相关对象的状态，为状态赋予一个
设想用户界面（User Interface)
考虑两种交互行为
应用逻辑：内在的、本质的内容，如系统内的信
息流和控制流。 用户界面：系统的外在的表现形式。
用户界面的要求：美观、方便、效率高。 为获得用户的认同，快速建立用户界面原型
ATM界面设想（P241）
画事件跟踪图
确定事件
定义常规行为
最基本的或公认的操作，如读、写类属性的操作，
在分析阶段对这些操作无须显式说明。
从事件导出的操作
接受事件的对象会根据其状态采取相应的行为，
即操作。 ATM对象接受事件“终止”后启动“打印帐单”
与数据流图中处理框对应的操作
数据流图中的每个处理框都与一个或多个对象上

标识结构，确定类和对象的关系


确定属性


定义服务

划分主题
二、需求陈述
需求陈述往往是非形式化的、不完整的、
不准确的。 需求陈述的内容
做什么
问题范围、功能和性能要求、应用环境及假设条
件等。
书写需求陈述的要点 语法正确，语义清晰 认识本质，强调重点 完整、准确、有效 自动取款机（ATM）系统（P226）
指明了目标系统的边界。
画功能级数据流图（P246，图10.13） 描述处理框功能
描述每个处理框代表的功能，不是具体的实现算法 ATM系统中对“更新帐户”的描述（P246）
ATM的基本系统模型图
帐户卡 卡号， 分行代码
ATM系统
储户 密码，金额， 事务类型
结算信息
储户
六、定义服务

直接提取动词短语得出关联 确定隐含的关联 根据问题域知识确定关联
已删除的类之间的关联 与问题无关或应在实现阶段才考虑的关联 瞬时事件 三元关联 派生关联 正名——分解——补充——表明阶数

筛选 （P231）


进一步完善（P232）

划分主题
定义
主题是一组具有较强联系的类组织在一起而
确定类和对象：类与对象的进一步调整

属性不适合于该类

如汽车有乘客数量属性

属性和服务相同的类 属性和服务相似的类 对同一事物的重复描述

人员和身份证

自动取款机（ATM）系统所确定“类与对象”的 过程见P228。注意需求隐含的类与对象“通讯 链路”、“事务日志”
确定关联

初步确定（P230）
的操作对应。
利用继承减少冗余操作
作业
习题十第4题
得到的类的集合。
目的
控制复杂性 易读
主题的表示
主题名称
主题划分的依据

不同主题内的对象间的依赖和交互最小原则。


注意：不是用功能分解方法来确定主题。
对于小型系统可能无须引入主题层。 对于中型系统，由于它所含有的对象较多，一般 先识别类与对象和关联，然后再划分主题。 对于大型系统，先由高级分析员粗略地识别类与 对象和关联，并初步划分主题，但随着对系统的 逐步认识和了解，须进一步修改和精练主题。
对象的三要素（三个子模型）

静态结构——对象模型——WHO

其作用是描述系统的静态结构，包括构成系统的类和对象，
它们的属性和操作，以及它们之间的联系。

交互次序——动态模型——WHEN

其作用是描述系统的控制逻辑，主要涉及系统中各个类和对
象的时序及变化情况。

数据变换——功能模型——WHAT

它着重于描述系统内部数据的传送与处理，它由多个数据流 图组成。
编写脚本
脚本（场景
Scenarios、情景）
指系统在某一执行期间的事件序列。 描述用户、外部设备等与系统间的典型交
互过程。
编写脚本的目的
对目标系统的行为有更具体的认识
防止对重要的交互步骤的遗漏
保证交互过程的正确性和清晰性
编写脚本所注意的问题

脚本编写过程实质上是分析系统交互行为的过程
识别继承关系
目的
利用继承机制共享公共性质 根据归纳关系（一般与特殊）对系统中的类加
以组织
建立继承关系的两种方式
自底向上（归纳过程） 自顶向下（演绎过程）
带有继承关系的ATM对象模型（P237）
反复修改
建模的反复过程
建模过程是一个反复修改、逐步完善的过程。 与问题规模有关。复杂问题需要领域专家的帮助。
第十八讲
面向对象分析建模过程
本讲（第十章 ）的主要内容
一、OO分析的基本过程 二、需求陈述 三、建立对象模型 四、建立动态模型 五、建立功能模型 六、定义服务
一、OO分析的基本过程
OOA就是抽取和整理用户需求并建立问
题域精确模型的过程。
OOA过程可以分为三个步骤：
需求获取 抽象和整理用户需求 建立问题域的精确模型
建模步骤次序因人而异，与经验、能力和实践有关。
对ATM对象模型的修改
由类“现金兑换卡”分解为“卡权限”和“现金兑
换卡” “事务”由“更新”组成 把“分行”与“分行计算机”合并
修改后的ATM对象模型（P221）
四、建立动态模型
编写脚本（Script)
设想用户界面 画事件跟踪图 画状态图 审查动态模型
意义明显的名字。 事件跟踪图中背向该对象的水平箭头线，代表这个 对象达到某个状态时所做的行为。 合并状态图（考虑分支点）应覆盖所有脚本。
ATM
系统中几个类的状态图（P243）
五、建立功能模型
画出基本系统模型（顶层数据流图和用例图）
代表系统与外部的联系。
描述系统加工、数据变换的整体功能。
事件包括系统与用户和外部设备交互的所有信号、
输入、输出、中断、动作等 传递信息的对象的动作也是事件
画事件跟踪图
事件跟踪图实际上是扩充的脚本 事件跟踪图的竖线代表一个类对象；水平箭头线代
表事件，箭头方向从事件的发送对象指向接受对象； 水平箭头线在垂直方向的相应位置表示事件发生的 先后。

确定类与对象：一种非正式的分析方法

把陈述中的名词作为类与对象的候选者
形容词作为确定属性的线索 动词作为服务的候选者 注意需求陈述中隐含的类与对象
确定类和对象：剔除原则
冗余的 无关的 笼统的
有些名词实际上描述的是某个对象的属性
区分操作、公共服务与类定义的名词和动词 暂缓考虑设计和实现阶段的内容
对象建模的步骤

确定类与对象


对问题域概念的抽象 从需求陈述、招标书等中获取 继承关系——整体与部分 聚合关系——一般与特殊（泛化与特化） 识别类与对象所保存的信息 给出各个类与对象之间的实体连接（一对一、一对多等） 即识别操作，并根据功能给出各个操作之间的消息连接 即识别系统的高层模块或子系统


基于需求陈述，多与用户和领域专家交流。
先考虑正常情况，再考虑特殊、出错和异常情况 指明触发事件、接受事件的对象和相应事件的参 数 ATM系统中正常和异常情况脚本（P240）

打电话者拿起电话受话器 电话忙音开始 打电话者拨数字（8） 电话忙音结束 打电话者拨数字（2）…… 打电话者拨数字（3） 接电话者的电话开始振铃 铃声在打电话者的电话上传出 接电话者回答(拿起电话受话器） 接电话者的电话停止振铃 铃声在打电话者的电话中消失 通电话……