数据库三级

Posted 2021-09-04 364.99°

目录

• 5.UML与数据库应用系统
• • 5.1.DBAS建模
  • • 5.1.1.各种建模方法
    • 5.1.2.统一建模语言
    • 5.1.3.UML中的视图
  • 5.2.DBAS业务流程与需求表达
  • • 5.2.1.业务流程与活动图概述
    • 5.2.2.系统需求与用例图
    • 5.2.3.三种模型元素的内容
    • 5.3.DBAS系统内部结构的表达
    • 5.3.1.概述
    • 5.3.2.系统结构与类图
    • 5.3.3.系统结构与顺序图
    • 5.3.4.系统结构与通信图
  • 5.4.DBAS系统微观设计的表达
  • • 5.4.1.概述
    • 5.4.2.微观设计与对象图
    • 5.4.3.微观设计与状态机图
    • 5.4.4.微观设计与时间图
  • 5.5.DBAS宏观设计的表达
  • • 5.5.1.宏观设计与包图
    • 5.5.2.宏观设计与交互概念图
    • 5.5.3.宏观设计与复合结构图
  • 5.6.DBAS系统实现与部署的表达
  • • 5.6.1.系统实现与组件图
    • 5.6.2.系统实现与部署图

5.UML与数据库应用系统

选择、填空

5.1.DBAS建模

5.1.1.各种建模方法

在用面向对象技术构建软件的早期阶段,面向对象建模语言的种类繁多,不同建模语言具有各自的优缺点

1. Booch方法：最早面向对象的方法之一，提出了面向对象软件工程的概念，比较适合于系统的设计和构造
2. OOSE方法：最大特点是面向用例，并在用例的描述中引入了外部角色的概念，适合支持商业工程和需求分析
3. OMT方法：采用了面向对象的概念，并引入各种独立于语言的表示符，适合用于分析和描述以数据为中心的信息系统

5.1.2.统一建模语言

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

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

1. 语义是用自然语言描述的,它定义在一个四层建模概念框架中 :
   1.1 元元模型层：组成了UML的最基本的元素“事物”,，代表要定义的所有事物
   1.2 元模型层：组成了UML的基本元素，包括面向对象和面向组件的概念，每个概念都是元元模型中“事务"概念的实例
   1.3 模型层：一层中的每个概念都是元模型层中概念的一个实例，这一层的模型通常叫作类模型或类型模型
   1.4 用户模型层：这层中的所有元素都是UML模型的实例。这层中的每个概念都是模型层的一个实例(通过分类)也是元模型层的一个实例
2. 表示法定义了UML的可视化标准表示符号,这决定了UML是种可视化的建模语言

---

视图的概念与种类

    使用UML时要从不同的角度观察和分析系统,因此产生了"视图"的概念。视图是对系统的模型在某方面的投影,注重于系统的某个方面。UML中包括以下五种视图：

5.1.3.UML中的视图

每种UML的视图都是由一个或多个图组成,一个图就是系统架构的某个侧面展示，所有的图-起组成了系统的完整视图。

UML 2.0提供了如下13种图：

5.2.DBAS业务流程与需求表达

5.2.1.业务流程与活动图概述

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

活动图的适用场合

1. 活动图主要用于描述系统、用例和程序模块中逻辑流程的先后执行次序，并行次序
   1.1 当活动图用于描述系统功能时,主要侧重于系统多个用例活动之间相互制约的执行顺序
   1.2 当活动图用于描述用例时,用于描述用例中的操作执行次序和操作完成的结果
2. 活动图用于低层次程序模块的作用类似于流程图，但活动图还可以描述并行操作，而流程图只能描述串行操作
3. 一般来说，活动图最适合用于描述系统或子系统的主要工作流程

---

用活动图描述的业务流程的主要内容：

1. 起始点：指一连串活动的开始点。在一张活动图中，必须有且只能有一个起始点，用
   表示
2. 结束点：指一连串活动的终结点。在一张活动图中,可以有多个结束点，用
   表示
3. 分区：在整个活动表达上，是一个非常重要的概念。可以利用分区来将活动分配给对应的角色

