第9章 面向对象分析 普通高等院校计算机类专业系列教材 软件工程教学课件.ppt

9.2.6 优化对象模型 通过以上各步，对象模型就建立起来了，但这样不能确保模型是完全正确的，还应反复修改，不断完善与优化。在建模的各个阶段，一旦发现了缺陷，就必须返回到前面阶段进行修改。有些细化工作(如定义服务)要等到动态模型和功能模型建完以后才能进行。 在建模的过程中，不一定按前述的工作顺序进行，分析员完全可以以自己的独特方法进行，既可以将几个阶段并行处理，又可以随意组织前述工作顺序。如果是初次使用面向对象方法，建议还是按照前述顺序进行比较好。 1. 删除冗余的类 如果某类中缺少属性、操作和关联，则可删除该类。 2. 分解类 “现金兑换卡”可分为“卡权限”和“现金兑换卡”两个功能，前者表示储户访问账户的权限，后者则表示含有分行代码和卡号的数据载体。 3. 补充关联 一个“事务”由若干个“更新”组成，它们构成整体 - 部分关系。一个“更新”是一个动作，即对账户所做的一次处理，如存款、取款、查询等。“更新”有类型、金额等属性，所以，可补充定义成为一个单独类，“事务”与它构成整体-部分关系。 4. 合并类 如在一个应用系统中，两个类虽然名字不同，但是它们所完成的任务以及与其他类的关系也相同，这时可将这两个类合并成为一个类。例如，“分行”与“分行计算机”合并为“分行”。 同样，可将“总行”与“中央计算机”合并成为“总行”。 通过进一步的优化，得出如图9.6所示的ATM对象模型。 图9.6 优化后的ATM对象模型 9.3 建立动态模型 当对象模型建立起来后，接着可以建立动态模型。动态模型的概念和表示方法前一章已经介绍了，本节以ATM系统为例，对动态模型的建立方法给予叙述。 建立动态模型对于每个系统并不是都重要，这要看开发系统的类型而定。对于数据库系统来说，动态模型并不重要，如果是交互式系统，建立动态模型却是非常重要的。 对于一个系统来说，功能模型指明了系统应该“做什么”，而动态模型则明确规定了“什么时候做”。即在何种状态下、接受了什么事件的触发，来确定对象的可能事件的顺序。 建立动态模型的步骤： (1) 编写典型的对话脚本； (2) 从脚本中提取出事件，联系该事件与其目标对象； (3) 组织事件的顺序和状态(采用状态图描绘)； (4) 比较各个不同对象的状态图，检查对象之间的一致性，确保事件之间的匹配。 9.3.1 编写脚本 1. 脚本的概念 当系统与用户交互时，为了对目标系统的行为有更具体的认识，用脚本表示系统的行为。脚本描述用户(或其他外部设备)与目标系统之间的一个或多个典型的交互过程，利用脚本来建立动态模型。在建立动态模型的过程时，为了确保整个交互过程的正确性和清晰性，不遗漏重要的交互步骤，首先要编写脚本，为建立动态模型奠定基础。 6) 实现准则 在分析阶段，应该去掉仅和实现有关的候选的类-＆-对象。这是因为，在设计和实现阶段，这些类-＆-对象可能是重要的，但是，目标系统实现不应该在分析阶段考虑，不然会分散我们的注意力。 例如，在ATM系统中，“事务日志”无非是对一系列事务的记录，它的确切表示方式是面向对象设计的议题；“通信链路”在逻辑上是一种联系，在系统实现时它是关联链的物理实现。因此，应该暂时去掉“事务日志”和“通信链路”这两个类，在设计或实现时再考虑它们。 综上所述，在ATM系统的例子中，经过初步筛选，剩下了下列类-＆-对象：ATM、中央计算机、分行计算机、营业终端、总行、分行、营业员、储户、账户、事务和现金兑换卡等。 9.2.2 确定关联 两个或多个对象之间的相互依赖、相互作用的关系就是关联。一般情况下，在初步分析问题域中的类-＆-对象确定之后，接着就可以分析、确定类-＆-对象之间存在的关联关系。由于在整个开发过程中，从OOA→OOD，面向对象概念和表示符号都是一致的，因此，分析员可以不按照这样的工作顺序，灵活地选取自己习惯的工作方式。 分析、确定关联，能促使分析员考虑问题域的边缘情况，有助于发现那些潜在的类-＆-对象。 聚集关系(整体 - 部分关系)是关联的一个特例，在分析、确定关联的过程中，不必明确地去区分关联和聚集。 1. 初步确定关联 通常，关联关系在需求陈述中，使用描述性动词或动词词组来表示。因此，通过分析需求陈述，首先，直接提取需求陈述中的动词词组来初步确定多数的关联，然后，还能挖掘一些在陈述中隐含的关联。最后，根据问题域实体间的相互依赖、相互作用关系，分析员还应该与用户及领域专家讨论，作再进一步的补充。 以ATM系统为例，用直接提取动词短语得出关联、 需求陈述中