|
1.统一建模语言(UML)概述 (1)在面向对象技术的发展过程中,产生了许多开发方法和开发工具。但都有各自的一套符号和术语,这导致了许多混乱甚至错误。 (2)在20世纪90年代中期,Booch、Rumbaugh和Jacobson等三位专家源于早先的方法和符号,但并不拘泥于早先的方法和符号,设计了一个标准的建立模型语言。 (3)他们把这个成果称为“统一建模语言”(Unified Modeling Language,简写为UML),并把UML版本交给OMG(Object Management Group)组织。 (4)经过修改后在1997年推出UML 1.0和UML 1.1版,确定UML为面向对象开发的行业标准语言,并得到了微软、Oracle、IBM等大厂商的支持和认证。 (5)UML适用于各类系统的建模,为了实现这种大范围应用能力,UML被定义成比较粗放和具有普遍性,以满足不同系统的建模。 (6)通过提供不同类型的图,UML能表达系统多方面的透视,这些图有类图(Class Diagram)、用例图(Use-Case Diagram)、状态图(State Diagram)、组件图(Component Diagram)等9种。 |
2.用类图表达类和关联 (1)类图 ①类图描述了系统的静态结构,包括类和类间的联系。 ②类图与前面学过的ER图、对象联系图有很多类似的地方。 ③但所用的术语和符号有所不同。 (2)类图与ER图中术语的区别
(3)类图中的基本成分是类和关联 ①类被表示为由三个部分组成的方框。 a.上面部分给出了类的名称。 b.中间部分给出了该类的属性(其类型为基本数据类型)。 c.下面部分给出了一些可以应用到这些对象的操作。 ②关联是对类的实例之间联系的命名,相当于ER模型中的联系类型。与关联有关的内容有。
|
|
|
|
关联元数(degree):与关联有关的类的个数,称为关联元数或度数。 关联角色(role):关联的端部,也就是与关联相连的类,称为关联角色。角色名可以命名,也可以不命名,就用类的名字作为角色名。 重复度(multiplicity):重复度是指在一个给定的联系中有多少对象参与。即是关联角色的重复度。重复度类似于ER模型中实体基数的概念。但这是两个相反的概念。
|
|
|
|
|
|
(4)实例1:大学、教师、课程组成的类图 ①对象联系图。
②形成的ER图。
③在图中,FACULTY是PERSON的子类。 ④类图。
⑤对类图的解释。 a.图中有4个类:University、Faculty、Coursetext和person。在每个类的方框中,指出了类名,对象的属性和操作。其中,Faculty是Person的子类,在超类的端点处标以空心三角形“Δ”。 b.图中有4个关联:President(1:1)、Staff(1:N)、Edit(1:N)和Teach(1:N)。这4个关联都是二元关联。虽然在类图中关联名可以沿着一个方向读(在关联名上加个实心三角形明确表示方向)。 |
(5)实例2
①两个一元关联:Is_married_to(婚姻)和Manage(管理)。 ②Manage关联的一端命名为角色“manager”,表示一个职员可担经理的角色。而另一角色没有命名,但是对关联已命名了。 ③在角色名没有出现时,可以把与端部相连的类的名字作为角色的命名。 (6)实例3
①表示Vendor(厂商)、Part(零件)和Warehouse(仓库)之间存在一个三元关联Supplies(供应)。 ②与ER图一样,用菱形符号表示三元关联,并填上关联的名字。 ③这里,联系是多对多对多,并且不可以用三个二元关联替换,若要替换,势必造成信息丢失。 |
3.用类图表达关联类 (1)像ER模型中联系可以有属性一样,类图中关联本身也可以有属性或自己的操作,此时应把关联模拟成“关联类”。 (2)实例。
①在ER模型中,学生与课程是一个多对多联系,其选课联系有一属性“成绩”。现在可以用类图表示。 ②图中,学生Student和课程Course表示成两个类。 ③Student和Course之间的关联Registration(注册)也有自己的属性term(学期)、grade(成绩)和操作checkEligibility(检查注册是否合格)。因此关联Registration应表示成一个类,即“关联类”,用虚线与关联线相连。 ④我们还可以发现,对于某门课程的注册,会给学生一个计算机账号。基于此,这个关联类还可以与另一个类ComputerAccount有一个关联。 |
4.用类图表达概化/特化 在2.6.2节中,已提到ER模型中的子类实体与超类实体概念。现在来讨论如何用类图来表达概化/特化。下面先举一个有概化/特化的类图例子,再详细解释。 |
(1)实例。 ①考察类图例子,每个类只标出类名和属性,未标出操作。
②职员有三种:计时制职员(HourlyEmp)、月薪制职员(SalariedEmp)和顾问(Consultant)。 ③这三种职员都共享的特征在Employee超类中,而自己特有的特征存储在其相应的子类中。 ④表示概化路径时,从子类到超类画一条实线,在实线的一端带空心的三角形指向超类。 ⑤也可以对给定超类的一组概化路径表达成一棵与单独子类相联系的多分支树,共享部分用指向超类的空心三角形表示。 ⑥譬如中,从门诊病人(Outpatient)到病人(Patient)和从住院病人(ResidentPatient)到病人(Patient)的两条概化路径结合成带指向Patient的三角形的共享部分。
|
(2)下面介绍类图中与概化/特化有关的内容。 ①鉴别器 a.可以在紧靠路径处设置一个鉴别器(discriminator)指出概化的基础。 b.在左图中,可以在职员类型(计时制、月薪制、顾问)的基础上鉴别出职员类别。
c.在右图中,可以在住不住院的基础上鉴别出病人的类别。 ②概化表示了继承性联系 a.子类的对象也是超类的对象,因此概化是一个“is a”联系,子类继承了超类的所有性质。 b.继承性是使用面向对象模型的一个主要优点。继承性可以使代码具有重用性(reuse):程序员不必编写已在超类中编写过的代码,只需对那些作为已存在类的新的、被精炼的子类编写不重复的代码。 ③抽象类和具体类 a.抽象类(abstract class)是一种没有直接对象,但它的子孙可以有直接对象的类。 b.在左图中,抽象类应在类名下面用一对花括号并写上abstract字样(类Patient中已标出)。 c.有直接对象的类,称为具体类(concrete class)。 d.在右图中,Outpatient和ResidentPatient都可以有直接对象,但Patient不可以有它自己直接的对象。 ④子类的语义约束 a.子类的语义约束词。 ·complete、imcomplete和disjoint等字样放在花括号内,靠近概化。 ·这些单词表示了子类之间的语义约束。 b.这些约束主要有4种,其意义如下。 ·overlapping(重叠):子类的对象集可以相交。 ·disjoint(不相交):子类的对象集不可以相交。 ·complete(完备):超类中的对象必须在子类中出现。 ·imcomplete(非完备):超类中的对象可以不在子类中出现。 c.说明。 ·图中的概化都是不相交的。 ·一个职员可以是计时制、月薪制或顾问,但不可以同时兼。 ·同样,一个病人可以是一个门诊病人或住院病人,但不可以同时是两者。 ·左图中的概化是非完备的,表示一个职员可以不属于三种类型中的任何一个,此时这个职员作为具体类Employee的对象存储。 ·相反,右图中的概化是完备的,表示一个病人必须是门诊病人或住院病人,不能是其他情况,因此Patient被说明成一个抽象类。 |
5.用类图表达聚合 (1)聚合的概念 ①聚合(aggregation)表达了成分对象和聚合对象之间的“is part of”(一部分)的联系。 ②聚合实际上是一种较强形式的关联联系(附加“is part of”语义)。 ③在类图中表示时,聚合的一端用空的菱形表示。 |
(2)实例1 ①大学的聚合结构。
②University(大学)由AdministrativeUnit(管理部门)和School(学院)聚合完成。 ③在Building(大楼)和Room(房间)之间联系的一端处的菱形不是空心的,是实心的。 ④实心菱形是一种较强形式的聚合,称为复合(Composition)。 ⑤在复合中,一个部分对象只属于一个整体对象,但与整体对象共存亡。 ⑥也就是聚合对象的删除将引起它的成分对象一起删除。 ⑦但是有可能在聚合对象消亡前就有可能其中一部分对象就被删掉了。大楼与房间就属于这样的联系。 |
(3)实例2 ①类图表示了Product(产品)、Part(零件)、Assembly(部件)和Simple Part(元件)之间的关联。
②产品有若干零件直接或间接组合而成。 ③零件被区分成部件和元件两类,元件是指不能再拆分的零件,而部件是指由其他部件或元件组合而成的零件。 ④也就是产品有若干零件组成,而零件本身又可以由其他零件组合而成。 ⑤这是一个“递归聚合”的例子。 ⑥在中,Part被表示成抽象类,因此一个零件可以是一个部件也可以是一个元件。 ⑦一个部件对象是零件实例的集合,表示它由其他部件和(或)元件组合而成。 |