第10章面向对象讲解_第1页
第10章面向对象讲解_第2页
第10章面向对象讲解_第3页
第10章面向对象讲解_第4页
第10章面向对象讲解_第5页
已阅读5页,还剩23页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、第10章面向对象分析10.1面向对象分析的基本过程不论采用哪种软件工程方法开发软件,需求分析的主要工作都是:理解需求、表达需求和验证需求,下面的图概括 地表示了参照当前系统建立目标系统的过程。怎么做做什么抽象化逻辑模型理辭需求导出表达需求图:参照当前系统建立目标系统面向对象分析 (Object-Oriented Analysis,简称 00A)的关键就是识别出对象与类,并分析它们之间的关系,最终建立对象模型、动态模型和功能模型。10.1.1 概述系统分析员要善于学习、勇于实践,更重要的是一切从实 际出发。注 “00A就是抽取和整理用户需求并建立问题域精确模型的过程。”(P231)这在一开始能做

2、到吗?一一扯蛋10.1.2 3个子模型与5个层次面向对象建模需建立包含系统的三个要素:1)静态结构(对象模型)、2)交互次序(动态模型)、3)数据交换(功 能模型)。建立系统模型的过程是一个迭代(iterations )式的自顶 向下的求精过程。对于一个大型复杂系统来说 对象模型 一般 由下述5个层次组成:图10.2复杂问题的对象模型的 5个层次其中主题层是指从一个更高(高于“类”)的抽象层次来描述对象模型(即从一个相当高的层次上描述总体模型),通过划分“主题”把一个复杂系统的对象模型分解成几个不 同的概念范畴。其实上述5个层次就是 00A中建立对象模型的 5项主 要工作:找出类和对象,识别结

3、构(类或对象之间的关系), 识别主题、定义属性、定义服务。我们知道动态模型和功能 模型中都包含了对象模型中的操作,因此人们在定义每个类中的服务前,往往先建立起动态模型和功能模型,这样说来 OOA大体上可按下列顺序进行:(1)确定类和对象(2)确定关联(3)划分主题(4)定义属性(5)确定继承关系(6)建立动态模型(7) 建立功能模型(8) 定义服务需要注意地是在这里我们根本不强调顺序,更不是谈什么步骤。10.2需求陈述需求陈述的主要任务是准确地回答“系统必须做什么?”,而不是“系统应该怎么做?”10.2.1书写要点1022例子我们用 “ ATM 系统”(ATM 是 Automatic Tell

4、er Machine 的缩写,意即自动柜员机)的开发作为OOA&OOD的实例图10.2ATM系统10.3建立对象模型10.3.1确定类与对象1. 找出候选的类与对象(例:P236 ATM系统)一般来说,大千世界中的客观事物可分为5类:1)可感知的物理实体,如:飞机,汽车,房屋2)人或组织的角色,如:教师,医生,计算机系,学生 处3)应该记忆的事件,如:飞行,演出,访问,交通事故4)对象的相互作用,如:购买,结婚,纳税5)概念,如:政策,刑法,泛化,集合2. 筛选出正确的类与对象我们需要确定的类与对象是:(1)应该记录的对象(2)需要它提供服务的对象同时要关注下述6个方面:1)冗余:去掉冗余的类

5、(如“用户”)2)无关:去掉无关的类(如“储蓄所”)3)笼统:去掉笼统的类(如“银行”)4)属性:区分属性和类(某个性质若具有很强的 独立性应当作为“类”)5)操作:区分操作和类(本身具有属性且需独立存 在的“操作”应当作为“类”)6)实现:忽略实现内容(应当去掉仅和实现有关 的“类”,如“事务日志”)10.3.2确定关联对象之间的相互依赖、相互作用的关系就是关联。在分析的起始阶段,我们不必花过多的精力去区分关联和聚集,聚集不过是一种特殊的关联,是关联的一个特例。1.初步确定关联P238通过分析动词词组我们可以得出大多数关联(例:ATM系统)2. 筛选筛选时要关注下述5个方面:1)已删去的类之

6、间的关联也要删除2)无关的或在实现阶段考虑的关联要删除3)描述瞬时事件的关系不应作为关联(关联应该描 述问题域的静态结构)4)三个或三个以上对象的关联要作分解或描述成限 定关联5)冗余关联要删除3. 进一步完善完善时要关注下述4个方面:1)正名:选择更明确的名字作为关联名2)分解:分解已确定的类以适用关联3)补充:及时补充遗漏关联4)标明重数:但无需花过多精力图10.3ATM系统原始的类图1033划分主题按问题领域而不是用功能分解来高度概括主题10.3.4确定属性属性是类中所定义的 数据,它表明了对象的性质。一般来说,确定属性的过程包括分析和选择两个步骤:1.分析通常用名词词组表示属性, 口:

