第10章 面向对象分析
合集下载
软件工程导论第10章面向对象分析
易于理解，同时减少了代码冗余和重复，提高了开发效率和代码质量。
03
提高软件的可重用性
面向对象分析鼓励使用抽象和封装技术，使得软件组件更加模块化和可
重用，减少了重复开发的工作量，提高了软件开发的效率。
02
面向对象分析的主要步骤
问题识别
总结词
明确问题的本质和范围
详细描述
在面向对象分析中，问题识别是首要步骤，它要求对问题进行深入理解和明确， 包括确定问题的范围、目标、限制条件等，以便为后续的分析和设计工作提供 清晰的方向。
面向对象分析的优势与不足
过度抽象
面向对象分析有时会过度抽象，导致 系统过于复杂，难以理解和实现。
缺乏对系统流程的关注
面向对象分析更关注静态结构，可能 忽略系统流程和动态行为。
面向对象分析与传统分析方法的结合使用
在实际软件开发中，可以结合 面向对象分析和传统分析方法， 取长补短，提高软件开发的效
率和成功率。
05
面向对象分析与传统分析方法的 比较
传统分析方法的问题与挑战
缺乏对系统整体结构的考虑
传统分析方法往往只关注单个功能或模块，忽略了系统整体的结 构和关系。
难以处理复杂系统
对于复杂系统，传统分析方法难以有效地进行抽象和建模。
难以维护和扩展
由于缺乏整体结构和面向对象的思维，传统分析方法构建的系统往 往难以维护和扩展。
对象是指系统中具有明确边界和状态 的结构，它可以包含数据和操作，并 且具有封装性、继承性和多态性等特 征。
面向对象的基本特征
封装
封装是将对象的属性和操作封装 在一起，形成一个独立的实体， 对外隐藏内部实现细节，只通过 接口与外界交互。
继承
继承是指子类可以继承父类的属 性和方法，并且可以扩展或修改 它们，从而实现代码的重用和扩 展。
第十章 状态机图-UML面向对象分析、建模与设计-吕云翔-清华大学出版社
事件包含一个参数列表（可能为空），用于从事件的产生者向其接 收者传递信息。
对应于触发器转换，没有明确的触发器的转换成为结束转换或无触 发器转换，是在状态的内部活动执行完毕后隐式触发的。
转换——事件
能够在触发器中接收的事件有以下四种：
调用事件：调用事件表示对象接收到一个调用操作的请求。其期待的结 果是事件的接收者触发一个转换并执行相应的操作。
改变事件：改变事件的发生依赖于事件中某个表达式所表达的布尔条件。 改变事件没有参数，要一直等到条件被满足才能发生。
信号事件：信号由一个对象准确地送给另一个或一组对象。发送给一组 对象的信号可能触发每个对象的不同转换。
时间事件：时间事件的发生依赖于事件中的一个时间表达式。比如，可 以让对象进入某状态后经过一段给定的时间或到达某个绝对时间后发生 该事件。
转换——事件
stm 订单类 Unselected
click(posX, posY) [posX==x and posY==y]
Selected
（a）
SingleSelectionMode shiftKeyUp MultiSelectionMode shiftKeyDown （c）
状态机图
状态机 状态机图
状态机图的基本概念
状态机
状态机是一种行为，它说明对象在其生命周期中响应事件所经历的 状态变化序列以及对那些时间的响应。
一般情况下，一个状态机依附于一个类，用来描述这个类的实例的 状态及其转换，和对接收到的事件所做出的响应。此外，状态机也可 以依附于用例、操作、协作等元素上，描述它们的执行过程。
等待支付
[立即支付] 审核完成
[及时支付]
[超出支付时限]
审核失败
状态机图
对应于触发器转换，没有明确的触发器的转换成为结束转换或无触 发器转换，是在状态的内部活动执行完毕后隐式触发的。
转换——事件
能够在触发器中接收的事件有以下四种：
调用事件：调用事件表示对象接收到一个调用操作的请求。其期待的结 果是事件的接收者触发一个转换并执行相应的操作。
改变事件：改变事件的发生依赖于事件中某个表达式所表达的布尔条件。 改变事件没有参数，要一直等到条件被满足才能发生。
信号事件：信号由一个对象准确地送给另一个或一组对象。发送给一组 对象的信号可能触发每个对象的不同转换。
时间事件：时间事件的发生依赖于事件中的一个时间表达式。比如，可 以让对象进入某状态后经过一段给定的时间或到达某个绝对时间后发生 该事件。
转换——事件
stm 订单类 Unselected
click(posX, posY) [posX==x and posY==y]
Selected
（a）
SingleSelectionMode shiftKeyUp MultiSelectionMode shiftKeyDown （c）
状态机图
状态机 状态机图
状态机图的基本概念
状态机
状态机是一种行为，它说明对象在其生命周期中响应事件所经历的 状态变化序列以及对那些时间的响应。
一般情况下，一个状态机依附于一个类，用来描述这个类的实例的 状态及其转换，和对接收到的事件所做出的响应。此外，状态机也可 以依附于用例、操作、协作等元素上，描述它们的执行过程。
等待支付
[立即支付] 审核完成
[及时支付]
[超出支付时限]
审核失败
状态机图
面向对象分析-顺序图
把消息表示为从一个对象生命线到另一个对象生命线的一个水平实线箭头， 即从源对象指向目标对象，以触发目标对象中的特定操作。对于对象到自身的 消息，箭头就从同一个对象符号开始和结束。
用消息（操作或信号）的名字及其参数值或者参数表达式标示箭头。
用如下种类的箭头表示不同种类的通讯：
同步消息
一般把它用于普通的过程调用。在外层控制恢复之前，要完成整个嵌套序列。 通常把它用于普通的过程调用。 若在一个主动对象发送信号并等待完成一个嵌套的行为序列才继续时，也可以 把它用于并发的主动对象。 同步消息返回 用它显式地表示从过程调用的返回。在控制的过程流中，可以省略返回箭头 （暗示执行规约结束），假设每个调用在任何消息后都有一个配对的返回，并可以 把返回值标示在初始的箭头上。
5.1
概念与表示法
1、概述 顺序图是一种详细表示对象之间以及对象与参与者实例之间交 互的图，它由一组协作的对象（或参与者实例）以及它们之间可发 送的消息组成，它强调消息之间的顺序。
由对象（参与者） 、消息、生命线和执行规约组成。
[对象名]：类名
从图中可以看出顺序图是二维的，其中： 垂直方向表示时间，水平方向表示不同的对 象或参与者。 通常时间维由上到下（根据需要，也可以 由下到上）。通常只有时间顺序是重要的， 但在实时应用中时间轴是能度量的。 对象的水平顺序并不重要，相应地生命线 之间的顺序可以是任意的。
3、执行规约
执行规约表示一个对象直接或者通过从属 例程执行一个行为的时期。它既表示了行 为执行的持续时间，也表示了活动和它的 调用者之间的控制关系。 用一个窄长的矩形表示执行规约，矩形 顶端和它的开始时刻对齐，末端和它的结 束时刻对齐。 在程序的控制流中，执行规约符号的顶 端画在进入的箭头的尖端（开始该动作的 那个箭头），底端画在返回的箭头的尾部。
软件工程ppt课件 第10章 面向对象分析-文档资料
拥有银行账户的储户有权申请领取现金兑换卡。
使用现金兑换卡可以通过ATM访问自己的账户。 目前仅限于用现金兑换卡在ATM上提取现金(即 取款)，或查询有关自己账户的信息(例如，某 个指定账户上的余额)。
将来可能还要求使用ATM办理转账、存款等事务。
所谓现金兑换卡就是一张特制的磁卡，上面有分行 代码和卡号。 分行代码惟一标识总行下属的一个分行，卡号确定 了这张卡可以访问哪些账户。通常，一张卡可以访 问储户的若干个账户，但是不一定能访问这个储户 的全部账户。
§1. 基本过程 Object model 由
主题 类与对象 结构 属性 方法
1+
五个层次组成
(Coad&Yourdon, 1991),相当于把
1+
五张透明胶片
(transparencies)
叠在一起，每 一层显示更多 的细节。
主题是指导读者(包括系统分析员、软件设计人员、 领域专家、管理人员、用户等 )理解大型、复杂 模型的一种机制。也就是说，通过划分主题把一 个大型、复杂的对象模型分解成几个不同的概念 范畴。
第3步：完善
§3.建立 Object Model
① 正名：分行提供分行计算机和柜员终端 = 分行拥有分行计算机 + 分行拥有柜员终端 ② 分解：适当分解前面确定的class-&-objects ,使 其适用于不同的关联 事务 = 远程事务 + 柜员事务 ③补充 柜员输入柜员事务 在ATM上输入远程事务 柜员事务输进柜员终端 远程事务由现金兑换卡授权
1+ ATM
输入
1+ 1+ 远程事务 1+
修改 授权
现金兑换卡 1. 总 行 2. 分 行 3. ATM
软件工程第10章 面向对象分析(简)
单击此处编辑母版标题样 下图所示为自动取款机(ATM)系统（作为OO分析和OO设计实例） (ATM)系统 OO分析和OO设计实例 下图所示为自动取款机(ATM)系统（作为OO分析和OO设计实例） 式
10.2.2 需求陈述书写举例
ATM系统 图10.2 ATM系统
单击此处编辑母版标题样 自动取款机(ATM)系统需求陈述 P234）： (ATM)系统需求陈述（ 自动取款机(ATM)系统需求陈述（P234）： 某银行拟开发一个自动取款机系统，它是一个由自动取款机、 某银行拟开发一个自动取款机系统，它是一个由自动取款机、中央计 式
主题含义：主题是指导开发人员和用户理解大型、 主题含义：主题是指导开发人员和用户理解大型、复杂模型的一种机 实际上， 制。实际上，主题就是对对象模型所涉及的诸多类和对象按照问题空 间的组成范围（方面）进行划分和归类。 间的组成范围（方面）进行划分和归类。 5个层次对应着建立对象模型的5项主要活动：找出类与对象，识别结 个层次对应着建立对象模型的5项主要活动：找出类与对象， 识别主题，定义属性，定义服务。 构，识别主题，定义属性，定义服务。 面向对象分析的一般步骤：寻找类与对象，识别结构，识别主题， 面向对象分析的一般步骤：寻找类与对象，识别结构，识别主题，定 义属性，建立动态模型，建立功能模型，定义服务。 义属性，建立动态模型，建立功能模型，定义服务。
单击此处编辑母版标题样 式
复杂问题的对象模型的5 图10.1 复杂问题的对象模型的5个层次
单击此处编辑母版标题样 对象模型5个层次的含义：类与对象、结构（类或对象之间的关系）、 对象模型5个层次的含义：类与对象、结构（类或对象之间的关系）、 式 属性和服务的概念，已经在第9章介绍过。现在介绍主题的概念。 属性和服务的概念，已经在第9章介绍过。现在介绍主题的概念。
第10章面向对象分析(OOA)
建立模型：
系统分析员应该深入理解用户需求，抽象出目标系 统的本质属性，并用模型准确地表示出来
分析模型应该成为对问题的精确而又简洁的表示 后继的设计阶段将以分析模型为基础
通过建立分析模型能够纠正在开发早期对问题域的 误解
建模的过程中，系统分析员必须认真向领域专家学 习
注意结果的可重用性
候选类：
银行，自动取款机(ATM)，系统，中央计算机，分 行计算机，柜员终端，网络，总行，分行，软件， 成本，市，街道，营业厅，储蓄所，柜员，储户， 现金，支票，账户，事务，现金兑换卡，余额，磁 卡，分行代码，卡号，用户，副本，信息，密码， 类型，取款额，账单，访问
根据领域知识或常识进一步把隐含的类与对象 提取出来
当用户把现金兑换卡插入ATM之后，ATM就与 用户交互，以获取有关这次事务的信息，并与 中央计算机交换关于事务的信息。首先，ATM 要求用户输入密码，接下来ATM把从这张卡上 读到的信息以及用户输入的密码传给中央计算 机，请求中央计算机核对这些信息并处理这次 事务。中央计算机根据卡上的分行代码确定这 次事务与分行的对应关系，并且委托相应的分 行计算机验证用户密码。如果用户输入的密码 是正确的，ATM就要求用户选择事务类型(取款、 查询等)。当用户选择取款时，ATM请求用户输 入取款额。最后，ATM从现金出口吐出现金， 并且打印出账单交给用户。
需求陈述的内容包括：
问题范围 功能需求 性能需求 应用环境及假设条件等
应该阐明“做什么”而不是“怎样做” 应该描述用户的需求而不是提出解决问题的方法 应该指出哪些是系统必要的性质，哪些是任选的 需求陈述可简可繁、要尽力做到语法正确 最好是分析员和系统用户共同完成
10.2.2 例子
面向对象的系统分析
实现上:一个对象中应有指向另一对象的指针 ① 参与者——事务模板 例如：学生——注册 约束基数的意义：一个学生可注册0次或 多次，而一个注册只能由一个学生进行 ② 事务——地方模板 表示事务发生的地方, 例: 缴费与缴费地方 ③ 参与者——地方模板 例如：学生与学院
学生
0-n
1
注册
出纳窗口
0-n
1
缴注册费
图10.15 参与者—事务模板
图10.16 地方—事务模板
1 注册费细目
学生
1
0-n
学院
缴注册费 1-n
图10.18 参与者--地方模板
图10.19 事务—事务细目模板
注册费项目 0-n
1 注册费细目
T3—保险费
实验费 体检费 保险费 学费
项目
T3--学费 T2--实验费 T2--学费 T1—保险费 T1-学费
其他事件流A1: (1)控制面板响铃一次. (2)系统复位. (3)执行事件流A0. 错误事件流E1: (1)控制面板显示系统出错. (2)结束使用案例.
10.3.2 类—责任—协作者模型
类—责任—协作者模型：用于描述用户的 需求，标出对象和类。 构成：CRC卡片，顶部: 类名，中左部: 责 任，中右部: 协作者。
10.3.1 使用案例
描述目标系统的一种使用情况。
1）角色 2）使用案例作用 3）使用案例图示 4）使用案例描述(事件流方法)
1）角色
和系统通讯并外部于系统的任何事物 (人、设备)。 特点：① 一个角色代表一类外部实体 ② 仅起一个作用 主要角色：直接并经常和系统相互作用。 次要角色：支持系统，使主要角色起作用。
class class_B { public: class_B( ); ～class_C( ); … }
学生
0-n
1
注册
出纳窗口
0-n
1
缴注册费
图10.15 参与者—事务模板
图10.16 地方—事务模板
1 注册费细目
学生
1
0-n
学院
缴注册费 1-n
图10.18 参与者--地方模板
图10.19 事务—事务细目模板
注册费项目 0-n
1 注册费细目
T3—保险费
实验费 体检费 保险费 学费
项目
T3--学费 T2--实验费 T2--学费 T1—保险费 T1-学费
其他事件流A1: (1)控制面板响铃一次. (2)系统复位. (3)执行事件流A0. 错误事件流E1: (1)控制面板显示系统出错. (2)结束使用案例.
10.3.2 类—责任—协作者模型
类—责任—协作者模型：用于描述用户的 需求，标出对象和类。 构成：CRC卡片，顶部: 类名，中左部: 责 任，中右部: 协作者。
10.3.1 使用案例
描述目标系统的一种使用情况。
1）角色 2）使用案例作用 3）使用案例图示 4）使用案例描述(事件流方法)
1）角色
和系统通讯并外部于系统的任何事物 (人、设备)。 特点：① 一个角色代表一类外部实体 ② 仅起一个作用 主要角色：直接并经常和系统相互作用。 次要角色：支持系统，使主要角色起作用。
class class_B { public: class_B( ); ～class_C( ); … }
软件工程第10章 面向对象分析
10.1 面向对象分析的基本过程
10.1.1.概述
面向对象分析，就是抽取和整理用户需求并建立问题域 精确模型的过程。 面向对象分析过程从分析陈述用户需求的文件开始。 接下来，系统分析员应该深入理解用户需求，抽象出目
标系统的本质属性，并用模型准确地表示出来。 在面向对象建模的过程中，系统分析员必须认真向领域
首先，面向对象分析通过控制读者能见到的层次数目 来控制可见性。
其次，面向对象分析增加了一个主题层，它可以从一 个相当高的层次描述总体模型，并对读者的注意力加 以指导。
10.1 面向对象分析的基本过程
在概念上可以认为，面向对象分析大体上按照下列顺 序进行：
寻找类与对象，识别结构，识别主题，定义属性， 建立动态模型，建立功能模型，定义服务。 但是，分析不可能严格地按照预定顺序进行，大型、 复杂系统的模型需要反复构造多遍才能建成。 分析也不是一个机械的过程。系统分析员必须与领域 专家及用户反复交流，以便澄清二义性，改正错误的 概念，补足缺少的信息。
主要内容
10.1 面向对象分析的基本过程 10.2 需求陈述 10.3 建立对象模型 10.4 建立动态模型 10.5 建立功能模型 10.6 定义服务
10.2 需求陈述
10.2.1. 书写要点
需求陈述应该阐明“做什么”而不是“怎样做”！
应该描述用户的需求而不是提出解决问题的方法。 应该指出哪些是系统必要的性质，哪些是任选的性质。 应该避免对设计策略施加过多的约束，也不要描述系
10.3 建立对象模型
10.3.1. 确定类与对象
类与对象是在问题域中客观存在的，系统分析员的主 要任务就是通过分析找出这些类与对象。 首先找出所有候选的类与对象； 然后从候选的类与对象中筛选掉不正确的或不必
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件工程
第10章 面向对象分析
第10章 面向对象分析
• 面向对象软件开发技术
– 面向对象分析(OOA) – 面向对象设计(OOD) – 面向对象实现(OOP)
面向对象技术是一个有全新概念 的开发模式,其特点是:
(1)方法是对软件开发过程所有阶段进 行综合考虑而得到的; (2)从生存期的一个阶段到下一个阶段 所使用的方法与技术具有高度的连 续性;
取消交易
顾客可在按下选择键前任何一个时刻，拉动退币杆取 消交易收回硬币。
自动售货系统系统
-端1 * -端2
自动售货系统::售货
*
顾客
-端2
-端1 *
自动售货系统::供货
*
供货人
-端1 * -端2
自动售货系统::取货款
*
收银员
自动售货系统系统
-端1 *
-端2
售货
*
<<extends>>
售散装饮料
顾客
• 业务中的执行者扮演什么角色？这些角色可以 看作类，如客户、操作员等。
（2）筛选对象类，确定最终对象类 我们可以用以下选择特征来确定最终的对象： 1) 保留的信息：仅当必须记住有关潜在对象的 信息，系统才能运作时，则该潜在对象在分 析阶段是有用的； 2) 需要的服务：潜在对象必须拥有一组可标识 的操作，它们可以按某种方式修改对象属性 的值； 3) 多个属性：在分析阶段，关注点应该是“较 大的”信息（仅具有单个属性的对象在设计 时可能有用，但在分析阶段，最好把它表示 为另一对象的属性）；
定义服务
• 对象=属性+操作（服务） • 因为在动态模型和功能模型中更明确地描 述了每个类中应该提供哪些服务，所以在 建立了这两个模型后才能最终确定类中应 有的服务。 • 事实上，在确定类中应有的服务时，既要 考虑该类实体的常规行为，又要考虑在本 系统中特殊需要的服务。
• 1、常规行为 • 读写该类每个属性的操作。通常无需显示 表示这些常规操作。 • 2、从事件导出的操作 状态图中发往对象的事件就是该对象接收 到的消息。 3、与数据流图中处理框对应的操作 4、利用继承减少冗余操作 抽取类似的公共属性和操作，建立父类
实例：饮料自动售货机系统 设臵
一个饮料自动售货机可以放臵五种不同或部分相同的 饮料，可由厂商根据销售状况自动调配，并可随时重新 设臵售价，但售货机最多仅能放臵50罐饮料，其按钮设 计在各种饮料样本的下方，若经金额计算器累计金额足 够，则选择键灯会亮；若某一种饮料已销售完毕，则售 完灯会亮。
销售
顾客将硬币投入售货机，经累加金额足额的饮料选择 键灯亮，等顾客按键选择。顾客按键后饮料由取物楼掉 出，并自动结算及找钱。
这种做法持续至所有的用例都完成为止。
动态建模
动态建模用来描述系统的动态行为，显 示对象在系统运行期间不同时刻的动态交互。 UML中用状态图、顺序图、活动图来建立动 态模型。
数据流图——建立功能模型
• 功能模型表明了系统中数据之间的依赖关 系，以及有关的数据处理功能，它由一组 数据流图组成。其中的处理功能可以用 IPO图、伪码等多种方式进一步描述。
4) 公共属性：可以为潜在的对象定义一组属性， 这些属性适用于该类的所有实例； 5) 公共操作：可以为潜在的对象定义一组操作， 这些操作适用于该类的所有实例； 6) 必要的需求：出现在问题空间中的外部实体 以及对系统的任何解决方案的实施都是必要 的生产或消费信息，它们几乎总是定义为需 求模型中的类。
4. 复审CRC卡 在填好所有CRC卡后，应对它进行复审。复 审应由客户和软件分析员参加，复审方法如 下： 1) 参加复审的人，每人拿CRC卡片的一个子集。 注意，有协作关系的卡片要分开，即，没有 一个人持有两张有协作关系的卡片。 2) 将所有用例/场景分类。 3) 复审负责人仔细阅读用例，当读到一个命名 的对象时，将令牌（token）传送给持有对 应类的卡片的人员。
-端2 *
-端1 *
供货
<<uses>> 打开机器 <<uses>> <<uses>> <<uses>>
供货人
-端2 -端1 * *
关闭机器
取货款
收银员
找出饮料自动售货机系统中的对象 设臵
一个饮料自动售货机可以放臵五种不同或部分相同的 饮料，可由厂商根据销售状况自动调配，并可随时重新 设臵售价，但售货机最多仅能放臵50罐饮料，其按钮设 计在各种饮料样本的下方，若经金额计算器累计金额足 够，则选择键灯会亮；若某一种饮料已销售完毕，则售 完灯会亮。
(3)将OOA、OOD、OOP集成到生存 期的相应阶段.
分析模型
•对象模型:
•功能模型: •动态模型:
描述静态结构, 定义做
事情的实体
描述处理(数据变换),
指明系统应“做什么”描述源自互过程, 规定什么时候做OMT模型系统分析和设计过程概观图
产生需求 问题描述
建立模型
对象模型、动态模型、功能模型 结构及对象 设计
分析的过程是提取系统需求的过程，主要包括：理 解、表达和验证。它通过建立以下三个模型来完成： – 对象模型 定义了做事情的实体，描述系统的数据结构，包括 对象之间的关系、对象的属性和操作，用对象图表示。 – 功能模型 说明发生什么，它只关心系统做什么，而不考虑怎 么做，描述系统的功能结构，用数据流程图DFD描述。 – 动态模型 明确规定了什么时候做（即在何种状态下接受了什 么事件的触发），描述系统的控制结构，即：描述类的 对象的状态和事件的正确次序。 每个类的动态行为用一张状态图来描绘，各个类的状 态图通过共享事件合并起来，从而构成系统的动态模型。
3. 标识协作者
一个类可以用它自己的操作去操纵它自己的属 性，从而完成某一特定的责任，一个类也可和其它 类协作来完成某个责任。如果一个对象为了完成某 个责任需要向其它对象发送消息，则我们说该对象 和另一对象协作。协作实际上标识了类间的关系。 为了帮助标识协作者，可以检索类间的类属关系。 如果两个类具有整体与部分关系，或者一个类必须 从另一个类获取信息，或者一个类依赖于另一个类， 则它们间往往有协作关系。
类和对象模型的基本模型元素有类、对 象以及它们之间的关系。系统中的类和对 象模型描述了系统的静态结构，在UML中 用类图和对象图来表示。
一旦建立了系统的用例模型，则可以开始标识 候选类，并指明它们的责任和协作。Wirfs-Brock等人 提出了一种类-责任-协作者(Class-responsibilitycollaborator,CRC)开发类图的卡片技术。该技术使用实 际的或虚拟的索引卡片，为定义类提供较多的信息。其 中责任是与该类相关的属性和操作，协作者是为一个类 提供要完成的责任所需要的信息的那些类。通常，协作 意味着对信息的请求或者对某种操作的请求。 在确定属性和操作时，可把它们列在卡片上。由于 卡片的空间有限，使得每一个类都不能太复杂。如果不 能在一张卡片上列出所有的职责，该类应分成两个相关 的类。可在白板上自由移动卡片以组成类图，在卡片之 间画线表示关联与泛化。低科技的卡片技术可能比操作 软件用户界面要快，对开发人员通过会议讨论确定方案 很有效。
举例：饮料自动售货机系统的状态图
Do:显示售货机在备用 所有灯都关闭 Do:显示金额总数
投入硬币 （有效的） 投入硬币金额
(1元、5元、10元)
无效的硬币 取消 取消
回到备用状态
Do:显示金额已够 饮料选择灯亮 按下选择饮料键
取出饮料 结算找零 扣减存量 完成交易
金额不足 再投币
数据流图
功能模型：模型
类图：视图
对象模型：模型
分析模型：模型
顺序图：视图 状态图：视图 活动图：视图 动态模型：模型
分析模型的构成
用例建模——需求分析
用例建模是用于描述一个系统应该做什么的 建模技术，用例建模不仅用于新系统的需求获 取，还可用于已有系统的升级。用例模型用用 例图来描述。
静态建模（对象模型）
2 定义操作 操作定义了对象的行为并以某种方式修 改对象的属性值。操作可以通过对系统的 过程叙述的分析提取出来，通常叙述中的 动词可作为候选的操作。类所选择的每个 操作展示了类的某种行为。 操作大体可分为三类：
• 以某种方式操纵数据的操作（如，增加、 删除、重新格式化、选择）； • 完成某种计算的操作； • 为控制事件的发生而监控对象的操作。
销售
顾客将硬币投入售货机，经累加金额足额的饮料选择 键灯亮，等顾客按键选择。顾客按键后饮料由取物楼掉 出，并自动结算及找钱。
取消交易
顾客可在按下选择键前任何一个时刻，拉动退币杆取 消交易收回硬币。
饮料自动售货机系统对象图
金额计算器
金额 累加 找零 重置
属于
贩卖机
饮料号码 价格 投币-接受 饮料掉出 金额显示 按纽 退币杆 售完显示
基于三个模型的分析步骤
• 需求陈述
• • • •
对象建模 动态建模 功能建模 添加操作反复建模
三种模型的关系
在面向对象方法学中，对象模型是最基本的、最 重要的，它为其他两种模型奠定了基础，我们依靠对 象模型完成三种模型的集成。
1. 针对每个类建立的动态模型，描述了类实例的生命 周期或运行周期。
分 析 阶 段
详细的对象模型 详细的动态模型 详细的功能模型
设 计 阶 段
面向对象分析 Object-Oriented Analysis
面向对象分析的一般步骤如下：
1. 获 取 客 户 对 系 统 的 需 求 ： 包 括 标 识 场 景 （scenario）和用例（use case也称用况）， 以及建造需求模型 2. 建立对象模型。 3. 建立功能模型。 4. 建立动态模型。 5. 利用用例/场景来复审分析模型。
属于
存量计算器
第10章 面向对象分析
第10章 面向对象分析
• 面向对象软件开发技术
– 面向对象分析(OOA) – 面向对象设计(OOD) – 面向对象实现(OOP)
面向对象技术是一个有全新概念 的开发模式,其特点是:
(1)方法是对软件开发过程所有阶段进 行综合考虑而得到的; (2)从生存期的一个阶段到下一个阶段 所使用的方法与技术具有高度的连 续性;
取消交易
顾客可在按下选择键前任何一个时刻，拉动退币杆取 消交易收回硬币。
自动售货系统系统
-端1 * -端2
自动售货系统::售货
*
顾客
-端2
-端1 *
自动售货系统::供货
*
供货人
-端1 * -端2
自动售货系统::取货款
*
收银员
自动售货系统系统
-端1 *
-端2
售货
*
<<extends>>
售散装饮料
顾客
• 业务中的执行者扮演什么角色？这些角色可以 看作类，如客户、操作员等。
（2）筛选对象类，确定最终对象类 我们可以用以下选择特征来确定最终的对象： 1) 保留的信息：仅当必须记住有关潜在对象的 信息，系统才能运作时，则该潜在对象在分 析阶段是有用的； 2) 需要的服务：潜在对象必须拥有一组可标识 的操作，它们可以按某种方式修改对象属性 的值； 3) 多个属性：在分析阶段，关注点应该是“较 大的”信息（仅具有单个属性的对象在设计 时可能有用，但在分析阶段，最好把它表示 为另一对象的属性）；
定义服务
• 对象=属性+操作（服务） • 因为在动态模型和功能模型中更明确地描 述了每个类中应该提供哪些服务，所以在 建立了这两个模型后才能最终确定类中应 有的服务。 • 事实上，在确定类中应有的服务时，既要 考虑该类实体的常规行为，又要考虑在本 系统中特殊需要的服务。
• 1、常规行为 • 读写该类每个属性的操作。通常无需显示 表示这些常规操作。 • 2、从事件导出的操作 状态图中发往对象的事件就是该对象接收 到的消息。 3、与数据流图中处理框对应的操作 4、利用继承减少冗余操作 抽取类似的公共属性和操作，建立父类
实例：饮料自动售货机系统 设臵
一个饮料自动售货机可以放臵五种不同或部分相同的 饮料，可由厂商根据销售状况自动调配，并可随时重新 设臵售价，但售货机最多仅能放臵50罐饮料，其按钮设 计在各种饮料样本的下方，若经金额计算器累计金额足 够，则选择键灯会亮；若某一种饮料已销售完毕，则售 完灯会亮。
销售
顾客将硬币投入售货机，经累加金额足额的饮料选择 键灯亮，等顾客按键选择。顾客按键后饮料由取物楼掉 出，并自动结算及找钱。
这种做法持续至所有的用例都完成为止。
动态建模
动态建模用来描述系统的动态行为，显 示对象在系统运行期间不同时刻的动态交互。 UML中用状态图、顺序图、活动图来建立动 态模型。
数据流图——建立功能模型
• 功能模型表明了系统中数据之间的依赖关 系，以及有关的数据处理功能，它由一组 数据流图组成。其中的处理功能可以用 IPO图、伪码等多种方式进一步描述。
4) 公共属性：可以为潜在的对象定义一组属性， 这些属性适用于该类的所有实例； 5) 公共操作：可以为潜在的对象定义一组操作， 这些操作适用于该类的所有实例； 6) 必要的需求：出现在问题空间中的外部实体 以及对系统的任何解决方案的实施都是必要 的生产或消费信息，它们几乎总是定义为需 求模型中的类。
4. 复审CRC卡 在填好所有CRC卡后，应对它进行复审。复 审应由客户和软件分析员参加，复审方法如 下： 1) 参加复审的人，每人拿CRC卡片的一个子集。 注意，有协作关系的卡片要分开，即，没有 一个人持有两张有协作关系的卡片。 2) 将所有用例/场景分类。 3) 复审负责人仔细阅读用例，当读到一个命名 的对象时，将令牌（token）传送给持有对 应类的卡片的人员。
-端2 *
-端1 *
供货
<<uses>> 打开机器 <<uses>> <<uses>> <<uses>>
供货人
-端2 -端1 * *
关闭机器
取货款
收银员
找出饮料自动售货机系统中的对象 设臵
一个饮料自动售货机可以放臵五种不同或部分相同的 饮料，可由厂商根据销售状况自动调配，并可随时重新 设臵售价，但售货机最多仅能放臵50罐饮料，其按钮设 计在各种饮料样本的下方，若经金额计算器累计金额足 够，则选择键灯会亮；若某一种饮料已销售完毕，则售 完灯会亮。
(3)将OOA、OOD、OOP集成到生存 期的相应阶段.
分析模型
•对象模型:
•功能模型: •动态模型:
描述静态结构, 定义做
事情的实体
描述处理(数据变换),
指明系统应“做什么”描述源自互过程, 规定什么时候做OMT模型系统分析和设计过程概观图
产生需求 问题描述
建立模型
对象模型、动态模型、功能模型 结构及对象 设计
分析的过程是提取系统需求的过程，主要包括：理 解、表达和验证。它通过建立以下三个模型来完成： – 对象模型 定义了做事情的实体，描述系统的数据结构，包括 对象之间的关系、对象的属性和操作，用对象图表示。 – 功能模型 说明发生什么，它只关心系统做什么，而不考虑怎 么做，描述系统的功能结构，用数据流程图DFD描述。 – 动态模型 明确规定了什么时候做（即在何种状态下接受了什 么事件的触发），描述系统的控制结构，即：描述类的 对象的状态和事件的正确次序。 每个类的动态行为用一张状态图来描绘，各个类的状 态图通过共享事件合并起来，从而构成系统的动态模型。
3. 标识协作者
一个类可以用它自己的操作去操纵它自己的属 性，从而完成某一特定的责任，一个类也可和其它 类协作来完成某个责任。如果一个对象为了完成某 个责任需要向其它对象发送消息，则我们说该对象 和另一对象协作。协作实际上标识了类间的关系。 为了帮助标识协作者，可以检索类间的类属关系。 如果两个类具有整体与部分关系，或者一个类必须 从另一个类获取信息，或者一个类依赖于另一个类， 则它们间往往有协作关系。
类和对象模型的基本模型元素有类、对 象以及它们之间的关系。系统中的类和对 象模型描述了系统的静态结构，在UML中 用类图和对象图来表示。
一旦建立了系统的用例模型，则可以开始标识 候选类，并指明它们的责任和协作。Wirfs-Brock等人 提出了一种类-责任-协作者(Class-responsibilitycollaborator,CRC)开发类图的卡片技术。该技术使用实 际的或虚拟的索引卡片，为定义类提供较多的信息。其 中责任是与该类相关的属性和操作，协作者是为一个类 提供要完成的责任所需要的信息的那些类。通常，协作 意味着对信息的请求或者对某种操作的请求。 在确定属性和操作时，可把它们列在卡片上。由于 卡片的空间有限，使得每一个类都不能太复杂。如果不 能在一张卡片上列出所有的职责，该类应分成两个相关 的类。可在白板上自由移动卡片以组成类图，在卡片之 间画线表示关联与泛化。低科技的卡片技术可能比操作 软件用户界面要快，对开发人员通过会议讨论确定方案 很有效。
举例：饮料自动售货机系统的状态图
Do:显示售货机在备用 所有灯都关闭 Do:显示金额总数
投入硬币 （有效的） 投入硬币金额
(1元、5元、10元)
无效的硬币 取消 取消
回到备用状态
Do:显示金额已够 饮料选择灯亮 按下选择饮料键
取出饮料 结算找零 扣减存量 完成交易
金额不足 再投币
数据流图
功能模型：模型
类图：视图
对象模型：模型
分析模型：模型
顺序图：视图 状态图：视图 活动图：视图 动态模型：模型
分析模型的构成
用例建模——需求分析
用例建模是用于描述一个系统应该做什么的 建模技术，用例建模不仅用于新系统的需求获 取，还可用于已有系统的升级。用例模型用用 例图来描述。
静态建模（对象模型）
2 定义操作 操作定义了对象的行为并以某种方式修 改对象的属性值。操作可以通过对系统的 过程叙述的分析提取出来，通常叙述中的 动词可作为候选的操作。类所选择的每个 操作展示了类的某种行为。 操作大体可分为三类：
• 以某种方式操纵数据的操作（如，增加、 删除、重新格式化、选择）； • 完成某种计算的操作； • 为控制事件的发生而监控对象的操作。
销售
顾客将硬币投入售货机，经累加金额足额的饮料选择 键灯亮，等顾客按键选择。顾客按键后饮料由取物楼掉 出，并自动结算及找钱。
取消交易
顾客可在按下选择键前任何一个时刻，拉动退币杆取 消交易收回硬币。
饮料自动售货机系统对象图
金额计算器
金额 累加 找零 重置
属于
贩卖机
饮料号码 价格 投币-接受 饮料掉出 金额显示 按纽 退币杆 售完显示
基于三个模型的分析步骤
• 需求陈述
• • • •
对象建模 动态建模 功能建模 添加操作反复建模
三种模型的关系
在面向对象方法学中，对象模型是最基本的、最 重要的，它为其他两种模型奠定了基础，我们依靠对 象模型完成三种模型的集成。
1. 针对每个类建立的动态模型，描述了类实例的生命 周期或运行周期。
分 析 阶 段
详细的对象模型 详细的动态模型 详细的功能模型
设 计 阶 段
面向对象分析 Object-Oriented Analysis
面向对象分析的一般步骤如下：
1. 获 取 客 户 对 系 统 的 需 求 ： 包 括 标 识 场 景 （scenario）和用例（use case也称用况）， 以及建造需求模型 2. 建立对象模型。 3. 建立功能模型。 4. 建立动态模型。 5. 利用用例/场景来复审分析模型。
属于
存量计算器