2 . 第二章 基本结构.pptVIP

第二章 基本结构 － 类 － 关系 － 公共机制 － 图 － 类图 类 － 术语和概念 － 普通建模技术 － 提示和技巧 类 术语和概念(1) 类是对一组具有相同属性，操作，关系和语义的对象的描述。 一个对象是一个class的实例。 一个Class是一个抽象。 － 着重在相关的特征。 － 隔离不相关的特征。 结构良好的类具有清晰的边界，并形成了整个系统的职责均衡分布的一部分。 一个类实现一个或者多个接口。 类 术语和概念(2) 名称 (name)： 名字是一个文本串。 单独的名称叫做简单名（simple name ）； 用类所在的包的名称作为前缀的类名叫做路径名（path name）。 属性 (attribute) ： 属性是以被命名的类的特性，它描述了该特性的实例可以取值的范围。类可以有任意数目的属性，也可以没有属性。 类 术语和概念(3) 操作(operation) ： 是一个服务的实现，该服务可以由类的任何对象请求以影响其行为。 职责(responsibility) ： 是类的一个契约或责任。 类图 术语和概念(4) 对属性和操作的组织 ： 当描画一个class的时候，不必把每个属性和操作都显示出来。 为了更好地组织属性和操作的长列表，可以利用构造型在每一组属性和操作之前加一个描述其种类的前缀。 类 普通建模技术(1) 对系统的词汇建模 识别用户或实现者用于描述问题或解决问题的那些事物。 对于每一个抽象，识别一个职责集。清楚地定义每个类，指责要在所有类之间很好地均衡。 提供为实现每个类的职责所需要的属性和操作。 类 普通建模技术(2) 对系统中职责的分布建模 识别一组为了完成某些行为而紧密地协同工作的类 对上述的每一个类识别出一组职责。 把职责过多的类分解成较小的抽象，把职责过于琐碎的小类合成较大的类，重新分配职责以使每一个抽象合理地存在。 考虑这些类的相互协作方式，相应地重新分配他们的职责，以使协作中没有哪个类的职责过少或过多。 类 普通建模技术(3) 对简单类型建模 对被抽象为类型或枚举的事物建模，这可以用带有适当构造型的类表示符来表示。 若需要详述与该类型相联系的值域，可以使用约束。 类 提示和技巧 一个结构良好的类，要遵循如下的策略： 为取自问题域或解域的词汇中的事物提供明确的抽象。 嵌入一个小的，明确定义的职责集，并且能很好地实现他们。 把抽象的规格说明和它的实现清楚地分开。 简单而且可理解，并具有可适应性和扩展性。 当用UML绘制一个class时，要遵循如下的策略： 仅显示在该类的语境中对于理解抽象较为重要的类的特性。 通过按种类对属性和操作的长列表分组，来进行组织。 把相关的类显示在相同的类图中。 关系 － 术语和概念 － 普通建模技术 － 提示和技巧 关系 术语和概念 关系(Relationship)是事物之间的联系。 在UML中，事物之间相互联系的方式，无论是逻辑上的还是物理上的，都被建模为关系。 在图形上，把关系画成一条线，并用不同的线区别关系的种类。 在面向对象的建模中，最重要的3种关系是依赖泛化和关联。 依赖(dependency) 泛化(generalization) 关联(association) 关系 图例 关系 依赖 依赖（dependency）是一种使用关系，它说明一个事物(如类Event)规格说明的变化可能影响到使用它的另一个事物(如类Window)，但反之未必。 在图形上，把依赖画成一条有向的虚线，指向被依赖的事物。当要指明一个事物使用另一个事物时，就使用依赖。 在大多数情况下，在类的语境中用依赖指明一个类把另一个类作为它的操作的特征标记中的参数。 也可以在很多其他的事物之间创建依赖，特别是注解和包。 依赖可以带有一个名称，但很少使用，除非模型有很多依赖，并义要引用它们或作出区别。 关系 依赖图例 关系 泛化 泛化(generalization)是一般事物(称为超类或父类)和该事物的较为特殊的种类(称为子类或儿子)之间的关系。有时也称泛化为”is-a-kind-of”关系。 泛化意味着子类可以替换父类。子类继承父类的特性。 若子类的操作与父类的操作的特征标记相同，则它重载父类的操作，这称为多态性。 一个类可以有0个、1个或多个父类。把没有父类且最少有一个子类的类称为根类或基类；把没有子类的类称为叶子类。可以说只有一个父类的类使用了单继承；也可以说有多个父类的类使用了多继承。 在UML中，也可以在其他的事物间创建泛化，最明显的例子是包。 泛化可以有名称，但很少使用。除非模型有很多泛化，而且要引用它们或者加以区分，才需要使用泛化的名称。 关系 泛化图例