7、“汽车的颜色”、“光 标的位置”,而用形容词表示可枚举的具体属性,如:“红 色的”、“白色的”。在分析阶段应该仅考虑与具体应用直接相关的属性, 不要考虑那些纯粹用于实现的属性。2.选择选择时要关注下述6个方面:1)区分对象与属性(仅关注其值的是属性);2)区分关联类属性与对象属性(例:依赖某个 关联链的性质是关联类属性);3)区分限定词和属性(能用限定词更好)4)区分内部状态和属性(例:某性质是对象的 内部状态)5)忽略无影响的属性(在分析阶段应该忽略对 大多数操作无影响的属性)6)注意属性的相关性(分解该“类”)图10.4ATM系统对象模型中的属性10.3.5识别继承关系确定了类中的属性之后

8、, 就可以利用继承机制共享公共 性质,并对众多的类重新加以组织。一般来说,可以应用两种方式建立继承(即泛化)关系:(1)自底向上:抽象出现有类的共同性质泛化出父软件工程导论(第五版)11类;(2)自顶向下:把现有类细化成更具体的子类。ATM付出倔中央计牡机代 码拥ffE输人站输入1十日期L-F相员申务远幹K H拥站号仃输输連佰拥 !甘打 ri号VI慵户地址现金兑換尺Iiii 眼皴图10.5带有继承关系的ATM对象模型对象模型的建立是一个反复修改、逐步完善的迭代过 程。对于初学者来说,可尝试用面向对象方法开发几个较小 系统,取得一定的经验后,再总结更适合自己的工作方式。1. 分解“现金兑换卡”类

9、2. “事务”由“更新”组成3. 把“分行”与“分行计算机”合并图10.6修改后的ATM对象模型般来说,建立动态模型的典型步骤如下:(1)编写脚本,确保不遗漏正常的交互行为;(2)从脚本中提取事件 ,确定每个事件的发送对象(触发该事件动作的对象)和接受对象;(3)画事件跟踪图(Sequence Diagram,时序图或顺序图,描述对象之间的时间顺序)(4)画状态图(5)审查状态图的完整性和一致性10.4.1编写脚本脚本是指系统在某一执行期间内出现的一系列事件(脚本描述事件序列,是用例的实例,是系统的一种实际使用方 法。),它描述用户(或其它外部设备)与系统之间的交互 过程;对于每个事件,脚本都

10、应该指明触发该事件的动作对 象(如:系统、用户或其它外部事物)、接受事件的目标对象,以及该事件的参数。目的编写脚本的目的是保证不遗漏重要的交互步骤实质编写脚本的实质是分析用户对与系统交互过程 的要求。编写脚本时,首先编写正常情况的脚本,其次考虑特殊情况,最后考虑出错情况;如有可能还应该允许用户“异常 操作”。此外还应该提供“在线帮助”、状态查询等在基本交 互行为之上的“通用”交互行为。表10+1 ATM系统的正常情况脚本* ATM请储户插卡;储户插入一张现金兑换卡*矗丁甌接受该卡并读它上面的井新代码和卡号*人丁皿要求储户输人密码:储户输人自己的密码12副等数字* ATM请求总行验证卡号和密码*

