需求分析——使用类图建模

在讨论类图之前，我们先看下面的一段文字。

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

上面的这段文字介绍了人脉项目的主要业务。由于业务相对简单，我们能够很快理解这类业务。但对一些业务比较复杂的系统来说，理解起来就不那么容易了，如果我们能够梳理业务中的关键概念及它们之间的关系，就可以帮助我们快速理解新系统的业务。

在上面介绍人脉系统业务的文字中，我们可以很容易发现业务的关键概念，其中用户、名片和数据库都是业务的关键概念。用户是业务的执行者，名片是业务的材料，数据库是业务的数据源。找出业务的关键概念后，我们还需要弄清业务概念之间的关系。下图给出了人脉系统业务概念之间的关系。

 

图 1 人脉系统业务概念关系图

通过人脉系统业务概念关系图，可以清晰理解人脉系统的业务内容，用户通过人脉系统管理名片信息，名片信息通过数据库进行存取。因此，只要我们把新系统业务的关键概念以及概念之间的关系描述清楚，自然也就理解了新系统的业务。

 

那么如何识别系统业务的关键概念呢？

在前面的课程中，我们掌握了从定义的系统事件中找出系统角色的方法，其实我们找出的系统角色就是业务的关键概念，角色的用例模型从系统的功能角度描述了系统应提供哪些功能，但没有给出角色的内容以及角色之间的关系。UML建模语言中的类图模型就是描述角色内容以及角色之间关系的模型。

在一些建模工具中（如Visio），类图是一个矩形的方框，方框分为三部分，最上面的部分是类的名称，中间部分是类的属性，下面的部分是类的行为。下图是一个简单的类图。

 

图 2 一个简单的类图

 

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

在上面的类图模型中，用户是类（角色）的名称，昵称和登录密码是类的属性，注册和登录是类的行为。

 

类与类之间也会存在关系。在需求分析阶段，类与类之间的关系有依赖关系、继承关系、关联关系。在设计阶段类图模型会增加聚合关系和实现关系。

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

 

图 3 类的依赖关系

 

继承关系是指一个类继承另一个类的属性和行为，被继承的类称为父类，继承的类称为子类。继承的思想是把同类事物的共同属性抽取出来形成基类，基类可以被更具体化的子类来继承。例如，假如人脉系统要支持多种类型的名片，我们就可以把名片的共同属性和行为抽取出来形成基类，然后在基类的基础上，通过继承关系创建视频名片、动画名片、文字名片等不同媒体的名片。下图是继承关系的类图模型。

 

图 4 类的继承关系

 

类的关联关系是指两个类之间有相关性，如果一个类的属性是另外一个类，就说这两个类之间有关联关系。例如在人脉系统中，假如用户类的一个属性是名片类，则可以说用户类和名片类有关联关系。下图是关联关系的类图模型。

 

图 5 类的关联关系

前面我们讨论了什么是类图以及类之间的关系。我们知道了类图模型是从业务角度来描述系统的，从系统业务中抽取的关键概念构成了业务类，系统业务类之间存在依赖关系、继承关系和关联关系。下节课我们将利用这些知识，为人脉项目V1.0系统建立类图模型。