软件工程第10章不讲.pptVIP

第10章 面向对象分析 10.1 面向对象分析的基本过程 10.2 需求陈述 10.3 建立对象模型 10.4 建立动态模型 10.5 建立功能模型 10.6 定义服务 10.7 小结 ATM类的状态图 大多数交互行为都可以分为应用逻辑和用户界面两部分。 应用逻辑是内在的、本质的内容，用户界面是外在的表现形式。 首先集中精力考虑系统的信息流和控制流。 采用不同界面(例如，命令行或图形用户界面)，可以实现同样的程序逻辑。 动态模型着重表示应用系统的控制逻辑。 软件开发人员往往快速地建立起用户界面的原型，供用户试用与评价。 10.4.2 设想用户界面 ATM界面格式 通常在画状态图之前先画出事件跟踪图，明确事件及事件与对象的关系。 1. 确定事件 分析每个脚本，从中提取出所有外部事件。 事件包括系统与用户(或外部设备)交互的所有信号、输入、输出、中断、动作等等。 从脚本中找出正常事件、异常事件和出错条件。 传递信息的对象的动作也是事件。 例如，储户插入现金兑换卡、储户输入密码、ATM吐出现金等都是事件。大多数对象到对象的交互行为都对应着事件。 10.4.3 画事件跟踪图 应该把对控制流产生相同效果的那些事件组合在一起作为一类事件，并给它们取一个惟一的名字。 例如，“吐出现金”是一个事件类，参数值不同(吐出的现金数额不同)并不影响控制流。 应该把对控制流有不同影响的那些事件区分开来，不要误把它们组合在一起。例如“账户有效”、“账户无效”、“密码错”等都是不同的事件。 一般说来，不同应用系统对相同事件的响应并不相同，若从状态图中看出某些事件之间的差异对系统行为并没有影响，则忽略这些事件间的差异。 应该区分出每类事件的发送对象和接受对象。 画事件跟踪图 2. 画出事件跟踪图 事件跟踪图实质上是扩充的脚本，是简化的UML顺序图。 一条竖线代表一个对象 每个事件用一条水平的箭头线表示 箭头方向从事件的发送对象指向接受对象。 时间从上向下递增 箭头线之间的间距并没有具体含义 用箭头线在垂直方向上的相对位置表示事件发生的先后，并不表示两个事件之间的精确时间差。 画事件跟踪图 ATM系统正常情况下的 事件跟踪图 一张状态图描绘一类对象的行为，确定了由事件序列引出的状态序列的关系。 从一张事件跟踪图出发画状态图时，仅考虑事件跟踪图中指向某条竖线的那些箭头线。两个事件之间的间隔就是一个状态。 把其他脚本的事件跟踪图合并到已画出的状态图中。 考虑完正常事件之后再考虑边界情况和特殊情况 例如，用户取消该事务、 产生“超时”事件等 当状态图覆盖了所有脚本，包含了影响某类对象状态的全部事件时，该类的状态图就构造出来了。 10.4.4 画状态图 只考虑“ATM”、“总行”、“柜员终端”和“分行”四类主动对象的状态图。 “现金兑换卡”、“事务”和“账户”是被动对象，并不发送事件。 “储户”和“柜员” 都是系统外部对象，无须在系统内实现。 ATM系统状态图 总行类的状态图 分行类的状态图 通过共享事件合并各个类的状态图，构成系统的动态模型。 完成具有重要交互行为的各个类的状态图，检查系统级的完整性和一致性。 通常每个事件应既有发送对象又有接受对象，发送者和接受者可以是同一个对象。 应着重审查没有前驱或没有后继的状态，若既不是交互序列的起点也不是终点，则出现错误。 审查每个事件，跟踪它对系统中各个对象所产生的效果，以保证它们与每个脚本都匹配。 10.4.5 审查动态模型 功能模型由一组数据流图表明系统数据之间的依赖关系和处理功能。 处理功能可以用IPO图(或表)、伪码等多种方式描述。 画出基本系统模型图 由若干个数据源点/终点和代表系统加工、变换数据整体功能的一个处理框组成。 基本系统模型指明了目标系统的边界。 10.5 建立功能模型 ATM系统的基本系统模型 画出功能级数据流图 分解处理框，描述系统加工、变换数据的基本功能。 描述处理框功能 描述分解细化的数据流图中各个处理框的功能。 通常使用说明性描述规定输入值和输出值之间的关系，以及输出值应遵循的规律。 建立功能模型 ATM系统的功能级数据流图 完整的对象模型既要定义类的属性，又要定义类的服务。 动态模型和功能模型明确地描述了每个类中应该提供哪些服务，最终确定类中应有的服务。 在确定类中应有的服务时，要考虑该类实体的常规行为和在本系统中特殊需要的服务。 1. 常规行为 无需在类图中表示类中定义的读、写每个属性的操作。 2. 从事件导出的操作 状态图中发往对象的事件也就是该对象接收到的消息，该对象必须指定操作修改对象状态（即属性值），启动服务（接受事件的对象在相应状态的行为）。 10.6 定义服务 例如，在ATM系统中，发往ATM对象的事件“中止”，启动该对象的服务“打印账单”；