11、 ATM请储户播卡|储户捆入一张现金兑换卡* ATN1接哽这张卡井顺序读它上面的数字* ATM要求密码储户误输入關貂-AT賊请求总行验证输入的数字和密码:总行在向有关分行咨询之后拒絶这张卡-ATM显示“密码错J并情储户克浙输人密码储户输人1234i ATM疔验证后知道这尖输.人的犠码正确* ATM请储户选择书务类型储户选择“取就 ATN1询何取款额;储户改变主意不想取款了,他捷下“取消”鹽* ATN1退出现金兑换卡并请储户拿走它辛储户拿走他的卡* AT賊请储户插卡总行要求39号分行核对储户密码*然后通知ATM说这张卡 有效-ATNI要求储户选择事务类型(取款,转账、査询等*储户选择取款”* A

12、TM要求话户输入取款额储户输人阴0* ATM确认取款额在预先规定的限额内,然后要求总行处理这个事务;总行把请求转给分行,谏分 行成功地处理完这顼事务并返回该账户的新余额* ATM吐出现金并请储户拿走这些现金;储户拿走现金* ATM何储户是否继鎮这项事务;储户回答不掷* ATM打印底单,退出现金兑换卡,请储户拿走它们|储户取走账单和卡* ATM请储户摘卡用户界面是用户对系统的“第一感”,它往往对用户是表10. 2 ATM系统的异常情况御本否喜欢一个系统起很重要的作用,因此在分析阶段也不能完全忽略用户界面。 设计用户界面时重要的是用户和系统进行 信息交换的方式。向储户显示的信息E H H B S

13、CH E E S E | | ENTER |CLEAR| |CANCER胀单出口现金出口图10.7 ATM的界面格式10.4.3画事件跟踪图脚本为建立动态模型(状态图)提供了很好的基础,但 用自然语言书写的脚本还不够简明,并且会有二义性,因此 在画状态图前,我们往往先画出事件跟踪图简化的UML顺 序图(Sequence Diagram,时序图),为此需进一步明确事件(事件就是引起系统做动作或(和)转换状态的控制信息) 及事件与对象的关系。1.确定事件事件包括系统与用户(或外部设备)交互的所有信号、输入、输出、中断、动作等,要注意的是(1)对象的动作也是事件;(2)对控制流产生相同效果的那些事件

14、应作为 一类事件。经过分析要确定每类事件的发送对象和接受对象。2.画出事件跟踪图从脚本中提取出各类事件, 并确定每类事件的发送对象 和接受对象,就可以用事件跟踪图把事件序列以及事件与对 象的关系表示出来,事件跟踪图是扩充的脚本,更是简化了 的UML顺序图。關户ATM总行箱入密円 1要求耶岛嬖叫1辅人娴输人也款斂i n上出我急诵求玄走现金r请求墩劇匕鄭疔f給康 .请求京世忙显示主屏秫请求验址厳F账门仃效曲求处理啪务琳务成功图10.8ATM系统正常情况脚本的事件跟踪图(时序图) 1044画状态图状态图描述了事件与对象状态(对象生命周期中的阶 段)的关系。UML用状态图来表示对象的动态行为,它确定了

15、由事 件序列引出的状态序列。 系统分析员应仅考虑系统内具有重 要交互行为的哪些类, 即每个主动发送事件的对象类的动态 行为用一张状态图来表示, 各个类的状态图通过共享事件合 并起来,从而构成系统的动态模型。从一张事件跟踪图出发画状态图时,象的事件,即考虑指向某条竖线(对象)的箭头线,把这些 事件作为状态图中的有向边(箭头线),边上标以事件名,两个事件之间的间隔就是一个状态。厂 W卄赫为!护j怡鬼丿不可凑的3显示不可J 怡息取消 、J;恥1需息丄3打印談草do !】;A?心I杜rnuIK)中止収消如吐卅现金; 讥求吐现余do:弁求唯续现金羽弗底功(d时辿伸F务)_(曲尖飒信云)-图10.9 AT

16、M类的状态图血聚讯味户 血牌求犬)zz二代码打H事事务关成K有效代耐I请求峥购一韦攻图10.10总行类的状态图图10.11分行类的状态图1045审查动态模型各个类的状态图通过共享事件合并起来,就构成了系统的“动态模型”,应该细致审查动态模型的完整性和一致性10.5建立功能模型功能模型表明了系统中数据之间的依赖关系,以及有关的数据处理功能,它由一组DFD组成,其中处理功能可以用IPO图(或表)、伪码等描述。10.5.1画出基本系统模型图最高层的DFD图10.12ATM系统的基本系统模型10.5.2画出功能级数据流图现金tirar iK确密叫现値 能n图10.13ATM系统的功能级数据流图10.5

17、.3描述处理框功能表163对更新账户功能的描述更新账户(账号*事务类型*金额)f现金额厳单數据信息如果耻款额趙过底户当前余赫,拒绝该事务且不忖出现金如果取款额不超过账户当飙余制从余额中减去取款额后柞为新的余额,忖出储户要取的现金 如果事务是存款.把存款额加劃余额中得到新余额,不忖出现金“如果事务是查询,不忖出现金,在上述任何一种情况不,账单内容都是ATM号,日期,时间,账号,事务类型,事务金额如果有 的话匕新余额10.6定义服务对象是由描述其属性的数据,以及可以对这些数据施加的操作,封装在一起构成的独立单元。在确定类中的操作时,既要考虑该类实体的常规行为,又要考虑本系统中特殊的服务。1. 常规行为在分析阶段可以认为,类中定义的每个属性都是可以访问的,也就是类中已经定义了读、写该类每个属性的操作,而无需显式表示这些常规操作。2. 从事件导出的操作状态图中若有发往对象的事件,该对象必须要有相应的操作3. 与数据流图中处理逻辑对应的操

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论