UML建模（类图）

一、类图

类图是面向对象系统建模中重要的图，是定义其它图的基础。类图主要是用来展现软件系统中的类、接口以及它们之间的静态结构。

在uml类图中，类之间关系有如下: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)

5.1.泛化: 泛化是继承关系的一种，子类继承父类的所有行为和属性，子类可以新增新的功能或者重写父类功能。 uml中使用带空心三角箭头的实线标示 【箭头指向】：箭头指向父类

image.png

5.2.实现: 实现是接口和类的关系，是指类实现了接口中定义的接口，uml中用带空心三角箭头的虚线 【箭头指向】：箭头指向接口类

image.png

5.3.关联: 在建模过程中必然存在类之间的联系，使类可以感知其他类的行为和属性，关联分为双向和单向关联

• 双向关联（标准） 对于双向关联来说被关联的两个类可以感知对方的存在

image.png 如图在线每端放置一个角色和多重值，对于Route来说我们应该看在bike端的角色和多重值，对于Route来说每个骑行路线对应0个或者多个自行车，0个是因为可能先制定了骑行路线但是还没有找到自行车，多个是因为可以有多个人骑行同一个路线。对于bike来说我们应该看route端的角色和多重值，对于一个bike来说每个自行车对于0个或者多个骑行路线，0个是因为虽然有一个自行车但是我可以不骑行，不指定骑行路线那，多个是因为我一个自行车可以指定多个骑行路线。

上面多重值为0...*,其实还有其他多重值如下表：

• 单向关联 对于一个单向关联来说也是两个类是相关的，但是只有一个类知道这种联系的存在

image.png

如图对于单向关联表示为一条带有指向已知类的开放箭头实线，单向关联只包含一个角色名和多重值，一个人可以有0个或者多个账户，人可以感知到账户的存在，但是账户却感知不到人的存在。

• 聚合 聚合是关联关系的一种，聚合主要描述整体与部分直接的关系，聚合有分为基本聚合和组合聚合，

基本聚合：对应基本聚合来说部分类的生命周期独立于 整体类 的生命周期，uml中使用一条从整体类到部分类的实线，并在整体类的关联末端画一个未填充棱形标示：

image.png

一个汽车有4个轮子组成，轮子的生命周期不依赖与车的，因为车轮可以独立于车独立存在。

组合聚合:组合聚合是聚合的一种情况，不同在于部分类的生命周期依赖整体类，uml中使用一条从整体类到部分类的实线，并在整体类的关联末端画一个填充棱形标示：

image.png

一个公司有至少一个部门组成，部门要依赖于公司的存在而存在，不会存在一个部门而它不属于某一个公司。

• 自身关联 自身关联涉及到一个类，是类自己关联自己的情况

image.png

一个雇员可以有0个或者多个管理者，而管理者本身也是雇员的一种。

5.4.依赖: 依赖即一个类的实现需要其他类的协助，通常代码表现为方法参数，局部变量，静态方法调用，util类调用，uml中使用一条箭头的虚线，从依赖方指向被依赖的类

image.png

一个例子 从UML官方网站搞了个 域模型图

image.png

下面围绕类Library类分析下这个图，首先library通过组合方式关联到了Catalog类目类，这说明类目不能独立存在要依赖图书馆存在，所以这里没有使用聚合而使用了组合。另外library通过聚合关联到了Book Item 类和Account账号类，这说明图书馆是有0个或者多个图书和账户组成，这里使用聚合而不是用组合是因为书和账号可以独立于图书馆存在，比如我有学号账号，但是图书馆里面不是必然有你的账号。

下面围绕Catalog分析，类目通过双向关联关联到bookitem，说明一个类目里面可能会有0个或者多个书籍，一个书籍对应着一个类目。另外类目有通过realization实现了search类和manage类的接口，让类目有搜索和管理功能。Search类搜索时候会依赖Patron类图书捐赠人的姓名地址或者Libraian类图书管理员的姓名地址，职位。 图书管理类时候会依赖图书管理员类的信息。

而Patron图书捐赠人有可能是一个学生，学生有自己的账号，所以patron类会聚合到Account. bookItem类通过泛化继承Book中书的共性部分信息。有通过关联关联到了account,说明一个账户只能接到0本和最多12本书，最多可以预定3本书。

最后Book类双向关联到Author类，数目一个作者至少写了1本书（严格说应该是0），一本书至少有一个作者编写， Account账户类有依赖一个AccountState的枚举值的类用来存放账号状态。