第1章类图

第1章类图1.1概述类图（classdiagram）用来表示系统内部的静态结构（staticstructure）。具体来说，开发人员可以通过类图的设计，将数以万行的程序代码分门别类，以构成系统内部的静态结构。过去，开发人员在写程序时，需要分模块（module）、定功能（function）、定义变量，这些动作在面向对象（Object-Oriented）技术中，一样都没少。现在，观念上有两个显著的改变：1.新术语。模块变成类（class）、功能变成操作（operation）、变量变成属性（attribute）。新术语并不是旧酒换新瓶，而是在分类、定操作、定义属性基础之上，有新的划分方法。2.新的划分方法。以前的做法是从功能的角度，把大功能、大流程分成数个模块；再把功能模块分成小功能、小流程，定出功能；然后在编写功能时，定义所需的变量。新的分法是，拿用户的领域术语当类，然后确定相关的操作和属性，最后将其封装在同一个类中。所以，再回过头来看，系统的内部结构是由一个个类所组成的，类内部有操作和属性，类和类之间有静态关系（staticrelationship）。由于类里头同时包含了静态数据（属性），数据之间会有关联的需要，这种以数据为主的关联，即为“静态关系”。也就是说，类图不仅规范了程序代码，其实还同时规范了数据库的数据结构。在UML中，类图的元素相当繁杂，分析师当然不需要全学，所以在接下来的1.2节中，我们仅谈论分析师必学的元素。1.2分析师必学元素1.2.1类想象一下，将系统数以万行的程序代码划分为一个个的区块，每一个区块即为一个类。每一个类中，包含有操作和属性；操作内部放置与逻辑运算相关的程序代码，属性则是所需的局部变量。分析师不能自己随意定义类，必须寻找领域术语作为类名称。比如，一谈到订房，我们就会想到打算预订什么样的房间，这里会找到两个领域概念：1.房间。真正住进去，特定房号的房间。2.房型。顾客在订房时，通常是预订某个房型的房间。类的图标为矩形，通常矩形内部会分为三格：顶格放置类名称、中格放置属性、底格放置操作，如图1-1所示。说明如下：属性。属性是数据项，所以需要指定它的类型（type），属性名称后接冒号隔开类型。如果，属性有默认值的话，也可以在类型后面加上等号，然后标出默认值。操作。操作名称后面以小括号括起输入参数，然后可以在小括号后接冒号，标出返回参数的类型。可见性。特别注意到，属性名称前面有个加号、操作名称前面也有个加号，这个符号称为“可见性（visibility）”。由于属性和操作封装在类中，所以需要使用可见性来标示它们的访问等级。UML2设置了4种可见性，分析师只要掌握“私有（private）”和“公有（public）”两种就可以了。私有。属性的可见性通常会设成私有等级，除了所属类内部的操作可以直接访问之外，其他类内部的操作不可以访问私有等级的属性。公有。操作的可见性通常设为公有等级，不仅所属类内部的其他操作可以调用（call），其他类内部的操作也可以调用公有等级的操作。1.2.2关联很多分析师都有设计“实体关系图（Entity-RelationshipDiagram，ERD）”的经验，我们会在表（table）之间建立关系，这样才能关联不同表内的数据。比较一下，表跟类最大的区别在于，表只包含数据，但是类同时包含了数据（属性）和操作。也就是说，类其实具备表的静态结构特性，但是又多了一份动态行为特性。至于原先在表之前的关系（relationship），对应到类之间，则称为“关联（association）”。分析师可以借用以前实体关系图的概念，来认识类图，简单对照如表1-1所示。虽然，记录的概念可以对应到对象，但只能对应到半个对象，因为一个对象同时含有属性值和操作，但是一条记录只含有字段值。表1-1实体关系图与类图表之间的关系可分为一对一关系、一对多关系、多对多关系，用来表示一条记录能够关联到另一个表中的几条记录。类之间的关联中，同样也这样的概念，叫做“多重性（multiplicity）”，用来表示一个对象能够结合到另一个类中的几个对象。关联的图标是实线，两个结合端点可以标示多重性。多重性的下限为0，上限是无限大（*），下限标示在前面，上限标示在后面，两个数字之间使用两个点（..）隔开。如图1-2中的例子，表示一个房型可能连接一到多个房间，而一个房间则一定被限定连接到某一个房型。在多对多的处理上，也参照关系型数据库的经验，由于处理起来太复杂，所以通常会将多对多拆解成两个一对多的结构。比方说，一次订房可能预订多种房型，而每一种房型也可能跟多个不同的订房事务有关，两者之间形成多对多的关联，如图1-3所示。因为多对多不好处理，所以我们将图1-3拆解成两个一对多的关联，如图1-4所示。一次订房包含多个订房明细，每一个订房明细则隶属于某一次的订房事务中。再者，一个订房明细会连接到一个房型，每一个房型可能出现在多个订房明细中。1.2.3组合关系再以图1-4为例，仔细比较订房-订房明细以及订房明细-房型两者之间的关系，不难发现，订房-订房明细之间的关系比较特别。订房-订房明细之间的关系有一种“整体-部分（whole-part）”的强烈关系，一旦代表整体的订房对象删除的话，底下所连接的订房明细对象都应该一并删除才对。但是，订房明细-房型之间则没有这种强烈的所有关系。如果分析师要表达两种对象之间有这种强烈的所有权，可以在整体端标示实心菱形，未标示的则代表部分端，如图1-5所示。具备强烈整体-部分的关联，特别地称为“组合关系（compositionrelationship）”。不过，组合关系很容易遭到滥用。整体-部分在领域概念上必须是不可分割或者难以分割的。1.3事务模式领域概念非常多，建议分析师应用“事务模式”迅速勾勒出类图的雏型。事务模式由知名的OOAD大师PeterCoad所提出，您可以在网络上查到许多相关资料，主要出处为《ObjectModels:Strategies,Patterns,&Applications》一书。不过，我们在此处的引用上，多了一些限制，所以使用上会比PeterCoad所提出的事务模式更狭隘一些，但是并没有改变PeterCoad的原意。我在《系统分析师UML实务手册》和《系统分析师UML用例实战》这两本书中，特别是后者中，都详细解释过事务模式，有兴趣的话，推荐您找来读一读。1.3.1事务与人、地、物顾名思义，事务模式强调以“事务（Transaction）”为中心，串起跟事务相关的事务明细（TransactionLineItem）、涉众（Participant）、地点（Place）、物品（Item），如图1-6所示。不过，此处对“事务”的定义比较广义，并不局限于一般的商业交易，系统中所有“必须记录的事件”都是我们的候选事务。因此，事务可能是一个短暂的时间片刻，也可能是一小段时间。所以，应用图1-6的事务模式，分析师大概可以很快得出如图1-7所示的类图雏型。1.3.2物品与特定物品事务涉及的物品概念，可以细分成两种：一种是具体的、特定的物品，另一种是针对一群同种类特定物品的描述或分类。在事务模式中，则将这两个概念分为“特定物品（SpecificItem）”和“物品（Item）”，如图1-8所示。其实，我们在前面提到的“房型－房间”的概念，就是“物品－特定物品”的应用，如图1-9所示。不过，在订房的范例中，我们目前还无法确定是否可以直接应用“特定物品－事务明细”以及“特定物品－事务”。分析师要是遇到这种未确定的情况，可以标上像记事贴一样的“注释（comment）”来提醒自己留意。之所以无法确定图1-9中“房间－订房明细”以及“房间－订房”这两条关联，最主要原因在于，这两条关联都不是单纯的一对多结合，而是如图1-10所示的多对多结合。此处，我们先保留多对多结合，稍后再来讨论细节。1.3.3后续事务事务本身含有时间因素，所以如果拉出一条时间轴的话，会看到事务之后可能有“后续事务（subsquentTransaction）”，如图1-11所示。想想看，订房成功之后，后续会发生哪些必须记录的重要事件？我第一个想到的后续事务是“入住（checkin）”，如图1-12所示。应用事务模式不仅可以帮助分析师快速作出类图雏型，更重要的是，可以协助分析师使用比较系统性的方法去理解领域概念。比方说，应用事务模式到目前为止，好像对“订房-订房明细”以及“入住－入住明细”领域概念一直没有真正理清，分析师可能开始觉得有必要理清这两个概念。首先，我们先理清订房-订房明细，如图1-13所示，我们做下述规定，让它看起来简单一点：一次订房可以同时订多个房间，但是只能限定是同一个预订日期。假设，这个会员要一次预订多天的话，必须拆成多个订房事务。再者，我们还规定一次入住事件对应一间房间。假设会员预订12/20两个房间的话，那这次订房就会对应到两个入住事件。在这样的规定之下，也就不再需要入住明细了，因此修改成图1-14的样子。1.3.4参与者与涉众最后，我们回过头来看事务模式中的涉众的概念。仔细探究起来，涉众其实是一种身份、一种角色，在这个角色背后有一个真正的“参与者（actor）”。“参与者－涉众”之间的关系就像是“演员－角色”一样，如图1-15所示。在订房系统中，只有具备会员身份的人才能够订房，所以“个人-会员”就对应到了“参与者－涉众”，如图1-16所示。不过，我们还不确定一个人是否可以申请多个会员身份，所以标上了未确定的注释。1.4酒店联合订房系统通过前面的讨论，我们已经有了类图的雏形，到目前为止，我们得到了如图1-17的类图雏形。原本在本节中，我们应该继续来讨论订房系统的类图，不过我想先到此为止，直接进入下一章来讨论用例图。分析师推进到用例图的时候，一定会捕捉且理解更多的领域概念，那时再把所捕获的内容反馈到类图中。其实，别沉溺在任何一张图中，单方面穷究一张图是无法检验出分析设计的好坏的。所以，我建议分析师应该迅速推进到下一张图，就像齿轮组一样，其中一个齿轮转动，其实也会同时带动其他齿轮的转动，这样才能够检验出其他齿轮有没有卡住，如图1-18所示。