---

1. 活动之间的转换由 → 表示，→表示执行方向，其标注为执行下一一个活动的条件,如果箭头线上没有条件,表示执行完该活动后自动执行箭头所指向的活动
2. 加粗直线为同步条，表示这之后的活动执行路线可并行进行，或在其上的所有并行活动执行完后，到此转为顺序执行
3. 菱形代表分支，表示判断
   

5.2.2.系统需求与用例图

1. 系统需求概念：

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

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

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

5.2.3.三种模型元素的内容

1. 系统

系统需求：
    系统是在边界线以内的区域（即用例的活动区域）抽象地表示能够实现的所有基本功能
在用例图中系统用一个长方框表示，系统的名字写在方框上或方框里面，方框内部还可以包含该系统中用符号表示的用例

1. 角色是与系统进行交互的外部实体，可以是系统用户、其他系统、硬件设备
2. 一个角色可以执行多个用例，一个用例也可被多个角色使用。在用例图中，用通用化关系来描述角色之间的行为
3. 通用化关系:指把某些角色的共同行为抽取出来作为通用行为，这些通用行为构成超类
4. 在定义某一具体角色时，仅仅定义其不同的行为
5. 角色之间的通用化关系用带空心三角形（作为箭头）的直线表示，箭头的方向指向超类

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

用例与角色间的关系

1. 用例与角色之间有连接关系，此关系属于关联(或通信关联)。这种关联表明哪种角色能与该用例通信。
2. 关联关系是双向的一对一关系，表示不仅角色可以与用例通信，用例也可以与角色通信,表示方法是一条连接角色和用例的带箭头直线。用例间关系类型如下图所示：
   

5.3.DBAS系统内部结构的表达

5.3.1.概述

系统内部结构

5.3.2.系统结构与类图

类图主要表达的是问题领域的概念模型，除了要表达抽象概念的名称外，还需表达"属性"和“行为" ，类图表示如下：类图展现了一组类、接口和协作以及它们间的关系。系统可以有多个类图,单个类图仅表达系统的一个方面

1. 属性
   属性包括属性的名称、类型、缺省值。UML规定其语法为：可见性名称：类型=缺省值{约束性}
2. 操作
   操作描述了类的动态行为，在UML中，操作的语法定义：可见性名称 (参数表) ：返回类型表达式(约束性)
3. 类表示图
   

---

1. 属性
   1.1 缺省值：属性的初始值
   1.2 约束性：列出该属性所有可能的取值,在定义枚举类型的属性时经常使用,每个枚举值之间用逗号分隔
   1.3 类型：定义属性的种类。它可以是一个基本数据类型，也可以是用户自定义的类型
   1.4 名称：是一个字符串，表示属性的名称
   1.5 可见性：表示该属性对类外的元素是否可见。不同属性具有不同的可见性。"+" 表示公有( Public)，“#" 表示受保护( Protected)， "-” 表示私有( Private)
2. 操作（操作中可见性和约束性与属性中的含义一样）
   2.1 可见性： “+” 表示公有操作，"#" 表示受保护的操作，"-” 表示私有操作
   2.2 名称：是一个字符串，表示操作的名称
   2.3 参数表：语法与属性的参数相同，参数的个数是任意的
   2.4 返回类型表达式：依赖于语言的描述，此项为可选项
   2.5 约束性：用以描述对此操作的约束
