在所有项目中,类都是最常见的UML模型元素(当然,不可否认,很多项目还没画出类图就直接进入编码实现的阶段了)。类是UML模型与具体实现代码之间的桥梁,随着对UML建模的深入了解,我们也会发现,类(确切说是分析类)其实也是一些模型之间的桥梁。
在真实世界中不同对象通过协同工作完成相关业务。而从软件系统实现层面来说,是系统中的不同对象通过协同工作完成业务系统的相关功能。系统中的对象往往是真实世界中对象的映射。在面向对象的分析、设计(OOAD)与编程(OOPL)中,系统中的对象是类的实例,而类是对现实世界中对象的抽象,它代表了现实世界中被抽象对象的集合。
类对对象的抽象是通过抽取其与业务需求实现相关联的特征而完成的,定义完成的类,可以看作是产生对象实例的工厂或模板。
真实世界中有两类对象:一类是看得见的摸得着的实实在在的实体对象,这些对象比较容易发现,我们可以给予它们名称,可以轻易了解它的一些属性,比如:图书、人、汽车等;另一类是看不见摸不着的抽象的概念,比如:购物网站的订单、日期、时间等。
不同的类拥有不同的特性和行为,类的特性称为属性,类的行为称为操作。
对于图书而言,它的特性由书名、作者、出版年份、ISBN号、印刷批次等组成,而这里的每一项是一个类的属性。我们可以通过这些属性识别出“这是谁写的哪本书”,而如果是在图书馆中的图书则还会有借阅号、借阅状态等属性,这些属性则可以识别出“这是放在哪个书架上的哪本书”。
对于图书而言,它本身不会有主动的行为,如果是在图书馆中的图书,它的行为(即操作)则可能包括借书、还书等。
UML中用类图来描述类,类图通常由三部分组成:类名、属性列表和操作列表,如下图所示。在使用时,类名是必须给出的,而属性列表与操作列表在不同视图中则可以根据需要省略其中的一个或者两者都省略,但如果两者都出现的话,则必须保证属性列表在上操作列表在下。
类名应该是一个名词,通常其首字母要大写。对于图书,我们可以将它的类名定义为Book。
属性名应该是一个名词,通常其首字母要小写,属性类型可以是基本数据类型、自定义的数据类型或者类。类Book的属性一般会包含有书名、作者、出版年份等信息,而如果类Book是为图书馆的借阅系统建立的,则类Book还应包含索书号等信息。添加了这些属性的类Book的类图如下所示:
在上图中,我们可以看到属性以“属性名:类型”的形式展现。在建模阶段,我们也可以先不考虑属性的类型,即“:类型”部分可以省略,省略属性类型的类图如下所示。
观察以下两个表示类Book的类图,可以发现这两个类图都省略了属性accessionNo,第一个类图在最后通过添加省略号(…)表示还有未显示出来的属性,如果在类图的属性区域出现省略号,则表示至少有一个属性在类图中没有被展示出来。
通常我们会通过工具来描绘UML中的各种图形,对于类图,工具通常支持按照属性的可见性进行筛选展示,例如你可以只展示public的属性而隐藏剩余的其它属性。
类图展示属性的区域,如果你愿意,还可以明确表明这个区域是描述类属性的区域,其具体做法是在类图属性区域的顶端标明“attributes”,但是要注意的是它是小写居中的复数形式。
操作是类实例可以被要求执行、承受、启动的相关行为,或者是可以在对象上被执行的相关行为。如果一个类不是一个活动类,它的实例不会自己主动做任何事情,这些操作将由其它对象进行触发。操作名应该是一个动词,通常其首字母要小写,并且其后要跟随一对小括号“()”。
依然以借阅系统中的代表图书的类Book为例,它应当具备的操作有借书、还书、预订等。添加了这些操作的类Book的类图如下图所示:
与属性类似,类图中的操作也可以在展示时省略,省略号表示至少有一个操作被隐藏。而展示操作的区域,也类似可以在顶端标明“operations”,它同样也是小写居中的复数形式。
操作可能会需要参数,添加了操作参数名称的类图如下所示:
为操作添加参数时,也可以明确说明各参数的类型,这可以通过在参数名后添加“:类型”来实现。类似地,如果建模者要说明操作的返回值类型,可以在跟随操作参数列表右侧的“)”后添加“:类型”来进行说明。为类Book的操作添加参数类型与返回类型的类图如下图所示:
需要补充说明的是,这里提及的“操作”在类的实例外是可见的,它可能会由一系列“方法”具体实现,这些“方法”在类的实例外是不可见的。通常,我们并不会刻意用“操作”与“方法”来区分这种差别,而是都称为“方法”,然后再通过可见性的约束来实现上述目的。
最后,再次提醒,如果在类图中要同时展示属性与操作,必须属性在上而操作在下。