第1章类图.doc

第1章　类图1.1　概述 类图（class diagram）用来表示系统内部的静态结构（static structure）。具体来说，开发人员可以通过类图的设计，将数以万行的程序代码分门别类，以构成系统内部的静态结构。 过去，开发人员在写程序时，需要分模块（module）、定功能（function）、定义变量，这些动作在面向对象（Object-Oriented）技术中，一样都没少。 现在，观念上有两个显著的改变： 1. 新术语。模块变成类（class）、功能变成操作（operation）、变量变成属性（attribute）。新术语并不是旧酒换新瓶，而是在分类、定操作、定义属性基础之上，有新的划分方法。 2. 新的划分方法。以前的做法是从功能的角度，把大功能、大流程分成数个模块；再把功能模块分成小功能、小流程，定出功能；然后在编写功能时，定义所需的变量。新的分法是，拿用户的领域术语当类，然后确定相关的操作和属性，最后将其封装在同一个类中。 所以，再回过头来看，系统的内部结构是由一个个类所组成的，类内部有操作和属性，类和类之间有静态关系（static relationship）。由于类里头同时包含了静态数据（属性），数据之间会有关联的需要，这种以数据为主的关联，即为“静态关系”。也就是说，类图不仅规范了程序代码，其实还同时规范了数据库的数据结构。 在UML中，类图的元素相当繁杂，分析师当然不需要全学，所以在接下来的1.2节中，我们仅谈论分析师必学的元素。 1.2　分析师必学元素 1.2.1　类 想象一下，将系统数以万行的程序代码划分为一个个的区块，每一个区块即为一个类。每一个类中，包含有操作和属性；操作内部放置与逻辑运算相关的程序代码，属性则是所需的局部变量。 分析师不能自己随意定义类，必须寻找领域术语作为类名称。比如，一谈到订房，我们就会想到打算预订什么样的房间，这里会找到两个领域概念： 1. 房间。真正住进去，特定房号的房间。 2. 房型。顾客在订房时，通常是预订某个房型的房间。 类的图标为矩形，通常矩形内部会分为三格：顶格放置类名称、中格放置属性、底格放置操作，如图1-1所示。说明如下： ? 属性。属性是数据项，所以需要指定它的类型（type），属性名称后接冒号隔开类型。如果，属性有默认值的话，也可以在类型后面加上等号，然后标出默认值。 操作。操作名称后面以小括号括起输入参数，然后可以在小括号后接冒号，标出返回参数的类型。 可见性。特别注意到，属性名称前面有个加号、操作名称前面也有个加号，这个符号称为“可见性（visibility）”。由于属性和操作封装在类中，所以需要使用可见性来标示它们的访问等级。UML 2设置了4种可见性，分析师只要掌握“私有（private）”和“公有（public）”两种就可以了。 私有。属性的可见性通常会设成私有等级，除了所属类内部的操作可以直接访问之外，其他类内部的操作不可以访问私有等级的属性。 公有。操作的可见性通常设为公有等级，不仅所属类内部的其他操作可以调用（call），其他类内部的操作也可以调用公有等级的操作。 1.2.2　关联 很多分析师都有设计“实体关系图（Entity-Relationship Diagram，ERD）”的经验，我们会在表（table）之间建立关系，这样才能关联不同表内的数据。 比较一下，表跟类最大的区别在于，表只包含数据，但是类同时包含了数据（属性）和操作。也就是说，类其实具备表的静态结构特性，但是又多了一份动态行为特性。至于原先在表之前的关系（relationship），对应到类之间，则称为“关联（association）”。 分析师可以借用以前实体关系图的概念，来认识类图，简单对照如表1-1所示。虽然，记录的概念可以对应到对象，但只能对应到半个对象，因为一个对象同时含有属性值和操作，但是一条记录只含有字段值。 表1-1　 实体关系图与类图 ? 表之间的关系可分为一对一关系、一对多关系、多对多关系，用来表示一条记录能够关联到另一个表中的几条记录。类之间的关联中，同样也这样的概念，叫做“多重性（multiplicity）”，用来表示一个对象能够结合到另一个类中的几个对象。 关联的图标是实线，两个结合端点可以标示多重性。多重性的下限为0，上限是无限大（*），下限标示在前面，上限标示在后面，两个数字之间使用两个点（..）隔开。如图1-2中的例子，表示一个房型可能连接一到多个房间，而一个房间则一定被限定连接到某一个房型。 ? 在多对多的处理上，也参照关系型数据库的经验，由于处理起来太复杂，所以通常会将多对多拆解成两个一对多的结构。比方说，一次订房可能预订多种房型，而每一种房型也可能跟多个不同的订房事务有关，两者之间形成多对多的关联，如图1-3所示。 ?