第三部分 参考资料.docVIP

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