UML与DBAS（上）-数据库技术

前言

与传统的建模方法相比，面向对象方法强调按照客观事物的本来面貌来刻画和描述客观对象，即不仅描述客观对象的属性特性，也描述其行为特征以及客观对象之间的关联关系。下面以数据库应用系统生命周期模型中的应用软件设计为主线介绍UML建模方法。

DBAS建模

统一建模语言UML

UML产生背景

在用面向对象技术构建软件的早期阶段，面向对象建模语言种类繁多，各有优缺点，相互之间也互有差异，主要有Booch、OOSE、OMT方法。

• Booch是最早的面向对象方法之一，提出了面向对象软件工程的概念，比较适合于系统的设计和构造。

• OMT方法引入各种独立于语言的表示符，这种方法用对象模型，动态模型，功能模型和用例模型共同完成对整个系统的建模，适用于分析和描述以数据为中心的信息系统。

• OOSE方法最大特点是面向用例，并在用例的描述中引入了外部角色的概念，适合支持商业工程和需求分析。

在精心比较不同的建模语言优缺点及总结面向对象技术应用实践的基础上，组织联合设计小组，根据应用需求取其精华，去其糟粕，求同存异，统一建模语言。

统一建模语言UML

概念：UML是一种定义良好，易于表达，功能强大，通用的可视化建模语言，为软件开发的各阶段提供模型化与可视化支持。

适用范围：适用于各种软件，应用领域以及开发工具的开发，同样也适用于数据库应用系统的设计和开发。

组成：UML的定义由语义和表示法两部分组成。

1.语义用自然语言描述，具体来说，UML的语义是定义在一个4层（或4个抽象级）建模概念框架中的，这4层分别是：

• 一、元元模型层。组成了UML的最基本的元素事物，代表要定义的所有事物。

• 二、元模型层。组成了UML的基本元素，包括面向对象和面向组件的概念，这一层的的每个概念都是元元模型层中事物概念的实例。

• 三、模型层。组成了UML的模型，这一层中的每个概念都是元模型层中概念的一个实例，这一层的模型通常叫做类模型或类型模型。

• 四、用户模型层。这层中的所有元素都是UML模型的实例。这一层的模型通常叫做对象模型或实例模型。

2.表示法定义了UML的可视化标准表示符号，这决定了UML是一种可视化的建模语言。

视图的概念和种类

使用UML时要从不同的角度观察和分析系统,因此产生了"视图”的概念。视图是对系统的模型在某方面的投影，注重于系统的某个方面，包括以下5种视图：结构视图，实现视图，行为视图，环境视图和用例视图。

每一种视图都是由一个或多个图组成的，一个图就是系统架构的某一个侧面的展示，所有的图一起组成了系统的完整视图。 UML2.0提供了以下13种不同的图：

DBAS业务流程与需求表达

业务流程与活动图

在UML中,对于业务流程支持的主要图形是活动图,活动图主要的目的在于陈述活动与活动之间的流程控制的转移。

活动图的适用场所

活动图主要用于描述系统、用例和程序模块中逻辑流程的先后执行次序,并行次序。

• （1）当活动图用于描述系统功能时,主要侧重于系统多个用例活动之间相互制约的执行顺序。

• （2）当活动图用于描述用例时,用于描述用例中的操作执行次序和操作完成的结果。

活动图用于低层次程序模块的作用类似于流程图,但活动图还可以描述并行操作,而流程图只能描述串行操作。一般来说，活动图最适合用于描述系统或子系统的主要工作流程。

活动图描述的业务流程

起始点：指一连串活动的开始点。在一张活动图中，必须有且只能有一个起始点,用就⚫表示

结束点：指一连串活动的终结点。在一张活动图中,可以有多个结束点，用看🔘表示。

分区：在整个活动表达上,是一个非常重要的概念。可以利用分区来将活动分配给对应的角色。

用活动图描述的业务流程有如下主要内容，下面是活动图的实例:

活动用圆角矩形框表示，活动之间的转换由箭头表示,箭头表示执行方向,其标注为执行下一个活动的条件,如果箭头线上没有条件,表示执行完该活动后自动执行箭头所指向的活动。

加粗直线为同步条,表示这之后的活动执行路线可并行进行,或在其上的所有并行活动执行完后,到此转为顺序执行。菱形代表分支,表示判断。

