UML设计图3-类图

1.类图的含义

　　类图（Class Diagram）显示了系统的静态结构，而系统的静态结构构成了系统的概念基础。类图从抽象角度描述系统的静态结构，特别时模型中存在的类、类的内部结构以及它们与其它类之间的相互关系。类图就是用于对系统中的各种概念进行建模，并描绘出它们之间关系的图。

2.类图在软件工程的阶段

　　分析设计实现阶段都有

　　属于静态视图

3.类图在项目开发中的作用

　　由于静态视图主要被用于支持系统的功能性需求，也就是系统提供给最终用户的服务，而类图的作用时对系统的静态视图进行建模。当对系统的静态视图进行建模时，通常时以如下三种方式来使用类图的。

为系统的词汇建模：

　　在使用UML构建系统时，最先就是构造系统的基本词汇，以描述系统的边界。对系统的词汇建模要做出如下的判断——哪些抽象是系统建模种的一部分，哪些抽象是处于建模系统边界之外的。系统分析者可以用类图详细描述这些抽象和它们所执行的职责。类的职责是指对该类的所有对象所具备的那些相同属性和操作共同组成的部件或服务的抽象。

模型化简单操作：

　　现实世界中的事务是普遍联系的，即使将这些事务抽象成类以后，这些类也是具有相关联系的，系统中的类极少能够孤立于系统中的其它类而独立存在，它们总是于其它类协同工作，以实现强于单个类的语义。系统分析者可以通过类图将这种简单的协作进行可视化和表述。

模型化逻辑数据库模式：

　　在设计数据库时，通常将数据库模式看作数据库概念设计的蓝图，在很多领域中，都需要在关系数据库或面向数据库中存储永久信息。系统分析者可以使用类图来对这些数据库进行模式建模。

4.类图的组成

　　类图（Class Diagram）是由类、接口等模型元素以及它们之间的关系组成的。类图的目的在于描述系统的构成方式，而不是系统是如何写作运行的。

4.1.类

　　类是面向对象系统组织结构的核心。类是对一组具有相同属性、操作、关系和语义的事务的抽象。这些事务包括了现实世界中的物理实体、商业事务、逻辑事务、应用事务和行为事务等，甚至还包括纯粹的概念性事务。根据系统抽象的程度不同，可以在模型中创建不同的类。
　　在UML的图形表示中，类的表示法是一个矩形，这个矩形由三个部分构成，分别是类的名称（Name）、类的属性（Attribute）和类的操作（Operation）。
　　类的名称位于矩形的顶端，类的属性位于矩形的中间部位，而矩形的底部显示类的操作。
　　在类的构成中还应当包含**类的职责（Responsibility）、类的约束（Constraint）和类的注释（Note）**等信息。

4.1.1.类的名称

　　类的名称是每个类的图形中所必须拥有的元素，用于同其它类进行区分。
　　类的名称应该是一个名词，且不应该有前缀和后缀，且类的名称的首字母应该大写。
　　类的名称的书写字体也有规范，正体字说明类是可以被实例化的，斜体字说明类为抽象类。
　　类在它的包含者内有唯一的名字，这个包含者通常是一个包，但也可能是另外一个类。包含者对类的名称也有一定的影响。在类中，默认显示包含类所在的名称。
单独的名称，即不包含冒号的字符串叫做简单名（Simple Name）。用类所在的包的名称作为前缀的类名叫做路径名（Path Name）。
　　示例：包含位置的类

4.1.2.类的属性

　　类的属性（Attribute）是类的一个特性，也是类的一个组成部分，描述了在软件系统中所代表对象具备的静态部分的公共特征抽象，这些特性是这些对象所共有的。

　　在UML中，类的属性的语法表示为([]内的内容是可选的)：

　　[可见性] 属性名称 [:属性类型] [=初始值] [{属性字符串}]

可见性

　　属性的可见性描述了该属性是否对于其它类能够可见，从而是否可以被其它类引用。类中的属性的可见性包含三种，分别是共有属性（public）、受保护类型（protected）和私有类型（private）。

属性的名称

　　属性是类的一部分，每个属性都必须有一个名字以区别于类的其它属性。
　　按照UML的约定，属性名称的第一个字母小写，如果属性名称包含了多个单词，则这些单词要合并，并且除了第一个英文单词外其余单词的首字母要大写。

