建立类图模型
1364字,阅读需时5分钟
来自专栏
课程/专栏

在前面的课程中,我们讨论了类图及类之间的关系,掌握了类图的建模方法。在这节课我们将利用这些知识,为人脉项目V1.0系统建立类图模型。

实际上我们已经得到了人脉项目V1.0系统的类,前面课程分析的角色就是系统中的类。下表是人脉项目V1.0系统角色表,表中给出了系统中的角色,以及角色的属性和行为。我们将根据下表的内容来建立类图模型,其中角色映射为类,角色名称映射为类的名称,角色的属性映射为类的属性,角色的行为映射为类的行为。

image.png


在绘制类图模型前,我们先要确定用户、名片、数据库三个类之间的关系。下图给出了用户、名片和数据库三者之间的业务关系。

 image.png        

                                     

图 1 人脉系统业务关系图

首先来看用户和名片的关系,用户可以添加名片、编辑名片、查看名片和删除名片。

在用户添加名片业务中,用户先要获取这个名片的信息,名片信息可能来自于纸质名片,也可能来自于EXECL通讯录,用户把名片信息录入到名片类中,然后名片类将自身信息写入到数据库中。从用户添加名片的业务流程来看,在该业务中需要使用名片类接收录入的名片信息,并将名片信息存储到数据库。

在用户编辑名片业务中,用户先要通过名片类获取名片信息,用户修改名片信息,修改名片信息完成后,再通过名片类将修改的名片信息写回到数据库。从用户编辑名片的业务流程来看,在该业务中也需要使用名片类完成业务操作。

同样,删除名片业务和查看名片业务也需要使用名片类来完成业务操作。

从上述业务情况来看,用户类的添加名片、编辑名片、查看名片和删除名片业务都需要使用名片类来完成相关业务操作。因此,用户类和名片类的关系为依赖关系。

有同学可能会问,为什么不是关联关系呢?这就要看关联关系和依赖关系的区别了。关联关系属于强关系,两个类的耦合比较紧密,当一个类是另一个类的属性时,这两个类就是关联关系。依赖关系属于弱关系,两个类的耦合相对比较弱,当一个类的行为使用到另一个类时,这两个类就是依赖关系。从程序设计角度看,类之间的耦合越弱越好,因此优先选用依赖关系。当然,在一些特殊情况下,例如从性能考虑,也会选用关联关系。

确定了用户和名片的关系。我们再来看用户和数据库的关系,从关系图中可以看出,用户类需要使用数据库类来完成用户信息在数据库的存取工作。从性能上考虑,可以把数据库类作为用户类的属性,如果把数据库类放到用户类的注册、登录等行为中,就会导致数据库频繁打开,从而使数据库的访问性能下降。因此,用户和数据库的关系为关联关系。

同样的道理,名片和数据库的关系也为关联关系。

image.png


图 2 人脉项目V1.0系统类图模型

上图是绘制的人脉项目V1.0系统类图模型,从给出的类图模型可以得到系统的如下信息。系统的主要业务类是用户、名片和数据库库。每个业务类有自身的属性和行为,用户的行为依赖于名片类,名片类与数据库类是关联关系,也就是在名片类中需要使用数据库类。同样,用户类与数据库类也是关联关系。

现在我们已经完成了类图的建模,通过类图的建模,我们对人脉项目V1.0系统的需求有了更清晰地了解。下节课我们将认识顺序图,顺序图主要用于描述业务的信息流和类之间的交互过程。

我要评论
全部评论