系统需求与用例图

系统需求概念：系统需求即是用户想要的，其本质最终不过是想办法捕捉到用户心中的真正期望。

用例模型的概念和组成关系

用例模型是把满足用户需求的所有功能表示出来的工具,对于正在构造的新系统,用例模型描述系统应该做什么;对于已构造完毕的系统,用例模型则反映了系统能够完成什么样的功能。

用例模型由用例图构成,用例图由系统、角色和用例三种模型元素以及元素之间的各种关系组成，其组成部分如下图所示:

系统

系统是在边界线以内的区域(即用例的活动区域)抽象地表示能够实现的所有基本功能。

在用例图中系统用一个长方框表示，系统的名字写在方框上或方框里面，方框内部还可以包含该系统中用符号表示的用例。

角色

角色是与系统进行交互的外部实体,可以是系统用户、也可以是其他系统、硬件设备。

一个角色可以执行多个用例, 一个用例也可被多个角色使用。在用例图中,用通用化关系来描述角色之间的行为。

通用化关系:指把某些角色的共同行为抽取出来作为通用行为,这些通用行为构成超类。在定义某一具体角色时 ,仅仅定义其不同的行为。

角色之间的通用化关系用带空心三角形(作为箭头)的直线表示,箭头的方向指向超类。

用例

用例代表的是一个完整的功能,是所有动作的集合。用例用于描述从系统用户的角度来观察,系统应该具有哪些功能，帮助分析人员理解系统的行为。在UML中，用椭圆形表示,用例位于系统边界的内部。

用例与角色之间的关系

用例与角色之间有连接关系,此关系属于关联(或通信关联)。这种关联表明哪种角色能与该用例通信。

关联关系是双向的一对一关系,表示不仅角色可以与用例通信,用例也可以与角色通信,表示方法是一条连接角色和用例的带箭头直线。

用例之间也存在关系，包括扩展、使用、组合三种。扩展和使用是继承关系即通用化关系的另一种体现形式，组合则是把相关的用例打包成包当做一个整体看待。用例间关系类型如下图所示:

用例之间的拓展关系，可以图示为带有构造型标志<>的通用化关系，使用关系被图示为具有构造型标志<>的通用化关系。

一般来说描述具体的用例的流程时，除了活动图，还要附上文档说明及用例叙述(包括前置条件、后置条件、事件流程)来去描述参与者和用例之间应该如何交互才能达到需求。

DBAS系统内部结构的表达

系统内部结构一般分为静态结构和动态结构。在UML图中，用类图来描述系统的静态结构，用顺序图和通信图来表示系统的动态结构。

系统结构与类图

类图技术是面向对象方法的核心技术，在面向对象方法的技术建模中，类、对象和他们之间的建模关系是最基本的建模元素。

类图主要表达的是问题领域的概念模型，除了要表达抽象概念的名称外，还需表达"属性"和"行为" .类图表示如下:

类图展现了一组类、接口和协作以及它们间的关系。系统可以有多个类图，单个类图仅表达系统的一个方面。

一、属性

属性包括属性的名称、类型、缺省值。UML规定其语法为:

可见性 名称:类型=缺省值{约束性}

名称:是一个字符串,表示属性的名称。

类型:定义属性的种类。它可以是一个基本数据类型，也可以是用户自定义的类型。

可见性:表示该属性对类外的元素是否可见。不同属性具有不同的可见性。"+”表示公有( Public).“#”表示受保护( Protected). "-" 表示私有( Private)。

约束性:列出该属性所有可能的取值,在定义枚举类型的属性时经常使用,每个枚举值之间用逗号分隔

缺省值：属性的初始值。

二、操作

操作描述了类的动态行为,在UML中,操作的语法定义:

可见性 名称(参数表) : 返回类型 表达式 ({约束性}

名称:是一个字符申,表示操作的名称。

可见性：+表示公有操作，#表示受保护操作，-表示私有操作。

参数表:语法与属性的参数相同,参数的个数是任意的。

返回类型表达式:依赖于语言的描述,此项为可选项。

约束性:用以描述对此操作的约束。

三、关系

类与类之间通常有关联、通用化(继承)、依赖和精化四种关系。

1.关联关系

表示两个类之间存在某种语义上的联系。例如: 一个人为某一家公司工作, 这家公司有很多办公室，就认为人和公司，公司和办公室之间存在某种语义上的联系。

通常情况下关联是双向的,若类与类之间的关联是单向的,则称为导航关联。实例如下图a所示。

双向的普通关联可看作导航关联的特例，省略了表示两个关联方向的箭头。

角色关联：若关联上没有角色名，则隐含地用类的名称作角色名。

角色还具有多重性，表示可以有多少个对象参与该关联。

多重性表示参与对象的数目的上下界限制。“" 代表0---∞，“1" 是1..1的简写。如“0..1” 表示零到1个对象，“0.."或“*"表示零到多个对象; "3” 表示3个对象。若图中没有明确标识关联的重数，就意味看是1。重数标识在表示关联关系的直线某一方向上的末端。角色关联的实例如图b所示。关联类通过一根虚线与关联连接，用于描述关联可能需要记录的一些信息，如图c所示。

聚集的划分及表示方法

聚集是一种特殊形式的关联,它表示类之间的关系是整体与部分的关系。聚集可以进一步划分成共享聚集和组成。

• 共享聚集即部分可以参加多个整体。

  例如:课题组包含很多成员，而每个成员又可以是另一个课题组的成员。如下a图所示。

• 组成是整体拥有各部分，部分与整体共存， 如整体不存在了，部分也会消失。

  例如:打开一个窗口,它由标题、外框和显示区所组成。窗口一旦关闭则各部分同时消失。如下图b所示。在UML中，共享聚集表示为空心菱形，组成为实心萎形。

2.继承关系

继承定义了一般元素（基类元素、父元素）和特殊元素（子元素）之间的分类关系。在UML中,继承表示为一头为空心三角形的连线。

3.依赖关系

有两个元素A和B ,如果修改元素A的定义可能会引起元素B的定义的修改,称元素B依赖于元素A。

4.精化关系

用于表示同一事物的两种描述之间的关系,常用于模型化表示同一个事物的不同实现。精化关系表示为带空心三角形的虚线。

系统结构与顺序图

顺序图的目的在于说明对象的协作如何达到系统的目标。系统的目标在进行用例分析时,已被区分为多个子目标。

顺序图主要用于描述系统内对象之间的消息发送和接收序列。顺序图有两个坐标轴:

• 纵向表示时间的持续过程，横向表示对象;
• 每一个对象用矩形框表示，纵向的虚线表示对象在序列中的执行情况称为对象的生命线。

对象间的通信用对象生命线之间的水平消息线表示，消息线的箭头说明消息的类型如同步、异步或简单。消息/方法名字标注在消息线上面。

消息也可以附加条件，这时规定只有当条件为真时才可以发送和接收信息。当用条件来描述分支时,如果各分支的条件不互相排斥,则消息可能会并行发出。如下图所示是带互斥条件的消息分支。

用条件来描述分支时,如果条件之间是互斥的,则一次只能发送一条消息。

在对象图的左边和右边可以有标签和注释。标签可以是任何类型的,例如可以用标签来描述定时约束,如下图所示。

通常状况下,循环过程就可以用边缘注释来描述,如下图所示。

顺序图的其他功能

• 描述对象是如何被创建和销毁的：在顺序图中通过一条消息，一个对象可以创建另一个对象。 被销毁对象的生命线也停止于被销毁的位置。创建和销毁对象的消息一般是同步消息

• 表示递归过程：当一个操作调用它本身时,消息总是同步的,因而,在顺序图中用同步消息来表示，并用一条简单消息来表示返回。

• 动态模型：顺序图主要的目的是表达对象与对象之间如何沟通与合作。顺序图中的所有元素都必须在类图中存在。

系统结构与通信图

通信图是交互图的一种,也被称为协作图。通信图中包含一组对象 ,并在图中展示这些对象之间的联系以及对象间发送和接收的消息。

通信图显示了在交互过程中各个对象之间的组织交互关系以及对象彼此之间的链接。

通信图中的主要元素基本和顺序图相同,只是在消息的传递上要特别表达消息的传递是由哪一个对象到另外一个对象。

顺序图和通信图都描述交互,但是顺序图强调的是时间,而通信图强调的是空间。

通信图显示的是对象之间的关系,并不侧重交互的顺序,它没有将时间作为一个单独的维度,而是使用序列号来确定消息及并发线程的顺序。下图是顾客购买商品的通信图。

微信关注