3. 关系
       类与类之间通常有关联、通用化(继承)、依赖和精化四种关系。它们各自的分类及内容如下：
   
   3.1 关联关系
       表示两个类之间存在某种语义上的联系。例如: 一个人为一家公司工作，一家公司有很多办公室。就认为人和公司、公司和办公室之间存在某种语义上的联系
       通常情况下关联是双向的，若类与类之间的关联是单向的，则称为导航关联。实例如下图a所示。其实双向的普通关联可看作导航关联的特例，省略了表示两个关联方向的箭头
   
   3.2 角色关联
       若关联上没有角色名，则隐含地用类的名称作角色名。角色还具有多重性，表示可以有多少个对象参与该关联。多重性表示参与对象的数目的上下界限制。“★” 代表0~∞，“1” 是1…1的简写。如**“0…1” 表示零到1个对象，"0…或"★"表示零到多个对象; “3” 表示3个对象*。若图中没有明确标识关联的重数，就意味看是1。重数标识在表示关联关系的直线某方向上的末端。角色关联的实例如图b所示
   
   3.3 聚集的划分及表示方法
       聚集是种特殊形式的关联，它表示类之间的关系是整体与部分的关系。聚集可以进一步划分成共享聚集和组成
       ● 共享聚集即部分可以参加多个整体，例如：课题组包含很多成员，而每个成员又可以是另一一个课题组的成员。
   
       ● 组成是整体拥有各部分,部分与整体共存，如整体不存在了，部分也会消失，例如:打开一个窗口， 它由标题、外框和显示区所组成。窗口-旦关闭则各部分同时消失。如下b图所示。在UML中，共享聚集表示为空心姜形，组成为实心萎形
   

---

关系

1. 继承关系
       继承定义了一般元素和特殊元素之间的分类关系。在UML中，继承表示为一头为空心三角形的连线。
2. 依赖关系
       有两个元素A和B ，如果修改元素A的定义可能会引起元素B的定义的修改，称元素B依赖于元素A
3. 精华关系
       用于表示同一事物的两种描述之间的关系，常用于模型化表示同一个事物的不同实现。精化关系表示为带空心三角形的虚线

5.3.3.系统结构与顺序图

1. 顺序图的目的在于说明对象的协作如何达到系统的目标。系统的目标在进行用例分析时,已被区分为多个子目标。
2. 顺序图主要用于描述系统内对象之间的消息发送和接收序列。

顺序图的两坐标轴：

1. 纵向：表示时间的持续过程；纵向的虚线表示对象在序列中的执行情况，称为对象的“生命线”
2. 横向：表示对象；每一个对象用矩形框表示

---

对象间的通信用对象生命线之间的水平消息线表示，消息线的箭头说明消息的类型，如同步、异步或简单。下图是顾客购买商品用例绘制的顺序图：

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

消息也可以附加条件，规定只有当条件为真时才可以发送和接收消息。用条件来描述分支时，如果条件之间是互斥的，则一次只能发送一条消息

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

通常情况下，循环过程就可以用边缘注释来描述，如图

---

顺序图的其他功能

1. 描述对象是如何被创建和销毁的
       在顺序图中通过一条消息，一个对象可以创建另一个对象。 被销毁对象的生命线也停止于被销毁的位置。创建和销毁对象的消息一般是同步消息
2. 表示递归过程
       当一个操作调用它本身时，消息总是同步的，因而，在顺序图中用同步消息来表示，并用一条简单消息来表示返回
3. 动态模型
       顺序图主要的目的是表达对象与对象之间如何沟通与合作。顺序图中的所有元素都必须在类图中存在

5.3.4.系统结构与通信图

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

通信图概述：

1. 通信图显示了在交互过程中各个对象之间的组织交互关系以及对象彼此之间的链接
2. 通信图中的主要元素基本和顺序图相同，只是在消息的传递上要特别表达消息的传递是由哪一个对象到另外一 个对象
3. 顺序图和通信图都描述交互，但是顺序图强调的是时间，而通信图强调的是空间

---

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

5.4.DBAS系统微观设计的表达

5.4.1.概述

5.4.2.微观设计与对象图

对象图

1. 定义
       UML中的对象图被用来描述特定时间点中所有对象在系统中的结构，也可以把对象图当成系统在某一时间点的"快照" 。对象图展示了一组对象以及对象间的关系。
2. 与类图的关系
       对象图是类图的一个实例，对象之间的关系是类之间的关系的实例，其图形表达与类的图形表示相似。对象图通常用于表示复杂的类图的个实例
       对象图是某一个特定时间点上 ，系统所存在的所有对象的个快照。可以被用来解释类图以及验证所设计的类图是否符合实际的状况，也可以帮助程序设计人员理解类图的复杂结构
   

5.4.3.微观设计与状态机图

