第10章 面向对象分析
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件工程
第10章 面向对象分析
第10章 面向对象分析
• 面向对象软件开发技术
– 面向对象分析(OOA) – 面向对象设计(OOD) – 面向对象实现(OOP)
面向对象技术是一个有全新概念 的开发模式,其特点是:
(1)方法是对软件开发过程所有阶段进 行综合考虑而得到的; (2)从生存期的一个阶段到下一个阶段 所使用的方法与技术具有高度的连 续性;
基于三个模型的分析步骤
• 需求陈述
• • • •
对象建模 动态建模 功能建模 添加操作反复建模
三种模型的关系
在面向对象方法学中，对象模型是最基本的、最 重要的，它为其他两种模型奠定了基础，我们依靠对 象模型完成三种模型的集成。
1. 针对每个类建立的动态模型，描述了类实例的生命 周期或运行周期。
2 定义操作 操作定义了对象的行为并以某种方式修 改对象的属性值。操作可以通过对系统的 过程叙述的分析提取出来，通常叙述中的 动词可作为候选的操作。类所选择的每个 操作展示了类的某种行为。 操作大体可分为三类：
• 以某种方式操纵数据的操作（如，增加、 删除、重新格式化、选择）； • 完成某种计算的操作； • 为控制事件的发生而监控对象的操作。
实例：饮料自动售货机系统 设臵
一个饮料自动售货机可以放臵五种不同或部分相同的 饮料，可由厂商根据销售状况自动调配，并可随时重新 设臵售价，但售货机最多仅能放臵50罐饮料，其按钮设 计在各种饮料样本的下方，若经金额计算器累计金额足 够，则选择键灯会亮；若某一种饮料已销售完毕，则售 完灯会亮。
销售
顾客将硬币投入售货机，经累加金额足额的饮料选择 键灯亮，等顾客按键选择。顾客按键后饮料由取物楼掉 出，并自动结算及找钱。
4. 复审CRC卡 在填好所有CRC卡后，应对它进行复审。复 审应由客户和软件分析员参加，复审方法如 下： 1) 参加复审的人，每人拿CRC卡片的一个子集。 注意，有协作关系的卡片要分开，即，没有 一个人持有两张有协作关系的卡片。 2) 将所有用例/场景分类。 3) 复审负责人仔细阅读用例，当读到一个命名 的对象时，将令牌（token）传送给持有对 应类的卡片的人员。
定义服务
• 对象=属性+操作（服务） • 因为在动态模型和功能模型中更明确地描 述了每个类中应该提供哪些服务，所以在 建立了这两个模型后才能最终确定类中应 有的服务。 • 事实上，在确定类中应有的服务时，既要 考虑该类实体的常规行为，又要考虑在本 系统中特殊需要的服务。
• 1、常规行为 • 读写该类每个属性的操作。通常无需显示 表示这些常规操作。 • 2、从事件导出的操作 状态图中发往对象的事件就是该对象接收 到的消息。 3、与数据流图中处理框对应的操作 4、利用继承减少冗余操作 抽取类似的公共属性和操作，建立父类
4) 角色（如：管理者、工程师、销售员），他 们由与系统交互的人扮演； 5) 组织单位（如：部门、小组、小队），他们 与一个应用有关； 6) 场所（如：制造场所、装载码头），它们建 立问题和系统所有功能的环境； 7) 构造物（如，四轮交通工具、计算机），它 们定义一类对象，或者定义对象的相关类。
回答下列问题来识别潜在对象： • 是否有要储存、转换、分析或处理的信息？ • 是否有外部系统？ • 是否有模式（pattern）、类库和构件等？ • 是否有系统必须处理的设备？ • 是否有组织部分（organizational parts）?
(3)将OOA、OOD、OOP集成到生存 期的相应阶段.
分析模型
•对象模型:
•功能模型: •动态模型:
描述静态结构, 定义做
事情的实体
描述处理(数据变换),
指明系统应“做什么”
描述交互过程, 规定什么
时候做
OMT模型系统分析和设计过程概观图
产生需求 问题描述
建立模型
对象模型、动态模型、功能模型 结构及对象 设计
3. 标识协作者
一个类可以用它自己的操作去操纵它自己的属 性，从而完成某一特定的责任，一个类也可和其它 类协作来完成某个责任。如果一个对象为了完成某 个责任需要向其它对象发送消息，则我们说该对象 和另一对象协作。协作实际上标识了类间的关系。 为了帮助标识协作者，可以检索类间的类属关系。 如果两个类具有整体与部分关系，或者一个类必须 从另一个类获取信息，或者一个类依赖于另一个类， 则它们间往往有协作关系。
这种做法持续至所有的用例都完成为止。
动态建模
动态建模用来描述系统的动态行为，显 示对象在系统运行期间不同时刻的动态交互。 UML中用状态图、顺序图、活动图来建立动 态模型。
数据流图——建立功能模型
• 功能模型表明了系统中数据之间的依赖关 系，以及有关的数据处理功能，它由一组 数据流图组成。其中的处理功能可以用 IPO图、伪码等多种方式进一步描述。
类和对象模型的基本模型元素有类、对 象以及它们之间的关系。系统中的类和对 象模型描述了系统的静态结构，在UML中 用类图和对象图来表示。
一旦建立了系统的用例模型，则可以开始标识 候选类，并指明它们的责任和协作。Wirfs-Brock等人 提出了一种类-责任-协作者(Class-responsibilitycollaborator,CRC)开发类图的卡片技术。该技术使用实 际的或虚拟的索引卡片，为定义类提供较多的信息。其 中责任是与该类相关的属性和操作，协作者是为一个类 提供要完成的责任所需要的信息的那些类。通常，协作 意味着对信息的请求或者对某种操作的请求。 在确定属性和操作时，可把它们列在卡片上。由于 卡片的空间有限，使得每一个类都不能太复杂。如果不 能在一张卡片上列出所有的职责，该类应分成两个相关 的类。可在白板上自由移动卡片以组成类图，在卡片之 间画线表示关联与泛化。低科技的卡片技术可能比操作 软件用户界面要快，对开发人员通过会议讨论确定方案 很有效。
4) 收到令牌的类卡片持有者要描述卡片上记录 的责任，复审小组将确定该类的一个或多 个责任是否满足用例的需求。当某个责任 需要协作时，将令牌传给协作者，并重复 4）。 5) 如果卡片上的责任和协作不能适应用例，则 需对卡片进行修改，这可能导致定义新的 类，或在现有的卡片上刻画新的或修正的 责任及协作者。
分析的过程是提取系统需求的过程，主要包括：理 解、表达和验证。它通过建立以下三个模型来完成： – 对象模型 定义了做事情的实体，描述系统的数据结构，包括 对象之间的关系、对象的属性和操作，用对象图表示。 – 功能模型 说明发生什么，它只关心系统做什么，而不考虑怎 么做，描述系统的功能结构，用数据流程图DFD描述。 – 动态模型 明确规定了什么时候做（即在何种状态下接受了什 么事件的触发），描述系统的控制结构，即：描述类的 对象的状态和事件的正确次序。 每个类的动态行为用一张状态图来描绘，各个类的状 态图通过共享事件合并起来，从而构成系统的动态模型。
4) 公共属性：可以为潜在的对象定义一组属性， 这些属性适用于该类的所有实例； 5) 公共操作：可以为潜在的对象定义一组操作， 这些操作适用于该类的所有实例； 6) 必要的需求：出现在问题空间中的外部实体 以及对系统的任何解决方案的实施都是必要 的生产或消费信息，它们几乎总是定义为需 求模型中的类。
分 析 阶 段
详细的对象模型 详细的动态模型 详细的功能模型
设 计 阶 段
面向对象分析 Object-Oriented Analysis
面向对象分析的一般步骤如下：
1. 获 取 客 户 对 系 统 的 需 求 ： 包 括 标 识 场 景 （scenario）和用例（use case也称用况）， 以及建造需求模型 2. 建立对象模型。 3. 建立功能模型。 4. 建立动态模型。 5. 利用用例/场景来复审分析模型。
数据流图
功能模型：模型
类图：视图
对象模型：模型
分析模型：模型
顺序图：视图 状态图：视图 活动图：视图 动态模型：模型
分析模型的构成
用例建模——需求分析
用例建模是用于描述一个系统应该做什么的 建模技术，用例建模不仅用于新系统的需求获 取，还可用于已有系统的升级。用例模型用用 例图来描述。
静态建模（对象模型）
属于
存量计算器
饮料号码 存量 递减 售完显示 重置
属于
属于
购买
退币杆
退币杆状态
拉动
被拉动
顾客
姓名 硬币 投币-置入 拿取饮料
选取
选择钮
选择钮状态 灯亮 灯熄 售完灯亮 按钮
举例：饮料自动售货机系统的事件追踪图
顾客
售货机 金额计算器
累加 总额
选择键 存量计算器 售完灯
投入硬币
显示总额
金额总够 灯亮 选择按纽 选择键 # 饮料 结算 余额 找零 扣减存量 存量为零 灯亮
销售
顾客将硬币投入售货机，经累加金额足额的饮料选择 键灯亮，等顾客按键选择。顾客按键后饮料由取物楼掉 出，并自动结算及找钱。
取消交易
顾客可在按下选择键前任何一个时刻，拉动退币杆取 消交易收回硬币。
饮料自动售货机系统对象图
金额计算器
金额 累加 找零 重置
属于
贩卖机
饮料号码 价格 投币-接受 饮料掉出 金额显示 按纽 退币杆 售完显示
举例：饮料自动售货机系统的状态图
Do:显示售货机在备用 所有灯都关闭 Do:显示金额总数
投入硬币 （有效的） 投入硬币金额
(1元、5元、10元)
无效的硬币 取消 取消
回到备用状态
Do:显示金额已够 饮料选择灯亮 按下选择饮料键
取出饮料 结算找零 扣减存量 完成交易
金额不足 再投币
• 业务中的执行者扮演什么角色？这些角色可以 看作类，如客户、操作员等。
（2）筛选对象类，确定最终对象类 我们可以用以下选择特征来确定最终的对象： 1) 保留的信息：仅当必须记住有关潜在对象的 信息，系统才能运作时，则该潜在对象在分 析阶段是有用的； 2) 需要的服务：潜在对象必须拥有一组可标识 的操作，它们可以按某种方式修改对象属性 的值； 3) 多个属性：在分析阶段，关注点应该是“较 大的”信息（仅具有单个属性的对象在设计 时可能有用，但在分析阶段，最好把它表示 为另一对象的属性）；
-端2 *
-端1 *
供货
<<uses>> 打开机器 <<uses>> <<uses>> <<uses>>
供货人
-端2 -端1 * *
关闭机器
取货款
收银员
找出饮料自动售货机系统中的对象 设臵
一个饮料自动售货机可以放臵五种不同或部分相同的 饮料，可由厂商根据销售状况自动调配，并可随时重新 设臵售价，但售货机最多仅能放臵50罐饮料，其按钮设 计在各种饮料样本的下方，若经金额计算器累计金额足 够，则选择键灯会亮；若某一种饮料已销售完毕，则售 完灯会亮。
2. 状态转换驱使行为发生，这些行为在数据流图中被 映射成处理，它们同时与对象模型中的服务相对应。 3. 功能模型中的处理，对应于对象模型中类-&-对象所 提供的服务。
三种模型的关系
4. 功能模型中的数据存储，以及数据的源点/终点， 通常是对象模型中的对象。
5. 功能模型中的数据流，往往是对象模型中的属性 值，也可能是整个对象。 6. 功能模型中的处理可能产生动态模型中的事件。 7. 对象模型描述了功能模型中的动作对象、数据存 储以及数据流的结构。
确定类
1. 标识类
这里介绍一种类—责任—协作者 （class—responsibility—collaborator，简 称CRC）技术。CRC实际上是一组表示类的 索引卡片，每张卡片分成三部分，它们分别 描述类名、类的责任和类的协作者。
类名：
责任： 协作者：
(1) 标识潜在的对象类 通常陈述中的名词或名词短语是可能的潜 在对象，它们以不同的形式展示出来，如： 1) 外部实体（如，其它系统、设备、人员）， 他们生产或消费计算机系统所使用的信息； 2) 物件（如，报告、显示、信函、信号），它 们是问题信息域的一部分； 3) 发生的事情或事件（如，性能改变或完成一 组机器人移动动作），它们出现在系统运行 的环境中；
取消交易
顾客可在按下选择键前任何一个时刻，拉动退币杆取 消交易收回硬币。
自动售货系统系统
-端1 * -端2
自动售货系统::售货
*
顾客
-端2
-端1 *
自动售货系统::供货
*
供货人
-端1 * -端2
自动售货系统::取货款
*
收银员
自动售货系统系统
-端1Hale Waihona Puke Baidu*
-端2
售货
*
<<extends>>
售散装饮料
顾客
第10章 面向对象分析
第10章 面向对象分析
• 面向对象软件开发技术
– 面向对象分析(OOA) – 面向对象设计(OOD) – 面向对象实现(OOP)
面向对象技术是一个有全新概念 的开发模式,其特点是:
(1)方法是对软件开发过程所有阶段进 行综合考虑而得到的; (2)从生存期的一个阶段到下一个阶段 所使用的方法与技术具有高度的连 续性;
基于三个模型的分析步骤
• 需求陈述
• • • •
对象建模 动态建模 功能建模 添加操作反复建模
三种模型的关系
在面向对象方法学中，对象模型是最基本的、最 重要的，它为其他两种模型奠定了基础，我们依靠对 象模型完成三种模型的集成。
1. 针对每个类建立的动态模型，描述了类实例的生命 周期或运行周期。
2 定义操作 操作定义了对象的行为并以某种方式修 改对象的属性值。操作可以通过对系统的 过程叙述的分析提取出来，通常叙述中的 动词可作为候选的操作。类所选择的每个 操作展示了类的某种行为。 操作大体可分为三类：
• 以某种方式操纵数据的操作（如，增加、 删除、重新格式化、选择）； • 完成某种计算的操作； • 为控制事件的发生而监控对象的操作。
实例：饮料自动售货机系统 设臵
一个饮料自动售货机可以放臵五种不同或部分相同的 饮料，可由厂商根据销售状况自动调配，并可随时重新 设臵售价，但售货机最多仅能放臵50罐饮料，其按钮设 计在各种饮料样本的下方，若经金额计算器累计金额足 够，则选择键灯会亮；若某一种饮料已销售完毕，则售 完灯会亮。
销售
顾客将硬币投入售货机，经累加金额足额的饮料选择 键灯亮，等顾客按键选择。顾客按键后饮料由取物楼掉 出，并自动结算及找钱。
4. 复审CRC卡 在填好所有CRC卡后，应对它进行复审。复 审应由客户和软件分析员参加，复审方法如 下： 1) 参加复审的人，每人拿CRC卡片的一个子集。 注意，有协作关系的卡片要分开，即，没有 一个人持有两张有协作关系的卡片。 2) 将所有用例/场景分类。 3) 复审负责人仔细阅读用例，当读到一个命名 的对象时，将令牌（token）传送给持有对 应类的卡片的人员。
定义服务
• 对象=属性+操作（服务） • 因为在动态模型和功能模型中更明确地描 述了每个类中应该提供哪些服务，所以在 建立了这两个模型后才能最终确定类中应 有的服务。 • 事实上，在确定类中应有的服务时，既要 考虑该类实体的常规行为，又要考虑在本 系统中特殊需要的服务。
• 1、常规行为 • 读写该类每个属性的操作。通常无需显示 表示这些常规操作。 • 2、从事件导出的操作 状态图中发往对象的事件就是该对象接收 到的消息。 3、与数据流图中处理框对应的操作 4、利用继承减少冗余操作 抽取类似的公共属性和操作，建立父类
4) 角色（如：管理者、工程师、销售员），他 们由与系统交互的人扮演； 5) 组织单位（如：部门、小组、小队），他们 与一个应用有关； 6) 场所（如：制造场所、装载码头），它们建 立问题和系统所有功能的环境； 7) 构造物（如，四轮交通工具、计算机），它 们定义一类对象，或者定义对象的相关类。
回答下列问题来识别潜在对象： • 是否有要储存、转换、分析或处理的信息？ • 是否有外部系统？ • 是否有模式（pattern）、类库和构件等？ • 是否有系统必须处理的设备？ • 是否有组织部分（organizational parts）?
(3)将OOA、OOD、OOP集成到生存 期的相应阶段.
分析模型
•对象模型:
•功能模型: •动态模型:
描述静态结构, 定义做
事情的实体
描述处理(数据变换),
指明系统应“做什么”
描述交互过程, 规定什么
时候做
OMT模型系统分析和设计过程概观图
产生需求 问题描述
建立模型
对象模型、动态模型、功能模型 结构及对象 设计
3. 标识协作者
一个类可以用它自己的操作去操纵它自己的属 性，从而完成某一特定的责任，一个类也可和其它 类协作来完成某个责任。如果一个对象为了完成某 个责任需要向其它对象发送消息，则我们说该对象 和另一对象协作。协作实际上标识了类间的关系。 为了帮助标识协作者，可以检索类间的类属关系。 如果两个类具有整体与部分关系，或者一个类必须 从另一个类获取信息，或者一个类依赖于另一个类， 则它们间往往有协作关系。
这种做法持续至所有的用例都完成为止。
动态建模
动态建模用来描述系统的动态行为，显 示对象在系统运行期间不同时刻的动态交互。 UML中用状态图、顺序图、活动图来建立动 态模型。
数据流图——建立功能模型
• 功能模型表明了系统中数据之间的依赖关 系，以及有关的数据处理功能，它由一组 数据流图组成。其中的处理功能可以用 IPO图、伪码等多种方式进一步描述。
类和对象模型的基本模型元素有类、对 象以及它们之间的关系。系统中的类和对 象模型描述了系统的静态结构，在UML中 用类图和对象图来表示。
一旦建立了系统的用例模型，则可以开始标识 候选类，并指明它们的责任和协作。Wirfs-Brock等人 提出了一种类-责任-协作者(Class-responsibilitycollaborator,CRC)开发类图的卡片技术。该技术使用实 际的或虚拟的索引卡片，为定义类提供较多的信息。其 中责任是与该类相关的属性和操作，协作者是为一个类 提供要完成的责任所需要的信息的那些类。通常，协作 意味着对信息的请求或者对某种操作的请求。 在确定属性和操作时，可把它们列在卡片上。由于 卡片的空间有限，使得每一个类都不能太复杂。如果不 能在一张卡片上列出所有的职责，该类应分成两个相关 的类。可在白板上自由移动卡片以组成类图，在卡片之 间画线表示关联与泛化。低科技的卡片技术可能比操作 软件用户界面要快，对开发人员通过会议讨论确定方案 很有效。
4) 收到令牌的类卡片持有者要描述卡片上记录 的责任，复审小组将确定该类的一个或多 个责任是否满足用例的需求。当某个责任 需要协作时，将令牌传给协作者，并重复 4）。 5) 如果卡片上的责任和协作不能适应用例，则 需对卡片进行修改，这可能导致定义新的 类，或在现有的卡片上刻画新的或修正的 责任及协作者。
分析的过程是提取系统需求的过程，主要包括：理 解、表达和验证。它通过建立以下三个模型来完成： – 对象模型 定义了做事情的实体，描述系统的数据结构，包括 对象之间的关系、对象的属性和操作，用对象图表示。 – 功能模型 说明发生什么，它只关心系统做什么，而不考虑怎 么做，描述系统的功能结构，用数据流程图DFD描述。 – 动态模型 明确规定了什么时候做（即在何种状态下接受了什 么事件的触发），描述系统的控制结构，即：描述类的 对象的状态和事件的正确次序。 每个类的动态行为用一张状态图来描绘，各个类的状 态图通过共享事件合并起来，从而构成系统的动态模型。
4) 公共属性：可以为潜在的对象定义一组属性， 这些属性适用于该类的所有实例； 5) 公共操作：可以为潜在的对象定义一组操作， 这些操作适用于该类的所有实例； 6) 必要的需求：出现在问题空间中的外部实体 以及对系统的任何解决方案的实施都是必要 的生产或消费信息，它们几乎总是定义为需 求模型中的类。
分 析 阶 段
详细的对象模型 详细的动态模型 详细的功能模型
设 计 阶 段
面向对象分析 Object-Oriented Analysis
面向对象分析的一般步骤如下：
1. 获 取 客 户 对 系 统 的 需 求 ： 包 括 标 识 场 景 （scenario）和用例（use case也称用况）， 以及建造需求模型 2. 建立对象模型。 3. 建立功能模型。 4. 建立动态模型。 5. 利用用例/场景来复审分析模型。
数据流图
功能模型：模型
类图：视图
对象模型：模型
分析模型：模型
顺序图：视图 状态图：视图 活动图：视图 动态模型：模型
分析模型的构成
用例建模——需求分析
用例建模是用于描述一个系统应该做什么的 建模技术，用例建模不仅用于新系统的需求获 取，还可用于已有系统的升级。用例模型用用 例图来描述。
静态建模（对象模型）
属于
存量计算器
饮料号码 存量 递减 售完显示 重置
属于
属于
购买
退币杆
退币杆状态
拉动
被拉动
顾客
姓名 硬币 投币-置入 拿取饮料
选取
选择钮
选择钮状态 灯亮 灯熄 售完灯亮 按钮
举例：饮料自动售货机系统的事件追踪图
顾客
售货机 金额计算器
累加 总额
选择键 存量计算器 售完灯
投入硬币
显示总额
金额总够 灯亮 选择按纽 选择键 # 饮料 结算 余额 找零 扣减存量 存量为零 灯亮
销售
顾客将硬币投入售货机，经累加金额足额的饮料选择 键灯亮，等顾客按键选择。顾客按键后饮料由取物楼掉 出，并自动结算及找钱。
取消交易
顾客可在按下选择键前任何一个时刻，拉动退币杆取 消交易收回硬币。
饮料自动售货机系统对象图
金额计算器
金额 累加 找零 重置
属于
贩卖机
饮料号码 价格 投币-接受 饮料掉出 金额显示 按纽 退币杆 售完显示
举例：饮料自动售货机系统的状态图
Do:显示售货机在备用 所有灯都关闭 Do:显示金额总数
投入硬币 （有效的） 投入硬币金额
(1元、5元、10元)
无效的硬币 取消 取消
回到备用状态
Do:显示金额已够 饮料选择灯亮 按下选择饮料键
取出饮料 结算找零 扣减存量 完成交易
金额不足 再投币
• 业务中的执行者扮演什么角色？这些角色可以 看作类，如客户、操作员等。
（2）筛选对象类，确定最终对象类 我们可以用以下选择特征来确定最终的对象： 1) 保留的信息：仅当必须记住有关潜在对象的 信息，系统才能运作时，则该潜在对象在分 析阶段是有用的； 2) 需要的服务：潜在对象必须拥有一组可标识 的操作，它们可以按某种方式修改对象属性 的值； 3) 多个属性：在分析阶段，关注点应该是“较 大的”信息（仅具有单个属性的对象在设计 时可能有用，但在分析阶段，最好把它表示 为另一对象的属性）；
-端2 *
-端1 *
供货
<<uses>> 打开机器 <<uses>> <<uses>> <<uses>>
供货人
-端2 -端1 * *
关闭机器
取货款
收银员
找出饮料自动售货机系统中的对象 设臵
一个饮料自动售货机可以放臵五种不同或部分相同的 饮料，可由厂商根据销售状况自动调配，并可随时重新 设臵售价，但售货机最多仅能放臵50罐饮料，其按钮设 计在各种饮料样本的下方，若经金额计算器累计金额足 够，则选择键灯会亮；若某一种饮料已销售完毕，则售 完灯会亮。
2. 状态转换驱使行为发生，这些行为在数据流图中被 映射成处理，它们同时与对象模型中的服务相对应。 3. 功能模型中的处理，对应于对象模型中类-&-对象所 提供的服务。
三种模型的关系
4. 功能模型中的数据存储，以及数据的源点/终点， 通常是对象模型中的对象。
5. 功能模型中的数据流，往往是对象模型中的属性 值，也可能是整个对象。 6. 功能模型中的处理可能产生动态模型中的事件。 7. 对象模型描述了功能模型中的动作对象、数据存 储以及数据流的结构。
确定类
1. 标识类
这里介绍一种类—责任—协作者 （class—responsibility—collaborator，简 称CRC）技术。CRC实际上是一组表示类的 索引卡片，每张卡片分成三部分，它们分别 描述类名、类的责任和类的协作者。
类名：
责任： 协作者：
(1) 标识潜在的对象类 通常陈述中的名词或名词短语是可能的潜 在对象，它们以不同的形式展示出来，如： 1) 外部实体（如，其它系统、设备、人员）， 他们生产或消费计算机系统所使用的信息； 2) 物件（如，报告、显示、信函、信号），它 们是问题信息域的一部分； 3) 发生的事情或事件（如，性能改变或完成一 组机器人移动动作），它们出现在系统运行 的环境中；
取消交易
顾客可在按下选择键前任何一个时刻，拉动退币杆取 消交易收回硬币。
自动售货系统系统
-端1 * -端2
自动售货系统::售货
*
顾客
-端2
-端1 *
自动售货系统::供货
*
供货人
-端1 * -端2
自动售货系统::取货款
*
收银员
自动售货系统系统
-端1Hale Waihona Puke Baidu*
-端2
售货
*
<<extends>>
售散装饮料
顾客