属性的类型

　　属性也具有类型，用来指出该属性的数据类型。典型的属性类型包括Boolean、Integer、Byte、Date、String和Long等，这些被称为简单类型。

初始值

　　用来保护系统的完整性。
　　为用户提供易用性。

字符串属性

　　属性字符串是用来指定关于属性的一些附加信息，比如某个属性应该在某个区域有限制。任何希望添加在属性定义字符串中但又没有合适的地方可以加入的规则，都可以放在属性字符串中

4.1.2.类的操作

　　类的操作（Operation）指的是类执行的操作，也是类的一个重要组成部分，描述了在软件系统中所代表的对象具备的动态部分的公共特征抽象。

　　在UML中，类操作的语法表示为（[]内的内容是可选的）

[可见性] 操作名称 [(参数表)] [:返回类型][{属性字符串}]

可见性；

　　操作的可见性描述了该操作是否对于其他类能够可见，从而是否可以被其他类引用。

操作的名称：

　　操作作为类的一部分，每个操作都必须有一个名称以区别于类中的其它操作。通常情况下，操作名由描述所属类的行为的动词或动词短语构成。规则与属性命名一致。

参数表：

　　参数表就是由类型、标识符对组成的序列，实际上是操作或方法被调用时接收传递过来的参数指的变量。

返回类型：

　　返回类型指定了由操作返回的数据类型。它可以是任意有效的数据类型，包括我们所创建的类型。

属性字符串：

　　属性字符串是用来附加一些关于操作的除了预定义元素之外的信息，方便对操作的一些内容进行说明。

类的职责

　　类的职责指的是对该类的所有对象所具备的那些相同的属性和操作共同组成的功能或服务的抽象。
　　在声明类的职责的时候，可以非正式地在类图的下方增加一栏，将该类的职责逐条描述出来。

类的约束

　　类的约束（Constraint）指定了该类所要满足的一个或多个规则。
　　在UML中，约束是用一个大括号括起来的文本信息。

类的注释

　　使用注释（Note）可以为类添加更多的描述信息，也是为类提供更多描述方式中的一种。

4.2.接口

　　接口（Interface）是在没有给出对象实现和状态的情况下对对象行为的描述。通常，在接口中包含一系列操作但是不包含属性，并且它没有外界可见的关联。
　　接口是一种特殊的类，所有接口都是由构造型<>的类。

　　在UML中，接口的表示方式是使用一个带有名称的小圆圈来表示，共可以通过一条Realize（实现关系）线与实现它的类相连接。

当接口被其它类依赖的时候，也就是说一个接口在某个特定类中实现后，一个类通过一个依赖关系与该接口相连接。这时，依赖类仅仅是依赖于指定接口中的那些操作，而不是依赖于接口实现类中的其它部分。在依赖中可以通过一些方式调用接口中的操作。

接口也可以像类那样进行特殊化和一般化处理。

在类图中，接口之间的泛化关系也是用类泛化关系所使用的符号表示。

4.3. 类之间的关系

类于类之间的关系最常见的通常有四种，它们分别是依赖关系（Dependency）、泛化关系（Generalization）、关联关系（Association）和实现关系（Realization）。

4.3.1.依赖关系（Dependency）

依赖表示的是两个或多个模型元素之间语义上的连接关系。它只是将模型元素本身连接起来而不需要用一组实例来表达它的意思。
它表示了这样一种情形，提供者的某些变化会要求或指示依赖关系中客户的变化。也就是说依赖关系将行为和实现于影响其它类的类关系起来。

4.3.2.泛化关系（Generalization）

泛化关系用来描述类的一般和具体之间的关系。具体描述建立在类的一般描述的基础之上，并对其进行了扩展。
在泛化关系中，一般描述的类被称为父类，具体描述的类被称为子类。

4.3.2.关联关系（Association）

关联关系是一种结构关系，指出了一个事务的对象于另一个事务的对象之间在语义上的连接。关联描述了系统中对象或实例之间的离散连接，它将一个含有两个或多个有序表的类，在允许赋值的情况下连接起来。
一个类关联的任何一个连接点都叫做关联端,与类有关的许多信息都附在它的端点上。关联端有名称、角色、可见性以及多重性等特性。