第10章 面向对象分析

软件工程
第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. 利用用例/场景来复审分析模型。
属于
存量计算器