计算机三级数据库技术备考知识点总结：第4~5章
第四章 数据库应用系统功能设计与实施
4.1 软件体系结构与设计过程
4.1.1 软件体系结构 软件体系结构/软件架构 = {构件，连接件，约束}。前面两章以及完成了概念和物理结构上的设计，已经到了把关系图完成的地步，接下来就是从代码的角度上去审视之前所做的工作，包括需求分析的结果以及关系图。
4.1.2 软件设计过程
概要设计，建立软件系统的总体结构和模块间的关系，定义个功能模块接口，设计全局数据库或数据结构，规定设计约束，制定计划；详细设计，细化概要设计中产生的功能模块，形成可编程的程序模块，制定模块测试方案，关于软件总体设计，通俗的讲就是现在要来生成软件的源代码了，像之前做的大多数工作一样也是自上而下的先对软件需求分解，抽象出大的模块，再逐步细化成小系统。
4.2 DBAS 总体设计
4.2.1 DBAS 体系结构设计 将系统从功能、层次/结构、地理分布(分布式系统)等角度进行分解，得到多个小系统，再定义小系统应实现的功能；设计系统的全局控制，明确各子系统之间的交互和接口关系。说白了跟我们 ER 很像，实体集+联系，这里是子系统+交互。
分解后选择或者设计合适的系统体系结构来组织子系统。
例如 C/S 客户/服务器体系结构，将 DBMS 数据管理功能与数据库应用相分离，将 DBMS 数据管理功能在客户端(也是用户交互)和服务器(分为数据库服务器完成 DBMS 的核心功能，和应用服务器完成用户交互功能)之间进行合理的分布和配置。数据库服务器和数据库可以有多个，即多个数据源，这种分开的方式有利于在添加新的数据库不用去维护一个大的总的数据库服务器，只需要为其配置一个小的即可。很直观的理解就是下载一个软件即客户端，让用户与客户端交互，客户端传递请求到 DBMS 去相应的数据库中调取数据并加工或执行其他操作。
例如三层 B/S 浏览器/服务器结构，将人机交互、应用业务逻辑处理和数据管理三类功能相互分离，提高了系统的可维护性。三层为：表示层即客户端，功能层即 Web 应用服务器(在 C/S 中是属于客户端的)，数据层即数据服务器。
4.2.2 DBAS 软件总体设计
4.2.3 软硬件选型与配置设计
4.2.4 业务规则初步设计 相比之前单纯的从 ER 模型到关系图的设计，应用软件的动态行为更加丰富。业务规则本质并不是一种“规则”，而是一种行为，即我们系统中的元素之间的组合、控制、信息传递等行为。先从外部交互入手，明确外部系统与 DBAS 的交互模式，然后再考虑内部的业务规则，逐步细化并作出初步设计。
例如商场经营管理，针对零售系统的商品销售业务需求， DBAS 需要满足以下但不限于此的业务规则： DBAS 交易子系统运行于销售终端POS机上；与后台支撑系统实现数据交互；交易前在系统内制定购物人的身份判断优惠折扣的情况......等等。通常业务活动都有逻辑上的先后顺序，可以表示成操作序列。也就是说我们撰写代码来实现这块功能的基本要求已经明确，与外部的交互就是输入所需的信息，计算、传递到数据库中相应的数据文件中去。
4.3 DBAS 功能概要设计
前面得到了总体设计的结果，加上更早的需求分析，可以将 DBAS 应用软件进一步细化为模块/子模块，组成应用软件的系统--子系统--模块--子模块的层次结构，并对以上的系统元素从结构、行为和数据三方面进行设计。
从功能角度可以将 DBAS 分成四部分：表示层、业务逻辑层、数据访问层、数据持久层。自上而下相邻的两层之间存在着相互作用。
4.3.1 表示层概要设计 主要进行人机界面设计。设计原则基本上都是为了用户使用体验。
4.3.2 业务逻辑层概要设计 主要任务是梳理 DBAS 各项业务活动，将其表示为各种系统构件。设计人员将数据库应用软件划分为一些列程序模块，每个模块实现一个具体的功能；但一个具体的功能可以由多个模块来共同实现；抽象出来的公共模块也可以被多个字程序中实现不同功能的程序模块调用。开始有熟悉的编程思想了。注意只需要考虑各业务模块的功能、输入输出等外部特性而不涉及内部的具体处理流程和编程实现机制。
高内聚与松耦合原则。
4.3.3 数据访问层概要设计 针对 DBAS 的数据处理需求设计用于操作数据库的各类事务，我理解就是封装一些操作。
4.4 DBAS 功能详细设计
4.4.1 表示层详细设计
使用原型迭代法：初步设计设计人机交互命令系统----用户界面细节设计----原型设计与改进首先构造原型系统再由用户体验提出建议后修改，直到符合要求。
4.4.2 业务逻辑层详细设计 对个程序模块设计内部处理流程、算法、具体数据结构和对外接口等内部内容。距离系统代码实现工作已经非常接近了。
4.5 应用系统安全架构设计
4.5.1 数据安全设计 安全性保护用户身份识别/权限控制/视图机制、完整性保护、并发控制排他锁(x锁)和共享锁(s锁)、数据可以的备份与恢复双机热备、数据转储、数据加密存储、数据加密传输数字安全证书、对称密钥加密、数字签名、数字信封。
4.5.2 环境安全设计 漏洞与补丁、计算机病毒防护、网络环境安全、物理环境安全。
4.5.3 制度安全设计
4.6 DBAS 实施
4.6.1 创建数据库 使用数据定义语言 DDL 或者图形化工具建立数据库和数据库对象，需要考虑初始空间大小、数据库增量大小、访问性能。
4.6.2 数据装载 筛选数据----转换数据格式为了符合新数据库中的数据类型要求----输入数据----校验数据。
4.6.3 编写与调试应用程序
4.6.4 数据库系统试运行
第五章 UML与数据库应用系统
5.1 DBAS 建模
UML 由语义和表示法两部分组成，语义用自然语言描述，表示法定义了 UML 的可视化标准表示符号。
语义是定义在一个四层建模概念框架中的从上到下细化：
(1) 元元模型层。组成了 UML 最基本的元素"事物"，代表要定义的所有东西。
(2) 元模型层。组成了 UML 的基本元素，包括面向对象和面向组建的概念，这一层的每个概念都是元元模型中"事物"概念的实例。
(3) 模型层。组成了 UML 的模型，这一层中的每个概念都是元模型层中概念的一个实例。
(4) 用户模型层。这层中的所有元素都是 UML 模型的实例。这层中的每个概念都是模型层的一个实例(通过分类)也是元模型层的一个实例。
UML 包括五种视图：结构视图、实现视图、行为视图、环境视图和用例视图。
5.2 DBAS 业务流程与需求表达
5.2.1 业务历程与活动图 活动图用于陈述活动与活动之间的流程控制的转移。要表达的明确、简单和清晰。
图中的元素有：起始点一连串活动的开始点，仅有一个，用实心原点表示；结束点一连串活动的终结点，可以有多个，用圆加一个圈套着表示；分区，利用分区来将活动分配给对应的角色。
例如商场经营管理系统中，商品销售业务模块的基本流程用活动图来描述如下：
有三个分区：顾客、销售员、销售系统。活动的起始点由客户开始----顾客 柜台结账----销售员 扫描商品----销售系统 生成商品清单----销售系统 计算商品总价----顾客 付款----销售员 收款----(判断是 VIP 用户需要额外执行 销售系统 累计积分，普通用户忽略这一步操作)----销售系统 打印小票----顾客 商品出库(结束点1)/销售系统 更新商品库(结束点2).
5.2.2 系统需求与用例图 用例模型是把满足用户需求的所有功能表示出来的工具，由三部分组成：用例椭圆、角色和系统长方框。用例用于描述从系统用户的角度来观察，系统应当具有哪些功能，是一个完整的功能是所有动作的集合；角色是与系统交互的外部实体，可以是用户(人)也可以是其他系统或设备；系统就是系统咯。
系统运行的大致过程为：外部角色先初始化用例，然后用例执行其代表所代表的功能，执行完后用例便给角色返回值，返回值是角色所需要的从系统中获取的信息。系统相当于各种用例的"黑盒子"。
用例图分为企业级用例图和系统级用例图。前者以商场经营管理为例，重点在于角色与系统的交互，用例忽略，而且引入了通用化关系，即把客服人员、销售人员、采购人员等商场的工作人员一律抽象为“员工”，然后“员工”这个超类再直接与商场经营管理系统交互；系统及用例图就用矩形框圈出了系统的边界，里面用椭圆来表示用例，用例可以与系统“外”的角色交互，称为之连接关系/关联/通信关联，也可以与系统内的其他用例由拓展<
可以再用活动图来进一步深入细化某个特定用例，配合上文档说明来阐明其工作流程。
5.3 DBAS 系统内部结构的表达
系统内部结构一般分为静态结构和动态结构，前者用类图描述，后者用顺序图和通信图来表示。
5.3.1 系统结构与类图 像其他语言中的类一样，秉承着面向对象的思想，先把主要的元素抽象出来，在 UML 中用“类”这个概念来表示。在高层给出类的主要职责，底层给出类的属性和操作。
1. 属性。UML 语法为 < 可见性 名称：类型=缺省值 {约束性} >。
可见性表示该属性对类外的元素是否可见，由 Public 公有、Protected 受保护和 Private 私有三种，在 UML 中用 "+"、"#"、"-" 表示。
名称，字符串。
类型，属性的种类，可以是基本的数据类型也可以是用户自定义的类型。
缺省值，属性的初始值，也相当于默认值。
约束性，列出该属性所有可能的取值，在定义枚举类型常使用，枚举值之间用逗号分隔。
2. 操作 UML 语法为 < 可见性 名称(参数表)：返回类型表达式 {约束性}>。
可见性、名称同上。
参数表，语法与属性的参数相同，个数是任意的。
返回类型表达式，依赖于语言的描述(?)，此项为可选项。
约束性，描述对该操作的约束。
3. 关系
(1) 关联关系。两个类存在某种语义上的联系，例如一个人为一家公司工作，可以认为“人”这个类和“公司”这个类存在语义上的联系。通常关联是双向，例如公司与人，之间的图示是两个矩形框(各代表两个类)用一根直线连接(无箭头指示方向说明是双向)。其中“雇员”和“雇主”称为角色名，角色还具有多重性即表示有多少个对象
参与该关联，1与*表示一家公司与多个人相关联。
如果类与类之间的关联是单向的，称之为导航关联。带箭头的线表示。
聚集是一种特殊形式的关联，表示类之间的关系是整体与部分的关系。聚集可以分成共享聚集和组成，部分参与多个整体就是共享聚集，组成就是整体与部分共存整体消失部分也会消失。
(2) 继承关系。
(3) 依赖关系。修改元素 X 的定义可能会引起元素 Y 的定义的修改，称元素 Y 依赖于元素 X。
(4) 精化关系。
5.3.2 系统结构与顺序图 系统内对象之间的信息发送与接收序列，强调时间。
5.3.3 系统结构与通信图 系统内对象之间的联系以及对象间发送和接收的信息，强调空间，不强调交互的顺序，没有将时间作为一个单独的维度，而使用序列号来确定信息及并发线程的顺序。
5.4 DBAS 系统微观设计的表达
5.5 DBAS 系统宏观设计的表达
5.6 DBAS 系统显示与部署的表达