需求分析-类图建模

类图中一共包含了以下几种模型元素，分别是：类（Class）、接口（Interface）以及类之间的关系。

类（Class)

在面向对象（OO) 编程中，类是对现实世界中一组具有相同特征的物体的抽象。

接口（Interface）

接口是一种特殊的类，具有类的结构但不可被实例化，只可以被实现（继承）。在UML中，接口使用一个带有名称的小圆圈来进行表示。

类图中关系（relation）

在UML类图中，常见的有以下几种关系:泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)

各种关系的强弱顺序：泛化 = 实现> 组合 > 聚合 > 关联 > 依赖

类图绘制要点

• 类的操作是针对类自身的操作，而不是它去操作人家。比如书这个类有上架下架的操作，是书自己被上架下架，不能因为上架下架是管理员的动作而把它放在管理员的操作里。

• 两个相关联的类，需要在关联的类中加上被关联类的ID，并且箭头指向被关联类。可以理解为数据表中的外键。比如借书和书，借书需要用到书的信息，因此借书类需包含书的ID，箭头指向书。

• 由于业务复杂性，一个显示中的实体可能会被分为多个类，这是很正常的，类不是越少越好。类的设计取决于怎样让后台程序的操作更加简单。比如单看逻辑，借书类可以不存在，它的信息可以放在书这个类里。然而借还书和书的上架下架完全不是一回事，借书类对借书的操作更加方便，不需要去重复改动书这个类中的内容。此外，如果书和借书是1对多的关系，那就必须分为两个类。

• 类图中的规范问题，比如不同关系需要不同的箭头，可见性符号等。

案例：

人脉管理项目的主要业务是用户通过人脉系统管理名片。用户可以通过电脑浏览器添加名片，添加的名片存储到数据库，也可以编辑和删除名片，当用户需要时可以随时查询和浏览名片。”

人脉管理项目的主要业务并不复杂，我们可以很容易发现业务的关键概念，其中用户、名片和数据库都是业务的关键概念。用户是业务的执行者，名片是业务的材料，数据库是业务的数据源。

找出业务的关键概念后，我们还需要弄清业务概念之间的关系。如下图：

业务概念关系图，可以清晰说明人脉系统的业务内容：用户通过人脉系统管理名片信息，名片信息通过数据库进行存取。

从定义的系统事件中找出系统角色，而找出的系统角色就是业务的关键概念，

类图模型描述了角色内容以及角色之间关系的模型。类图是一个矩形的方框，方框分为三部分，最上面的部分是类的名称，中间部分是类的属性，下面的部分是类的行为。下图是一个简单的类图。

类就是我们前面分析得到角色，角色有属性和行为，因此在类图中也有属性和行为。

建立类关系

依赖关系：指在类的行为中使用到另一个类。

例如用户类的注册行为，就会使用到数据库类来存储用户信息。下图是依赖关系的类图模型。

继承关系：指一个类继承另一个类的属性和行为，被继承的类称为父类，继承的类称为子类。

例如，假如人脉管理系统要支持多种类型的名片，我们就可以把名片的共同属性和行为抽取出来形成基类，然后在基类的基础上，通过继承关系创建视频名片、动画名片、文字名片等不同媒体的名片。

关联关系：指两个类之间有相关性，如果一个类的属性是另外一个类，就说这两个类之间有关联关系。

例如在人脉系统中，假如用户类的一个属性是名片类，则可以说用户类和名片类有关联关系。