第 二 部分
面向对象的分析
关于软件工程的补充知识
软件危机
硬件性能提高，价格则下降，应用领域迅速扩大；
要求计算机做的事越来越多，也越来越复杂；
这使计算机软件的功能、规模及复杂性与日俱增。
软件的复杂性达到了它的开发者难以控制的程度。
大系统的复杂性是小程序无法比拟的。
当几十个人开发一个大型软件系统时，没有任何人能对它从全局到
细节都了如指掌。各部分的问题错纵复杂，相互影响，不可避免地
隐藏大量错误，并且没有可靠的方法能彻底发现和排除这些错误。
这种情况导致了严重的后果 ——
软件可靠性下降；开发效率低下；维护极为困难。
这使软件开发者陷入困境，人们称之为“软件危机”。
寻求摆脱危机的出路：
程序设计方法学的研究
—— 着眼于程序本身，研究怎样才能写出高质量的
程序。如结构化程序设计方法。
软件工程学的研究
—— 着眼于软件生产的全过程（编程只是其中的一
个阶段），研究用工程学的方法来开发软件。
其它
—— 如并发程序设计、数据结构与算法、以及编程
语言等方面的研究。
软件工程：
软件工程的基本思想，就是用工程学的方法进行软件的开
发与维护，并对软件生产过程进行工程化的管理。
在此之前，软件的生产方式是手工作坊式的。程序员
象是一些个体的手工劳动者，程序设计被当作一种艺
术创造，而不当作是一项工程。这种生产方式只能适
应较小的程序，不能适应大型软件开发。
和其它行业的道理一样，当软件的规模和复杂性达到一定
程度时，即使有大量熟练的程序员也难以胜任它的开发任
务。需要用工程的方法来进行软件生产，这就是软件工程
。
软件生命周期（软件工程理论所揭示的一项规律）
一个软件总是要经历从诞生到死亡的过程，其间需要经过
需求分析、设计、编码、测试、维护 等一系列生存阶段。
需求分析 —— 分析用户需求，研究问题域，搞清楚应该建
立一个什么样的系统才能满足用户的需求。
设计 —— 分为概要设计和详细设计。
概要设计是以需求分析的结果为依据定义系统的主要
构成成分和它们之间的关系。
详细设计是定义每个系统成分内部的构造细节。
编程 —— 按设计的要求来编写程序，并通过调试使之能够
运行。
测试 —— 通过一系列测试用例来检验程序正确性，看它是
否能达到预期的要求。
维护 —— 在系统交付使用之后，根据使用中发现的错误或
用户的需求变化，对软件进行修改。
软件工程的主要内容包括：
针对软件生命周期全过程及其每个具体阶段的 工程方法
、技术细则、文档规范、技术支持、管理制度、人员织
组以及质量保证体系 等。
每个软件开发者必须按工程的统一要求行事，不能随意地自
由发挥。
每个开发阶段都要产生健全的、符合工程规范的文档。
软件产品是这些文档的总合，而不仅仅是程序。
实行软件工程的主要意义：
提高软件产品的质量
提高了软件生产率
软件工程的推行从根本上改变了软件生产中无章可循、各行
其是的混乱局面，并为软件开发从手工生产转向工业化生产
奠定了基础。
软件开发方法：
软件工程所采用的方法不是唯一的。自软件工程出现以来
，人们已经提出了多种软件开发方法，例如：
功能分解法、
数据流法（结构化方法）、
快速原型法、
信息模型法、
面向对象方法。
软件过程模型
描述软件开发过程的各项活动、角色、产品及其相互关系
的模型。 例如：
瀑布模型、螺旋模型、增量模型和喷泉模型等 。
不同的软件开发方法和软件开发模型要求有不同的工程体
系。
从历史看，使用最多的是结构化方法和瀑布模型；
代表当前技术主流的是面向对象方法和喷泉模型。
分析
设计
编程
测试
维护
瀑布模型：
强调严格的
阶段划分和
前后次序
先做完 OOA
再进行 OOD
OOA
OOD
喷泉模型：
各个阶段之
间没有严格
的界限，其
活动可以交
叠和回溯。
演化
集成
测试
编程
设计
分析OOA
OOD
有些工作既可在 OOA中进行，
也可在 OOD中进行。
各阶段概念和表示法的一致为
采用这种模型提供了条件。
面向对象的分析（ OOA），就是运用面向对象方法进行系统
分析。
OOA是分析，是软件生命周期的一个阶段，具有一般分析方
法共同具有的内容、目标及策略；
但强调运用面向对象方法进行分析，用面向对象的概念和
表示法表达分析结果。
基本任务是：运用面向对象方法，对问题域和系统责任进
行分析和理解，找出描述问题域及系统责任所需的对象，
定义对象的属性、服务以及它们之间的关系。
目标是建立一个符合问题域、满足用户需求的 OOA模型。
2.1 什么是面向对象的分析？
第二章 为什么需要 OOA
2.2 分析面临的主要问题
1、问题域和系统责任复杂性日益增长
问题域 （ problem domain）：被开发系统的应用领域，即
在现实世界中由这个系统进行处理的业务范围。
系统责任 （ system responsibilities）：所开发的系统
应该具备的职能。
困难所在：
分析人员，多半不是问题域的专家；问题域专家多半
不是软件专家；
系统所面临的问题域比以往更为广阔和复杂, 系统比
以往更为庞大 。
硬件性能提高价格的下降；编程效率不断提高 。 对需
求分析的压力比其它开发阶段更为巨大 。
2、交流问题
软件工程是非常, 面向人的,,是一项思维活动、思想
交流和人为因素十分密集的工作。
·与用户和领域专家的交流
·分析人员之间的交流
·与用户和领域专家的再交流
·与设计人员的交流
·与管理人员的交流
如果分析所产生的文档使分析员以外的其他人员都很难
读懂, 那就很不利于交流 。 这会使彼此的思想不易沟通,
并容易隐藏许多错误 。
3、需求的不断变化
引起需求变化的因素
用户
客观原因,主观原因
竞争因素
经费
技术因素
软件开发者必须以合作的态度满足用户需求
易变部分和稳定部分：
功能：最易变
外部接口：很易变
属性：较易变
对象：较稳定
4、软件复用的要求
复用级别提高 —— 分析结果复用
一个分析模型中的可复用部分用于多个系统
一个分析模型在多种条件下实现
对分析提出了更高的要求
2.2分析方法综述
功能分解法 （ function decomposition）
功能分解＝ 功能
+子功能
+功能接口
以系统需要提供的功能为中心来组织系统 。
首先定义各种功能, 然后把功能分解为子功能, 同时定
义功能之间的接口 。
对较大的子功能进一步分解, 直到可给出明确的定义 。
根据功能／子功能的需要设计数据结构 。
优点与缺点,
直接地反映用户的需求，所以工作很容易开始。
不能直接地映射问题域，很难检验分析结果的正确性。
对需求变化的适应能力很差。
局部的错误和局部的修改很容易产生全局性的影响。
功能 功能 功能
系统
子功能 子功能
子功能 子功能
分解
分解
分解
……
……
…… ……
工作过程：
一层层地进行功能分解
功能
模块
功能
模块
功能
模块
功能
模块
功能
模块
功能
模块
功能
模块
功能
模块
功能
模块
功能
模块
得到的系统模型：
由模块及其接口构成
数据流法（ data flow approach）
数据流法＝ 数据流＋数据处理（加工）＋数据存储＋端
点＋处理说明＋数据字典
又称作结构化分析。基本策略是跟踪数据流，即研究问题
域中数据如何流动以及在各个环节上进行何种处理，从而
发现数据流和加工。问题域被映射为数据流图（ DFD），
并用处理说明和数据字典进行详细说明。
优点与缺点：
有严格的法则，较强调研究问题域。
仍然是间接映射；
与结构化设计的表示法不一致，而且没有一种严格的、可操作的
转换规则。因此从分析到设计的过渡比较困难；
大系统数据流和加工的数量常常多到难以控制的程度，引起分析
文档的膨胀 。
数据流
加工
数据存储
端点
处理说明
————
————
————
————
————
————
数据词典
————
————
————
————
————
————
信息建模法（ information modeling）
信息建模＝ 实体（对象）＋属性＋关系＋父类型／子类
型＋关联对象
由实体 -关系法（ E-R方法）发展而来。
与数据库设计有很深的渊源。
核心概念是实体和关系。实体描述问题域的事物，含有属性；
关系描述事物之间在数据方面的联系，也可以带有属性。
发展之后的方法也把实体称作对象，并使用了类型和子类型
的概念，作为实体（对象）的抽象描述。
有人也把它列入面向对象方法，但有以下差别：
1.强调的重点是信息建模和状态建模, 而不是对象建模 。
2.没有把对实体属性的操作封装到实体对象中 。
3.只有属性的继承, 不支持服务 （ 操作 ） 的继承 。
4.没有采用消息通讯 。
面向对象的分析
面向对象＝ 对象，类
＋结构与连接
＋继承
＋封装
＋消息通讯
是对问题域中事物的完整映射，包括事物的数据特征和行
为特征。
如实地反映了问题域中事物之间的各种关系，包括分类结
构、组装结构、静态联系和动态联系。
采用封装、继承、消息通讯等原则，使问题域的复杂性得
到控制。
不同的分析方法
—— 对现实世界（问题域）的不同映射
信息建模法 面向对象方法
功能 /子功能
功能接口
功能分解法
数据流
加工
结构化方法
分析方法如何适应面临的挑战？
1,是否有利于对问题及系统责任的理解
要求分析方法采用与问题域一致的概念, 术语及系统成
分, 产生一个较好地映射问题域, 准确反映系统责任的
系统模型 。
2,是否有利于人员之间交流
要求分析方法使用与问题域一致的概念及术语, 尽可能
体现人类的日常思维方式, 使各类人员具有共同语言 。
3,对需求变化的适应性
要求分析方法把系统中最容易变化的因素隔离起来, 并
使系统的各个单元之间接口尽可能少 。 即把需求变化所
引起的影响局部化 。
4,是否支持软件复用
系统模型的基本成分具有完整性 （ 能完整地对应问题域
中的事物 ） 和独立性 （ 与其它成分接口尽量少 ） 。
分析方法的比较
功能分解法
数据流法
信息建模法
OOA
对问题域
和系统责
任的理解
改进交流 适应变化 支持复用
差 差 差最差
差 差较差较差
较好 较好 略好 略好
好 好 好 好
OOA的主要优点
有利于对问题的理解，使系统的复杂性得到控制
采用与问题域一致的概念、术语及系统成分,使系统能较
好地映射问题域，准确反映系统责任。
有利于各类人员之间的交流
使用与问题域一致的概念及术语，体现人类的日常思维方
式，从而使各类人员具有一 种比较易懂的共同语言。
对需求变化的适应性
按封装原则把系统中最容易变化的因素隔离起来, 系统的
各个单元成分之间接口很少, 把需求 变化所引起的影响局
部化 。
封装、继承、聚合等原则，对象的完整性,独立性以及与
问题域的良好对应，使面向对象方法非常有利于软件复用。
支持软件复用
贯穿软件生命周期全过程的一致性
从 OOA开始使用与问题域一致的概念、词汇、原则及表示
法，这种一致性保持到设计、编程、测试、维护等各个阶
段，这对于整个软件生命周期的各种开发、维护及管理活
动都具有重要的意义。
实用性
仅仅数年以前，面向对象的软件开发还被许多人看作一种
理论研究或未来的新技术，现在已经无可置疑地成为一种
实用技术。
国外情况，国内情况。
有利于用户参与
中国的国情 ——用户更希望参与应用系统的开发
对用户而言，学习 OO方法的困难要比其它方法少得多。
—— 先进不等于难学难用
Berard方法
Booch方法
Coad-Yourdon方法
Firesmith方法
Jacobson方法 (OOSE)
Martin-Odell方法
Rumbaugh方法 (OMT)
Seidewitz-Stark方法
Shlaer-Mellor方法
Wirfs-Brock方法
……
不同的 OOA&D方法
方法的异同
体现于：
概念
表示法
系统模型
开发过程
可用性
技术支持
1、概念
多种 OOA方法在概念方面的差别体现在：
概念的取舍不同；同一术语的概念定义不同 （ 往往是
措词不同而涵义相近 ） ；对同一概念使用的术语不同 。
有些 OOA方法不同程度地采用了一些非 OO方法的概念,
这是衡量该方法是不是纯 OO的重要因素 。
2、原则
对于面向对象方法所提倡的原则，各种 OOA方法遵从的程
度有所不同，例如有的方法不体现数据与操作的封装，
有的方法不支持操作的继承。
4,OOA模型
OOA模型即通过面向对象的分析所建立的系统逻辑模型,
它以基本表示法的图形符号为图元, 表达 OOA阶段所认
识的系统成分及彼此之间的关系, 在系统的全局范围内
构成完整的图形表示 。 各种 OOA方法所产生的 OOA模型从
整体形态, 结构框架到具体内容都有较大的差异 。
3,表示法及详细说明规范
各种 OOA方法都提出了一套表示 OO概念并体现 OO原则的图
形表示法 。 此外规定一套建立详细说明的文档规范 。
各种方法的差别体现了采用的概念与原则的不同 。 对相
同的概念, 各种方法采用的表示符号也不尽相同 。
过程模型
对象层
结构层
主题层
属性层
服务层
不同的方法，不同的 OOA模型
Coad-Yourdon方法
动态模型
静态模型
逻辑模型
物理模型
Booch方法
Shlaer-Mellor方法
信息模型
状态模型
Rumbaugh方法 (OMT)
功能模型
5,过程
各种 OOA方法都要规定进行分析工作的具体步骤, 指出
每个步骤应该做什么及如何做, 并给出一些策略与启
发 （ 告诉使用者对各种情况应该怎样处理以及从哪些
方面去思考有助于实现自己的目标 ） 。
各种 OOA方法在概念和模型方面的差别都将在其过程中
反映出来 。 过程的详简也各有差异 。
6,技术支持
一种 OOA方法最终能否被广泛采用, 要看是否能提供必
要的技术支持 。 最重要的技术支持包括,CASE工具,
技术资料 （ 包括书籍 ）, 培训计划等 。
抽象
对象，类
属性
服务
封装
继承
消息
关联
聚合
多态
主动对象
类
属性
服务
一般 -特殊结构
消息连接
实例连接
整体 -部分结构
多态性表示
主动对象类
主题
抽象
分类
行为分析
封装
继承
消息通信
关联
聚合
粒度控制
建模元素基本概念 原则
第三章 本课讲授的 OOA方法概貌
1、概念与表示法
类名
普通对象 主动对象
(a) 类 (b) 属性与服务
一般类
特殊类 特殊类
(c) 一般 -特殊结构
整体对象类
m
n
部分对象类
(d) 整体 -部分结构
类 类m n
(e) 实例连接
发送者 接收者
(f) 消息连接
编号 主题名
压缩方式
编号 主题名
类名
······
半展开方式
编号
编号
编号
编号
展开方式
(g) 主题的三种表示方式
表示法
＠类名
(控制线程内 )
(控制线程间 )
类名
普通对象 主动对象
＠类名
＠服务
...
属性
...
服务
...
属性
...
2,OOA的主要原则
（ 1）抽象
过程抽象
任何一个完成确定功能的操作序列，其使用者都
可把它看作一个单一的实体，尽管实际上它可能
是由一系列更低级的操作完成的。
数据抽象
根据施加于数据之上的操作来定义数据类型，并
限定数据的值只能由这些操作来修改和观察。
（ 2）封装
（ 3）继承
（ 4）分类
把具有相同属性和服务的对象划分为一类，用类作为
这些对象的抽象描述。
（ 5） 聚合
（ 6） 关联
（ 7） 消息通信
即要求对象之间只能通过消息进行通讯, 而不允许
在对象之外直接地存取对象内部的属性 。
（ 8）粒度控制
引入主题（ subject）的概念，使模型具有大小不
同的粒度层次，以利于控制复杂性。
（ 9）行为分析
关系层
特征层
对象层
基本模型 (类图 )
交
互
图
主
题
图
详 细 说 明
给出所有与问题
域和系统责任有
关的对象，用对
象类表示
定义每个对
象类的属性
与服务
通过结构与连
接描述对象之
间的关系 对模型中的所有元
素进行详
细说明
对关系密
切的类打
包，帮助
理解类图
一幅交互图表现完成某一
项特定功能的一组对象之
间的详细交互。每一项功
能用一个 use case描述
3,OOA模型
4,OOA过程
发现对象
定义属性与服务
建立结构与连接
划分主题
建立交互图
详
细
说
明
定义 USE CASE
原
型
开
发
定义 use case（辅助模型，可选）
用 use case对用户需求进行规范化描述。
建立类图（基本模型）
* 发现对象、定义对象类
* 识别对象的内部特征
* 识别对象的外部关系
划分主题，建立主题图（辅助模型，
可选）
建立交互图 （辅助模型，可选）
对照 use case，描述一组对象
进行协作时的交互情况和消息
的时序关系。
原型开发
结合其他活动反复进行
建立详细说明
对模型中的成分
进行规范的定义
和文字说明。可
以集中进行，也
可分散在各个活
动中。
5,OOA与生命周期其它阶段的关系
OOA与 OOD可适合不同的生命周期模型
分析
设计
编程
测试
维护
瀑布模型：
强调严格的
阶段划分和
前后次序
先做完 OOA
再进行 OOD
OOA
OOD
喷泉模型：
各个阶段之
间没有严格
的界限，其
活动可以交
叠和回溯。
演化
集成
测试
编程
设计
分析OOA
OOD
有些工作既可在 OOA中进行，
也可在 OOD中进行。
各阶段概念和表示法的一致为
采用这种模型提供了条件。
OOA OOD OOP 最好
OOA OOD 用非 OO语言编程 可以从 OO获益
非 OO的分
析与设计 OOD OOP 没有多大意义
从分析、设计到编程
概念：对象、主动对象 以及它们的类
对象,是系统中用来描述客观事物的一个实体，它是构成系统的
一个基本单位。一个对象由一组属性和对这组属性进行操作的一
组服务构成。
类,具有相同属性和服务的一组对象的集合，它为属于该类的全
部对象提供了统一的抽象描述，其内部包括属性和服务两个主要
部分。
类和对象的关系 —— 模板与实例
主动对象 (active object),至少有一个服务不需要接收消息就能主
动执行的对象，用于描述具有主动行为的事物。
主动对象的类叫做主动类。
从事物的主动行为认识主动对象；
从系统的执行认识主动对象。
第四章 发现对象，建立对象类
类 名
普通对象 主动对象
@ 类 名
表示法,在 OOA模型 中，用类描述属于它的全部对象实例，
用类符号来表示。
在尚未确定是不是主动对象之前，暂时用普通对象的类符号表示。
研究用户需求，明确系统责任
阅读：阅读一切与用户需求有关的书面材料
交流：与用户交流，澄清疑点，
纠正用户不切实的要求或不确切的表达
调查：到现场调查（只限于澄清需求）
记录、整理：产生一份符合工程规范、确切表达系统责
任的需求文档
研究问题域
亲临现场调查，掌握第一手资料
听取问题域专家的见解
阅读与问题域有关的材料
借鉴相同或类似问题域已有的系统开发经验及文档
确定系统边界
系统边界：系统与外部世界的界限
活动者：在系统边界以外，与系统进行交互的事物
—— 人员、设备、外系统
活动者 (人员 )
活动者 (设备 )
活动者 (外系统 )
系统边界
系统、系统边界及活动者
对
象
对象
对象 对象
对象
系 统
对象
认识系统边
界与活动者
，对发现主
动对象、定
义 use case有
重要意义。
策略与启发
（ 1）考虑问题域：
人员 组织 物品 设备
事件 表格 结构,.,
（ 2）考虑系统边界：
人员 设备 外系统
从不同的角
度考虑人员
和设备
（ 3）考虑系统责任：
检查每一项功能需求是否有相应的对象提供，发现新的对象
审查与筛选
（ 1）舍弃无用的对象
通过属性判断：
是否通过属性记录了某些有用的信息？
通过服务判断：
是否通过服务提供了某些有用的功能？
二者都不是 —— 无用
（ 2）对象的精简
只有一个属性的对象
只有一个服务的对象
班级
……
……
班主任
姓名1 1
班级
班主任姓名
……
……
输出设备
……
……
格式转换器
文件格式转换
输出设备
……
文件格式转换
……
（ 3）与实现条件有关的对象
例如：与
图形用户界面（ GUI）系统、
数据管理系统、
硬件 及
操作系统有关的对象
—— 推迟到 OOD考虑
识别主动对象
（ 1）考虑问题域和系统责任
哪些对象需呈现主动行为？
（ 2）从需求考虑系统的执行情况
是否需要并发执行？
控制线程的起点在哪个对象？
（ 3）考虑系统边界
哪些对象与活动者交互？
如果一个交互是由活动者发起的，
第一个处理该交互的对象是主动对象
在分析阶段
不能完全确定
对象分类
（ 1）异常情况的检查和调整
*类的属性或服务不适合全部对象实例
例：“汽车”类的“乘客限量”属性
问题：分类不够详细
—— 进一步划分特殊类
*属性及服务相同的类
经过抽象，差别很大的事物可能只保留相同的特征
—— 考虑能否合并为一个类
*属性及服务相似的类
—— 考虑能否提升出一个一般类
*同一事物的重复描述
例：“职员”和“工作证”
—— 取消其中一个
（ 2）类的命名
*使用名词，避免无意义的符号
*反映个体而不是群体
*适合该类及其特殊类的全部对象实例
*使用问题域通用、规范的词汇
*在中国：可用中、英文双重命名
（ 3）建立类图的对象层
*用类符号表示每个对象类
*填写类描述模板
*发现的属性与服务、结构与连接
可以随时加到类符号中
属性 —— 实例属性、类属性，
服务 —— 主动服务、被动服务
表示法：
类 名
普通对象 主动对象
属性 1
···
属性 n
服务 1
···
服务 m
@类 名
属性 1
···
属性 n
服务 1
···
@服务 m
第五章 定义属性与服务
概念：
定义属性
（ 1）策略与启发
*按常识这个对象应该有哪些属性？
*在当前的问题域中，对象应该有哪些属性？
*根据系统责任，这个对象应具有哪些属性？
*建立这个对象是为了保存和管理哪些信息？
*对象为了完成其功能，需要增设哪些属性？
*对象是否需要通过专设的属性区别其状态？
*用什么属性表示整体 -部分结构和实例连接？
（ 2）审查与筛选
*是否体现了以系统责任为目标的抽象
（例：书的重量）？
*是否描述对象本身的特征
（例：课程 — 电话号码）？
*是否破坏“原子性”
（例：通信地址）？
*是否可通过继承得到？
*是否可从其他属性直接导出？
（ 3）推迟到 OOD考虑的问题
*规范化问题
*对象标识
*性能问题
（ 4）属性的命名与定位
命名：原则与类的命名相同
定位：针对所描述的对象，适合全部对象实例
（ 5）属性的详细说明
*文字解释
*数据类型
*实现要求及其它
定义服务
问题讨论：什么是对象的状态？
关于对象状态的不同解释
状态 = 属性
只是一个别名，没有更多的意义
状态 = 属性值
没错，但没有必要辨别这么多状态
,对象技术词典, 的另一种定义：
对象或者类的整体行为（例如响应消息）的某些规则
所能适应的（对象或类的）状况、情况、条件、形式
或生存周期阶段。
—— 从属性值的等价类看问题
例 1：一个容量为 1000的栈，需要区分几种状态？
空 半满 满
压入
弹出
可执行 可执行
可执行 可执行
不可执行
不可执行
服务 状态
例 2：为“设备”对象设立一个属性，名为“状态”
属性值：关闭、待命、运行、故障等。
在此例中,每一种状态是一组使对象呈现共同行为规
则的属性值组合。
在这里，“状态”是一个专门设置的属性，它的值
反映了实际事物的状态。
状态转换图（ STD）
空
半满
满
创建
弹出 <报错 >
弹出 (已空 )
压入
压入 (未满 )
弹出 (未空 ) 压入 (已满 )
弹出
压入 <报错 >
作用：帮助分析对象的行为、定义对象的服务
一个 STD一般只针对一个（或少数几个对象），
在实际系统中，无法建立全系统的 STD。
—— 不宜作为系统级的模型
对象行为分类
（ 1）系统行为
例：创建、删除、复制、转存
（ 2）对象自身的行为 —— 算法简单的服务
例：读、写属性值
（ 3）对象自身的行为 —— 算法复杂的服务
计算或监控
（ 1）考虑系统责任
有哪些功能要求在并对象提供？
（ 2）考虑问题域
对象在问题域对应的事物有哪些行为？
（ 3）分析对象状态
对象状态的转换，是由哪些服务引起的？
（ 4）追踪服务的执行路线
模拟服务的执行，并在整个系统中跟踪
策略与启发
审查对象的每个服务
是否真正有用
是否直接提供系统责任所要求的某项功能？
或者
响应其它服务的请求间接地完成这种功能的
某些局部操作？
调整 —— 取消无用的服务
是不是高内聚的
一个服务只完成一项 单一的, 完整的 功能
调整 —— 拆分 或 合并
审查与调整
（ 1）考虑问题域
对象行为是被引发的，还是主动呈现的？
（ 2）与活动者交互的对象服务
认识对象的主动行为
操作界面
报警器监控
操作界面
打印机驱动器
（ 3）完成最外层功能的对象服务
（ 4）服务执行路线逆向追踪
操作界面
打印机驱动器
命名：动词或动宾结构
定位：
与实际事物一致
例：售货员 —— 售货，商品 —— 售出
在一般 -特殊结构中的位置
—— 适合类的全部对象实例
服务的命名和定位
*服务解释
*消息协议
*消息发送
*约束条件
*服务流程图
yes no
陈述框。
判断框
连线，用于连接各个框，
指出执行时的控制流。
入口 /出口标记，指出服
务的开始或结束。
问题：分析阶段为什么要给出服务流程图？
关于 OOA/OOD分工的两种不同观点；
对一种操作过程的说明，可详可简，
但更难区分“做什么”和“怎么做”
服务的详细说明
例题：超级市场销售管理系统
超级市场业务管理系统的子系统，只负责前台的销售管理
功能需求：
·为顾客选购的商品计价, 收费, 打印清单 。
·记录每一种商品的编号, 单价及现有数量 。
·帮助供货员发现哪些商品将要脱销, 以及时补充货源 。
·随时按上级系统的要求报告当前的款货数量, 增减商品种类或修
改商品定价 。
·交接班时结算货款数目, 报告上级系统 。
发现对象：
收款机、供货员、上级系统接口、商品、特价商品、
计量商品、商品一览表、销售事件、帐册
问题：
为什么没有“收款员”和“经理”这两类对象？
帐 册
商品一览表
销售事件
@上级系统接口
@收款机
供货员
商 品
计量商品特价商品
帐 册
商品一览表
销售事件
@收款机
供货员
商品
计量商品特价商品
本班收款员
开始时间
结束时间
@登录
售货
结帐
前班结余
销售事件表
收入累计
上交款
本班结余
···接班
记帐
报帐交班
收款人
购物清单
应收款
···
销售计价
入帐
商品目录
检索
种类增删
@上级系统接口
帐册目录
@消息收发
查账
报帐
价格更新
种类增删
编号
名称
单价
架上数量
下限
售出
补充
价格更新
缺货登记表
缺货登记
供货
开始日期
结束日期
* 单价
计量单位
计价方式
* 售出
* 补充
* 价格更新
面向对象的分析
关于软件工程的补充知识
软件危机
硬件性能提高，价格则下降，应用领域迅速扩大；
要求计算机做的事越来越多，也越来越复杂；
这使计算机软件的功能、规模及复杂性与日俱增。
软件的复杂性达到了它的开发者难以控制的程度。
大系统的复杂性是小程序无法比拟的。
当几十个人开发一个大型软件系统时，没有任何人能对它从全局到
细节都了如指掌。各部分的问题错纵复杂，相互影响，不可避免地
隐藏大量错误，并且没有可靠的方法能彻底发现和排除这些错误。
这种情况导致了严重的后果 ——
软件可靠性下降；开发效率低下；维护极为困难。
这使软件开发者陷入困境，人们称之为“软件危机”。
寻求摆脱危机的出路：
程序设计方法学的研究
—— 着眼于程序本身，研究怎样才能写出高质量的
程序。如结构化程序设计方法。
软件工程学的研究
—— 着眼于软件生产的全过程（编程只是其中的一
个阶段），研究用工程学的方法来开发软件。
其它
—— 如并发程序设计、数据结构与算法、以及编程
语言等方面的研究。
软件工程：
软件工程的基本思想，就是用工程学的方法进行软件的开
发与维护，并对软件生产过程进行工程化的管理。
在此之前，软件的生产方式是手工作坊式的。程序员
象是一些个体的手工劳动者，程序设计被当作一种艺
术创造，而不当作是一项工程。这种生产方式只能适
应较小的程序，不能适应大型软件开发。
和其它行业的道理一样，当软件的规模和复杂性达到一定
程度时，即使有大量熟练的程序员也难以胜任它的开发任
务。需要用工程的方法来进行软件生产，这就是软件工程
。
软件生命周期（软件工程理论所揭示的一项规律）
一个软件总是要经历从诞生到死亡的过程，其间需要经过
需求分析、设计、编码、测试、维护 等一系列生存阶段。
需求分析 —— 分析用户需求，研究问题域，搞清楚应该建
立一个什么样的系统才能满足用户的需求。
设计 —— 分为概要设计和详细设计。
概要设计是以需求分析的结果为依据定义系统的主要
构成成分和它们之间的关系。
详细设计是定义每个系统成分内部的构造细节。
编程 —— 按设计的要求来编写程序，并通过调试使之能够
运行。
测试 —— 通过一系列测试用例来检验程序正确性，看它是
否能达到预期的要求。
维护 —— 在系统交付使用之后，根据使用中发现的错误或
用户的需求变化，对软件进行修改。
软件工程的主要内容包括：
针对软件生命周期全过程及其每个具体阶段的 工程方法
、技术细则、文档规范、技术支持、管理制度、人员织
组以及质量保证体系 等。
每个软件开发者必须按工程的统一要求行事，不能随意地自
由发挥。
每个开发阶段都要产生健全的、符合工程规范的文档。
软件产品是这些文档的总合，而不仅仅是程序。
实行软件工程的主要意义：
提高软件产品的质量
提高了软件生产率
软件工程的推行从根本上改变了软件生产中无章可循、各行
其是的混乱局面，并为软件开发从手工生产转向工业化生产
奠定了基础。
软件开发方法：
软件工程所采用的方法不是唯一的。自软件工程出现以来
，人们已经提出了多种软件开发方法，例如：
功能分解法、
数据流法（结构化方法）、
快速原型法、
信息模型法、
面向对象方法。
软件过程模型
描述软件开发过程的各项活动、角色、产品及其相互关系
的模型。 例如：
瀑布模型、螺旋模型、增量模型和喷泉模型等 。
不同的软件开发方法和软件开发模型要求有不同的工程体
系。
从历史看，使用最多的是结构化方法和瀑布模型；
代表当前技术主流的是面向对象方法和喷泉模型。
分析
设计
编程
测试
维护
瀑布模型：
强调严格的
阶段划分和
前后次序
先做完 OOA
再进行 OOD
OOA
OOD
喷泉模型：
各个阶段之
间没有严格
的界限，其
活动可以交
叠和回溯。
演化
集成
测试
编程
设计
分析OOA
OOD
有些工作既可在 OOA中进行，
也可在 OOD中进行。
各阶段概念和表示法的一致为
采用这种模型提供了条件。
面向对象的分析（ OOA），就是运用面向对象方法进行系统
分析。
OOA是分析，是软件生命周期的一个阶段，具有一般分析方
法共同具有的内容、目标及策略；
但强调运用面向对象方法进行分析，用面向对象的概念和
表示法表达分析结果。
基本任务是：运用面向对象方法，对问题域和系统责任进
行分析和理解，找出描述问题域及系统责任所需的对象，
定义对象的属性、服务以及它们之间的关系。
目标是建立一个符合问题域、满足用户需求的 OOA模型。
2.1 什么是面向对象的分析？
第二章 为什么需要 OOA
2.2 分析面临的主要问题
1、问题域和系统责任复杂性日益增长
问题域 （ problem domain）：被开发系统的应用领域，即
在现实世界中由这个系统进行处理的业务范围。
系统责任 （ system responsibilities）：所开发的系统
应该具备的职能。
困难所在：
分析人员，多半不是问题域的专家；问题域专家多半
不是软件专家；
系统所面临的问题域比以往更为广阔和复杂, 系统比
以往更为庞大 。
硬件性能提高价格的下降；编程效率不断提高 。 对需
求分析的压力比其它开发阶段更为巨大 。
2、交流问题
软件工程是非常, 面向人的,,是一项思维活动、思想
交流和人为因素十分密集的工作。
·与用户和领域专家的交流
·分析人员之间的交流
·与用户和领域专家的再交流
·与设计人员的交流
·与管理人员的交流
如果分析所产生的文档使分析员以外的其他人员都很难
读懂, 那就很不利于交流 。 这会使彼此的思想不易沟通,
并容易隐藏许多错误 。
3、需求的不断变化
引起需求变化的因素
用户
客观原因,主观原因
竞争因素
经费
技术因素
软件开发者必须以合作的态度满足用户需求
易变部分和稳定部分：
功能：最易变
外部接口：很易变
属性：较易变
对象：较稳定
4、软件复用的要求
复用级别提高 —— 分析结果复用
一个分析模型中的可复用部分用于多个系统
一个分析模型在多种条件下实现
对分析提出了更高的要求
2.2分析方法综述
功能分解法 （ function decomposition）
功能分解＝ 功能
+子功能
+功能接口
以系统需要提供的功能为中心来组织系统 。
首先定义各种功能, 然后把功能分解为子功能, 同时定
义功能之间的接口 。
对较大的子功能进一步分解, 直到可给出明确的定义 。
根据功能／子功能的需要设计数据结构 。
优点与缺点,
直接地反映用户的需求，所以工作很容易开始。
不能直接地映射问题域，很难检验分析结果的正确性。
对需求变化的适应能力很差。
局部的错误和局部的修改很容易产生全局性的影响。
功能 功能 功能
系统
子功能 子功能
子功能 子功能
分解
分解
分解
……
……
…… ……
工作过程：
一层层地进行功能分解
功能
模块
功能
模块
功能
模块
功能
模块
功能
模块
功能
模块
功能
模块
功能
模块
功能
模块
功能
模块
得到的系统模型：
由模块及其接口构成
数据流法（ data flow approach）
数据流法＝ 数据流＋数据处理（加工）＋数据存储＋端
点＋处理说明＋数据字典
又称作结构化分析。基本策略是跟踪数据流，即研究问题
域中数据如何流动以及在各个环节上进行何种处理，从而
发现数据流和加工。问题域被映射为数据流图（ DFD），
并用处理说明和数据字典进行详细说明。
优点与缺点：
有严格的法则，较强调研究问题域。
仍然是间接映射；
与结构化设计的表示法不一致，而且没有一种严格的、可操作的
转换规则。因此从分析到设计的过渡比较困难；
大系统数据流和加工的数量常常多到难以控制的程度，引起分析
文档的膨胀 。
数据流
加工
数据存储
端点
处理说明
————
————
————
————
————
————
数据词典
————
————
————
————
————
————
信息建模法（ information modeling）
信息建模＝ 实体（对象）＋属性＋关系＋父类型／子类
型＋关联对象
由实体 -关系法（ E-R方法）发展而来。
与数据库设计有很深的渊源。
核心概念是实体和关系。实体描述问题域的事物，含有属性；
关系描述事物之间在数据方面的联系，也可以带有属性。
发展之后的方法也把实体称作对象，并使用了类型和子类型
的概念，作为实体（对象）的抽象描述。
有人也把它列入面向对象方法，但有以下差别：
1.强调的重点是信息建模和状态建模, 而不是对象建模 。
2.没有把对实体属性的操作封装到实体对象中 。
3.只有属性的继承, 不支持服务 （ 操作 ） 的继承 。
4.没有采用消息通讯 。
面向对象的分析
面向对象＝ 对象，类
＋结构与连接
＋继承
＋封装
＋消息通讯
是对问题域中事物的完整映射，包括事物的数据特征和行
为特征。
如实地反映了问题域中事物之间的各种关系，包括分类结
构、组装结构、静态联系和动态联系。
采用封装、继承、消息通讯等原则，使问题域的复杂性得
到控制。
不同的分析方法
—— 对现实世界（问题域）的不同映射
信息建模法 面向对象方法
功能 /子功能
功能接口
功能分解法
数据流
加工
结构化方法
分析方法如何适应面临的挑战？
1,是否有利于对问题及系统责任的理解
要求分析方法采用与问题域一致的概念, 术语及系统成
分, 产生一个较好地映射问题域, 准确反映系统责任的
系统模型 。
2,是否有利于人员之间交流
要求分析方法使用与问题域一致的概念及术语, 尽可能
体现人类的日常思维方式, 使各类人员具有共同语言 。
3,对需求变化的适应性
要求分析方法把系统中最容易变化的因素隔离起来, 并
使系统的各个单元之间接口尽可能少 。 即把需求变化所
引起的影响局部化 。
4,是否支持软件复用
系统模型的基本成分具有完整性 （ 能完整地对应问题域
中的事物 ） 和独立性 （ 与其它成分接口尽量少 ） 。
分析方法的比较
功能分解法
数据流法
信息建模法
OOA
对问题域
和系统责
任的理解
改进交流 适应变化 支持复用
差 差 差最差
差 差较差较差
较好 较好 略好 略好
好 好 好 好
OOA的主要优点
有利于对问题的理解，使系统的复杂性得到控制
采用与问题域一致的概念、术语及系统成分,使系统能较
好地映射问题域，准确反映系统责任。
有利于各类人员之间的交流
使用与问题域一致的概念及术语，体现人类的日常思维方
式，从而使各类人员具有一 种比较易懂的共同语言。
对需求变化的适应性
按封装原则把系统中最容易变化的因素隔离起来, 系统的
各个单元成分之间接口很少, 把需求 变化所引起的影响局
部化 。
封装、继承、聚合等原则，对象的完整性,独立性以及与
问题域的良好对应，使面向对象方法非常有利于软件复用。
支持软件复用
贯穿软件生命周期全过程的一致性
从 OOA开始使用与问题域一致的概念、词汇、原则及表示
法，这种一致性保持到设计、编程、测试、维护等各个阶
段，这对于整个软件生命周期的各种开发、维护及管理活
动都具有重要的意义。
实用性
仅仅数年以前，面向对象的软件开发还被许多人看作一种
理论研究或未来的新技术，现在已经无可置疑地成为一种
实用技术。
国外情况，国内情况。
有利于用户参与
中国的国情 ——用户更希望参与应用系统的开发
对用户而言，学习 OO方法的困难要比其它方法少得多。
—— 先进不等于难学难用
Berard方法
Booch方法
Coad-Yourdon方法
Firesmith方法
Jacobson方法 (OOSE)
Martin-Odell方法
Rumbaugh方法 (OMT)
Seidewitz-Stark方法
Shlaer-Mellor方法
Wirfs-Brock方法
……
不同的 OOA&D方法
方法的异同
体现于：
概念
表示法
系统模型
开发过程
可用性
技术支持
1、概念
多种 OOA方法在概念方面的差别体现在：
概念的取舍不同；同一术语的概念定义不同 （ 往往是
措词不同而涵义相近 ） ；对同一概念使用的术语不同 。
有些 OOA方法不同程度地采用了一些非 OO方法的概念,
这是衡量该方法是不是纯 OO的重要因素 。
2、原则
对于面向对象方法所提倡的原则，各种 OOA方法遵从的程
度有所不同，例如有的方法不体现数据与操作的封装，
有的方法不支持操作的继承。
4,OOA模型
OOA模型即通过面向对象的分析所建立的系统逻辑模型,
它以基本表示法的图形符号为图元, 表达 OOA阶段所认
识的系统成分及彼此之间的关系, 在系统的全局范围内
构成完整的图形表示 。 各种 OOA方法所产生的 OOA模型从
整体形态, 结构框架到具体内容都有较大的差异 。
3,表示法及详细说明规范
各种 OOA方法都提出了一套表示 OO概念并体现 OO原则的图
形表示法 。 此外规定一套建立详细说明的文档规范 。
各种方法的差别体现了采用的概念与原则的不同 。 对相
同的概念, 各种方法采用的表示符号也不尽相同 。
过程模型
对象层
结构层
主题层
属性层
服务层
不同的方法，不同的 OOA模型
Coad-Yourdon方法
动态模型
静态模型
逻辑模型
物理模型
Booch方法
Shlaer-Mellor方法
信息模型
状态模型
Rumbaugh方法 (OMT)
功能模型
5,过程
各种 OOA方法都要规定进行分析工作的具体步骤, 指出
每个步骤应该做什么及如何做, 并给出一些策略与启
发 （ 告诉使用者对各种情况应该怎样处理以及从哪些
方面去思考有助于实现自己的目标 ） 。
各种 OOA方法在概念和模型方面的差别都将在其过程中
反映出来 。 过程的详简也各有差异 。
6,技术支持
一种 OOA方法最终能否被广泛采用, 要看是否能提供必
要的技术支持 。 最重要的技术支持包括,CASE工具,
技术资料 （ 包括书籍 ）, 培训计划等 。
抽象
对象，类
属性
服务
封装
继承
消息
关联
聚合
多态
主动对象
类
属性
服务
一般 -特殊结构
消息连接
实例连接
整体 -部分结构
多态性表示
主动对象类
主题
抽象
分类
行为分析
封装
继承
消息通信
关联
聚合
粒度控制
建模元素基本概念 原则
第三章 本课讲授的 OOA方法概貌
1、概念与表示法
类名
普通对象 主动对象
(a) 类 (b) 属性与服务
一般类
特殊类 特殊类
(c) 一般 -特殊结构
整体对象类
m
n
部分对象类
(d) 整体 -部分结构
类 类m n
(e) 实例连接
发送者 接收者
(f) 消息连接
编号 主题名
压缩方式
编号 主题名
类名
······
半展开方式
编号
编号
编号
编号
展开方式
(g) 主题的三种表示方式
表示法
＠类名
(控制线程内 )
(控制线程间 )
类名
普通对象 主动对象
＠类名
＠服务
...
属性
...
服务
...
属性
...
2,OOA的主要原则
（ 1）抽象
过程抽象
任何一个完成确定功能的操作序列，其使用者都
可把它看作一个单一的实体，尽管实际上它可能
是由一系列更低级的操作完成的。
数据抽象
根据施加于数据之上的操作来定义数据类型，并
限定数据的值只能由这些操作来修改和观察。
（ 2）封装
（ 3）继承
（ 4）分类
把具有相同属性和服务的对象划分为一类，用类作为
这些对象的抽象描述。
（ 5） 聚合
（ 6） 关联
（ 7） 消息通信
即要求对象之间只能通过消息进行通讯, 而不允许
在对象之外直接地存取对象内部的属性 。
（ 8）粒度控制
引入主题（ subject）的概念，使模型具有大小不
同的粒度层次，以利于控制复杂性。
（ 9）行为分析
关系层
特征层
对象层
基本模型 (类图 )
交
互
图
主
题
图
详 细 说 明
给出所有与问题
域和系统责任有
关的对象，用对
象类表示
定义每个对
象类的属性
与服务
通过结构与连
接描述对象之
间的关系 对模型中的所有元
素进行详
细说明
对关系密
切的类打
包，帮助
理解类图
一幅交互图表现完成某一
项特定功能的一组对象之
间的详细交互。每一项功
能用一个 use case描述
3,OOA模型
4,OOA过程
发现对象
定义属性与服务
建立结构与连接
划分主题
建立交互图
详
细
说
明
定义 USE CASE
原
型
开
发
定义 use case（辅助模型，可选）
用 use case对用户需求进行规范化描述。
建立类图（基本模型）
* 发现对象、定义对象类
* 识别对象的内部特征
* 识别对象的外部关系
划分主题，建立主题图（辅助模型，
可选）
建立交互图 （辅助模型，可选）
对照 use case，描述一组对象
进行协作时的交互情况和消息
的时序关系。
原型开发
结合其他活动反复进行
建立详细说明
对模型中的成分
进行规范的定义
和文字说明。可
以集中进行，也
可分散在各个活
动中。
5,OOA与生命周期其它阶段的关系
OOA与 OOD可适合不同的生命周期模型
分析
设计
编程
测试
维护
瀑布模型：
强调严格的
阶段划分和
前后次序
先做完 OOA
再进行 OOD
OOA
OOD
喷泉模型：
各个阶段之
间没有严格
的界限，其
活动可以交
叠和回溯。
演化
集成
测试
编程
设计
分析OOA
OOD
有些工作既可在 OOA中进行，
也可在 OOD中进行。
各阶段概念和表示法的一致为
采用这种模型提供了条件。
OOA OOD OOP 最好
OOA OOD 用非 OO语言编程 可以从 OO获益
非 OO的分
析与设计 OOD OOP 没有多大意义
从分析、设计到编程
概念：对象、主动对象 以及它们的类
对象,是系统中用来描述客观事物的一个实体，它是构成系统的
一个基本单位。一个对象由一组属性和对这组属性进行操作的一
组服务构成。
类,具有相同属性和服务的一组对象的集合，它为属于该类的全
部对象提供了统一的抽象描述，其内部包括属性和服务两个主要
部分。
类和对象的关系 —— 模板与实例
主动对象 (active object),至少有一个服务不需要接收消息就能主
动执行的对象，用于描述具有主动行为的事物。
主动对象的类叫做主动类。
从事物的主动行为认识主动对象；
从系统的执行认识主动对象。
第四章 发现对象，建立对象类
类 名
普通对象 主动对象
@ 类 名
表示法,在 OOA模型 中，用类描述属于它的全部对象实例，
用类符号来表示。
在尚未确定是不是主动对象之前，暂时用普通对象的类符号表示。
研究用户需求，明确系统责任
阅读：阅读一切与用户需求有关的书面材料
交流：与用户交流，澄清疑点，
纠正用户不切实的要求或不确切的表达
调查：到现场调查（只限于澄清需求）
记录、整理：产生一份符合工程规范、确切表达系统责
任的需求文档
研究问题域
亲临现场调查，掌握第一手资料
听取问题域专家的见解
阅读与问题域有关的材料
借鉴相同或类似问题域已有的系统开发经验及文档
确定系统边界
系统边界：系统与外部世界的界限
活动者：在系统边界以外，与系统进行交互的事物
—— 人员、设备、外系统
活动者 (人员 )
活动者 (设备 )
活动者 (外系统 )
系统边界
系统、系统边界及活动者
对
象
对象
对象 对象
对象
系 统
对象
认识系统边
界与活动者
，对发现主
动对象、定
义 use case有
重要意义。
策略与启发
（ 1）考虑问题域：
人员 组织 物品 设备
事件 表格 结构,.,
（ 2）考虑系统边界：
人员 设备 外系统
从不同的角
度考虑人员
和设备
（ 3）考虑系统责任：
检查每一项功能需求是否有相应的对象提供，发现新的对象
审查与筛选
（ 1）舍弃无用的对象
通过属性判断：
是否通过属性记录了某些有用的信息？
通过服务判断：
是否通过服务提供了某些有用的功能？
二者都不是 —— 无用
（ 2）对象的精简
只有一个属性的对象
只有一个服务的对象
班级
……
……
班主任
姓名1 1
班级
班主任姓名
……
……
输出设备
……
……
格式转换器
文件格式转换
输出设备
……
文件格式转换
……
（ 3）与实现条件有关的对象
例如：与
图形用户界面（ GUI）系统、
数据管理系统、
硬件 及
操作系统有关的对象
—— 推迟到 OOD考虑
识别主动对象
（ 1）考虑问题域和系统责任
哪些对象需呈现主动行为？
（ 2）从需求考虑系统的执行情况
是否需要并发执行？
控制线程的起点在哪个对象？
（ 3）考虑系统边界
哪些对象与活动者交互？
如果一个交互是由活动者发起的，
第一个处理该交互的对象是主动对象
在分析阶段
不能完全确定
对象分类
（ 1）异常情况的检查和调整
*类的属性或服务不适合全部对象实例
例：“汽车”类的“乘客限量”属性
问题：分类不够详细
—— 进一步划分特殊类
*属性及服务相同的类
经过抽象，差别很大的事物可能只保留相同的特征
—— 考虑能否合并为一个类
*属性及服务相似的类
—— 考虑能否提升出一个一般类
*同一事物的重复描述
例：“职员”和“工作证”
—— 取消其中一个
（ 2）类的命名
*使用名词，避免无意义的符号
*反映个体而不是群体
*适合该类及其特殊类的全部对象实例
*使用问题域通用、规范的词汇
*在中国：可用中、英文双重命名
（ 3）建立类图的对象层
*用类符号表示每个对象类
*填写类描述模板
*发现的属性与服务、结构与连接
可以随时加到类符号中
属性 —— 实例属性、类属性，
服务 —— 主动服务、被动服务
表示法：
类 名
普通对象 主动对象
属性 1
···
属性 n
服务 1
···
服务 m
@类 名
属性 1
···
属性 n
服务 1
···
@服务 m
第五章 定义属性与服务
概念：
定义属性
（ 1）策略与启发
*按常识这个对象应该有哪些属性？
*在当前的问题域中，对象应该有哪些属性？
*根据系统责任，这个对象应具有哪些属性？
*建立这个对象是为了保存和管理哪些信息？
*对象为了完成其功能，需要增设哪些属性？
*对象是否需要通过专设的属性区别其状态？
*用什么属性表示整体 -部分结构和实例连接？
（ 2）审查与筛选
*是否体现了以系统责任为目标的抽象
（例：书的重量）？
*是否描述对象本身的特征
（例：课程 — 电话号码）？
*是否破坏“原子性”
（例：通信地址）？
*是否可通过继承得到？
*是否可从其他属性直接导出？
（ 3）推迟到 OOD考虑的问题
*规范化问题
*对象标识
*性能问题
（ 4）属性的命名与定位
命名：原则与类的命名相同
定位：针对所描述的对象，适合全部对象实例
（ 5）属性的详细说明
*文字解释
*数据类型
*实现要求及其它
定义服务
问题讨论：什么是对象的状态？
关于对象状态的不同解释
状态 = 属性
只是一个别名，没有更多的意义
状态 = 属性值
没错，但没有必要辨别这么多状态
,对象技术词典, 的另一种定义：
对象或者类的整体行为（例如响应消息）的某些规则
所能适应的（对象或类的）状况、情况、条件、形式
或生存周期阶段。
—— 从属性值的等价类看问题
例 1：一个容量为 1000的栈，需要区分几种状态？
空 半满 满
压入
弹出
可执行 可执行
可执行 可执行
不可执行
不可执行
服务 状态
例 2：为“设备”对象设立一个属性，名为“状态”
属性值：关闭、待命、运行、故障等。
在此例中,每一种状态是一组使对象呈现共同行为规
则的属性值组合。
在这里，“状态”是一个专门设置的属性，它的值
反映了实际事物的状态。
状态转换图（ STD）
空
半满
满
创建
弹出 <报错 >
弹出 (已空 )
压入
压入 (未满 )
弹出 (未空 ) 压入 (已满 )
弹出
压入 <报错 >
作用：帮助分析对象的行为、定义对象的服务
一个 STD一般只针对一个（或少数几个对象），
在实际系统中，无法建立全系统的 STD。
—— 不宜作为系统级的模型
对象行为分类
（ 1）系统行为
例：创建、删除、复制、转存
（ 2）对象自身的行为 —— 算法简单的服务
例：读、写属性值
（ 3）对象自身的行为 —— 算法复杂的服务
计算或监控
（ 1）考虑系统责任
有哪些功能要求在并对象提供？
（ 2）考虑问题域
对象在问题域对应的事物有哪些行为？
（ 3）分析对象状态
对象状态的转换，是由哪些服务引起的？
（ 4）追踪服务的执行路线
模拟服务的执行，并在整个系统中跟踪
策略与启发
审查对象的每个服务
是否真正有用
是否直接提供系统责任所要求的某项功能？
或者
响应其它服务的请求间接地完成这种功能的
某些局部操作？
调整 —— 取消无用的服务
是不是高内聚的
一个服务只完成一项 单一的, 完整的 功能
调整 —— 拆分 或 合并
审查与调整
（ 1）考虑问题域
对象行为是被引发的，还是主动呈现的？
（ 2）与活动者交互的对象服务
认识对象的主动行为
操作界面
报警器监控
操作界面
打印机驱动器
（ 3）完成最外层功能的对象服务
（ 4）服务执行路线逆向追踪
操作界面
打印机驱动器
命名：动词或动宾结构
定位：
与实际事物一致
例：售货员 —— 售货，商品 —— 售出
在一般 -特殊结构中的位置
—— 适合类的全部对象实例
服务的命名和定位
*服务解释
*消息协议
*消息发送
*约束条件
*服务流程图
yes no
陈述框。
判断框
连线，用于连接各个框，
指出执行时的控制流。
入口 /出口标记，指出服
务的开始或结束。
问题：分析阶段为什么要给出服务流程图？
关于 OOA/OOD分工的两种不同观点；
对一种操作过程的说明，可详可简，
但更难区分“做什么”和“怎么做”
服务的详细说明
例题：超级市场销售管理系统
超级市场业务管理系统的子系统，只负责前台的销售管理
功能需求：
·为顾客选购的商品计价, 收费, 打印清单 。
·记录每一种商品的编号, 单价及现有数量 。
·帮助供货员发现哪些商品将要脱销, 以及时补充货源 。
·随时按上级系统的要求报告当前的款货数量, 增减商品种类或修
改商品定价 。
·交接班时结算货款数目, 报告上级系统 。
发现对象：
收款机、供货员、上级系统接口、商品、特价商品、
计量商品、商品一览表、销售事件、帐册
问题：
为什么没有“收款员”和“经理”这两类对象？
帐 册
商品一览表
销售事件
@上级系统接口
@收款机
供货员
商 品
计量商品特价商品
帐 册
商品一览表
销售事件
@收款机
供货员
商品
计量商品特价商品
本班收款员
开始时间
结束时间
@登录
售货
结帐
前班结余
销售事件表
收入累计
上交款
本班结余
···接班
记帐
报帐交班
收款人
购物清单
应收款
···
销售计价
入帐
商品目录
检索
种类增删
@上级系统接口
帐册目录
@消息收发
查账
报帐
价格更新
种类增删
编号
名称
单价
架上数量
下限
售出
补充
价格更新
缺货登记表
缺货登记
供货
开始日期
结束日期
* 单价
计量单位
计价方式
* 售出
* 补充
* 价格更新
