《UML参考手册（第二版）》.pdf

《UML参考手册》 第三部分 参考资料 第 1 章 术语大全 1. 抽象 abstract 抽象是不能被直接实例化的类、用例、信号、其他类元或其他泛化元素，它也可以 用来描述没有实现的操作。反义词：具体(concrete)。 见抽象操作(abstract operation)，可泛化元素(generalizable element) 。 语义 抽象类是不可被实例化的类，即它可以没有直接实例，这既可能是因为它的描述是 不完整的（如缺少一个或多个操作的方法），也可能是因为即使它的描述是完整的它也 不想被实例化。抽象类是为了以后说明。抽象类必须有可能含有实例的后代才能使用， 一个抽象的叶类是没用的（它可以作为叶在框架中出现，但是最终它必须被说明）。 具体类可以没有任何抽象操作（否则，它必为抽象的），但是抽象类可以有具体操 作。具体操作是可以被实现一次并在所有子类中不变地使用的操作。在它们的实现中， 具体操作可以只使用声明它们的类所知道的特征（属性和操作）。继承的目的之一即将 这些操作在抽象的超类中分解以使得它们可以被所有的子类分享。一个具体操作可以是 多态的，即后代类中的方法优先于它，但是它也可以不必是多态的，它可以是一个叶操 作。一个所有操作都被实现的类可以是抽象的，但是这一点必须被明确声明。一个有着 一个或多个未实现操作的类自然是抽象的。 同样的语义也适用于用例。抽象的用例定义了行为的片断，这个行为自己不能出现， 但是它可以通过泛化、包括或扩展关系在具体用例的定义中出现。通过在抽象的用例中 分解公用的行为，模型变得更小和易于理解。 类似的关系也存在于其他的类元和泛化元素中。 表示法 抽象类或抽象操作的名字用斜体字表示。关键字 abstract可以放置在位于名称下 面或后面的特性表中，如 Account{abstract}。 见 class name。 示例 图 13-1 表示一个抽象类 Account，它有一个抽象操作 computeinterest 和一个具 体操作 deposite。两个具体子类已经被声明了。因为子类是具体的，所以它们每一个 必须实现操作 computeinterest。属性总是具体的。 《UML参考手册》 图 13-1 抽象和具体的类 讨论 将一个类建模成抽象的或具体的，其间的差别并不像它第一次出现时那么清晰和基 本。它更像有关模型的设计结果而不是继承特性。在设计的发展过程中，类的状态可能 发生变化。如果将列举出所有可能性的子类加入到具体类中，那么这个具体类可以建模 成抽象的。如果子类之间的差别被认为是不必要的且被删除，或者这些差别用属性值而 不是用不同的子类表示，那么这个抽象类可以建模成具体的。 简化决定的方法之一是采纳以下设计准则：所有的非叶类必须是抽象的（除了某些 为了以后说明的抽象叶类外，所有的叶类必须是具体的）。这并不是 UML 的规则，它既 可以被采用也可以不被采用，设计这个抽象超类规则的原因是超类上可继承的方法和 具体类上的方法经常有不同的需求，这种需求并不能被单个方法很好地实现。超类中的 方法被迫做两种事：定义能被所有后代观察到的通用例子和为特定类实现通用例子。但 是这两个目标经常发生冲突。相反，一个非抽象的超类能被机械地分离到一个抽象的超 类和一个具体的叶子类中。抽象的超类包含被所有子类继承的方法；具体的子类包含所 有特定的可实例化类要求的方法。在抽象的超类规则后也允许在保持特定具体类型的变 量或参数与保持着超类的任何后代的变量或参数之间存在完全的区别。 《UML参考手册》