软件工程分享第10章.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 功能模型表明了系统中数据之间的依赖关系，以及有关的数据处理功能，它由一组数据流图组成。其中的处理功能可以用IPO图(或表)、伪码等多种方式进一步描述。 通常在建立了对象模型和动态模型之后再建立功能模型。 本书第2章已经详细讲述了画数据流图的方法，本节结合ATM系统的例子，再复习一遍有关数据流图的概念和画法。 10.5 建立功能模型 基本系统模型由若干个数据源点/终点，及一个处理框组成，这个处理框代表了系统加工、变换数据的整体功能。基本系统模型指明了目标系统的边界。由数据源点输入的数据和输出到数据终点的数据，是系统与外部世界之间的交互事件的参数。 图10.12是ATM系统的基本系统模型。 10.5.1 画出基本系统模型图 图10.12 ATM系统的基本系统模型 图10.13 把基本系统模型中单一的处理框分解成若干个处理框，以描述系统加工、变换数据的基本功能，就得到功能级数据流图。 ATM系统的功能级数据流图如图10.13（见书246页）所示。 10.5.2 画出功能级数据流图 把数据流图分解细化到一定程度之后，就应该描述图中各个处理框的功能。应该注意的是，要着重描述每个处理框所代表的功能，而不是实现功能的具体算法。 描述既可以是说明性的，也可以是过程性的。说明性描述规定了输入值和输出值之间的关系，以及输出值应遵循的规律。过程性描述则通过算法说明“做什么”。一般说来，说明性描述优于过程性描述，因为这类描述中通常不会隐含具体实现方面的考虑。 10.5.3 描述处理框功能 ATM系统数据流图中大多数处理框的功能都比较简单。作为一个例子，表10.3（见书246页）给出了对“更新账户”这个处理功能的描述。 正如10.3节指出的那样，“对象”是由描述其属性的数据，及可以对这些数据施加的操作(即服务)，封装在一起构成的独立单元。因此，为建立完整的对象模型，既要确定类中应该定义的属性，又要确定类中应该定义的服务。然而在10.3节中已经指出，需要等到建立了动态模型和功能模型之后，才能最终确定类中应有的服务，因为这两个子模型更明确地描述了每个类中应该提供哪些服务。事实上，在确定类中应有的服务时，既要考虑该类实体的常规行为，又要考虑在本系统中特殊需要的服务。 10.6 定义服务 1. 常规行为 在分析阶段可以认为，类中定义的每个属性都是可以访问的，也就是说，假设在每个类中都定义了读、写该类每个属性的操作。但是，通常无需在类图中显式表示这些常规操作。 2. 从事件导出的操作 状态图中发往对象的事件也就是该对象接收到的消息，因此该对象必须有由消息选择符指定的操作，这个操作修改对象状态(即属性值)并启动相应的服务。例如，在ATM系统中，发往ATM对象的事件“中止”，启动该对象的服务“打印账单”；发行分行的事件“请分行验卡”启动该对象的服务“验证卡号”；而事件“处理分行事务”启动分行对象的服务“更新账户”。可以看出，所启动的这些服务通常就是接受事件的对象在相应状态的行为。 3. 与数据流图中处理框对应的操作 数据流图中的每个处理框都与一个对象(也可能是若干个对象)上的操作相对应。应该仔细对照状态图和数据流图，以便更正确地确定对象应该提供的服务。例如，在ATM系统中，从状态图上看出分行对象应该提供“验证卡号”服务，而在数据流图上与之对应的处理框是“验卡”，根据实际应该完成的功能看，该对象提供的这个服务应该是“验卡”。 4. 利用继承减少冗余操作 应该尽量利用继承机制以减少所需定义的服务数目。只要不违背领域知识和常识，就尽量抽取出相似类的公共属性和操作，以建立这些类的新父类，并在类等级的不同层次中正确地定义各个服务。 分析就是提取系统需求并建立问题域精确模型的过程，它包括理解、表达和验证等3项主要工作内容。面向对象分析的关键工作，是分析、确定问题域中的对象及对象间的关系，并建立起问题域的对象模型。 大型、复杂系统的对象模型通常由下述5个层次组成：主题层、类与对象层、结构层、属性层和服务层。它们对应着在建立对象模型的过程中所应完成的5项工作。 10.7 小结 大多数分析模型都不是一次完成的，为了理解问题域的全部含义，必须反复多次地进行分析。因此，分析工作不可能严格地按照预定顺序进行；分析工作也不是机械地把需求陈述转变为分析模型的过程。分析员必须与用户及领域专家反复交流、多次磋商，及时纠正错误认识并补充缺少的信息。 分析模型是同用户及领域专家交流时有