软件工程构件级设计建模教程详解.ppt

对象约束语言 对象约束语言 该OCL语句定义一个不变量——也就是必须在一些行为之前(pre)和之后(post)存在的条件。开始的时候，前置条件建立了一个由客户指定的价格上限和交付期限，并且任务授权必须设置为”no”。确定价格上限和交付期限之后，将应用后置条件。还需要注意的是，表达式self.jobAuthorization=‘yes’并不是用来设置”yes”值，而是声明在操作结束时必须将jobAuthorization设置为”yes”。 设计传统构件 传统软件构件的构件级设计基础在20世纪60年代已经形成，Dijkstra等人提出，所有程序都可以建立在一组限定好的逻辑构造之上，这一组逻辑构造强调了“对功能域的支持”，其中每一个逻辑结构有可预测的逻辑结构(structure)，从顶端进入，从底端退出，读者可以很容易地理解过程流。 这些逻辑构造包括顺序型、条件型和重复型。这些逻辑构造是结构化编程的基础，而结构化编程是构件级设计的一种重要技术。 图形化设计表示 图10-10 流程图构造 图形化设计表示 一般来说，如果需要从一组嵌套的循环或条件中退出，完全依赖结构化的构造将导致效率降低。更重要的是，退出路径上的复杂逻辑检验将会使软件的控制流不清晰，增加出错的可能，降低可读性和可维护性。 设计人员有两种选择：(1)重新设计过程表示，保证内层嵌套的控制流中不需要退出分支;(2)以受控方式突破结构化的构造，即设计一条从嵌套层内退出的路径。第一种选择是最理想的，但第二种选择也不违反结构化编程的精神。 表格式设计表示 在许多软件应用系统中，模块需要对复杂的组合条件求值，并根据这些条件选择要执行的动作。决策表（判定表）提供了一种表示方法，可以将动作和条件翻译成表格。 决策表分为四个部分，左上部列出了所有的条件，左下部列出所有可能的动作，右半部构成了一个矩阵，表示条件的组合以及特定条件组合对应的动作，因此矩阵的每一列可以解释成一条处理规则。 表格式设计表示 开发决策表的步骤如下： 1、列出特定过程（或模块）相关的所有动作。 2、列出执行该过程时的所有条件（或所做的决策）。 3、将特定的条件组合与特定的动作相关联，消除不可能的条件组合；或者找出所有可能的条件排列。 4、定义规则，指出一组条件对应哪个或哪些动作。 决策表实例 图10-11 决策表 程序设计语言 程序设计语言PDL也称为结构化的英语或伪代码，它是“一种混合语言”，采用一种语言的词汇和另一种语言的语法。 设计表示方法的比较 设计表示方法应该能够导致一个易于理解和评审的过程表示。此外，这些表示方法还应该增强“面向代码”的能力，以便代码确实能够成为设计的一个自然副产品。最后，设计表示方法必须易于维护，使得设计总是正确地表示程序。 PDL可以被直接嵌入到源程序列表中，以改善文档并减少设计维护的难度。可以由任何文本编辑程序或字处理系统完成编辑，自动处理器已经存在，并具有“自动代码生成”的潜力。 活动图和流程图的图形化特征使得设计人员更容易看清控制流。 决策表的准确内容，是表驱动应用系统的理想工具。 对设计工具的选择可能更取决于人为因素而不是技术因素。 基本设计原则 共同复用原则：”不能一起复用的类不能被分到一组”。当包中的一个或者多个类变更时，包的发布版本数量也会发生。所有那些依赖于已经发生变更的包的类或者包，都必须升级到最新的版本，并且都需要进行测试以保证新发布的版本能够无故障运转。如果类没有根据内聚性进行分组，那么这个包中与其他类无关联的类有可能会发生变更，而这往往会导致进行没有必要的集成和测试。因此，只有那些一起被复用的类才应该包含在一个包中。 构件级设计指导方针 构件。对那些已经被确定为体系结构模型一部分的构件应该建立命名约定，并对其做进一步的细化和精化，使其成为构件级模型的一部分。体系结构构件的名字来源于问题域，并且应该能够被查看体系结构模型的所有共利益者理解。 在详细设计层面使用构造型帮助识别构件的特性也很有价值。 构件级设计指导方针 接口。接口提供关于通信和协作的重要信息。然而接口表示的随意性会使构件图趋于复杂化。[AMB02]建议：(1)当构件图变得复杂时，在较正式的UML框和虚箭头记号方法中使用接口的棒棒糖式记号；(2)为了保持一致，接口都放在构件框的左边；(3)即使其他的接口也适用，也只表示出那些与构件相关的接口。 依赖与继承。为了提高可读性，依赖关系是自左向右，继承关系是自下而上。另外，构件之间的依赖关系通过接口来表示，而不是采用“构件到构件”的方法来表示。遵照OCP的思想，这种方法使得系统更易于维护。 内聚性 内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。[LET01]定义了许多不同类型的内聚性。 内聚性 功能内聚 分层内聚 通信内