当某一个对象或某一个事件有非常复杂的状态转换时，可用状态机图来描述这个过程。

状态机图的概述：

1. 在状态图中，只能有一个起始状态 ，这一点与活动图中起始点是相同的，起始状态的图示是一个实心的圆形。结束状态代表整个状态机到此活动结束,可以有多个结束状态
2. 状态与状态之间，是利用转移来表达其间的关系的，用带有箭头的直线图示
3. 状态图的主要目的在于陈述系统中有关事件或对象的状态转移

---

在状态机图中，如果是因为某个事件发生而造成状态的转移，需要在转移的关系上标示上该事件。如下图所示：

5.4.4.微观设计与时间图

在状态机图中，状态之间的转移是由事件驱动的，而有时候状态的转换是由时间因素决定，可以配合时间图来描述时间对状态变化的影响

5.5.DBAS宏观设计的表达

5.5.1.宏观设计与包图

包的概述

1. 包是一种组合机制，把模型元素通过内在的语义连在一起成为一个整体叫包，包又称子系统
2. 构成包的模型元素称为包的内容
3. 包拥有自己的模型元素，包与包之间不能共用一个相同的模型元素，包能够引用来自其他包的模型元素
4. 包的图示类似书签卡片，由两个长方形组成，小长方形(标签)位于大长方形的左上角
   
5. 包图是表明包与包之间的关系的类图，必须保证低耦合、高内聚。广义地讲，包可以包含类、接口、组件、结点协作、用例等，还可以内嵌其他子包
6. 包与包之间允许建立的关系有依赖、精化和通用化
       继承：实现箭头
   
       依赖：虚线箭头
   

---

与类一样，包也具有可见性，利用可见性控制外部包对包中内容的存取方式

1. 共有可见允许其他元素存取和使用胞中的内容
2. 私有可见性只允许拥有和引用属于自己的包，存取和使用包中的内容
3. 保护可见性具有私有可见性的存取要求外，还允许有继承关系的包中的具体包存取一般包中的元素
4. 实现可见性与私有可见性非常相似。有依赖关系的包之间，如果被引用的包定义为实现可见性，则不允许应用该包中的元素使用被引用包中的类

---

包图是一个高阶的视图，由于所有的类都必须属于某一个包。 当包之间的关系被限定时，该包内部所有的类，都会收到包图中设置的影响，故包图可以作为项目后期实现与部署阶段的蓝图

5.5.2.宏观设计与交互概念图

交互概念图的概念

交互概述图主要是利用活动图作为基础，只是其在控制流间连接的UML元素并非活动，而是交互图(包括顺序图、通信图、时间图及交互概述图。交互概述图的主要元素和活动图完全一样，唯一不同的是一个交互框，用来取代活动图中的活动框。例如商品销售中顾客购买商品用例：

5.5.3.宏观设计与复合结构图

在UML中，复合结构图主要用来表达系统接口架构，适用于需要进行系统整合的情况，可以利用复合结构图绘制出要开发的系统与外部系统间的关系

市场经营管理系统复合结构图

复合结构图的概述

1. 复合结构图中最主要的元素就是部件,一个部件可以代表某个实体组件，也可以代表个子系统
2. 部件与部件之间的连接关系主要是装配关系,这种关系要通过接口来沟通
3. 部件与外部的部件连接时，必须通过端口才能连接，用正方形图示
4. 供给接口代表某个特定的部件提供服务给外部的部件。需求接口代表某个特定的部件需要外部的部件提供服务

5.6.DBAS系统实现与部署的表达

5.6.1.系统实现与组件图

组件图用来表示系统的静态实现视图，展现了一组组件之间的组织和依赖，用于对源代码、可执行的发布、物理数据库等的系统建模。组件是逻辑设计中定义的概念和功能在物理框架中的实现

市场经营管理系统组件图

5.6.2.系统实现与部署图

部署图又叫配置图，描述系统中硬件和软件的物理配置情况和系统体系结构。用结点表示实际的物理设备,并根据它们之间的连接关系，将相应的结点连接起来，并说明其连接方式。

市场经营管理系统部署图