软件工程第10章面向对象资料.ppt

* * * * * * * * 10.4. 4画状态图 状态图描绘事件与对象状态的关系。 一张状态图描绘一类对象的行为，它确定了由事件序列引出的状态序列。应该集中精力仅考虑具有重要交互行为的那些类 以ATM系统为例： “ATM”、“柜员终端”、“总行”和“分行”都是主动对象，它们相互发送事件； 而“现金兑换卡”、“事务”和“账户”是被动对象，并不发送事件。 “储户”和“柜员”虽然也是动作对象，但是，它们都是系统外部的因素，无须在系统内实现它们。因此，只需要考虑“ATM”、“总行”、“柜员终端”和“分行”的状态图。 10.4. 4画状态图 从一张事件跟踪图出发画状态图时，应该集中精力仅考虑影响一类对象的事件,即仅考虑事件跟踪图中指向某条竖线的那些箭头线。 通常，从事件跟踪图中当前考虑的竖线射出的箭头线，是这条竖线代表的对象达到某个状态时所做的行为(往往是引起另一类对象状态转换的事件)。 根据一张事件跟踪图画出状态图之后，再在其他脚本的事件跟踪图中找出以前考虑过的脚本的分支点，然后把其事件序列并入已有的状态图中，作为一条可选的路径。 10.4. 4画状态图 考虑完正常事件后再考虑边界情况和特殊情况。 当状态图覆盖了所有脚本，包含了影响某类对象状态的全部事件时，该类的状态图就构造出来了。 状态图与事件追踪图的关系 状态图叙述一个对象的个体行为，事件追踪图则给出多个对象所表现出来的集体行为。它们从不同侧面来说明同一系统的行为。 例如，一个事件追踪图指出某一对象在接受一个事件之后发出另一事件，同一行为在此对象的状态图中也应当有所表示。 10.4.5 审查动态模型 各个类的状态图通过共享事件合并起来，构成了系统的动态模型。 在完成了每个具有重要交互行为的类的状态图之后，应该检查系统级的完整性和一致性。 每个事件都应该既有发送对象又有接受对象。 对于没有前驱或没有后继的状态应该着重审查 应该审查每个事件，跟踪它对系统中各个对象所产生的效果，以保证它们与每个脚本都匹配。 以ATM系统为例：在总行类的状态图中，事件“分行代码错”是由总行发出的，但是在ATM类的状态图中并没有一个状态接受这个事件。因此，在ATM类的状态图中应该再补充一个状态“do/显示分行代码错信息”，它接受由前驱状态“do/验证账户”发出的事件“分行代码错”，它的后续状态是“退卡”。 图10.10 总行类的状态图 10.5 建立功能模型 功能模型表明了系统中数据之间的依赖关系，以及有关的数据处理功能，它由一组数据流图组成。 其中的处理功能可以用IPO图(或表)、伪码等多种方式进一步描述。 通常在建立了对象模型和动态模型之后再建立功能模型。 10.5.1 画出基本系统模型图 基本系统模型由若干个数据源点/终点，及一个处理框组成，这个处理框代表了系统加工、变换数据的整体功能。 基本系统模型指明了目标系统的边界。 由数据源点输入的数据和输出到数据终点的数据，是系统与外部世界之间的交互事件的参数。 图10.12是ATM系统的基本系统模型。 图10.12 ATM系统的基本系统模型 10.5.2 画出功能级数据流图 把基本系统模型中单一的处理框分解成若干个处理框，以描述系统加工、变换数据的基本功能，就得到功能级数据流图。 ATM系统的功能级数据流图如图10.13（见书246页）所示。 10.5.3 描述处理框功能 把数据流图分解细化到一定程度之后，就应该描述图中各个处理框的功能。注意，要着重描述每个处理框所代表的功能，而不是实现功能的具体算法。 描述既可以是说明性的，也可以是过程性的。 说明性描述规定了输入值和输出值之间的关系，以及输出值应遵循的规律。 过程性描述则通过算法说明“做什么”。 一般说来，说明性描述优于过程性描述，因为这类描述中通常不会隐含具体实现方面的考虑。 10.6 定义服务 为建立完整的对象模型，既要确定类中应该定义的属性，又要确定类中应该定义的服务。 需要等到建立了动态模型和功能模型之后，才能最终确定类中应有的服务，因为这两个子模型更明确地描述了每个类中应该提供哪些服务。 在确定类中应有的服务时，既要考虑该类实体的常规行为，又要考虑在本系统中特殊需要的服务。 1. 常规行为 在分析阶段可以认为，类中定义的每个属性都是可以访问的，也就是说，假设在每个类中都定义了读、写该类每个属性的操作。但是，通常无需在类图中显式表示这些常规操作。 2. 从事件导出的操作 状态图中发往对象的事件也就是该对象接收到的消息，因此该对象必须有由消息选择符指定的操作，这个操作修改对象状态(即属性值)并启动相应的服务。 例如，在ATM系统中，发往ATM对象的事件“中止”，启动该对象的服务“打印账单”；发往分行