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