系统架构师学习笔记

软考 高级职称 系统架构师 学习笔记

---

第一章 计算机组成与体系结构

1.1 计算机系统组成

1.1.1 计算机硬件的组成

1. 控制器。控制器是分析和执行指令的部件，也是统一指挥并控制计算机各部件协调工作的中心部件，所依据的是机器指令。控制器的组成包含如下：
   
   • 程序计数器PC：存储下一条要执行指令的地址；
   • 指令寄存器IR：存储即将执行的指令；
   • 指令译码器ID：对指令中的操作码字段进行分析解释；
   • 时序部件：提供时序控制信号。
2. 运算器。也成算数逻辑单元（ALU），主要功能是在控制器的控制下完成各种算术运算和逻辑运算。运算器的组成包含如下：
   
   • 算数逻辑单元ALU：数据的算数运算和逻辑运算；
   • 累加计数器AC：通用寄存器，为ALU提供一个工作区，用在暂存数据；
   • 数据缓冲寄存器DR：写内存时，暂存指令或数据；
   • 状态条件寄存器PSW：存状态标志与控制标志。
3. 主存储器。也称为内存储器（通常简称主存或内存），存储现场操作的信息于中间结果，包括机器指令和数据。
4. 辅助存储器。也称外存储器，通常简称外存或辅存。存储需要长期保存的各种信息。
5. 输入设备。
6. 输出设备。

1.1.2 计算机系统结构的分类

1. 存储程序的概念

2. Flynn分类

根据指令流、数据流的多倍性特征对计算机系统进行分类。根据不同的指令流-数据流组织方式，将计算机系统分为以下四类：

1. 单指令流单数据流SISD
2. 单指令流多数据流SIMD
3. 多指令流单数据流MISD
4. 多指令流多数据流MIMD

1.1.3 复杂指令集系统于精简指令集系统

1. 复杂指令系统计算机CISC指令系统的特点

1. 指令数量众多，通常有100-250条
2. 指令使用频率相差悬殊
3. 支持很多种寻址方式。通常为5-20种
4. 变长的指令。指令长度不固定
5. 指令可以对于主存单元中的数据直接进行处理。执行速度较慢
6. 以微程序控制为主

2. 精简指令系统RISC的特点

1. 指令数量少。
2. 指令的寻址方式少。通常只支持寄存器、立即数、相对寻址方式等。
3. 指令长度固定。
4. 以硬布线逻辑控制为主。
5. 单周期指令执行，采用流水线技术。
6. 优化的编译器。
7. CPU中通用寄存器数量多，一般在32个以上，有的可达上千个。

大多数RISC采用了Cache方案，使用Cache来提高取指令的速度。而且，有的RISC使用两个独立的Cache来改善性能，一个称为指令Cache，另一个称为数据Cache。这样，取指令和取数据可以同时进行，互不干扰。

1.1.4 总线

是一组能为多个部件分时共享的公共信息传输线路。共享是指总线上可以挂接多个部件，各个部件之间相互交换的信息都可以通过这组公共线路传送；分时是指同一时刻只允许有一个部件向总线发送信息，如果出现两个或两个以上部件同时向总线发送信息，势必导致信号冲突。当然，在同一时刻，允许多个部件同时从总线上接收相同的信息。

按总线相对于CPU或其他芯片的位置可以分为内部总线和外部总线两种。在CPU内部，寄存器之间和算数逻辑部件ALU与控制部件之间传输数据所用的总线称为内部总线；外部总线是指CPU与内存RAM、ROM和输入/输出设备接口之间进行通信的线路。由于CPU通过总线实现程序取指令、内存/外设的数据交换，在CPU与外设一定的情况下，总线速度是制约计算机整体性能的最大因素。

按总线功能来划分，又可以分为地址总线、数据总线、控制总线三类，人们通常所说的总线都包括这三个组成部分，地址总线用来传送地址信息，数据总线用来传送数据信息，控制总线用来传送各种控制信号。

1.2 存储器系统

用来存放程序和数据的部件。

传统的存储器系统一般分为高速缓冲存储器（Cache）、主存、辅存三级。

• 主存可由CPU直接访问，存储速度快，但是容量较小，一般用来存放当前正在执行的程序和数据。
• 辅存直接设置在主机外部，存储容量大，价格较低，但存取速度较慢，一般用来存放暂时不参与运行的程序和数据，CPU不可以直接访问辅存，辅存中的程序和数据在需要时才传送到主存。
• 当CPU速度很高时，为了使访问存储器的速度能与CPU的速度相匹配，又在主存和CPU间增设了一级Cache。Cache的存取速度比主存速度更快，但是容量更小，用来存放当前最急需处理的程序和数据，以便更快速的向CPU提供指令和数据。

多层级的存储体系之所以能用低投入换来较高的存取速率，得益于局部性原理。局部性原理是指程序在执行时呈现出局部性规律，即在一较短的时间内，程序的执行仅局限于某个部分。相应的，它所访问的存储空间也仅局限于某个区域。程序局限性包括时间局部性和空间局部性，时间局部性是指程序中的某条指令一旦执行，不久以后该指令可能再次执行。产生时间局部性的典型原因是由于程序中存在着大量的循环操作；空间局部性是指一旦程序访问了某个存储单元，不久以后，其附近的存储单元也将被访问，即程序在一段时间内所访问的地址可能集中在一定的范围内，其典型情况是程序顺序执行。

存储器中常用的存储方式：

1. 顺序存取：存储的数据以记录的形式进行组织。对数据的访问必须按特定的顺序进行。磁带存储器
2. 直接存取：与顺序存储相似。直接存储使用一个共享的读写装置对所有的数据进行访问。但是，每个数据块都有唯一的地址标识，读写装置可以直接移动到目的数据块所在位置进行访问，存取时间也是可变的。硬盘存储器。
3. 随机存取：存储器的每一个可寻址单元都具有自己唯一的地址和读写装置，系统可以在相同的时间内对任意一个存储单元的数据进行访问，而与先前的访问序列无关。主存储器。
4. 相联存取：是随机存取的一种形式，但是选择某一单元进行读写时取决于其内容而不是其地址。每个单元都有自己的读写装置，读写时间也是一个常数，使用相联存取方式，可以对所有的存储单元的特定位进行比较，选择符合条件的单元进行访问。Cache。

1.2.1 主存储器

用来存放计算机运行期间所需要的程序和数据，CPU可以直接随机的进行读/写。主存具有一定容量，存取速度较高。由于CPU要频繁的访问主存，所以主存的性能在很大程度上影响了整个计算机系统的性能。主存可以分为随机存取存储器和只读存储器。

1. 随机存取存储器
   RAM，可写入读出，但断电后信息无法保存，因此只能用于暂时存储数据。可分为DRAM动态存储和SRAM静态存储两种。DRAM的信息会随时间逐渐消失，因此需要定时对其刷新维持信息不丢失；SRAM在不断电的情况下信息能够一直保持而不会丢失。DRAM密度大于SRAM且更加便宜，但SRAM速度快，电路简单，容量小，价格高。
2. 只读存储器
   ROM，可以看作RAM的特殊形式，特点是：存储器的内容只能随即读出而不能写入。一旦写入，固定不变，即使断电，写入的内容也不会丢失，又称固定存储器。用来存放系统程序BIOS
3. 主存编址方法
   计算机系统中，存储器中每个单元的位数时相同且固定的，成为存储器编址单位。主要分为字编址和字节编址

1.2.2 辅助存储器

用于存放当前不需要立即使用的信息，一旦需要，再和主机成批交换数据。主机的外部设备，称为外存储器。存储容量大、可靠性高、价格低。

1. 磁带存储器

顺序存取的设备，特点为：存取时间较长，但存储容量大，便于携带，价格便宜。

2. 磁盘存储器

在磁盘上进行信息的读写时，首先要定位到目标磁道，这个过程称之为寻道，寻道所消耗的时间成为寻道时间，定位到目标磁道后，需要定位到目标扇区，此过程通过旋转盘片完成，平均旋转半圈可到目标位置，故磁盘访问时间为：

$$磁盘访问时间（存取时间）=寻道时间+旋转延迟时间$$

1.2.3 Cache存储器

功能是为了提高CPU数据输入输出的速率，即CPU与存储系统间数据传送带宽限制。通常在CPU和内存之间设置小容量的Cache。

Cache采用相联存储器CAM，是一种基于数据内容进行访问的存储设备。对其写入数据时，CAM能够自动选择一个未用的空单元进行存储；当需要读出数据时，而是直接给出该数据或该数据的一部分内容。CAM通过对所有存储单元中的数据同时进行比较，并标记符合条件的所有数据以供提取。比较是同时、并行进行的。

1. Cache基本原理

使用Cache改善性能的依据是程序的局部性原理。

根据局部性原理，可以爸目前常用或将要用到的信息预先放到Cache中，当CPU需要读取数据时，首先在Cache中查找是否有所需内容，如果有，则直接从Cache中读取；若没有，再从内存中读取该数据，然后同时送往CPU和Cache。如果CPU需要访问的内容大多都能在Cache中找到（称为访问命中），则可以大大提高系统性能。

如果以$h$代表对Cache的访问命中率（$1-h$称为失效率，或未命中率），$t_1$表示Cache的周期时间，$t_2$表示内存的周期时间，以读操作为例，使用“Cache+主存储器”的系统的平均周期为$t_3$，则：

$$t_3=t_1\times h+t_2\times (1-h)$$

系统的平均存储周期与命中率有很密切的关系，命中率的提高即使很小也能导致性能的极大改善。

例如：设某计算机主存的读/写时间为100ns，有一个指令和数据合一的Cache，已知该Cache的读/写时间为10ns，取指令的命中率为98%，取数的命中率为95%，在执行某类程序时，约有$1/5$指令需要存/取一个操作数。假设指令流水线再任何时候都不阻塞，则设置Cache后，每条指令的平均访存时间约为：

$$(2\%\times 100ns+98\%\times 10ns)+1/5\times (5\%\times 100ns+95\%\times 10ns)=14.7ns$$

2. 映射机制

当CPU发出访存请求后，存储器地址先被送到Cache控制器以确定所需数据是否已在Cache中，若命中则直接对Cache进行访问。这个过程称为Cache的地址映射（映像）。在Cache的地址映射中，主存和Cache将均分成容量相同的块（页）。常见的映射方法有直接映射、全相联映射和组相联映射。

1) 直接映射

以随机存储器作为Cache存储器，硬件电路较简单。在进行映射时，主存地址被分成三个部分，从高到低一次为：区号、页号、页内地址。

区号	页号	页内地址
7位	4位	19位
-	Cache地址	Cache地址

例如：内存容量为1GB，Cache容量为8MB，页大小为512KB。直接映像中，先分区，再分页。一个区的大小就是Cache容量的大小，所以一共分：1GB/8MB=128个区，所以区号为7位。每个区分：8MB/512KB=16个页，所以页号为4位。

直接映射方式中，没个内存也只能复制到某一固定的Cache页中。映射规律为：主存中每个区的第0页，只能进入Cache的第0页。若当前时刻Cache中0号页已被占据，而1-15号页空闲，现在要将1区的第0页（即内存的16页）调入Cache是会发生冲突的。所以直接映射的块冲突率非常高。

在Cache中，为每一个页设立一个Cache标记，该标记用于识别当前的Cache块来自于哪个内存页。直接映像中，由于每个区的N号页，都必须进入到Cache的N号页，所以只需要记录区号即可。所以此时标记位的长度为7位。

直接映射方式的优点是比较容易实现，缺点是不够灵活，有可能使Cache的存储空间得不到充分利用。

2) 全相联映像

使用相联存储器组成的Cache存储器。该方式中，主存中的每一页可以映射到Cache的任一页。如果淘汰Cache中某一页的内容，则可调入任一主存页的内容，因此比直接映射方式更为灵活。

在全相联映射方式中，主存地址分为两个部分，分别为地址部分（主存页标记）和数据部分（页内地址）。数据部分用来存放数据，而地址部分则存放该数据的存储器地址。

页号	页内地址
11位	19位
主存页号

因为Cache中某一页的内容都可以在主存中的任一页中存储，所以在Cache中也需要存储该页所对应的主存页号，所以，Cache标记信息位数增加，比较逻辑成本随之增加。

在全相联映射方式中，主存地址不能直接提取Cache页号，而是需要将主存页标记于Cache各页的标记诸葛比较，直到找到符合标记的页（访问Cache命中），或者全部比较完成仍无符合的标记（访问Cache失败）。因此这种映射方式速度很慢，是掉了高速缓存的作用，也是该方式的最大缺点。因此只适用于小容量Cache。

3) 组相联映射

也称页组映射，介于直接映射和全相联映射之间，是这两种映射的折衷方案。全相联映射以页为单位，可自由映射，没有固定的对应关系，直接映射方式中，主存分组，主存组内的各页与Cache的页之间采取的是固定的映射关系，但各组均可映射到Cache中。在组相联映射中就，主存和Cache都分组，主存中的一个组内的页数与Cache的分组数相同。

区号	组号	组内页号	页内地址
7位	3位	1位	19位
-	Cache地址	Cache地址	Cache地址

组关联映射的规则为：主存中的组于Cache中的组形成直接映射关系，而每个组内的页是全相联映射关系。如主存中1区0页，它在0组中，所以只能进入Cache中的0组中，至于进入到Cache中的0组0页还是0组1页，并无强制要求，可以任意放置。

如果Cache中每组只有一页，则组相联映射方式就变成了直接映射方式，如果Cache中每组页数为16页（即Cache只分一组），那就是全相联映射。

在组相联映射中，由于Cache中每组有若干可以选择的页，因而它在映射定位方面较直接映射方式灵活；每组页数有限，因此付出的代价不是很大，可以根据设计目标选择组内页数。

3. 替换算法

当Cache中产生了一次访问未命中之后，相应的数据应同时读入CPU和Cache。但是当Cache已存满数据后，新数据必须替换（淘汰）Cache中的某些旧数据。

1) 随机算法

最简单的替换算法。完全不管Cache块过去、现在及将来的使用情况，简单的根据一个随机数，选择一块替换掉。

2) 先进先出算法FIFO

按照调入Cache中的先后顺序决定淘汰的顺序，即在需要更新时，将最先进入Cache中的块最为被替换的块。该方法要求为每块做一记录，记下他们进入Cache的先后顺序。这种方法容易实现，而且系统开销小，缺点是可能会把一些需要经常使用的程序块（如循环程序）替换掉。

3) 近期最少使用原则LRU

LRU算法是把CPU近期最少使用的块作为被替换的块。这种替换方法需要随时记录Cache中各块的使用情况，以便确定哪个块时近期最少使用的块。LRU算法相对合理，但实现起来比较复杂，系统开销较大。通常需要对每一块设置一个称为“年龄计数器”的硬件或软件计数器，用以记录其被使用的情况。

4. 写操作

因为需要保证缓存在Cache中的数据与内存中的内容一致，相对读操作而言，Cache的写操作比较复杂。

1) 写直达

当要写Cache时，数据同时写回内存，有时也称为写通。当某一块需要替换时，也不必把这一块写回到主存中去，新调入的块可以立即把这一块覆盖掉。这种方法实现简单，而且能随时保持主存数据的正确性，但可能增加多次不必要的主存写入，会降低存取速度。

2) 写回

CPU修改Cache中的某一块之后，相应的数据并不立即写回内存单元，而是当该块从Cache中被淘汰时，才把数据写回到内存中。在采用这种更新策略的Cache块表中，一般有一个标志位，当一块中的任何一个单元被修改时，标志位被置“1”。当需要替换掉这一块时，如果标志位为“1”，则必须先把这一块写回到主存中去之后，才能再掉入新的块；如果标识为“0”，则这一块不必写回内存，只要用新调入的块覆盖掉这一块即可。这种方法的优点是操作速度块，缺点是因主存中的字块会随时修改而有可能出错。

3) 标记法

对Cache中的每一个数据设置一个有效位。当数据进入Cache后，有效位置“1”；而当CPU要对该数据进行修改时，数据只需要写入内存并同时将该有效位置“0“。当要从Cache中读取数据时需要测试其有效位，若为”1“则直接从Cache中取数，否则，从内存中取数。

1.3 流水线

流水线技术吧一个任务分解为若干顺序执行的子任务，不同的子任务由不同的执行机构负责执行，而这些机构可以同时并行工作。在任一时刻，任一任务只占用其中一个执行机构，这样就可以实现多个任务的重叠执行，以提高效率。

1.3.1 流水线周期

流水线应用过程中，会将需要处理的工作分为N个阶段，最耗时的那一段所消耗的时间为流水线周期。如：使用流水线技术执行100条指令，每条指令取指2ms，分析4ms，执行1ms，则流水线周期为4ms。

1.3.2 计算流水线执行时间

延续上面的场景，将一个任务的执行过程可以分为N个阶段，假设每个阶段的完成时间为t，则完成该任务所需的时间即为Nt。若以传统的形式，则完成k个任务所需的时间为kNt；而使用流水线技术执行，则花费的时间是Nt+(k-1)t。也就是说，除了第1个任务需要完整的时间外，其他都通过并行，节省下了大量的时间。所以流水线的执行时间可以通俗的表达为：

流水线执行时间=第1条指令的执行时间+(n-1)X流水线周期
n代表需要处理的任务数量。

在考试时，需要特别注意一个细节问题，流水线的执行时间计算，其实进一步可以分理论情况和实践情况两种不同的处理方式。下面以实例进行说明。

例：某计算机系统，一条指令的执行需要经历取指2ms，分析4ms，执行1ms三个阶段，现需要执行100条指令，利用流水线技术需要多长时间？
理论上来说，一条指令的执行时间为：2ms+4ms+1ms=7ms
所以理论上流水线的执行时间为：2ms+4ms+1ms+(100-1)X4ms=403ms
而实际上，真正做流水线处理时考虑到处理的复杂性，会将执行的每个阶段的时间都统一为流水线周期，即1条指令的执行周期为4ms+4ms+4ms=12ms。
所以，实际流水线的执行时间为4ms+4ms+4ms+(100-1)X4ms=408ms。

考试时，80%以上的概率采用理论公式计算，所以考试时需要以理论公式计算，若计算的结果无正确选项，才考虑使用实际公式计算。

1.3.3 流水线的吞吐率

流水线的吞吐率（Though Put Rate，TP）是指在单位时间内流水线所完成的任务数量或输出的结果数量。计算流水线吞吐率的最基本公示如下：

$$TP=\frac{n}{T_k}$$

$n$为任务数，${T_k}$是处理完成$n$个任务所用的时间。

流水线的最大吞吐率为：

$$TP_{max}=\operatorname*{Lim}_{n\to \infty}\frac{n}{(k+n-1)\Delta t}=\frac{1}{\Delta t}$$

1.3.4 流水线的加速比

完成同样一批任务，使用流水线所用的时间与不使用流水线所用的时间之比成为流水线的加速比（speedup radio）。如果不使用流水线，则顺序执行所用的时间为$T_0$，使用流水线的执行时间为$T_k$，则计算流水线加速比的基本公式如下：

$$S=\frac{T_0}{T_k}$$

如果流水线各个流水段的执行时间都相等（设为$\Delta t$），则一条$k$段流水线完成$n$个连续任务所需要的时间为$(k+n-1)\Delta t$。如果不使用流水线，即顺序执行这$n$个任务，则所需的时间为$nk\Delta t$。因此，各个流水段执行时间均相等的一条$k$段流水线完成$n$个连续任务的实际加速比为：

$$S=\frac{nk\Delta t}{(k+n-1)\Delta t}=\frac{nk}{k+n-1}$$

这种情况下的最大加速比为：

$$S_{max}=\operatorname*{Lim}_{n\to \infty}\frac{nk}{k+n-1}=k$$

第二章 操作系统

掌握操作系统原理的关键在于深入理解“一个观点，两条线索”。一个观点是以资源管理的观点来定义操作系统；两条线索是指操作系统如何管理计算系各类资源和控制程序的执行。

2.1 操作系统的类型与结构

操作系统的基本类型有：批处理操作系统、分时操作系统和实时操作系统。从资源管理的角度看：操作系统主要是对处理器、存储器、文件、设备和作业进行管理。

2.1.1 操作系统的定义

OS是计算机系统中的核心系统软件，负责管理和控制计算机系统中的硬件和软件资源，合理的组织计算机工作流程和有效的利用资源，再计算机和用户之间起到接口的作用。

2.1.2 操作系统分类

按照功能划分，可以分为批处理操作系统、分时操作系统、实时操作系统、网络操作系统、分布式操作系统、嵌入式操作系统、微内核操作系统等。

2.2 操作系统基本原理

主要功能是进行处理机与进程管理、存储管理、设备管理、文件管理和作业管理的工作。

2.2.1 进程管理

进程是处理机管理中最基本、最重要的概念。进程是系统并发执行的体现。由于在多道程序系统中，众多的计算机用户都以各种各样的任务，随时随地争夺使用处理机。为了动态的看待操作系统，则以进程作为独立运行的基本单位，以进程作为分配资源的基本单位。处理机管理也称进程管理。

1. 进程的概念

顺序程序是指程序中若干操作必须按照某种先后次序来执行，并且每次操作前和操作后的数据、状态之间都有一定的关系。在多道程序系统中，程序的运行环境发生了很大的变化，主要体现在：

1. 资源共享。为提高资源的利用率，计算机系统中的资源由多道程序共同使用。
2. 程序的并发执行或并行执行。逻辑上讲允许多道不同用户的程序并行运行；允许一个用户程序内部完成不同操作的程序段之间并行运行；允许操作系统内部不同的程序之间并行运行。物理上讲：内存储器中保存多个程序，I/O设备被多个程序交替的共享使用；在多处理机系统的情形下，表现为多个程序在各自的处理机上运行，执行时间是重叠的。单处理机系统时，程序的执行表现为多道程序交替的在处理机上相互空插运行。

实际上，在多道程序系统中，程序的并发执行和资源共享之间时相辅相成的。以方便，只有允许程序并行执行，才可能存在资源共享的问题；另一方面，只有有效的实现资源共享，才可能使得程序并行执行。

并发操作实际上是这样的：大多数程序段只要求操作在时间上是有序的，也就是有些操作必须在其他操作之前，这是有序的，但其中有些操作却可以同时进行。

2. 进程的状态转换

进程至少具有以下三种状态：

1. 就绪状态。当进程已分配了除CPU意外的所有必要的资源后，只要能再获得处理机，便能立即执行，这是的进程状态为就绪状态。在一个系统中，可以有多个进程同时处于就绪状态，通常把它们排成一个队列，称为就绪队列。
2. 执行状态。指进程已获得处理机，其程序正在执行。在单处理机系统中，只能有一个进程处于执行状态。
3. 阻塞状态。指进程因发生某事件（如请求I/O、申请缓冲空间等）而暂停执行时的状态，即进程的执行受到阻塞，故称这种暂停状态为阻塞状态，也称“等待”状态，或“睡眠”状态。通常将处于阻塞状态的进程排成一个队列，称为阻塞队列。

进程状态的变化情况如下：

1. 运行态$\to$等待态：一个进程运行中启动了外围设备，它就变成等待外围设备传输信息的状态；进程在运行中申请资源得不到满足时；进程在运行中出现了故障时
2. 等待态$\to$就绪态：外围设备工作结束后等待外围设备传输信息的进程结束等待；等待的资源得到满足时；故障排队后让等待干预的进程结束等待。任何一个结束等待的进程必须先变成就绪状态，待分配到处理器后才能运行。
3. 运行态$\to$就绪态：进程用完了一个使用处理器的时间后强迫该进程暂时让出处理器，当有更优先权的进程要运行时也迫使正在运行的进程让出处理器。由于自身或外界原因成为等待状态的进程让出处理器时，它的状态就变成就绪状态。
4. 就绪态$\to$运行态：等待分配处理器的进程，系统按一种选定的策略从处于就绪状态的进程中选择一个进程，让它占用处理器，哪个被选中的进程就变成了运行态。

3. 关于挂起状态

引入刮起状态的原因有：

1. 对换的需要。为了缓和内存紧张的情况，而将内存中处于阻塞状态的进程换至外存上，使进程又处于一种有别于阻塞状态的新状态。因为即使该进程所期待的事情发生，该进程仍不具备执行条件而不能进入就绪队列，成这种状态为挂起状态。
2. 终端用户的请求。当终端用户在自己的程序运行期间，发现有可以问题时，往往希望使自己的进程暂停下来。也就是说，使正在执行的进程暂停执行，若是就绪进程，则不接受调度以便研究其执行情况或对程序进行修改。把这种静止状态也称为挂起状态。
3. 父进程请求。父进程常希望挂起自己的子进程，以便考察和修改子进程，或者协调各子进程之间的活动。
4. 负荷调节的需要。当实时系统中的工作负荷较重，有可能影响到实时任务的控制时，可由系统吧一些不重要的进程挂起，以保证系统正常运行。
5. 操作系统的需要。操作系统希望挂起某些进程，以便检查运行中资源的使用情况及进行记账。

综上所述，挂起状态具有以下三个属性：

1. 被挂起的进程，原来可能处于就绪状态，此时进程（被挂起）的状态称为挂起就绪；若被挂起的进程原来处于阻塞状态，此时的状态称为挂起阻塞。不论那种状态，该进程都是不可能被调度而执行的。
2. 处于挂起阻塞状态的进程，其阻塞条件与挂起状态无关；当进程所期待的事件出现后，进程虽不再被阻塞，但仍不能运行，这时，应将该进程从静止阻塞状态转换为挂起就绪状态。
3. 进程可以由其自身挂起，也可由用户或操作系统等将之挂起。其目的都在于组织进程继续进行，被挂起的进程只能用显示方式来激活，以便从挂起状态中解脱出来。

4. 进程互斥与同步

进程互斥定义为：一组并发进程中一个或多个程序段，因为共享某一共有资源而导致必须以一个不允许交叉执行的单位执行。也就是说互斥是保证临界资源在某一时刻只被一个进程访问。

进程同步定义为：把异步环境下的一组并发进程因直接制约而互相发送消息而进行互相合作、互相等待，使得各进程按一定的速度执行的过程称为进程同步。也就是说进程之间时异步执行的，同步即是使各进程按一定的制约顺序和速度执行。

互斥时资源的竞争关系，同步是进程间的协作关系。

一次仅允许一个进程使用的资源称为临界资源。一个进程访问临界资源的那段程序代码称为临界区。由此互斥可以描述为：禁止两个或两个以上的进程同时进入访问同一临界资源的临界区。协调准则如下：

1. 空闲让进。无进程处于临界区时，若有进程要求进入临界区则立即允许其进入；
2. 忙则等待。当已有进程进入临界区时，其他试图进入各自临界区的进程必须等待，以保证各进程互斥的进入临界区；
3. 有限等待。有若干进程要求进入临界区时，应在有限时间内使一进程进入临界区，即它们不应相互等待而谁也不进入临界区；
4. 让权等待。对于等待进入临界区的进程必须释放其占有的CPU。

信号量可以有效的实现进程的同步和互斥。在操作系统中，信号量是一个证书。当信号量大于等于0时，代表可供并发进程使用的资源实体数，当信号量小于0时则表示正在使用临界区的近成熟。建立一个信号量必须说明所建信号量代表的意义和设置初值，以及建立相应的数据结构，以便指向那些等待使用该临界区的进程。

对信号量只能施加特殊的操作：P操作和V操作。P操作和V操作都是不可分割的原子操作，称为原语。因此，P操作和V操作执行期间不允许中断发生。

P(sem)操作的过程是将信号量sem值减1，若sem的值成负数，则调用P操作的进程暂停执行，直到另一个进程对同一信号量作V操作。V(sem)操作的过程是将信号量sem的值加1，若sem的值小于等于0，从相应队列（与sem有关的队列）中选择一个进程，唤醒它。操作的定义如下：

P操作

P(sem) {
    sem = sem - 1;
    if (sem < 0) 进程进入等待状态;
    else 继续执行；
}

V操作

V(sem) {
    sem = sem + 1;
    if (sem <= 0) 唤醒队列中的一个等待进程;
    else 继续执行；
}

设信号量mutex是用于互斥的信号量，初值为1，表示没有并发进程使用该临界区。于是各并发进程的临界区可以改写成下列形式的代码段：

P(mutex);
临界区
V(mutex);

要用P，V操作实现进程同步，需要引进私用信号量。私用信号量只与制约进程和被制约进程有关，而不是与整组并发进程有关。与此相对，进程互斥使用的信号量为公用信号量。首先为各并发进程设置私用信号量，然后为私用信号量赋初值，最后利用P、V原语和私用信号量规定各进程的执行顺序。

5. 前趋图

前趋图是一个由结点和有向边构成的有向无循环图。该图通常用于表现事务之间先后顺序的制约关系。图中的每一个节点可以表示一个语句、一个程序段或是一个进程，节点间的有向边表示两个节点之间存在的前趋关系。

没有前趋节点的称为开始节点，没有后继节点的，称为终止节点。

在前趋图中，执行先后顺序的制约关系可分为两种：直接制约和间接制约。

直接制约通常是指一个操作中，多个步骤之间的制约关系，也可以说是“同步的进程之间的制约关系”。

间接制约通常是指多个操作之间相同步骤的制约关系，也可以说是“互斥的进程之间的制约关系”。

6. 进程调度与死锁

进程调度即处理器调度，又称上下文转换，主要功能是确定在什么时候分配处理器，并确定分配给哪一个进程，即让正在执行的进程改变状态并转入就绪队列的队尾，再由调度原语将就绪队列的队首进程取出，投入执行。

引起进程调度的原因有以下几类：

1. 正在执行的进程执行完毕
2. 执行中的进程自己调用阻塞原语将自己阻塞起来进入睡眠状态。
3. 执行中的进程调用了P原语操作，从而因资源不足而阻塞；或调用V原语操作激活了等待资源的进程队列。
4. 在分时系统中，当一个进程用完了一个时间片。
5. 就绪队列中某进程的优先级变得高于当前执行进程的优先级，也将引起进程调度。

进程调度的方式有两类：剥夺方式和非剥夺方式。非剥夺方式是指：一旦某个作业或进程占用了处理器，别的进程就不能把处理器从这个进程手中夺走，直到该进程自己因调用原语操作而进入阻塞状态，或时间片用完而让出处理机；剥夺方式是指：当就绪队列中有进程的优先级高于当前执行进程的优先级时，便立即发生进程调度，转让处理机。

进程调度算法如下：

1. 先来先服务FCFS调度算法，又称先进先出。就绪队列按先来后到原则排队。
2. 优先数调度。优先数反映进程优先级，就绪队列按优先数排列。有两种确定优先级的方法，即静态优先级和动态优先级。静态优先级是指进程的优先级在进程开始执行前确定，执行过程中不变，而动态优先级则可以在进程执行过程中改变。
3. 轮转法。就绪队列按FCFS方式排队。每个进程执行一次占有处理器时间都不超过规定的时间单位（时间片）若超过，则自动释放自己所占有的CPU而排到就绪队列的队尾，等待下一次调度。同时，进程调度程序又去调度当前就绪队列中的第一个进程。

当若干个进程互相竞争对方已占有的资源，无限期的等待，不能向前推进时会造成“死锁”。

1. 死锁条件。产生死锁的主要原因是供共享的系统资源不足，资源分配策略和进程的推进顺序不当。系统资源既可能时可重复使用的永久性资源，也可能时消耗性的临时资源。产生死锁的必要条件是：互斥条件、保持和等待条件、不剥夺条件和环路等待条件。
2. 解决死锁的策略。处于死锁状态的进程不能继续执行但又占用了系统资源，从而阻碍其他作业的执行。
   解决死锁有两种策略：一种是在死锁发生前采用的预防和避免策略；另一种是在死锁发生后采用的检测和恢复策略。
   死锁的预防主要是通过打破死锁产生的4个必要条件之一来保证不会产生死锁。采用的死锁预防策略通常有资源的静态分配法或有序分配法，他们分别打破了资源动态分配条件和循环等待条件，因此不会发生死锁，但是会大大降低系统资源的利用率和进程之间的并行程度。
   死锁避免策略，则是在系统进行资源分配时，先执行一个死锁避免算法，以保证本次分配不会导致死锁发生。由于资源分配很频繁，所以死锁避免策略要耗费大量的CPU和时间。

2.2.2 存储管理

系统中内存的使用一般分为两部分，一部分为系统空间，存放操作系统本身及相关的系统程序；另一部分为用户空间，存放用户的程序和数据。

存储管理主要是针对内存储器的管理，负责对内存的分配和回收、内存的保护和内存的扩充。目的是尽量提高内存的使用效率。

1. 页式存储管理

分页的基本思想是把程序的逻辑空间和内存的物理空间按照同样的大小划分成若干页面，并以页面为单位进行分配。在页式存储管理中系统中虚地址是一个有序对（页号，位移）。系统为每一个进程建立一个页表，其内容包含进程的逻辑页号于物理页号的对应关系、状态等。

页式系统的动态地址转换方式如下：当进程运行时，其页表的首地址已在系统的动态地址转换机构中的基本地址寄存器中。执行的指令访问虚存地址时，首先根据页号查询页表，若已调入内存，则得到该页的内存位置，然后，同页内位移值组合，得到物理地址。如果该页尚未调入内存，则产生缺页中断，以装入所需的页。

页式虚拟存储管理是在页式存储管理的基础上实现虚拟存储器的。

当装入一个当前需要的页面时，如果内存储器中无空闲块，则可选择一个已在内存储器中的页面，把它暂时调出内存。若在执行中该页被修改过，则把该页信息重新协会到磁盘上，否则不必重新写回磁盘。当一页被暂时调出内存后，让出的内存空间用来存放当前需要使用的页面。页面被调出或装入之后都要对页表中的相应表目作修改。这称之为页面调度。如果页面调度不合理，导致同一内容反复调出调入，称为“抖动”。

常见的页面调度算法有：

1. 最优算法OPT：选择不再使用或者最远的将来才被使用的页，这时理想的算法，但是难以实现，常用于淘汰算法的比较。
2. 随机算法RAND：随机选择被淘汰的页，开销小，但是可能酸中立即就要访问的页。
3. 先进先出算法FIFO
4. 最近最少使用算法LRU

2. 段式存储管理

与页式存储管理相似。分段的基本思想是把用户作业按逻辑意义上有完整意义的段来划分，并以段为单位作为内外存交换的空间尺度。

分段系统中，允许程序（作业）占据内存中许多分离的分区。没个分区存储一个程序分段。分段系统中虚地址是一个有序对（段号，位移）。地址转换方式同页内存储管理方式相似。

3. 段页式存储管理

是段式和页式两种管理方法的结合。根据程序模块分段，段内再分页，内存被划分成定长的页。虚地址形式为（段号、页号、页内位移）。

段页式虚拟存储管理结合了段式和页式的优点，但增加了设置表格（段表、页表）和查表等开销，段页式虚拟存储器一般只在大型计算机系统中使用。

2.2.3 设备管理

1. 数据传输控制方式

主要任务之一是控制设备和内存或CPU之间的数据传送。选择和衡量控制方式的原则如下：

1. 数据传送速度足够高，能满足用户的需要但又不丢失数据。
2. 系统开销小，所需的处理控制程序少。
3. 能充分发挥硬件资源的能力，使得I/O设备尽量处于使用状态中，而CPU等待时间少。

常用的数据传送方式主要有如下几种：

1. 程序控制方式。处理器启动数据传输，然后等设备完成。
2. 中断方式。程序控制方式不能实现并发。中断方式的数据传输过程为，进程启动数据传输（如读）后，该进程放弃处理器，当数据传输完成，设备控制器产生中断请求，中断处理程序对数据传输工作处理之后，让相应进程成为就绪状态。以后，该进程得到所需要的数据。
3. 直接存储访问方式DMA。指外部设备和内存之间开辟直接的数据交换通路。除了控制状态寄存器和数据缓冲寄存器外，DMA控制器中还包括传输字节计数器、内存地址计数器等。
4. 通道方式。又称为输入/输出处理器IOP，可以独立完成系统交付的输入/输出任务，通过执行自身的输入/输出专用程序（称通道程序）进行内存和外设之间的数据传输，主要有3种通道：字节多路通道、选择通道和成组多路通道。

2. 虚设备与SPOOLING技术

采用假脱机技术，可以将低速的独占设备改造成一种可独占的设备，而且一台物理设备可以对应若干台虚拟的同类设备。假脱机（SPOOLING）的意思是外部设备同时联机操作，又称为假脱机输入/输出操作，采用一组程序或进程模拟一台输入/输出设备。

SPOOLING技术必须有高速、大容量并且可随机存取的外存（如磁盘或磁鼓）支持。例如现在电脑中的多窗口技术。

2.2.4 文件管理

操作系统对计算机的管理包括两个方面：硬件资源和软件资源。硬件资源的管理包括CPU的管理、存储器的管理、设备管理等。主要解决硬件资源的有效和合理利用问题。

软件资源包括各种系统程序、各种应用程序、各种用户程序，也包括大量的文档材料、库函数等。每一种软件资源本身都是具有一定逻辑意义的相关信息的集合，在操作系统中它们以文件形式存储。

文件系统是操作系统中组织、存取和保护数据的一个重要部分。

文件管理的功能包括：建立、修改、删除文件；按文件名访问文件；决定文件信息存放的位置、存放形式及存放权限；管理文件件的联系及提供对文档的共享、保护、保密等。允许多个用户协同工作又不引起混乱。文件的共享是指一个文件可以让多个用户共同使用，他可以减少用户的重复性劳动，节省文件的存储空间，减少输入/输出文件的次数等。文件的保护主要是为防止由于错误操作而对文件造成的破坏。文件的保密是为了防止未经授权的用户对文件进行访问。

文档的保护、保密实际上是用户对文件的存取权限控制问题。一般为文件的存取设置两级控制：第1级是访问者的识别，即规定哪些人可以访问；第2级是存取权限的识别，即有权参与访问者可对文件执行何种操作。

1. 文件的逻辑结构

指文件的组织形式。一般可分文两种：无结构的字符流文件和有结构的记录文件。记录文件由记录组成，即文件内的信息划分成多个记录，以记录为单位组织和使用信息。

记录文件有顺序文件、索引顺序文件、索引文件和直接文件。

1. 顺序文件。大多数文件是顺序文件。顺序文件的记录定长，记录中的数据项和类型长度与次序固定，一般还有一个可以唯一标识记录的数据项，称为键（Key），记录是按键值的约定次序组织的。常用于批处理应用，用于查询或更新某个记录的处理性能不太好。
2. 索引顺序文件。是基于键的约定次序组织的，而且维护键的索引和溢出区域。键的索引也可以是多级索引。索引顺序文件既适用于交互方式应用，也适用于批处理方式应用。
3. 索引文件。是基于记录的一个键数据项组织的。许多应用需按照别的数据项访问文件，为此，常采用索引文件方法，即对主文件中的记录按需要的数据项（一个或几个）建索引，索引文件本身是顺序文件组织。
4. 直接文件。又称哈希（Hash）文件。记录以他们在直接访问存储设备上的物理地址直接（随机的）访问。常用于需要高速访问文件而且每次仅访问一条记录的应用中。

2. 文件的物理结构

指的是文件在存储设备上的存储方法。文件的存储设备通常划分为大小相同的物理块，物理块是分配和传输信息的基本单位。文件的物理结构涉及文件存储设备的组块策略和文件分配策略，决定文件信息在存储设备上的存储位置。常用的文件分配策略有：

1. 顺序分配（连续分配）。最简单的分配方法。在文件建立时预先分配一组连续的物理块，然后，按照逻辑文件中的信息（或记录）顺序，依次把信息（或记录）按顺序存储到物理块中。这样，只需知道文件在文件存储设备上的起始位置和文件长度，就能进行存取。这种分配方式适合于顺序存取，在连续存取相邻信息时，存取速度快。其缺点是在文件建立时必须指定文件的信息长度，以后不能动态增长，一般不宜用于需要经常修改的文件。
2. 链接分配（串联分配）。这是按单个物理块逐个进行的。每个物理块中（一般是最后一个单元）设有一个指针，指向其后续链接的下一个物理块的地址，这样，所有的物理块都被链接起来，形成一个链接队列。在建立链接文件时，不需要指定文件的长度，在文件的说明信息中，只需支出该文件的第一个物理块块号，而且链接文件的文件长度可以动态的增长。只需调整物理块间的指针就可以插入或删除一个信息块。
   链接分配的优点是可以解决存储器的碎片问题，提高存储空间利用率。由于链接文件只能按照队列中的链接指针顺序查找，因此搜索效率低，一般只适用于顺序访问，不适用于随机存储。
3. 索引分配。是另外一种对文件存储不连续分配的方法。采用索引分配方法的系统，为每一个文件建立一张索引表，索引中的每一项指出文件信息所在的逻辑块号和与之对应的物理块号。
   索引分配既能满足文件动态增长的要求，又可以方便而迅速的实现随机存取。对一些大的文件，当索引表的大小超过一个物理块时，会发生索引表的分配问题。一般采用多级（间接索引）技术，这时在由索引表指出的物理块中存放的不是文件存放处，而是文件存放信息的物理块地址。这样，如果一个物理块能存放$n$个地址，则一级间接索引将使可寻址的文件长度变成$n^2$块，对于更大的文件可以采用二级甚至三级是间接索引（UNIX系统使用三级索引结构）。
   索引文件的优点是既适用于顺序存储，又适用于随机存储，缺点是索引表增加了存储空间的开销。另外，在存取文件时需要访问两次磁盘，一次是访问索引表，一次是根据索引表提供的物理块号访问文件信息。为了提高效率，一种改进的方法是，在对某个文件进行操作之前，预先把索引表调入内存。这样文件的存取就能直接从内存的索引表中确定相应的物理块号，从而只需要访问一次磁盘。

3. 文件存储设备管理

文件存储设备的管理实质上是对空闲块的组织和管理问题。它包括空闲块的组织，空闲块的分配与空闲块的回收等问题，空闲块管理方法如下：

1. 索引法。把空闲块作为文件并采用索引技术。为了有效，索引对应一个或由几个空闲块组成的空闲区。这样，磁盘上的每一个空闲块区都对应索引表中的一个条目，这个方法能有效的支持每一种文件分配方法。
2. 链接法。使用链表把空闲块组织在一起，当申请者需要空闲块时，分配程序从链首开始摘取所需的空闲块。反之，管理程序把回收的空闲块逐个挂入队尾，这个方法适用于每一种文件分配方法。空闲块的链接方法可以按释放的先后顺序链接，也可以按空闲块区的大小顺序链接。后者有利于获得连续的空闲块的请求，但在分配请求和回收空闲块时系统开销多一点。
3. 位示图法。该方法是在外存上建立一个位示图，记录文件存储器的使用情况。每一位仅对应文件存储器上的一个物理块，取值0和1分别表示空闲和占用。
   位图是利用二进制的一位来表示磁盘中的一个盘块的使用情况。当其值为0时，表示对应的盘块空闲；当为1时，表示已分配。

4. 树形目录结构

在树形目录结构中，树的根节点为根目录，数据文件作为树叶，其他所有目录均作为树的结点。

根目录隐含在磁盘的一个分区中，根目录在最顶层，它包含的子目录是一级子目录，每一个一级子目录又可以包含二级子目录等，这样的目录结构称为目录树。

当前盘和当前目录是系统默认的操作对象。如果用户没有指明操作对象，那么系统就将用户命令指向当前盘和当前目录。

路径是指从根目录或者当前目录开始到访问对象（目录或文件），在目录树中路径的所有目录的序列。在树形目录结构中，从根目录到任何数据文件之间，只有一条唯一的通路，从树根开始，把全部目录文件名与数据文件名，依次用“/”（UNIX/Linux系统）或“\”（Windows系统）连接起来，构成该数据文件的路径名，且每个数据文件的路径名是唯一的。

从树根开始的路径为绝对路径。从当前目录开始，在逐级通过中间的目录文件，最后到达所要访问的数据文件。

绝对路径给出文件或目录位置的完全描述，通常由层级结构的顶端开始（根目录），通常第一个字符是“/”（UNIX/Linux系统）或盘符（Windows系统）。相对路径通常是由目录结构中的当前位置开始，一般都比绝对路径要短。

父目录是指当前路径的上一层目录。每个目录都有代表当前目录的“.”文件和代表当前目录父目录的“..”文件，相对路径名一般就是从“..”开始的。

2.2.5 作业管理

从用户的角度看，作业是系统为完成一个用户的计算任务（或一次事务处理）所做的工作总和。过程中的每一个步骤，成为作业步，作业步的顺序执行即完成了一个作业。

从系统的角度看，作业则是一个比程序更广的概念。它由程序、数据和作业说明书组成。系统通过作业说明书控制文件形式的程序和数据，使之执行和操作。而且，在批处理系统中，作业是占据内存的基本单位。

用户的作业可以通过直接的方式，由用户自己按照作业步骤顺序操作；也可以通过间接的方式，由用户率先编写的作业步依次执行的说明，一次交给操作系统，由系统按照说明依次处理。前者称为联机方式，后者称为脱机方式。

1. 作业状态及其转换

一个作业从交给计算机系统到执行结束退出系统，一般都要经历提交、后后备、执行和完成四个状态。

1. 提交状态。作业由输入设备进入外存储器（也称输入井）的过程称为提交状态。处于提交状态的作业，其信息正在进入系统。
2. 后备状态。当作业的全部信息进入外存后，系统就为该作业建立一个作业控制块JCB。系统通过JCB感知作业的存在。JCB主要内容包括作业名、作业状态、资源要求、作业控制方式、作业类型及作业优先权等。
3. 执行状态。一个后备状态被作业调度程序选中二分配了必要的资源并进入了内存。作业调度程序同时为其建造了相应的进程后，该作业就由后备状态变成了执行状态。
4. 完成状态。当作业正常运行结束，它所占用的资源尚未完全被系统回收时的状态为完成状态。

2. 用户接口

也称用户界面，其含义有两种，一种是指用户与操作系统交互的途径和通道，即操作系统的接口；另一种是指这种交互环境的控制方式，即操作环境。

1. 操作系统的接口。操作系统的接口又可分成命令接口和程序接口。命令接口包含键盘命令和作业控制命令；程序接口又称编程接口或系统调用，程序经编程接口请求系统服务，即通过系统调用程序与操作系统通信，系统调用是操作系统提供给编程人员的唯一接口。系统调用对用户屏蔽了操作系统的具体动作而只提供有关功能。系统调用大致分为设备管理、文件管理、进程控制、进程通信和存储管理等。
2. 操作环境。操作环境支持命令接口和程序接口，提供友好的、易用的操作平台。操作系统的交互界面已经从操起的命令驱动方式，发展到菜单驱动方式、图形驱动方式和视窗操作环境。

第三章 数据库系统

3.1 数据库管理系统的类型

通常有多个分类标准。如按数据模型分类、按用户数分类、按数据库分布站点分类等。我们需要了解的是按数据模型分类。

当前，主流数据模型为关系数据模型。常见的DBMS按数据模型划分，包括：关系型DBMS、文档型DBMS、键值型DBMS、对象型DBMS等。

3.2 数据库模式与范式

3.2.1 数据库的接口与模式

1. 三级抽象

数据库系统划分为三个抽象级：用户级、概念级、物理级。

1. 用户级数据库。对应于外模式，是最接近用户的一级数据库，是用户可以看得到和使用的数据库，又称用户视图。主要由外部记录组成，不同的用户视图可以互相重叠，用户的所有操作都是针对用户视图进行的。
2. 概念级数据库。对应于概念模式。介于用户级和物理级之间，是所有用户视图的最小并集，是数据库管理员可以看到和是哟经的数据库，又称DBA视图。由概念记录组成，一个数据库可以有不同的用户视图，每个用户视图由数据库某一部分的抽象表示所组成，一个是数据库应用系统只存在一个DBA视图，他把数据库作为一个整体的抽象表示，概念机模式把用户视图有机结合成一个整体，综合平衡考虑所有用户要求，实现数据的一致性，最大限度降低数据冗余，准确的反映数据间的联系。
3. 物理级数据库。对应于内模式，是数据库的低层表示，描述数据的实际存储组织，是最接近物理存储的级，又称内部视图。物理级数据库由内部记录组成，物理级数据库并不是真正的物理存储，而是最接近于物理存储的级。

2. 三级模式

三级模式为内模式、概念模式、内模式。

1. 概念模式。（模式、逻辑模式）用以描述整个数据库中数据库的逻辑结构，描述现实世界中的实体及其性质和联系，定义记录、数据项、数据的完整性约束条件及记录之间的联系，是数据项值的框架。
   数据库系统概念模式通常还包含有访问控制、保密定义、完整性检查等方面的内容，以及概念/物理之间的映射。
   概念模式是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图，一个数据库只有一个概念模式。
   外模式是数据库用户（包括程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用 有关的数据库的逻辑表示，一个数据库可以有多个外模式，一个应用程序只能使用一个外模式。
2. 外模式。（子模式、用户模式）用以描述用户看到或使用的那部分数据的逻辑结构，用户根据外模式用数据操作语句或应用程序去操作数据库中的数据。外模式主要描述组成用户视图的各个记录的组成、相互关系、数据项的特征、数据的安全性和完整性约束条件。
3. 内模式。内模式是整个数据库的最低层表示，不同于物理层。它假设外存是一个无限的线性地址空间。内模式定义的是存储记录的类型、存储域的表示以及存储记录的物理顺序，指引元、索引和存储路径等数据的存储组织。
   内模式是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式，一个数据库只有一个内模式。

内模式、模式和外模式之间的关系如下：

1. 模式是数据库的中心与关键；
2. 内模式依赖于模式，独立于外模式和存储设备。
3. 外模式面向具体的应用，独立于内模式和存储设备。
4. 应用程序依赖于外模式，独立于模式和内模式。

两级独立性

指数据库独立性和逻辑独立性。三个抽象级间通过两级映射（外模式——模式映射，模式——内模式映射）进行相互转换，值得数据库的三级形成一个统一的整体。

1. 物理独立性。是指用户的应用程序与存储在磁盘上的数据库中的数据是相互独立的。当数据的物理存储改变时，应用程序不需要改变。
   物理独立性存在于概念模式和内模式之间的映射转换，说明物理组织发生变化时应用程序的独立程度。
2. 逻辑独立性。是指用户的应用程序与数据库中的逻辑结构是相互独立的。当数据库的逻辑结构改变时，应用程序不需要改变。
   逻辑独立性存在于外模式和概念模式之间的映射转换，说明概念模式发生变化时应用程序的独立程度。

逻辑独立性要比物理独立性更难实现。

3.2.2 数据模型

主要有两大类，分别是概念数据模型（实体-联系模型）和基本数据模型（结构数据模型）

概念数据模型是按照用户的观点来对数据和信息建模，主要用于数据库设计。概念模型主要用实体——联系方法表示，所以也称E-R模型。

基本数据模型是按照计算机系统的观点来对数据和信息建模，主要用于DBMS的实现。基本数据模型是数据库系统的核心和基础。基本数据模型通常由数据结构、数据操作和完整性约束三部分组成。其中数据结构是对系统静态特性的描述，数据操作是对系统动态特性的描述，完整性约束是一组完整性规则的集合。

常用的基本数据模型有层级模型、网状模型、关系模型和面向对象模型。

层次模型用树形结构表示实体类型及实体间的联系。层次模型的优点是记录之间的联系通过指针来实现，查询效率较高。层次模型的缺点是只能表示1:n联系，虽然有多种辅助手段实现m:n联系，但比较复杂，用户不易掌握。由于层次顺序的严格和复杂，导致数据的查询和更新操作很复杂，应用程序的编写也比较复杂。

网状模型是用有向图表示实体类型和实体间的联系。网状模型的优点是记录之间的联系通过指针实现，m:n联系也容易实现，查询效率高。其缺点是编写应用程序的过程比较复杂，程序变必须数据数据库的逻辑结构。

关系模型用表格结构表达实体集，用外键表示实体间的联系。其优点有：

1. 建立在严格的数学概念基础上；
2. 概念（关系）单一，结构简单清晰，用户易懂易用；
3. 存取路径对用户透明，从而数据独立性、安全性好，简化数据库开发工作

3.2.3 关系代数

关系代数的基本运算主要有并、交、差、笛卡尔积、选择、投影、连接和除法运算。

1. 并。计算两个关系在集合理论上的并集，即给出关系$R$和$S$（两者有相同元/列数），$R\cup S$的元组包括$R$和$S$所有元组的集合，形式定义如下（也就是数据库中的union）：
   $$R\cup S\equiv \{t|t\in R\lor t\in S\}$$
   式中$t$是元组变量（下同）。显然$R\cup S=S\cup R$。
2. 差。计算两个关系的区别的集合。即给出关系$R$和$S$（两者有相同元/列数），$R-S$的元组包括$R$中有而$S$中没有的元组的集合，形式定义如下（也就是数据库中的not exists）：
   $$R-S\equiv \{t|t\in R\land t\notin S\}$$
3. 交。计算两个关系集合理论上的交集，即给出$R$和$S$（两者有相同元/列数），$R\cap S$的元组包括$R$和$S$相同元组的集合，形式定义如下（也就是数据库中的inner join）：
   $$R\cap S\equiv \{t|t\in R\land t\in S\}$$
   显然，$R\cap S=R-(R-S)$和$R\cap S=S-(S-R)$成立。
4. 笛卡尔积。计算两个关系的笛卡尔乘积，令$R$为有$m$元的关系，$S$为有$n$元的关系，则$R\times S$是$m+n$元的元组的集合，其前$m$个元素来自$R$的一个元组，而后$n$个元素来自于$S$的一个元组。形成定义如下：
   $$R\times S\equiv \{t|t\le t_r,t_s>\land t_r\in R\land t_s\in S\}$$
   若$R$有$u$个元组，$S$有$v$个元组，则$R\times S$有$u\times v$个元组。
5. 投影。从一个关系中抽取指明的属性（列）。令$R$为一个包含属性$A$的关系，则：
   $$\pi_A(R)\equiv \{t[A]|t\in R\}$$
6. 选择。从关系$R$中抽取满足给定限制条件的记录，记作：
   $$\sigma_F(R)\equiv \{t|t\in R\land F(t)=true\}$$
   其中F表示选择条件，是一个逻辑表达式（逻辑运算符+算数运算符）。选择运算是从元组（行）的角度进行的运算。
7. $\theta$连接，$\theta$从两个关系的笛卡尔积中选取属性之间满足一定条件的元组。如果两个关系中进行比较的分量必须是相同的属性组，并且在结果中将重复的属性去掉，则成为自然连接。
8. 除。

3.2.4 数据的规范化

关系模型满足的确定约束条件为范式，根据满足约束条件的级别不同，范式由低到高分为1NF（第一范式）、2NF（第二范式）、3NF（第三范式）、BCNF（BC范式）、4NF（第四范式）等。不同级别范式性质不同。

把一个低一级的关系模型分解为高一级关系模型的过程，称为关系模型的规范化。关系模型分解必须遵守两个准则。

1. 无损连接性：信息不失真（不增减信息）。
2. 函数依赖保持性：不破坏属性间存在的依赖关系。

规范化的基本思想是逐步消除不合适的函数依赖，使数据库中的各个关系模型达到某种程度的分离。规范化解决的主要是单个实体的质量问题，是对于问题域中原始数据展现的正规化处理。

规范化理论给出了判断关系模型优劣的理论标准，帮助预测模型可能出现的问题，是数据库逻辑设计的指南和工具。具体有：

1. 用数据依赖的概念分析和表示各数据项之间的关系。
2. 消除E-R图中的冗余联系。

1. 函数依赖

就像是自变量x确定以后，相应的函数值f(x)也就唯一确定了一样，函数依赖就是衡量和调整数据规范化的最基础的理论依据。

关系$R<U$，$F>$中的一个属性或一组属性$K$，如果给定给一个$K$则唯一确定$U$中的一个元组，也就是$U$函数完全依赖于$K$，就称$K$为$R$的码。一个关系可能有多个码，选中其中一个作为主码。

包含在任一码中的属性称为主属性，不包含在任何码中的属性称为非主属性。

关系R中的属性或属性组X不是R的码，但X是另外一个关系模型的码，称X是R的外码。

主码和外码就是数据库中的主键和外键。

2. 第一范式

1NF是最低的规范化要求。如果关系R中所有属性的值域都是简单域，其元素（即属性）不可再分，是属性项而不是属性组，那么关系模型R是第一范式的，记作$R\in 1NF$。

这一限制是关系的基本性质，所以任何关系都必须满足第一范式。第一范式是实际数据库涉及中必须先达到的，通常称为数据元素的结构化。

满足第一范式的关系模型会有许多重复值，并且增加了修改其数据时引起疏漏的可能性。为了消除这种数据冗余和避免更新数据的遗漏，需要更加规范的2NF。

3. 第二范式

如果一个关系R属于1NF，且所有的非主属性都完全依赖于主属性，则称之为第二范式，记作$R\in 2NF$。

4. 第三范式

如果一个关系R属于2NF，且每个非主属性不传递依赖于主属性，这种关系是3NF，记作$R\in 3NF$。

5. BC范式

一般满足3NF的关系模型已经消除冗余和各种异常现象，获得比较满意的结果，但无论是2NF还是3NF都没有涉及主属性间的函数依赖，所以有时仍会引起一些问题。由此引入BC范式。通常认为是第三范式的改进。

定义：如果关系模型$R\in 1NF$，且R中的每一个函数依赖关系中的决定因素都包含码，则R是满足BC范式的关系，记作$R\in BCNF$。

当一个关系模型$R\in BCNF$，则在函数依赖范畴内，救认为已彻底实现了分离，消除了插入、删除的异常。

结合1NF、2NF和3NF、BCNF的内涵可概括如下：

1. 非主属性完全函数依赖于码（2NF的要求）。
2. 非主属性不传递依赖于任何一个候选码（3NF的要求）。
3. 主属性对不包含他的码完全函数依赖（BCNF的要求）。
4. 没有属性完全函数依赖于一组非主属性（BCNF的要求）。

3.2.5 反规范化

数据库中的数据规范化的优点是减少了数据冗余，节约了存储空间，相应逻辑和物理的I/O次数减少，同时加快了增删改查的速度，但是对完全规范的数据库查询，通常需要更多的连接操作，从而影响查询速度。因此，有时为了提高某些查询或应用的性能而破坏规范规则，即反规范化（非规范化处理）。常见的反规范化技术包括：

1. 增加冗余列
   指多个表中具有相同的列，它常用来在查询时避免连接操作。
2. 增加派生列
   指增加的列可以通过表中其他数据计算生成，它的作用是在查询时减少计算量，从而加快查询速度。
3. 重新组表
   指如果许多用户需要查看两个表连接起来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。
4. 分割表
   水平分割：根据一列或多列数据的值把数据航放到两个独立的表中。水平分割通常在如下的情况下使用。
   
   • 表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低索引的层数，提高查询效率。
   • 表中的数据本来就有独立性。
   • 需要把数据存放到多个介质上。
     垂直分割：把主码和一些列放到一个表，然后把主码和另外的列放到另一个表中。如果一个表中某些列常用，而另外一些列不常用，则可以采用垂直分割。另外垂直分割可以使得数据行变小，一个数据页就能存放更多的数据，在查询时就会减少I/O次数。其缺点是需要管理冗余列，查询所有数据需要连接操作。

3.3 数据库设计

数据库设计的过程是将数据库系统与现实世界密切的、有机的、协调一致的结合起来的过程。数据库的设计质量与设计者的知识、经验和水平密切相关。

以数据库为基础的数据库应用系统与其他计算机应用系统相比往往具有数据量庞大、数据保存时间长、数据关联复杂、用户要求多样化等特点。

数据库设计中面临的主要困难和问题有：

1. 同时具备数据库知识和应用知识的人很少。懂得计算机与数据库的人一般都缺乏应用知识和实际经验，而熟悉应用业务的人又往往不懂计算机和数据库。
2. 项目初期往往不能确定应用业务的数据库系统的目标。
3. 缺乏完善的设计工具和设计方法。
4. 需求的不确定性。用户总是在系统的开发过程中不断提出新的要求，甚至在数据库建立之后还会要求修改数据库结构或增加新的应用。
5. 应用业务系统千差万别，很难找到一种适合所有业务的工具和方法，这就增加了数据库自动生成工具的难度。因此，研制适合一切应用业务的全自动数据库生成工具是不可能的。

3.3.1 数据库设计的方法

目前已有的数据库设计方法可分为四类，即直观设计法、规范设计法、计算机辅助设计法和自动化设计法。直观设计法又称单步逻辑设计法，它依赖于设计者的知识、经验和技巧，缺乏工程规范的支持和科学依据，设计质量也不稳定，因此越来越不适应信息管理系统发展的需求。因此，将数据库设计规范分为需求分析、概念结构分析、逻辑结构设计和物理结构设计4个阶段。

基于3NF的数据库设计方法基本思想是在需求分析的基础上，识别并确认数据库模式中的全部属性和属性间的依赖，将它们组织成一个单一的关系模型，然后再分析模式中不符合3NF的约束条件，用投影和连接的办法将其分解，使其达到3NF条件。

1. 设计企业模式。利用上述得到的3NF关系模型画出企业模式。具体包括：
   
   • 分析应用环境，并设定环境中所使用的各种资料。
   • 确定每一种报表各自所包含的数据元素。
   • 确定数据元素之间的关系，如确定主关键字和一般的数据元素。
   • 对每一组或若干组数据元素推导出3NF的关系模型。
   • 在3NF关系模型的基础上画出数据库的企业模式。
2. 设计数据库逻辑模式。根据上一步得到的企业模式选定数据模型，从而得出适用于某种DBMS的逻辑模式。根据逻辑模式导出各种报表与事务处理所使用的外模式。
3. 设计数据库物理模式（存储模式）。根据数据库的逻辑模式和给定的计算机系统设计物理模式。
4. 评价物理模式。对物理模式估算空间使用情况，并推算输入输出的概率。必要时根据物理模式调整各种报表和事务处理的外模式。对外模式进行存取时间的估算。
5. 数据库实现。具体实现数据库。

3.3.2 数据库设计的基本步骤

分步设计法遵循自顶向下、逐步求精的原则，将数据库设计过程分解为若干相互独立又相互依存的阶段，每一阶段采用不同的技术与工具，解决不同的问题，从而将问题局部化，减少了局部问题对整体设计的影响。

在分步设计法中，通常将数据库的设计分为需求分析、概念结构设计、逻辑结构设计和数据库物理设计4个阶段。

1. 需求分析

指收集和分析用户对系统的信息需求和处理需求，得到设计系统所必需的需求信息，建立系统说明文档。其目标是通过检查研究，了解用户的数据要求和处理要求，并按一定格式整理成需求说明书。需求说明书是需求分析阶段的成果，也是今后设计依据，它包括数据库所涉及的数据、数据的特征、使用的频率和数据量的估计。这些关于数据的数据称为元数据。在设计大型数据库时，这些数据通常由数据字典来管理。

2. 概念结构设计

是数据库设计的第二阶段，目标是对需求说明书提供的所有数据和处理要求进行抽象和综合处理，按一定的方法构造反映用户环境的数据及其相互联系的概念模型，即用户的数据模型或企业数据模型。这个数据模型与DBMS无关。

3. 逻辑结构设计

设计目标是把上一阶段得到的与DBMS无关的概念数据模型转换成等价的，并为某个特定的DBMS所接受的逻辑模型所表示的概念模式，同时将概念设计阶段得到的应用视图转换成外部模式，即特定DBMS下的应用视图。该阶段的结果是DDL脚本。

4. 数据库物理设计

把逻辑设计阶段得到的满足用户需求的已确定的逻辑模型在物理上加以实现，主要内容是根据DBMS提供的各种手段，设计数据库的存储形式和存取路径，即设计数据库的内模式或存储模式。

数据库设计的基本过程和任何复杂系统开发一样，在每一阶段设计基本完成后，都要进行认真的检查，看是否满足应用需求，是否符合前面已执行步骤的要求和满足后续步骤的需要，并分析设计结果的合理性。在每一步设计中，都可能发现前面步骤的遗漏或处理不当之处，此时，往往需要返回去重新处理并修改设计和有关文档。所以，数据库设计过程通常是一个反复修改，反复设计的的迭代过程。

3.3.3 需求分析

需求分析是数据库设计过程中的第一步，是整个数据库设计的依据和基础。目标是通过对单位的信息需求和处理要求的调查分析得到设计数据库所需的数据集及其相互联系，形成需求说明书，作为后面各设计阶段的基础。因此，这一阶段的任务是：

1. 确认需求、确认设计目标

2. 分析和收集数据

3. 整理文档

3.3.4 概念结构设计

该阶段所涉及的信息不依赖于任何实际实现时的环境，即计算机的硬件和软件系统。目标是产生一个用户易于理解的，反应系统信息需求的整体数据库概念结构。任务是，在需求分析中产生的需求说明书的基础上按照一定的方法抽象成满足应用需求的用户的信息结构，即通常所称的概念模型。概念结构的设计过程就是正确选择设计策略、设计方法和概念数据模型并加以实施的过程。

作用是：提供能够识别和理解系统要求的框架；为数据库提供一个说明性结构，作为设计数据库逻辑结构，即逻辑模型的基础。

设计策略主要有自底向上、自顶向下、由里向外和混合策略。在具体实现设计目标时有两种极端的策略或方案，一是建立一个覆盖整个单位所有功能域的全局数据库，称之为全局方案或全局策略；另一种则是对每一个应用都建立一个单独的数据库，称为应用方案或应用策略。

1. 视图设计

在视图分析法中，局部视图设计的第一步是确定其所属的范围，即它所对应的用户组，然后对每个用户组建立一个仅由实体、联系及他们的标识码组成的局部信息结构（局部数据模式）框架，最后再加入有关的描述信息，形成完整的局部视图（局部数据模式）。这样做的目的是为了集中精力处理好用户数据需求的主要方面，避免因无关紧要的描述细节而影响局部信息结构的正确性。整个过程可分为4个步骤：确定局部视图的范围；识别实体及其标识；确定实体间的联系；分配实体及联系的属性。

1. 确定局部视图的范围。
   需求说明书中标明的用户视图范围可以作为确定局部视图范围的基本依据，但它通常与子模式范围相对应。范围确定的基本原则是：
   
   • 各种局部视图支持的功能域之间的联系应最少。
   • 实体个数适量。一个局部视图所包含的实体数量反映了该局部视图的复杂性，按照信息论中“$7\pm2$”的观点，人们在同一时刻可同时顾及的事情一般在5~9个之间，其中以6或7最为适当。因此，一个局部视图内的实体数不宜超过9个。
2. 识别实体及其标识。
   任务是在确定的局部视图范围内，识别哪些数据对象作为局部视图的基本试题及其标识，并定义有关数据对象在E-R模型中的地位。
3. 确定实体间的联系。
   定义联系就是对联系语义的仔细分析，识别联系的类型，确定实体在联系中的参与度。
   1) 二元联系的类型与定义。二元联系是指两个实体类之间的联系。根据参与联系的两个实体类值之间的对应关系分为一对一、一对多即多对多三种类型。
   
   • 一对一联系。
   • 一对多联系。
   • 多对多联系
   • 实体内部的联系
     2) 多元联系的识别与定义。两个以上的实体类之间的联系称为多元联系。

2. 视图集成

就是要将反映各用户组数据的局部数据模式综合成单位中某个确定范围内的单一数据视图，即全局数据模式，又称模式汇总。当所有局部视图设计完毕，就可开始试图集成，集成过程中会发生一些冲突，冲突的表现和处理策略如下：

1. 同名异义。为了发现不同视图间的同名异义问题，可以列出所有同名数据对象，然后逐一辨别其语义。对同名异义冲突通常采用换名加以解决，即可对同名者之一换名，也可对两者都给以重新命名。识别语义的主要方法是进行值域分析。
2. 异名同义。识别异名同义比较困难，一般由设计者对所有对象一个不漏的逐一鉴别。它同样采用换名的方法解决。若归并时试图将它们合并为一个对象，则可以把其中之一的名称作为合并后的对象名；若集成后，他们仍以两个不同的对象存在，则可对其一换名。当然，若原名都不合适，则可对两者都重新命名。
3. 同名不同层次。如果两个对象同名，但其中之一作为一个视图中的实体，而另一个是另一视图中的属性，则在集成时会发生同名不同层次的冲突。解决这种冲突的办法有两个，一是将属性转换为实体，二是将实体变换成属性。
   

   实体变换为属性时通常需要满足一些特定条件，例如，该实体工厂只含有一个与同名属性具有共同特征的属性，且一定存在一个与该实体存在联系的另外的实体。

4. 虽同名同义，但对象联系测度不同。所谓联系测度是指实体联系是一对一、一对多还是多对多。若同名同义对象在一个局部视图中为一对多联系，在另一局部视图中为多对多联系，则在集成时会发生联系测度冲突。一般而言，一对多包含一堆一，多对多包含一对多。所以解决这种冲突的办法往往取较高测度为集成后的相应联系的测度。

3.3.5 逻辑结构设计

1. 将概念结构向一般关系模型转化。
2. 将第一步得到的结构向特定的DBMS支持下的数据模型转换。
3. 根据应用的需求和具体的DBMS的特征进行调整和完善。

1. 基本E-R模型向关系模型的转换

基本E-R模型主要包含实体和联系两个抽象概念，实体和联系本身还可能附有若干属性，其转换的基本原则是，实体和联系分别转换成关系，属性这转换成相应关系的属性。

1. 一对一联系
2. 一对多联系
3. 多堆垛联系。由两个实体类之间多对多联系组成的E-R模型向关系模型转换时，将两个实体类和一个联系类分别转换成关系，实体类的属性分别转换成对应关系的属性，其标识属性转换为其关键字，由联系类转换得到的关系的属性有两个实体类的标识属性和联系类本身的属性组成，其关键字是有两个联系的实体类的标识属性组成。
4. 多元联系。实体类分别转换为相应的关系，三个实体类间的多元联系转换为以该联系名为关系名的关系，关系的属性由各实体的标识属性及其联系的属性组成，并以各实体的标识属性为其关键字。
5. 自联系。是同一实体集的不同实体间的联系。
6. 弱实体类的转换。一个实体类，如果它的存在依赖于另一个实体类，则称之为弱实体类。

2. 数据模型的优化

优化的内容是改善数据库的性能和节省存储空间两个方面。

1. 改善数据库性能的考虑。
   1) 减少连接运算。连接运算对关系数据库的查询速度有着重要的影响，连接的关系越多，参与连接的关系越大，开销也越大，因而查询速度也越慢。对于一些常用的、性能要求较高的数据库查询，最好是一元查询，称为逆规范化。
   2) 减少关系大小及数据量。被查询的关系大小对查询速度影响较大。为了提高查询速度，可以采用水平分割或垂直分割等方法把一个关系分成几个关系，使每个关系的数据量减少。
   3) 尽量使用快照。快照是某个用户所关心的那部分数据，与视图一样是一种导出关系，但它与视图有两点不同：一是视图是虚关系，数据库中并不存储作为视图的导出关系，仅仅保留它的定义，快照则是一个由系统事先生成后保留在数据库中的实关系；二是视图随数据当前值的变化而变化，快照则不随原来关系中数据的改变而及时改变。它只反映数据库中某一时刻的状态，不反应数据库的当前状态。快照不是一成不变的，它可以由系统周期性的刷新，或由用户用命令刷新。
2. 节省存储空间的一些考虑。
   1) 缩小每个属性占用的空间。两种方法：用编码和用缩写符号表示属性。
   2) 采用假属性。可以减少重复数据占用的存储空间。

3.3.6 物理结构设计

数据库在实际的物理设备上的存储结构和存取方法称为数据库的物理结构。数据库物理设计是利用已确定的逻辑结构及DBMS提供的方法、技术，以较优的存储结构、数据存取路径、合理的数据存储位置及存储分配，设计出一个高效的、可实现的物理数据库结构。数据库的物理设计完全依赖于给定的硬件环境和数据库产品。

为设计出一个较好的存储模式，设计者必须了解一下几个方面的问题，做到心中有数。

1. 了解并熟悉应用要求，包括各个用户对应的数据视图，即数据库的外模式（子模式），分清哪些是主要的应用，了解各个应用的使用方式、数据量和处理频率等，以便对时间和空间进行平衡，并保证优先满足应用的时间要求。
2. 熟悉使用的DBMS的性能，包括DBMS的功能，提供的物理环境、存储结果、存取方法和可利用的工具。
3. 了解存放数据的外存设备的特性，如物理存储区域的划分原则，物理块的大小等有关规定及I/O特性等。

3.4 事务管理

数据库系统运行的基本工作单位是事务。事务相当于操作系统中的进程，是用户定义的一个数据库操作序列，要么全做，要么全不做。数据库具有以下特性：

1. 原子性Atomicity：数据库的逻辑工作单位。
2. 一致性Consistency：使数据库从一个一致性状态变到另一个一致性状态。
3. 隔离性Isolation：不能被其他事务干扰。
4. 持久性Durability：一旦提交，改变就是永久性的。

数据库事务的使用方式，这里就不写了。

3.4.1 并发控制

在多用户共享系统中，许多事务是可能同时对同一数据进行操作，称为“并发操作”。

数据库并发操作带来的问题有：丢失更新问题、不一致分析问题（读过时的数据）、依赖于未提交更新的问题（读了“脏”数据）。

处理并发控制的主要方法是采用封锁技术。它有两种类型：排他型封锁（X封锁）和共享型封锁（S封锁），分别介绍如下：

1. 排他型封锁（X封锁）。如果事务T对数据A（可以是数据项、记录、数据集乃至整个数据库）实现了X封锁，那么只允许事务T读取和修改数据A，其他事务要等事务T解除X封锁之后，才能对数据A实现任何类型的封锁。
2. 共享型封锁（S封锁）。X封锁只允许一个事务独锁和使用数据，要求太严，需要适当放宽，例如可以允许并发读，但不允许修改，这就产生了S封锁概念。S封锁的含义是：如果事务T对数据A实现了S封锁，那么允许事务T读取数据A，但不能修改数据A，在所有S封锁解除前决不允许任何事务对数据A实现X封锁。

在多个事务并发执行的系统中，主要采取封锁协议来进行处理。

1. 一级封锁协议。事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。一级封锁协议可防止丢失修改，并保证事务T是可以恢复的。但不能保证可重复读和不读“脏”数据。
2. 二级封锁协议。一级封锁协议加上事务T在读取数据R之前先对其加S锁，读完后即可释放S锁。二级封锁协议可防止丢失修改，还可防止读“脏”数据，但不能保证可重复读。
3. 三级封锁协议。一级封锁协议加上事务T在读取数据R之前先对其加S锁，直到事务结束才释放。三级封锁协议可以方式丢失修改、防止读”脏“数据与防止数据重复读。
4. 两段锁协议。所有事务必须分两个阶段对数据项加锁和解锁。其中扩展阶段是在对任何数据进行读、写操作之前，首先要申请并获得对该数据的封锁；收缩阶段是在释放一个封锁之后，事务不能再申请和获得任何其他封锁。若并发执行的所有事务均遵守两段封锁协议，则对这些事务的任何并发调度策略都是可串行化的。遵守两段封锁协议的事务可能发生死锁。

下面讨论封锁的粒度。所谓封锁的粒度即是被封锁数据目标的大小。在关系数据库中，封锁粒度有属性值、属性值集、元组、关系、某索引项（或整个索引）、整个关系数据库、物理页（块）等几种。

封锁粒度小则并发性高，但开销大；封锁粒度大则并发性低，但开销小。

采用封锁的方法会带来死锁问题。

1. 预防法。采用一定的操作方式以保证避免死锁的出现，顺序申请法、一次申请法等即是此类方法。所谓顺序申请法是指对封锁对象按序编号，在用户申请封锁时必须按编号顺序（从小到大或反之）申请，这样能避免死锁发生。所谓一次申请法即是指用户在一个完整操作过程中必须一次性申请它所需要的所有封锁，并在操作结束后一次性归还所有封锁，这样也能避免死锁的发生。
2. 死锁的解除法。此方法允许产生死锁，并在死锁产生后通过解锁程序以解除死锁。这种方法需要有两个程序，一是死锁检测程序，用它测定死锁是否发生，另一是解锁程序，一旦经测定系统已经产生死锁则启动解锁程序以解除死锁。

3.4.2 故障与恢复

1. 数据库故障

数据库的故障可以用事务的故障来表示，主要分为四类：

1. 事务故障。事务在运行过程中由于某些原因，未能运行至正常终止点就被撤销。
2. 系统故障。系统在运行过程中，由于某种原因，致使事务在执行过程中以非正常方式终止，这时内存中的信息丢失，但是存储在外存储设备上的数据不会受影响。
3. 介质故障。系统在运行过程中，由于某种硬件故障，是存储在外存储上的数据部分损失或全部损失。
4. 计算机病毒

在数据库系统中，恢复的基本含义就是恢复数据库本身。也就是说，在发生某种故障使数据库当前的状态已经不再正确时，把数据库恢复到已知为正确的某一状态。目前数据库中最常用的恢复方式是转储和登记日志文件。

2. 故障的恢复

1. 事务故障的恢复。恢复子系统应对此事务做撤销处理。事务故障的恢复是系统系统完成的，不需要用户敢于，步骤如下：
   
   • 反向扫描文件日志，查找该事务的更新操作。
   • 对该事务的更新操作执行逆操作。
   • 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
   • 如期处理下去，直至读到此事务的开始标记，事务故障恢复完成。
2. 系统故障的恢复。系统故障发生时，造成数据库不一致状态的原因有两个：一是由于一些未完成事务对数据库的更新已写入数据库；二是由于一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库。系统故障的恢复是在重新启动时自动完成的，不需要用户干预，步骤如下：
   
   • 正向扫描日志文件，找出在故障发生前已经提交的事务，将其事务标记记入重做（Redo）队列。同时找出故障发生时尚未完成的事务，将其事务标记记入撤销（Undo）队列。
   • 对撤销队列中的各个事务进行撤销处理：反向扫描日志文件，对每个Undo事务的更新操作进行逆操作。
   • 对重做队列中的各个事务进行重做处理：正向扫描日志文件，对每个Redo事务重新执行日志文件登记的操作。
3. 介质故障与病毒破坏的恢复。在发生介质故障和遭病毒破坏时，磁盘上的物理数据库被破坏，这是的恢复操作可分为三步：
   
   • 装入最新的数据库后备副本，是数据库恢复到最近一次转储时的一致性状态。
   • 从故障点开始反向读日志文件，找出已提交事务标识将其记录重做队列。
   • 从起始点开始正向读取日志文件，根据重做队列中的记录，重做所有已完成事务，将数据库恢复至故障前某一时刻的一致状态。
4. 具有检查点的恢复技术。检查点记录的内容可包括：
   
   • 建立检查点时刻所有正在执行的事务清单。
   • 这些事务最近一个日志记录的地址。
     采用检查点的恢复步骤如下：
   • 从重新开始文件中找到最后一个检查点记录在日志文件中的位置，由该地址在日志文件中找到最后一个检查点记录。
   • 由该检查点记录得到检查点建立时所有正在执行的事务清单队列（A）。
   • 建立重做队列（R）和撤销队列（U），把A队列放入U队列中，R队列为空。
   • 从检查点开始正向扫描日志文件，若有新开始的事务T1，则把T1放入U队列，若有提交的事务T2，则把T2从U队列移到R队列，直至日志文件结束。
   • 对U队列的每个事务执行Undo操作，对R队列的每个事务执行Redo操作。

DBA要做的基本操作是：

• 重装最近转储的后援副本。
• 运行日志文件，执行系统提供的恢复命令。

3.5 备份与恢复

备份和恢复计划的制定要遵循以下两个原则：

1. 保证数据丢失的情况尽量少或完全不丢失，因为性价比的要求，这要取决于显示系统的具体要求。
2. 备份和恢复时间尽量短，保证系统最大的可用性。

数据库备份按照不同方式可分为多种，这里按备份内容可以分为物理备份和逻辑备份两类。

物理备份是在操作系统层面上对数据库的数据文件进行备份，物理备份分为冷备份和热备份两种。冷备份是将数据库正常关闭，在停止状态下利用操作系统的copy、cp、tar、cpio等命令将数据库的文件全部备份下来，当数据库发生故障时，将数据文件复制回来，进行恢复。热备份也分为两种，一种是不关闭数据库，将数据库中需要备份的数据文件依次置于备份状态，相对保持静止，然后再利用操作系统的copy、cp、tar、cpio等命令将数据库的文件备份下来，备份完毕后再将数据文件恢复为正常状态，当数据库发生故障时，恢复方法同冷备份一样。热备份的另外一种方式是利用备份软件在数据库正常运行的情况下，将数据库中的数据文件备份出来。

为了提高物理备份的效率，通常将完全、增量、累积三种备份方式相结合。完全备份是将数据库中的内容全部备份，作为增量、累积的基础；增量备份是只备份上次完全、增量或累积备份以来修改的数据；累积备份是备份自上次完全或累计备份以来修改过的数据。一个备份周期通常由一个完全备份和多个增量、累积备份组成。由于增量或累积备份导出的数据少，所以其导出的文件较小，所需要的时间较少。利用一个完全备份和多个增量、累积备份恢复数据库的步骤如下：

1. 首先从完全备份恢复数据库。
2. 然后按照时间顺序从早到晚依次导入多个增量和累积备份文件。

逻辑备份是指利用各数据库系统自带的工具软件备份和恢复数据库的内容。

3.6 分布式数据库系统

3.6.1 分布式数据库的概念

是相对于集中式数据库系统而言的，是将数据库技术和网络技术向结合的产物。分布式数据库DDB比较确切的定义是：分布式数据库是由一组数据组成的，这组数据分布在计算机网络的不同计算机上，网络中的每个结点具有独立处理的能力，称为场地自治，它可以执行局部应用，同时，每个结点也能通过网络通信子系统执行全局应用。负责分布式数据库的建立、查询、更新、复制、管理和维护的软件，称为分布式数据库管理系统DDBMS。分布式数据库管理系统保证分布式数据库中数据的物理分布对用户的透明性。一个计算机网络组成的计算机系统，在配置了分布式数据库管理系统，并在其上建立了分布式数据库和相应的应用程序后，救称其为分布式数据库系统DDBS。

1. 分布式数据库的特点

1. 数据库的分布性。分布式数据库中的数据分布于网络中的各个结点。
2. 统一性。主要表现在数据在逻辑上的统一性和数据在管理上的统一性两个方面。
3. 透明性。用户在使用分布式数据库系统时，数据在物理上的存储对用户是透明的。同使用集中式数据库一样。

与集中式数据库相比，分布式数据库具有下列优点：

1. 坚固性好。即系统的可靠性和可用性好。
2. 可扩充性好。可根据发展的需要增减结点，或对系统重新配置。
3. 可改善性能。在分布式数据库中可就近分布，合理的冗余的原则来分布各个结点上的数据，构造分布式数据库，是大部分数据可以就近访问，避免了集中式数据库的瓶颈问题，减少了系统的响应时间，提高了系统的效率，而且也降低了通信费用。
4. 自治性好。数据可以分散管理，同意鞋套，即系统中各结点的数据操作和相互作用是高度自治的，不存在主从控制。

同样同集中式数据库相比，分布式数据库也有集中式数据库所没有的问题。首先，异构数据库的集成问题是一项比较复杂的技术问题，目前还很难用一个通用的分布式数据库管理系统来解决这一问题。其次，如果数据库设计的不好，数据分布不合理，以致远距离访问过多，尤其是分布连接操作过多，不但不能改善性能，反而会使性能降低。

2. 分布式数据库的分类

1. 按DDBMS软件同构度来分，当所有服务器软件（或每个DDBMS）和所有的客户软件均用相同的软件时称为同构型分布式数据库；反之，称为异构型分布式数据库。
2. 按局部自治度来分。当对DDBMS的存取必须通过客户软件，则系统称为无局部自治；当局部事务允许对服务器软件进行直接存取，则系统称为有一定的局部自治。自治的两个分别是无局部自治和联邦型DDBMS霍城多数据库系统。多数据库系统本质上是集中式和分布式的混合体：对一个局部用户而言，它是自治的，那么是一个DBS；对一个全局用户而言，则是一个分布式DBS，但这个DDBS没有全局概念模式，只有一个由各局部数据库提供给全局允许共享的有关模式的集成。
3. 按分布透明度来分。分布式透明度的另一个概念是模式集成度。若用户可以对集成模式操作不需要涉及任何片段、重复、分布等信息，则这类DDBMS称为具有高度分布透明（或高度模式集成）；若用户必须知道所有关于片段、重复、分布等信息时则这类DDBMS没有分布透明，没有模式集成度。当系统不提供分布透明，用户查询时必须指定特定的场地，特定的片段等信息。当然DDBMS也可以部分分布透明。

3. 分布式数据库的目标

1. 局部结点自治性。
2. 不依赖中心结点。即每个结点具有全局字典管理、查询处理、并发控制和恢复控制等功能。
3. 能连续操作。该目标使中断分布式数据库服务情况减至最少，当一个新场地合并到现有的分布式系统或从分布式系统中撤离一个场地不会导致任何不必要的服务中断；在分布式系统中可以动态的建立和消除片段，而不中止任何组成部分的场地和数据库；应尽可能在不使整个系统停机的情况下对组成分布式系统的场地的DBMS进行升级。
4. 具有位置独立性（或称位置透明性）。
5. 分片独立性（或称分片透明性）。将给定的关系分成若干块或片，提高系统的处理性能。
6. 数据复制独立性。指将给定的关系（或片段）可在物理级用许多不同存储副本或复制品在不同场地上存储。
7. 支持分布式查询处理。在分布式数据库系统中有三类查询：局部查询、远程查询和全局查询。局部查询和远程查询仅涉及单个结点的数据，查询优化技术是集中式数据库的查询优化技术。全局查询涉及多个结点上的数据，起查询处理和优化要复杂的多。
8. 支持分布事务管理。事务管理有两个主要方面：恢复控制和并发控制。在分布式系统中，单个事务会涉及多个场地上的代码执行，会涉及多个场地上的更新，可以说每个事务是由多个“代理”组成的，每个代理代表在给定场地上的给定事务上执行的过程。在分布式系统中必须保证事务的代理集或者全部一致交付，或者全部一致回滚。
9. 具有硬件独立性。
10. 具有操作系统独立性。
11. 具有网络独立性。
12. 具有DBMS独立性。实现对异构型分布式系统的支持。

一个分布式数据库系统，对于用户来说，应当看上去想一个非分布式系统。

3.6.2 分布式数据库的架构

模式从整体上可以分为两大部分：下半部分是集中式数据库的模式结构，代表了各局部场地上局部数据库系统的基本结构；上半部分是分布式数据库系统增加的模式级别。

1. 全局外模式。是全局应用的用户视图，是全局概念模式的子集。
2. 全局概念模式。定义分布式数据库中数据的整体逻辑架构，数据如同没有分布一样，可用传统的集中式数据库中所采用的方法定义。
3. 分片模式。每一个全局关系可以划分为若干不相交的部分，每一个部分称为一个片段，即“数据分片”。分片模式就是定义片段及全局关系到片段的映像，这种映像是一对多的，即每个片段来自一个全局关系，而一个全局关系可对应多个片段。
4. 分布模式。定义片段的存放结点。分布模式的映像类型确定了分布式数据库是冗余的还是非冗余的。若映像是一对多的，即一个片段分配到多个结点上存放，则是冗余的分布式数据库，否则是不冗余的。
   根据分布模式提供的信息，一个全局查询可以分解为若干子查询，每一子查询要访问的数据都属于同一场地的局部数据库。
   分片模式和分布模式均是全聚德，分布式数据库中增加的这些模式和相应的映像是的分布式数据库系统具有了分布透明性。
5. 局部概念模式。一个全局关系经逻辑划分成一个或多个逻辑片段，每个逻辑片段被分配在一个或多个场地上，称为该逻辑片段在某场地上的物理映像或物理片段。分配在同一场地上的同一个全局概念模式的若干片段（物理片段）构成了该全局模式在该场地上的一个物理映像。
   一个场地上的局部概念模式是该场地上所有全局概念模式在该场地上物理映像的集合。
   全局概念模式与场地独立，而局部概念模式与场地有关。
6. 局部内模式。是DDB中关于物理数据库的描述，类似于集中式DB中的内模式，但起描述的内容不仅包含局部本场地的数据的存储描述，还包括全局数据在本场地的存储描述。

在六层模式中，全局概念模式、分片模式和分布模式是与场地特征无关的，是全局的，因此他们不依赖于局部DBMS的数据模型。在低层次上，需要把物理映像映射成由局部DBMS支持的数据模型。这种映像由局部映射模式完成。

这种分层的模式结构为理解DDB提供了一种通用的概念结构。它有三个显著的特征：

1. 数据分片和数据分配概念的分离，形成了“数据分布独立型”概念。
2. 数据冗余的显示控制。
3. 局部DBMS的独立性。也成为“局部映射透明性”。

分布式数据库系统与并行数据库系统的区别

相似点：它们都是通过网络连接各个数据处理结点的，整个网络中的所有结点构成一个逻辑上统一的整体，用户可以对各个结点上的数据进行透明存取等。区别有以下几个方面：

1. 应用目标不同。并行数据库的目标是充分发挥并行计算机的优势，利用系统中各个处理机结点并行的完成数据库任务，提高数据库的整体性能。分布式数据库系统的主要目标在于实现各个场地自治和数据的全局透明共享，而不要求利用网络中的各个结点来提高系统的整体性能。
2. 实现方式不同。在并行数据库中，为了充分发挥各个结点的处理能力，各结点件采用高速通信网络互联，节点间数据传输代价相对较低。当负载不均衡时，可以将工作负载过大的结点上的任务通过高速通信网络送给空闲结点处理，从而实现负载平衡。在分布式数据库系统中，各节点（场地）间一般通过局域网或广域网互联，网络带宽比较低，各场地之间的通信开销较大，因此在查询处理时一般应尽量减少结点间的数据传输量。
3. 各结点的地位不同。在并行数据库中，各结点之间不存在全局应用和局部应用的概念，各个结点协同作用，共同处理，而不可能有局部应用。
   在分布式数据库系统中，各结点除了能够通过网络协同完成全局事务外，还有自己结点场地的自治性。也就是说，分布式数据库系统的每个场地又是一个独立的数据库和自己的客户，可运行自己的DBMS，执行局部应用，具有高度的自治性。这也是并行数据库与分布式数据库之间最主要的区别。

2. 数据分片和透明性

分片的方式有多种，水平分片和垂直分片是两种基本的分片方式，混合分片和导出分片是较复杂的分片方式。

1. 分片透明性是分布透明性的最高层次。指的是用户或应用程序只对全局关系进行操作而不必考虑数据的分片。当分片模式改变时，只要改变全局模式到分片模式的映像（映像2），而不映像全局模式和应用程序。全局模式不变，应用程序不必改写，这就是分片透明性。
2. 位置透明性是分布透明性的下一个层次。指用户或应用程序应当了解分片情况，但不必了解片段的存储场地。当存储场地改变时，只要改变分片模式到分配模式的映像（映像3），而不影响应用程序。同时，若片段的重复副本数目改变了，那么数据的冗余也会改变，但用户不必关心如何保持各副本的一致性，这也提供了重复副本的透明性。
3. 局部数据模型透明性是指用户或应用程序应当了解分片及各片段存储的场地，但不必了解局部场地上使用的是何种数据模型。模型的转换及语言等的转换均由映像4来完成。

3. 分布式数据库管理系统

任务，首先就是把用户与分布式数据库隔离开来，使其对用户而言，整个分布式数据库就像是一个传统的集中式数据库。换句话说，一个分布式数据库管理系统和用户之间的接口，在逻辑上与集中式数据库管理系统是一致的，但是考虑到分布式数据库的特点，其物理实现上又与集中式数据库不同。

DDBMS由4部分组成：

1. LDBMS（局部DBMS）。局部场地上的数据库管理系统的功能是建立和管理局部数据库，提供场地自治能力、执行局部应用及全局应用的子查询。
2. GDBMS（全局DBMS）。全局数据库管理系统的主要功能是提供分布透明性，协调全部事务的执行，协调各局部DBMS以完成全局应用，保证数据库的全局一致性，执行并发控制，实现更新同步，提供全局恢复功能。
3. 全局数据字典。存放全局概念模式、分片模式。定义及各模式之间映像的行医：存放有关用户存取权限的定义，以保证全局用户的合法权限和数据库的安全性；存放数据完整性的约束条件的定义，其功能与集中式数据库的数据字典类似。
4. CM，通信管理。在分布式数据库各场地之间传送消息和数据，完成通信功能。

DDBMS功能的分割和重复及不同的配置策略就导致了各种架构。

1. 全局控制集中的DDBMS。特点是全局控制成分GDBMS集中在某一结点上，由该结点完成全局事务中的协调和局部数据库转换等一切控制功能。全局数据字典只有一个，也存放在该结点上，它是GDBMS执行控制的依据。优点是控制简单，易实现更新一致性，但由于控制集中在某一特定的结点上，不仅容易形成瓶颈而且系统较脆弱，一旦该节点出故障，整个系统就会瘫痪。
2. 全局控制分散的DDBMS。特点是全局控制成分GDBMS分散在网络的每一个结点上，全局数据字典也在每个结点上有一份，每个结点都能完成全局事务的协调和局部数据库转换，每个结点即是全局事务的参与者又是协调者，一般称这类结构为完全分布的DDBMS。优点是结点独立，自治性强，单个结点退出或进入系统均不会影响整个系统的运行，但是全局控制的协调机制和一致性的维护都比较复杂。
3. 全局控制部分分散的DDBMS。这种结构是根据应用的需要将GDBMS和全局数据字典分散在某些结点上，是介于前两种情况之间的架构。

局部DBMS的一个重要性质是：局部DBMS是同构的还是异构的。同构和异构的级别可以有三级：硬件、操作系统和局部DBMS。

异构型DDBMS的设计和实现比同构性DDBMS更加复杂，他要解决不同的DBMS之间及不同的数据模型之间的转换。

3.7 数据仓库

3.7.1 数据仓库的概念

数据仓库是一个面向主题的、集成的、相对稳定的、且随时间变化的数据集合，用于支持管理决策。

1. 面向主题的

操作型数据库的数据组织面向事务处理任务（面向应用），各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织的。主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面。一个主题通常与多个操作型信息系统相关。

2. 集成的

最重要特性。面向事务处理的操作型数据库通常与某些特定的应用有关，数据库之间相互图例，而且往往是异构的。而数据仓库中的数据是咋对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

3. 相对稳定的

操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析，所涉及到的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但是修改和删除操作很少，通常只需要定期的加载、更新。

4. 随时间变化的

操作型数据库主要关心当前某一个时间段内的数据，而数据仓库内的数据通常包含历史信息，系统记录了企业从过去某一时刻点（如开始应用数据仓库的时点）到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

数据仓库反映历史变化的属性主要表现在：

1. 数据仓库中的数据时间期限要远远长于传统操作型数据库系统中的数据时间期限，传统操作型数据库系统中的数据时间期限可能为数十天或数个月，数据仓库中的数据时间期限往往为数年甚至几十年
2. 传统操作型数据库系统中的数据含有“当前值”数据，这些数据在访问时是有效的，当然数据的当前值也能被更新，但数据仓库中的数据仅仅是一系列某一时刻生成的复杂的快照；
3. 传统操作型数据系统中可能包含也可能不包含时间元素，如年、月、日、时、分、秒等，而数据仓库中一定会包含时间元素。

数据仓库与传统数据库的比较

比较项目	传统数据库	数据仓库
数据内容	当前值	历史的、归档的、归纳的、计算的数据（处理过的）
数据目标	面向业务操作程序、重复操作	面向主体域，分析应用
数据特性	动态变化、更新	静态，不能直接更新，只能定时添加、更新
数据结构	高度结构化，复杂，适合操作计算	简单、适合分析
使用频率	高	低
数据访问量	每个事务一般只访问少量记录	每个事务一般访问大量记录
对响应时间的要求	计时单位小，如秒	计时单位相对较大，除了秒，还有分钟、小时

3.7.2 数据仓库的结构

数据仓库系统要包含数据源、数据准备区、数据仓库数据库、数据集市/知识挖掘库和各种管理工具和应用工具。数据仓库建立之后，首先要从数据源中抽取相关的数据到数据准备去，在数据准备去中经过净化处理后再加载到数据仓库数据库，最后根据用户的需求将数据导入数据集市和知识挖掘库中。当用户使用数据仓库时，可以利用包括OLAP在内的多种数据仓库应用工具向数据集市/知识挖掘库或数据仓库进行决策查询分析或知识挖掘。数据仓库的创建、应用可以利用各种数据仓库管理工具辅助完成。

1. 数据仓库的参考框架

由数据仓库基本功能层、数据仓库管理层和数据仓库环境支持层组成。

1. 数据仓库基本功能层。包含数据源、数据准备区、数据仓库结构、数据集市或知识挖掘库，以及存取和使用部分。功能是从数据源中抽取数据，对所抽取的数据进行筛选、清理，将处理过的数据导入或者加载到数据仓库中，根据用户的需求设立数据集市，完成数据仓库的复杂查询、决策分析和知识的挖掘等。
2. 数据仓库管理层。由数据仓库的数据管理和数据仓库的元数据管理组成。
   包含数据提取、新数据需求与查询管理，数据加载、存储、刷新和更新系统，安全性及用户授权管理系统及数据归档、恢复及净化系统等四个部分。
3. 数据仓库的环境支持层。由数据仓库数据传输层和数据仓库基础层组成。数据仓库的不同结构之间的数据传输需要数据仓库的传输层来完成。
   数据仓库的传输层包含数据传输和传送网络、客户/服务器代理和中间件、复制系统及数据传输层的安全保障系统。

2. 数据仓库的架构

1. 数据源。数据仓库系统的基础。通常包括企业内部信息和外部信息。内部信息包括存放于RDBMS（关系型DBMS）中的各种业务处理数据和各类文档数据。外部信息包括各类法律法规、市场信息和竞争对手的信息等。
2. 数据的仓库与管理。是整个数据仓库系统的核心。数据仓库的真正关键是数据的存储和管理。数据仓库的组织管理方式决定了他有别于传统数据库，也决定了其对外部数据的表现形式。数据仓库按照数据的覆盖范围，可以分为企业级数据仓库和部门级数据仓库。
3. OLAP服务器。对分析需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势。具体实现可以分为：ROLAP、MOLAP和HOLAP。ROLAP基本数据和聚合数据均存放在RDBMS之中；MOLAP基本数据和聚合数据均存放在多维数据库中；HOLAP基本数据存放在RDBMS中，聚合数据存放于多维数据库中。
4. 前端工具。主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具及各种基于数据仓库或数据集市的应用开发工具。其中数据分析工具主要针对OLAP服务器，报表工具、数据挖掘工具主要针对数据仓库。

3.7.3 数据仓库的实现方法

数据仓库的建立过程分为：需求分析、概念模型设计、逻辑模型设计、物理模型设计和数据仓库生成。

从整体的角度看，数据仓库的实现方法主要有自顶向下法、自底向上法和联合方法。

1.自顶向下法

在该方法中，首先应找出数据仓库解决方案所要满足的商业需求，把商业需求视为实际数据仓库的首要任务。自顶向下法的优缺点如下表

优点	缺点
商业需求清楚的描绘出数据仓库实现的范围，因此是实现数据仓库解决方案的有效方法	有时会超出当前的业务范围
技术取决于商业	技术可以促进商业和竞争优势，但开始时对商业的促进是不明显的
易于向决策者提供数据仓库的收益情况	一旦数据仓库已经实现，可能就不再要求更公告的目标

该方法一般用于以下情况：

1. 实现单位比较熟悉技术，并具有根据商业需求采用自顶向下法开发应用程序的丰富经验
2. 决策层（总经理、决策者、投资者）完全清楚数据仓库的预测目标。
3. 决策层（总经理、决策者、投资者）完全清楚数据仓库用作哪些机构的决策支持工具。
4. 决策层（总经理、决策者、投资者）完全清楚数据仓库已经是长夜过程中的一个子过程。

2. 自底向上法

一般从实现和基于技术的原型入手。先选择一个特定的、众所周知的商业问题的子集，再为该子集制定方案。实现自底向上法一般是比较快的。优缺点如下表：

优点	缺点
实现的需求和开始时的需求远远超过自顶向下分析和长期考虑的范围	最初方案实现以后，最好回顾一下方案是如何服务于整个企业的。
在企业对数据仓库了解的初期，该方法使企业无需巨大投入就可见到效益	单个自底向上工程项目的失败可能推迟潜在技术的实现
少数人集中工作在一个部门范围，可以加速实现决策过程	早起的小组应不断发展为较大的小组，以扩充最初方案的覆盖范围。

自底向上法一般用于以下情况：

1. 企业还没有确定掌握数据仓库技术，希望进行技术评估来决定运行该技术的方式、地点和时间。
2. 企业希望了解实现和运行数据仓库所需要的各种费用情况。
3. 企业在对数据仓库进行投资选择。

3. 联合方法

在以上两种方法的联合方法中，企业在保持自底向上的快速实现和基于应用的同时，还可以利用自顶向下方法的规划和决策性质。这种方法依赖于以下两个因素：

1. 自顶向下的结构、标准和设计小组，可以从一个项目向另外一个项目传递知识，也可以把战术决策变为战略决策。
2. 自底向上的项目小组，它直接负责在短期内实现一个集中的、部门级的商务解决方案。

联合方法具有以上两种方法的优点，但是难以作为一个项目来管理，该方法一般有用于：

1. 实现企业拥有经验丰富的设计师，有能力建立、证明、应用和维护数据结构、数据结构和企业模型，可以很容易从具体（运作系统中的元数据）转移到抽象。
2. 企业拥有固定的项目小组，完全清楚数据仓库技术应用的场所。他们可以清楚的看到当前的商务需求。

3.8 数据挖掘

目前的数据库系统可以高效的实现数据的录入、查询、统计等功能，但无法发现数据中存在的关系和规则，无法根据现有的数据预测未来的发展趋势。

3.8.1 数据挖掘的概念

三种基础技术分别为：海量数据搜集、强大的多处理器计算机和数据挖掘算法。

从技术角度来看，数据挖掘就是从大量的、不完全的、有噪声的、模糊的、随机的实际应用数据中，提取隐含在其中的、人们实现不知道的、但又潜在有用的信息和知识的过程。这个定义包括好几层含义：数据源必须是真实的、大量的、含噪声的；发现的是用户感兴趣的知识；发现的知识要可接受、可理解、可运用；并不要求发现放之四海皆准的知识，仅支持特定的发现问题。

从商业角度来看，数据挖掘是一种新的商业信息处理技术，其主要特点是对商业数据库中的大量业务数据进行抽取、转换、分析和其他模型化处理，从中提取辅助商业决策的关键性数据。

简而言之，数据挖掘其实是一种深层次的数据分析方法。按企业既定业务目标，对大量的企业数据进行探索和分析，揭示隐藏的、未知的或验证已知的规律性，并进一步将其模型化的先进有效的方法。

数据挖掘与传统的数据分析（如查询、报表、联机应用分析）的本质区别是数据挖掘是在没有明确假设的前提下去挖掘信息、发现知识。数据挖掘所得到的信息应具有先知、有效和可实用三个特征。

数据挖掘技术从一开始就是面向应用的。它不仅是面向特定数据库的简单检索查询调用，而且要对这些数据进行微视、中观乃至宏观的统计、分析、综合和推理，以指导实际问题的求解，企图发现事件间的相互关联，甚至利用已有的数据对未来的活动进行预测。

3.8.2 数据挖掘的功能

数据挖掘通过预测未来趋势及行为，做出前摄的、基于知识的决策。数据挖掘的目标是从数据库中发现隐含的、有意义的知识。主要有以下五类功能。

1. 自动预测趋势和行为

2. 关联分析

关联可分为简单关联、时序关联、因果关联。关联分析的目的是找出数据库中隐含的关联网。

3. 聚类

数据库中的记录可被划分为一系列有意义的子集，即聚类。聚类技术主要包含传统的模式识别方法和数学分类学。

4. 概念描述

是对某类对象的内涵进行描述，并概括这类对象的有关特征。分为特征性描述和区别性描述。前者描述某类对象的共同特征，后者描述不同对象之间的区别。生成一个对象的特征性描述只涉及该类对象中的所有对象的共性。生成区别性描述的方法很多，如决策树方法、遗传算法等。

5. 偏差检测

基本方法是：寻找观测结果与参照值之间有意义的差别。

3.8.3 数据挖掘常用技术

1. 关联分析

主要用于发现不同事件之间的关联性，即一个事件发生的同时，另一个事件也经常发生。重点在于快速发现那些有实用价值的关联发生的事件。主要依据是事件的发生概率和条件概率应该符合一定的统计意义。

2. 序列分析

主要用于发现一定时间间隔内接连发生的事件。这些事件构成一个序列，发现的序列应该具有普遍意义，其依据除了统计上的概率之外，还要加上事件的约束。

3. 分类分析

通过分析具有类别的样本的特点，得到决定样本属于各种类别的规则或方法。利用这些规则和方法对未知类别的样本分类时应该具有一定的准确度。其主要方法有基于统计学的贝叶斯方法、神经网络方法、决策树方法和支持向量机。

4. 聚类分析

是根据物以类聚的原理，将本身没有类别的样本聚集成不同的组，并且对这样的组进行描述的过程。其主要依据是聚集到同一个组的样本应该彼此相似，而属于不同组的样本应该足够不相似。

5. 预测

与分类类似，但预测是根据样本的已知特征估算某个连续类型的变量的取值的过程，而分类知识用于判别样本所属的离散类别而已。预测常用的技术是回归分析。

6. 时间序列分析

分析的是随时间变化的时间序列，目的是预测未来发展趋势，或者寻找相似发展模式或者是发现周期性发展规律。

3.8.4 数据挖掘的流程

数据挖掘的大致流程如下：

1. 问题定义

在开始数据挖掘之前，需要先弄清楚背景知识，即决定到底要干什么

2. 建立数据挖掘库

将要挖掘的数据收集到一个数据库中，而不是采用原有的数据库或数据仓库。这是因为大部分情况下需要修改要挖掘的数据，而且还会遇到采用外部数据的情况；另外，数据挖掘还要对数据进行各种纷繁复杂的统计分析，而数据仓库可能不支持这些数据结构。

3. 分析数据

是通常所进行的对数据深入调查的过程，从数据集中找出规律和趋势，用聚类分析区分类别，最终要达到的目的就是搞清楚多因素相互影响的、十分复杂的关系、发现因素之间的相关性。

4. 调整数据

对分析的数据进行进一步的明确化和量化。针对问题的需求对数据进行增删，按照对整个数据挖掘的过程的新认识组合或生成一个新的变量，以体现对状态的有效描述。

5. 模型化

在问题进一步明确，数据结构和内容进一步调整的基础上，救可以建立形成知识的模型。这一步是数据挖掘的核心环节，一般运用神经网络、决策树、数理统计、时间序列分析等方法来建立模型。

6. 评价和解释

上面得到的数据模型，有可能是没有实际含义或者没有使用价值的，也有可能是其不能准确反映数据的真实意义，甚至在某些情况下是与事实相反的，因此需要评估，确定哪些是有效的、有用的模式。评估的一个办法是直接使用原先建立的挖掘数据库中的数据来进行检验，另一种办法是另找一批数据并对其进行检验，在一中办法是在实际运行的环境中取出新鲜数据进行检验。

数据挖掘过程的分布实现，不同的步骤需要不同专长的人员，他们大致可以分为三类；

1. 业务分析人员。要求精通业务，能够解释业务对象，并根据各业务对象确定出用于数据定义和挖掘算法的业务需求。
2. 数据分析人员。精通数据分析技术，并较熟练的掌握统计学，有能力好把业务需求转化为数据挖掘的各步操作，并为每步操作选择合适的技术。
3. 数据管理人员，精通数据管理技术，并从数据库或数据仓库中收集数据。

由上可见，数据挖掘是一个多种专家合作的过程，也是一个在资金上和技术上高投入的过程，这一过程要反复进行，在反复过程中，不断地趋近事物的本质，不断地优选问题的解决方案。

3.9 NOSQL

即Not Only SQL，不仅仅是SQL。NOSQL数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具有关系型数据库无法比拟的性能优势。

与关系型数据库相比，NOSQL数据库具有以下几个优点：

1. 易扩展

去掉关系数据库的关系型特征。数据之间无关系，这样就非常容易扩展，在架构的层面上带来了可扩展的能力。

2. 大数据量，高性能

具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关特性，数据库的结构简单。一般MySQL使用Query Cache，每次表一更新Cache就失效，它是一种大粒度的Cache，在针对Web2.0的交互频繁的应用，Cache性能不高。而NOSQL的Cache是记录级别的，是一种细粒度的Cache，所以NOSQL在这个层面上来讲性能就好很多。

3. 灵活的数据模型

无须事先为要存储的数据建立字段，随时可以存储自定义的数据格式。

4. 高可用

在不太影响性能的星空，就可以方便的实现高可用的架构，通过复制模型也能实现高可用

当然，NOSQL也存在很多缺点，例如：并未形成一定标准，各种产品层出不穷，内部混乱，各种项目还需要时间来检验，缺乏相关专家技术的支持等。

3.10 大数据

指无法在一定时间范围内用常规软件工具进行捕捉、管理、和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流动优化能力的海量、高增长和多样化的信息资产。

1. 大数据的特点

业界通常用4个V（即Volume、Variety、Value、Velocity）来概括大数据的特征。

• Volume：指的是数据体量巨大，从TB级别跃升到PB级别、EB级别，甚至于达到ZB级别。
• Variety：指的是数据类型繁多。这种类型的多样性也让数据被分为结构化数据和非结构化数据。
• Value：指的是价值密度低，价值密度的高低与数据总量的大小成反比。
• Velocity：指的是处理速度快，也是大数据区别于传统数据挖掘的最显著特征。

2. 传统数据与大数据的比较

比较维度	传统数据	大数据
数据量	GB或TB级	PB级或以上
结构化程度	结构化或半结构化数据	所有类型的数据
数据分析需求	现有数据的分析与检测	深度分析（关联分析、回归分析）
硬件平台	高端服务器	集群平台

3. 大数据处理关键技术

一般包括：大数据采集、大数据预处理、大数据存储及管理、大数据分析及挖掘、大数据展现和应用（大数据检索、大数据可视化、大数据应用、大数据安全等）。

4. 大数据应用

大数据可以在各行各业得到应用。

第四章 计算机网络

计算机网络是指由通信线路互相连接的许多独立自足工作的计算机构成的资源共享集合体，它是计算机技术和通信技术相结合的产物。

4.1 网络架构与协议

网络架构是指计算机网络的隔层及其协议的集合。计算机之间要交换数据，就必须遵守一些事先约定好的规则，用于规定信息的格式及如何发送和接受信息的一套规则就称为网络协议。

计算机网络采用分层设计方法，按照信息的传输过程将网络的整体功能分解为一个个的功能层，不同机器上的同等功能层之间采用相同的协议，同一机器上的相邻功能层之间通过接口进行信息传递。

4.1.1 网络互联模型

开放系统互联参考模型OSI/RM，构造了由下到上的七层模型，分别是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。

1. OSI/RM各层的功能

1. 物理层。主要功能是透明的完成相邻接点之间原始比特流的传输。物理层在传输介质基础上作为系统和通信介质的接口，为数据链路层提供服务。
2. 数据链路层。负责在两个相邻接点之间的线路上无差错的传递以帧为单位的数据，通过流量控制和差错控制，将原始不可靠的物理层连接变成无差错的数据通道，并解决多用户竞争问题，使之对网络层显现一个可靠的链路。
3. 网络层。是通信子网的最高层，主要任务是在数据链路层服务的基础上，实现整个通信子网的连接，并通过网络连接交换网路服务数据单元。主要解决数据传输单元分组在通信子网中的路由选择、拥塞控制和多个网络互联的问题。网络层建立网络连接为传输层提供服务。
4. 传输层。既是负责数据通信的最高层，又是面向网络通信的低三层（物理层、数据链路层、网络层）和面向信息处理的高三层（会话层、表示层和应用层）之间的中三层，是资源子网和通信子网的桥梁，主要任务是为两台计算机的通信提供可靠的端到端的数据传输服务。
5. 会话层。利用传输层提供的端到端的数据传输服务，具体实施服务请求者与服务器提供者之间的通信、组织和同步他们的会话活动，病管理他们的数据交换过程。会话层提供服务通常需要经过建立连接、数据传输和释放连接三个阶段。会话层是最薄的一层，常被省略。
6. 表示层。处理的是用户信息的表示问题。短用户（用户进程）之间传送的数据包含语义和语法两个方面。语义是数据的内容及其含义，它由应用层负责处理；语法是与数据表示形式有关的方面，例如，数据的格式、编码和压缩等。表示层主要用于处理应用实体面向对象交换的信息的表示方法，包括用户数据的结构和在传输时的比特流（或字节流）的表示。这样，即使每个应用系统有各自的信息表示法，但被交换的信息类型和数值仍能用一种共同的方法来描述。
7. 应用层。通常是直接面向用户的一层，是计算机网络和最终用户之间的界面。在实际应用中，通常会把会话层和表示层归入应用层，是OSI/RM称为一个简化的五层模型。

2. TCP/IP结构模型

传输控制协议/网际协议。

1. 网络接口层。大致对应OSI/RM的数据链路层和物理层，TCP/IP协议不包含具体的物理层和数据链路层，只定义了网络接口层作为物理层的接口规范。网络接口层处在TCP/IP接口模型的最底层，主要负责为物理网络准备数据所需的全部服务程序和功能。
2. 网络互联层。也成网络层、互联网层或网际层，负责将数据报文独立的从信源传送到信宿，主要解决路由选择、阻塞控制和网络互联等问题，在功能上类似于OSI/RM中的网络层。
3. 传输层。负责在信源和信宿之间提供端到端的数据传输服务，相当于OSI/RM中的传输层。
4. 应用层。直接面向用户应用，为用户方便的提供对各种网络资源的访问服务，包含了OSI/RM会话层和表示层中的部分功能。

4.1.2 常见的网络协议

1. 应用层协议

应用程序通过本层协议利用网络完成数据交互的任务。主要协议如下：

• FTP，文件传输协议。是网络上两台计算机传送文件的协议，运行在TCP之上，是通过Internet将文件从一台计算机传输到另一台计算机的一种途径。传输模式包括Bin（二进制传输）和ASCII（文本文件）两种，除了文本文件之外，都应该使用二进制传输。FTP在客户机和服务器之间需建立两条TCP连接，一条用于传送控制信息（使用21号端口），另一条用于传送文件内容（使用20号端口）。
• TFTP，简单文件传输协议。用来在客户机和服务器之间进行简单文件传输的协议，提供不复杂，开销不大的文件传输协议。建立在UDP（用户数据报协议）之上，提供不可靠的数据流传输协议，不提供存取授权与认证机制，使用超时重传方式来保证数据的到达。
• HTTP，超文本传输协议，是用于从WWW服务器传输超文本到本地浏览器的传送协议。可以使浏览器更加高效，使网络传输减少。HTTP建立在TCP之上，它不仅保证计算机正确快速的传输超文本文档，还确定传输文档中的哪一部分，以及哪一部分内容首先显示等。
• SMTP，简单邮件传输协议，建立在TCP之上，是一种提供可靠且有效的电子邮件传输协议。SMTP是建模在FTP文件传输服务上的一种邮件服务器，主要用于传输系统之间的邮件信息，并提供与电子有间有关的通知。
• DHCP，动态主机配置协议，建立在UDP之上，是基于客户机/服务器模型设计的。所有的IP网络设定数据都由DHCP服务器集中管理，并负责处理客户端的DHCP要求；而客户端则会使用从服务器分配下来的IP环境数据。DHCP通过续租（默认为8天）的概念，有效且动态的分配客户端的TCP/IP设定。当租约过半时，客户机需要向DHCP服务器申请续租，当租约超过87.5%时，如果仍然没有和当初提供IP的DHCP服务器联系上，则开始联系其他的DHCP服务器。DHCP服务器分配的IP地址可以分为三种方式，分别是固定分配、动态分配和自动分配。
• Telnet，远程登录系统，是登录和仿真程序，建立在TCP之上，基本功能是允许用户登录进入远程计算机系统。以前，Telnet是一个将所有用户输入送到远程计算机进行处理的简单的终端程序。目前，它的一些较新的版本是在本地执行更多的处理，可以提供更好的响应，并且减少了通过链路发送到远程计算机的信息数量。
• DNS，域名系统，在Internet上域名与IP地址之间是一一对应的，域名虽然方便人们记忆，但机器之间只能互相识别IP地址，他们之间的转换工作称为域名解析，域名解析需要专门的域名解析服务器来完成，DNS就是进行域名解析的服务器。DNS通过对用户友好的名称查询计算机和服务，当用户在应用程序中输入DNS名称时，DNS服务可以将此名称解析为与之相关的其他信息，例如，IP地址。
• SNMP，简单网络管理协议，是为了解决Internet上的路由器管理问题而提出的，他可以在IP、IPX、AppleTalk和其他传输协议上使用。SNMP是指一系列网络管理规范的集合，包括协议本身、数据结构的定义和一些相关概念。

2. 传输层协议

• TCP，是整个TCP/IP协议族中最重要的协议之一。它是在IP协议提供的不可靠数据服务的基础上，采用了重发技术，为应用程序提供一个可靠的、面向连接的、全双工的数据传输服务。TCP协议一般用于传输数据量比较小，且对可靠性要求高的场合。
• UDP是一种不可靠的、无连接的协议，可以保证应用程序进程间的通信。与TCP相比，UDP是一种无连接的协议，他的错误检测功能要弱得多。可以这样说，TCP有助于提供可靠性，而UDP有助于提高传输速率。UDP协议一般用于传输数据量大，对可靠性要求不是很高，但要求速度快的场合。

3. 网络层协议

• IP，提供无连接的和不可靠的服务，它将差错检测和流量控制之类的服务授权给了其他的各层协议，这正是TCP/IP能够高效率工作的一个重要保证。网络层的功能主要由IP来提供，除了提供端到端的分组分发功能外，IP还提供很多扩充功能。例如，为了克服数据链路层对帧大小的限制，网络层提供了数据分块和重组功能，这使得很大的IP数据包也能以较小的分组在网络上传输。
• ARP 地址解析协议，用于童泰的完成IP地址向物理地址的转换。物理地址通常是指计算机的网卡地址，也称为MAC（媒体访问控制）地址，每块网卡都有唯一的地址。
• RARP，反向地址解析协议。用于动态完成物理地址向IP地址的转换。
• ICMP，网际控制报文协议，专门用于发送差错报文的协议，由于IP协议是一种尽力传送的通信协议，即传送的数据可能丢失、重复、延迟或乱序传递，所以需要一种尽量避免差错并能在发生差错时报告的机制，者就是ICMP的功能。
• IGMP，网际组管理协议。允许Internet中的计算机参加多播，是计算机用作向相邻多目路由器报告多目组成员的协议。多目路由器是支持组播的路由器，它向本地网络发送IGMP查询，计算机通过发送IGMP报告来应答查询。多目路由器负责将组播包转发到网络中所有组播成员。

4.1.6 IPv6

互联网协议的第6版

1. IPv6地址表示

一个32位的IPv4地址以8个位为一段分成4段，每段之间用点“.”分开。而IPv6的地址的128位是以16位为一段，共分为8段，每段的16位转换为一个4位的16禁止数字，每段之间使用冒号“:”分开。例如

2001:0da8:d001:0001:0000:0000:0000:0001

2. IPv6压缩地址表示

在IPv6中，常见到使用包含一长串0的地址，为了方便书写，对于每一段中的前导0可以进行省略，如前面的手续按格式地址经过一次压缩，可以得到：

2001:da8:d001:1:0:0:0:1

对于连续2段以上都为0的字段可以使用“::”（两个冒号）来表示，这样再次压缩，变成：

2001:da8:d001:1::1

注意，每个IPv6地址只允许有一个“::”

3. 内嵌IPv4的IPv6地址

这种表示法的第一部分使用十六进制表示，而IPv4部分采用10进制，这是过渡机制所采用的IPv6地址特有的表示法，如：

fe80:200:5efe:58.20.27.60

4. IPv6地址类型

IPv4有单播、广播和组播地址类型，在IPv6里面，广播已经不再使用了，这对网络管理员来说，应该是个好消息，因为在传统的IP网络中，出现的很多问题都是由于广播引起的。IPv6仍有3种地址类型，分别是单播、多播（也成为组播）、泛播（也称作任意播）。

1. 单播IPv6地址：单播地址唯一标识一个IPv6节点的接口。发送往单播地址的数据包最终传递给这个地址所标识的接口。为适应负载均衡，IPv6协议允许使用相同的IPv6地址，只要它们对于主机上的IPv6协议表现为一个接口。
2. 多播IPv6地址：多播地址标识一组IPv6节点的接口，发送往多播地址的数据包会被该多播地址所有的成员处理。
3. 泛播IPv6地址：泛播地址指派给多个节点的接口。发送往泛播地址的数据包只会传递给其中的一个接口，一般是相隔最近的一个接口。

5. IPv6的优势

1. IPv6具有更大的地址空间。IPv4中桂东IP地址长度为32位，而IPv6中IP地址的长度为128位。
2. IPv6使用更小的路由表。IPv6的地址分配一开始就遵循路由汇聚的原则，使路由器能在路由表中用一条记录表示一个子网，大大减小了路由器中路由表的长度，提高了路由器转发数据包的速度。
3. IPv6增加了增强的组播支持和对流支持，使网络上的多媒体应用有了长足发展的机会，为服务质量QoS控制提供了良好的网络平台。
4. IPv6加入了对自动配置的支持。这是对DHCP协议的改进和扩展，使得网络（尤其是局域网）的管理更加方便和快捷。
5. IPv6具有更高的安全性。在使用IPv6网络时，用户可以对网络层的数据进行加密，并对IP报文进行校验，极大地增强了网络的安全性。

6. IPv4到IPv6的过渡技术

1. 双协议栈技术：双栈技术通过节点对IPv4和IPv6双协议栈的支持，从而支持两种业务的共存。
2. 隧道技术：隧道技术通过在IPv4网络中部署隧道，实现在IPv4网络上对IPv6业务的承载，表示业务的共存和过渡。具体的隧道技术包括：6to4隧道、6over4隧道、ISATAP隧道。
3. NAT-PT技术：使用网关设备连接IPv4和IPv6网络，当IPv4和IPv6节点互相访问时，NAT-PT网关实现两种协议的转换翻译和地址的映射。

4.2 局域网和广域网

局域网LAN是将分散在有限地址范围内的多台计算机通过传输媒体连接起来的通信网络，通过功能完善的网络软件，实现计算机之间的相互通信和资源共享。广域网WAN是在传输距离较长的前提下所发展的相关技术的集合，用于将广大区域范围内的各种计算机设备和通信设备互联在一起，组成一个资源共享的通信网络。

4.2.1 局域网基础知识

局域网一般具有如下特点：

1. 地理分布范围较小。
2. 数据传输速率高。早起的局域网数据传输速率一般为10Mbps~100Mbps，目前，1000Mbps的局余万哥已经非常普遍。
3. 数据误码率低。这是因为局域网通常采用短距离基带传输，可以使用高质量的传输媒体，从而提高传输质量。
4. 一般以PC为主题，还包括终端和各种外设，网络中一般不架设主干网络系统。
5. 协议相对简单，结构灵活，建网成本低、周期短，便于管理和扩充。

构成局域网的网络拓扑结构主要有星形结构、总线结构、环形结构和网状结构。

1. 星形结构

就像一个蜘蛛网，中间是一个枢纽（网络交换设备）。所有的结点都连接到这个枢纽上，最终组成一个星形的拓扑结构的网络。目前一般办公室的局域网便是该结构。

2. 总线结构

是由一条共享的通信线路将所有结点连接在一起。这条共享的通信线路可以是一根同轴电缆或其他介质。

3. 环形结构

与总线结构类似，也是由一条共享的通信线路将所有节点连接在一起，不同的是，环形结构中的共享线路是闭合的，即它将所有节点排列成一个环，每个节点只与其他两个邻居节点直接相连。若一个节点想要给另一个节点发送消息，消息报文必须经过它们之间的所有节点。

4. 网状结构

网状结构方式的网络就是任何节点彼此之间都会由一根物理通信线路相连，任何节点出现故障都不会影响到其他节点。采用这种拓扑方式的网络的布线比较复杂，而且网络建设的成本也很高，控制方式也很复杂。在实际应用中，一般很少见到这种网络。

4.2.2 无线局域网

无线局域网WLAN主要运用射频RF技术取代原来局域网系统中必不可少的传输介质（例如：同轴电缆、双绞线）来完成数据的传送人物，有了WLAN，用户不必因使用有线传输介质而破坏原有的工作环境，可根据需要调整网络节点的位置。

1. 拓扑结构

无线局域网可以分为两大类，分别是有接入点模式（基础设施网络）和无接入点模式（Ad hoc网络）。

1. 基础设施网络。整个网络都使用无线通信的方式，但系统中存在接入点AP，通过接入点将一组节点逻辑上联系在一起，形成一个局域网。AP的作用于网桥类似，负责在802.11和802.3的MAC协议之间进行转换。一个AP覆盖的部分称为一个基本业务域，而AP控制的所有节点组成一个基本业务集，由两个以上的基本业务域可以组成一个分布式系统。
2. Ad hoc网络。整个网络都使用无线通信的方式，直接通过无线网卡实现点对点连接，与基础设施网络相比，Ad hoc网络中并没有AP这样的设备，可扩展性和灵活性更好，但路由和协调控制等技术都难以解决。

2. IEEE 802.11标准

定义了媒体访问控制层MAC层和物理层。物理层定义了工作在2.4GHz的ISM（工业、科学和医学）频段上的扩频通信方式，总数据传输速率设计为2Mbps。而MAC层采取了载波侦听多路访问/冲突避免协议CSMA/CA，级采用主动避免碰撞而非被动侦测的方式来解决冲突问题。

IEEE 802.11的业务主要限于数据存取，在速率和传输距离上都不能满足人们的需要，因此，IEEE在制定更高速度的标准时，救产生了802.11a和802.11b两个分支，后来又陆续推出了802.11g、802.11n、802.11ac的标准，主要是以物理层的不同作为区分，它们的区别直接表现在工作频段和数据传输率、最大传输距离等指标上。而工作在MAC层的标准又分为802.11h、802.11e和802.11i。802.11h是802.11a的扩展，目的是兼容其他5GHz频段的标准；802.11e是IEEE为满足QoS方面的要求而制定的标准，IEEE 802.11i规定使用802.1x认证和密码管理方式。

3. 3G通信技术

主流标准包括：WCDMA、CDMA2000和TD-SCDMA。

• WCDMA，宽频CDMA。支持者主要是GSM（全球移动通信系统）为主的欧洲厂商，中国联合网络通信集团公司。
• CDMA 2000，中国电信集团公司。
• TD-SCDMA，中国移动通信集团公司。

4. 4G通信技术

是第四代移动通信及其技术的简称，是集3G和WLAN与一体并能传输高质量视频图像且图像传输质量与高清晰度电视不相上下的技术产品。

4G标准主要有两大方向，即LTE与WiMAX，而LTE又可进一步分为TD-LTE和FDD-LTE。

1. TD-LTE 分时长期演进
   TDD即时分双工，是移动通信技术使用的双工技术之一，与FDD频分双工向对应。TD-LTE与TD-SCDMA实际上没有关系，TD-LTE是TDD版本的LTE的技术，FDD-LTE的技术是FDD版本的LTE技术。TD-SCDMA是CDMA（码分多址）技术，TD-LTE是OFDM（正交频分复用）技术。两者从编解码、帧格式、空口、信令，到网络架构，都不一样。
2. FDD-LTE 频分双工长期演进
3. WiMAX 全球微波互联接入
   另一个名字是IEEE 802.16。
   802.16工作的频段采用的是无需守全频段，范围在2GHz至66GHz，而802.16a则是一种采用2GHz至11GHz无需授权频段的宽带无线接入系统，其频道带宽可以根据需求在1.5M至20MHz范围进行调整。WiMAX具有如下优点：
   
   • 对于已知的干扰，窄的信道带宽有利于避开干扰，而且有利于节省频谱资源。
   • 灵活的带宽调整能力，有利于运营商或用户协调频谱资源。
   • WiMAX所能实现的50公里的无线信号传输距离是无线局网所不能比拟的，网络覆盖面积是3G发射塔的10倍，只要少数基站建设就能实现全城覆盖，能够使无线网络的覆盖面积大大提升。
     不过WiMAX网络在网络覆盖面积和网络的带宽上优势很大，但是其移动性却有着先天的缺陷，无法满足高速（>=50km/h）下的网络的无缝链接。

4.2.3 广域网技术

主要提供面向通信的服务，支持用户使用计算机进行远距离的信息交换。

4.2.4 网络接入技术

目前，接入Internet的主要方式又有PSTN、ISDN、ADSL、FTTx+LAN和HFC接入等五种

1. PSTN接入 公用交换电话网络

是指利用电话线拨号接入Internet，通常计算机需要安装一个Modem调制解调器，将电话线插入到Modem上，在计算机上利用拨号程序输入号码进行接入。PSTN速度较低，一般低于64Kbps。

2. ISDN接入 综合业务数字网

是在电话网络的技术上构造的纯数字方式的综合业务数字网。

3. ADSL接入 非对称数字用户线路

服务端设备和用户端设备之间通过普通的电话线连接，无需对入户线缆进行改造。特点是上行速度和下行速度不一样，并且往往是下行速度大于上行速度。

4. FTTx+LAN接入

光纤通信指利用光导纤维传输光波信号的一种通信方法，相对于以电为媒介的通信方式而言，光纤通信的主要优点有传输频带宽、通信容量大、船速损耗小、抗电磁干扰能力强、线径细、重量轻、资源丰富等。

1. FTTx技术
   根据光纤深入用户的程度，可以分为五种：分别为FTTC光纤到路边、FTTZ光纤到小区、FTTB光纤到楼，FTTF光纤到楼层、FTTH光纤到户。
2. 无源光纤网络（PON）技术。是实现FFTB的关键技术，在光分支点不需要节点设备，只需安装一个简单的光分支器即可，因此，具有节省光缆资源、带宽资源共享、节省机房投资、设备安全性高、建网速度快和综合建网成本低等优点。

5. 同轴+光纤接入

同轴光纤技术HFC是将光线铺设到小区，然后通过光电转换节点，利用有线电视CATV的总线式同轴电缆连接到用户，提供综合电信业务的技术。这种方式充分利用CATV原有的网络，由于其建网快、造价低等特点，逐渐成为最佳的接入方式之一。一般光线干线网采用星形结构，同轴电缆分配网采用树形结构。

4.3 网络互连与常用设备

网络互连是为了将两个以上具有独立自治能力、同构或异构的计算机网络连接起来，实现数据流通，扩大资源共享的范围，或者容纳更多的用户。

1. 网络互连设备

在网络互连时，各节点一般不能简单的直接相连，而是需要通过一个中间设备来实现。

互联设备	工作层次	内容	主要功能
中继器	物理层	实现物理层协议转换，在电缆间转换二进制信号	对接收信号进行再生和发送，只起到扩展传输距离的作用，对高层协议是透明的，但使用个数有限（例如，在以太网中只能使用4个）
网桥	数据链路层	实现物理层和数据链路层协议转换	根据帧物理地址进行网络之间的信息转发，可缓解网络通信繁忙度，提高效率。只能够连接相同的MAC层的网络。
路由器	网络层	实现网络层和以下各层协议转换	通过逻辑地址进行网络之间的信息转发，可完成异构网络之间的互联互通，只能连接使用相同网络层协议的子网。
网关	高层（第4~7层）	提供从最底层到传输层或以上各层的数据转换	最复杂的网络互联设备，用于连接网络层以上执行不同协议的子网。
集线器	物理层		多端口中继器
二层交换机	数据链路层		是指传统意义上的交换机，多端口网桥
三层交换机	网络层		带路由功能的二层交换机
多层交换机	高层（第4~7层）		带协议转换的交换机。

2. 交换技术

在计算机网络中，当用户较多而传输的距离较远时，通常不采用两点固定连接的专用线路，而是采用交换技术，使通信传输线路为各个用户公用，提高传输设备的利用率，降低系统费用。交换技术的分类和主要特点如下：

1. 电路交换。在数据传送之前必须先设置一条通路。在线路释放之前，该通路将由一对用户独占。
2. 报文交换。报文从源点传送到目的地采用存储转发的方式，在传送报文时，同时只占用一段通道。在交换节点中需要缓冲存储，报文需要排队。因此报文交换不能满足实时通信的要求。
3. 分组交换。同报文交换方式类似，但报文被分成分组传送，病规定了最大的分组长度。在数据报分组交换中，目的地需要重新组装报文；在虚电路分组交换中，在数据传送之前必须通过虚呼叫设置一条虚电路。分组交换在数据网络中使用最广。

3. 路由技术

工作在Internet上的路由器也成为IP网关。

路由器的主要功能就是进行路由选择。当一个网络中的计算机要给另一个网络中的计算机发送分组时，它首先将分组送到同一个网络中用于网络之间连接的路由器，路由器根据目的地址信息，选择合适的路由，将该分组传递到目的网络用于网络之间连接的路由器中，然后通过目的网络中内部使用的路由选择协议，该分组最后被递交给目的计算机。

根据路由选择协议的应用范围，可以将其分为内部网关协议IGP、外部网关协议EGP和核心网关协议GGP三大类。

1. 内部网关协议。是指在一个自治系统AS内运行的路由选择协议，主要包括RIP（路由信息协议）、OSPF（开放式最短路径优先）、IGRP（内部网关路由协议）和EIGRP（增强型IGRP）等。其中AS指同构性的网关连接的互联网络，通常是由一个网络管理中心控制的。
2. 外部网关协议。指两个AS之间使用的路由选择协议，最新的EGP有BGP（边界网关协议），其主要功能是控制路由策略。
3. 核心网关协议。Internet中有个主干网，所有的AS中都连接到主干网上，主干网中的网关称为核心网关，核心网关之间交换路由信息时使用的是GGP。

从路由协议使用的算法来看，所有的路由协议可以分为以下三类：

1. 距离向量协议。计算机网络中所有链路的矢量和距离，并以此为依据来确定最佳路径。这类协议会定期向相邻的路由器发送全部或部分路由表。
2. 链路状态协议。使用为每个路由器创建的拓扑数据库来创建路由表，通过计算最短路径来形成路由表。这类协议会定期向相邻路由器发送网络链路状态信息。
3. 平衡型协议。结合了距离向量协议和链路状态协议的优点。

4.4 网络工程

4.4.1 网络规划

1. 网络需求分析

需求分析包含以下几个方面：

1. 功能需求
2. 通信需求。指了解用户需要的通信类型、通信频度、通信时间和通信量等。
3. 性能需求。包括容量（带宽）、利用率、最优利用率、吞吐率、可提供负载、准确度、效率、延迟（等待时间）、延时变化量、响应时间、最优网络利用率、端到端的差错率、精确度和网络效率等。
4. 可靠性需求。包括精确度、错误率、稳定性、无故障时间、数据备份等几个方面。
5. 安全需求，可用性、完整性和保密性。
6. 运行和维护需求。
7. 管理需求。包括用户管理、资源管理、配置管理、性能管理和网络维护。

2. 可行性研究

通常从技术可行性、经济可行性、法律可行性和用户使用可行性等方面进行论证。

3. 对现有网络的分析与描述

如果是在现有网络系统的基础上进行升级，那么需要分析现有网络，分析包含以下几个方面：

1. 服务器的数量和位置。
2. 客户机的数量和位置。
3. 同时访问的数量。
4. 每天的用户数
5. 每次使用的时间
6. 每次数据传输的数据量。即每笔业务所产生的数据流量。
7. 网络拥塞的时间段。
8. 采用的协议
9. 通信模式

综合对现有网络系统的调研与分析，并在其基础上进行新的网络规划，能够通过以下措施更有效的保证用户的原始投资：

1. 不要推倒重来，要基于现有设备的基础上进行升级和改造。
2. 将现有的设备降级使用，并新增更先进的设备，以提高网络的性能。

4.4.2 网络设计

网络设计的工作是在网络规划的基础上，设计一个能够解决用户问题的方案。在整个设计过程中，首先要确定网络总体目标和设计原则，然后设计网络的逻辑结构，再设计网络的物理结构。

1. 网络逻辑结构设计

是体现网络设计核心思想的关键阶段，在这一阶段根据需求规范和通信规范，选择一种比较适宜的网络逻辑结构，并基于该逻辑结构实施后续的资源分配规划、安全规划等内容。

在逻辑网络设计阶段，需要描述满足用户需求的网络行为和性能，详细说明数据是如何在网络上传输的，此阶段不涉及网络元素的具体网络位置。

此阶段最后应该得到一份逻辑网络设计文档，输出的内容包括以下几点：

1. 逻辑网络设计图
2. IP地址方案
3. 安全方案
4. 具体的软件、硬件、广域网连接设备和基本的服务
5. 雇佣和培训新网络员工的具体说明
6. 初步对软件、硬件、服务、网络雇佣员工和培训的费用估计。

2. 网络物理结构设计

是对逻辑网络设计的物理实现，通过对设备的具体物理分布、运行环境等的确定，确保网络的物理连接符合逻辑连接的要求。在这一阶段，网络设计者需要确定具体的软硬件、连接设备、布线和服务。

输出的内容如下：

1. 物理网络图和布线方案
2. 设备和部件的详细列表清单
3. 软件、硬件和安装费用的估计
4. 安装日程表，用以详细说明实际和服务中断的时间和期限
5. 安装后的测试计划
6. 用户培训计划

3. 分层设计

三个关键层分别为：核心层、汇聚层和接入层。通常将网络中直接面向用户连接或访问网络的部分称为接入层，将位于接入层和核心层之间的部分称为分布层或汇聚层。

接入层的目的是允许终端用户连接到网络，因此，接入层交换机具有低成本和高端口密度特性。

汇聚层完成网络访问策略控制、数据包处理、过滤、寻址，以及其他数据处理的任务。汇聚层交换机是多台接入层交换机的汇聚点，它必须能够处理来自接入层设备的所有通信量，并提供到核心层的上行链路，因此，汇聚层交换机与接入层交换机比较，需要更高的性能，更少的接口和更高的交换速率。

网络主干部分称为核心层，主要目的在于通过高速转发通信，提供优化、可靠的骨干传输结构，因此，核心层交换机应拥有更高的可靠性、性能和吞吐量。在纯粹的分层设计中，核心层只完成数据交换的特殊任务。在主干网中，考虑到高可用性的需求，通常会使用双星（树）结构，即采用两台相同的交换机，与汇聚层交换机分别连接，并使用链路聚合技术实现双机互联。

4.4.3 网络实施

是在网络设计的基础上进行设备的购买、安装、调试和系统切换工作。主要包括以下步骤：

1. 工程实施计划。
2. 网络设备到货验收
3. 设备安装
4. 系统测试
5. 系统试运行
6. 用户培训
7. 系统转换。系统转换可以采用三种方法，分别是直接转换、并行转换和分段转换。

4.5 网络存储技术

1. 直接附加存储 DAS

是将存储设备通过SCSI（小型计算机系统接口）电缆直接连到服务器，其本身是硬件的堆叠，存储设备依赖于服务器，不带有任何存储操作系统。因此，DAS又称SAL（服务器附加存储）。DAS的适用范围为：

1. 服务器在地理分布上很分散，通过SAN或NAS在他们之间进行互连非常困难。
2. 存储操作系统必须直接连接到应用服务器上时。
3. 包括许多数据库应用和应用服务器在内的应用，他们需要直接连接到存储器上时。

由于DAS直接将存储设备连接到服务器上，这导致它在传输距离、连接数量、传输速率方面都受到限制。因此，当存储容量增加时，DAS方式很难扩展，这对存储容量的升级是一个巨大的瓶颈；另一方面，由于数据库的读取都要通过服务器来处理，必然导致服务器的处理压力增大，数据处理和传输能力将大大降低。此外，当服务器出现宕机等异常状况时，也会波及存储数据，使其无法使用。目前DAS基本被NAS所代替。

2. 网络附加存储 NAS

采用NAS技术的存储设备不再通过I/O总线附属于某个特定的服务器，而是通过网络接口与网络直接相连，由用户通过网络访问。类似于一个专门的文件服务器。

NAS以数据为中心，将存储设备与服务器分离，其存储设备在功能上完全独立于网络中的主服务器，客户机与存储设备之间的数据访问不再需要文件服务器的敢于，同时它允许客户机与存储设备之间进行直接的数据访问，所以不仅响应速度快，而且数据传输速率也很高。

NAS支持多种TCP/IP协议，主要是NFS（网络文件系统）和CIFS（通用Internet文件系统）来进行文件访问，所以NAS的性能特点是进行小文件级的共享存取。在具体使用时，NAS设备通常配置为文件服务器，通过使用基于Web的管理界面来实现系统资源的配置、用户配置管理和用户访问登录等。

NAS存储支持即插即用，可以在网络的任一位置建立存储。基于Web管理，从而使设备的安装、使用和管理更加容易。NAS可以很经济的解决存储容量不足的问题，但难以获得满意的性能。

3. 存储区域网络 SAN

是通过专用交换机将磁盘阵列与服务器连接起来的高速专用子网。它没有采用文件共享存取方式，而是采用块（block）级别存储。是通过专用高速网络讲一个或多个网络存储设备和服务器连接起来的专用存储系统，其最大特点是将存储设备从传统的以太网中分离出来，称为独立的存储区域网络。

根据数据传输过程采用的协议，其技术划分为FC SAN和IP SAN。另外，还有一种新兴的IB SAN技术。

1. FC SAN。FC（光纤通道）和SCSI一样，原先是换门为网络系统设计的，但是随着存储系统对速度的需求，才逐渐应用到磁盘系统中。光纤通道的主要特性有：热插拔性、高速带宽、远程连接、连接设备数量大灯。
   FC SAN由三个基本的组件构成：接口（SCSI、FC）、连接设备（交换机、路由器）和协议（IP，SCSI）。这三个组件再加上附加的存储设备和服务器就构成一个SAN系统，它是专用、高速、高可用的网络，允许独立、动态的增加存储设备，使得管理和集中控制更加简化。
   FC SAN有两个较大的缺陷，分别是成本高和复杂性，其原因就是因为使用了FC。
2. IP SAN。是基于IP网络实现数据块级别存储方式的存储网络。由于设备成本低，配置技术简单，可以共享和使用大容量的存储空间，因而逐渐获得好评。
   在具体应用上，IP存储主要是指ISCSI（Internet SCSI），ISCSI基于IP网络实现SAN架构，既具备了IP网络配置和管理简单的优势，又提供了SAN架构所拥有的强大功能和扩展性。ISCSI是连接到一个TCP/IP网络的直接寻址的存储库，通过使用TCP/IP协议对SCSI指令进行封装，可以使指令能够通过IP网络进行传输，而过程完全不依赖于地点。

ISCSI优势的主要表现在于，首先，建立在SCSI、TCP/IP这样稳定和熟悉的标准上，安装成本和维护成本都很低；其次，ISCSI支持一般的以太网交换机而不是特殊的光纤通道交换机，减少了异构网络和电缆；最后，ISCSI通过IP传输存储命令，因此可以在整个Internet上传输，没有距离限制。

ISCSI缺点在于，存储和网络是同一个物理结构，同时协议本身的开销很大，协议本身需要频繁的将SCSI命令封装到IP包中以及从IP包中将SCSI命令解析出来，这两个因素都造成了贷款的占用和主处理器的负担。

4.6 综合布线

是一种模块化的、灵活性极高的建筑物内或建筑物之间的信息传输通道。

综合布线系统可以分为七个部分：

1. 工作区。一个独立的需要设置终端设备的区域宜划分为一个工作区。工作区应由配线子系统的信息插座模块延伸到终端设备处的连接缆线及适配器组成。
2. 配线子系通。应由工作区的信息插座模块、信息插座模块至电信间配线设备的配线电缆和光缆、电信间的配线设备及设备线缆和跳线等组成。
3. 干线子系统。应由设备间至电信间的干线电缆和光缆，安装在设备间的建筑物配线设备及设备线缆和跳线组成。
4. 建筑群子系统。应由连接多个建筑物之间的主干线缆和光缆、建筑群配线设备及设备缆线和跳线组成。
5. 设备间。是在每幢建筑物的适当地点进行网络管理和信息交换的场地。对于综合布线系统工程设计，设备间主要是用来安装建筑物配线设备。电话交换机、计算机主机设备及入口设施也可与配线设备安装在一起。
6. 进线间。是建筑物外部通信和信息管线的入口部位，并可作为入口设施和建筑群配线设备的安装场地。
7. 管理。应对工作区、电信间、设备间、进线间的配线设备、缆线、信息插座模块等设施，按一定的模式进行标识和记录。

第五章 系统性能评价

5.1 性能指标

5.1.1 计算机

对计算机评价的主要性能指标如下：

1. 时钟频率（主频）

也就是主时钟的脉冲频率，现在还需要内核数。

2. 高速缓存

3. 运算速度

单位一般用MIPS（百万条指令/秒）和MFLOPS（百万次浮点运算/秒）。MIPS用于描述计算机的定点运算能力；MFLOPS则用来标识计算机的浮点运算能力。

4. 运算精度

取计算机处理信息时能直接处理的二进制数据的位数，位数越多，精度救越高。参与运算的数据的基本位数通常用基本字长来表示。

5. 内存的存储容量

内存的容量越大，可存储的数据和程序就越多，从而减少与磁盘信息交换的次数，使运行效率得到提高。

6. 内存的存取周期

内存完成一次读（取）或写（存）操作所需要的时间称为存储器的存取时间或者访问时间，而连续两次读（或写）所需的最短时间称为存储周期，存储周期越短，表示从内存存取信息的时间越短，系统的性能也就越好。

7. 数据处理速率

数据处理速度PDR的计算公式为：$PDR=L/R$。其中：
$L=0.85G+0.15H+0.4J+0.15K$，
$R=0.85M+0.09N+0.06P$

• G是每条定点指令的位数；
• H是每条浮点指令的位数；
• J是定点操作数的位数；
• K是浮点操作数的位数；
• M是平均定点加法时间；
• N是平均浮点加法时间；
• P是平均浮点乘法时间。

另外还规定，G>20位，H>30位；从主存中去一条指令的时间等于取一个字的时间；指令和操作数都存放在同一个主存，无变址或间址操作；允许有先行或并行取指令功能，此时选用平均取指令时间。

8. 响应时间

• 0.1秒，用户感觉不到任何延迟。
• 1.0秒，用户愿意接受的系统立即响应的时间极限。即当执行一项任务的有效反馈时间在0.1~1秒之间，用户都是愿意接受的。超过此数据值，则意味着用户会感觉到有延迟，但是只要不超过10秒，用户还是可以接受的。
• 10秒，用户保持注意力执行本次任务的极限，如果超过此数值仍然得不到有效的反馈，客户会在等待计算机完成当前操作时转向其他的任务。

9. RASIS特性

RASIS特性是可靠性（Reliability）、可用性（Availability）、可维护性（Serviceability）、完整性（Integraity）和安全性（Security）五者的统称。

10. 平均故障响应时间

TAT，即从出现故障到该故障得到确认修复前的这段是时间。该指标反映的是服务水平。

11. 兼容性

5.1.2 网络

1. 设备级性能指标。计算机网络设备（主要指路由器）的标准性能指标主要包括吞吐量（信道的最大吞吐量为“信道容量”）、延迟、丢包率和转发速度等。
2. 网络级性能指标。可达性、网络系统的吞吐率、传输速率、信道利用率、信道容量、带宽利用率、丢包率、平均传输延迟、平均延迟抖动、延迟/吞吐量的关系、延迟抖动/吞吐量的关系、丢包率/吞吐量的关系等。
3. 应用级性能指标。QOS、网络对语言应用的支持程度、网络对视频应用的支持程度、延迟/服务质量的关系、丢包率/服务质量的关系、延迟抖动/服务质量的关系等。
4. 用户级性能指标。可靠性和可用性。
5. 吞吐量。在没有帧丢失的情况下，设备能够接受的最大速率。

5.1.3 操作系统

1. 系统的可用性
2. 系统的吞吐量。指系统在单位时间内所处理的信息量，以每小时或每天所处理的各类作业的数量来度量。
3. 系统响应时间，指用户从提交作业到得到计算结果这段时间，又称周转时间。
4. 系统资源利用率。指系统中各部件、各设备的使用程度。它用在给定时间内，某一设备实际使用时间所占的比例来度量。
5. 可移植性

5.1.4 数据库管理系统

1. 数据库描述功能，定义数据库的全局逻辑结构，局部逻辑结构和其他各种数据库对象。
2. 数据库管理功能。包括系统配置与管理，数据存取与更新管理，数据完整性管理和数据安全性管理、
3. 数据库的哈讯和操纵功能，包括数据库检索和修改。
4. 数据库维护功能。包括数据库引入引出功能，数据库结构维护，数据恢复功能和性能监测。

因此，衡量数据库管理系统的主要性能指标包括数据库本身和管理系统两部分。

数据库和数据库管理系统的性能指标包括数据库的大小、单个数据库文件的大小、数据库中表的数量、单个表的大小，表中允许的记录（行）数量、单个记录（行）的大小、表上所允许的索引数量、数据库所允许的索引数量、最大并发事务处理能力、负载均衡能力，最大连接数。

5.1.5 Web服务器

最大并发连接数、响应延迟、吞吐量（每秒处理的请求数）、成功请求数、失败请求数、每秒点击次数、每秒成功点击次数、每秒失败点击次数、尝试连接数、用户连接数等。

5.2 性能计算

性能指标计算的主要方法有：定义法、公式法、程序检测法、仪器检测法。定义法主要根据其定义直接获取其理想数据，公式法一般适用于根据基本定义所衍生出的复合性能指标的计算，而程序检测法和仪器检测法则是通过实际的测试来得到其实际值。

1. MIPS的计算方法

$$MIPS=\frac{指令条数}{执行时间\times10^6}=\frac{F_z}{CPI}=IPC\times F_z$$

公式中，$F_z$为处理机的工作主频，CPI为每条指令所需的平均时钟周期数，IPC为每个时钟周期平均执行的指令条数。

2. 峰值计算

衡量计算机性能的一个重要指标就是计算峰值或者浮点计算峰值，他是计算机每秒钟能够完成的浮点计算最大次数。包括理论浮点峰值和实测浮点峰值。

理论浮点峰值是该计算机理论上能够达到的每秒钟能完成浮点计算最大次数，它主要是由CPU的主频决定。

$$理论浮点峰值=CPU主频\times CPU每个时钟周期执行浮点运算的次数\times 系统中CPU数$$

CPU每个时钟周期执行浮点运算的次数是由处理器中浮点运算单元的个数及每个浮点运算单元在每个时钟周期能处理几条浮点运算决定的。

3. 等效指令速度

静态指令使用频度指的是程序中直接统计的计算机速度。动态指令使用频度指的是在程序执行过程中统计的指令速度。

5.3 性能设计

5.3.1 阿姆达尔解决方案

阿姆达尔定律是这样的：系统中对某部件采用某种更快的执行方式，所获得的系统性能的改变程度，取决于这种方式被使用的频率，或所占总执行时间的比例。

阿姆达尔定律定义了采用特定部件所取得的加速比。

加速比反映了使用增强部件之后完成一个任务比不使用增强部件完成同一任务加快了多少。加速比主要取决于两个因素：

1. 在原有的计算机上，能被改进并增强的部分在总执行时间中所占的比例。这个值，称为增强比例，它永远小于等于1.
2. 通过增强的执行方式所取得的改进，即如果整个程序使用了增强的执行方式，那么这个任务的执行速度会有多少提高，这个值是在原来条件下程序的执行时间与使用增强功能后程序的执行时间之比。

5.3.2 负载均衡

由多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，都可以单独对外提供服务而无需其他服务器的辅助。通过某种负载分担技术，将外部发来的请求均匀的分配到对称结构中的某一台服务器上，而接收到请求的服务器独立的回应客户的请求。

1. 负载均衡技术的类型

1. 基于特定服务器软件的负载均衡，如网络协议中的重定向功能。
2. 基于DNS的负载均衡。通过DNS服务红的随机名字解析来实现负载均衡。
3. 反向代理负载均衡。使用代理服务器可以将请求转发给内部的Web服务器，使用这种加速模式可以提升静态网页的访问速度。
4. 基于NAT（网络地址转化）的负载均衡技术。网络地址转换指的是在内部地址和外部地址之间进行转换，以便具备内部地址的计算机能访问外部网络，而当外部网络中的计算机访问地址转换网关拥有的某一外部地址时，地址转换网关能将其转发到一个映射的内部地址上。
5. 扩展的负载均衡技术。即使用半中心的负载均衡方式，当客户请求发送给负载均衡器的时候，中心负载均衡器将请求打包并发送给某个服务器，而服务器的回应请求不再返回给中心负载均衡器，而是直接返回给客户，因此中心负载均衡器只负责接受并转发请求，其网络负担就较小了。

2. 服务器负载均衡

一般用于提供服务器的整体处理能力，并提高可靠性、可用性和可维护性，最终目的是加快服务器的响应速度，从而提高用户的体验度。

负载均衡从结构上分为本地负载均衡和全域负载均衡，前者是指对本地的服务器群做负载均衡，后者是指对分别放置在不同的地理位置、有不同的网络及服务器群之间做负载均衡。

全域负载均衡具有以下特点：

1. 解决网络拥塞问题，服务就近提供，实现地址位置无关性；
2. 对用户提供更好的访问质量；
3. 提高服务器响应速度；
4. 提高服务器及其他资源的利用效率；
5. 避免了数据中心单点失效。

5.4 性能评估

是对一个系统进行各项检测，并形成一份直观的文档。

5.4.1 基准测试程序

把应用程序中用得最多、最频繁的那部分核心程序作为评价计算机性能的标准程序。称为基准测试程序。

1. 证书测试程序：Dhrystone。用C语言编写，100条语句。包括：各种赋值语句、各种数据类型和数据区、各种控制语句、过程调用和参数传送、整数运算和逻辑运算。
2. 浮点测试程序：Linpack。用FORTRAN语言编写，主要是浮点加法和浮点乘法操作。用MFPOPS表示GFLOPS、TFLOPS。
3. Whetstone基准测试程序。用FORTRAN语言编写的综合性测试程序，主要包括：浮点运算、整数算数运算、功能调用、数组变址、条件转移、超越函数。测试结果用Kwips表示。
4. SPEC基准测试程序。
5. TPC基准测试程序
6. Linpack测试。是国际上最流行的用于测试高性能计算机系统浮点性能的测试。通过对高性能计算机采用高斯消元法求解一元N次稠密线性代数方程组的测试，评价高性能计算机的浮点性能。

5.4.2 Web服务器的性能评估

在测试中，能够反应其性能的主要包括最大并发连接数、响应延迟和吞吐量几个参数。

现在常见的Web服务器性能评估方法有基准性能测试、压力测试和可靠性测试。基准测试即采用前面所提到的各种基准程序对其进行测试；压力测试则是采用一些测试工具来测试Web服务器的一些性能指标，如最大并发连接数，间接测试响应时间，以及每秒可以处理的请求数目。

5.4.3 系统监视

目标是为了评估系统性能。要监视系统性能，需要收集某个时间段内的3中不同类型的性能数据。

1. 常规性能数据。
2. 比较基准的性能数据。
3. 服务水平报告数据。

第六章 开发方法

6.1 软件生命周期

软件生命周期划分为8个阶段：可行性研究与计划、需求分析、概要设计、详细设计、实现、集成测试、确认测试、使用和维护。

1. 可行性研究与计划：通过可行性研究，来确定开发软件的必要性，并根据可行性研究的结果初步确定软件的目标、范围、风险、开发成本等内容。该阶段会产生《可行性研究报告》和《软件开发计划》，并进入需求分析的阶段。
2. 需求分析：是软件开发的重要阶段。
3. 概要设计：负责将需求分析的结果转化为技术层面的设计方案。在概要设计中，需求确定系统架构、各子系统间的关系、接口规约、数据库模型、编码规范等内容。概要设计的结果将做为程序员的工作指南，供程序员了解系统的内部原理，并在其基础上进行详细设计和编码工作。
4. 详细设计：完成编码前的最后设计，详细设计在概要设计的基础上，进行细化，如类设计。不是必须的阶段。
5. 实现：包括编码和单元测试。
6. 集成测试：又称为组装测试。
7. 确认测试：验证软件是否同需求一致，是否达到了预期目标。
8. 使用和维护：在使用过程中不断进行维护和修改。当使用和维护阶段结束后，软件系统也就自然消亡，软件系统的生命周期结束。

6.2 软件开发模型

6.2.1 瀑布模型

1. 瀑布模型的核心思想

开发过程中，软件要经过需求分析、总体设计、详细设计、编码、调试、集成调试和系统测试阶段才能被准确的实现。而且每个阶段都有回到前一级的反馈线，指的是，在软件开发中当在后续阶段发现缺陷的时候，可以把这个缺陷反馈到上一阶段进行修正。

瀑布模型的一个重要特点是：软件开发的阶段划分是明确的，一个阶段到下一个阶段有明显的界限。在每个阶段结束后，都会有固定的文档或源程序流入下一阶段。在需求分析阶段结束后，需要有明确的描述软件需求的文档；总体设计结束后，需要有描述软件总体结构的文档；详细设计结束后，需要有可以用来编码的详细设计文档；而编码结束后，代码本身被作为文档流到下一阶段。因此也成瀑布模型为面向文档的软件开发模型。

2. 瀑布V模型

整个瀑布模型在编码与调试阶段转了个弯，形成了一个对称的V字。瀑布V模型同标准瀑布模型一样，在进行完需求分析后就将进入总体设计阶段，但是除总体设计外，需要分析还有一条虚线指向系统测试。这指的是，需求分析的结果将作为系统测试的准则，即需求分析阶段也将产生通软件需求一致的系统测试；同时软件产品是否符合最初的需求也将在系统测试阶段得到验证。以此类推，总体设计对应了集成测试，详细设计对应了单元测试。瀑布V模型不但保持了瀑布模型的阶段式文档驱动的特点，而且更强调了软件产品的验证工作。

3. 瀑布模型的缺点

首先，在瀑布模型中，需求分析阶段是一切活动的基础，设计、实现和验证活动都是从需求分析的结果到处的。一旦需求分析的结果不完全正确，存在偏差，那么后续的活动只能放大这个偏差。所以瀑布模型后期的维护工作相当繁重，而这些维护工作大多都是修正在需求分析阶段引入的缺陷。

其次，瀑布模型难以适应变化。在瀑布模型中精确地定义了每一个阶段的活动和活动结果，而每一阶段都紧密依赖于上一阶段的结果。如果在软件的后期出现了需求的变化，整个系统又要从头开始。

再次，使用瀑布模型意味着当所有阶段都结束才能最终交付软件产品，所以在提出需求后，需要相当长的一段时间的等待才能够看到最终结果，才能发现软件产品究竟能不能满足客户的需求。

最后，文档驱动型的瀑布模型除了制造出软件产品外还将产生一大堆的文档，大部分的文档对客户没有任何意义，但是完成这些对客户没有意义的文档却需要花费大量的人力。所以瀑布模型也是一种重载模型。

6.2.2 演化模型

一般情况下，一个演化模型可以看做若干次瀑布模型的迭代，当完成一个瀑布模型后，重新进入下一个迭代周期，软件在这样的迭代过程中得以演化、完善。根据不同的迭代特点，演化模型可以演变为螺旋模型、增量模型和原型法开发。

6.2.3 螺旋模型

螺旋模型将瀑布模型和演化模型结合起来，不仅体现了两个模型的优点，而且还强调了其他模型军忽略了的风险分析。螺旋模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段。

螺旋模型的基本做法实在瀑布模型的每一个开发阶段前，引入一个非常严格的风险识别、风险分析和风险控制。它把软件项目分解成一个个小项目，每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。

螺旋模型特别适用于庞大而复杂、具有高风险的系统。

与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高目标软件的适应能力，为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发风险。

但是，不能说螺旋模型绝对比其他模型优越，事实上，螺旋模型也有其自身的缺点：

1. 采用螺旋模型，需要具有相当丰富的风险评估经验和专业知识。在风险较大的项目开发中，如果未能及时标识风险，势必会造成重大损失。
2. 过多的迭代次数会增加开发成本，延迟提交时间。

6.2.4 增量模型

对于增量模型，通常有两种策略。一个是增量发布的方法。即首先做好系统的分析和设计工作，然后将系统划分为若干不同的版本，每一个版本都是一个完整的系统，后一版本以前一个版本为基础进行开发，扩充前一版本的功能。在这种策略中，第一版本旺旺是系统的核心功能，可以满足用户最基本的需求，随着增量的发布，系统的功能逐步的丰富、完善起来。用户在很短的时间内救可以得到系统的初始版本并进行试用，试用中的问题可以很快的反馈到后续开发中，从而降低了系统的风险。在应用增量模型中需要注意：

1. 每一个版本都是一个完整的版本。虽然最初的几个增量不能完全的实现用户需求，但这些版本都是完整的、可用的。
2. 版本间的增量要均匀，这一点是很重要的。

另一种策略是原型法。同增量发布不同，原型法的每一次迭代都经过一个完整的生命周期，当用户需求很不明确或技术架构中存在很多不可知因素的时候，可以采用原型法。在初始的原型中，针对一般性的用户需求进行快速实现，并不考虑算法的合理性或系统的稳定性。这个原型的主要目的是获得精确的用户需求，或验证架构的可用性。一般情况下，会在后面的开发中抛弃这个原型，重新实现完整的系统。

6.2.5 构件组装模型

在构件组装模型中，当经过需求分析定义出软件功能后，将对构件的组装结构进行设计，将系统划分成一组构件的集合，明确构建之间的关系。在确定了系统构件后，则将独立完成每一个构件，这是既可以开发软件构件，也可以重用已有的构件，当然也可以购买或选用第三方的构件。构件是独立的、自包容的，因此架构的开发也是独立的，构建之间通过接口相互合作。

优点如下：

1. 构建的自包容性让系统的扩展变得更加容易
2. 设计良好的构件更容易被重用，降低软件开发成本
3. 构件的粒度较整个系统更小，因此安排开发任务更加灵活，可以将开发团队分成若干组，并行的独立开发构件。

缺点如下：

1. 对构件的设计需要经验丰富的架构设计师，设计不良的构建难以实现构件的优点，降低构建组装模型的重用度
2. 在考虑软件的重用度时，往往会对其他方面做出让步，如性能等。
3. 使用构件组装应用程序时，需要程序员熟练地掌握构件，增加了研发人员的学习成本。
4. 第三方构件库的质量会最终影响到软件的质量，而第三方构件库的质量往往是开发团队难以控制的。

6.3 统一过程 UP

1. UP的二维模型

• 在初始阶段，开发者刚刚接入系统，此时最重要的工作是界定系统范围，明确系统目的。在这一阶段，业务建模和需求工作成了重头戏。
• 在细化阶段，开发者需要抽象出软件的逻辑模型，设计出软件的架构，在这一阶段，分析设计工作是最主要的工程活动。
• 在构建阶段，开发者需要基本完成系统的构建，使之成为一个完整的实体，并进行测试和部署。在这一阶段，实施和测试时最主要的活动。
• 在交付阶段（也称转移阶段），软件系统需求已经完全成熟或产品化，或进入下一个版本。在这一阶段不可避免的要对软件系统进行重构、修改、测试和部署。

对于纵轴而言，业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理、环境称为UP的9个核心工作流。可以把这9个核心工作流进行简单的分类以帮助理解，业务建模、需求、分析设计、实施、测试和部署是工程活动，而配置与变更管理、项目管理和环境是管理活动。

2. UP的生命周期

1. 目标里程碑。对应着先启阶段的结束，当开发者可以明确软件系统的目标和范围时即达到了该里程碑。
2. 架构里程碑。架构里程碑是UP生命周期中的第二个里程碑，在这个里程碑前，开发者需要确定稳定的系统架构。
3. 能力里程碑。当系统已经足够的稳定和成熟并完成Alpha测试后，认为达到了第三个里程碑。
4. 发布里程碑。在达到发布里程碑前，需要完成系统的测试、完成系统发布和用户培训等工作。

在经过这4个里程碑后，即为一个完整的生命周期，开发出一个新的版本。此时可以关闭该产品的开发，也可以迭代进入下一版本。

3. UP的特点

1. UP是一个迭代的二维开发模型，在生命周期的每一阶段都可以进行需求、设计等活动。UP不但给出了迭代的生命周期，还给出了生命周期每一阶段的迭代指南。
2. 采用不同迭代方式的UP可以演变为演化模型或增量模型。
3. UP的迭代特点使得更容易控制软件开发的风险。
4. 虽然UP是一个迭代的开发模型，但UP本身不属于敏捷方法。相反，一般认为，未经裁剪的UP是一个重载过程。
5. 在实际应用中可以根据具体问题对UP进行裁剪，从而使其可以使用各种规模的软件和开发团队。

4. 架构设计师在UP中的活动

在UP中，架构设计师除了需要建立系统架构模型外，还需要：

1. 同需求人员和项目管理人员密切协作。
2. 细化软件架构
3. 保持整个架构的概念完整性。

具体的说，架构设计师不但需要设计系统架构，还需要定义设计方法、设计指南、编码指南、评审设计等工作。因此，也有人称UP是有一个以架构为中心的开发模型。

6.4 敏捷方法

敏捷开发宣言内容：

• 尽早的、持续的向客户交付有价值的软件对开发人员来说是最重要的。
• 拥抱变化，即使在开发的后期。敏捷过程能够驾驭变化，保持客户的竞争力。
• 经常交付可工作的软件，从几周到几个月，时间范围越小越好。
• 在整个项目中，业务人员和开发者紧密合作。
• 围绕士气高昂的团队进行开发，为团队成员提供适宜的环境，满足他们的需要，并给予足够的信任。
• 在团队中，最有效率的、也是效果最好的沟通方式是面对面的交流。
• 可以工作的软件是进度首要的度量方式。
• 可持续的开发。投资人、开发团队和用户应该保持固定的节奏。
• 不断追求优秀的技术和良好的设计有助于提高敏捷性
• 要简单，尽可能减少工作量。减少工作量的艺术是非常重要的。
• 最好的架构、需求和设计都来自于一个自我组织的团队。
• 团队要定期的总结如何能够更有效率，然后相应的自我调整。

6.4.1 极限编程 XP

XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于：

1. 在更短的周期内，更早的提供具体、持续的反馈信息。
2. 迭代的进行计划变编程，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断的发展它。
3. 依赖于自动测试程序来监控开发进度，并及早的捕捉缺陷。
4. 依赖于口头交流、测试和源程序进行沟通。
5. 倡导持续的、演化式的设计。
6. 依赖于开发团队内部的紧密协作。
7. 尽可能达到程序短期利益和项目长期利益的平衡。

XP由价值观、原则、实践和行为四个部分组成。

1. 四大价值观

1. 沟通。XP组合了诸如结对编程这样的最佳实践，鼓励大家进行口头交流、通过交流解决问题，提高效率。
2. 简单。尽量简单化的开发。
3. 反馈。开发过程中必要的反馈，通过持续、明确的反馈来暴露软件状态的问题。
4. 勇气。有勇气面对快速开发。

2. 十二个最佳实践

1. 计划游戏。主要思想是先快速的制定一份概要计划，然后随着项目细节的不断清晰，再逐步完善这份计划。计划游戏产生的结果是一套用户故事及后续的一两次迭代的概要计划。
2. 小型发布。XP方法秉承的是“持续集成、小步快走”的哲学思维，也就是说每一次发布的版本应尽可能的小。由于小型发布可以使得集成更频繁，客户获得的中间结果越频繁，反馈也就越频繁，客户就能实时的了解项目的进展情况，从而提出更多的意见，以便在下一次迭代中计划进去，以实现更高的客户满意度。
3. 隐喻。一种语言的表达手段，它用来暗示字面意思不相似的事物之间的相似之处。隐喻常用于四个方面：寻求共识、发明共享词汇、创新的武器、描述架构。
4. 简单设计。强调简单的价值观，引出了简单性假设原则，落到实处就是“简单设计”实践。XP的简单设计实践并不是要忽略设计，而是认为设计不应该在编码之前一次性完成，因为那样只能建立在“情况不会发生变化”或者“我们可以预见所有的变化”之类的谎言的基础上。
5. 测试先行。
6. 重构。对代码进行改动而不影响功能实现。
7. 结对编程。
8. 集体代码所有制。团队中的每个成员都拥有对代码进行改进的权利，每个人都拥有全部代码，也都需要对全部代码负责。同时，XP强调代码是谁破坏的（修改后出现问题），就应该由谁来修复。
9. 持续集成。
10. 每周工作40小时。
11. 现场客户。在项目中有客户在现场明确用户故事，并作出响应的业务决策。
12. 编码标准。

6.4.2 特征驱动开发 FDD

FDD是一个迭代的开发模型。FDD的每一步都强调质量，不断的交付可运行的软件，并以很小的开发提供精确的项目进度报告和状态信息。

1. FDD角色定义

FDD认为，有效的软件开发不可缺少的三个要素是人、过程和技术。软件开发不能没有过程，也不能没有技术，但软件开发中最重要的是人。FDD定义了6种关键的项目角色：

1. 项目经理。是开发的组织者，但是不是开发的主宰。对于项目团队来说，项目经理应该是团队的保护屏障，他同团队外界（如高层领导、人事甚至写字楼的物业管理员）进行沟通，努力为团队提供一个适宜的开发环境。
2. 首席架构设计师。负责系统架构的设计。
3. 开发经理。负责团队日常的开发，解决开发中出现的技术问题与资源冲突。
4. 主程序员。带领一个小组完成特征的详细设计和构建的工作，一般要求主程序员具有一定的工作经验，并能够带动小组的工作。
5. 程序员。
6. 领域专家

2. 核心过程

1. 开发整体对象模型。也就是业务建模的阶段。不过FDD强调的是系统的完整的面向对象建模，这种做法有助于把握整个系统，而不仅仅关注系统中的若干个点。在这一阶段，领域专家和首席架构设计师相互配合，完成整体对象模型。
2. 构造特征列表。完成系统建模后，需要构造一个完整的特征列表。所谓特征指的是一个小的、对客户有价值的功能。采用动作、结果和膜表来描述特征，特征的粒度最好可以在两周之内实现。在这一阶段中，可以整理出系统的需求。
3. 计划特征开发。这一阶段中，项目经理根据构造出的特征列表、特征间的依赖关系进行计划，安排开发任务。
4. 特征设计。在这一阶段，主程序员将带领特征小组对特征进行详细设计，为后面的构建做准备。
5. 特征构建。特征构建和特征设计这两个阶段合并起来可以看做特征的是现阶段，这两个阶段反复的迭代，直到完成全部的开发。

3. 最佳实践

包括：领域对象建模、根据特征进行开发、类的个体所有、组成特征小组、审查、定期构造、配置管理、结果的可见性。

6.4.3 Scrum

是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周。在Scrum中，使用产品Backlog来管理产品的需求，产品Backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint Backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。

1. Scrum的五个活动

主要包括：产品代办事项列表梳理、Sprint计划会议，每日Scrum会议、Sprint评审会议、Sprint回顾会议等五个活动

1) 产品代办事项列表梳理

包括但不限于以下内容：保持产品代办事项列表有序、把看起来不再重要的事项移除或者降级、增加或提升涌现出来的或变得更重要的事项、将事项分解成更小的事项、将事项合并成更大的事项、对事项进行估算。

梳理时会特别关注那些即将被实现的事项。

2) Sprint计划会议

整个团队都要参加Sprint计划会议。针对排好序的产品代办事项列表，产品负责人和开发团队成员讨论每个事项，并对该事项达成共识，包括根据当前的“完成的定义”，为了完成该事项所需要完成的所有事情。所有的Scrum会议都是限定市场的，推荐的市场是Sprint中的每周对应两小时或者更少。因为会议室定长的，Sprint计划会议的成功十分依赖于产品待办事项列表的质量。

在Scrum中，Sprint计划会议有两部分：

• 决定在Sprint中需要完成哪些工作
• 决定这些工作如何完成

最终产生的待办事项列表就是“Sprint代办事项列表（Sprint Backlog）”

3) 每日Scrum会议

开发团队自组织的。开发团队通过每日Scrum会议来确认他们仍然可以实现Sprint的目标。这个会议每天在同样的时间和同样的地点召开。每一个开发团队成员需要提供一下三点信息：

从上一个每日Scrum到现在，我完成了什么；从现在到下一个每日Scrum，我计划完成什么；有什么阻碍了我的进展。

每日Scrum中可能有简要的问题澄清和回答，但是不应该有任何话题的讨论。通常，许多团队会在每日Scrum之后马上开会处理他们遇到的任何问题。

每日Scrum是Scrum中的一个关键组成部分，它可以带来透明性、信任和更好的绩效。它能帮助快速发现问题，并促成团队的自组织和自立。所有的Scrum会议都是限定时长的。每日Scrum通常不超过15分钟。

4) Sprint评审会议

5) Sprint回顾会议

2. Scrum的5大价值观

• 承诺——愿意对目标作出承诺
• 专注——把你的心思和能力都哟井道你承诺的工作上去
• 开放——Scrum把项目中的一切开放给每个人看
• 尊重——每个人都有他独特的背景和经验
• 勇气——有勇气作出承诺，履行承诺，接受别人的尊重。

6.4.4 水晶方法 Crystal

透明水晶方法具有以下七大体系特征：

1. 经常交付

项目主办者根据团队的工作进展获得重要反馈。用户有机会发现他们原来的需求是否是他们真正想要的，也有机会将观察结果反馈到开发当中。开发人员打破未解决问题的死结，从而实现对重点的持续关注。团队得以调整开发和配置的过程，并通过完成这些工作鼓舞团队的士气。

2. 反思改进

在迭代中及时反思和改进。

3. 渗透式交流

渗透交流就是信息流向团队成员的背景听觉，使得成员就像通过渗透一样获取相关信息。这种交流通常都是通过团队成员在同一间工作室内工作而实现的。

4. 个人安全

指的是当你指出困扰你的问题时，你不许担心受到报复。个人安全非常重要，有了它，团队可以发现和改正自身的缺点。没有它，团队成员们知而不言，缺点则愈发严重以至于损害整个团队。个人安全是迈向信任的第一步。

5. 焦点

就是确定首先要做什么，然后安排时间，以平和的心态开展工作。确保团队成员清楚地了解他们自己最重要的任务是什么，确保他们能够有充分的时间去完成这些任务。

6. 与专家用户建立方便的联系

能够提给团队提供：对经常交付进行配置以及测试的地方，关于成品质量的快速反馈，关于设计理念的快速反馈，最新的（用户）需求。

7. 配有自动测试、配置管理和经常集成功能的技术环境

最好的团队是将这三大技术结合成“持续测试集成技术”。

6.4.5 其他敏捷方法

• 开放式源码：指的是开放源码界所用的一种运作方式。开放式源码有一个特别之处，就是程序开发人员在地域上分布很广。一个突出特点就是查错排障的高度并行性，任何人发现了错误都可以将改正源码的“补丁”文件发送给维护者，然后由维护者将这些“补丁”或是新增的代码并入源码库。ASD方法的核心是三个非线性的、重叠的开发阶段：猜测、合作与学习。

6.5 软件重用

6.5.1 软件重用

指的是利用已经存在的软件元素建立新的软件系统，这其中的软件元素既可以是软件产品、源程序，也可以使文档、设计思想甚至是领域知识。常用的软件重用形式包括；

1. 源代码重用
2. 架构重用
3. 应用框架的重用。
4. 业务建模的重用
5. 文档即过程的重用
6. 软构件的重用。
7. 软件服务的重用。

6.5.2 构建技术

构件又称为组件，是一个自包容、可复用的程序集。首先，构件是一个程序集，或者说是一组程序的集合。这个集合可能会以各种方式体现出来，如源程序或二进制的代码。这个集合整体向外提供统一的访问接口，构件外部只能通过接口来访问构件，而不能直接操作构件的内部。

构件的两个最重要的特性是自包容和可重用。自包容指的是构件本身是一个功能完整的独立体，构件内部与外部的功能界限清晰明确，可以独立配置与使用。而可重用即是构件的特点，也是构件出现的目的。

目前应用比较广泛的构件标准有CORBA、Java Bean/EJB、COM/DCOM。

6.6 基于架构的软件设计 ABSD

是一种架构驱动方法，有三个基础：

1. 功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。
2. 通过选择架构风格来实现质量和业务需求。
3. 软件模板的使用。软件模板利用了一些软件系统的结构。

软件模板是一个特殊类型的软件元素，包括描述所有这种类型的元素在共享服务和底层构造的基础上如何进行交互。软件模板还包括属于这种类型的所有元素的功能，这些功能有：每个元素都必须记录某些重大事件，每个元素必须为运行期间的外部诊断提供测试点等。在软件产品线系统中，软件模板显得格外重要，因为新元素的引入是一个通用的技术，这种技术用来使产品线架构适应一个特定的产品。

ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，这有助于降低架构设计的随意性。

6.6.1 ABSD方法与生命周期

ABSD的输入由下列部分组成：

1. 抽象功能需求

包括需求的粗略变化的描述和通用的需求。

2. 用例

用例是一个或多个最终用户与系统之间的交互的具体表述。

3. 抽象的质量和业务需求

必须对待构建系统的质量和业务需求进行编号，每个质量属性都宝库啊一个特定的刺激，以及希望得到的响应。质量需求要尽量具体化。

4. 架构选项

5. 质量场景

质量场景是质量需求的特定扩充，使质量需求具体化。

6. 约束

6.6.2 基于架构的软件开发模型 ABSDM

把整个基于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等6个子过程

1. 架构需求

需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。架构需求受技术环境和架构设计师的经验影响。需求过程主要是获取用户需求，标识系统中所要用到的构件。如果以前有类似的系统架构的需求，我们可以从需求库中取出，加以利用和修改，以节省需求获取的时间，减少重复劳动，提高开发效率。

1. 需求获取

架构需求一般来自三个方面，分别是系统的质量目标、系统的业务目标和系统开发人员的业务目标。软件架构需求获取过程主要是定义开发人员必须实现的软件功能，使得用户能够完成他们的任务，从而满足业务上的功能需求。与此同时，还需要获得软件质量属性，满足一些非功能需求。

2. 标识构件

这一过程又分为三步来实现

第一步：生成类图。
第二步：对类进行分组。一般的，与其他类隔离的类形成一个组，由泛化关联的类组成一个附加组，由聚合或组合关联的类形成一个附加组。
第三步：把类打包成构件。把在第二步得到的类簇打包成构件，这些构件可以分组合并成更大的构件。

3. 需求评审

组织一个由不同代表组成的小组，对架构需求及相关构件进行仔细的审查。审查的主要内容包括所获取的需求是否真实反映了用户的要求，累的分组是否合理，构建合并是否合理等。

2. 架构设计

1. 提出软件架构模型
2. 把已标识的构件映射到软件架构中。把在架构需求阶段已标识的构件映射到架构中，将产生一个中间结构，这个中间结构只包含那些能明确适合架构模型的构件。
3. 分析构件之间的相互作用
4. 产生软件架构
5. 设计评审

3. 架构文档化

架构文档化的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明书两个文档。生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。

4. 架构复审

在一个主版本的软件架构分析后，要安排一次由外部人员参加的复审。

复审的目的是标识潜在的风险，以及早发现架构设计中的缺陷和错误，包括架构能否满足需求，质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否能满足功能和性能的要求等。

5. 架构实现

所谓“实现”就是要用实体来显示出一个软件架构，既要符合脚骨所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。

整个实现过程是以复审后的文档化的架构说明书为基础的，每个构件必须满足软件架构中说明的对其他构件的责任。这些决定即实现的约束是在系统级或项目范围内作出的，每个构件上工作的实现者是看不见的。

在架构说明书中，已经定义了系统中构件与构件的关系。因为在架构层次上，构件接口约束对外唯一的代表了构件，所以可以从构件库中查找符合接口约束的构件，必要时开发新的满足要求的构件。

然后，按照设计提供的结构，通过组装支持工具把这些构件的实现体柱状起来，完成整个软件系统的连接与合成。

最后一步是测试，包括单个构件的功能性测试和被组装应用的整体功能和性能测试。

6. 架构演化

在构件开发过程中，最终用户的需求可能还有变动。在软件开发完毕，正常运行后，由一个单位移植到另一个单位，需求也会发生变化。在这两种情况下，就必须响应的修改软件架构，以适应新的软件架构。

架构演化是使用系统演化步骤去修改应用，以满足新的需求。主要包括以下七个步骤：

1. 需求变动归类。首先必须对用户需求的变化进行归类，使变化的需求与已有构件对应。对找不到对应构件的变动，也要做好标记。在后续构件中，将创建新的构件，以对应这部分变化的需求。
2. 制定架构演化计划。在改变原有结构之前，开发组织必须制定一个周密的架构演化计划，作为后续演化开发工作的指南。
3. 修改、增加或删除构件。在演化计划的基础上，开发人员可根据在第一步得到的需求变动的归类情况，决定是否修改或删除存在的构件、增加新构件。最后，对修改和增加的构件进行功能性测试。
4. 更新构件的相互作用。随着构件的增加、删除和修改，构件之间的控制流必须得到更新。
5. 构建组装与测试。通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成，形成新的架构。然后对组装后的系统的整体功能和性能进行测试。
6. 技术评审。对上述步骤进行确认，进行技术评审。评审组装后的架构是否反映需求变动，符合用户需求。如果不符合，则需要在第2到第6步之间进行迭代。
7. 产生演化后的架构。在原来系统上所做的所有修改必须集成到原来的架构中，完成一次演化过程。

6.7 形式化方法

指采用严格的数学方法，使用形式化规约语言来精确定义软件系统。非形式化的开发方法是通过自然语言、图形或表格描述软件系统的行为和特性，然后基于这些描述进行设计和开发，而形式化开发则是基于数学的方式描述、开发和验证系统。

形式化方法包括形式化描述和基于形式化描述的形式化验证两部分内容。形式化描述就是用形式化语言进行描述，建立软件需求和特性，即解决软件“做什么”的问题。形式化验证是指验证已有的程序是否满足形式化描述的定义。形式化描述主要可以分为两类，一类是通过建立计算模型来描述系统的行为特征，另一类则通过定义系统必须满足的一些属性来描述系统。形式化描述又称之为形式化规约，相对于自然语言描述，形式化描述是精确的、可验证的，避免了模糊性与二义性，消除需求中相互矛盾的地方，避免需求定义人员和开发人员对需求的理解偏差。

形式化描述可以通过计算机技术进行自动处理，进行一致性的检查和证明，提高需求分析的效率和质量。通过形式化描述，需求分析的质量大大提高，很多自然语言描述无法避免的缺陷在序曲分析阶段就会被发现，并得到解决，从而降低后期开发和维护的成本，并提升软件的质量和可靠性。

第七章 系统计划

7.1 项目的提出与选择

7.1.1 项目的立项目标和动机

1. 进行基础研究并获取技术
2. 进行应用研发并获得产品
   此类项目通常由企业立项和研发，通常是为了得到应用软件产品并向目标客户群进行销售从而获得利润等。可归入“应用研发”型软件
3. 提供技术服务
4. 信息技术产品的使用者

7.1.2 项目的选择和确定

系统项目的选择至少包含两种实用性目的，一个是软件开发公司在诸多的产品方向中选择适当的方向进行研究和开发，另一种是客户从诸多的产品中购买适合自己需要的产品或者选择自己需要的技术方案进行实施。

1. 选择有核心价值的产品/项目或者开发方向
   该策略在于确认什么样的系统项目是有价值的。在企业或客户经营活动中对价值链增值最大的部分，就是企业或客户的“核心业务”。
2. 评估项目风险、收益和代价
3. 评估项目的多种实施方式
   这种实施方式通常既包括了前面对项目风险、预期收益和资源开销的评估，也包含了企业对现阶段经营目标和现有资源如何合理运用的考虑。
4. 平衡的选择适合的方案
   项目开发方更多考虑的是项目风险和回报，而客户更多关心的是成本和购买后的满意度。

7.1.3 项目提出和选择的结果

系统项目提出和选择的结果，最终会以“产品/项目建议书”的方式来体现。

产品/项目建议书是一个包含多种综合内容的报告，涉及的范围通常要比GB8567-1988标准中规定的标准——“项目可行性分析报告”的内容更全面。

7.2 可行性研究与效益分析

虽然可行性研究不能指出项目最终的详细计划和方向，但是可行性研究可以在项目定义阶段用最小的代价识别出错误构思的系统，从而规避未来更多的资源投入的损失（时间、资金、人力、机会），或者因遭遇到无法逾越的技术障碍或环境障碍导致的不可避免的失败。

7.2.1 可行性研究的内容

1. 经济可行性
   主要评估项目的开发成本及项目成功后可能获得的经济收益。
2. 技术可行性
   评估对于假想的软件系统需要实现的功能和性能，以及技术能力约束。可以通过“提问——回答”的方式来进行论证，包括：
   
   1. 技术：现有的技术能力和IT技术的发展现状足以支持想象中的系统目标实现吗？
   2. 资源：现有的资源（掌握技术的职员、公司的技术积累、构件库、软硬件条件等）足以支持项目实施吗？技术风险在评估的哪个范围内？
   3. 目标：在目前设定的系统目标中，哪些目标会遭遇到较强的技术障碍？尤其是哪些被设定为必须实现的系统目标。
3. 法律可行性
   评估可能由系统开发引起的侵权或法律责任。
4. 执行可行性
   也称操作可行性，主要评估预期的软件系统在真实环境中能够被应用的程序和实施过程中障碍。
5. 方案的选择
   评估系统或产品开发的可选方法。

7.2.2 成本效益分析

效益分析实际上包含了“成本——效益”的分析。从内容上看，效益分析是可以包含在可行性研究的经济可行性分析中的。但效益分析的目的在于，项目开发目标的成本及可度量的项目现金收入和无形收益进行一次专门化的评估。

1. 项目可能涉及的成本

项目的成本部分，包括：

• 基础建设支出：基础设施、设备、软件等
• 一次性支出：各种费用支出
• 运营维护费用：定期消耗、租金、工资等。

2. 项目可能涉及的收益

项目的收益，通常可以分为一次性收益、非一次性收益和不可定量的收益三个部分。

a. 一次性收益

- 开支的缩减。包括改进了的系统的运行所引起的开支缩减。如资源要求的减少，运行效率的改进等。
- 价值的提升。包括由于一个应用系统的使用价值的增升所引起的收益，如资源利用的改进，管理和运行效率的改进及出错率的减少等。
- 其他。如多余设备的出售回收的收入等。

b. 非一次性收益
在整个系统生命周期内由于运行所建议系统而导致的按月的、按年的能用人民币表示的收益，包括开支的减少

c. 不可定量的收益
无法直接用人民币表示的收益。如服务的改进，由操作失误引起的风险的减少，信息掌握情况的改进等。有些不可捉摸的收益只能大概估计或进行极值估计

3. 效益分析的若干指标和进一步的分析

• 收益/投资比：软件项目实施后整个系统生命期的收益/投资比值；
• 投资/回报周期：收益的累计数开始超过支出的累计数的时间；
• 敏感性分析：分析项目中一些关键性因素如系统生命期长度、系统的工作负荷量、工作负荷的类型、处理速度、设备和软件的配置等因素发生变化或进行合理搭配时，对开支和收益的影响最灵敏的范围估计。通常在项目需要在不同因素之间取舍和调整的时候，需要参考敏感性分析的内容。

7.2.3 可行性分析报告

可行性分析报告最重要的内容应有以下几项：

• 项目背景：包括问题描述、实现环境和限制条件；
• 管理概要和建议：包括重要的研究结果、说明、建议和影响；
• 候选方案：包括候选系统的配置和最佳方案的选择标准；
• 系统描述：包括系统工作范围的简要说明和被分配系统元素的可行性；
• 经济可行性（成本/效益分析）：包括经费概算和预期的经济效益；
• 技术可行性（技术风险评价）：包括技术实力、已有工作基础和设备条件；
• 法律可行性：包括系统开发可能导致的侵权、违法和责任等；
• 用户使用可行性：包括用户单位的行政管理，工作制度和使用人员的素质；
• 其他与项目有关的问题：例如，其他方案介绍和未来可能的变化。

可行性研究报告首先由项目负责人审查（审查内容是否可靠），再上报给上级主管审阅（评估项目的地位）。

7.3 方案的制定和改进

1. 确定软件架构

1. 分析模型的架构。
2. 一些对应于系统目标的最基本、最重要的实现元素。
3. 特性和要点的解释。

2. 确定实现的各种关键性要素和实现手段

关键性的实现要素通常包括：

• 关键的用例、最主要的控制类、功能和服务的首要组织方式（例如网站首页）。
• 对象的组织模式；
• 常用和最关键的实现算法模型。

关键性的实现手段通常包括：

• 选定基础计算平台，如操作系统、数据库、Web服务器等
• 选定开发工具和开发环境

3. 归结目标到最适合的计算体系

通过同时参考系统概念模型，将前面得到的系统功能清单和系统实现的各种关键要素整理并分类，然后与现有的技术、标准的实现体系进行比较和匹配，就可以将系统概念模型定义的系统目标，进一步映射到真正可计算、可实现的系统架构上。这个过程可以理解为一种不断归纳、比较并匹配的过程。

归结系统实现要素到计算体系的时候，要点在于理解各种计算体系的大致分层和结构，比较实现要素的目标和实现手段之间的“适合程度”，而不是生搬硬套某种实现机制，或盲目追求某种“流行的”或“先进的”计算体系。

系统方案制定后，需要根据有关标准进行评价，找出不符合实际的地方，然后进行改进。

7.4 新旧系统的分析和比较

遗留系统是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统。遗留系统应具有以下特点：

1. 系统虽然能完成企业中需要重要的业务管理工作，但已经不能完全满足要求。一般实现业务处理电子化及部分企业功能，极少涉及经营决策。
2. 系统在性能上已经落后，采用的技术已经过时。
3. 通常是大型的系统，已经融入企业的业务运行和决策管理机制之中，维护工作十分困难。
4. 系统没有使用现代系统工程方法进行管理和开发，限制基本上已经没有文档，很难理解。

7.4.1 遗留系统的评价方法

1. 启动评价

评价是为了获得对遗留系统的足够深度的理解，从技术、商业和企业角度对系统的理解为系统处理策略提供基础，开始评价前，需要了解以下问题：

1. 对企业来说，遗留系统是否是至关重要的。
2. 企业的商业目标是什么。
3. 演化需求是什么。
4. 所期望的系统寿命多长。一个系统的寿命由软件和硬件的服务能力决定，一旦系统硬件或支撑软件过时，系统的有效性就受到了限制。
5. 系统使用期限多久。
6. 系统的技术状态如何。
7. 企业是否愿意改变。
8. 企业是否有能力承受演化。

2. 商业价值评价

商业价值评价的目标是判断遗留系统对企业的重要性。可以在概要和详细两个级别上对遗留系统的商业价值评价。

概要级评价将为更加详细的分析提供信息。包括：

1. 咨询。向有关专家进行咨询，包括最终用户和负责业务处理的管理人员。
2. 评价问卷。问卷应该标识系统在业务处理过程中的哪些地方使用，本系统与其他系统的关系，如系统不再运行所需的代价，系统已有的缺点和存在的问题等。问题的准确性依赖于所评价的系统。
3. 进行评价

3. 外部环境评价

系统的外部技术环境指硬件、支撑软件和企业基础设施的统一体。

1. 硬件。系统硬件包括许多需要进行常规性维护的部件，这些硬件或者在一个站点，或者分布在许多站点并由网络连接。
   与商业评价类似，硬件评价也可以分为概要级评价和详细级评价。概要级评价把遗留系统作为一个整体，提供硬件质量估计。详细级评价包括识别系统中的每个部件。在这两种情况下，必须识别一系列特征，用作评价的基础。特征的选择取决于要评价的系统。系统的一些常见特征有：供应商、维护费用、失效率、年龄、功能、性能等。
   具体评价方法是：每一个部件（或整个系统）在每个特征上分配一个价值分数（取值为1~4），然后把所有分数相加，获得该部件的总分。
2. 支撑软件。系统的支撑软件环境也由许多部分组成，可包括操作系统、数据库、事务处理程序、编译器、网络软件、应用软件等。一般来说，支撑软件是依赖于某个硬件的，应用程序依赖于系统软件。在评价过程中，必须考虑这种依赖性。支撑软件的评价方法类似于硬件评价。
3. 企业基础设施。包括开发和维护系统的企业职责和运行该系统的企业职责，这些基础设施都是很难评价的，但对遗留系统的演化起关键作用，因此必须考虑以下问题：
   
   • 企业和使用者的类型
   • 开发组织的技术成熟度
   • 企业的培训过程
   • 系统支持人员的技术水平
   • 企业是否愿意改变

4. 应用软件评价

应用软件评价也有两个级别

1. 系统级。把整个系统看做是不可分的原子，评价时不考虑系统的任何部分。
2. 部件级。关注系统的没格子系统，考虑每个子系统的特征，包括复杂性、数据、文档、外部依赖性、合法性、维护记录、大小、安全性等。

5. 分析评价结果

评价活动将产生硬件、支撑软件、企业基础设施和应用软件的特征值矩阵，这些矩阵值体现了遗留系统当前的技术因素，其加权平均值代表了系统的技术水平。计算公式如下：

$$OR=(P_1ORH+P_2ORS+P_3ORF+P_4ORA)/4$$

其中ORA是硬件的评价值，ORS是支撑软件的评价值，ORF是企业基础设施的评价值，ORA是应用软件的评价值。$P_i(1<=i<=4)$分别是它们的权系数，即第$i$个评价值对遗留系统的影响因子。

根据评价结果的分值，可以将评价结果分为四种类型

类型	处理方式
高水平低价值	集成
高水平高价值	改造
低水平高价值	继承
低水平低价值	淘汰

7.4.2 遗留系统的演化策略

1. 淘汰策略

当遗留系统的评价很低，为低水平低价值时，就说明遗留系统的技术含量很低，且具有较低的商业价值。对于这种遗留系统的演化策略为淘汰，即全面重新开发新的系统以代替遗留系统。

完全淘汰是一种极端性策略，一般是企业的业务产生了根本的变化，遗留系统基本上不再适应企业运作的需要；或者是遗留系统的维护人员、维护文档都丢失了。经过评价，发现遗留系统完全淘汰，开发全新的系统比改造旧系统从成本上更合算。

2. 继承策略

当评价的结果为低水平、高价值时，说明遗留系统的技术含量较低，可满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业业务对该系统仍有很大的依赖性。对这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。

3. 改造策略

当评价结果为高水平、高价值时，说明遗留系统的技术含量较高，本身还有较大的生命力，且具有较高的商业价值，基本上能够满足企业业务运作和决策支持的要求。这种系统可能建成的时间还很短，对这种遗留系统的演化策略为改造。

这种改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变。数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型转化的过程。

4. 集成策略

当评价结果为高水平低价值时，说明遗留系统的技术含量较高，但是商业价值较低，可能只完成某个部门（或子公司）的业务管理。这种系统在各自的局部领域里工作良好，但从企业全局来看，多个这样的系统他们各自基于不同的平台，不同的数据模型，无法互联互通，数据还不一致，这就是很严重的问题了。

因此对这种遗留系统的演化策略为集成。

集成过程中，可采用由互连系统构成的系统的架构，遗留系统可作为从属系统来描述。

第八章 系统分析与设计方法

8.1 定义问题与归结模型

定义问题的过程包括：理解真实世界中的问题和用户的额需要，并提出满足这些需要的解决方案的过程。

8.1.1 问题分析

目标就是在开发之前对要解决的问题有一个更透彻的理解。为了达到这一目标，通常需要经过在问题定义上达成共识，理解问题的本质，确定项目干系人和用户，定义系统的边界和确定系统实现的约束这五个步骤。

1. 在问题定义上达成共识

应当将问题用标准的格式写出来，根据UP的建议，应当包括以下几个方面的要素。

• 问题概述：用简短的几句话，将所理解的问题本质描述出来；
• 影响：说明该问题将会对哪些项目干系人（风险承担者）产生影响；
• 结果：确定问题对项目干系人和商业活动或产生什么样的影响；
• 优点：概要性的提出解决方案，并列举出该解决方案的主要优点。

在问题定义上达成共识，能够有效的将开发团队的理解与用户的需求达成一致，这样就能够使得整个系统的开发沿着合理的方向发展。

2. 理解问题的本质

一种技术是“根本原因”分析，这是一种提示问题或其表象的根本原因的系统化方法。在实际的应用中，长使用因果鱼骨图和累托图两种方法。

因果鱼骨图

是一种有效的探寻问题根源的技术，它通过直观的图形找出问题或现象的所有潜在原因，从而追踪出问题的根源。提供了一种运用集体智慧解决问题的方法。在使用时，通常按照以下步骤进行。

• 将问题简明扼要的写在右边的方框里；
• 确定问题潜在原因的主要类别，把它们连到鱼的脊骨上；
• 用头脑风暴方法寻找原因并归类。

帕累托法

是采用释放图的形式，根据问题的相对频率或大小从高往低将序排列，帮助设计师将精力集中在重要的问题上。它为80%的问题找到关键的20%的 原因，可以一目了然的显示出各个问题的相对重要程度，有助于预防在解决了一些问题后，却使另外一些问题变得更糟的现象发生。在使用时，通常按照以下步骤进行：

• 明确问题：也就是前面达成共识的问题定义
• 找出问题的各种可能原因
• 选择评价标准和考察期限：最常用的评价标准包括频率（占总原因的百分比）和费用（产生的影响），而考察的期限则应具有相应问题的代表性，并不是越长越好。
• 收集各种原因发生的频率及费用数据；
• 将原因按照发生的频率或费用从大到小排列起来；
• 将原因排在横轴上，频率或费用排列在纵轴上。

3. 确定项目干系人和用户

要想有效的解决问题，必须了解用户和其他相关的项目干系人（任何将从新系统或应用的实现中受到实质性影响的人）的需要。

4. 定义系统的边界

系统的边界是指解决方案系统和现实世界之间的边界。在系统边界中，信息以输入和输出的形式流入系统并由系统流向系统外的用户，所有和系统的交互都是通过系统和外部的接口进行的。在定义系统边界时，将世界分为两个部分：系统及与系统进行交互的事物。

要描述系统的边界有两种方法：一种是结构化分析中的“上下文范围图”，另一种则是面向对象分析中的“用例模型”。

1. 上下文范围图。也就是数据流图中的顶层图，他是一个反映领域信息的模型，能够清晰的显示出系统的工作职责和相邻系统的职责起止支出，从而让读者能够从宏观的层面去了解系统。
2. 用例模型。通过引入参与者来描述“和系统进行交互的事物”

然后，在根据每个参与者的功能需求，识别出代表系统功能的用例，从而界定系统的边界。

5. 确定系统实现的约束

由于各种因素的存在，会对解决方案的选择造成一定的限制，成这种限制为约束。每条约束都将影响到最后的解决方案的形成，甚至会影响是否能够提出解决方案。

8.1.2 问题定义

对于一个问题的完整定义，通常应包括目标、功能需求和非功能需求三个方面。

1. 目标

指构建系统的原因，他是最高层次的用户需求，是业务上的需要，而功能、性能需求则必须是以某种形式对该目标作出贡献。在描述目标时，应该注意一下几个方面。

• 优势：目标应该不仅仅是解决问题，还要提供业务上的优势；
• 度量：不仅要说明业务的优势，而且还必须提供度量这种优势的标准；
• 合理性：要确保完成解决方案所需的工作量少于所获得的业务优势，这才是合理的解决方案；
• 可行性：要探寻能够满足度量标准的解决方案；
• 可达成性：对于组织而言，是否具备获取该系统的技能，构件完成狗是否能够操作它。

2. 功能需求

是用来指明系统必须做的事情，只有这些行为的存在，才有系统存在的价值。功能需求是在与用户或某个业务人员交谈时，他们所描述的内容是为了完成他们某部分的工作而必须做的事情。而在设计解决方案时，会遇到一些限制条件，这些东西也是“系统需求”的一部分，不过应该以设计约束或非功能需求形式指定。

需求的二义性主要体现在以下几个方面：

1. 同名异义的词。
2. 代词。

3. 非功能需求

是系统必备的属性，这些属性可以看做是一些使产品更有吸引力、易用、快速或可靠的特征或属性。非功能需求并不改变产品的功能，它是为工作赋予特征的。功能需求是以动词为特征的，而非功能需求则是以副词为特征的。非功能需求主要包括以下几种。

1. 敏感需求：即产品外观的精神实质，也就是与用户界面的观感相关的一组属性。
2. 易用性需求：也就是产品的易用程度，以及特殊的可用性考虑，通常包括用户的接受率、因为引入该产品而提高的生产效率、错误率、特殊人群的可用性等指标；
3. 性能需求：也就是关于功能实现要求有多快、多可靠、多少处理量及多精确的约束。
4. 可操作性需求：衡量产品的操作环境，以及对该操作环境必须考虑的问题；
5. 可维护性和可移植性需求：期望的改变，以及完成改变允许的时间；
6. 安全性需求：产品的安全保密性，通常体现为保密性、完整性和可获得性；
7. 文化和政策需求：由产品的开发者和使用者所带来的特别需求；
8. 法律需求：哪些法律和标准适用于本产品。

8.2 需求分析与软件设计

8.2.1 需求分析的任务与过程

需求分析主要就是确定待开发软件的功能、性能、数据、界面等要求。需求分析的实现步骤通常包括：获取当前系统的物理模型、抽象出当前系统的逻辑模型、建立目标系统的逻辑模型三个部分。具体来说，修分析阶段可以分成4个方面：

1. 问题识别：用于发现需求、描述需求，以此来预先估计以后系统可能达到的目标。
2. 分析与综合：对问题进行分析，然后在此基础上整合出解决方案。这个步骤是经常进行的，常用的方法有面向数据流的结构化分析方法，面向数据结构的Jackson方法，面向对象的分析方法以及用于建立动态模型的状态迁移图和Petri网。
3. 编制需求分析的文档：也就是对已经确定的需求进行文档化描述，该文档通常称为“需求规格说明书”。
4. 需求分析与评审：主要是对功能的正确性、完整性和清晰性，以及其它需求给予评价。

1. 需求的分类

• 功能需求：指系统必须完成的，为了向它的用户提供有用的功能，产品必须执行的动作。
• 非功能需求：指产品必须具备的属性或品质，如性能、响应时间、可靠性、容错性、扩展性等。
• 设计约束：也称为限制条件、补充规约。

除了三种需求之外，还有业务需求、用户需求、系统需求这三个处于不同层面的概念

• 业务需求：指反映组织结构或客户对系统、产品高层次的目标需求，通常问题定义本身就是业务需求。
• 用户需求：指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度出发的需求。
• 系统需求：是从系统的角度来说明软件的需求，它包括用特性说明的功能需求、质量属性、肺功能需求及设计约束。

2. 需求工程

就是包括创建和维护系统需求文档所必须的一切活动的过程，主要包括需求开发和需求管理两大工作。

1. 需求开发：包括需求捕获、需求分析、编写规格说明书和需求验证4个阶段。在这个阶段需要完成确定产品所期望的用户类型，获取每种用户类型的需求，了解实际用户任务和目标这些任务所支持的业务需求、分析源于用户的信息、对需求进行优先级分类、将所收集的需求编写成为软件规格说明书和需求分析模型，对需求进行评审等工作。
2. 需求管理：通常包括定义需求基线、处理需求变更、需求跟踪等方面的工作。

这两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。换句话说，需求开发是努力更清晰，更明确的掌握客户对系统的需求；而需求管理管理则是对需求的变化进行管理的过程。

需求分析方法

1. 结构化分析方法。
2. 软系统方法
3. 面向对象分析方法
4. 面向问题域的分析PDOA

8.2.2 如果进行系统设计

优秀的系统设计一般在以下几个方面都很出色。

1. 组件的独立性。审视自己设计的系统，是否做到了高内聚、低耦合？
2. 例外的识别和处理。
3. 防错和容错。

8.2.3 软件设计的任务与活动

软件设计是一个把软件需求变换成软件表示的过程，最初这种表示只是描绘出软件的总体框架，然后再进一步细化，并在此框架中填入细节。

1. 软件设计的两个阶段

1. 概要设计。也称为高层设计，将软件需求转化为数据结构和软件的系统结构。例如，如果采用结构化设计，则将从宏观的角度讲软件划分成各个组成模块，病确定模块的功能及模块之间的调用关系。
2. 详细设计。也称为低层设计，将对结构表示进行细化，得到详细的数据结构与算法。同样的，如果采用结构化设计，则详细设计的任务就是为每个模块进行设计。

2. 主要的设计方法比较

8.3 结构化分析与设计

8.3.1 结构化分析

结构化分析方法的基本思想是自顶向下逐层分解。分解和抽象是人们控制问题复杂性的两种基本手段。将一个大问题逐层逐级分解为最底层的问题，就是分解过程。

结构化分析与面向对象分析方法之间的最大差别是：结构化分析方法把系统看做一个过程的集合体，包括人完成的和电脑完成的；而面向对象方法则把系统看成一个相互影响的对象集。结构化分析方法的特点是利用数据流图来帮助人们理解问题，对问题进行分析。

结构化分析方法一般包括以下工具：数据流图DFD、数据字典DD、结构化语言、判定表、判定树。

结构化系统分析方法从总体上看是一种强烈依赖数据流图的自顶向下的建模方法。

1. 结构化分析的工作步骤

1. 研究“物质环境”：首先，应画出当前系统（可能是非计算机系统，或是半计算机系统）的数据流图，说明系统的输入、输出数据流，说明系统的数据流情况，以及经历了哪些处理过程。这个过程可以帮助分析员有效的理解业务环境，在与用户的充分沟通与交流中完成。
2. 建立系统逻辑模型。当物理模型建立之后，接下来的工作就是画出相对于真实系统的等价逻辑数据流图。在前一步骤建立的数据流图的基础上，将所有自然数据流都转成等价的逻辑流。
3. 划清人机界限。最后，确定在系统逻辑模型中，哪些将采用自动化完成，哪些仍然保留手工操作。

2. 数据流图

DFD是一种图形化的系统模型，它在一张图中展示信息系统的主要需求，即输入、输出、处理（过程）、数据存储。DFD包括以下几个基本元素

• 过程：也称为加工，一步步的执行指令，完成输入到输出的转换。
• 外部实体：也称为源/宿，系统之外的数据源或目的。
• 数据存储：也称为文件，存放数据的地方，一般是以文件、数据库等形式出现。
• 数据流：从一处到另一处的数据流向，数从数据或数据到一个过程的数据流。

• 实时连接：当过程执行时，外部实体与过程之间的来回通信。

  1. 数据流图的层次。数据流图提供一种表现系统高层和低层概念的机制，也就是先绘制一张较高层次的数据流图，然后再次基础上，对其中过程（处理）进行分解，分解成为若干独立的、低层次的、详细的数据流图，而且可以这样逐一分解下去，知道系统被清晰的描述出来。
  2. Context图。也就是系统上下文范围关系图。这是描绘系统最高层结构的DFD图。它的特点是：将整个待开发的系统表示为一个过程，将所有的外部实体和进出系统的数据流都画在一张图中。用来描述系统有什么输入、输出数据流，与哪些外部实体直接相关，可以把整个系统的范围勾画出来。
  3. 逐级分解。当完成了Context图的建模之后，就可以在此基础上进行进一步的分解。
  4. 如何画DFD。DFD的绘制是一个自顶向下、由外到里的过程，通常按照以下几个步骤进行。
• 画系统的输入和输出：就是在图的边缘标出系统的输入、输出数据流。这一步其实是绝地你个研究的内容和系统的范围。在画的时候，可以先将尽可能多的输入、输出画出来，然后再删除多余的，增加遗漏的。
• 画数据流图的内部：将系统的书、输出用一系列的处理连接起来，可以从输入数据流花香输出数据流，也可以从中间画出去。
• 为每一个数据流命名：命名的好坏与数据流图的可理解性密切相关，应避免使用空洞的名字。
• 为加工命名：注意应使用动宾短语。
• 不考虑初始化也重点，暂不考虑出错路径等细节，不画控制流和控制信息。

3. 细化记录DFD部件

为了更好的描述DFD的部件，结构化分析方法还引入了数据字典、结构化语言及决策树、决策表等方法。其中数据字典应用最为广泛。

数据字典技术是一种很实用、有效的表达数据格式的手段。他是对所有与系统相关的数据元素的一个有组织的列表和精确严格的定义。使得用户和系统分析员对于输入、输出、存储层粉和中间计算机有共同的理解。通常数据字典的每一个条目中包括以下信息。

1. 名称：数据或控制箱、数据存储或外部实体的主要名称，如果有别名的还应该将别名列出来。
2. 何处使用/如何使用
3. 内容描述：说明该条目的内容组成，通常采用以下符号进行说明
   
   • =：由...构成
   • +：和，代表顺序连接的关系。
   • [|]：或，代表从中选一个
   • {}*：n次重复
   • ()：代表可选的数据项
   • *...*：表示特定限制的注释
4. 补充信息：关于数据类型、默认值、限制等信息。

8.3.2 结构化设计

结构化设计包括架构设计、接口设计、数据设计和过程设计等任务。他是一种面向数据流的设计方法，是以结构化分析阶段所产生的成果为基础，进一步自顶向下、逐步求精和模块化的过程。

1. 概要设计与详细设计的主要任务

概要设计阶段的主要任务是设计软件的结构、确定系统是由哪些模块组成，以及每个模块之间的关系。它采用结构图来描述程序的结构，此外还可以使用层次图和HIPO（层次图加输入/处理/输出图）。

整个过程主要包括：复查基本系统模型、复查并精化数据流图、确定数据流图的信息流类型（包括交换流和事务流）、根据流类型分别实施变换分析或事务分析、根据软件设计原则对得到的软件结构图进一步优化。

而详细设计阶段的主要任务则是确定应该如何具体的实现所要求的系统，得出对目标系统的精确描述。它采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构。

2. 结构图

结构图的基本成分包括模块、调用（模块之间的调用关系）和数据（模块间传递及处理数据信息）。

结构图是在需求分析阶段产生的数据流图的基础上进行进一步的设计。它将DFD图中的信息流分为两种类型。

• 交换流：信息首先沿着输入通路进入系统，并将其转换为内部表示，然后通过变换中心（加工）的处理，再沿着输出转换为外部形式离开系统。具有这种特性的加工流就是交换流。
• 事务流：信息首先沿着输入通路进入系统，事务中心根据输入信息的类型在若干个动作序列（活动流）中选择一个执行，这种信息流称为事务流。

3. 程序流程图和盒图

程序流程图和盒图都是用来描述程序的细节逻辑的。

程序流程图的特点是简单、直观、易学，但它的缺点是由于其随意性而使得画出来的流程图容易成为非结构化的流程图。

盒图的主要特点是功能域明确、无法任意转移控制、容易确定全局数据和局部数据的作用域、容易表示嵌套关系、可以表示模块的层次结构。但它的缺点是修改相对比较困难。

4. PAD和PDL

PAD是问题分析图的缩写，它符合自顶向下、逐步求精的原则，也符合结构化程序设计的思想，最大的特点在于能够很方便的转换为程序语言的源程序代码。

PDL这是语言描述工具的缩写，它和高级程序语言很相似，也包括数据说明部分和过程部分，还可以带注释等成分，但它是不可执行的。PDL是一种形式化语言，其控制结构的描述是确定的，但内部的描述语法是不确定的。PDL通常也被称为伪码。

8.3.3 模块设计

模块是执行某一特定任务的数据结构和程序代码。通常将模块的接口和功能定义为其外部特性，将模块的局部数据和实现该模块的程序代码称为内部特性。而在模块设计中，最重要的原则就是实现信息隐蔽和模块独立。

1. 信息隐蔽原则

信息隐蔽是开发整体程序结构时使用的法则，即将每个程序的成分隐藏或封装在一个单一的设计模式中，并且尽可能少的暴露其内部的处理。通常将难的决策、可能修改的决策、数据结构的内部连接以及对它所做的操作细节、内部特征码、与计算机硬件有关的细节等隐蔽起来。

通过信息隐蔽可以提高软件的可修改性、可测试性和可移植性。

2. 模块独立性原则

模块独立是指每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系最简单。保持模块的高度独立性，也是设计过程中的一个很重要的原则。通常用耦合（模块之间联系的紧密程度）和内聚（模块内部各元素之间联系的紧密程度）两个标准来衡量，设计的目标是高内聚、低耦合。

模块的内聚类型如下图，根据内聚度从高到低排序

内聚类型	描述
功能内聚	完成一个单一功能，各个部分协同工作，缺一不可
顺序内聚	处理元素相关，而且必须顺序执行
通信内聚	所有处理元素集中在一个数据结构的区域上
过程内聚	处理元素相关，并且必须按特定的次序执行
瞬时内聚	所包含的任务必须在同一时间间隔内执行（如初始化模块）
逻辑内聚	完成逻辑上相关的一组任务
偶然内聚	完成一组没有关系或松散关系的任务

模块的耦合类型如下图，根据耦合度从低到高排序

耦合类型	描述
非直接耦合	没有直接联系，互相不依赖对方
数据耦合	借助参数表传递简单数据
标记耦合	一个数据结构的一部分借助于模块接口来传递
控制耦合	模块间传递的信息中包含用于控制模块内部逻辑的信息
外部耦合	与软件以外的环境有关
公共耦合	多个模块引用同一个全局数据区
内容耦合	一个模块访问另外一个模块的内部数据 一个模块不通过正常入口转入到另一个模块的内部 两个模块有一部分程序代码重叠 一个模块有多个入口

除了满足以上两大基本原则外，通常在模块分解时还需要注意：保持模块的大小适中，尽可能减少调用的深度，直接调用该模块的个数应该尽量大，但调用其他模块的个数则不宜过大；保证模块是单入口、单出口的；模块的作用域应该在控制域之内；功能应该是可预测的。

8.4 面向对象的分析与设计

8.4.1 面向对象的基本概念

1. 对象和类

对象是系统中用来描述客观事物的一个实体，它由对象标识（名称）、属性（状态、数据、成员变量）和服务（操作、行为、方法）三个要素组成，它们被封装为一个整体，以接口的形式对外提供服务。

类是对具有相同属性和服务的一个或一组对象的抽象。类与对象是抽象描述和具体实例的关系，一个具体的对象被称为类的一个实例。

在系统设计过程中，类可以分为三种类型，分别是实体类、边界类和控制类。

1. 实体类：实体类映射需求中的每个实体，实体类保存需要存储在永久存储体重的信息。实体类通常是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存周期都需要。
   实体类通常采用业务领域术语命名，一般来说是一个名词，在用例模型向领域模型的转化中，一个参与者一般对应于实体类。通常可以从SRS中的那些与数据库表（需要持久存储）对应的名词着手来寻找实体类。通常情况下，实体类一定有属性，但不一定有操作。
2. 控制类：控制类是用于控制用例工作的类，一般是由动宾结构的短语（“动词+名词”或“名词+动词”）转化来的名词。控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象（控制类的实例）通常控制其他对象，因此，它们的行为具有协调性。
   通常情况下，控制类没有属性，但一定有方法
3. 边界类：用于封装在用例内、外流动的信息或数据流。边界类位于系统与边界的交界处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。每个参与者与用例交互至少要有一个边界类。
   边界类用于系统接口与系统外部进行交互，边界对象将系统与其外部环境的变更分隔开，使这些变更不会对系统的其他部分造成影响。通常情况下，边界类可以既有属性也有方法。

2. 继承与泛化

继承用来说明特殊类（子类）与一般类（父类）的关系，而通常用泛化来说明一般类和特殊类的关系，也就是说它们是一对多关系。

3. 多态与重载

多态性（即多种形式）一般是指一般类中定义的属性被特殊类继承后，可以具有不同的数据类型或表现出不同的行为，通常是使用重载和改写两项技术来实现的

多态类型	描述
重载（专用多态）	描述一个函数名称有多种不同实现方式，通常可以在编译时基于类型签名来区分各个重载函数的名称
改写（包括多态）	是重载的一种特殊情况，只发生在有关父类和子类之间关系中。通常签名相同，内容不一样。
多态变量（赋值多态强制多态）	声明为一种类型，但实际上却可以包含另一种类型数值的变量
泛型（模板，参数多态）	它提供了一种创建通用工具的方法，可以在特定的场合将其特化

重载是编译时进行的（静态绑定），而改写则是运行时选择的（动态绑定）。

4. 模板类

也称类属类，用来实现参数多态机制。一个类属类是关于一组类的特性抽象，强调的是这些类的成员特征中与具体类型无关的那些部分，而用变元来表示与具体类型有关的那些部分。

5. 消息和消息通信

消息就是向对象发出的服务请求，通常包括提供服务的对象标识、消息名、输入信息和回答消息。消息通信则是面向对象方法学中的一个重要原则，它与对象的封装原则密不可分，为对象间提供了唯一合法的动态联系的途径。

8.4.2 面向对象分析

1. OOA/OOD方法

OOA模型中包括主题、对象类、结构、属性和服务5个层次，需经过标识对象类、标识结构与关联、划分主题、定义属性、定义服务5个步骤来完成整个分析同坐。

OOD中将贯穿OOA中的5个层次和5个活动，它由人机交互部件、问题域部件、任务管理部件、数据管理部件4个部分组成，其主要的活动就是这4个部件的设计工作。

• 设计问题域部分：OOA的结果恰好是OOD的问题域部件，分析的结果在OOD中可以被改动或增补，但基于问题域的总体组织框架是长时间稳定的；
• 设计人机交互部件：人机交互部件在上述结果中加入人机交互的设计和交互的细节，包括窗口和输出服务的设计。可以用原型来帮助实际交互机制进行开发和选择；
• 设计任务管理部分：这部分主要是识别事件驱动任务，识别时钟驱动任务，识别优先任务和关键任务，识别协调者，审查每个任务并定义每个任务。
• 设计数据管理部分：数据管理部分提供了在数据管理系统中存储和检索对象的基本结构，其目的是隔离数据管理方法对其他部分的影响。

2. Booth方法

Booth任务软件开发是一个螺旋上升的过程，每个周期中包括标识类和对象、确定类和对象的含义、标识关系、说明每个类的接口和实现四个步骤。

/	静态模型	动态模型
逻辑模型	类图 对象图	状态转换图 时序图
物理模型	模块图 进程图

Booth方法的挨罚过程是一个迭代的、渐进式的系统开发过程，它可以分为宏过程和微过程两类。宏过程用于控制微过程，是覆盖几个月或几周所进行的活动。它包括负责建立核心需求的概念化，为所期望的行为建立模型的分析，建立架构的设计，形成实现的进化，以及管理软件交付使用的维护等5个主要活动。

而微过程则基本上代表了开发人员的日常活动，它由4个重要、没有顺序关系的步骤组成：在给定的抽象层次上识别出类和对象，识别出这些类和对象的语义，识别出类间和对详见的关系，实现类和对象。

3. OMT方法

OMT是对象建模技术的缩写，主要用于分析、系统设计和对象设计。包括对象模型（静态的、结构化的系统的“数据”性质，通常采用类图）、动态模型（瞬时的、行为化的系统“控制”性质，通常使用状态图）和功能模型（表示变化的系统的“功能”性质，通常使用数据流图）。OMT方法的三大模型如下表

模型	说明	主要技术
对象模型	描述系统中对象的静态结构、对象之间的关系、属性、操作。它表示静态的、结构上的、系统的“数据”特征	对象图
动态模型	描述与时间和操作顺序有关的系统特征，如激发事件、事件序列、确定事件先后关系的状态。它表示瞬时、行为上的、系统的“控制”特征	状态图
功能模型	描述与值的变换有关的系统特征：功能、映射、约束和函数依赖	数据流图

4. OOSE方法

面向对象软件工程的缩写。它在OMT的基础上，对功能模型进行了补充，提出了“用例”的概念，最终取代数据流图进行需求分析和建立功能模型。

8.4.3 统一建模语言

1. UML是什么

• UML是一种语言。为软件开发人员之间提供给了一种用于交流的词汇表和一种用于软件蓝图的标准语言。
• UML是一种可视化语言
• UML是一种可用于详细描述的语言：UML所建的模型是精确的、无歧义和完整的，因此适合于对所有重要的分析、设计和实现决策进行详细描述。
• UML是一种构造语言
• UML是一种文档化语言：适合于建立系统架构及其所有的细节文档。

2. UML的结构

UML由构造快、公共机制和架构三个部分组成。

1. 构造块。构造块也就是基本的UML建模元素（事物）、关系和图。
   
   • 建模元素：包括结构事物（类、接口、协作、用例、活动类、组件、节点等）、行为事物（交互、状态机）、分组事物（包）、注释事物。
   • 关系：包括关联关系、依赖关系、泛化关系、实现关系。
   • 图：UML2.0包括14中不同的图，分为表示系统静态结构的静态模型（包括类图、对象图、包图、构件图、部署图、制品图），以及表示系统动态结构的动态模型（包括对象图、用例图、顺序图、通信图、定时图、状态图、活动图、交互概览图）。
2. 公共机制。指达到特定目标的公共UML方法。
   
   • 规格说明：规格说明是元素语义的文本描述，它是模型的重要组成部分。
   • 修饰：UML为每一个模型元素设置了一个简单的记号，还可以通过修饰来表达更多的信息。
   • 公共分类：包括类元与实体（类元表示概念，而实体表示具体的实体）、接口和实现（接口用来定义契约，而实现就是具体的内容）两组公共分类。
   • 扩展机制：包括约束（添加新规则来扩展元素的语义）、构造型（用于定义新的UML建模元素）、标记值（添加新的特殊信息来扩展模型元素的规格说明）。
3. 架构。UML对系统架构的定义是：系统的组织结构，包括系统分解的组成部分、它们的关联性、交互、机制和指导原则，这些提供系统设计的信息。而具体来说，就是指5个系统视图。
   
   • 逻辑视图：以问题域的词汇组成的类和对象集合。
   • 进程视图：可执行县城和进程作为活动类的建模，它是逻辑视图的一次执行实例。
   • 实现视图：对组成基于系统的物理代码的文件和组件进行建模
   • 部署视图：把组件物理的部署到一组物理的、可计算的节点上。
   • 用例视图：最基本的需求分析模型

3. 用例图基础

用例实例实在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例。

用例模型描述的是外部参与者所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。

1. 参与者。参与者代表与系统接口的任何事物或人，是指代表某一种特定功能的角色。因此，参与者都是虚拟的概念。在UML中，用一个小人表示参与者
2. 用例。用例是对系统行为的动态描述，它可以促进设计人员、开发人员与用户的沟通，理解正确的需求、还可以划分系统和外部实体的界限，是系统设计的起点。
3. 包含和扩展。两个用例之间的关系可以主要概况为两种情况。一种是用于重用的包含关系，用构造型<<include>>或者<<use>>表示；另一种是用于分离出不同的行为，用构造型<<extend>>表示。
   
   • 包含关系：当可以从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一个组件来实现某一个用例的部分功能是很重要的事时，应该使用包含关系来表示。所提取出来的公共行为称为抽象用例。
   • 扩展关系：如果一个用例明显的混合了两种或两种以上的不同场景，即根据情况可能发生多种事情。可以将这个用例分为一个主用例和一个或多个辅用例，描述可能更加清晰。

4. 类图和对象图基础

在面向对象建模技术中，将客观世界的实体映射为对象，并归纳成一个个类。类、对象和它们之间的关联是面向对象技术中最基本的元素。对于一个想要描述的系统，其类型和对象模型揭示了系统的结构。在UML中，类和对象模型分别由类图和对象图表示。类图是OO方法的核心。

1. 类和对象。通常用对象描述客观世界中某个具体的实体。类是对一类具有相同特征的对象的描述。对象是类的实例。在UML中，类的可视化表示为一个划分成三个格子的长方形（下面两个格子可省略）。
   
   • 类的获取和命名：最顶部的格子包含类的名称。
   • 类的属性：中间的格子包含类的属性，用以描述该类对象的共同特点。该项可省略。UML规定类的属性的语法为：“可见性 属性名：类型 = 默认值 {约束特性}”。
     可见性包括Public、Private和Protected，分别用+、-、#表示。
     类型表示该类的种类，它可以是基本数据类型，例如整数、实数、布尔型等，也可以使用户自定义的类型。一般它由所涉及的程序设计语言确定。
     约束特性则是用户对该属性性质的一个约束说明。例如“{只读}”说明该属性是只读属性。
   • 类的操作：该项可省略。操作用于修改、检索类的属性或执行某些动作。操作通常也被称为功能，但是它们被约束在类的内部，只能作用到该类的对象上。操作名、返回类型和参数表组成操作界面。UML规定操作的语法为“可见性：操作名（参数表）：返回类型 {约束特性}”。
     类图描述了类和类之间的静态关系。
2. 类之间的关系。关系是事物间的连接，在面向对象建模中，有4个很重要的关系。
   
   • 依赖关系。有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于元素X。在UML中，使用带箭头的虚线表示依赖关系。
   • 泛化关系。描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系。也就是说子类是从父类中集成的，而父类则是子类的泛化。在UML中，使用带空心箭头的实线表示，箭头指向父类。
     在UML中，对泛化关系有三个要求：
     a. 子类应与父类完全一致，父类所具有的关联、属性和操作，子类都应具有。
     b. 子类中除了与父类一致的信息外，还包括额外的信息。
     c. 可以使用父类实例的地方，也可以使用子类实例。
   • 关联关系。关联表示两个类之间存在某种语义上的联系。在UML中，用一条实线来表示关联关系。
     a. 聚合关系：聚合表示类之间的关系是整体和部分的关系。在UML中，用一个带空心菱形的实线表示，空心菱形指的是代表“整体”的类。
     b. 组合关系：如果聚合关系中的表示“部分”的类存在，与表示“整体”的类有着紧密的关系，那么就应该使用“组合”关系来表示。在UML中，用带有实心菱形的实线表示，菱形指向的是代表“整体”的类。
   • 实现关系。是用来规定接口和实现接口的类或组件之间的关系的。接口是操作的集合，这些操作用于规定类或组件的服务。在UML中，用一个带空心箭头的虚线表示。
3. 多重性问题：重复性又称多重性，多重性表示为一个整数范围n...m，整数n定义所连接的最少对象的数目，而m则为最多对象数（当不知道确切的最大数时，最大数用表示）。最常见的多重性有：0...1;0...;1...1;1...;。
   多重性是用来说明关联的两个类之间的数量关系的。
4. 类图。对于软件系统，其类模型和对象模型类图描述类和类之间的静态关系。与数据模型不同，它不仅显示了信息的结构，同时还描述了系统的行为。类图是定义其他图的基础。
5. 对象图。UML中对象图与类图有相同的表示形式。对象图可以看做是类图的一个实例。对象是类的实例；对象之间的链是类之间的关联的实例。对象与类的图形表示相似，均为划分成两个格子的长方形（下面的格子可省略）。上面的格子是对象名，对象名下有下划线；下面的格子记录属性值。链的图形表示与关联相似。对象图常用于表示复杂类图的一个实例。

5. 交互图基础

交互图是表示各组对象如何依赖某种行为进行写作的模型。通常可以使用一个交互图来表示和说明一个用例的行为。

1. 顺序图。用来描述对象之间动态的交互欢喜，着重体现对象间消息传递的时间顺序。顺序图允许直观的表示出对象的生存期，在生存期内，对象可以对输入消息作出响应，并且可以发送信息。
   对象间的通信通过在对象的生命线上画消息来表示。消息的箭头知名消息的类型。顺序图中的消息可以使信号、操作调用或类似于C++中的RPC和JAVA中的RMI。当收到消息时，接收对象立即开始执行活动，即对象被激活了。通过在对象生命线上显示一个细长矩形框来表示激活。
   消息可以用消息名及参数来标识，消息也可带有顺序号。消息还可以带有条件表达式，表示分支或决定是否发送消息。如果用于表示分支，则两个分支是相互排斥的，即在某一时刻仅可发送分支中的一个消息。
2. 通信图。用于描述相互合作的对象间的交互关系和链接关系。顺序图着重体现交互的时间顺序，通信图则着重体现交互对象间的静态链接关系。
3. 定时图。着重表示定时约束的定时图。
   根据UML的定义，定时图实际上是一种特殊形式的顺序图，它与顺序图的区别主要在几个方面：
   
   • 坐标轴交换了位置，改为从左到右来表示时间的推移。
   • 用生命线的“凹下凸起”来表示状态的变化，每个水平位置代表一种不同的状态，状态的顺序可以有意义、也可以没有意义。
   • 生命线可以跟在一根线后面，在这根线上显示一些不同的状态值。
   • 可以显示一个度量时间值得标尺，用刻度表示时间间隔。
     定时图的土元包括生命线、状态、状态变迁、消息、时间刻度。

6. 状态图基础

用来描述一个特定对象的所有可能状态及其引起状态转移的事件。一个状态图包括一系列状态及状态之间的转移。

状态图包括以下部分：
- 状态：又称为中间状态，用圆角矩形框表示
- 初始状态：又称为初态，用一个黑色的实心圆圈表示，在一张状态图中只能够有一个初始状态。
- 结束状态：又称为终态，在黑色的实心圆圈外面套上一个空心圆，在一张状态图中可能有多个结束状态。
- 状态转移：用箭头说明状态的转移情况，并用文字说明引发这个状态变化的相应事件是什么。

一个状态也可能被细分成为多个子状态，那么如果将这些子状态都描绘出来的话，那么这个状态就是符合状态。

7. 活动图基础

活动图是由状态图变化而来的。活动图依据对象状态的变化来捕获动作（将要执行的工作或活动）与动作的结果。活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的变迁可能需要事件的触发）。

1. 基本活动图。活动图与状态图类似，包括了初始状态、终止状态，以及中间的活动状态，每个活动之间也就是一种状态的变迁。在活动图中，还引入了以下几个概念：
   
   • 判定：说明基于某些表达式的选择性路径，在UML中用菱形表示。
   • 分支与组合：处理并发流，UML中使用粗线表示。
2. 带泳道的活动图。将活动图的逻辑描述与顺序图、协作图的责任描述结合起来。
3. 对象流：在活动图中可以出现对象。对象可以作为活动的输入或输出，对象与活动间的输入/输出关系用虚线箭头来表示。如果仅表示对象受到某一活动的影响，则可用不带箭头的虚线来连接对象与活动。
4. 信号：在活动途中可以表示信号的发送与接收，分别用发送与接收标识来表示。发送和接收标识也可与对象相连，用于表示消息的发送者和接收者。

8. 构件图基础

构件图是面向对象系统的物理方面进行建模要用的两种图之一。它可以有效的显示一组构件，以及他们之间的关系。构件图中通常包括构件、接口及各种关系。

通常构件值得是源代码文件、二进制代码文件和可执行文件等。而构件图就是用来显示编译、链接或执行时构件之间的依赖关系的。通常来说，可以使用构件图完成以下工作：

• 对源代码进行建模：这样可以清晰地表示出各个不同源程序文件之间的关系。
• 对可执行体的发布建模：将清晰地表示出各个可执行文件、DLL文件之间的关系。
• 对物理数据库建模：用来表示各种类型的数据库、表之间的关系。
• 对可调整的系统建模

在绘制构件图时，应该注意侧重于描述系统的静态实现视图的一个方面，图形不要过于简化，应该为构件图取一个直观的名称，在绘制时避免产生线的交叉。

9. 部署图基础

也成为实施图，和构件图一眼个，是面向对象系统的物理方面建模的两种图之一。构件图说明构建之间的逻辑关系，而部署图是在此基础上更进一步的描述系统硬件的物理拓扑结构及在此结构上运行的软件构件，常用于帮助理解分布式系统。通常包括以下一些关键的组成部分：

1. 节点和连接。节点代表一个物理设备及其上运行的软件系统。在UML中，使用一个立方体表示一个节点，节点名放在左上角。节点之间的连线表示系统之间进行交互的通信路径，在UML中被称为连接。通信类型则放在连接旁边的“《》”之间，表示所用的通信协议或网络类型
2. 构件和接口。在部署图中，构件代表可执行的物理代码模块，如一个可执行程序。
   在面向对象方法中，类和构件等元素并不是所有的属性和操作都对外可见。他们对外提供了可见操作和属性，称之为类和构件的接口。界面可以表示为一头是一个小圆圈的直线。

8.5 用户界面设计

接口设计主要包括三个方面的内容：一是设计软件构件间的接口；二是软件设计模块和其他非人的信息生产者和消费者（如外部实体）的接口；三是人（如用户）和计算机间的界面设计。

8.5.1 用户界面设计的原则

设计时必须遵从三个黄金法则

• 置用户与控制之下：具体来说就是以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式、提供灵活的交互、允许用户交互时可以被中断和撤销、当技能级别增长时可以使交互流水化并允许定制交互、使用户隔离内部细节、设计应允许用户和出现在屏幕上的对象直接交互。
• 减少用户的记忆负担：具体来说就是减少对短期记忆的要求、建立有意义的默认、定义直觉性的捷径、界面的视觉布局应该基于对真实世界的隐喻、以不断进展的方式提示信息。
• 保持界面的一致性：具体来说就是允许用户将当前任务放入有意义的语境、在应用系列内保持一致性，如果过去的交互模型已经建立了用户期望，除非有不得已的理由，否则不要改变它。

用户界面设计原则如下：

原则	描述
用户熟悉	界面所使用的术语和概念应该来自于用户的经验，这些用户是将来要使用系统最多的人。
意外最小化	永远不要让用户对系统的行为感到吃惊。
可恢复性	界面应该有一种机制来允许用户从错误中恢复
用户指南	在错误发生时，界面应该提供有意义的反馈，并有上下文感知能力的用户帮助功能。
用户差异性	界面应该为不同类型用户提供合适的交互功能

8.5.2 用户界面设计过程

用户界面的设计过程也应该是迭代的，它通常包括4个不同的框架活动：

1. 用户、任务和环境分析：着重于分析将和系统交互的用户的特点，记录下技术级别、业务理解和对新系统的一般感悟，并定义不同的用户类别。然后对用户将要完成什么样的任务进行详细的标识和描述。最后对用户的物理工作环境进行了解和分析。
2. 界面设计：主要包括建立任务的目标和意图，为每个目标或意图定制特定的动作序列，按在界面上执行的方式对动作序列进行规约，指明系统状态，定义控制机制，指明控制机制如何影响系统状态，指明用户如何通过界面上的信息来解释系统状态。
3. 实现：就是根据界面设计进行实现，前期可以通过原型工具来快速实现，减少返工的工作量。
4. 界面确认：界面实现后就可以进行一些定性和定量的数据收集，以进行界面的评估，以调整界面的设计。

8.6 工作流设计

8.6.1 工作流设计概述

工作流是一类能够完全或者部分自动执行的经营过程，根据一系列过程规则、文档、信息或任务在不同的执行者之间传递、执行。

1. 工作流。是现实中的具体工作从开始到结束过程的抽象和概括。这个过程包括了众多因素：任务顺序、路线规则、时间时限约束等。
2. 流程定义。是指对业务过程的形式化表示，定义了过程运行中的活动和所涉及的各种信息。这些信息包括过程的开始和完成条件、构成过程的活动和进行活动间导航的规则、用户所需要完成的任务、可能被调用的应用、工作流间的引用关系，以及工作流数据的定义。
3. 流程实例。常称为工作，是一个流程定义的运行实例。
4. 工作流管理系统。与数据库管理系统类似，是一个软件系统。这个程序存储流程的定义，按照所使用的流程定义来触发流程状态的改变，推动流程的运转。这个推动的依据常常被称为工作流引擎。
5. 流程定义工具。同样是一套软件系统。可能是独立的软件，也可能是工作流管理系统的一部分。
6. 参与者。回答业务流程中“谁”这个问题。
7. 活动。活动是流程定义中的一个元素，一次活动可能改变流程处理数据的内容、流程的状态，并可能将流程推动到其他活动中去。活动可以有人来完成，也可以是系统自动的处理过程。
8. 活动所有者。参与者之一，它有权决定该活动是否结束，当他决定活动结束时，将活动推动到其他活动中，可能是下一个活动，也可能是前一个活动。
9. 工作所有者。是有权整体控制流程实例执行过程的参与者。
10. 工作项。代表流程实例中活动的参与者将要执行的工作。

要分析现实中的处理流程，必须首先描述目标系统的流程，这个过程也可以称为建模。

8.6.2 工作流管理系统

是一种“在工作流形式化表示的驱动下，通过软件的执行而完成工作流定义、管理及执行的系统”，其主要目标是对业务过程中各活动发生的先后次序及与活动相关的相应人力或信息资源的调用进行管理，而实现业务过程的自动化。工作流管理系统的六个基本模块的参考模型如下：

1. 流程定义工具。这部分软件提供图形化或者其他方式的界面给设计者。由设计者将实际工作流程进行抽象，并将设计者提交的流程定义转换为形式化语言描述，提供给计算机工作流执行服务进行流程实例处理的一句。
2. 工作流执行服务。这个服务程序是工作流管理系统的核心，它使用一种或多种数据流引擎，对流程定义进行解释，激活有效的流程实例，推动流程实例在不同的活动中运转。和客户应用程序、其他工作流服务执行程序进行交互，从而完成流程实例的创建、执行和管理工作。同时这部分软件为每个用户维护一个活动列表告诉用户当前必须处理的任务。如果有必要，还可以通过电子邮件甚至短消息的形式提醒用户任务的到达。
3. 其他工作流执行服务。
4. 客户应用程序。这是给最终用户的界面，用户通过使用这部分软件对工作流的数据进行必要的处理，如果用户是当前活动的拥有者，还可以通过客户应用程序改变流程实例的活动，将流程实例推动到另一个活动中。
5. 被调用应用程序。
6. 管理和监控工具。

8.7 简单分布式计算机应用系统的设计

8.8 系统运行环境的集成和设计

1. 集中式系统

所有操作都集中于一台主机中，而操作员必须在主机的附近操作。集中式系统常见于银行、保险、证券行业。集中式系统由以下几个部分组成：

1. 单计算机结构；这种结构简单、容易维护，但是处理能力受到限制。
2. 集群结构：由多个计算机组成，这些计算机具有类似的硬件平台、操作系统等。通常采用负载均衡、资源共享等方式实现更大的处理能力和容量。
3. 多计算机结构：由多个计算机组成，这些计算机之间操作环境可能不同。适用于当系统可以分解成多个不同的子系统时。

2. 分布式系统

3. C/S结构

4. 多层结构

这种结构是C/S结构的扩展，典型的分为由存储数据的数据库服务器作为数据层、实现商业规则的程序作为逻辑层、管理用户输入输出的视图层所组成的三层结构。

多层结构形式复杂、工鞥多余，实现多层结构常常需要来实现不同层次建通信的专门程序——管件，也称为中间件。中间件大多数实现远程程序调用、对象请求调度等功能。

5. Internet、Intranet和Extranet

Internet是全球的网络集合，使用通用的TCP/IP协议来相互连接。Internet提供了电子邮件、文件传输、远程登录等服务。Intranet是私有网络，只限于内部使用，也使用TCP/IP协议。Extranet是一个扩展的Intranet。它包括企业之外的和企业密切相关合作的其他企业。Extranet允许分离的组织交换信息并进行合作，这样就形成了一个虚拟组织，现在的VPN技术允许在公用网络上架构支队组织内部开发服务。

8.9 系统过渡计划

1. 直接过渡

当新系统运行时，立即关闭原来的系统

2. 并行过渡

让新系统和旧系统在一段时间里同时运行

3. 阶段过渡

适用于分阶段开发的系统。

第九章 软件架构设计

9.1 软件架构概述

9.1.1 软件架构的定义

定义1：软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构有软件元素、元素的外部可见属性及他们之间的关系组成。

定义2：软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式的约束组成。

定义3：软件架构是指一个系统的基础组织，它具体体现在：系统的构件，构建之间、构件和环境之间的关系，以及知道其设计和烟花的原则上。

为更好的理解软件架构的定义，特作如下说明：

1. 架构是对系统的抽象，它通过描述元素、元素的外部可见属性，以及元素之间的关系来反映这种抽象。因此，仅与内部具体实现有关的细节是不属于架构的，即定义强调元素的“外部可见”属性。
2. 架构有多个结构组成，结构是从功能角度来描述元素之间的关系的，具体的结构传达了架构某方面的信息，但是个别结构一般不能代表大型软件架构。
3. 任何软件都存在架构，但不一定有对盖家沟的具体表述文档。即架构可以独立于架构的描述而存在。如文档已过时，则该文档不能反映架构。
4. 元素及其行为的集合构成架构的内容。体现系统由哪些元素组成，这些元素各有哪些功能（外部可见），以及这些元素间如何连接与互动。即在两个方面进行抽象：在静态方面，关注系统的大粒度（宏观）总体结构（如分层）；在动态方面，关注系统内关键行为的共同特征。
5. 架构具有“基础”性：它通常涉及解决各类关键的重复问题的通用方案（复用性），以及系统设计中影响深远（架构敏感）的各类重要决策（一旦贯彻，更改的代价昂贵）。
6. 架构隐含有“决策”，即架构是由架构设计师根据关键的功能和非功能性需求（质量属性即项目相关的约束）进行设计和决策的结果。不同的架构设计师设计出来的架构是不一样的，为了避免架构设计师考虑不周，重大决策应该经过评审。特别是架构设计师自身的水平是一种约束。

在设计软件架构时也必须考虑硬件特性和网络特性。架构设计师通常将架构的重点放在软件部分。

1. 影响架构的因素。软件系统的项目干系人（客户、用户、项目经理、程序员、测试人员、市场人员等）对软件系统有不同的要求，开发组织（项目组）有不同的人员知识结构、架构设计师的素质和经验、当前技术环境等方面都是影响架构的因素。
   这些因素通过功能性需求、非功能性需求、约束条件及相互冲突的要求，影响架构设计师的决策，从而影响架构。
2. 架构对上述诸因素具有反作用。系统的示范性、架构的可复用性及团队开发经验的提升，同时，成熟的系统将影响客户对下一个系统的要求等。这种反馈机制构成了架构的商业周期。

9.1.2 软件架构的重要性

从技术角度看，软件架构的重要性表现为如下几个方面：

1. 项目关系人之间交流的平台。
2. 早期设计决策。从软件生命周期来看，软件架构是所开发系统的最早设计决策的体现，主要表现为：
   
   • 架构明确了对系统实现的约束条件：架构是架构设计师对系统实现的各方面进行权衡的结果，是总体设计的体现，因此，在具体实现时必须按架构的设计进行。
   • 架构影响着系统的质量属性。
   • 架构可以用来预测系统的质量。
   • 架构为维护的决策提供依据。在架构层次上能为日后的更改决策提供推理、判断的依据。
   • 架构有助于原型开发。可以按照架构构造一个骨架系统。
   • 借助于架构进行成本和进度的估计。
3. 在较高层面上实现软件复用。软件架构作为系统的抽象模型，可以在多个系统间进行传递（复用），特别是比较容易的应用到具有相似质量属性和功能需求的系统中。产品线通常可以共享一个脚骨。
4. 架构对于开发的指导和规范意义不容忽略。

从软件开发过程来看，如果采用传统的软件开发模型（生命周期模型），则软件架构的建立应位于概要设计之前、需求分析之后。

基于架构的软件开发模型则明确的把整个软件过程划分为架构需求、设计、文档化、评审（评估）、实现、演化等6个子过程。

9.1.3 架构的模型

软件架构可以归纳为5种模型：结构模型、框架模型、动态模型、过程模型和功能模型。最常用的是结构模型和动态模型。

1. 结构模型。是一个最直观、最普遍的建模方法。这种方法以加过的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是架构描述语言。
2. 框架模型。与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
3. 动态模型。是对结构或框架模型的补充，研究系统“大颗粒”的行为性质。例如，描述系统的重新配置或演化。动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。
4. 过程模型。研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。
5. 功能模型。该模型认为架构是由一组功能构件按层次组成，且下层向上层提供服务。可以看做是一种特殊的框架模型。

“4+1”的视图模型从5个不同的侧面，即逻辑视图、进程视图、物理视图、开发视图和场景来描述软件架构。每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件架构的全部内容。

1. 逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不仅可以用来进行功能分析，而且可以用作标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问题是要保持一个单一的，内聚的对象模型贯穿整个系统。
2. 进程视图：侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的主要抽象的进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。
3. 物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。当软件运行于不同的节点上时，各视图中的构件都直接或间接的对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其它视图的影响最小。
4. 开发视图：也称为模块视图，主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织。这样一个软件系统就可以由不同的人进行开发。开发视图要考虑软件内部的需求，如软件的容易醒、软件的重用性和通用性，要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统输入输出关系的模型图和子系统图来描述，可以在确定了软件包含的所有元素之后描述完整的开发角度，也可以在确定每个元素之前，列出开发视图原则。
5. 场景：可以看做是那些重要活动的抽象，它是四个视图有机的联系起来，从某种意义上说，场景是最重要的需求抽象。在开发架构中，它可以帮助设计者找到架构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用该图形小时。

9.2 架构需求与软件质量属性

软件属性包括功能属性和质量属性。但是，软件架构师重点关注的是质量属性。

9.2.1 软件质量属性

软件质量特性包括功能性、可靠性、易用性、效率、可维护性、可移植性等六个方面，每个方面都包含若干子特性。

• 功能性：适合性、准确性、互操作性、依从性、安全性；
• 可靠性：成熟性、容错性、易恢复性；
• 易用性：易理解性、易学性、易操作性；
• 效率：时间特性、资源特性；
• 可维护性：易分析性、易改变性、稳定性、易测试性；
• 可移植性：适应性、易安装性、遵循性、易替换性；

1. 运行期质量属性

• 性能： 指软件系统及时提供相应服务的能力。包括速度、吞吐量和持续高速性三个方面的要求。
• 安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
• 易用性：指软件系统易于被使用的程度。
• 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
• 互操作性：指本软件系统和其他软件系统交换数据和相互调用服务的难易程度。
• 可靠性：软件系统在一定的时间内无故障运行的能力。
• 持续可用性：指系统长时间无故障运行的能力。与可靠性相关联，常将其纳入可靠性中。
• 鲁棒性：指软件系统在一些非正常情况下（如用户进行了非法操作、相关的软硬件系统发生了故障等）下仍能正常运行的能力，也称健壮性或容错性。

2. 开发期质量属性

• 易理解性：指设计被开发人员理解的难易程度。
• 可扩展性：软件因适应新需求或需求变化而增加新功能的能力。也称为灵活性。
• 可重用性：指重用软件系统或某一部分的难易程度。
• 可测试性：对软件测试以证明其满足需求规范的难易程度。
• 可维护性：当需求修改缺陷、增加功能、提供质量属性时，定位修改点并实施修改的难易程度。
• 可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

下表反映了质量属性之间的相互制约关系（正相关或负相关），其中“+”代表“行属性”能促进“列属性”；而“-”则相反。

~	性能	安全性	持续可用性	可互操作性	可靠性	鲁棒性	易用性	可测试性	可重用性	可维护性	可扩展性	可移植性
性能				-	-	-	-	-		-	-	-
安全性	-			-			-	-	-
持续可用性					+	+
可互操作性	-	-									+	+
可靠性	-		+			+	+	+		+	+
鲁棒性	-		+		+		+
易用性	-					+		-
可测试性	-		+		+		+			+	+
可重用性	-	-		+	-			+		+	+	+
可维护性	-		+		+			+			+
可扩展性	-	-			+			+		+		+
可移植性	-			+			-	+	+	-	+

9.2.2 6个质量属性及实现

从架构关注点角度，将质量属性分为六种：可用性、可修改性、性能、安全性、可测试性、易用性。

质量属性场景由以下六个部分组成：

• 刺激源：生成该刺激的实体（人、计算机系统或其他激励器）
• 刺激：到达系统时可能产生的影响（即需要考虑和关注的情况）
• 环境：该刺激在某条件内发生。如系统可能正处于过载情况。
• 制品：系统中受刺激的部分（某个制品被刺激）
• 响应：刺激到达后所采取的行动
• 响应度量：当响应发生时，应能够以某种方式对其度量，用于是否满足需求的测试。

需要将一般的质量属性场景与具体的质量属性场景区别开来，前者是指独立于具体系统、适合于任何系统的一般性场景；而后者是指适合于正在考虑的某个特定系统的场景，具体场景通常是指从一般场景中抽取特定的、面向具体系统的内容。

实现这些质量属性的基本设计决策，称为”战术“，而把战术的集合称为”架构策略“。这些架构策略工架构设计师选择。

1. 可用性及其实现战术

1. 可用性的描述

场景的部分	可能的值
刺激源	系统内部、系统外部
刺激	错误：疏忽（构件对某输入未作出反应）、崩溃、时间不当（响应时间太早或太迟）、响应不当（以一个不正确的值来响应）
制品	系统的处理器、通信通道、存储器、进程
环境	正常操作、降级模式
响应	系统应检测事件，并进行如下一个或多个活动： 使其记录下来 通知合适的各方，包括用户和其他系统 根据规则屏蔽导致错误或故障的事件源 不可用（进入修理状态） 继续在正常或降级模式下运行
响应度量	可用时间、修复时间、各种情况的时间间隔

2. 可用性战术

目标是阻止错误发展成故障，至少能够把错误的影响限制在一定范围内，从而使修复称为可能。战术分为：错误检测、错误恢复、错误预防。

1. 错误检测
   
   • 命令/响应：一个构件发出一个命令，并希望在预定义的时间内收到一个来自审查构件的响应，例如远程错误的检测
   • 心跳（计时器）：一个构件定期发出一个信条消息，另一个构件收听到消息。如果未收到心跳消息，则嘉定构件失败，并通知错误纠正构件。
   • 异常：当出现异常时，异常处理程序开始执行。
2. 错误恢复
   
   • 表决：通过冗余构件（或处理器）与表决器连接，构件按相同的输入及算法计算输出值给表决器，由表决器按表决算法（如多数规则）确定是否有构件出错，表决通常用在控制系统中。
   • 主动冗余（热重启、热备份）：所有的冗余构件都以并行的方式对事件作出相应。它们都处在相同的状态，但仅使用一个构件的响应。丢弃其余构件的响应。错误发生时通过切换的方式使用另一个构件的响应。
   • 被动冗余（暖重启/双冗余/三冗余）：一个构件（主构件）对事件作出响应，并通知其他构件（备用的）必须进行的状态更新（同步）。当错误发生时，备用构件从最新同步点接替主构件的工作。
   • 备件：是计算平台配置用于更换各种不同的故障构件。
   • 状态再同步：主动和被动冗余战术要求所恢复的构件在重新提供服务前更新其状态。更新方法取决于可以承受的停机时间、更新的规模以及更新的内容多少。
   • 检查点/回滚：检查点就是使状态一致的同步点，它或者是定期进行，或者是对具体事件作出响应。当在两个检查点之间发生故障时，则以这个一致状态的检查点（有快照）和之后发生的事务日志来恢复系统（数据库中常使用）。
3. 错误预防
   
   • 从服务中删除：如删除进程再重新启动，以防止内存泄漏导致故障的发生。
   • 事务：使用事务来保证数据的一致性，即几个相关密切的步骤，要么全成功，要不全不成功。
   • 进程监视器：通过监视进程来处理进程的错误。

2. 可修改性及其实现战术

1. 可修改性的描述

场景的部分	可能的值
刺激源	最终用户、开发人员、系统管理员
刺激	增加/删除/修改/改变：功能、质量属性、容量
制品	用户界面、平台、环境或关联系统
环境	运行时、编译时、构建时、设计时
响应	查找要修改的位置、进行修改（不影响其他功能）、进行测试、部署所修改的内容
响应度量	对修改的成本进行度量，对修改的影响进行度量

2. 可修改性战术

1. 局部化修改。在设计期间为模块分配责任，以便把预期的变更限制在一定的范围内，从而降低修改的成本。
   
   • 维持语义的一致性：语义的一致性指的是模块中责任之间的关系，是这些责任能够协同工作，不需要过多的依赖其他模块。耦合和内聚指标反映一致性，应该根据一组预期的变更来度量语义一致性。使用”抽象通用服务“（如应用框架的使用和其他中间软件的使用）来支持可修改性是其子战术。
   • 预期期望的变更：通过对变更的预估，进行预设、准备，从而使变更的影响最小。
   • 泛化该模块：使一个模块更通用、更广泛的功能
   • 限制可能的选择：如在更换某一模块（如处理器）时，限制为相同家族的成员。
2. 防止连锁反应。由于模块之间有各种依赖性，因此，修改会产生连锁反应。防止连锁反应的战术如下：
   
   • 信息隐藏：就是把某个实体的责任分解为更小的部分，并选择哪些信息称为公有的，哪些称为私有的，通过接口获得公有责任。
   • 维持现有的接口：尽可能维持现有接口的稳定性。例如通过添加接口（通过新的接口提供新的服务）可以达到这一目的。
   • 限制通信路径：限制于一个给定的模块共享数据的模块。这样可以减少由于数据产生/使用引入的连锁反应。
   • 仲裁者的使用：在具有依赖关系的两个模块之间插入一个仲裁者，以管理与该依赖相关的活动。仲裁者有很多种类型，例如：桥、调停者、代理等就是可以提供把服务的语法从一种形式转换为另一种形式的仲裁者。
3. 推迟绑定时间。系统具备在运行时进行绑定并允许非开发人员进行修改（配置）。
   
   • 运行时注册：支持即插即用
   • 配置文件：在启动时设置参数
   • 多态：在方法调用的后期绑定
   • 构件更换：允许载入时绑定

3. 性能及其实现战术

1. 性能的描述

场景的部分	可能的值
刺激源	系统外部或内部
刺激	定期事件、随机事件、偶然事件
制品	系统
环境	正常模式、超载模式
响应	处理刺激、改变服务级别
响应度量	度量等待、期限、吞吐量、缺失率、数据丢失等

2. 性能战术

性能与时间相关，影响事件的响应时间有两个基本因素：

• 资源消耗：事件到达后进入一系列的处理程序，每一步处理都要占用资源，而且在处理过程中消息在各构件之间转换，这些转换也需要占用资源。
• 闭锁时间：指对事件处理时碰到了资源争夺、资源不可用或对其他计算的依赖等情况，就产生了等待时间。

性能的战术有如下几种：

1. 资源需求
   
   • 减少处理事件流所需的资源：提高计算效率（如改进算法）、减少计算开销（如在可修改性与性能之间权衡，减少不必要的代理构件）。
   • 减少所处理事件的数量：管理事件屡，控制采样频率。
   • 控制资源的使用：限制执行时间（如减少迭代次数）、限制队列大小。
2. 资源管理
   
   • 引入并发
   • 维持数据或计算的多个副本：C/S结构中客户机C就是计算的副本，他能减少服务器计算的压力；高速缓存可以存放数据副本（在不同速度的存储器之间的缓冲）。
   • 增加可用资源：在成本允许时，尽量使用速度更快的处理器、内存和网络。
3. 资源仲裁
   资源仲裁战术是通过如下调度策略来实现的
   
   • 先进/先出FIFO
   • 固定优先级调度：先给事件分配特定的优先级，再按优先级高低顺序分配资源。
   • 动态优先级调度：轮转调度、时限时间最早邮线
   • 静态调度；可以离线确定调度。

4. 安全性及其实现战术

1. 安全性的描述

场景的部分	可能的值
刺激源	对敏感资源进行访问的人或系统（合法的、非法的）
刺激	试图：显示数据、改变/删除数据、访问系统服务、降低系统服务的可用性
制品	系统服务，系统中的数据
环境	在线或离线、联网或断网、有或无防火墙
响应	对用户身份验证；阻止或允许对数据或服务的访问；授予可回收访问权；加密信息；限制服务的可用性；通知用户或系统
响应度量	增加安全性的成本；检测或确定攻击的可能性；降低服务级别后的成功率；恢复数据/服务

2. 安全性战术

包括抵抗攻击、检测攻击和从攻击中恢复。

1. 抵抗攻击
   
   • 对用户进行身份验证：包括动态密码、一次性密码、数字证书及生物识别码
   • 对用户进行授权：即对用户的访问进行控制管理
   • 维护数据的机密性：一般通过对数据和通信链路进行加密来实现
   • 维护完整性：对数据添加校验或哈希值
   • 限制暴露的信息
   • 限制访问：如用防火墙，DMZ策略。
2. 检测攻击。一般通过“入侵检测”系统进行过滤、比较通信模式与历史基线等方法。
3. 从攻击中恢复
   
   • 恢复：与可用性中的战术相同
   • 识别攻击者：作为审计追踪，用于预防性或惩罚性目的。

5. 可测试性及其实现战术

1. 可测试性的描述

场景的部分	可能的值
刺激源	各类测试人员（单元测试、集成测试、验收、用户）
刺激	一种测试
制品	设计、代码段、完整的应用
环境	设计时，开发时、编译时、部署时
响应	提供测试的状态值、测试环境与案例的准备
响应度量	测试成本、出现故障的概率、执行时间等。

2. 可测试性战术

1. 输入/输出
   
   • 记录/回放：指捕获跨接口的信息，并将其作为测试专用软件的输入
   • 将接口与实现分离：允许使用实现的替代（模拟器）来支持各种测试目的
   • 优化访问线路/接口：用测试工具来捕获或赋予构件的变量值。
2. 内部监控。当监视器处于激活状态时，记录事件（如通过接口的信息）

6. 易用性及其实现战术

1. 易用性的描述

场景的部分	可能的值
刺激源	最终用户
刺激	学习系统特性、有效使用系统、使错误的影响最低、适配系统、对系统满意
制品	系统
环境	运行时或配置时
响应	支持“学习系统特性”的响应：界面为用户所熟悉或使用帮助系统 支持“有效使用系统”的响应：数据/命令聚合或复用；界面是导航；操作的一致性；多个活动同时进行 支持“使错误的影响最低”的响应：撤销/取消；从故障中恢复；识别并纠正用户错误；验证系统资源 支持“适配系统”的响应：定义能力；国际化 支持“对系统满意”的响应：显示系统状态；与用户的节奏合拍
响应度量	从最终用户的角度进行度量，如：学习成本、错误数量、解决问题的数量、满意度等

2. 易用性战术

1. 运行时战术
   
   • 任务的模型：维护用户的信息，使系统了解用户试图做什么，并提供各种协助
   • 用户的模型：维护用户的信息，例如使系统以用户可以阅读页面的速度滚动页面。
   • 系统的模型：维护系统的信息，它确定了期望的系统行为，并向用户提供反馈。
2. 设计时战术。将用户接口与应用的其余部分分离开来，预计用户接口会频繁发生变化，因此，单独维护用户接口代码将实现变更局部化。这与可修改性相关
3. 支持用户主动操作。如支持“取消”、“撤销”、“聚合”和“显示多个视图”。

9.3 软件架构风格

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义了一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束支出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特征，并指导如何将各个模块和子系统有效的组织成一个完整的系统。按这种方式理解，软件架构风格定义了用于描述系统的术语表和一组指导构件系统的规则。

9.3.1 软件架构风格分类

架构风格最关键的四要素内容：提供一个词汇表，定义一套配置规则，定义一套语义解释原则和定义对基于这种风格的系统所进行的分析。通用架构风格的分类：

1. 数据流风格：批处理序列；管道/过滤器
2. 调用/返回风格：主程序/子程序；面向对象风格；层次结构
3. 独立构件风格：进程通信；事件系统
4. 虚拟机风格：解释器；基于规则的系统
5. 仓库风格：数据库系统；超文本系统；黑板系统

9.3.2 数据流风格

在该结构下，所有的数据按照流的形式在执行过程中前进，不存在结构的反复和重构，数据在流水点的各个结点上被加工，最终输出需要的结果。

1. 批处理序列

批处理风格的每一步都是独立的，并且每一步是顺序执行的。只有当前一步处理完，后一步才能开始。数据传送在步与步之间作为一个整体。（组件为一系列固定顺序的计算单元，组件间只通过数据传递交互。每个处理步骤一个独立的程序，每一步必须在前一步结束后才能开始，数据必须是完整的，以整体的方式传递）。

批处理的典型应用：

1. 经典数据处理
2. 程序开发
3. Windows下的BAT程序就是这种应用的典型案例

2.管道和过滤器

在该软件架构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出流。这个过程通常通过对输入流的变换和增量计算来完成，所以输入被完全消费之前，输出便产生了。因此，这里的构件被称为过滤器。这种风格的连接件就像是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。过滤器必须是独立的实体，不能与其他的过滤器共享数据，而且一个过滤器不知道他上游和下游的标识。一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。

一个典型是以UNIX shell编写的程序，另一个例子是传统的编译器。

管道/过滤器风格的软件架构具有很多很好的特点：

1. 使得软构件具有良好的隐蔽性和高内聚、低耦合的特点
2. 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成。
3. 支持软件重用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来。
4. 系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉
5. 允许对一些如吞吐量、死锁等属性的分析
6. 支持并行执行。每个过滤器作为一个单独的任务完成，因此可与其他任务并行执行。

但是，也存在若干不利因素

1. 通常导致进程成为批处理的结构，这是因为虽然过滤器可增量式的处理程序，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。
2. 不适合处理交互的应用，当需要增量的显示改变时，这个问题尤为严重
3. 因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性

3. 批处理序列风格与管道过滤器风格对比

共同点：把任务分成一系列固定顺序的计算单元（组件）。组件间指通过数据传递交互。
区别：批处理是全部的、高潜伏性的，输入时可随机存取，无合作性、无交互性。而管道过滤器是递增的，数据结果延迟小，输入时处理局部化，有反馈、可交互。批处理强调数据在步与步之间作为一个整体，而管道过滤器无此要求。

9.2.3 调用/返回风格

1. 主程序/子程序

是结构化时期的经典架构风格。这种风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。调用关系具有层次性，其语义逻辑表现为子程序的正确性，取决于它调用的子程序的正确性。

2. 面向对象风格

这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或是说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程调用来交互的。

这种风格的两个主要特征为：

1. 对象负责维护其表示的完整性
2. 对象的表示与其他对象而言是隐蔽的。因为一个对象对它的客户隐藏了自己的表示，所以这些对象可以不影响它的客户就能改变其实现方法。

面向对象的系统优点如下：

1. 因为对象对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他的对象；
2. 设计者可以将一些数据存取操作的问题分解成一些交互的代理程序的集合。

存在的问题如下：

1. 为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象；
2. 必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么C对B的使用所造成的对A的影响可能是料想不到的。

3. 层次结构风格

层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层课件。这样的系统中构件在一些层实现了虚拟机（在另一些层次结构中层是部分不透明的）。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间的交互的约束。

这种风格支持基于可增加抽象层的设计。允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件重用提供了强大的支持。

层次结构的优点如下：

1. 支持基于抽象程度递增的系统设计，使设计者可以吧一个复杂系统被递增的步骤进行分解。
2. 支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层
3. 支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交互使用。这样就可以定义一组标准的接口，而允许各种不同的实现方法。

层次结构的缺点如下：

1. 并不是每个系统都可以很容易的划分分层的模式，甚至几十一个系统的逻辑结构是层次化的。出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；
2. 很难找到一个合适的、正确的层次抽象方法。

9.3.4 独立构件风格

主要强调系统中的每个构件都是相互独立的个体，它们之间不直接通信，以降低耦合度，提升灵活性。

1. 进程通信架构风格

构件是独立的过程，连接件是消息传递。这种风格的特点是构件通常是命名过程，消息传递的方式可以是点到点、异步和同步方式以及远过程调用等。

2. 事件系统风格

基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。一同中的其他构建中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。

从架构上来说，这种风格的构件是一些模块，这些模块既可以是一些过程，又可以是一些事件的集合。过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。

基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响，这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用。因此，许多隐式调用的系统也包含显示调用作为构件交互的补充形式。

隐式调用系统的主要优点有：

1. 为软件重用提供了强大的支持，当需要将一个构件加入现存系统中时，只需将他注册到系统的事件中
2. 为改进系统带来了方便，当一个构件代替另一个构件时，不会影响到其他构件的接口。

隐式调用系统的主要缺点：

1. 构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的过程，它也不能保证这些过程被调用的顺序。
2. 数据交换的问题。有时数据可能被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。
3. 既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。

9.3.5 虚拟机风格

基本思想是人为构建一个运行环境。在这个环境之上，可以解析与运行一些自定义的一些语言，这样来增加架构的灵活性。

1. 解释器

一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行进度的数据结构。

具有解释器风格的软件中包含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。解释器通常被用来建立一个虚拟机以弥合程序语义与硬件语义之间的差异，其缺点是执行效率过低。典型的例子是专家系统。

2. 基于规则的系统

基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内容。

9.3.6 仓库风格

在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行，仓库与外构件间的相互作用在系统中会有大的变化。

仓库风格包含的自风格有：数据库系统；超文本系统；黑板系统

数据库系统构件主要有两大类：一个是中央共享数据源，保存当前系统的数据状态；另一个是多个独立处理元素，处理元素对数据元素进行操作。而超文本系统的典型代表，就是早期的静态网页。三种架构子风格中，最复杂的是黑板系统。

黑板系统是在抽象与总结语言理解系统HEARSAY-11的基础上产生的，适合于复杂的非结构化的问题，能在求解过程中综合运用不同知识源，使得问题的表达、组织和求解都变得比较容易。黑板系统是一种问题求解模型，是组织推理步骤、控制状态数据和问题求解之领域知识的概念框架，它将问题的解，空间组织成一个或多个应用相关的分级结构，分级结构的每一层信息由一个唯一的词汇来描述，它代表了问题的部分解。领域相关的知识被分成不同知识表达方法、推理框架和控制机制的组合来实现，影响黑板系统设计的最大因素是应用问题本身的特性，但是支撑应用程序的黑板体系结构有许多相似的特征和构件。

对于特定应用问题，黑板系统可通过选取各种黑板、知识源和控制模块中的构件来设计，也可以利用关预先定制的黑板体系结构的编程环境。黑板系统的传统应用是信号处理领域，如语言和模式识别。另一个应用是松耦合代理数据共享存取。

黑板系统主要由三个部分组成：

1. 知识源：知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通信，它们之间的交互只通过黑板来完成。
2. 黑板（共享数据）：黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板上的数据来解决问题。
3. 控制：控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。

9.4 层次系统架构风格

9.4.1 二层及三层C/S架构风格

C/S架构是基于资源不对等，且为实现共享而提出的。将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与用户的交互任务。

C/S软件架构具有强大的数据操作和事务处理能力，模型西乡简单，易于人们理解和接收，但是随着企业规模的日益扩大，软件的复杂程度不断提高，传统的C/S架构存在以下几个局限：

• 二层C/S架构为单一服务器且以局域网为中心，所以很难扩展至大型企业广域网或Internet
• 软、硬件的组合及集成能力有限
• 服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏
• 数据安全性能不好，因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。

三层C/S架构将应用功能分为表示层、功能层和数据层三个部分。

表示层是应用的用户接口部分，它但负责用户与应用间的对话功能，它用于检查用户从键盘等输入的数据，并显示应用输出的接口。在变更用户接口时，只需要改写控制和数据检查程序，而不影响其他两层，检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。

功能层相当于应用的本体，他是将具体的业务处理逻辑编入程序中。而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简洁。

数据层就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此，一般从功能层传送到数据层的要求大都使用SQL语言。

9.4.2 B/S架构风格

浏览器/服务器风格就是上述三层应用结构的一种实现方式，其具体结构为：浏览器/web服务器/数据库服务器。

B/S架构主要是利用不断成熟的WWW浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大工鞥呢，并节约了开发成本。

与C/S架构相比，B/S架构也有不足之处，例如：

1. B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理能力。
2. 采用B/S架构的应用系统，在数据查询等响应速度上，要远远的低于C/S架构。
3. B/S架构的数据提交一般是以页面为单位，数据的动态交互性不强，不利于在线事务处理应用

9.4.3 MVC架构风格

全名是模型-视图-控制器。

MVC各个部分的分工与协作是这样的。

1. Model是对应用状态和业务能力的封装，我们可以将它理解为同时包含数据和行为的领域模型。Model在接收Controller的请求并完成相应的业务处理在状态改变的时候向View发出相应的通知。
2. View实现可视化界面的呈现并捕捉最终用户的交互操作。
3. View捕捉到用户交互操作后悔直接转发给Controller，后者完成相应的UI逻辑，如果需要涉及业务功能的调用，Controller会直接调用Model。在完成UI处理后，Controller会根据需要控制原View或创建新的View对用户交互操作予以相应。

9.4.4 MVP架构风格

Model-View-Presenter。Model提供数据，View负责显示，Controller/Presenter负责逻辑的处理。MVC中允许View与Model直接交流，这在MVP模式中是不允许的。它们之间的通信是通过Presenter，所有的交互都发生在Presenter内部。

MVP的优点包括：

1. 模型与视图完全分离，我们可以修改视图而不影响模型。
2. 可以更高效的使用模型，因为所有的交互都发生在一个地方——Presenter内部。
3. 我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。
4. 如果我们将逻辑放在Presenter的中，那么我们就可以脱离用户接口来测试这些逻辑。

MVP的缺点包括：

视图和Presenter的交互会过于频繁。如果Presenter过多的渲染了视图，往往会使得他与特定视图的联系过于紧密，一旦视图需要变更，那么Presenter也需要变更。

9.5 面向服务的架构

1. W3C的定义：SOA是一种应用程序架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。
2. SA的定义：服务是精确定义、封装完善、独立于其他服务所处环境和状态的函数。SOA本质上是服务的集合，服务之间彼此通信，这种通信可能是简单的数据传递。也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进行连接。
3. Garner的定义：SOA是一种C/S架构的软件设计方法，应用由服务和服务使用者组成，SOA与大多数通用的C/S架构模型不同之处，在于它着重强调软件的松散耦合，并使用独立的软件接口。

9.5.1 SOA概述

虽然基于SOA的系统并不排除使用OOD来够简单个服务，但是其整体设计却是面向服务的。由于SOA考虑到了系统内的对象，所以虽然SOA是基于对象的，但是作为一个整体，它却不是面向对象的。

SOA建立在XML等新技术的基础上，通过使用基于XML的语言来描述接口，服务已经转到更动态且更灵活的接口系统中。

在SOA系统中，所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务都通过服务总线或流程管理器来连接。各服务在交互的过程中无需考虑双方的内部实现细节，以及部署在什么平台。

1. 服务的基本结构

服务模型的表示层从逻辑层分离出来，中间增加了服务对外的接口层。通过服务接口的标准化描述，使得服务可以提供给在任何异构平台或任何用户接口使用。

2. SOA设计原则

1. 明确定义的接口。服务定义必须长时间稳定，一旦公布，不能随意更改；服务的定义应尽可能明确，减少请求者的不适当使用；不要让请求者看到服务内部的私有数据。
2. 自包含和模块化。服务封装了那些在业务上稳定的、重复出现的活动和构件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
3. 粗粒度。服务数量不应该太多，依靠消息交互而不是远程过程调用。通常消息量较大，但是服务之间的交互频率较低。
4. 松耦合。服务请求者可见的是服务的接口，其位置、实现技术、当前状态和私有数据等，对服务请求者而言是不可见的。
5. 互操作性、兼容和策略声明。

3. 服务构件和传统构件

服务构件架构SCA是基于SOA的思想描述服务之间组合和写作的规范，它描述用于使用SOA构建应用程序和系统的模型。可以简化可用SOA进行应用程序的开发和实现工作。提供了构件粗粒度构件的机制，这些粗粒度构件由细粒度构件组装而成。SCA将传统中间件编程从业务逻辑中分离出来，从而使程序员避免受其复杂性的困扰。允许开发人员集中精力编写业务逻辑，而不必将大量的时间花费在更为底层的技术实现上。

SCA服务构件与传统构件的主要区别在于：服务构件旺旺是粗粒度的，而传统构件以细粒度居多；服务构件的接口是标准的，主要是服务描述语言接口，而传统构件常以具体API形式出现；服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言；服务构件可以通过构件容器提供QoS的服务，而传统构件完全由程序代码控制。

9.5.2 SOA的关键技术

1. UDDI

统一描述、发现和集成。提供一种服务发布、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它。UDDI规范描述了服务的概念，同时也定义了一种编程接口。通过UDDI提供的标准接口，企业可以发布自己的服务供其他其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。

UDDI技术规范中，主要包含下面三个部分的内容：

1. 数据模型。是一个用于描述业务组织和服务的XML Schema
2. API。十一组用于查找或发布UDDI数据的方法。基于SOAP
3. 注册服务。是SOA中的一种基本设施，对应着服务注册中心的角色。

2. WSDL

Web语言描述对象是对服务进行描述的语言。有一套基于XML的语法定义。描述的重点是服务，包含服务实现定义和服务接口定义。

服务接口定义就是一种抽象的、可重用的定义，行业标准组织可以使用这种抽象的定义来规定一些标准的服务类型，服务实现者可以根据这些标准定义实现具体的服务。

服务实现定义描述了给定服务提供者如何实现特定的服务接口。服务实现定义中包含服务和端口描述。一个服务往往会包含多个服务访问入口而每个访问入口都会使用一个端口元素来描述，端口描述的是一个服务入口的部署细节。

3. SOAP

简单对象访问协议。定义了服务请求者和服务提供者之间的消息传输规范。使用XML来格式化消息，用HTTP来承载消息。通过SOAP，应用程序可以在网络中进行数据交换和远程过程调用RPC。SOAP主要包括以下四个部分：

1. 封装。
2. 编码规则，定义了一种序列化的机制，用于交换系统所定义的数据类型的实例。
3. RPC表示。定义了一个用来表示远程过程迪奥哟经和应答的协议。
4. 绑定。定义了一个使用底层传输协议来完成在结点之间进行交换SOAP封装的约定。

SOAP消息基本上是要从发送端到接收端的单向传输，但它们常常结合起来执行类似于请求/应答的模式。所有的SOAP消息都使用XML进行编码。SOAP消息包括以下三个部分：

1. 封装（信封）。元素名是Envelope，在表示消息的XML文档中，封装是顶层元素，在SOAP中必须出现。
2. SOAP头。元素名是Header，提供了向SOAP消息中添加关于这个SOAP消息的某些要素的机制。SOAP定义了少量的属性来表明这项要素是否可选以及由谁来处理。可能出现，也可能不出现，一旦出现，必须是第一个直接子元素。
3. SOAP体。元素名是Body，是包含消息的最终接收者想要的信息的容器。必须出现，且必须是直接子元素。如果有头元素，则必须直接跟在头元素的后面，如果没有，则必须是第一个子元素。

4. REST

表述性状态转移。是一种只使用HTTP和XML进行基于web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。REST从根本上只支持几个操作（POST、GET、PUT和DELETE）。REST提出了如下一些设计概念和准则：

1. 网络上的所有事物都被抽象为资源。
2. 每个资源对应一个唯一的资源标识。
3. 通过通用的连接件接口对资源进行操作。
4. 对资源的各种操作不会改变资源标识。
5. 所有的操作都是无状态的。

9.5.3 SOA的实现方法

1. Web Service

一共有三种工作角色，其中服务提供者和服务请求者是必需的，服务注册中心是一个可选的角色。

1. 服务提供者。是服务的所有者，负责定义并实现服务，使用WSDL对服务进行详细、准确、规范性描述，并将该描述发布到服务注册中心，工服务请求者查找并绑定使用。
2. 服务请求者。是服务的使用者。从架构的角度看，服务请求者是查找、绑定并调用服务，或与服务进行交互的应用程序。服务请求者角色可以由浏览器来担当，由人或程序来控制。
3. 服务注册中心。是连接服务提供者和服务请求者的纽带，服务提供者在此发布它们的服务描述，而服务请求者可以在服务注册中心查找它们需要的服务。如果是使用静态绑定的服务，服务提供者可以把描述直接发给服务请求者。

Web service模型中的操作如下，这些操作可以单次或反复出现；

1. 发布。服务提供者发布服务描述
2. 查找。服务请求者直接检索服务描述或在服务注册中心查询所要求的服务类型。对服务请求者来说，可能会在生命中秋的两个不同阶段中涉及查找操作，首先是在设计阶段，为了程序开发而查找服务的接口描述；其次是在运行阶段，为了调用而查找服务的位置描述。
3. 绑定。服务请求者使用服务描述中的绑定细节来定位、联系并调用服务，从而在运行时与服务进行交互。绑定可以分为动态绑定和静态绑定。在动态绑定中，服务请求者通过服务注册中心查找服务描述，并动态的与服务交互；在静态绑定中，服务请求者已经与服务提供者达成默契，通过本地文件或其他方式直接与服务进行绑定。

在采用Web service作为SOA的实现技术时，应用程序大致可以分为六个层次，如下：

1. 底层传输层。主要负责消息的传输机制，HTTP、JMS和SMTP都可以作为服务的消息传输协议，其中HTTP使用最广。
2. 服务通信协议层。主要功能是描述并定义服务之间进行消息传递所需的技术标准，常用的标准是SOAP和REST协议。
3. 服务描述层。主要以一种统一的方式描述服务的接口与消息交换方式，相关的标准是WSDL。
4. 服务层。主要功能试讲遗留系统进行包装，并通过发布的WSDL接口描述被定位和调用。
5. 业务流程层。主要功能是支持服务发现，服务调用和点到点的服务调用，并将业务流程从服务的底层调用抽象出来。
6. 服务注册层。主要功能是使服务提供者能够通过WSDL发布服务定义，并支持服务请求者查找所需的服务信息，相关的标准是UDDI。

2. 服务注册表

虽然也有运行时的功能能，但主要在SOA设计时使用。它提供了一个策略执行点PEP，在这个点上，服务可以在SOA中注册，从而可以被发现和使用。从理论上来说，任何帮助服务注册、发现和查找服务合约、元数据和策略的信息库、数据库、目录或其他节点都可以被认为是一个注册表。

1. 服务注册。指服务提供者向服务注册表发布服务的功能（服务合约），包括服务身份、位置、方法、绑定、配置、方案和策略等描述性属性。
2. 服务位置。指服务使用者，帮助它们查找已注册的服务，寻找符合自身要求的服务。
3. 服务绑定。服务使用者利用查找到的服务合约来开发代码，开发的代码将与注册的服务进行绑定，调用注册的服务，以及与他们实现互动。

3. 企业服务总线

ESB，是一种为连接服务提供的标准化的通信基础结构，基于开放的标准，为应用提供一个可靠的、可度量和高度安全的环境，并可帮助企业对业务流程进行设计和模拟，对每个业务流程进行控制和跟踪、分析、并改进流程和性能。

ESB是由中间件技术实现并支持SOA的一组基础架构，是传统中间件技术与XML、Web Service等技术结合的产物，是在整个企业集成环境下的面向服务的企业应用集成机制。具体来说，ESB具有以下功能

1. 支持异构环境中的服务、消息和基于事件的交互，并且具有适当的服务级别和可管理性。
2. 通过使用ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使现有系统具有全新的服务接口，并能够在部署环境中支持任何标准。
3. 充当缓冲器的ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑相分离，从而使不同的系统可以同时使用同一个服务，不用在系统或数据发生变化时，改动服务代码。
4. 在更高的层次，ESB还提供诸如服务代理和协议转换等功能，允许在多种形式下通过向HTTP、SOAP和JMS总线的多种传输方式，主要是以网络服务的形式，为发表、注册、发现和使用企业服务或界面提供基础设施。
5. 提供可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息到不同的目的地。
6. 提供安全和拥有者机制，以保证消息和服务使用的认证、授权和完整性。

9.5.4 微服务

微服务架构是一种架构模式，提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构件，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构件。

核心特点是：小，且专注做一点事情、轻量级的通信机制、松耦合、独立部署。

1. 微服务的优势

1. 技术异构性

在微服务架构中，每个服务都是一个相对独立的个体，每个服务都可以选择适合于自身的技术去实现。

2. 弹性

主要讲的是系统中的一部分出现故障，会引起多大问题。微服务架构中，每个服务都可以内置可用性的解决方案与功能降级方案。

3. 扩展

可以针对单个服务进行扩展

4. 简化部署

微服务架构中，每个服务的部署都是独立的。可以更快的对特定部分的代码进行部署。

5. 与组织结构相匹配

微服务架构可以将架构与组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小及生产力。

6. 可组合型

在微服务架构中，系统会开放很多接口供外部使用。当情况发生改变时，可以使用不同的方式构件应用。

7. 对可替代性的优化

在微服务架构中，我们可以在需要时轻易的重写服务，或删除不再使用的服务。

2. 微服务面临的挑战

1. 分布式系统的复杂度
2. 运维成本
3. 部署自动化
4. DevOps与组织结构
5. 服务间依赖测试
6. 服务间依赖管理

3. 微服务与SOA

微服务	SOA
能拆分的就拆分	是整体的，服务能放到一起的都放到一起
纵向业务划分	是水平分多层
由单一组织负责	按层级划分不同部门的组织负责
细粒度	粗粒度
两句话可以解释明白	几百字只相当于SOA的目录
独立的子公司	类似大公司里面划分了一些业务单元
组件小	存在较复杂的组件
业务逻辑存于每一个服务中	业务逻辑横跨多个业务领域
采用轻量级的通信方式，如HTTP	企业级服务充当了ESB充当了服务之间通信的角色

微服务架构实现	SOA实现
团队级，自底向上开展实施	企业级，自顶向下开展实施
一个系统被拆分成多个服务，粒度细	服务由多个子系统组成，粒度大
无集中式总线，松散的服务架构	企业服务总线，集中式的服务架构
集成方式简单（HTTP/REST/JSON）	集成方式复杂（ESB/WS/SOAP）
服务能独立部署	单块架构系统，相互依赖、部署复杂

9.6 架构设计

1. 演变交付生命周期

在生命周期模型中，架构设计就是从初步的需求分析开始逐步进行循环迭代。即：一方面在了解系统需求前，不能开始设计架构；另一方面，刚开始设计架构时并不需要等到全部需求都收集到。

2. 属性驱动设计法

是一种定义软件架构的方法，该方法将分解过程建立在软件必须满足的质量属性智商。

ADD的步骤如下。

1. 选择要分解的模块
2. 根据如下步骤对模块进行求精：
   
   • 从具体的质量场景和功能需求集合中选择架构驱动因素。并不是同等看待所有需求，而是在满足了最重要的需求的条件下，才满足不太重要的需求，即针对架构需求有优先级。
   • 选择满足架构驱动因素的架构模式，根据前面的战术创建（或选择）模式。其目标是建立一个由模块类型组成的总体架构模式。
   • 实例化模块并根据用例分配功能，使用多个视图进行表示。
   • 定义子模块的接口。
   • 验证用例和质量场景，并对其进行求精，使他们成为子模式的限制。
3. 对需要进一步分解的每个模块重复上述步骤。

3. 按架构组织开发团队

4. 开发骨架系统

5. 利用商用软件进行开发

9.7 软件架构文档化

1. 架构文档的使用者

是架构的项目关系人。编写技术文档的最基本的原则之一是要从读者的角度来编写。

2. 合理的编档规则

1. 从读者的角度编写文档
2. 避免出现不要的重复
3. 避免歧义
4. 使用标准结构
5. 记录基本原理
6. 使文档保持更新，但更新频率不要过高
7. 针对目标的适宜性对文档进行评审

3. 视图编档

文档组织结构包含七个部分：

1. 视图概述：对系统进行概述性的描述，包含视图的主要元素和元素箭的关系（但并不包含所有元素和元素箭的过膝）。主要表示可用多个形式：图形、表格、文本。通常用图形形式，使用UML语言来描述。
2. 元素目录：对主要表示中所描述的元素及其关系进行详细描述，包括：元素及其属性、关系及其属性、元素接口、元素行为。这部分是文档的主要组成部分，其中要注意：
   
   • 对元素及其协同工作的行为进行编档，如用UML中的顺序图和状态图描述行为；
   • 对接口进行编档
3. 上下文图：用图形展示系统如何与其环境相关。
4. 可变性指南：描述架构的可变化点。文档中应包含这些变化点，如各系统要作出选择的选项、作出选择的时间。
5. 架构背景：为架构的合理性提供足够的、令人信服的论据。包括：基本原理、分析结果及设计中所反映的假定。
6. 术语表：对文档中每个术语进行简要说明。
7. 其他信息：描述不属于架构方面的必要信息。

4.跨视图文档

包括如下内容：

1. 文档由哪些内容以及如何组织：视图目录；视图模板
2. 架构概述：描述系统的目的、是土建的关联、元素表及索引、项目词汇
3. 基本原理：跨视图基本原理解释了整体架构实际上是其需求的一个解决方案。及解释了作出决策的原因、方案的限制、改变决策时的影响及意义。

5. 使用UML

6. 软件架构重构

软件架构重构就是研究及反向解析软件架构的工作。

软件架构重构由以下活动组成，这些活动以迭代方式进行。

1. 信息提取：提取目标的依赖关系；提取静态信息；提取动态信息
2. 数据库构造：将提取的信息转化为标准的形式，并置于数据库中。
3. 视图融合：将数据库中的信息组合在一起，生成该架构的一个内聚的视图。
4. 重构：根据数据抽象和各种表示以生成架构表示，主要由两个活动组成：最后生成需要的架构文档。

9.8 软件架构评估

是在对架构分析、评估的基础航，对架构策略的选取进行决策。他可以灵活的运用于软件架构进行评审等工作中。

9.8.1 软件架构评估的方法

1. 基于调查问卷或检查表的方式：关键是要设计好问卷或检查表，它充分利用系统相关人员的经验和知识，获得对架构的评估。缺点是在很大程度上依赖于评估人员的主观推断。
2. 基于场景的方式：应用在架构权衡分析法和软件架构分析方法中。通过分析软件建构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
3. 基于度量的方式：建立在软件架构度量的基础上的，涉及三个基本活动，首先需要建立质量属性和度量之间的映射原则，即确定怎样从度量结果中退出系统具有什么样的质量属性；然后从软件架构文档中获取度量信息；最后根据映射原则分析推导出系统的质量属性。它能提供更为客观和量化的质量评估，对评估人员及其使用的技术有较高的要求。

9.8.2 架构的权衡分析法

从技术的角度对软件架构进行评估，旨在通过分析来遇见软件的质量，通过分析来创建、选择、评估与比较不同的架构。ATAM方法不但能够揭示架构如何满足特定的质量需求，而且还提供了分析这些质量需求之间交互作用的方法。使用ATAM方法评价一个软件架构的目的是理解架构设计满足系统质量需求的结果。ATAM产生如下结果。

1. 一个简洁的架构描述
2. 表述清楚的业务目标。
3. 用场经济和捕捉质量需求。
4. 架构决策到质量需求的映射。
5. 所确定的敏感点和权衡点集合：这个集合是一些对一个或多个质量属性具有显著影响的架构。
6. 有风险角色和无风险决策
7. 风险主题的集合。
8. 产生一些附属结果
9. 还产生一些无形结果。

ATAM的九个步骤如下：

1. ATAM方法的表述
2. 商业动机的表述
3. 架构的表述
4. 对架构方法进行分类
5. 生成质量属性效用树。
6. 分析架构方法
7. 集体讨论并确定场景的优先级
8. 分析架构方法
9. 结果的表述

9.8.3 成本效益分析法

CBAM是在ATAM上构建，用来对于架构设计决策的成本和收益进行建模，是优化此类决策的一种手段。CBAM协助项目管理人根据其投资回报ROI选择架构策略。CBAM在ATAM结束时开始，它实际上使用了ATAM评估的结果。步骤如下：

1. 整理场景
2. 对场景进行求精
3. 确定场景的优先级
4. 分配效用。对场景的响应级别（最坏情况、当前情况、期望情况和最好情况）确定效用表。
5. 架构策略设计那些质量属性及相应级别，形成相关的策略——场景——响应级别的对应关系。
6. 使用内插法确定“期望的”质量属性响应级别的效用。即根据第4步的效用表以及第5步的对应关系，确定架构策略及对应场景的效用表。
7. 计算各架构策略的总收益。
8. 根据受成本限制影响的投资报酬率ROI选择架构策略。

9.9 构件及其复用。

定义1：构件是指软件系统中可以明确辨识的构成成分。而可复用构件是指具有相对独立的功能和可复用价值的构件。
定义2：构件是一个组成单元，具有约定规范的接口及明确的依赖环境。
定义3：构件是软件系统中具有相对独立功能、可以明确辨识、接口由七月制定、和语境由明显依赖关系、可独立部署的可组装软件实体。

9.9.1 商用构件标准规范

1. CORBA

公共对象请求代理架构。主要分为3个层次：对象请求代理、公共对象服务和公共设施。最底层的对象请求代理ORB，规定了分布对象的定义（接口）和语言映射，实现对象间的通信和互操作，是分布对象系统中的“软总线”；在ORB之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务（交易）服务、安全服务等各种各样的服务；最上层的公共设施则定义了构件框架，提供可直接为业务对象使用的服务，规定业务对象有效写作所需的协定规则。

CORBA CCM（CORBA构件模型）是OMG组织制定的一个用于开发和配置分布式应用的服务器端构件模型规范，它主要包含以下三项内容。

1. 抽象构件模型：泳用以描述服务器端构建结构及构件间互操作的结构。
2. 构件容器结构：用以提供通用的构件运行和管理环境，并支持对安全、事务、持久状态等系统服务的集成。
3. 构件的配置和打包规范：CCM使用打包技术来管理构件的二进制、多语言版本的可执行代码和配置信息，并制定了构建包的具体内容和文档内容标准

2. J2EE

在分布式互操作协议上，J2EE同时支持远程方法调用RMI和互联网内部对象请求代理协议IIOP。

EJB中的Bean可以分为会话Bean和实体Bean，前者维护会话，后者处理事务，通常由Servlet负责与客户端通信，访问EJB，并把结果通过JSP产生页面返回客户端。

3. DNA 2000

Microsoft的COM+组件

9.9.2 应用系统簇与构件系统

一般情况下，构件系统只在开发单位内部使用，而应用系统提供给外部客户。与应用系统相比，构件系统具有通用性、可复用性。一个构件系统是能提供一系列可复用特性的系统产品。

9.9.3 基于复用开发的组织结构

与传统的开发组织结构不同，它需要有一部分用于开发可复用资产的资源，这部分资源应同具体引用系统的开发资源分开，以确保不被占用。

9.10 产品线与系统演化

实质上是用架构技术构建产品线，并在此基础上借用复用技术持续演化，不断的推出新产品，满足市场追求产品升级换代的需求。

9.10.1 复用与产品线

软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性及，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。

可复用的资产非常广，包括以下几点：

• 需求
• 架构设计
• 元素：捕获并复用设计中的可取之处，避免设计失败的地方
• 建模与分析
• 测试
• 项目规划
• 过程、方法和工具
• 人员
• 样本系统
• 缺陷消除

9.10.2 基于产品线的架构

软件产品线架构是针对一系列产品而设计的通用框架，并在此基础上，进一步向系列产品公用的模块实现实现，供直接重用；将架构用框架的形式予以实现，供定制使用。这就是通常所说的“平台”。

产品线架构较之单个产品架构，有如下三点特别之处：

1. 产品线架构必须考虑一系列明确许可的变化
2. 产品架构一定要文档化
3. 产品架构必须提供“产品常见指南”（开发指南），描述架构的实例化过程。

通常应在识别变化时，应考虑三个方面：

1. 确定变化点：确定变化是一项需要持续进行的活动，可以在开发过程中的任何时间确定变化。
2. 支持变化点：对变化的支持有多种形式，例如：
   
   • 包含或生路额元素，如条件编译
   • 包含不同数量的复制元素：如通过添加更多的服务器产生高容量的变体。
   • 具有相同的接口但具有不同的行为或质量特性的元素版本的选择：如静态库和动态链接库的使用。
   • 在面向对象的系统中，通过特化或繁华特定的类实现变化。
   • 通过参数配置来实现变化
     3、 对产品架构的适应性进行评估
   • 评审方法
   • 评估的内容
   • 评估的时间

9.10.3 产品线的开发模型

开发（确定）产品线的方法有两种模型:

1. “前瞻性”产品线：利用在应用领域的经验，对市场和技术发展趋势的了解及企业判断力等进行产品线设计，它反映了企业的战略决策。通常是自上而下的采用产品线方法。
2. “反应性”模型：企业根据以前的产品构建产品家族，并随着新产品的开发，扩展架构和设计方案，它的核心资产库是根据“已有证明”为共有、而非“预先计划”为共有的元素构建的。通常是自下而上的采用产品线方法。

9.10.4 特定领域软件架构

架构的本质在于其抽象性。包括两个方面的抽象：业务抽象和技术抽象。其中业务抽象面向特定的技术领域

特定领域软件架构DSSA可以看做开发产品线的一个方法（或理论），它的目标就是在支持在一个特定领域中有多个应用的生成。

DSSA的必备特征有：

1. 一个严格定义的问题域或解决域
2. 具有普遍性，使其可以用于领域中某个特定应用的开发
3. 对整个领域的合适程度的抽象
4. 具备该领域固定的、典型的在开发过程中的可复用元素。

从功能覆盖的范围角度理解DSSA中领域的含义有两种方法L

1. 垂直域。定义了一个特定的系统族，到处在该领域中可作为系统的克星解决方案的一个通用软件架构。
2. 水平域。定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统（族）的特定部分功能。

DSSA的活动阶段如下：

1. 领域分析：主要目标是获得领域模型。即通过分析领域中系统的需求（领域需求），确定哪些需求是被领域中的系统广泛共享的，从而建立领域模型。
2. 领域涉及：这个阶段的目标是获得DSSA，他是一个能够适应领域多个系统的需求的一个高层次的设计。
3. 领域实现：主要目标是依据领域模型和DSSA开发和组织可复用信息。这些复用信息可以使从现有系统中提取得到的，也可能通过新的额开发得到。这个阶段可以看做复用基础设施的实现阶段。

领域模型的主要作用如下：

1. 领域模型为需求定义了领域知识和领域词汇，这较之单一的项目需求更有较好的大局观。
2. 软件界面的设计往往和领域模型关系密切
3. 领域模型的合理性将严重影响软件系统的可扩展性
4. 在分层架构的指导下，领域模型精化后即成为业务层的骨架。
5. 领域模型也是其数据模型的基础
6. 领域模型是团队交流的基础，因为它规定了重要的领域词汇表，并且这些词汇的定义是严格的。

9.10.5 架构及系统演化

架构（系统）演化包含七个步骤：

1. 需求变动归类
2. 制定架构演化计划
3. 修改、增加或删除构件
4. 更新构件的相互作用
5. 构件组装与测试
6. 技术评审
7. 产生演化后的架构

9.11 软件架构视图

9.11.1 软件视图的分类

结构是元素本身的集合，而视图则是捕获和表达结构（文档描述）

软件视图通常分为三种类型：

1. 模块视图类型：为系统的主要模块实现单元编档
2. 构件和连接件视图类型：为系统的构件和连接件执行单元编档
3. 分配视图类型：为软件的开发和执行环境之间的关系编档

组别	架构风格	说明	应用于
模块视图类型	分解	大模块分解为小模块，小到容易理解	资源分配、项目结构化和规划；信息隐蔽、封装；配置控制
模块视图类型	使用	一个单元的正确性依赖于另一个单元的正确性（如版本）	设计子集；设计扩展（增量开发）
模块视图类型	分层	上层使用下层的服务；实现隐藏细节的抽象	增量式开发；基于“虚拟机”上的可移植性
模块视图类型	类或泛化	“继承自”或“是一个实例”；共享访问方法	面向对象的设计（使用公共模板）。
构件-连接器视图类型	客户机-服务器	构件是客户机和服务器，连接件是协议及共享消息	分布式操作；关注点分离（支持可修改性）；负载均衡
构件-连接器视图类型	进程或通信进程	通过通信、同步或排除操作形成进程或线程之间的关联	调度分析；性能分析
构件-连接器视图类型	并发	在相同的“逻辑线程”上运行	确定资源争用；分析线程
构件-连接器视图类型	共享数据	运行时产生数据，使用数据（共享数据存储库）	性能；数据完整性；可修改性
分配视图类型	部署	软件功能分配给软件（进程）、硬件（处理器）和通信路径	性能、可用性、安全性说明。尤其是在分布式或并行系统中
分配视图类型	实现	模块映射到开发活动中	配置控制、集成、测试活动
分配视图类型	工作分配	将责任分配到适当的开发小组，特别是公共部分不是每个人去实现	项目管理、管理通用性，最好的专业技术安排。

9.11.2 模块视图类型及其风格

模块将遵循某种方式将软件系统分解成可管理的功能单元。

架构模块视图是通过文档来枚举系统的主要实现单元或模块，及这些单元之间的关系。任务完整的架构文档必须包含有模块视图，它为源代码提供蓝图。

模块视图的四种风格如下：

1. 分解风格能展示向模块分配责任的方式
2. 使用风格能展示模块相互依赖的方式
3. 分层风格能将系统分割成一组虚拟机，通过“允许使用”关系相互关联，分层风格能帮助实现可移植性和可修改性。
4. 泛化风格能展示一个模块如何成为另一个模块的泛化或特化，从而使模块之间产生关联。它广泛应用于面向对象的系统，能展示继承性，并能用来使用模块之间的共性。

9.11.3 C&C视图类型及其风格

能定义由具有某种运行时存在的元素模型，这些元素包括进程、对象、客机、服务器及数据存储器等。此外，它还包括作为元素的交互路径，如通信链路和协议、信息流及共享存储器访问。几种风格如下：

1. 管道和过滤器风格中的交互模式表现出数据流连续变换的特征。数据抵达过滤器并经过转换后由管理传送给下一个过滤器
2. 共享数据风格通过保留持久数据来支配交互模式，持久数据由多个数据存储器和至少一个储存库保留。
3. 发布-订阅风格用于向一组未知接受者发送时间和消息。可在不修改生产者的情况下添加洗呢接受者（订阅者）。在发布-订阅风格中，构件通过事件发布进行交互，构件可以订阅一组事件
4. 客户机-服务器风格能展示构件通过请求其他构件的服务进行交互的过程，将功能划分成客户机和服务器后即可基于运行时准则把他们单独分配给各个级。
5. 对等连接系统能通过构件之间的直接交换支持服务交换。他是一种调用/返回风格。
6. 通信-进程风格的特征表现在通过各种连接件机制并发执行构件的交互，如通过同步、消息传递、数据交换、启动和停止等进行交互。

9.11.4 分配视图类型及其分割

硬件、文件系统和团队结构都会与软件架构进行交互，将软件架构映射到其环境的一般形式称为“分配视图类型”。

分配视图类型的常见风格如下：

1. 布置风格体现为C&C风格（如进程-进程风格）的元素被分配到执行平台。
2. 实现风格能将模块视图类型中的模块映射到开发基础结构，实现一个模块总会产生许多独立文件，必须对这些文件进行组织，以免失去对系统的控制及系统的完整性。通常利用配置管理技术进行文件管理。
3. 软件项目的时间和预算估计取决于工作分解结构WBS，而工作分解结构则取决于软件架构。工作任务风格将软件架构映射到有人组成的团队之中，实现这一项目管理的目的。

9.11.5 各视图类型间的映射关系

1. 模块视图类型中的视图通常会映射到构件和连接件视图类型中的视图。模块实现单元将映射到运行时构件
2. 系统中的构件和连接件视图和模块视图之间的关系可能会非常复杂。同样的代码模块可由C&C视图的许多元素执行。反之，C&C视图的单一构件可执行有许多模块定义的代码。同样，C&C构件可能会拥有许多与环境进行交互的点，每个交互点由统一模块接口定义。
3. 分配视图类型是为有效的实现软件架构的辅助性视图，它将其他视图类型中的软件元素映射到软件环境中，即反应其他视图与软件环境之间的关系。

第十章 设计模式

10.1 设计模式概述

对被用来在特定场景下解决一般设计问题的类和互相通信的对象的描述，通俗的说，可以把设计模式理解为对某一类问题的通用解决方案。

10.1.1 设计模式的概念

设计模式解决的是一类问题。是一种通用的解决方案，而不是具体的，也不是唯一的。学习设计模式时需要注意一下两点：

1. 学习这些模式是一个方面，另一方面更要了解模式中的思想。设计模式本身是为了提高软件架构的质量，学习设计模式的目的也是为了提高架构设计的水平。
2. 设计模式虽然可以使设计变得更精妙，但滥用设计模式会适得其反。

10.1.2 设计模式的组成

在描述一个设计模式，至少要包含四个方面：模式名称、问题、解决方案、效果。

10.1.3 GoF设计模式

23个设计模式统称为GoF模式，这23个模式如下：

1. Factory Method模式：提供了一种延迟创建创建类的方法，使用这个方法可以在运行期间由子类决定创建哪一个类的实例。
2. Abstract Factory模式。又称抽象工厂模式，主要为解决复杂系统中对象创建的问题。抽象工厂模式提供了一个一致的对象创建接口来创建一系列具有相似基类或相似接口的对象。
3. Builder模式。与抽象工厂模式非常类似，但是Builder模式是逐步的构造出一个复杂对象，并在最后返回对象的实例。可以把复杂对象的创建于表示分离，使得同样的创建过程可以创建不同的表示。
4. Prototype模式。可以根据原型实例制定创建的对象的种类，并通过深复制这个原型来创建新的对象。有着与抽象工厂模式和建造者模式相同的效果，不过当需要实例化的类是在运行期才被指定的而且要避免创建一个与产品曾是平行的工厂类层次时，可以使用Prototype模式。该模式可以在运行时增加或减少原型。
5. Singleton模式。保证在一个类仅有一个实例，从而可以提供一个单一的全局访问点。
6. Adapter模式。可以解决系统间接口不相容的问题。通过Adapter可以把类的接口转化为客户程序所希望的接口，从而提高复用性。
7. Bridge模式。把类的抽象部分同实现部分相分离，这样类的抽象和实现都可以独立的变化
8. Composite模式。提供了一种以树形结构组合对象的方法，该模式可以使单个对象和组合后的对象具有一致性以提高软件的复用性。
9. Decorator模式。可以动态的为对象的某一个方法增加更多的功能，很多时候，使用该模式可以不必继承出新的子类从而维护间接的类继承结构。
10. Facade模式。为一组类提供了一致的访问接口。使用该模式可以封装内部具有不同接口的类，使其对外提供统一的访问方式。
11. Flyweight模式。可以共享大量的细粒度对象，从而节省创建对象所需要分配的空间，不过在时间上的开销会变大。
12. Proxy模式。为对象提供了一种访问代理，通过对象代理可以控制客户程序的访问，也可以将开销较大的访问化整为零，提高访问效率。
13. Interpreter模式。定义了一个解释器，来解释遵循给定语言和文法的句子。
14. Template Method模式。定义一个操作模板，其中的一些步骤会在子类中出现，以适应不同的情况。
15. Chain of Responsibility模式。可以把响应请求的对象组织成一条链，并在这条对象链上传递请求，从而保证多个对象都有机会处理请求而且可以避免请求方和响应方的耦合。
16. Command模式。将请求封装为对象，从而增强请求的能力。
17. Iterator模式。提供了顺序访问一个对象集合中的各元素的方法，使用该模式可以避免暴露集合中对象的耦合关系。
18. Mediator模式。可以减少系统中对象间的耦合性。该模式使用中介对象封装其他的对象，从而使这些被封装的对象间的关系就成了松散耦合
19. Memento模式。提供了一种捕捉对象状态的方法，且不会破坏对象的封装。并且可以在对象外部保存对象的状态，并在需要的时候恢复对象状态。
20. Observer模式。提供了将对象的状态广播到一组观察者的方式，从而可以让每个观察者随时可以得到对象更新的消息。
21. State模式。允许一个对象在其内部状态改变的时候改变它的行为。
22. Strategy模式。可以让对象中算法的变化独立于客户。
23. Visitor模式。表示对某对象结构中各元素的操作，使用该模式可以在不改变各元素类的前提下定义作用于这些元素的新操作。

10.1.4 其他设计模式

1. Intercepting Filter模式。通过截取客户请求，并将请求发送到Filter中，一步一步的进行预处理，知道这些处理结束，请求才会被转发到真正响应客户请求的Servlet中
2. Session Facade模式。

10.1.5 设计模式与软件架构

软件架构描述了软件的组成。设计模式则更侧重于类与类、对象与对象之间的关系。

常见的架构风格有分层架构、客户端——服务器架构、消息总线、面向服务的架构。

10.1.6 设计模式的分类

GoF模式

-	创建型	结构型	行为型
应用于类	Factory Method	Adapter	Interpreter Templete Method
应用于对象	Abstract Factory Builder Prototype Singleton	Adapter Bridge Composite Decorator Facade Flyweight Proxy	Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

J2EE设计模式分类

表现层	业务层	综合层
Intercepting Filter Front Controller View Helper Composite View Service to Worker Dispacher View	Business Delegate Value Object Session Facade Composite Entity Value Object Assembler Value List Handler Service Locator	Data Access Object Service Activator

10.2 设计模式及实现

10.2.1 Abstract Factory模式--抽象工厂模式

Java设计模式-工厂模式

10.2.2 Singleton模式--单例模式

Java设计模式-单例模式

10.2.3 Decorator模式--装饰模式

Java设计模式-装饰模式

10.2.4 Facade/Session Facade模式--外观模式、门面模式

Java设计模式-装饰模式

10.2.5 Mediator模式--中介者模式

Java设计模式-装饰模式

10.2.6 Observer模式--观察者模式

Java设计模式-观察者模式

10.2.7 Intercepting Filter模式--筛选器模式

1. 意图解决的问题

在使用MVC架构进行Web应用开发时，通常需要对来自于客户的请求进行一些预处理，如验证客户身份、验证请求来源、对请求解码等，然后再传递给控制器。如果把这些预处理都交给控制器来完成，将增加控制器的复杂度，而且难以维护和扩展。

2. 模式描述

FilterManager负责调度整个FilterChain，它将在请求到达Target前拦截请求，并传递给FilterChain，由FilterChain中的过滤器依次进行预处理。知道请求经过最后一个过滤器后才完成了全部的预处理，然后由FilterManager把请求转发给实际的目标。

3.效果

使用该模式使得预处理的逻辑和真正的处理逻辑分离，进行实际处理的Target只需要关心具体的逻辑，而同请求相关的预处理都放在FilterManager中进行。同时解除了这两类处理的耦合性，扩展、修改预处理过程变得容易，系统具有更好的维护性和扩展性

10.3 设计模式总结

学习设计模式最重要的是理解，而不是生搬硬套。每种设计模式中都包含着良好的设计架构的思想，如隐藏内部细节，降低耦合度等，越是复杂的系统越是需要这些思想的支撑。

第十一章 测试评审方法

11.1 测试方法

“错误”主要针对软件开发过程，“缺陷”主要针对软件产品。软件测试的目的就是在软件投入生产性运行之前，尽可能多的发现软件产品（主要是指程序）中的错误（缺陷）。

为了发现软件中的错误（缺陷），应竭力设计能暴露错误（缺陷）的测试用例。测试用例是由测试数据和预期结果构成的。一个好的测试用例极有可能发现至今为止尚未发现的错误（缺陷）的测试用例。一次成功的测试是发现了至今尚未发现的错误（缺陷）的测试。

11.1.1 软件测试阶段

1. 单元测试

也称模块测试，通常可以放在编程阶段，由程序员对自己编写的模块自行测试，检查模块是否实现了详细设计说明书中规定的功能和算法。单元测试主要发现变成和详细设计中产生的错误，单元测试计划应该在详细设计阶段制定。

单元测试期间着重从以下几个方面对模块进行测试：模块接口、局部数据结构、重要的执行通路、出错处理通路和边界条件等。

测试一个模块时需要为该模块编写一个驱动模块和若干个桩模块。驱动模块用来调用被测模块，它接收测试者提供的测试数据，并把这些数据传送给被测模块，然后从被测模块中接收测试结果，并以某种可以看见的方式将测试结果返回给测试者。桩模块用来模拟被测模块所调用的子模块，它接收被测模块的调用，检验调用参数，并以尽可能简单的操作模拟被测模块所调用的子模块功能，把结果返回被测模块。顶层模块测试时不需要驱动模块，底层模块测试时不需要桩模块。

2. 集成测试

也称组装测试，它是对由各模块组装而成的程序进行测试，主要目标是发现模块间的接口和通信功能。集成测试主要发现设计阶段产生的错误，集成测试计划应该在概要设计阶段制定。

集成的方式可分为非渐增式和渐增式。

非渐增式集成是先测试所有的模块，然后一下子把所有这些模块集成到一起，并把庞大的程序作为一个整体来测试。只适合于一些非常小的软件。

渐增式集成是将单元测试和集成测试合并到一起，它根据模块结构图，按某种次序选一个尚未测试的模块，把它同已经测试好的模块组合在一起进行测试，每次增加一个模块，直到所有模块被集成在程序中。这种测试方法比较容易定位和改正错误。

渐增式集成又可以分为自顶向下集成和自底向上集成。自顶向下集成先测试上层模块，再测试下层模块。由于测试下层模块时它的上层模块已经测试过，所以不必另外编写驱动模块。自底向上集成先测试下层模块，再测试上层模块。同样，由于测试上层模块时他的下层模块已经测试过，所以不必另外编写桩模块。

3. 系统测试

是软件测试中最后的，最完整的测试，它是在单元测试和集成测试的基础上进行的，它从全局来考察软件系统的功能和性能要求。系统测试计划应该在需求分析阶段制定。

系统测试包括确认测试和验收测试。确认测试，主要依据软件需求说明书检查软件的功能、性能及其他葛铮是否与用户的需求一致。软件配置复查时确认测试的另一项重要内容。复查的目的是保证软件配置的所有成分都已齐全，质量符合要求，文档与程序完全一致，具有完成软件维护所必须的细节。

$\alpha$测试由用户在开发者的场所进行，并且在开发者的指导下进行测试。开发者负责记录发现的问题和使用中遇到的问题。也就是说，$\alpha$测试是在“受控的”环境中进行的。

$\beta$测试是在一个或多个用户的现场由该软件的最终用户实施的，开发者通常不在现场，用户负责记录发现的错误和使用中需要的问题并把这些问题报告给开发者。也就是说，$\beta$测试是在“不受控的”环境中进行的。

经过系统测试之后的软件通常就可以交付使用了。

11.1.2 白盒测试和黑盒测试

1. 白盒测试

又称结构测试，主要用于单元测试阶段。它的前提是可以把程序看成装在一个透明的白箱子里，测试者完全知道程序的结构和处理算法。这种方法按照程序内部逻辑设计测试用例，检测程序中的主要执行通路是否都能按预定要求正常工作。

白盒测试根据软件的内部逻辑设计测试用例，常用的技术是逻辑覆盖，即考察用测试数据运行被测程序对程序逻辑的覆盖程度。主要的覆盖标准如下：

1. 语句覆盖。是指选择足够多的测试用例，使得运行这些测试用例时，被测程序的每个语句至少执行一次。是一种很弱的覆盖标准
2. 判定覆盖。又称分支覆盖，含义是，不仅每个语句至少执行一次，而且每个判定的每种可能的结果都至少执行一次。比语句覆盖强，但对程序逻辑的覆盖程度仍然不高。
3. 条件覆盖。含义是，不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取得各种可能的结果。条件覆盖不一定包含判定覆盖，判定覆盖也不一定包含条件覆盖。
4. 判定/条件覆盖。同时满足判定覆盖和条件覆盖的逻辑覆盖称为判定/条件覆盖。含义是，选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次。
5. 条件组合覆盖。含义是，选取足够的测试用例，使得每个判定表达式中条件结果的所有可能组合至少出现一次。满足条件组合覆盖的测试用例，也不一定更满足判定/条件覆盖。因此，条件组合覆盖是上述5种覆盖标准种最强的一种。然而，条件组合覆盖还不能保证程序中所有可能的路径都至少经过一次。
6. 路径覆盖。含义是，选取足够的测试用例，使得程序的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每条环路路径都至少经过一次）。路径覆盖实际上考虑了程序中各种判定结果的所有可能组合，因此是一种较强的覆盖标准。但路径覆盖并未考虑判定中的条件结果的组合，并不能代替条件符合和条件组合覆盖。

2. 黑盒测试

又称功能测试。主要用于集成测试和确认测试阶段，它把软件看做一个不透明的黑箱子，完全不考虑（或不了解）软件的内部结构和处理算法，只检查软件功能是否能按照软件需求说明书的要求正常使用，软件是否能适当的接收输入数据并产生正确的输出信息，软件运行过程中能否保持外部信息的完整性等。

黑河测试根据软件需求说明书所规定的功能来测试用例，不考虑软件的内部结构和处理算法。

常用的黑盒测试技术如下:

1. 等价类划分。在设计测试用例时，等价类划分是用的最多的一种黑盒测试方法。就是某个输入域的集合，对于一个等价类的输入值来说，它们揭示程序中错误的输入是等效的。也就是说，如果等价类中的一个输入数据能检测出一个错误，那么等价类中的其他数据也能检测出同一个数据；反之，如果等价类中的一个输入数据不能检测出某个错误，那么等价类中的其他输入数据也不能检测出这一错误。
   如果一个等价类中的数据是符合（软件需求说明书）要求的、合理的数据，则称这个等价类为有效等价类。有效等价类主要用来检验软件是否实现了软件需求说明书中规定的功能。
   如果一个等价类内的数据是不符合（软件需求说明书）要求的、不合理或非法的数据，则称这个等价类为无效等价类。无效等价类主要用来检验软件的容错性。
   黑盒测试中，利用等价类划分方法设计测试用例的步骤是：
   
   • 根据软件的功能说明，对每一个输入条件确定若干个有效等价类和若干个无效等价类，并为每个有效等价类和无效等价类编号。
   • 设计一个测试用例，使其覆盖尽可能多的尚未被覆盖的有效等价类，重复这一步，直至所有的有效等价类均被覆盖。
   • 设计一个测试用例，使其覆盖一个尚未被覆盖的无效等价类。重复这一步，直至所有的无效等价类均被覆盖。
2. 边值分析。经验表明，软件在处理边界情况时最容易出。设计一些测试用例，使软件恰好运行在边界附近，暴露出软件错误的可能性会大一些。
   通常，每一个等价类的边界，都应该着重测试，选取的测试数据应该恰好等于、稍小于或稍大于边界值。
3. 错误推测。使用等价类划分和边值分析技术，有助于设计出具有代表性的，容易暴露软件错误的测试方案。但是，不同类型不同特定的软件通常又有一些特殊的容易出错的地方。错误推测法主要依靠测试人员的经验和直觉，从各种可能的测试方案中选出一些最可能引起程序出错的方案。
4. 因果图。是根据输入条件和输出条件之间的因果关系来设计测试用例的，它首先检查输入条件的各种组合情况，并找出输出结果对输入结果的依赖关系，然后为每种输出条件的组合设计测试用例。

11.1.3 缺陷的分类和级别

1. 输入/输出错误。
2. 逻辑错误
3. 计算错误
4. 接口错误
5. 数据错误

错误的严重程度分类：
1. 轻微：界面文字有个别的错别字，但不影响理解
2. 中等：界面文字错误可能误导操作者
3. 使人不悦：数字串被断开
4. 影响使用：有些交易没有处理
5. 严重：丢失交易
6. 非常严重：不正确的交易处理
7. 季度严重，经常出现不正确的交易
8. 无法容忍：数据库遭到破坏
9. 灾难性：系统无法工作
10. 传染性：可导致其他系统无法工作

11.1.4 调试

又称为排错。测试成功的标志是发现了错误。根据错误迹象确定错误的原因和准确位置并加以改正，主要依靠排错技术。

隐藏在程序中的错误具有下列条数的性质：

1. 错误的外部征兆远离引起错误的内部原因，对于高度耦合的程序结构此类现象更为严重。
2. 纠正一个错误造成另一错误现象（暂时）的消失。
3. 某些错误征兆只是假象。
4. 因操作人员一时疏忽造成的某些错误征兆不易追踪
5. 错误是由于分时而不是程序引起的
6. 输入条件难以精确的再构造。
7. 错误征兆时有时无，此现象对嵌入式系统尤其普遍。
8. 错误是由于把任务分布在若干台不同处理机上运行而造成的。

常用的排错策略分为三类：

1. 原始类。主要思想是“通过计算机找错”。
2. 回溯类。方法是从出现错误征兆处开始，人工的沿控制流程往回追踪，直至发现出错的根源，不行的是程序变大后，可能的回溯路线显著增加，以致人工进行完全回溯可望而不可即。
3. 排除类。基于归纳和演绎原理，采用“分治”的概念，首先分析与错误出现有关的所有数据，假想一个错误原因，用这些数据证明或反驳它，；或者一次列出所有可能的原因，通过测试一一排除。只要某次测试结果说明某种假设已呈现端倪，则立即精化数据，乘胜追击。

11.2 评审方法

1. 软件需求评审。在软件需求分析结束后必须进行软件需求评审，以确保在软件需求说明书中所规定的各项需求的合适性。
2. 概要设计评审。在软件概要设计结束后必须进行概要设计评审，以评价软件设计说明书中所描述的软件概要设计在总体结构、外部接主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性。
3. 详细设计评审。在软件详细设计结束后必须进行详细设计评审，以评价软件设计说明书中所描述的软件详细设计在每一个基本部件的工鞥呢、算法和过程描述等方面的合适性。
4. 软件验证和确认评审。在软件验证与确认计划完成后必须进行软件验证与确认评审，以评价软件验证与确认计划中所规定的验证与确认方法的合适性和完整性。
5. 功能检查。在软件释放前，要对软件进行功能检查，以验证所开发的软件已经满足在软件需求说明书中规定的所有需求。
6. 物理检查。在软件验收前，要对软件进行物理检查，以验证程序和文档已经一致并做好了交付的准备。
7. 综合检查。在软件验收时，要允许用户或用户所委托的软件对所要要收的软件进行设计抽样的综合检查，已验证代码和设计文档的一致性、接口规格说明的一致性（硬件和软件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性。
8. 管理评审。要对计划的执行情况定期（或按阶段）进行历评审，这些评审必须由独立于被评审单位的机构或授权的第三方主持进行。

在评审过程中，以下几点值得注意：

1. 不应以测试代替评审。
2. 评审人员应关注产品而不应评论开发人员。
3. 评审人员应关注于实质性问题。
4. 评审会议不应变为问题解决方案讨论会。
5. 评审应被安排进项目计划。
6. 评审参与者应了解整个评审过程。
7. 评审人员事先应对评审材料充分了解。
8. 应重视精神的组织工作。

11.3 验证与确认

1. 验收

1. 合同验证。应根据下列准则验证合同：
   
   • 供方具有满足需求的能力
   • 需求是一致的并覆盖了用户的需要
   • 为处理需求变更和升级问题规定了适当的规程。
   • 规定了各方之间的接口及其合作规程与范围，包括所有权、许可权、版权和保密要求。
   • 按照需求规定了验收准则和规程
2. 过程验证。应根据下列准则验证过程：
   
   • 项目是适当的、及时的。
   • 为项目选择的过程是适当的并满足合同要求的。
   • 用于项目过程的标准、规程和环境是适当的。
   • 根据合同要求为项目配备了经过培训的人员。
3. 需求验证。应根据下列准则验证需求：
   
   • 需求是明确的、一致的、无歧义的
   • 需求是可行的。
   • 需求是可测试的。
4. 设计验证。应根据下列准则验证设计：
   
   • 设计师正确的，是可以实现需求的。
   • 可以从需求导出设计，可以从设计追踪需求
5. 编码验证。应根据下列准则验证编码：
   
   • 编码是正确的，可以实现设计和需求。
   • 可以从设计导出编码，可以从编码追踪设计
6. 集成验证。应根据下列准则验证集成：
   
   • 每一个软件项的软件部分和软件单元已完整、正确的集成到软件项中。
   • 系统的硬件项、软件项和人工操作已完整、正确的集成到系统中。
7. 文档验证。应根据下列准则验证文档：
   
   • 文档是充分的，完备的、一致的。
   • 文档制定是及时的。
   • 文档配置管理遵循了规定的规程。

2. 确认

1. 编写测试需求、测试用例和测试规程。
2. 确保这些测试需求、测试用例和测试规程可以反映软件产品的预期用途。
3. 执行测试
4. 确认软件产品满足其预期用途。

11.4 测试自动化

一些适于考虑进行自动化的测试工作为：

1. 测试用例的生成（包括测试输入、标准输出、测试操作指令等）
2. 测试的执行控制（包括单机与网络多机分布运行、夜间及假日运行、测试用例调用控制、测试对象、范围、版本控制等）
3. 测试结果与标准输出的对比
4. 不吻合的测试结果的分析、记录、分类和通报
5. 总测试状况的统计，报表的产生

11.5 面向对象的测试

1. 面向对象测试模型

面向对象的软件测试分为：面向对象分析的测试、面向对象设计的测试、面向对象编程的测试、面向对象的单元测试、面向对象的集成测试和面向对象的系统测试。

2. 面向对象分析的测试

传统的面向过程分析是一个功能分解的过程，是把一个系统看成可以分解的功能的集合。功能分解分析法的着眼点在于一个系统需要什么样的信息处理方法和过程，以过程的抽象来对待系统的需要。面向对象的分析直接映射问题空间，将问题空间内的实例抽象为对象，用对象的结构反映问题空间的复杂实例和复杂关系，用属性和操作表示实例的特性和行为。OOA的结果为后面阶段类的选定和实现、类层次结构的组织和实现提供平台。因此，对OOA的测试，应从以下方面考虑：

1. 对认定的对象的测试。
2. 对认定的结构的测试
3. 对认定的主题的测试
4. 对定义的属性和实例关联的测试
5. 对定义的服务和消息关联的测试

3. 面向对象设计的测试

传统的结构化设计方法，采用面向作业的思路，它把系统分解以后，提出一组作业，这些作业是以过程实现系统的基础构造，把问题域的分析转化为求解域的设计，分析的结果是设计阶段的输入。而OOD以OOA为基础归纳出类，并建立类结果或进一步构造成类库，实现分析结果对问题空间的抽象。OOD确定类和类结构不仅满足当前需求分析的要求，更重要的是通过重新组合或加以适当的补充，能够方便的实现功能的重用和扩充，以不断适应用户的要求。因此，对OOD的测试，应从如下三个方面考虑：

1. 对认定的类的测试
2. 对构造的类层次结构的测试
3. 对类库的支持的测试

4. 与面向对象编程的测试

在OOP阶段，忽略类功能实现的细则，将测试的焦点集中在类功能的实现和相应的面向对象程序风格，主要体现为以下两个方面：

1. 数据成员是否满足数据封装的要求
2. 类是否实现了要求的功能

5. 面向对象的单元测试

将操作作为类的一部分

6. 面向对象的集成测试

对OO软件的集成测试也有两种不同策略：第一种称为基于线程的测试，集成系统的一个输入或事件所需的一组类，每个线程被集成并分别测试，并使用回归测试以保证没有产生副作用。第二种称为基于使用的测试，首先测试那些几乎不使用其他类的类（称为独立类）并开始构造系统，当独立类测试完成后，下一层的使用独立类的类（称为依赖类）被测试。这个依赖类层次的测试序列以致持续到构造完整个系统。

7. 面向对象的系统测试

系统测试时，应该参考OOA分析的结果，对应描述的对象、属性和各种服务，检查软件是否能够完全”再现“问题空间。系统测试不仅是检查软件的整体行为表现，从另一个侧面看，也是对软件开发设计的再确认。

第十二章 嵌入式系统设计

12.1 嵌入式系统概论

是一种以应用为中心，以计算机技术为基础，可以使用不同应用对功能、可靠性、成本、体积、功耗等方面的要求，集可配置，可裁剪的软、硬件与一体的专用计算机系统。核心要素如下：

1. 嵌入性：指计算机嵌入到对象系统中，且满足对象系统的环境要求，如物理环境（小型）、电气/气氛环境（可靠）、成本（价廉）等要求。
2. 专用性：指软、硬件的裁剪性，满足对象要求的最小软、硬件配置等
3. 计算机系统：指嵌入式系统必须是一个能满足对象系统控制要求的计算机系统。

归纳起来，典型的嵌入式系统具有以下特点：

1. 系统专用性强。嵌入式系统是针对具体应用的专门系统。个性化很强，软件和硬件结合紧密。一般要针对硬件进行软件的开发和移植，根据硬件的变化和增减对软件进行修改。
2. 系统实时性强。嵌入式系统中有相当一部分系统要求对外来事件在限定的时间内及时作出响应，具有实时性。
3. 软、硬件依赖性强。
4. 处理器专用。嵌入式系统的处理器一般是为某一特定目的和应用而专门设计的。通常具有功耗低、体积小、集成度高等优点。
5. 多种技术紧密结合。嵌入式系统通常是计算机技术、半导体技术、电力电子技术及机械技术与各行业的具体应用相结合的产物。
6. 系统透明性。
7. 系统资源首先

12.2 嵌入式系统的组成

12.2.1 硬件架构

1. 嵌入式处理器

是嵌入式系统的核心部件，可以分为如下几类：

1. 嵌入式微处理器EMPU。是由通用计算机的CPU演变而来。功能上跟普通的微处理器基本一致，但是它具有体积小、功耗低、质量轻、成本低及可靠性高的优点。通常，嵌入式微处理器和ROM、RAM、总线接口及外设接口等部件安装在一块电路板上，称为单板计算机。
2. 嵌入式微控制器EMCU。又称单片机，就是整个计算机系统都集成到一块芯片中。一般以某一种微处理器内核为核心，芯片内部集成有ROM/EPROM/E2PROM、RAM、总线、总线逻辑、定时器/计数器、WatchDog（监督定时器）、并口/串口、数模/模数转换器、山村等必要外设。与嵌入式微处理器相比，最大特点是单片化，因而体积更小，工号和成本更低，可靠性更高。
3. 嵌入式数字信号处理器EDSP。是一种专门用于信号处理的处理器，DSP芯片内部采用程序和数据分开的哈佛结构，具有专门的硬件乘法器，广泛采用流水线操作，提供特殊的DSP指令，可以用来快速实现各种数字信号的处理算法。
4. 嵌入式片上系统ESOC。是一种在一块芯片上继承了很多功能模块的复杂系统，如微处理器内核、RAM、USB、IEEE 1394、Bluetooth等。大幅缩小了系统的体积、降低了系统的复杂度，增强了系统的可靠性。

2. 总线

是连接计算机系统内部各个部件的共享高速通路。嵌入式系统的总线一般分为片内总线和片外总线。片内总线是指嵌入式微处理器内的CPU与片内其他部件连接的总线；片外总线是指总线控制器集成在微处理器内部或外部芯片上的用于连接外部设备的总线。

1. AMBA总线，先进微控制器总线架构。该总线规范独立于处理器和制造工艺技术，增强了各种应用中外设和系统单元的可重用性，提供将RISC处理器与IP核集成的机制。该规范定义了三种总线：
   
   • 先进性能总线AHB。AHB由主模块、从模块和基础结构三部分组成，整个AHB总线上的传输都是由主模块发起、从模块响应。基础结构包括：仲裁器、主从模块多路选择器、译码器、名义主模块、名义从模块等。AHB系统具有时钟边沿出发、无三态、分帧传输等特性。AHB也支持复杂的事务处理，如突发传送、主单元重试、流水线操作以及分批事务处理等。
   • 先进系统总线ASB。用于高性能模块的互连，支持突发数据传输模式，叫老的总线格式，逐步由AHB总线所替代。
   • 先进外设总线APB。主要用于连接低带宽外围设备，其总线结构只有唯一的主模块，即APB桥，它不需要中才气以及响应/确认信号，以最低能耗为原则进行设计，具有总是两周期传输、无等待周期和响应信号的特点。
2. PCI总线，外围构件互连总线。该总线式地址数据复用的高性能32位与64位总线，是微处理器与外围设备互连的机构，它规定了互联协议、电器、机械以及配置空间的标准。PCI是不依赖于具体处理器的局部总线，从结构上看，PCI是在微处理器和原来的系统总线之间加入的以及总线，有一个桥接电路负责管理，实现上下接口和协调数据传送，管理器提供了信号缓冲，使多种外设能够在高时钟频率下保持高性能。PCI总线支持主控技术，允许智能设备在需要时获得总线控制权，以加速数据传输。
3. Avalon总线。用于可编程片山系统中连接片上处理器和其他IP模块的一种简单总线协议，规定了主部件和从部件之间进行连接的端口和通信时序。

几种嵌入式总线技术的主要特点

总线类型	主要特点
AMBA总线	带宽高；采用地址与数据分离的流水线操作；支持固定长与不定长突发传送；兼容性好；支持多个总线主设备
PCI总线	速度快；支持线性突发传送；支持即插即用；兼容性好；可靠性高；可扩展性好
Avalon总线	支持字节、半字和字传输；同步接口；独立的地址线、数据线和控制线；设备内嵌译码部件；支持多个总线主设备；自动生成仲裁机制；多个主设备可同时操作使用一条总线；可自动调整总线宽度，以适应尺寸不匹配的数据。

3. 存储器

主要包括主存和外存。

1. 高速缓存。是存放当前使用最多的程序代码和数据的，即主存中部分内容的副本，在嵌入式系统中，Cache全部集成在嵌入式微处理器内部，可以分为：数据Cache、指令Cache和混合Cache。
2. 主存。是处理器能够直接访问的存储器，用来存放系统和用户的程序和数据，系统上电后，主存中的代码直接运行，主存的主要特点是速度快，一般采用ROM、EPROM、NOR flash、SRAM和DRAM等存储器件。
3. 外存。是不与运算器直接联系的后备存储器，用来存放不常用或暂时不用的信息，外存一般以非易失性存储器构成，数据能够持有保存，即使断电，也不消失。

4. I/O设备与接口

嵌入式系统中接口电路的设计需要首先考虑的是电平匹配问题，嵌入式系统微处理器所提供与接收信号的电平，必须与所连接的设备的电平相匹配，否则将导致电路损坏或逻辑判断错误。其次，还要考虑驱动能力和干扰问题等因素。

当前，在嵌入式系统中广泛应用的接口主要有：

1. RS-232接口。是一种串行通信总线标准，是数据通信设备和数据终端设备间传输数据的接口总线，RS-232-C标准规定其最高速率为20kbps，在低码元畸变的情况下，最大传输距离为15米，通过使用增强器，其传输距离已经延长到1000米左右。
2. USB接口。通用串行总线。支持USB外部设备到主机外部总线的连接。在USB系统中，必须有一个USB主控制器，USB设备通过四根电缆与USB主控制器直接或间接相连。最高速度可达480Mbps。
3. 1394接口。由6根电缆组成，包括一堆电源线和两队双绞控制线。IEEE1394定义了三种传输速率：98.304Mbps、196.608Mbps、392.216Mbps，分别称之为S100、S200和S400，线缆的长度一般不会超过4.5米。
   该标准通过所有连接设备建立起一种对等网络，不需要主控结点来控制数据流，即跟USB技术相比，最大的区别是不需要主控制器，不同的外设之间可以直接传递信息，此外，采用该技术，两台计算机可以共享同一外部设备。
   该标准同时支持同步和异步传输两种模式。在异步传输模式下，信息的传递可以被中断，在同步传输模式下，数据将不受任何中断和干扰下实现连接传输。

12.2.2 软件架构

软件架构体系自底向上有三部分组成：嵌入式操作系统、应用支撑软件和应用软件。

1. 操作系统。有操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务，其他大部分的功能则由支撑软件完成。
2. 应用支撑软件。有窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。一般用于一些浅度嵌入的系统中。
3. 应用软件。是系统整体功能的集中体现。

12.3 嵌入式开发平台与调试环境

12.3.1 嵌入式系统软件开发平台

1. 交叉平台开发环境

嵌入式系统的软件开发采用交叉平台开发方法CPD，即软件在一个通用平台上开发，而在另一个嵌入式目标平台上运行。这个用于开发嵌入式软件的通用平台通常叫做宿主机系统，被开发的嵌入式系统通常叫做目标机系统。而当软件执行环境和开发环境一致时的开发过程则成为北地开发ND。

通常包含三个高度集成的部分。

1. 运行在宿主机和目标机上的强有力的交叉开发工具和实用程序
2. 运行在目标机上的高性能、可裁剪的实时操作系统
3. 连接宿主机和目标机的多种通信方式，例如，以太网、串口线、在线仿真器ICE或ROM仿真器等

2. 交叉编译环境

宿主机提供的基本开发工具是交叉编译器、交叉链接器和源代码调试器。作为目标机的嵌入式系统则可能提供一个动态装载器、链接装载器、监视器和一个调试代理等。在目标机和宿主机之间有一组连接，通过这组连接程序代码映像从宿主机下载到目标机，这组连接同时也用来传输宿主机和目标机调试代理之间的信息。

交叉编译器将用户编写的C/C++/Java源代码文件根据目标机的CPU类型生成包含二进制代码和程序数据的目标文件。在此过程中，交叉编译器会产成一个符号表，包含所产生的目标文件中指向映像地址的富豪命，当建立重定位输出时，编译器为每个相关的符号产生地址。

目前，嵌入式系统中常用的目标文件格式是COFF（公共对象文件）和ELF（可执行链接格式）。另外，一些系统还需要有一些专门的工具将上述格式转换成二进制代码格式才能使用。

通常，一个目标文件包含：

1. 关于目标文件的通用信息，如文件尺寸、启动地址、代码段和数据段等。
2. 机器架构特定的二进制指令和数据。
3. 符号表和重定位表
4. 调试信息

12.3.2 嵌入式开发调试

1. 直接调试法

就是讲目标代码下载到目标机上，让其执行，通过观察指示灯来判断程序的运行状态。基本步骤是：

1. 在宿主机上编写程序。
2. 在宿主机上变异、链接生成目标机可执行程序代码。
3. 将可执行代码写入目标机的存储器中
4. 在目标机运行程序代码
5. 判断程序的运行情况，如有错误则纠正错误，重复以上步骤，直到正确为止。
6. 将可执行代码固化到目标机，开发完成。

2. 调试监控法

也叫插桩法。目标机和宿主机一般通过串行口、并行口或以太网相连接，采用这种方法还需要在宿主机的调试器内和目标机的操作系统上分别启动一个功能模块，然后通过这两个功能模块的相互通信来实现对应用程序的调试。在目标机上添加的模块叫做桩，也叫调试服务器或调试监控器，主要有两个作用：其一，监视和控制被调试的程序；其二，跟宿主机上调试程序通信，接收控制指令、返回结果等。

基本步骤是：

1. 在宿主机上编写程序的源代码。
2. 在宿主机上编译、链接生成目标机可执行程序。
3. 将目标机可执行程序下载到目标机的存储器中。
4. 使用调试器进行调试
5. 在调试器帮助下定位错误
6. 在宿主机上修改源代码，纠正错误，重复上述步骤直到正确为止。
7. 将可执行代码固话到目标机上。

相对于直接测试法，插桩法明显的提高了开发效率，降低了调试的难度，缩短了产品的开发周期，有效的降低了开发成本。但是仍有明显的缺点，主要体现在以下几个方面：

1. 调试监控器本身的开发是个技术难题。
2. 调试监控器在目标机中药占用一定的系统资源。
3. 调试时，不能响应外部中断，对由时间特性的程序不适用
4. 在调试过程中，被调试的程序实际上是在调试监控器所提供的环境中运行，这个环境可能会与实际目标程序最终的运行环境有一定的差异，这种差异可能导致调试通过的程序最终仍不能运行。

为了克服插桩法的缺点，出现了一种改良的方法，即ROM仿真器法

ROM仿真器法可以被认为是一种用于替代目标机上ROM芯片的硬件设备，ROM仿真器一端跟宿主机相连，一端通过ROM芯片的引脚插座与目标机相连。对于嵌入式处理器来说，ROM仿真器像是一个只读存储器，而对于宿主机来说，像一个调试监控器。该方法有如下优点：

1. 不必再开发调试监控器
2. 由于是通过ROM仿真器上的串行口、并行口或网络接口与宿主机连接，所以不必占用目标机上的系统资源。
3. ROM仿真器代替了目标机上原来的ROM，所以不必占用目标机上的存储空间来保存调试监控器
4. 另外，即使目标机本身没有ROM，调试依然可以进行，并且不需要使用专门工具向ROM写入程序和数据。

3. 在线仿真法

ICE是一种用于替代目标机上CPU的设备。对于目标机来说，在线仿真器就相当于他的CPU，在线仿真器本身就是一个嵌入式系统，有自己的CPU、内存和软件。即使没有目标机，仅用在线仿真器也可以进行程序的调试。

在线仿真器和宿主机一般通过串行口、并行口或以太网相连接。在连接在线仿真器和目标系统时，用在线仿真器的CPU引出端口替代目标机的CPU。

在线仿真器能实时的检查运行程序的处理器的状态，设置硬件断点和进行实时跟踪，所以提供了更强的调试功能。支持多种时间的触发断点，这些时间包括内存读写、I/O读写及中断等。一个重要特性就是实时跟踪。但是，在线仿真器的价格一般都比较昂贵。

4. 片上调试法

ICD是CPU芯片内部的一种用于支持调试的功能模块。按照实现的技术，片上调试器可以分为仿调试监控器、后台调试模式BDM、连接测试存取组JTAG和片上仿真OnCE等几类。

该方法的主要优点是：不占用目标机的通信端口等资源；调试环境和最终的程序运行环境基本一致；无需在目标机上增加任何功能模块即可运行；支持软、硬断电；支持跟踪功能，可以精确计量程序的执行时间；支持时序逻辑分析等功能。

该方法的缺点是：实时性不如在线仿真器法强；使用范围受限，如果目标机不支持片上调试功能，则该方法不适用；实现技术多样，标准不完全统一，工具软件的开发和使用均不方便。

5. 模拟器法

模拟器是运行在宿主机上的一种纯软件工具，它通过模拟目标机的指令系统或目标机操作系统的系统调用来达到在宿主机上运行和调试嵌入式应用程序的目的。

适合于调试非实时的应用程序，这类程序一般不与外部设备交互，实时性不强，程序的执行过程是时间封闭的，开发者可以直接在宿主机上验证程序的逻辑正确性。当确认无误后，将程序写入目标机上即可正确运行。

模拟器有两种主要类型：一类是指令级模拟器，在宿主机模拟目标机的指令系统；另一类是系统调用级模拟器，在宿主机上模拟目标操作系统的系统调用。

使用模拟器的最大好处是在实际的目标机不存在的条件下就可以为其开发应用程序，并且在调试时利用宿主机的资源提供更消息的错误诊断信息，但模拟器有许多不足之处。

1. 模拟器环境和实际运行环境差别很大，无法保证在模拟条件下通过的应用程序也能在真实环境中正常运行。
2. 模拟器不能模拟所有的外部设备，嵌入式系统通常包含诸多外设，但模拟器只能模拟少数部分。
3. 模拟器的实时性差，对于实时类应用程序的调试结果可能不可靠。
4. 运行模拟器需要较高的宿主机配置。

12.4 嵌入式网络系统

12.4.1 现场总线网

是一种将数字传感器、变换器、工业仪表及控制执行机构等现场是被与工业控制单元，现场操作站等互相连接而成的网络。

是一种低带宽的底层控制网络，位于生产控制和网络结构的底层，因此也被称为底层网。主要应用于生产现场，在测量控制设备之间实现双向的、串行的、多节点的数字通信。

现场总线控制系统FCS是运用现场总线连接各控制器及仪表设备而构成的控制系统，该控制系统将控制功能彻底下放到现场，降低了安装成本和维护费用。现场总线控制系统把单个分散的测量控制设备变成网络节点，以现场总线为纽带，使这些分散的设备称为可以互相沟通信息共同完成自动控制任务的网络系统。

12.4.2 家庭信息网

是一种把家庭范围内的个人计算机、家用电器、水、电、气仪表、照明设备和网络设备、安全设备连接在一起的局域网。

12.4.3 无线数据通信网

是一种通过无线电波传送数据的网络系统。

12.4.4 嵌入式Internet

1. 嵌入式Internet的接入方式

嵌入式设备上集成了TCP/IP协议栈及相关软件，这类设备可以作为Internet的一个节点，分配有IP地址，与Internet直接互联。

或通过接入设备接入Internet。

2. 嵌入式TCP/IP协议栈

1. 嵌入式协议栈的调用接口与普通的协议栈不同。普通协议栈的套接字接口是标准的，应用软件的兼容性好。
2. 嵌入式协议栈的可裁剪性。嵌入式协议栈多数是模块化的，如果存储器的空间有限，可以在需要时进行动态安装，并且都省去了接口转发、全套的Internet服务工具等几个针对嵌入式系统非必须的部分。
3. 嵌入式协议栈的平台兼容性。
4. 嵌入式协议栈的高效率。

12.5 嵌入式数据库管理系统

是指在嵌入式设备上使用的数据库管理系统。也称为移动数据库或嵌入式移动数据库。作用主要是解决移动计算环境下数据的管理问题。移动数据库是移动计算环境中的分布式数据库。

在嵌入式系统中引入数据库技术，主要是因为直接在嵌入式操作系统或裸机智商开发信息管理应用程序存在如下缺点：

1. 所有的应用程序都要重复进行数据的管理工作，增加了开发难度和代价。
2. 各应用之间的数据共享性差。
3. 应用软件的独立性、可以执行差、可重用度低。

12.5.1 使用环境的特点

1. 设备随时移动性
2. 网络频繁断接
3. 网络条件多样化
4. 通信能力不对称

12.5.2 系统组成与关键技术

1. 嵌入式数据库管理系统。是一个功能独立的单用户数据库管理系统，可以独立于同步服务器和主数据库管理系统运行，对嵌入式系统中的数据进行管理，也可以通过同步服务器连接到主服务器上，对主数据库中的数据进行操作，还可以通过多种方式进行数据同步。
2. 同步服务器。是嵌入式数据库和主数据库之间的连接枢纽，保证嵌入式数据和主数据库中数据的一致性。
3. 数据服务器。数据服务器的主数据及数据库管理系统可以采用Oracle或Sybase等大型通用数据库系统
4. 连接网络。主数据库服务器和同步服务器之间一般通过高带宽、低延迟的固定网络进行连接。移动设备和同步服务器之间的连接根据设备的具体情况可以是无线局域网、红外连接、通用串行线或公众网等。

1. 嵌入式移动数据库在应用中的关键

1. 数据的一致性
2. 高效的事务处理
   
   • 根据网络连接情况来确定事务处理的优先级，网络连接速度高的事务优先处理
   • 根据操作时间来确定事务是否迁移，即长时间的事务操作将全部迁移到服务器上执行，无须保证网络的一直畅通。
   • 根据数据量的大小来确定事务是上载执行还是下载数据副本执行后上载；
   • 完善的日志记录策略
   • 事务处理过程中，网络断接处理时采用服务器发现机制还是采用客户端声明机制。
   • 事务移动过程中的用户位置属性的实时更新。
3. 数据的安全性

2. 移动数据库管理系统的特性

1. 微核结构，便于实现嵌入式功能。
2. 对标准SQL的支持
3. 事务管理功能。
4. 完善的数据同步机制。应具有以下几个特点：
   
   • 提供多种数据同步方式，具有上载同步、下载同步和完全同步三种方式。
   • 具有完善的冲突检测机制和灵活的冲突解决方案，具有冲突日志记录功能
   • 支持快速同步，系统同步时，只传递变化的数据，节省了大量的同步时间
   • 支持标的水平分割和垂直分割复制，最大限度降低了嵌入式数据库的大小。
   • 支持异构数据源连接同步，可以用支持ODBC的异构数据源作为主数据库和嵌入式设备上的数据库进行数据同步。
   • 具有主动同步的功能。允许用户对系统提供的同步事件自定义过程实现，提供了最大灵活度的同步过程。
5. 支持多种连接协议
6. 完备的嵌入式数据库管理功能
7. 平台无关性与支持多种嵌入式操作系统。
8. 零管理特性

12.6 实时系统与嵌入式操作系统

实时系统可以看成是对外部事件能够及时响应的系统。这种系统最重要的特征是时间性，也就是实时性，实时系统的正确性不仅依赖于系统计算的逻辑结果，还依赖于产生这些结果的时间。

12.6.1 嵌入式系统的实时概念

1. 逻辑（或功能）正确，是指系统对外部事件的处理能够产生正确的结果。
2. 时间正确，是指系统对外部事件的处理必须在预定的周期内完成。
3. 死线或时限、死亡时限、截止时间，是指系统必须对外部事件进行处理的最迟时间界限，错过此界限可能产生严重的后果。
4. 实时系统。是指功能正确和时间正确同时满足的系统，二者同等重要。

对于实时系统的划分，通常还可以根据实时性的强弱，即系统必须对外部事件作出响应的时间长短，将实时系统分为：

1. 强实时系统，其系统的响应时间非常短，通常在毫秒级或微秒级。
2. 一般实时系统，其系统响应时间比强实时系统要求姚笛，通常在秒级
3. 弱实时系统，其系统响应时间可以更长，也可以随系统负载的轻重而变化。

根据对错失时限的容忍程度，可以将实时系统分为软实时系统和硬实时系统。

1. 硬实时系统，指系统必须满足其灵活性接近零时限要求的实时系统。时限必须满足否则就会产生灾难性后果，并且实现之后得到的处理结果或是零级无用，或是高度编制。
2. 软实时系统，指必须满足时限的要求，但有一定灵活性的实时系统。时限可以包含可变的容忍等级、平均的截止时限，甚至是带有不同程度的、可接受性的响应时间的统计分布。在软实时系统中，时限错失通常不会导致系统失败等严重后果。

12.6.2 嵌入式操作系统概述

1. 嵌入式操作系统的特点

1. 微型化：嵌入式操作系统的运行平台不是通用计算机，而是嵌入式计算机系统。这类系统一般没有大容量的内存，几乎没有外存，因此，嵌入式操作系统必须做的小巧，以尽量少占用系统资源。为了提高系统的执行速度和可靠性，嵌入式系统中的软件一般都固话在存储器芯片中，而不是存放在磁盘等载体中。
2. 代码质量高：在大多数应用中，存储空间依然是宝贵的资源，者就要求程序代码的质量要搞，代码要尽量精简。
3. 专业化：嵌入式系统的硬件平台多种多样，处理器更新速度快，每种都是针对不同的应用领域而专门设计。因此，嵌入式操作系统需要有很好的适应性和移植性，还要支持多种开发平台
4. 实时性强：嵌入式系统广泛应用于过程控制、数据采集、通信、多媒体信息处理等要求实时响应的场合，因此实时性称为嵌入式操作系统的又一特点。
5. 可裁剪、可配置：应用的多样性要求嵌入式操作系统具有较强的适应能力，能够根据应用的特点和具体要求进行灵活配置和合理裁剪，以适应微型化和专业化的要求。

2. 嵌入式操作系统的分类

1. 商业型。

2. 免费型。典型的由Linux

3. 实时嵌入式操作系统RTEOS。支持实时系统工作，首要任务是调度一切可利用资源，以满足对外部事件响应的实时时限，其次着眼于提高系统的使用效率。主要用子啊控制、通信等领域

4. 非实时嵌入式操作系统。不特别关注单个任务响应时限，平均性能、系统效率和资源利用率一般较高，适合于实时性要求不严格的消费类电子产品，如个人数字助理、机顶盒等。

12.6.3 实时嵌入式操作系统

1. 实时内核型的RTEOS：这类操作系统，驱动程序传统嵌在内核之中，应用程序和中间件实现在标准的应用程序接口之上。
2. 实时通用型的RTEOS：这类操作系统，驱动程序并非晨读嵌入到讷河中，而是在内核之上实现，并且仅包含少数必须的驱动程序，应用程序和中间件可以直接在驱动程序之上实现，而不必在标准的APIs上实现。

1. 嵌入式实时操作系统的关键特性

1. 满足嵌入式应用的高可靠性
2. 满足应用需要的可裁剪能力
3. 内存需求少
4. 运行的可预测性
5. 采用实时调度策略
6. 系统的规模紧凑
7. 支持从ROM或RAM上引导和运行
8. 对不同的硬件平台均有更好的可移植性。

2. 嵌入式实时操作系统的实时性能指标

1. 任务切换时间：指CPU控制权由运行太的任务转移给另外一个就绪任务所需要的时间，包括在进行任务切换时，保存和恢复任务上下文所花费的时间及选择下一个待运行任务的调度时间，该指标跟微处理器的寄存器数目和系统结构有关。相同的操作系统在不同微处理器上运行时所花费的时间可能不同。
2. 中断处理相关的时间指标。
   
   • 中断延迟时间，指从中断发生到系统获知中断的时间，主要受系统做大关中断时间的影响，关中断时间越长，中断延迟也就越长。
   • 中断处理执行时间，改时间由具体的应用决定
   • 中断响应时间，指从中断发生到开始执行用户中断服务例程的时间。
   • 中断恢复时间，指从用户中断服务例程结束回到被中断的代码之间的时间。
   • 最大关中断时间，包含两个方便，一是内核最大关中断时间，及内核在执行临界区代码时关中断；二是应用关中断时间，关中断最大时间是这两种关中断时间的最大值。
   • 任务响应时间，指从任务对应的中断产生到该任务真正开始运行的时间。
     对于可抢占式调度，中断恢复的时间还要加上进行任务切换和恢复新的任务上下文的时间。
3. 系统响应时间，指系统在发出处理请求到系统做出应答的时间，即调度延迟，这个时间的大小主要有内核任务调度算法所决定。

12.6.4 主流嵌入式操作系统介绍

12.7 嵌入式系统开发设计

主要任务是定义系统的功能、决定系统的架构，并将功能映射到系统实现架构上。

12.7.1 嵌入式系统设计概述

1. 嵌入式系统设计的特点

1. 软、硬件协同并行开发
2. 微处理器的类型多种多样
3. 实施嵌入式操作系统具有多样性
4. 与通用系统开发相比，可利用系统资源很少
5. 应用支持少
6. 要求特殊的开发工具
7. 软、硬件都要很健壮
8. 调试很困难

2. 嵌入式系统的技术指标

1. NRE成本（非重复性工程成本）：设计系统所需要支付的一次性货币成本，即一旦设计完毕，不需要额外支付的设计费用，就可以制造任意数的产品。
2. 单位成本：生产单个产品所需要支付的货币成本，不包含NRE成本。
3. 大小：指系统所占的空间，对软件而言，一般用字节数来衡量；对硬件而言，则用逻辑门或晶体管的数目来衡量。
4. 性能：系统完成规定任务所需的时间，是设计时最常用的设计指标，主要有两种衡量方式，一是响应时间，即开始执行到任务结束之间的时间。二是完成量，即单位时间内所完成的任务量。
5. 功率：系统所消耗的功率，决定了电池的寿命或电路的散热需求。
6. 灵活性：在不增加NRE成本的前提下，改变系统功能的能力
7. 样机建立时间：建立系统可运行版本所需的时间，系统样机可能比最终产品更大更昂贵，但可以验证系统的额用途和正确性，改进系统的功能。
8. 上市时间：从系统开发到可以上市卖给消费者的时间，最主要的影响因素包括设计时间、制造时间和检测时间
9. 可维护性：系统推出或上市后进行修改的难易程度，特别是针对非原始开发人员进行的修改。
10. 正确性：正确实现了系统的功能，可以在整个世界过程中检查系统的功能，也可以插入测试电路检验是否正确。
11. 安全性：系统不会造成伤害的概率。

3. 嵌入式系统的设计挑战

1. 需要多少硬件
2. 如何满足时限
3. 如何减少系统的功耗
4. 如何保证系统的可升级性
5. 如何保证系统的可靠性
6. 测试的复杂性
7. 可视性和可控制性有限
8. 开发环境受限

12.7.2 开发模型与设计流程

1. 常用开发模型

1. 瀑布模型。由五个主要阶段组成：需求分析阶段确定目标系统的基本特点；系统结构设计阶段将系统的功能分解为主要的构架；编码阶段主要进行程序的编写和调试；测试阶段检测错误；最后一个阶段是维护阶段，主要负责修改代码以适应环境的变化，并改正错误、升级。各个阶段的工作和信息总是由高级的抽象到较详细的设计步骤单向流动是一个理想的自顶向下的设计模型。
2. 螺旋模型。假定要建立系统的多个版本，早起的版本是一个简单的实验模型，用于帮助设计者建立对系统的直觉和积累开发此系统的经验，随着设计的进展，会创建更加复杂的系统。在每一层设计中，设计者都会经过需求分析、结构设计、测试三个阶段。在后期，当构成更复杂的系统版本时，每一个阶段都会有更多的工作，并需要扩大设计的螺旋。
3. 逐步求精模型。是一个系统被建立多次，第一个系统被称为原型，其后逐个将系统进一步求精。
4. 层次模型。从最初的完整系统设计到个别部件的设计，设计的流程随着系统的抽象层次的变化而变化，从最高抽象层次的整体设计到中间抽象层次的整体设计，再到每个具体模块的设计，都是逐层展开的。

2. 嵌入式系统的设计方法

一个良好的嵌入式系统设计方法是十分重要的，这是因为：

1. 良好的设计方法可以使设计者清楚的了解他们所做工作的进度，这样可以确保不遗漏其中任何一项工作。
2. 允许使用计算机辅助工具帮助设计者进行工作，将整个过程分成几个可控的步骤进行。
3. 良好的设计方法方便设计团队的成员之间相互交流，通过定义全面的设计过程，使团队里的每个成员可以很好的理解他们所要做的工作及完成分配给他们的任务时所达到的目标。

嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固话、测试及运行等几个阶段。

12.7.3 嵌入式系统设计的核心技术

1. 处理器技术

1. 通用处理器。这类处理器可以用于不同类型的应用，一个重要的特征就是存储程序，由于设计者不知道处理器会运行何种运算，所以无法用数字电路建立程序。另一个特征就是通用的数据路径，为了处理各类不同的运算，数据路径是通用的，其数据路径一般有大量的寄存器及一个或多个通用的算术逻辑单元。
2. 单用途处理器。是设计用于执行特定程序的数字电路，也指协处理器、加速器、外设等。嵌入式系统设计者可通过设计特定的数字电路来建立单用途的处理器。设计者也可以采用预先设计好的商业化的单用途处理器。
3. 专用处理器。专用指令集处理器是一个可编程处理器，针对某一特定类型的应用进行最优化。这类应用具有相同的特征，如嵌入式控制、数字信号处理等。

2. IC技术

从系统的集成电路设计描述得到实际芯片的物理映射过程的实现技术就是IC（集成电路）技术，当前在半导体领域的三类实现技术，即全定制、半定制和可编程技术均可应用于嵌入式系统的硬件设计。

1. 全定制/VLSI（超大规模集成电路）。在全定制IC技术中，需要根据特定的嵌入式系统的数字实现来优化各层设计人员从晶体管的版图尺寸、位置、连线开始设计以达到芯片面积利用率高、速度快、功耗低的最优化性能。利用掩膜在制造厂生产实际新品，全定制的IC设计也成为VLSI，具有很高的NRE成本、很长的制造时间，适用于大量或对性能要求严格的应用。
2. 半定制/ASIC（专用集成电路）。是一种约束型设计方法，包括门阵列设计法和标准单元设计法，他是在芯片制作好一些具有通用性的单元元件和元件组的半成品硬件，设计者仅需要考虑电路的逻辑功能和各功能模块之间的合理连接即可。这种设计方法灵活方便、性价比高，缩短了设计周期，提高了成品率。
3. 可编程/ASIC。可编程器件中所有各层都已经存在，设计完成后，在实验室里即可烧制出设计的芯片，不需要要IC厂家参与，开发周期显著缩短。可编程ASIC具有较低的NRE成本，单位成本较高，功耗较大，速度较慢。

3. 设计/验证技术

设计技术主要包括硬件设计技术和软件设计技术两大类。其中，硬件设计领域的技术主要包括芯片级设计技术和电路板级设计技术两个方面。

芯片级设计技术的核心是编译/综合、库/IP（知识产权）、测试/验证。编译/综合技术是设计者用抽象的方式描述所需的功能，并自动分析和插入实现细节。库/IP将预先设计好的低抽象级实现用于高级抽象。测试/验证技术确保每级功能正确，减少各级之间反复设计的成本。

12.7.4 嵌入式开发设计环境

1. 与嵌入式操作系统配套的开发环境。
2. 与处理器芯片配套的开发环境。这类开发环境一般由处理器厂商提供。
3. 与具体应用平台配套的开发环境。
4. 其他类的开发环境

12.7.5 嵌入式软件设计模型

嵌入式系统常用的计算模型有如下几种：时序计算模型、通信进程模型、状态机模型、数据流模型、面向对象模型、并发进程模型

1. 状态机模型

有限状态机FSM是一个基本的状态模型，可以用一组可能的状态描述系统的行为，系统在任何时刻只能处于其中一个状态，也可以描述由输入确定的状态转移，最后可以描述在某个状态下或状态转移期间可能发生的操作。

当FSM被用于嵌入式系统设计时，其输入和输出的类型都是布尔类型，而函数表示含有布尔运算的布尔函数，这种模型对于没有数据输入或输出的很多纯控制系统而言已经足够。如果要处理数据，则将FSM扩展为带有数据路径的状态机FSMD。另外，对状态机模型可以进一步扩展以支持分级和并发，这种模型称为分级/并发FSM模型

2. 数据流模型

是并发多任务模型派生出的一种模型，该模型将系统的行为描述为一组结点和边，其中结点表示变换，边表示从一个结点到另一个结点的数据流向。每个结点使用来自其输入边的数据，执行变换并在其输出边上产生数据。

每个边可能有货没有数据，出现在边上的数据称为令牌。当每个结点的所有输入边都至少有一个令牌时，该结点可触发。结点触发后，将使用来自每条输入边上的一个李竞拍，对所有使用的令牌进行数据变换，并在输出边上产生一个令牌，结点的触发仅决定于令牌出现的情况。

同步数据流模型中，在结点的每条输入边和输出边上分别标注每次触发所使用和产生的令牌数。该模型的优点是，在实现时不需要将其转换为并发多任务模型，而是用静态方式调度结点，产生时序程序模型。该模型可以使用时序程序语言来表达，不需要实时操作系统就可以执行，因此其执行效率更高。

3. 并发进程模型

是由一组进程构成，每个进程是一个顺序执行的过程，各进程间可以并发执行。并发进程模型提供创建、终止、暂停、恢复和连接进程的操作。进程在执行中可以相互通信，交换数据。进程间通信可以采用两种方式：共享变量和消息传递。信号量、临界区、管程和路径表达式等用来对并发进程的操作进行同步。

4. 面向对象模型

是以一种更加直接的方式刻画客观世界中的活动，模型中存在着潜在的并发执行能力。一个对象向另一个对象发送消息后，若不需要或不立即需要消息的执行结果，前者不必等待后者处理消息，消息发送者和消息接受者可以并发执行。对象不都是处于被动的提供服务状态，他们中的一些除了能通过接收消息向外提供服务外，还可以有自己的事务处理。一个对象往往可以同时处理多个消息。

对象是数据和操作的封装体，数据存放在对象的局部变量中，对象的状态由对象所有的局部变量在某一时刻的取值来表示。在并发环境中，还要考虑对象并发状态的描述问题，因为对象的并发控制是根据对象的并发状态来进行的。

把并发和面向对象相结合，归结起来可分为两条途径：

1. 在面向对象模型中引入并发机制，充分利用面向对象刻画客观世界的良好模型能力和面向对象的各个重要特性，同时把其潜在的并发能力描述出来，使其适合于描述并发计算。
2. 在传统并发模型中引进面向对象思想。

面向对象的并发模型可以分为两种类型：

1. 隐式并发模型。特点是推迟并发设计，将对象建模作为建模基础。在进入运行阶段之前，将对象看成自主单元，各种对象的活动看成立项并发方式完成的特定工作。就像每个对象拥有一个自己的处理器，这个处理器可以为对象提供一个执行线程。进入系统的外部事件可以看成是一个处理请求，以广播方式传给一些对象，这些对象接着向其他对象进一步提出处理请求。理论上，对应一个请求，可以由任意多个对象执行响应的处理。在实现时，由调度程序最终决定其对象的操作顺序。
2. 显示并发模型。特点是首先考虑并发，应先把并发概念和对象概念分开。在建立对象以后，用实时操作系统支持的进程概念来表示并发，形成对象和进程两个抽象层次，即先将系统分解为准兵法进行作为开始，而在每个进程的内部采用个面向对象的技术。对象间交互表示成嵌套的函数调用，通过加入锁、监视器、信号量等显示同步机制，来保证对象的完整。该模型将进程置于对象之上，对象中不必考虑并发、对象串行化。

12.7.6 需求分析

需求分析阶段最重要的文档输出就是系统的规格说明。

规格说明是精确反映客户需求并且作为设计时必须遵循的要求的一种技术文档。规格说明应该是清晰的、无歧义的，否则由该规格说明建造系统可能不符合实际要求。流行的方法是采用UML进行规格说明的描述。

在需求分析阶段，通过用例来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统（用例）的功能要求，分析阶段主要关心问题域中的主要概念和机制，需要识别这些类及它们相互间的关系，并用UML类图来描述。在分析阶段，只对问题域的对象建模，而不考虑定义软件系统中技术细节的类。

12.7.7 系统设计

1. 协同合成工具。
   
   • POLIS。交互式嵌入系统的软、硬件协同设计框架，适用于小型控制系统的设计，系统描述支持基于FSM的语言。不支持共享内存。
   • COSYMA。一种探索硬件和软件协同设计合成进程的平台，面向软件系统的描述较简单，支持自动分割和协同处理器合成，在合成时期可以对设计空间进行探索，系统合成取决于硬件限制，不支持并发模块。
   • Chinook。为控制系统而设计的，整个系统的描述作为一个输入提供给Chinook，它的内部模式基于类似等级状态的模式，不对代码进行分割，为整个设计提供单一的模拟环境。
2. 协同模拟工具。不仅提供检验，而且为用户提供各系统的性能信息，这有助于在系统的早期提出变更方案，不至于造成重大损失。目前，主要的协同模拟工具有如下两种：
   
   • PTOLEMY。关键思想是混合使用面向对象内核的计算模型，可用于模拟多种的系统，在各种应用中被过饭使用，但不适合于系统合成，硬件模拟也是它的一项功能。
   • TSS。是模拟复杂硬件的工具，采用C语言编写，单个模块的提取可由用户控制，可以方便的进行添加和删除模块。但不支持分级模块，没有用于同步各处理器存取共享数据结构的机制，模块间的通信通过端口和总线进行，并且，支持多核系统的模拟。

1. 系统架构设计

先考虑系统的软件架构，然后再考虑其硬件实现。

1. 原始框架。
2. 软件系统架构
3. 硬件系统架构

2. 硬件子系统设计

嵌入式系统的开发环境由四部分组成：目标硬件平台、嵌入式操作系统、编程语言和开发工具。

1. 选择处理器技术。
2. 通用嵌入式处理器的选择。根据用户的需求和项目的需要选择合适的通用的嵌入式处理器，选择时需要考虑如下指标：
   
   • 处理器的速度。一个处理器的性能取决于多个方面的因素：时钟频率、内部寄存器的大小，指令是否对等处理所有的寄存器等。
   • 技术指标
   • 开发人员对处理器的熟悉程度
   • 处理器的I/O性能是否满足系统的需求
   • 处理器的相关软件支持工具
   • 处理器的调试，即处理器是否集成了调试功能
   • 处理器制造商的支持可信度。
3. 硬件设计的注意事项。首先，将硬件划分为部件或模块，并绘制部件或模块连接框图。其次，对每个模块进行细化，把系统分成更多可管理的小块，可以被单独实现。设计时需要注意以下几点：
   
   • I/O端口：列出硬件的所有端口、端口地址、端口属性、使用的命令和序列的意义、端口的状态及意义。
   • 硬件寄存器：对每个寄存器设计寄存器的地址、寄存器的位地址和每个位表示的意义，以及对寄存器读写的说明、使用该寄存器的要求和时序说明。
   • 内存映射：共享内存和内存映射I/O的地址，对每个内存映射，说明每个I/O操作的读/写序列、地址分配。
   • 硬件中断
   • 存储器空间分配

3. 软件子系统设计

根据需求分析阶段的规格说明文档，确定系统计算模型，对软件部分进行合理的设计即可。

1. 操作系统的选择。在选择嵌入式操作系统时，需要做多方面的考虑K
   
   • 操作系统的功能
   • 配套开发工具的选择
   • 操作系统的移植难易程度
   • 操作系统的内存需求如何
   • 操作系统附加软件包
   • 操作系统的实时性如何
   • 操作系统的灵活性如何
2. 编程语言的选择。在选择编程语言时，也需要做多方面的考虑：
   
   • 通用性
   • 可移植性
   • 执行效率
   • 可维护性
   • 基本型恩能够
3. 软件开发过程。主要有如下步骤：
   
   • 选择开发语言，建立交叉开发环境
   • 根据详细设计说明编写源代码，进行交叉编译、链接
   • 目标代码的重定位和下载
   • 在宿主机或目标机调试、验证软件功能
   • 进行代码的优化
4. 软件开发文档。在嵌入式产品的开发设计过程中，开发阶段完成系统产品的实现，这一阶段同时需要完成一系列的文档，这些文档对完成产品设计、维护相当重要，这些文档分别为技术文件目录、技术任务书、技术方案报告、产品规格、技术条件、设计说明书、实验报告、总结报告等。

12.7.8 系统集成与测试

通常嵌入式系统测试主要包括软件测试、硬件测试、单元测试三个部分。差别如下：

1. 嵌入式软件必须长时间稳定运行
2. 嵌入式徐如那件一般不会频繁的版本升级
3. 嵌入式软件通常使用在关键性的应用中
4. 嵌入式软件必须和嵌入式硬件一起对产品的故障和可靠性负责
5. 现实世界的条件是异步和不可预测的，使得模拟测试非常困难。

嵌入式测试主要集中在以下4个不同的方面：

1. 因为实时性和同时性很难满足，所以大多数测试集中于实施测试。
2. 大多数实时系统都有资源约束，因此需要更多的性能和可用性测试。
3. 可以使用专用实时跟踪工具对代码覆盖率进行测试。
4. 对可靠性的测试级别比通用软件要高得多。

第十三章 开发管理

项目管理是指在项目环境中运用专门的知识、技能、工具和方法，使项目能够实现或超过项目干系人的需要和期望。一般的项目管理分为范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理9个知识领域。对于软件的开发管理来讲，软件范围管理、软件进度管理、软件成本管理、软件配置管理、软件质量管理、软件风险管理、开发人员管理7个方面的管理尤为重要。

13.1 项目的范围、时间的成本

项目管理首先要考虑三个约束条件：项目范围、时间进度、成本预算。

13.1.1 项目范围管理

包括保证项目顺利完成所需的全部工作过程。其目的是控制项目的全部活动都在需求范围内，以确保项目资源的高效利用。主要包括项目启动、范围计划编制、范围定义、范围核实和范围变更控制5个部分的内容。项目启动是指批准项目启动或允许项目进入下一个过程；范围计划编制是将生产项目产品所需进行的项目工作渐进明细和形成文件的过程；范围定义是把主要的项目可交付成果分解成更小、更易管理的单元，以达到如下目的：

• 提高对成本、时间及资源估算的准确性
• 为绩效测量和控制定义一个基准计划
• 便于进行明确的职责分配

当范围定义不明确时，不可避免的变更会使最终项目成本大大超出预算，因为这些不可避免的变更会破坏项目节奏，导致返工，增加项目历时、降低生产率和工作人员的士气。范围核实是项目关系人正式接收项目范围的过程。范围核实需要审查可交付成果和工作结果，以确保它们都已经正确圆满的完成。如果项目被提前终止，项目核实过程应当对项目完成程度建立文档。范围核实与质量控制是不同的，范围核实是有关工作结果的“接收”，而质量控制是有关工作结果的正确性。项目范围变更涉及的是：

• 对造成范围变更的因素施加影响，以确保这些变更得到一致认可。
• 确定范围变更是否已经发生
• 当范围变更发生时对实际变更进行管理。

13.1.2 项目成本管理

是保证在批准预算内完成项目所需要的过程。包括资源计划编制、成本估算、成本预算、成本控制3个主要部分内容。资源计划编制是确定为完成项目个活动需要什么资源和这些资源的数量。资源计划与成本估算是紧密相关的。成本估算是计算出完成一个项目的个活动所需个资源成本的近似值。当一个项目按合同进行时，应却分成本估算和定价这两个不同意义的词。成本估算所涉及的是对可能数量结果的估算——执行组织为提供产品和服务的花费是多少；而定价是一个商业决策——执行组织为提供的含片或服务索取多少费用。成本估算包括确认和考虑各种不同的成本估算替代方案。

成本预算是把估算的总成本分配到单个活动或工作包上去，建立基准计划来度量项目实际绩效。成本控制的内容有：对造成成本基准计划变化的因素施加影响，以保证这种变化得到一致认可；确定成本基准计划是否已经发生变化；当变化发生和正在发生时，对这种变化执行管理。

成本控制包括以下方面：

• 监测成本执行情况，以寻找出并掌握计划的偏差及原因
• 确保所有变更都准确的记录在成本基准计划中
• 防止把不正确、不适宜或未批准的变更纳入成本基准标准
• 将批准的变更通知项目干系人
• 采取措施，把预计的成本控制在可接受的范围内。

13.1.3 项目时间管理

时间管理包括项目按时完成所需的各个过程。包括活动定义、活动排序、活动历时估算、进度计划编制、进度控制5个部分内容。

活动定义是对WBS中规定的可交付成果或半成品的产生所必须进行的具体活动进行定义，并形成文档。

活动排序是确定各活动之间的依赖关系，并形成文档。

项目活动历时估算是根据项目范围和资源的相关信息为进度表设定历时输入的过程。

制定进度计划要决定项目活动的开始和结束日期。若开始和结束日期是不现实的，项目就不可能按计划完成。

进度控制涉及的是：

• 对造成进度变更的因素施加影响，以确保这些变更得到一致认可。
• 确定进度变更是否已经发生
• 当变更发生时对实际变更进行管理。

13.2 配置管理与文档管理

13.2.1 软件配置管理的概念

SCM是指在软件系统中确定和定义构件（源代码、可执行程序、文档等），在整个生命周期中控制发布和变更，记录和报告构件的状态和变更请求，并定义完整的、正确的系统构件的过程。软件配置管理包括以下几个方面功能:

• 配置标识：产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。
• 版本控制：通过建立产品极限，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。
• 状态统计：记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。
• 审计和审查：确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合。
• 生产：对产品的生产进行优化管理。它将解决最新发布的产品应由那些版本的文件和工具来生成的问题。
• 过程管理：确保软件组织的规程、方针和软件周期得意正确贯彻执行，它将解决要交付给用户的产品是否经过测试和质量检查的问题。
• 小组协作：控制开发同一产品的多个开发人员的协作。

在另一标准ISO中，对软件配置管理系统做了如下要求：

• 唯一标识每个软件项的版本
• 标识共同构成一个完整产品的特定版本的每一软件项的版本；
• 控制由两个或多个独立工作的人员同时对一个给定软件项的更新
• 按要求在一个或多个位置对复杂产品的更新进行协调
• 标识并跟踪所有的措施和更改；这些措施和更改是从开始直到放行期间，由于更改请求或问题引起的。

两个版本都强调了三个核心部分：版本管理、问题跟踪和建立管理，其中版本管理是基础，应完成如下主要任务

• 建立项目
• 重构任何修订版的某一项或某一文件
• 利用加锁技术防止覆盖
• 当增加一个修订版时要求输入变更描述
• 提供比较任意两个修订版的使用工具
• 采用增量存储方式
• 提供对修订版历史和锁定状态的报告功能
• 提供归并功能
• 允许在任何时候重构任何版本
• 权限的设置
• 晋升模型的建立
• 提供各种报告

13.2.2 软件配置管理的解决方案

1. Rational ClearCase

可以用于Windows和Unix开发环境。主要应用于复杂的产品发放、分布式团队合作、并行的开发和维护任务，支持Client Server的网络结构，主要功能有：

1. 版本控制
2. 工作控件管理
3. 建立管理
4. 过程控制

2. Merant PVCS

1. PVCSVersionManager：能完整、详细的记录开发过程中出现的变更和修改，可快速得到系统中任何文件的各个版本，并使修订版本自动升级。
2. PVCSConfigurationBuilder：提供可靠的自动重构过程
3. PVCSTracker：为整个开发过程中确定个追踪软件的每一变更的要求
4. PVCSNotify：将软件状态的变更通过EMail通知组织机构中的其他成员
5. PVCSReporter：为GUI界面环境提供一个客户报表工具，容易的生成和存储多个项目的报表
6. PVCSProductionGateway：提供了局域网间与大型机MVC系统双向同步互联
7. PVCSDeveloper’sToolkit：提供应用程序开发接口API
8. PVCSRequisitePro：提供了一个独特的界面和需求数据库。=，从而可直接跟踪最终用户的项目需求及需求变更。

3. Mirosoft VSS，CVS

提供了基本的认证安全和版本控制机制，包括入库、出库、分支、标定等功能。是一种源代码控制系统，带有专业的文档、代码管理库。

13.2.3 软件文档管理

1. 软件文档的作用

1. 管理依据。
2. 任务之间联系的凭证
3. 质量保证
4. 培训和参考
5. 软件维护支持
6. 历史档案
7. 销售可能

2. 文档的归类

1. 开发文档。描述软件开发过程，包括软件需求、软件设计、软件测试、保证软件质量的一类文档。也包括软件的详细技术描述（程序逻辑、程序间相互关系、数据格式和存储等）。开发文档起到如下5种作用：
   
   • 它们是软件开发过程中包含的所有阶段之间的通信工具，它们记录生成软件需求、设计、编码和测试的详细规定和说明；
   • 它们描述开发小组的职责。通过规定软件、主题事项、文档编制、质量保证人员、一级包含在开发过程中任何其他事项的角色来定义做什么、如何做和何时做；
   • 它们用作检查点而允许管理者评定开发进度。如果开发文档丢失、不完整或过时，管理者将失去跟踪和控制软件项目的一个重要工具；
   • 它们形成了维护人员所要求的基本的软件支持文档。而这些支持文档可以作为产品文档的一部分。
   • 它们记录软件开发的历史。
     基本的开发文档包括：可行性研究和项目任务书；需求规格说明；概要设计说明；详细设计说明，包括程序和数据规格说明；项目开发计划；软件集成和测试计划；质量保证计划、标准、进度；安全和测试信息
2. 产品文档。规定关于软件产品的使用、维护、增强、转换和传输的信息。产品的文档起到如下三个作用：
   
   • 为使用和运行软件产品的任何人规定培训和参考信息
   • 使得那些未参加开发本软件的程序员维护它
   • 促进软件产品的市场流通或提高可接受性
     产品文档主要应用于下列类型的读者：
   • 用户
   • 运行着
   • 维护者
     产品文档包括如下内容：用于管理者的指南和资料，他们监督软件的使用；宣传资料通过软件的可用性并详细说明它的功能、运行环境等；一般信息对任何对其感兴趣的人描述软件产品。基本的产品文档实物包括：培训手册；参考手册和用户指南；软件支持手册；产品手册和信息广告；维护修改建议等。
3. 管理文档。建立在项目管理信息的基础上，从管理的角度规定软件生存的信息。包括：项目开发计划、测试计划；开发过程的每个阶段的进度和进度变更的记录；软件变更情况的记录；相对于开发的判定记录；开发人员职责定义；测试报告、开发进度月报；项目开发总结等。
   另外，软件文档从用途上还可以分为内部文档和外部文档。其中，内部文档包括项目开发计划、需求分析、架构设计说明，详细设计说明、构件索引、构件成分说明、构件接口及调用说明、构件索引、构件接口及调用说明、类索引、类属性及方法说明、测试报告、测试统计报告、质量监督报告、源代码、文档分类版本索引和软件安装打包文件等。
   外部文档主要包括软件安装手册、软件操作手册、在线帮助、系统性能指标报告和系统操作索引等。

3. 文档编制计划

文档计划一般包括以下几个方面内容：

• 列出应编制文档的目录
• 提示编制文档应参考的标准
• 指定文档管理员
• 提供编制文档所需要的条件，落实文档编写人员、所需经费及编制工具等。
• 明确保证文档质量的方法，为了确保文档内容的正确性、合理性，应采取一定的措施，如评审、鉴定等。
• 绘制进度表，以图表形式列出在软件生存期个阶段应产生的文档、编制人员、编制日期、完成日期、评审日期等。

4. 对文件质量的要求

1. 针对性。文档编制前应分清读者对象。对不同类型、不同层次的读者，决定如何满足适应他们的需要。
2. 精确性。文档的行文应当十分确切，不能出现多义性的描述。同一课题几个文档的内容应当是协调一致、没有矛盾的。
3. 清晰性。文档编写应力求简明，如有可能，配以适当的图标，以增强其清晰性。
4. 完整性。任何一个文档都应当是完整的、独立的，它应自成体系。不要在文档中出现转引其他文档内容的情况。
5. 灵活性。各个不同软件项目，其规模和复杂度有着许多实际差别，不能相同看待，应根据具体的软件开发项目，决定编制的文档种类。

13.3 软件需求管理

13.3.1 需求变更

是指在软件开发过程中，用户确定软件需求之后，由于各种客观和主观条件的变化，用户增加了新的需求或改变了原有需求。

通常软件开发机构会采取如下措施：

1. 项目启动阶段的变更预防。
2. 项目实施阶段的需求变更。控制需求变更需要注意以下几点：
   
   • 需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就称为必然了。
   • 需求的变更要经过出资者的认可，使需求的变更有成本的概念。
   • 小的需求变更也要经过正规的需求管理流程。
   • 还要注意沟通的技巧。

13.3.2 需求跟踪

是指在软件需求管理的过程中定义需求变更流程，分析需求变更影响，控制变化的版本，维护需求变更记录，跟踪每项需求状态。

1. 确定需求变更控制过程，制定一个选择，分析和决策需求变更的标准过程，所有的需求变更都需要遵循此过程。
2. 进行需求变更影响分析，评估每项需求变更，以确定它对项目计划安排和其他需求的影响，明确与变更相关的任务，并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门作出更好的决策。
3. 建立需求基准版本和需求控制版本文档，确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。
4. 维护需求变更的历史记录
5. 跟踪没想需求的状态。

13.4 软件开发的质量和风险

关于软件质量，IEEE729-1983有如下定义：

• 软件产品满足给定需求的特性及特征的总体的能力。
• 软件拥有所期望的各种属性组合的程度
• 顾客或用户认为软件满足他们综合期望的程度
• 软件组合特性在使用中，满足用户预期需求的程度。

软件质量管理的目的是建立对项目的软件产品质量的定量理解和实现特定的质量目标。

13.4.1 软件质量管理

项目质量管理包括保证项目能满足原先规定的各项要求所需要的过程，即“总体管理功能中决定质量方针、目标与责任的所有活动，并通过诸如质量规划、质量保证、质量控制、质量改进等手段在质量体系内加以实施”。软件质量管理着重于确定软件产品的质量目标，制定达到这些目标的计划，并监控及调整软件计划、软件工作产品、活动及质量目标以满足顾客及最终用户对高质量产品的需要及期望。软件质量管理包括下面三个部分：

1. 软件质量计划

在正式进行软件开发前，需要制定一个软件质量计划，用于说明项目管理团队奖如何实施其质量方针。在该阶段应该完成以下活动：

• 对项目的软件质量活动作出规划
• 对软件产品质量的可测量的目标及其优先级进行定义
• 确定软件产品质量目标的实现过程是可量化和可管理的
• 为管理软件产品的质量提供适当的资源和资金
• 对实施和支持软件质量管理的人员进行实施和支持过程中所要求的培训。
• 对软件开发项目组和其他与软件项目有关的人员进行软件质量管理方面的培训
• 按照已文档化的规程制定和维护项目的软件质量计划
• 项目的软件质量管理活动要以项目的软件质量计划为基础
• 在整个软件生命周期，要确定、监控和更新软件产品的质量目标。

2. 软件质量保证

指为项目符合相关质量标准要求树立信心而在质量系统内部实施的各项有计划的系统活动。

3. 软件质量控制

指监视项目的具体结果，确定其是否符合相关的质量标准，并判断如何杜绝造成不合格结果的根源。应贯穿于项目的始终。质量管理包括如下活动；

• 对软件产品进行测试，并将测试结果用于软件质量管理活动的状态。
• 高级管理者定期参与评审软件质量管理的活动
• 软件项目负责人定期参与评审软件质量管理的活动
• 软件质量保证评审小组负责评审软件的质量管理活动个工作产品，并填写相关报告。

1. 软件评审。

不是在软件开发完毕后进行评审，而是在软件开发的各个阶段都要进行评审。首先，要明确评审目标包括如下部分：

• 发现任何形式表现的软件错误、逻辑或实现方面的错误；
• 通过评审验证软件的需求
• 保证软件按预先定义的标准表示
• 已获得的软件是统一的形式开发的
• 使项目更容易管理

其次，评审过程应包括：

• 召开评审会议
• 会议结束时必须做出以下决策之一：1接受该产品，不需做修改；2由于错误严重，拒绝接受；3暂时接受该产品
• 评审报告与记录：所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外必须完成评审简要报告。

还应该遵循基本的评审准则，如：

• 对每个正式技术评审分配资源和时间进度表
• 评审产品，而不是评审设计者，不能使设计者有任何压力；
• 会议不能脱离主题，应建立议事日程并维持它
• 评审会不是为了解决问题，而是为了发现问题，限制争论与反驳
• 对每个被评审的产品建立评审清单，以帮助评审人员思考。

2. 测试。

测试过程中将产生下述基本文档

• 测试计划：确定测试范围、方法和需要的资源等
• 测试过程：详细描述与每个测试方案有关的测试步骤和数据（包括测试数据及预期的结果）
• 测试结果：把每次测试运行的结果归入文档，如果运行出错，则应产生问题报告，而且必须经过调试解决所发现的问题。

13.4.2 项目风险管理

项目风险的管理不仅贯穿于整个项目过程，而且在项目事件发生之前风险的分析就已经开始。可以根据风险控制与项目实现发生的时间将风险控制划分为三个部分：事前控制——风险管理规划，事中控制——风险管理方法，事后控制——风险管理报告。

1. 项目风险管理的概念

是指对象项目风险进行识别、分析、并蔡旭应对测试的系统过程。包括尽量扩大有利于项目目标事项发生的概率与后果，而尽量减少不利于项目目标事项发生的概率与后果

项目风险按是否有可确定性划分为：已知风险、可预知风险、不可预知风险。按风险管理的内容又可以划分为如下几种类型：

1. 内部技术风险。采用新技术或技术创新
2. 内部非技术风险。公司经营战略发生的变化，其他项目相关的内容发生变化。
3. 外部法律风险
4. 外部非法律风险

2. 风险管理的过程

风险管理包括对项目风险识别、分析和应对的过程，从而将正面事件影响扩大到最大化和将负面影响减少到最小化。项目风险管理的主要过程包括：

• 风险管理规划，决定如何指导和规划项目的风险管理活动
• 项目风险识别，找打哪些风险可能影响项目，并记录其特征
• 定性风险识别，完成风险和环境的定性分析，并按其对项目目标的影响进行排序。定性风险分析是决定具体风险的重要性并指导作出相关反应的一种方法。与风险相关的动作的时间相关性可能使风险的重要性加大。
• 定量风险分析，度量风险的可能性和后果，估量其对项目目标的潜在影响
• 风险应对计划，创建过程和技术来为项目目标增进机会和减小威胁
• 风险监督与控制，在项目周期中监视现存的风险，识别新的风险、执行环节风险计划及评估其效果。

上述过程不仅彼此有交互作用，而且也同其他知识领域的过程有交互作用。一般来说，每个过程在项目中至少出现一次。

1. 风险识别

就是识别整个项目过程中可能存在的风险事件。一般是根据项目的性质，从潜在的事件及产生的后果和潜在的后果和产生的原因来检查风险。收集、整理项目可能的风险并充分征求各方意见就形成项目的风险列表，并对这些风险事件进行描述。

2. 风险分析

确定了项目的风险列表之后，就可以进行风险分析。风险分析的目的是确定每个风险对项目的影响大小，一般是对已经识别出来的项目风险进行量化估计，这里要注意三个概念：

• 风险得失值：是指一旦风险发生可能对项目造成的影响大小，说明可能造成的损失。如果损失的大小不容易直接估计，可以将损失分解为更小部分再评估它们。风险得失值可以用相对数值表示。
• 风险概率。风险发生可能性的百分比表示，是一种主观判断
• 风险值：又称风险曝光度或风险暴露度，是评估风险的重要参数。“风险值”=“风险概率”*“风险影响”。

风险分析就是对以上识别出来的风险事件做风险影响分析。

3. 风险应对方法

制定风险应对策略主要考虑一下4个方面的因素：可规避性、可转移性、可缓解性、可接受性。4种应对方法如下：

• 规避。规避风险是指改变项目计划，以排除风险或条件，或者包含项目目标，使其不受影响。
• 转移。是指设法将风险的后果连同应对的责任转移到第三方身上。
• 减轻。通过降低风险事件发生概率或得失率来减轻对项目的影响。
• 接受。接受风险造成的结果。

确定风险的应对策略后，就可变写风险应对计划，主要包括：已识别的风险及其描述、风险发生的概率、风险应对的责任人、风险对应策略及行动计划、应急计划等。

4. 风险应对计划

针对需要采取应对措施的风险事件，开发应对计划，一旦发生风险事件，就实施应对计划。应对计划常应用于项目运行期间发生的已识别风险，事先制定应变计划可大大降低风险发生时采取行动的成本。

5. 风险监控

风险监控包括两个层面的工作：其一是跟踪已识别风险的发展变化情况，包括在整个项目周期内，风险产生的条件和导致的后果变化，衡量风险减缓计划需求。其二是根据风险的变化情况及时调整风险应对计划，并对已发生的风险及其产生的遗留风险和新增风险及时识别、分析，并蔡旭适当的应对措施。

13.5 人力资源管理

1. 组织规划

用于确定、记录并分派项目角色、职责和请示汇报关系。角色、职责和请示汇报关系可以分派给个人或集体

1. 垂直团队组织。由多面手组成。优点在于，以单个功能模块为基础实现平滑的端到端开发；开发人员能够掌握更广泛的技能。缺点：
   
   • 多面手通常是一些要加很高并且很难找到的顾问
   • 多面手通常不具备快速解决具体问题所需的特定技术专长
   • 主体专家可能不得不和若干开发人员小组一起工作，从而增加了他们的负担。
   • 所有多面手水平各不相同
2. 水平团队组织。由专家组成。此类团队同事处理多个功能模块，每个成员都从事功能模块中有关自身的方面。优点在于能够高质量的完成项目各个方面的工作。缺点在于：专家们通常无法意识到其他专业的重要性，导致项目的各个方面之间缺乏联系；由于专家们的优先权、看法和需求互不相同，所以项目管理比较困难。
3. 混合团队组织。由专家和多面手共同组成。多面手继续操作一个功能模块的整个开发过程，支持并处理多个功能模块，使各部分的专家们一起工作。可能拥有前两种方案的优点：外部小组只需要与一小部分专家进行交互；专家们可集中精力从事他们所擅长的工作；各个功能模块的实现都保持一致。但是也可能拥有前面两种方案的缺点：尽管这应该由多面手来调节，专家们仍然不能认识到其他专家的工作并且无法很好的协作；多面手很难找到，故而，项目管理仍然较难。

2. 人员招募

是指获取分派到项目上、并在那里工作所需的人力资源（个人或集体）。要考虑的问题有：

• 以往经验
• 个人兴趣
• 能否得到
• 胜任与熟练程度

项目经理是团队组织的核心，其综合素质直接影响项目的成败。一般要求项目经理具备如下能力：

1. 领导能力

项目经理必须具备高超的领导才能拿和强烈的科技意识和较强的业务处理能力。

首先，项目经理应懂得如何授权和分配职责，采取参与和顾问式的领导方式，发挥导向和教练作用，让成员在职责范围内充分发挥能动性，自主的完成项目工作。

其次，项目经理应善于激励。进行非物质激励。另外，对项目成员的工作成绩要及时表示认可。

第三，项目经理应该为成员梳理榜样，表现出积极的心态，称为团队的典范和信心的源泉。

第四，项目经理应该能够果断抉择，负责人的主要任务是决策。

2. 沟通技巧

有效的沟通是项目顺利进行的保证，沟通及时、集思广益、步调一致，才能取得项目最终的成功。在沟通过程中，项目经理应善于提问，并做到有效的聆听，能经常站在对方的角度思考问题。

3. 人际交往能力

良好的人际关系有助于项目的协调，避免生硬的操作方式。

4. 应付压力的能力

项目的特点决定了项目工作过程存在一定的不可预见性，项目经理需要做好随时面对压力甚至是冲突的准备。一旦面临压力或冲突，最重要的是保持冷静，避免项目陷入困境。项目经理要以乐于解决问题的姿态出现在团队及上级或客户面前。

5. 培养员工的能力

出色的项目经理重视对项目成员的培养，通过项目过程使小组每个成员都能发挥才能并提升员工的能努力，促进员工的自我发展。项目经理要帮助成员明晰自己的只也和技能发展方向，分配合适的工作任务，鼓励学习和相互交流，让项目小组成员具有很强的成就感。

6. 时间管理技能

当需要在同一时段处理两项以上的任务是，时间管理就是必要的。而项目经理往往需要同时面对数项甚至是十几项任务，可见有效的时间管理是极为重要的。项目经理不仅需要管理好自己的时间，还需要与相关部门及人员订立时间使用协议，尽量较少非预期的时间占用。

合格的项目经理具有敏锐的洞察力，能瞄准目标，实事求是，精心组织，坚决果断，灵活应变，享有信誉；善于制定计划，解决问题，沟通信息；具有良好的市场意识和交际能力。

他应该具有实现这些条件的素质，并注重经验的积累、素质的提高和能力的培养。

3. 团队建设

项目团队的建设既包括提高仙姑干系人作为个人做出贡献的能力，也包括提高项目团队作为集体发挥作用的能力。个人的培养（管理能力及技术水平）是团队建设的基础，而团队建设则是项目实现其目标的关键。

团队中的每个人必须积极融入整个集体中，不能互相推诿，更不能互相埋怨和职责，正确的态度是大家在充分信任的基础上团队协作、互相帮助、主动承担任务，利用集体的智慧获得成功。

在软件项目中，应该为软件开发人员和管理人员等各类项目人员营造一个和谐、梁皓的工作氛围，为开发人员创造出一个人尽其才的环境也是项目成功的重要缓解，让他们能得心应手的施展自己的才华，特别在工作安排上要煞费苦心，针对每个人不同的特长，根据项目的具体环境和条件把人员合理的安排在恰当的岗位上。使他们能感到项目成功的把握并有积极的工作心态，将项目作为自己事业的一部分，确保项目队伍的稳定性和连续性。

软件项目团队的成长规律，分为以下4个阶段：

1. 形成阶段

促使个体成员转变为团队成员。

为使项目团队明确方向，项目经理一定要向团队成员说明项目目标，并设想出项目成功的美好前景及成功所产生的益处；公布项目的工作范围、质量标准、预算及进度计划的标准和限制。项目经理在这一阶段还要进行组织构件工作，包括确立团队工作的初始操作规程，规范沟通渠道、审批及文件记录工作。所以在这一阶段，对于项目成员采取的激励方式主要为预期激励、信息激励和参与激励。

2. 震荡阶段

这一阶段，成员们开始着手进行分配到的任务，缓慢的推进工作。

震荡阶段的特点是人们有挫折、愤怒或者队里的情绪。这一阶段士气很低，成员可能会抵制形成团队，因为他们要表达与团队联合相对立的个性。

因此在这一阶段，项目经理要做导向工作，致力于解决矛盾，绝不能希望通过压制来使其自行消失。这时，对于项目成员采取的激励方式主要是参与激励、责任激励和信息激励。

3. 正规阶段

经受了震荡阶段的考验，项目团队就进入了发展的正规阶段。项目团队逐渐接受了现有的工作环境，团队的凝聚力开始形成。

在正规阶段，项目经理采取的激励方式除参与激励外，还有两个重要方式：一是发掘每个成员的自我成就感和责任意识，引导员工进行自我激励；二是尽可能多的创造团队成员之间互相沟通、相互学习的环境，以及从项目外部聘请专家讲解与项目有关的新知识、新技术，给员工充分的知识激励。

3. 表现阶段

团队成长的最后阶段是表现阶段。这时，项目团队积极工作，急于实现仙姑目标。这一阶段的工作绩效很高，团队有集体感和荣誉感，信息十足。

这一阶段，项目经理需要特别关注预算、进度计划、工作范围及计划方面的项目业绩。如果实际进程落后于计划进程，项目经理就需要协助支持修正行动的制定与执行。这一阶段的主要方式是危机激励、目标激励和知识激励。

需要强调的是，对于信息系统建设人才，要更多的引导他们进行自我激励和知识激励。足够的物质激励是不言而喻的，永远都是最有效的激励。

激励的结果是使参与信息系统的所有成员组成一个富有成效的项目团队，这种团队具有如下特点：

• 能清晰的理解项目的目标
• 每位成员的角色和职责都有明确的期望
• 以项目的目标为行为的导向
• 项目成员之间高度信任、高度合作互助。

13.6 软件的运行与评价

指软件开发结束后交付用户使用，用户在实际使用中对软件是否符合开发时制定的一系列评价标准进行打分，看是否满足了用户的使用要求。通常，关注如下几点：

1. 软件的稳定性和可靠性评价
2. 软件是否满足了用户的需求
3. 软件实施给用户带来的好处。

13.7 软件过程改进

用于帮助软件企业对其软件生产过程进行计划、过程诊断、改进方案的制定及实施工作。它的实施对象是软件企业的软件过程，即软件产品的生产过程，也包括配置管理、软件维护等辅助过程。目前，使用最多的软件过程改进模型包括CMM、CMMI、ISO9000和ITIL等系列标准。

第十四章 信息系统基础知识

信息系统是一个由人、计算机等组成的能进行信息的手机、传递、存储、加工、维护和使用的系统，它是一门综合了经理管理理论、运筹学、统计学、计算机科学的系统性和边缘性科学。

信息系统包含三大要素，分别是系统的观点、数学的方法和计算机应用。能够充分利用数据资源为企业经理管理服务；能够利用信息和模型辅助企业决策，从而预测和控制企业行为。

14.1 信息系统概述

信息系统IS一般泛指手机、存储、处理和传播各种信息的具有完整功能的集合体。现代的信息系统总是指以计算机为信息处理工具、以网络为信息传输手段的信息系统。

14.1.1 信息系统的组成

1. 信息系统的数据环境

第一类数据环境：数据文件。特征是：没有使用数据库管理系统，根据大多数的应用需要，由系统分析师和程序员分散的设计各种数据文件。特点是简单，相对容易实现。但随着应用程序增加，数据文件数目剧增，导致很高的维护费用；一小点应用上的变化都将引起连锁反应，使修改和维护工作缓慢切费用高昂，并很难进行。

第二类数据环境：应用数据库。这类信息系统，虽然使用了数据库管理系统，但没达到第三类数据环境的共享程度。分散的数据库为分散的应用而设计。实现起来比第三类数据环境简单。像第一类数据环境一样，随着应用的扩充，应用数据库的个数，以及每个数据库中的数据量也在急剧增加，随之而导致维护费用的大幅度增高，有时甚至高于第一类数据环境。该类数据环境还没有发挥使用数据库的主要优越性

第三类数据环境：主题数据库。信息系统所建立的主题数据库与一般具体的应用有很大的区别，它有很强的独立性，数据经过设计，其存储去的结构与使用它的处理程序都是独立的。各种面向业务主题的数据库，如顾客数据、产品数据或人事数据，通过一些共享数据库被联系和体现出来。这种主题数据库的特点是：经过严格的数据分析，建立应用模型，虽然设计开发需要花费较长的时间，但其后的维护费用很低。最终（但不是立即）会使应用开发加快，并能使用户直接与这些数据库交互使用数据。主题数据库的开发需要改变传统的系统分析方法和数据处理的管理办法。但是，如果管理不善，也会蜕变成第二类甚至是第一类数据环境。

第四类数据环境：信息检索系统。一些数据库经过组织能保证信息检索和快速查询的需要，而不是大量的事务管理。软件设计中要采用转换文件、倒排表或辅关键字查询技术。新的字段可随时动态的加入到数据结构中。有良好的最终用户查询和报告生成软件工具。大多数用户掌握的系统都采用第四类数据库。这种环境的特点是：比传统的数据库有更大的灵活性和动态可变性。一般应该与第三类数据环境共存，支持综合信息服务和决策系统。

2. 信息系统的应用层次

一个公司的管理活动可以分成4级：战略级、战术级、操作级和事务级，相应的，信息系统就其功能和作用来看，也可以分为4种类型，即战略级信息系统、战术级信息系统、操作级信息系统和事务级信息系统。一般来说，战略级信息系统的所有者和使用者都是企业的最高管理员，对于现代公司制企业，就是企业的董事会和经理班子；战术级信息系统的使用者一般是企业的中层经理及其管理的部门；操作级信息系统的使用者一般是服务型企业的业务部门；事务级信息系统的使用者一般是企业的管理业务人员。

14.1.2 信息系统的生命周期

1. 信息系统的产生阶段

也是信息系统的概念阶段或者是信息系统的需求分析阶段。这一阶段又分为两个过程，一是概念的产生过程，即根据企业经营管理的需要，提出建设信息系统的初步想法；而是需求分析过程，即对企业信息系统的需求进行深入的调研和分析，并形成需求分析报表。

2. 信息系统的开发阶段

是信息系系统生命周期中最重要和最关键的阶段。该阶段又可分为5个阶段，具体如下：

1. 总体规划阶段。是系统开发的起始阶段，基础是需求分析，以计算机和互联网为工具的信息系统是企业管理系统的重要组成部分，是实现企业总体目标的重要工具。因此，他必须服从和服务于企业的总体目标和企业的决策管理活动。总体规划的作用主要有：
   
   • 指明信息系统在企业经营战略中的作用和地位。
   • 知道信息系统的开发
   • 优化配置和利用各种资源，包括内部资源和外部资源
   • 通过规划过程规范企业的业务流程
     一个比较完整的总体规划，应当包括信息系统的开发目标、信息系统的总体规划、信息系统的组织结构和管理流程、信息系统的实施规划、信息系统的技术规范等。
2. 系统分析阶段。系统分析阶段的目标是为系统设计阶段提供系统的逻辑模型。
   该阶段以企业的业务流程分析为基础，规划即将建设的信息系统的基本架构，它是企业的管理流程和信息流程的交汇点。系统分析的内容主要应包括，组织架构及功能分析、业务流程分析、数据和数据流程分析、系统初步方案等。
3. 系统设计阶段。该阶段是根据系统分析的结果，设计出信息系统的实施方案。系统设计的主要内容耕保科，系统架构设计、数据库设计、处理流程设计、功能模块设计、安全控制方案设计、系统组织和队伍设计、系统管理流程设计等。
4. 系统实施阶段。改阶段是将设计阶段的结果在计算机和网络上具体实现，也就是将设计文本变成能在计算机上运行的软件系统。由于系统实施阶段是对以前的全部工作的检验。因此，系统实施阶段用户的参与特别重要。如果说在系统设计阶段以前，用户处于辅助地位的话，而到了系统实施阶段后，用户就应逐步变为系统的主导地位。
5. 系统验收阶段。信息系统实施阶段结束以后，系统就要进入试运行。通过试运行，系统性能的优劣、是否做到了用户友好等问题都会暴露在用户面前，这是就进入了系统验收阶段。

3. 信息系统的运行阶段

当信息系统通过验收，正式移交给用户之后，系统就进入了运行阶段。

要保障信息系统长长运行，一项不可缺少的工作就是系统维护。在软件工程中，把维护分为4中类型，即排错性维护、适应性维护、完善性维护和预防性维护。一般在系统运行初期，排错性维护和适应性维护比较多，而到后来，完善性维护和预防性维护会比较多。

4. 信息系统的消亡阶段

14.1.3 信息系统建设的原则

1. 高层管理人员接入原则

2. 用户参与开发原则

主要包括以下几项含义：

一是“用户”有确定的范围。

二是用户，特别是核心用户，应当参与信息系统的整个过程。

三是用户应当深度参与系统开发。

3. 自顶向下规划原则

4. 工程化原则

5. 其他原则

• 创新性原则，用来体现先进性
• 整体性原则，用来体现完整性
• 发展性原则，用来体现超前性
• 经济性原则，用来体现实用性

14.1.4 信息系统开发方法

1. 结构化方法

是由结构化系统分析和设计组成的一种信息系统开发方法。

它假定被开发的系统是一个结构化的系统，因而，其基本思想是将系统的生命周期划分为系统调查、系统分析、系统设计、系统实施、系统维护等阶段。结构化方法的开发过程一般是先把系统功能视为一个大的模块，再根据系统分析设计的要求对其进行进一步的模块分解或组合。主要特点如下：

1. 开发目标清晰化。开发遵循“用户第一”的原则，开发中要保持与用户的沟通，取得与用户的共识，这使得信息系统的开发建立在可靠的基础之上。
2. 工作阶段程式化。每个阶段的工作内容明确，注重开发过程的控制。每一阶段工作完成后，要根据阶段工作目标和要求进行审查，这使得各阶段工作有条不紊，也避免为以后的工作留下隐患。
3. 开发文档规范化。每一阶段工作完成后，要按照要求完成相应的文档，以保证各个工作阶段的衔接与系统维护工作的便利。
4. 设计方法结构化。采用自上而下的结构化、模块化分析与设计方法，时各个子系统间相互独立，便于系统的分析、设计、实现和维护。

2. 原型法

是一种根据用户需求，利用系统开啊工具，快速的建立一个系统模型展示给用户，在此基础上与用户交流，最终实现用户需求的信息系统快速开发的方法。

3. 面向对象方法

是对客观世界的一种看法，是把客观世界从概念上看成一个由相互配合而协作的对象所组成的系统。

4. 面向服务的方法

14.2 信息系统工程

14.2.1 信息系统工程的概念

系统是由相互作用和相互依赖的若干部分，按一定规律结合成的、具有特定功能的有机整体。系统有下述特征：

1. 集合性。系统是由许多元素有机的组成的整体。每个元素服从整体，追求全局最优。
2. 相关性。系统的各个组成部分之间是互相联系、互相制约的。
3. 目的性。任何系统都是有目的和目标的。
4. 层次性。一个系统往往由多个部门（或部分）组成。每个部门可以看做一个小的系统，称为子系统，子系统之下又可划分为子子系统。系统具有层次结构。
5. 环境适应性。任何系统都是存在并活动于一个特定的环境之中，与环境不断进行物质、能量和信息的交换。系统必须适应环境。

1. 系统的分类

按照系统功能划分：工业控制系统、信息管理系统、军事系统和经济系统等。
按照系统与外界的关系划分：封闭系统和开放系统
按照系统的内部结构划分：开环系统和闭环系统等。
按照抽象程度将系统分为：概念系统（描述系统的主要特征和大致轮廓）、逻辑系统（脱离实现细节的合理系统）和物理系统（实际存在的系统）。

2. 系统工程

从不同的角度、不同的背景、不同的应用目的，系统工程有不同的含义。归纳不同的含义，给出系统工程的定义如下：

系统工程是以研究大规模复杂系统为对象的一门交叉学科。它把自然科学和社会科学的某些思想、理论、方法、策略和手段等根据总体协调的需要，有机的联系起来，应用定量和定性分析相结合的方法和计算机等技术工具，对系统的构成要素、组织结构、信息交换和反馈控制等功能进行分析、设计、制造和服务，从而达到最优设计、最优控制和最优管理的目的。

3. 信息系统

一般泛指手机、存储、处理和传播各种信息的具备完整功能的集合体。当前信息系统最重要的特征是计算机和互联网技术的应用。

现代信息系统是以计算机为信息处理工具，以网络为信息传输手段的；它最大限度的屏蔽了时间和空间的限制，使人们能以最快捷的方式获取所需信息并加以利用。

4. 信息系统工程

将系统工程的理论、方法应用到信息系统，并结合信息系统自身特点，就形成了信息系统工程。信息系统工程应强调研究法的整体性、系统性，技术应用的综合性和项目管理的规范化、标准化。

研究方法的整体性，就是把研究对象看做一个由若干个子系统有机结合的整体来分析和设计。对各子系统的技术首先要从实现整个系统技术协调的观点来考虑，从总体最有的需求来选择解决方案。研究方法的系统性要求研究方法反映和顺应客观事物和系统自身的特征和运动规律。

一个复杂的信息系统工程客观上存在两个秉性工程，一个是工程技术进程，一个是对工程技术进程的管理控制进程。后者包括工程的规划、组织、控制、进度安排，对各种方案进行分析、比较和决策、评价选定方案的技术效果等。

14.2.2 信息系统工程的内容

信息系统工程的内容主要包括几个方面：一是体系，二是技术、三是管理。

1. 信息系统工程的体系构成

信息系统分为信息网络系统、信息资源系统和信息应用系统三类，并对每一类的含义进行了界定：

• 信息网络系统是指以信息技术为主要手段建立的信息处理、传输、交换和分发的计算机网络系统。
• 信息资源系统是指以信息技术为主要技术手段建立的信息资源采集、存储、处理的资源系统
• 信息应用系统是指以信息技术为主要手段建立的各类业务管理的应用系统。

2. 信息系统工程的技术构成

软件工程和信息工程都是信息系统工程的技术基础。

软件工程是开发、运行、维护和修复软件的系统方法。其中，“软件”的定义为：计算机程序、方法、规则、相关的文档资料以及在计算机上运行时所必须的数据的集合。

软件工程包括三个要素：方法、工具和过程。方法为软件开发提供了“如何做”的技术。包括项目计划与估算、需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试及维护等；工具包括各种软件工具、开发及其和开发过程信息库，提供自动或半自动的软件开发环境；过程定义了方法使用的顺序、要求交付的文档资料、为保证质量和协调变化所需要的管理及软件开发各个阶段完成的里程碑。

信息工程是指以数据系统为基础，建立一个信息化企业所需要的一套相互关联的原则。信息工程的主要焦点是用计算机来存储和维护数据，而信息则是从这些数据提炼出来，来满足人们的某种需要的数据。

信息工程方法的主要特点：一是以数据为中心，进一步的工作是建立主题数据库；二是将工程的实施划分为对业务系统的实施和对技术系统的实施。前者包含了软件的技术内容，而后者则包含了工程内容。

3. 组织流程管理

组织和流程是两个既有联系又有区别的概念。一个组织必然有工作，而有工作就必然有流程；任何流程必然发生在某一个具体的组织之内。因此，组织流程管理是一个组织管理的重点和中心内容，也是信息系统工程的重要内容。

组织流程管理模式的主要工作在于处理好组织内各流程之间的关系，合理的在各流程之间分配资源。因此，必须建立有效的组织保障，这样才能保证流程管理工作的连续性和长期性。有效的组织保障包括：

1. 建立流程管理机构，这一机构可归入管理流程之中。
2. 配备强有力的领导来负责内部的流程管理工作。
3. 制定各流程之间的动态关系规则。通过实施流程管理模式，传统组织中的组织图将不复存在，取代他的将是流程管理图。

4. 信息系统工程的管理

信息系统工程首先是一项工程，而一项工程一般总是被定义为一个项目，因此，信息系统工程管理也可以视同为项目管理。

所谓“项目”是指在特定的条件下，具有特定目标的一次任务，是在一定时间内，满足一系列特定目标的多项相关工作的总称。

以上关于项目的定义包含三层含义，一是项目是一次性的任务，且有特定的范围和要求；二是在一定的组织机构内，利用有限资源在规定时间内完成任务；三是任务要满足一定性能、质量、水浪、技术指标等要求。所以可以用项目管理的思想和方法来指导信息系统的建设。

项目管理就是把各种资源应用于目标，以实现项目的目标，满足各方面既定的需求。

在具体实施过程中，项目管理一般包含了一下几个方面的内容：

1. 任务划分。是把整个开发工作定义成一组任务的集合，这组任务又可以进一步划分成若干个子任务，进而形成具有层次结构的任务群。
2. 计划安排。根据划分完毕的任务即可制定出整个开发及项目管理计划，并产生完成任务的计划表
3. 经费管理。经费管理在整个开发项目管理中处于一个重要的地位。项目经理可以运用经济杠杆来控制整个开发工作。
4. 审计控制。按照采用的标准方法，针对每一类开发人员制定出工作过程中的责任、义务、完成任务的质量标准等，按照计划对每项任务进行审计。
5. 风险管理。
6. 质量保证。

14.2.3 信息系统工程的总体规划

1. 信息系统工程总体规划的概念

是信息系统工程生命周期的第一阶段，这一阶段的主要目标是明确系统整个生命周期内的发展方向、系统规模和开发计划。

1. 总体规划的需求

不少已经建成或正在建设的系统仍然存在一系列问题，主要如下：

• 系统建设与组织发展的目标和战略不匹配。
• 已建成的系统解决问题的有效性低，即系统建成后对管理并无显著改善
• 不能适应环境变化和组织变革的需要。
• 组织结构陈旧，管理落后
• 系统使用人员的素质较低
• 系统开发环境落后，技术方案不合理
• 系统开发及运行维护的标准、规范混乱
• 资源短缺，投入太少，而对系统的期望又过高。

综上所述，在系统建设中，往往缺乏科学的、有效的系统规划。

2. 总体规划的主要任务

主要目标就是制定出信息系统工程的长期发展方案，决定信息系统工程在整个生命周期内的发展方向、规模和发展过程。这样做能为以后的系统分析和设计打好基础。这个阶段的主要任务是：

• 制定信息系统工程的发展战略。主要是使信息系统工程的战略与整个组织的战略和目标协调一致。
• 确定组织的主要信息需求，形成信息系统工程的总体结构方案，安排项目开发计划。
• 制定系统建设的资源分配计划，即制定为实现开发计划而需要的硬软件资源、数据通信设备、人员、技术、服务和资金等计划，提出整个系统的建设概算。

3. 总体规划主要步骤

进行信息系统工程的总体规划一般包括以下几个阶段。

1. 对当前系统进行初步的调查。初步调查主要由两部分构成：
   
   • 一般调查。
   • 信息需求初步调查。通过调查组织系统的工作职责及活动来了解各职能机构所要处理的数据，估计各机构发生的数据量及频度。信息需求初步调查还应调查环境信息，包括内部环境和外部环境的信息。
2. 分析和确定系统目标。
3. 分析子系统的组成及基本功能。
4. 拟定系统的实施方案
5. 进行系统的可行性研究
6. 编写可行性研究报告

2. 信息系统工程总体规划的目标

就是信息系统工程的方向和指导方针。

1. 总体规划目标的意义

信息系统工程建设初期的总体规划是完成后续工作，如详细定义信息系统工程的需求、优化企业各类业务流程、在项目实施中控制需求范围，保证信息系统工程顺利实施、取得良好效果的关键所在。信息系统的总体规划是进行具体开发工作的必要准备和基本依据。

2. 总体规划目标的功能

这里要注意两个原则：

一是从组织的战略出发，而不是从系统的需求出发，这样就可以避免脱离组织宗旨和战略目标，走入为建设而建设的困境；

二是从业务的变革出发，而不是从技术的变革出发，这样有利于充分利用组织的现有资源来满足关键需求，从而避免信息系统工程无法有效的支持组织决策。

信息系统工程规划的主要目标是根据企业总体目标规划好统一的、既有集中式又有分布式、分期逐步实现的数据平台和应用平台的建设。

3. 总体规划目标的分析过程

1. 确定组织的总体目标。分析的步骤是：
   
   • 根据系统调查的结果，进行分析，归纳出现行系统中的关键问题，做出问题表
   • 根据问题表，构造目标的层次结构，即目标树。在目标树中，最上层是总目标，一下各层是分目标或子目标，最下层是为实现目标而采取的具体措施，他是用来衡量目标是否切合实际的标准。
   • 对目标树中的各项分目标进行分析。分析各项分目标之间的关系，确定解决目标冲突的方法，指出各项措施的考核指标。
   • 将目标树按各层分目标在系统中所起的作用重新绘制。
2. 确定信息系统工程规划的总体目标。信息系统工程的目标分析是指在组织总体目标分析的基础上，确立信息系统工程应在哪些方面发挥作用，以及如何发挥作用。通常，信息系统工程应该在下面几个方面发挥作用：
   
   • 信息系统工程的辅助决策功能。期望达到的目标有系统预测、计算机辅助鞠策、系统模拟与控制等。
   • 信息系统工程的辅助管理功能。期望达到的目标是实现办公自动化
   • 企业资源管理

4. 总归规划目标的使用

要根据用户的需求和组织的现状，将目标进行分解和阐释。在总体目标的指导下，进一步规划系统的实施范围、功能结构、开发进度、投资规模、参与人员和组织保证等；在做好可行性分析的基础上，制定出实施方案，确定系统的总体结构和子系统的划分。以上工作完成后，要组织有关专家对总体规划报告进行评估认证，根据认证意见修改或调整计划，必要时重新制定。

3. 信息系统工程总体规划的范围

1. 总体规划的层次

从层次上可以分为：信息战略规划、信息资源规划、信息系统工程建设规划和企业资源计划（ERP）。

1. 信息战略规划。信息战略规划的基础是战略数据规划。
2. 信息资源规划。是一个系统工程，包括：需求分析、集成化的管理信息系统的建设、信息资源管理基础标准的制定，业务概念设计模型的的建立、信息资源网的构建等。
3. 信息系统工程建设规划。
4. 企业资源规划。

2. 总体规划的任务

无论是哪个层次的信息系统工程规划，其基本原理和过程都是一致的，大致都需要完成以下任务：

• 明确组织远景和使命。
• 确立组织发展战略和目标
• 明晰组织业务及管理变革策略
• 识别组织关键成功因素、分析关键性能指标、抽取信息需求。
• 建立总体信息工程框架
• 提出可行性报告和总体规划方案。

信息系统工程的规划本质上可以对从完成业务战略出发到实现信息系统工程战略进行定位。

3. 信息系统工程的功能范围

根据已确定的系统目标和估算出的整个信息系统的信息量，考虑企业现有的客观条件，包括资金情况、设备条件、现场条件、技术水平、管理现状等，合理的确定系统的范围和功能。应注意，在不超越客观条件限制的条件下，使人、物、财得到充分利用，使系统的功能尽可能完善，保证系统目标的实现。

对于新建立的系统，可能要求现行的管理机构在组织上和功能上做某些调整和变动，以适应计算机的管理。在划分系统范围时，应按客观需要选择必要的系统结构和功能，不要受现行系统的限制。因为新系统在管理机制上，性能要优于现行系统，所以不能把现行体制搬到新的系统上，必要时，可以启动业务流程再造。

4. 确定功能范围的步骤

步骤如下：

1. 绘制出系统的总数据流程图。该图是系统分析阶段的各业务部门的数据流程图，综合绘制在一张图上。
2. 根据系统方案的规定和用户的要求，结合现行系统的环境，确定系统的边界范围，并在总信息流程图上圈出。
3. 有关人员协商讨论
4. 确定系统范围，并作出分析说明

5. 系统总体结构分解

为了将复杂的信息系统分解成便于理解和实现的部分，一般将信息系统分解为若干相对独立而又相互联系的子系统，即信息系统的主要系统。

如果信息系统规模很大，为了方便信息系统的实现，还需将子系统再细分成若干个分系统。这是因为，首先，子系统键的相互关系仍过于复杂，分解之后，可以使这种关系更为明确、简单；其次，并不是在一个子系统中的所有过程都需要给予高优先级的支持，而应分出不同的优先级；最后，给定的子系统往往较大，难以一次实现，需要以分系统或几个分系统为单位来实现。

6.投资概算

1. 计算机系统软、硬件设备投资。
2. 系统开发费。指从系统调研到系统全部实现这一过程中花费的研制时间和人力折合的费用，一般按人月或人周计算。
3. 系统安装和维护费用。包括3方面内容：计算机软、硬件的安装和维护费用，这个费用一般根据计算机软、硬件生产厂家的报价估算；信息系统的安装和维护费用；基础设施的维修和改造费用。
4. 人员培训费。

7. 总体规划的成果

总体规划的成果是可行性分析报告和总体规划报告。

可行性分析报告也成为可行性研究。

总体规划报告是信息系统功能总体规划的最终成果，经过一定的审批程序，以组织的名义发布实施，成为信息系统工程的指导性文件。

14.2.4 总体规划的方法论

1. 业务系统规划法 BSP

既是信息系统的重要规划方法，同时，也是信息系统工程总体战略规划的重要方法。

1. BSP的概念

辅助企业信息系统规划，来满足其近期和长期的信息化需求。

实行BSP的前提是，在企业内有改善信息系统的要求，并且有为建设这一系统而建立的总的战略的需要。因而BSP的基本功能是服务于信息系统建设的长期目标。

1. 信息系统的战略应当表达出企业的各个管理层次的需求。首先，信息系统应强调对管理决策的支持。一般认为，在任一企业内同时存在着三个不同的层次，战略计划层：是决策组织目标、达到这些目标所需用的资源，以及获取、分配这些资源的策略的过程；管理控制层：通过这一过程，管理者确认资源的获取及组织的目标是否有效的使用了这些资源；操作控制层：保证有效率的完成具体的任务。
2. 信息系统应该向整个企业提供一致的信息。
3. 信息系统应该适应组织机构和管理体制的改变。
4. 信息系统的战略规划，应当从总体信息系统结构中的子系统开始实现。

总结起来，BSP方法确立了信息系统建设的若干原则。方法本身是可以灵活运用的，即方法中的某些步骤和技巧可根据具体情况变化而做相应的调整，但它的基本原则不能违背，因为这些原则是BSP的灵魂。

2. BSP的目标

主要是提供信息系统规划，用以支持企业短期的和长期的信息需要。其具体目标可归纳如下：

• 为管理者提供一种形式化的、客观的方法，明确建立信息系统的优先顺序，而不考虑部门的狭隘利益，并避免主动性。
• 为具有较长生命周期系统的建设和投资提供保障。由于系统是基于业务过程的，因而不因机构变化而失效。
• 为了以最高效率支持企业目标，BSP提供数据处理和资源管理
• 增加负责人的信息，使其坚信高效的信息系统能够被实施。
• 通过提供信息系统对用户需求的快速响应，从而改善信息系统管理部门和用户之间的关系。
• 应将数据作为一种企业资源甲乙确定，为使每个用户更有效的使用这些数据，要对这些数据进行统一规划、管理和控制。
• 由BSP得到的规划不应被看成是一成不变的，它只是在某一阶段对事物的最好认识。

BSP方法的真正价值在于提供了下面的机会：

一是创造一种环境和提出初步行动计划，使企业能依此对未来的系统和优先次序的改变做出反应，不致造成设计的重大失误。

二是定义信息系统的职能，并不断完善。

3. BSP方法的实施步骤

1. 确立项目。必须得到最高领导者和某些最高管理部门的参与的承诺。
2. 工作准备。要有一位企业领导用全部时间参加项目工作并指导项目组的活动。
3. 主要活动
   
   • 开始。首项活动是企业活动介绍，全体项目成员都要参加。
   • 定义业务过程。
   • 定义数据类
   • 分析现存系统支持能力
   • 确定管理部门对系统的要求
   • 提出判断和结论
   • 定义信息总体结构
   • 确定总体结构中的优先顺序
   • 评价信息资源管理工作
   • 制定建议书和开发计划
   • 工作成果报告

2. 关键成功因素法 CSF

能够帮助组织找到影响系统成功的关键因素，进行分析以确定组织的信息需求，从而为管理部门控制信息技术及其处理过程提供实施指南。

在每个企业中都存在着对企业成功起关键性作用的因素，称为关键成功因素。

1. CSP的确定

特征如下：

• 内部CSF：针对机构的内部活动，如改善产品质量、提高工效等。
• 外部CSF：与机构的对外活动有关，如满足客户企业的进入标准、获得对方的信贷。
• 监控性CSF：对现有业务流程等进行监控，如检测零件缺陷百分比
• 建设性CSF：适应组织未来变化的有关活动，如改善产品组合。

CSF共分4层：行业的CSF、组织的CSF、部门的CSF、管理者的CSF。

2. CSF实施步骤

CSF实施过程通常是：通过集成高层管理者的目标而确定成功因素，通过个人的成功因素的汇总，导出组织整体的决定性成功因素，然后据此建立能够提供与这些成功因素相关的信息系统。

第一步：了解组织的战略目标

第二步：识别所有成功因素。可以通过与高级管理层进行交流，辨别其目标和由此产生的成功因素；也可以采用逐层分解的方法，引出影响系统战略目标的各种因素及影响这些因素的子因素。

第三步：确定关键成功因素。对所有成功因素进行评价，根据组织的现状和目标确定关键成功因素。

第四步：识别绩效指标和标准，以及测量绩效的数据。即给出每个成功因素的绩效指标和标准，以及用以衡量相应指标额数据。

关键成功因素与组织战略规划密切相关，组织战略描述组织期望的目标，关键成功因素则提供达到目标的关键路径和所需的测量标准。关键成功因素是为确保业务过程的成功需要完成最重要的工作，是业务过程的可观察、可测量的特征。

CSF的优缺点

缺点是：数据的汇总和数据分析过程比较随意，缺乏一种专门严格的方法将众多个人的关键成功因素汇总成一个明确的整个组织的成功因素；由于个人和组织的成功因素往往并不一致，两者之间的界限容易被混淆，从而容易使组织的成功因素具有个人倾向性；由于环境和管理经常迅速变化，信息系统也必须做出相应调整，而用CSF法开发的系统可能无法适应变化了的环境；CSF在应用于较低层的管理时，由于不容易找到相应目标的关键成功因子及其关键指标，效率可能会比较低。

3. 战略目标集合转换法 SST

将组织的战略看成一个“信息集合”，包括使命、目标、战略和其他战略变量。战略性系统规划就是把组织的战略集合转化为信息系统的战略集合，而后者由信息系统的系统目标、环境约束和战略规划组成。

该方法的步骤如下：

第一步：识别和阐明组织的战略集合。首先考虑组织是否有书面的战略规划，如果没有，就要去构造这种战略集合。其构造过程如下：

1. 描绘出组织各类人员结构。
2. 识别每类人员的目标
3. 对于每类人员识别其使命及战略。

第二步，将组织的战略集合转化为信息系统战略集合。这个转换过程包括对组织战略集合的每一个元素确定对应的信息系统战略元素。信息系统战略集合由系统目标、系统约束和系统设计原则组成。然后提炼出整个信息系统的结构，最后，选出一个较优的方案呈送管理层。

战略目标集合转化法所描述的是从组织的基本宗旨出发，得到对系统开发阶段的输入，其目的是产生一个与组织的战略和能力紧密相关的系统。

14.3 政府信息化与电子政务

政府信息化就是应用现代信息技术、网络技术和通信技术，通过信息资源的开发和利用来集成管理和服务，从而提高政府的工作效率、决策质量、调控能力，并节约开支，改进政府的组织结构、业务流程和工作方式，全方位的向社会提供优质、规范、透明的管理和服务。

这个定义包括三个方面的内容：第一，政府信息化必须借助于信息技术和网络技术，离不开信息基础设施和软件产品；第二，政府信息化是一个系统工程，它不仅是与行政有关部门的信息化，还包括立法、司法部门及其他一些公共组织的信息化；第三，政府信息化并不是简单的将传统的政府管理事务原封不动的搬到不联网上，而是要对已有的组织结构和业务流程进行重组或再造。政府信息化的主要内容是电子政务。

14.3.1 我国政府信息化的历程和策略

1. 我国政府信息化的发展历程

2. 我国政府信息化的策略

1. 做好战略数据规划
2. 面向主导业务流程
3. 重视资源条件
4. 以人为本
5. 设立CIO
6. 加强规范化和标准化
7. 充分利用社会资源

14.3.2 电子政务的内容

电子政务实质上是对现有的、工业时代形成的政府形态的一种改造，即利用信息技术和其他相关软件，来构造更适合信息时代的政府组织结构和运行方式。

政府与政府，政府与企（事）业，一级政府与公民之间的互动构成了下面5个不同又相互关联的领域

1. 政府与政府。
2. 政府对企业。
3. 政府对公民。
4. 企业对政府
5. 公民对政府
6. 政府对公务员

14.3.3 电子政务建设的过程模式和技术模式

电子政务建设的过程模式是电子整我目标的实现过程，而电子政务的技术模式则是其实现的技术手段。

1. 电子政务建设的过程模式

1. 以用户为中心。
2. 引进“客户关系管理”技术
3. 政府门户

2. 电子政务的技术模式

电子政务的技术模式由网络管理模式、信息资源管理模式和应用开发模式，以及网络安全、标准化等构成。电子政务通过一定的技术模式将现有的和即将建设的各个政府网络和应用系统连接起来，统一标准和规划，做到互通互联，称为一个统一的政府信息化平台。

1. 网络管理模式

• 专用网络。指政府部门之间的网络，因为对于机密信息的交换，需要在于外部网络进行物理隔离的专用网络上传输，以保证机密信息的绝对安全性。
• 内部网络。政府内部的办公网络，以局域网为主，用于政府内部和政府部门之间一般的信息交换。内部网络具有传统数据网络的性能优点和共享数据网络结构的优点，同事，还能够提供远程访问，以及外部网络和内部网络的连接。
• 外部网络。对于未公众提供的信息及其他可公开的信息，可以利用政府网站等形式发布到Internet网上。

2. 信息资源管理模式

信息资源是电子政务的处理对象，也是电子政务的基础。政府部门的信息从内容上大致分为两类：一类是来自公文系统的文档型信息另一类是来自数据处理系统的结构化信息。电子政务可以选用的信息资源管理模式有多种，目前主要有两种，即元数据管理模式和XML数据管理模式。

元数据管理模式。该模式可以为不同部门、不同级别的机构提供统一的数据管理和交换模式，为跨部门、跨行业的信息资源整合提供技术基础。元数据管理模式一般采用分布式的数据存储形式，通过元数据实现各级部门之间的信息检索和内容调用。元数据管理模式采用分类编目管理结构，对电子政务系统中的各类信息进行分类组织，从而达到知识管理管理和决策支持的目标。

XML数据管理模式。在数据交换和共享的层面上，基于XML数据管理模式，建立统一的信息技术平台，实现不同的不换。它覆盖了信息处理的从数据采集、处理、传输，到信息管理、分析和共享的整个流程，将传统的管理信息系统提升到具有数据分析和共享功能的系统中。从数据中挖掘和提炼只是，为决策提供有力的支持。

3. 应用开发模式

电子政务的应用开发模式主要有：

• 政府与公务员G2E
• 政府对经济活动G2B
• 政府部门与政府部门G2G
• 政府对工薪服务G2C

4. 电子政务的安全体系

电子政务的安全提示包括物理安全、网络安全、信息安全和安全管理等方面。

信息安全系统以PKI技术为基础，围绕数字证明应用，为各种业务应用提供信息的真实性、完整性、机密性和不可否认保证，并在业务系统中建立有效的信任管理机制、授权控制机制和严密的责任机制。信息安全与应用紧密相关，可分为信息安全基础设施和信息安全应用产品两类。

信息安全基础设施产品为各种应用提供通用的安全服务，通过建立通用的安全接口来实现安全服务。主要包括：PKI、PMI、密钥管理。PKI以公开密钥技术为基础，以数据机密性、完整性、身份认证和行为的不可否认为安全目的。信任服务体系提供基本PKI数字证书认证机制的实体身份鉴别服务，从而建立全系统范围内一致的信任基准，为实施电子政务提供支持。密钥管理基础设施KMI提供统一的密钥管理服务，涉及密钥生成服务器、密钥数据库服务器和密钥服务管理器等组成部分。授权管理基础设施GMI主要负责向应用系统提供与应用相关的授权服务管理，授权管理以资源为核心，将对资源的访问控制权统一交由资源的所有者进行访问控制。

5. 电子政务的标准化

电子政务建设的指导思想和原则：统一规划、加强领导；需求主导，突出重点；整合资源，拉动产业；统一标准，保障安全。

14.4 企业信息化与电子商务

14.4.1 企业信息化概述

指企业以业务流程的优化和重构为基础，在一定的深度和广度上利用计算机技术、网络技术和数据库技术，控制和集成化刮泥企业生产经营活动中的各种信息，实现企业内外部信息的共享和有效利用，以提高企业的经济效益和市场竞争力。

1. 企业信息化的目的

一般意义而言，企业信息化的目的就是要建立一个整体上相对于人的神经系统的数字神经系统。这种数字神经系统，使得企业具有平稳和有效的运作能力，对紧急情况和商机作出快速反应，为企业内外部用户提供有价值的信息，以提高企业的核心竞争力。

2. 企业信息化的规划

企业信息化一定要建立在企业战略规划基础智商高，以企业战略规划为基础建立的企业管理模式是建立企业战略数据模型的依据。

企业信息化就是技术和业务的融合，这个“融合”需要从三个层面来实现：

首先，企业战略的层面。

其次，业务运作层面

在此，管理运作层面。

企业战略数据模型分为数据库模型和数据仓库模型，数据库模型用来描述日常事务处理中的数据及其关系；数据仓库模型则描述企业高层管理决策者所需信息及其关系。在企业信息化过程中，数据库模型是一出，一个好的数据库模型应该客观的反应企业生产经营的内在联系。数据库是办公自动化、计算机辅助管理系统、开发与设计自动化、生产过程自动化、Internet的基础和环境。

3. 企业信息化的方法

1. 业务流程重构方法
2. 核心业务应用方法
3. 信息系统建设方法
4. 主题数据库方法
5. 资源管理方法
6. 人力资本投资方法

14.4.2 企业资源规划

企业资源是指企业业务运作和战略运作的事物，既包括人们常说的人、财、物，也包括人们没有特别关注的信息资源；同时，不仅包括企业的内部资源，还包括企业的各种外部资源。因此，ERP就是一个有效的组织、计划和实施企业的内外部资源的管理系统，它依靠IT的技术和手段得以保证其信息的继承性、实时性和统一性。

1. ERP的结构

ERP是一个层次结构，可分为三个层次，即管理思想、软件产品、管理系统

1.ERP的管理思想

基本思想是将企业的业务流程看做一个紧密连接的供应链，将企业内部划分成几个相互协同作业的支持子系统，如财务、市场营销、生产制造、质量控制、服务维护、工程技术等。

2. 软件产品

现在，大多数ERP产品供应商都在模块化的基础上，把软件产品和软件服务进行集成，实现软件产品的技术先进性和个性化设计，为用户提供一体化的解决方案。

3. 管理系统

管理系统是ERP的基础和依托。ERP是一个集成的信息系统，承诺建立跨越企业多个部门、各种生产要素和环境的单一应用原则下处理所有的事务，即意味着集成。这种集成应该包括人力资源、财务、销售、制造、任务分派和企业供应链等的各种管理业务。

具体而言，ERP管理系统主要由六大功能目标组成：

1. 支持企业整体发展战略经营系统。
2. 实现全球大市场营销战略与集成化市场营销，也就是实现在预测、市场规模、广告策略、价格策略、服务、分销等方面进行信息集成和管理集成。
3. 完善企业成本管理机制
4. 研究开发管理系统，保证能够迅速的开发适应市场要求的新的产品，构筑企业的核心技术体系，保持企业的竞争优势。
5. 建立敏捷的后勤管理系统，强调通过动态联盟模式把优势互补的企业联合在一起，用最有效和最经济的方式参加竞争，迅速响应市场孙曦万变的需求。
6. 准时生产模式，把客户纳入产品开发过程，吧销售代理商和供应商、写作单位纳入生产体系，按照客户不断变化的需求同步组织生产，时刻保持产品的高质量、多样性和灵活性。

2. ERP的主要功能

1. 支持决策的功能。
2. 为处于不同行业的企业提供有针对性的IT解决方案
3. 从企业内部的供应链发展为全行业和跨行业的供应链

3. ERP的主要功能模块

ERP是将企业所有资源进行集成整合，简单的说是将企业的三大流：物流、资金流、信息流进行全面一体化管理的管理信息系统。

14.4.3 客户管理管理

CRM是在坚持以客户为中心的理念的基础上，重构包括市场营销和客户服务等业务流程。CRM的目标不仅要使这些业务流程自动化，而且要确保前台应用系统能够改进客户满意度、增加客户忠诚度，以达到使企业获利的最终目标。

1. CRM的概念

CRM是一种旨在改善企业与客户之间关系的新型管理机制。CRM继承了信息系统和办公系统等的一整套应用系统，从而确保了客户满意度的提高，以及通过对业务流程的全面管理来降低企业成本。

2. CRM的北京

3. CRM的内容

1. 客户服务。
2. 市场营销。
3. 共享的客户资料库
4. 分析能力

4. CRM的解决方案和实施过程

CRM的根本要求就是与客户建立起一种互相学习的关系，即从与客户的接触中了解他们在使用产品中遇到的问题，以及对产品的意见和建议，并帮助他们加以解决。

一般来说CRM由两部分组成，即触发中心和挖掘中心，前者指客户和CRM通过电话、传真、Web、Email等多种方式“触发”进行沟通；挖掘中心则是指对CRM记录交流沟通的信息进行智能分析。由此可见，一个有效的CRM解决方案应该具备以下要素：

1. 畅通有效的客户交流渠道（触发中心）。
2. 对所获信息进行有效分析（挖掘中心）。
3. CRM必须能够与ERP很好的集成。

CRM的实现过程具体来说，包含三方面的工作。一是客户服务与支持，即通过控制服务品质赢得顾客的忠诚度；二是客户群维系，即通过与顾客的了交流实现新的销售；三是商机管理，即利用数据库开展销售。

5. CRM的价值

14.4.4 产品数据管理

PDM是工程数据管理、文档管理、产品信息管理、技术数据管理、技术信息管理、图像管理，以及其他产品定义信息管理的集成管理框架技术。

1. PDM简介

PDM是帮助产品设计师、制造工程师和其他人员有效管理产品数据及产品开发过程的工具。目标是跟踪、组织、访问和管理产品设计、开发、修改和生产，甚至维修全过程中的所有数据和信息。PDM能够跨越时间和操作环境，实现数据的无缝连接和移动，保证正确的数据、在正确的时间、以正确的格式、出现在正确的位置，进而推动产品尽快的投入市场并能有效的平衡生产能力。

PDM系统的用户主要有三类：

1. 信息的使用者
2. 数据的创造者
3. 系统管理员

2. 企业对PDM的需求

实施PDM可以：

1. 在企业内部建立起完整的、统一的、共享的数据模型，保证各部门的产品信息一致。
2. 缩短产品的上市时间。
3. 适应多品种小批量生产方式
4. 提高设计效率和提高生产效率，降低产品成本
5. 提高设计与制造的准确性，提高产品质量
6. 保护数据完整性
7. 更好的控制项目
8. 实现全面的质量管理
9. 建立起企业级的协同工作平台，为最终实现企业的电子商务打下坚实的基础。

3. PDM的发展过程

1. 配合CAD使用的操起简单的PDM系统。
2. 产品数据管理
3. 产品协同商务或PDM标准化

4. PDM主要功能模块和内容

从结构上讲，基本上可以分成面向信息集成的系统集成工具和面向用户的PDM功能模块两部分。

1. 数据基库：PDM的核心，一般建立在关系型数据库系统的基础上，主要保证数据的安全性和完整性，并支持各种查询和检索功能
2. 产品配置管理：以数据基库为底层支持，以BOM为组织核心，把定义最终产品的所有工程数据和文档联系起来，对产品对象及其相互之间的联系进行维护和管理。
3. 工作流管理：主要实现产品设计与修改过程的跟踪与控制。包括工程数据的提交与修改、管理和监督、文档的分部控制、自动通知等。
4. 分类及检索功能：与面向对象的技术相结合，将具有相似特性的数据与过程分为一类，并赋予一定的属性和方法，使用户能够在分布式环境中高效的查询文档、数据、零件、标准件等对象。
5. 项目管理：在项目实施过程中实现其计划、组织、人员及相关数据的管理与配置，进行项目运行状态的坚实，完成计划的反馈。

14.4.5 企业门户

1. 企业门户的功能

企业门户的主要功能有：

1. 能够将一个机构现有的互联网址和服务完全合并而且相互兼容
2. 能够支持开放标准和应用编程接口，让平台得以轻易容纳新的应用程序
3. 能够介入一个由支持企业门户网站架构的伙伴或专业服务公司所组成的网络。
4. 能够多渠道接入网站，
5. 能够以统一的服务作为企业门户网站各种服务的基础，让用户享有多种便利

总之，门户网站应该是一个起点，引领用户接触企业最重要的信息、应用和服务。

2. 企业门户的分类

1. 企业信息门户EIP：基本作用是为人们提供企业信息，强调对结构化和与非结构化数据的手机、访问、管理和五福集成。
2. 企业知识门户EKP：是企业员工日常工作所涉及相关主题内容的“总店”。还具有信息搜集、整理、提炼的功能，可以对已有的只是进行分类，建立企业知识库并随时更新知识库的内容。
3. 企业应用门户EAP：实际上是对企业业务流程的集成。以商业流程和企业应用为核心，把商业流程中功能不同的应用模块通过门户技术集成在一起。从某种意义上说，可以吧企业应用门户看成是企业信息系统的集成界面。

3. 企业门户的要素

1. 战略性思维。评估未来的需求，并将这些需要与影响业务发展的因素一并考虑。
2. 为用户所需要的不同类型门户网站建立一个门户网站架构
3. 寻找合适的技术供货商——既能够支持各主要标准并能够将其基本门户网站架构与其他供货商的应用程序整合起来。
4. 确定索要建立的门户网站类型。制定可量化的目标，并清楚界定投资回报。如果对进展感到满意，就可逐步实行门户网站策略的其他元素。
5. 首先小规模的试办项目，确保有一个可行的工作环境。接着，如果用户的工作队伍决定加入新服务，就可以相应的扩充项目。

14.4.6 企业应用集成

1. EAI的简要历史

2. EAI的内容

EAI是企业信息系统集成的科学、方法和技术，其目的就是讲企业内的应用批次连接起来，或在企业之间连接起来。

EAI主要包括两方面：企业内部应用集成和企业间应用集成。EAI包括的内容跟复杂，设计结构、硬件、软件及流程等企业系统的各个层面。

1. 企业内的集成。就是要解决在企业内部的业务流程和数据流量的问题。就是维持数据正确而自动的流转。从应用和技术上综合考虑，EAI分为界面集成、平台集成、数据集成、应用集成和过程集成。
   
   • 界面集成。是比较原始和最浅层次的集成，又是常用的集成。这种方法就是把用户界面作为公共的集成点，把原有零散的系统界面集中在 一个新的、通常是浏览器的界面之中。
   • 平台集成。这种集成要实现系统基础的集成，使得底层的结构、软件、硬件及异构网络的特殊需求都必须得到集成。平台集成要应用一些过程和工具，以保证这些系统进行快速安全的通信。
   • 数据集成。为了完成应用集成和过程集成，必须首先解决数据和数据库的集成问题。在集成之前，必须首先对数据进行标识并编成目录，另外还要确定元数据模型，保证数据在数据库系统中分布和共享。
   • 应用集成。这种集成能够为两个应用中的数据和函数提供接近实时的集成。
   • 过程集成。当进行过程集成时，企业必须对各种业务信息的交换进行定义、授权和管理，以便改进操作，减少成本，提高响应速度。过程集成包括业务管理、进程模拟等，还包括业务处理中每一步都需要的工具。
2. 企业间应用集成。

3. 集成技术的发展展望

目前市场主流的集成模式由三种，分别是面向信息的集成技术、面向过程的集成技术和面向服务的集成技术。

在数据集成的层面上，信息集成技术仍然是必选的方法。信息集成采用的主要数据处理技术有数据复制、数据集合和接口集成等。其中，接口集成通过一种集成代理的方式实现集成，即为应用系统创建适配器作为自己的代理，适配器通过其开放或私有接口将信息从应用系统中提取出来，并通过开放接口与外界系统实现信息交互。

面向对象的集成技术其实是一种过程流集成的思想，不需要处理用户界面开发、数据库逻辑、事务逻辑等，而只是处理系统之间的过程逻辑，与核心业务逻辑相分离。在结构上，面向过程的集成方法在面向接口的集成方案之上，定义了另外的过程逻辑层；而在该结构的底层，应用服务器、消息中间件提供了支持数据传输和跨过程协调的基础服务。对于提供集成代理、消息中间件及应用服务器的厂商来说，提供用于业务过程集成是对产品的拓展，也是目前应用集成市场的重要需求。

14.4.7 供应链管理

1. 供应链管理的定义

SCM的核心是供应链。供应链是指一个整体的网络，用来传送产品和服务，从原材料开始一直到最终客户（消费者），它凭借着一个设计好的信息流、物流和现金流来完成。现代意义的供应链是利用计算机网络技术全面规划供应链中的商流、物流、信息流、资金流等并进行计划、组织、协调和控制。

供应链有两层含义，一层含义是任何一个企业内部都有一条或几条供应链，包括从生产到发货的各个环节；另一层含义是一个企业必定处在市场更长的供应链之中，包括从供应商的供应商到顾客的顾客的每一个环节。

供应商管理是从源头供应商到最终消费者的集成业务流程。供应链管理至少包括以下六大应用功能：需求管理（预测和协作工具）、供应链计划（多工厂计划）、生产计划、生产调度、配送计划、运输计划。

2. 供应链和物流

供应链管理是一种管理方法或思想，而物流是在现实经营活动中的物质活动，供应链管理思想是从物流管理的实践中提取出来的，管理的对象是物流；物流分为采购物流、生产物流、销售物流，而供应商管理将这些全部纳入到一个管理体系之中。在供应商、分销商、零销商之间搭建起一个流畅的平台，建立起一个信息共享的机制，从而优化整个供应链，达到降低成本、提高效率等目的。

3. 供应链管理是一种管理思想

4. 供应链管理的运作模式

同一的信息系统架构是决定信息能否共享的物质技术基础，主要包括：为系统功能和结构建立统一的信息交流规范体系等。因为即使某些细节之处没有遵循共同的标准，也会影响到数据交流和信息共享。

14.4.8 电子商务概述

1. 什么是电子商务

EC是指买卖双方利用现代开放的Internet，按照一定的标准所进行的各类商业活动。主要包括网上购物、企业之间的网上交易和在线电子支付等新型的商业运营模式。

电子商务氛围三个方面：即电子商情广告、电子选购和交易及电子交易平衡的交换、电子支付与结算及网上售后服务等

参加电子商务的实体有四类：顾客（个人消费者或集团购买）、商户（包括销售商、制造商、储运商）、银行（包括发卡行、收单行）及认证中心。

2. 电子商务的类型

1. 企业与消费者之间的电子商务B2C。
2. 企业与企业之间的电子商务B2B
3. 消费者与消费者之间的电子商务C2C
4. O2O即在线离线/线上到线下。是指将线下的商务机会与互联网集合，让互联网称为线下交易的平台。

14.6 知识管理与商业智能

14.6.1 知识管理

1. 知识管理的概念

在组织中建构一个人文与技术兼备的知识系统，让组织中的信息与知识，通过获得、创造、分享、整合、记录、存取、更新等过程，实现不断创新。同时，这种创新知识又不断回馈到组织之内，从而使组织的知识不间断的累积和升华，进而转化为企业的智慧资本。

2. 知识管理的工具和手段

知识管理工具是实现知识的生成、编码和转移技术的集合。知识管理工具主体是以计算机为基础的技术集合，同时也包括传统的知识管理工具。

1. 知识管理工具的范畴

基于计算机技术的管理工具分为三类：数据管理工具、信息管理工具、知识管理工具。

数据管理工具的管理对象是数据，手工数据等，基于计算机技术的有数据库、数据仓库、搜索引擎、数据建模工具等。

信息管理工具的管理对象是信息。

知识管理工具的管理对象是知识。

2. 知识管理工具的分类

从企业中知识的生命周期来看，知识管理可以分为知识的生成、知识的编码和知识的转移。相应的，知识管理工具也分为三类：即知识的生成、编码和编译工具。

1. 用于知识生成的工具
2. 用于知识编码的工具
3. 用于知识转移的工具

3. 对知识管理工具的评价

1. 功能不完整
2. 集成度不高
3. 协同性不够
4. 可重构性差

14.6.2 商业智能

BI是企业对商业数据的搜集、管理和分析的系统过程，目的是企业的各级决策者获得知识和洞察力，帮助他们做出其他对企业更有利的决策。

商业智能系统主要实现将原始业务数据转换为企业决策信息的过程。与一般的信息系统不同，他在处理海量数据、数据分析和信息展现多个方面都具有突出性能。

商业智能系统主要包括数据预处理、建立数据仓库、数据分析及数据展现4个主要阶段。数据预处理是整个企业原始数据的第一步，它包括数据的抽取、转换和装载三个过程。建立数据仓库则是处理海量数据的基础。数据分析是体现系统智能的关键，一般采用联机分析处理和数据挖掘两大技术。联机分析处理不仅进行数据汇总/聚集，同时还提供切片、切块、下钻、上卷和旋转等数据分析功能，用户可以方便对海量数据进行多维分析。数据挖掘的目标则是挖掘数据背后隐藏的知识，通过关联分析、积累和分类等方法建立分析模型，预测企业未来发展趋势和将要面临的问题。在海量数据和分析手段增多的情况下，数据展现则主要保障系统分析结果的可视化。

14.7 业务流程重组

1. BPR的概念

所谓业务流程，是指为了完成某一目标或任务而进行的一系列跨越时空的逻辑相关活动的有序集合。

2. BPR的内容

1. 根本性。强调要进行根本性的再思考，各方面都要关注流程，因为他还是企业的核心流程
2. 彻底性。是要求对BPR进行追根溯源，对既定存在的时候不是小修小补，而是要进行彻底的改造。
3. 戏剧性。表名BPR完全抱起传统管理挂念，不是追求稍有改善，而是充分强调结果的满意度；在衡量员工的业绩标准上，BPR注重员工创造的价值，倡导创新，这与传统的“多劳多得”有本质的不用；BPR彻底否定企业中大量的低效劳动和无效监督控制；另外，员工的晋升是靠综合能力而非一时的工作业绩。
4. 流程。主张不是企业的业务流程的简单改善，而是要创建全新的组织结构，打破以专业分工理论为基础的职能部门管理框架，建立以流程工作小组为单元的管理模式，形成扁平式管理机构，大大压缩了管理层级，不但提高了管理效率，增强组织柔性，而且节约了中间管理层所产生的巨额费用。

3. BPR的作用

1. BPR的实施使企业更贴近市场。
2. BPR使生产成本成倍压缩。
3. BPR使产品质量得到全面提升
4. 服务质量更趋完美

4. BPR遵循的原则

1. 流程中心原则
2. 团队管理原则
3. 客户导向原则

第十五章 基于中间件的开发

15.1 中间件技术

中间件是基础软件的一大类，属于可复用软件的范畴。中间件处在操作系统、网络和数据库之上，应用软件的下层。

15.1.1 中间件的概念

中间件应具有如下的一些特点：

• 满足大量应用的需要
• 运行于多种硬件和OS平台
• 支持分不计算，提供跨网络、硬件和OS平台的透明性的应用或服务的交互
• 支持标准的协议
• 支持标准的结构

中间件的十大优越性

• 缩短应用的开发周期
• 节约应用的开发成本
• 减少系统初期的建设成本
• 降低应用开发的失败率
• 保护已有的投资
• 简化应用集成
• 减少维护费用
• 提高应用的开发质量
• 保证技术进步的连续性
• 增强应用的生命力

15.1.2 中间件的分类

1. 通信处理（消息）中间件。
2. 事务处理（交易）中间件
3. 数据存取管理中间件
4. Web服务器中间件
5. 安全中间件
6. 跨平台和架构的中间件
7. 专用平台中间件
8. 网络中间件。

15.1.3 中间件产品介绍

1. IBM MQSeries

2. BEA Tuxedo

15.2 应用服务器技术

15.2.1 应用服务器的概念

并非一种传统意义上的软件，而是一个可以提供通过Internet来实施电子商务的平台。而且拥有极高的稳定性、可扩展性和安全性，它能够；

1. 更合理的分工企业级应用开发，加快应用的开发速度，减少应用的开发量。
2. 应用设计、开发、部署、运行、管理、维护的平台。应用服务器既是应用开发的平台，包括表示层、应用层和数据层的设计模式和编程环境；同时又是多层结构应用中的部署、运行平台，对多层结构应用进行配置、启动、监控、调整，并在开发的不同阶段承担不同的职责。
   
   • 设计：应用服务器完成底层通信、服务、并屏蔽掉复杂的底层技术细节，向用户提供结构简单、功能完善的编程接口，让用户可以专心于商务逻辑的设计。
   • 开发：应用服务器提供了完全开放的编程语言和应用接口，用户可以用任何自己习惯的开发工具来工作，另外应用服务器自己也提供快速开发的工具和手段，帮助用户提高开发效率。
   • 部署：应用服务器可以部署在任何硬件平台、任何操作系统上，而且可以分布在异构网络中，应用服务器帮助用户在复杂的网络环境中配置系统参数，使系统发挥最大的性能，拥有最好的稳定可靠性。
   • 运行：应用服务器采用的是开放技术标准，它提供了一个完整的标准实现，即提供了系统的运行环境，任何基于同样标准的系统都能很好的运行与这个环境中。在运行中提供应用系统的名字解析、路由选择、负载平衡、事务控制等服务，并提供系统容错、修复、迁移、升级扩展等功能。
   • 管理：应用服务器让用户通过图形化的界面方便的管理自己的资源，而且在系统运行时也能动态的监控和管理。
3. 使得应用与底层平台无关。
4. 为企业引用提供现成的、稳定而强健的、灵活的、成熟的基础架构。应用服务器通过分布式体系来保障系统提供24小时不间断的服务，在大负荷量和长时间运转情况下的稳定性，表现为：
   
   • 当系统处理能力不够使，可以通过简单的增加硬件来解决。
   • 动态调整不同主机间的负载可以最大的利用系统资源，同时提高单机的稳定性
   • 当系统中的某台机器出现故障时，它的工作可由其他机器来承担，不会影响整个系统的运行，即无丹丹故障。

15.2.2 主要的应用服务器

15.3 J2EE

J2EE是针对Web Service、业务对象、数据访问和消息报传送的一组规范。J2EE注重两件事，一是建立标准，使Web应用的部署和服务器无关；二是使服务器能控制构件的生命周期和其他资源，以便能够处理扩展、并发、事务处理管理和安全性问题。

15.3.1 表示层

分布式企业应用可以同时包括多种客户端，并且这些客户端都可以访问相同的业务逻辑。当客户端是HTML时，JSP/Servlet组合将成为能实现业务目标的真正客户端。当客户端是Java程序或基于COM程序时，他可以直接访问业务逻辑。

15.3.2 应用服务层

一般情况下，应用服务器层包含表示层请求的表示逻辑和业务逻辑，表示层由显示HTML页面的JSP页面和Servlets实现。业务逻辑通过RMI对象和EJB实现。EJB依靠容器来实现事务处理、生命周期和状态管理、资源池、安全等问题。容器是EJB运行的环境。

1. Servlet

是指可以扩展Web服务器功能的程序，Servlet从客户端接受请求，动态生成响应，然后将包含HTML或XML文档的请求发送给客户端。Servlet类似于CGI（公共网关接口），但Servlet使用Java类和流，更易于编写；由于Servlet可编译为Java字节码，在运行时，Servlet例程驻留在内存中，每一个用户请求都生成一个新线程，故而他们的执行速度也更快。

2. JSP

JSP页面是基于文本的Servlet开发方式。JSP页面具有Servlet的所有优点，如果与JavaBeans类结合在一起，合一很容易的将内容和显示逻辑分开。这使得无需了解Java代码就能更新页面的外观，更新JavaBeans的人也无需深入了解Web页面的设计。相对CGI而言，由于CGI依赖于平台，小号资源更多，而且程序不能容易的访问参数数据等缺点，故而JSP页面和Servlet都比CGI应用广泛。

3. EJB

EJB构件用于封装业务逻辑，使开发人员无需再担心数据访问、事务处理支持、安全性、高速缓存和并发等琐碎任务的编程。在EJB规范中，他们由EJB容器负责。EJB包含接口和类。客户端通过EJB的本地接口和编程接口访问EJB方法。本地接口提供的方法可以用于生成、删除和查找EJB ，远程接口则提供业务方法。部署时，容器从这些接口生成类，这些类使客户端可以访问、生成、删除、查找和调用EJB上的业务方法。EJB类为业务方法、生成方法和查找方法提供实施，如果Bean管理自己的存储，还得提供生成生命周期方法的实施。

EJB共有三种类型，具体如下

1. EntityBean 实体Bean。表示数据库中的数据及作用于数据的方法。实体Bean是具有持久性的事务处理型EJB，只要数据存在于数据库中，实体Bean就存在。
2. SessionBean 会话Bean。代表与客户间的短暂对话。在执行数据库读写时，会话Bean可以请求JDBC调用，也可以使用实体Bean执行调用，这时会话Bean是实体Bean的客户端。会话B二胺的字段中包含对话的状态，如果服务器或客户端出现故障，会话Bean将消失
   会话Bean可以有状态，也可以无状态。有状态会话Bean包含客户端方的对话状态。对话状态是会话Bean实例的字段值加上可以从会话Bean字段阅读的所有对象。有状态的会话Bean不表示持久数据库中的数据，但能够以客户端的名义访问和更新数据。
   无状态会话Bean没有客户端的任何状态信息，他们一般不提供保留任何状态的服务器行为。无状态会话Bean需要的系统资源较少。提供通用服务或表示共享数据视图的业务对象适合作为无状态的会话Bean
3. Message Driven Bean 消息驱动Bean。EJB2.0规范中的消息驱动Bean能处理从JMS消息队列中接收到的异步消息。JMS将消息路由到消息驱动Bean，有消息驱动Bean从池中选择某个实例处理消息。

4. JMS

是支持Java程序之间信息交换的J2EE机制。这也是Java支持异步通信的方法——发送者和接收者无需相互了解，因此可以独立操作。JMS支持两种消息传播模式：

1. 点到点。基于消息队列，消息穿绳这将消息发送到队列中。消息消费者可以将自身与队列连接，以倾听消息，当消息到达队列时，客户可以从队列中区中，并给出响应。消息只能发送给一个队列，只能由一个消费者使用。消费者可以过滤消息，以便获得希望获得的消息。
2. 出版和订阅。消息生产者将消息发送到一个话题（topic），注册到此话题的消费者都能接收到这些消息。这种情况下，许多消费者都能接收到同样的消息。

5. JNDI

Java命名和目录接口。客户端和应用代码使用JNDI查找用户定义对象（如EJB）和环境实体。在JDBC2.0中，数据源可以绑定到JNDI上，并允许应用程序访问。

6. 事务处理

J2EE事务处理模型可以在部署过程中定义组成一个事务处理的方法之间的联系，以便事务处理中的所有方法可以作为一个整体存在。如果用户希望完成这一任务，因为事务处理是一系列步骤，要么全部执行成功，要么全部回滚。

事务处理的属性在应用构件的集成过程中确定。他可以将各种方法组合城应用构件间的事务处理，即用户可以在J2EE应用中方便的重新分配应用构件的事务处理属性，无需修改代码和重新编译。J2EE事务处理API（JTA）和Java事务处理服务（JTS）形成J2EE中事务处理支持的基础，而且更适合EJB和JDBC2.0。JTS是低级事务处理管理API，主要作用是将Java映射到对象管理组（OMG）的对象事务处理服务。JTA是高级API，包括两个部分：

• 事务处理接口。允许事务处理定界，通过分布式构件由进行全局事务处理登记来完成工作。这种方法可以另多组操作组成一个事务处理。
• XA资源管理。基于能处理分布式事务处理的X/Open/XA接口，有时也成为两步提交事务处理，需要多种资源之间的协调，如数据库或序列。分布式事务处理由两步提交协议协调，可跨越用XA兼容的JDBC驱动程序访问的多个数据库。

15.4 .NET

15.4.1 .NET平台

.NET平台包括4个重要特点：

1. 软件变服务
2. 基于XML的共同语言
3. 融合多种设备和平台
4. 新一代的人机界面

15.4.2 .NET框架

1. 通用语言运行时 CLR

为多种语言提供了统一的运行环境。

基于通用语言运行时开发的代码称为受控代码。它的运行步骤大体如下：首先使用一种语言运行时支持的语言编写源代码，然后使用针对通用语言运行时的编译器生成独立于机器的微软中间语言MIL，同事产生运行所需的元数据，在代码运行时再使用即时编译器JITC生成相应的机器代码来执行。

2. 基础类库

包括从输入输出到数据访问等方面，提供了一个统一的面向对象的、层次化的、可扩展的编程接口。

3. ADO.NET

访问数据库的技术。

4. ASP.NET

网络编程结构。可以从以下几个方面了解ASP.NET：

1. Web表单。目的是使开发者能够非常容易的创建Web表单。
2. ASP.NET Web服务器。
3. ASP.NET应用框架

5. WinForms

6. 开发语言

7. 其他特征

15.5 企业应用集成 EAI

EAI是指通过将业务流程，应用软件、硬件和各种标准联合起来，对企业中完成不同业务功能的应用系统进行无缝集成，使他们想一个整体一样进行业务处理和信息共享，从而提高企业效率，为客户提供灵活的业务服务。

EAI可以通过中间件技术来连接企业级各种应用，使异构应用系统之间能够相互“交流”与“协作”

首先，中间件产品对各种硬件平台、操作系统、网络数据库产品及客户端实现了兼容和开放

其次，中间件保持了平台的透明性，使开发者不必考虑操作系统的问题。

第三，中间件实现了对交易的一致性和完整性的保护，提高了系统的可靠性

第四，中间件产品可以缩短开发周期50%~75%，从而大大降低了开发成本，提高了工作效率

EAI包括的内容个很复杂，涉及结构、硬件、软件及流程等企业系统的各个层面，根据EAI集成的深度来划分可以分为应用集成、业务过程集成、数据集成。

1. 应用集成

主要为两个以上的应用中的数据和函数提供接近实时的集成。在网络环境中的跨平台应用程序之间的应用到应用的集成。应用层次的集成一般来说是通过处理多个应用系统之间的消息交换，实现系统间的集成，各个应用能够处于同步模式，即基于客户（请求程序）和服务器（响应程序）之间的请求响应交互机制。应用系统能够自己处理消息的转换，并且它将影响被集成系统的数据转换和有效性。但是，这需要对系统进行修改以建立发送和接收消息的接口。

2. 业务过程集成

需要处理企业范围内的业务过程和把企业存在的应用系统整合到这些业务过程中。

当对业务过程进行集成的时候，企业必须在各种业务想听中定义、授权和管理各种业务信息的交换，以便改进操作、减少成本、提高响应速度。业务过程集成包括业务管理、进程模拟，以及综合任务、流程、组织和进出信息的工作流，还包括业务处理中每一步都需要的工作。业务过程集成至少包括以下两种形式的流程。

1. 交互式流程。包含了跨两个系统之间的事务处理。这种流程是完整的且不间断的，不包含任何需要人为参与的工作和间断的流程。
2. 多步流程。多步流程有系列的步骤并同多个系统相关，能在一定时间内完成。这种流程可以是一对多、多对一或多对多的关系。

3. 数据集成

要完成应用集成和业务过程集成，必须首先解决数据和数据库的继承问题。

15.6 轻量级架构和重量级架构

15.6.1 Struts框架

是一个基于SUN J2EE平台的MVC框架，主要是采用Servlet和JSP技术来实现的。

15.6.2 Spring框架

轻量级J2EE应用程序框架。包括声明性事务管理，通过RMI或Web Service远程访问业务逻辑，mail支持工具，一级对于数据库和数据库之间持久层的各种配置的支持。Spring允许自由选择和组装各部分功能，会提供和其他软件集成的接口。

核心本身是一个容器，管理物件的生命周期、物件的组态、相依注入等，并控制物件在创建时是以原型或单例的方式来创建。

核心概念是控制反转IoC，更具体而易懂的名字是依赖注入。Spring的目标是实现一个全方位的整合框架，在Spring框架下实现多个子框架的组合，这些自框架之间可以彼此独立，也可以使用其他的框架方案加以替代。

Spring模块建立在核心容器智商，核心容器定义了创建、配置和管理Bean的方式。Core封装包的主要构件是BeanFactory，它提供对Factory模式的经典实现来消除对程序性单例模式的需要，并真正的允许从程序逻辑中分理处依赖关系和配置。

DAO提供了JDBC的抽象层，它可消除冗长的JDBC编码和解析数据库厂商特有的错误代码。并且，JDBC封装包还提供了一种比编程性更好的声明性事务管理办法，不仅实现了特定接口，而且对所有的POJOs都适用。

ORM框架提供了对象关系映射工具，其中包括JDO（Java持有对象）、Hibernate、Ibstis、JPA（Java持有API）。所有这些都遵从Spring的通用事务和DAO异常层次结构。

Context（上下文）是一个配置文件。Spring的上下文包括企业服务。

Web包提供了基础的针对Web开发的集成特性。当与Web或Struts一起使用Spring时，这个包使Spring可与其他框架结合。

通过策略解耦，MVC框架变为高度可配置的，容纳了大量视图技术。

15.6.3 Hibernate框架

是一种对象和关系之间映射的框架，是Java应用和关系数据库之间的桥梁。可以将数据库资源映射为一个或多个POJO。

在Hibernate中对象/关系映射机制的核心是一个XML文件，通常命名为*.hbm.xml。这个映射文件描述了数据库模式是怎么与一组Java类绑定在一起的。Hibernate提供工具从已有的数据库模式和Java代码生成*.hbm.xml。一旦有了*.hbm.xml文件，就可以生成Java代码，或数据库模式，或两者兼得。

Hibernate只是一个将持久化类与数据库表映射的工具，Hibernate只需要将每个持有化实例对应于数据库表中的一个数据行即可。

15.6.4 基于Struts、Spring和Hibernate的轻量级架构

1. 表示层。由Struts实现，主要完成如下任务：管理用户请求和响应；提供一个控制器代理以调用业务逻辑和各层的锤炼；处理从其它层抛给StrutsAction的异常；为显示提供数据模型；借助Struts Validator框架帮助完成Web层的验证工作。
2. 持久层。有Hibernate实现。通过一个面向对象的查询语言（HQL）正则表达式的API检索对象的相关信息。
3. 业务层。由Spring来实现。优点是：利用延时注入思想组装代码，提高了系统扩展性和灵活性，实现插件式变成。利用AOP思想，集中处理业务逻辑，减少重复代码，构建了较理想的解决方案。

15.6.5 轻量级架构和重量级架构的探讨

第十六章 安全性和保密性设计

信息安全，具体的说就是保证信息的保密性、完整性、真实性、占有性。

保密性是指系统中的信息必须按照该信息的拥有者的要求保证一定的秘密性，不会被未经许可的第三方非法获取。系统必须阻止一些对秘密信息的非授权访问或泄露。

完整性是指系统中的信息应当安全、准确、有效。要求数据不能被非法改动或删除。

真实性是指对信息的发送者身份的确认或系统中有关主题的身份确认，这样可以保证信息的可信度。信息的真实性可以通过数字签名、公钥加密等方式来实现。

占有性是指要报货信息赖以存储的节点、介质、载体等不被盗用或窃取。保护信息占有性的方法有使用版权、专利、商业秘密性，提供物理的或逻辑的存取限制方法，为沪和检查有关窃取文件的记录等。

16.1 加密和解密

密码学是研究加密方法、秘密通信的原理，以及解密方法、破译密码的方法的一门科学。

加密和解密的过程大致如下：首先，信息的发送方准备好要发送信息的原始格式，叫做明文。然后对明文经过一系列变换后形成信息的另一种不能直接体现明文含义的形式，叫做密文。由明文转换为密文的过程叫做加密。在加密时所采用的一组规则或方法称为加密算法。接受者在收到密文后，再把密文还原成明文，以获得信息的具体内容，这个过程叫做解密。解密时也要运用一系列与加密算法相对应的方法或规则，这种方法或规则称为解密算法。在加密、解密过程中，由通信双方掌握的参数信息控制具体的加密和解密过程，这个参数叫做密钥。密钥分为加密密钥和解密密钥，分别用于加密过程和解密过程。

在加密和解密的过程中，如果采用的加密密钥与解密密钥相同，或者从一个很容易计算出另一个，则这种方法叫做对称密钥密码体制，也叫做单钥密码体制。反之，如果加密和解密的密钥并不相同，或者从一个很难计算出另外一个，就叫做不对称密钥密码系统或公开密钥密码体制，也叫做双钥密码体制。

16.1.1 对称密钥加密算法

在这种密码体制中，密码称为整个秘密通信的核心，整个加密通信的安全性完全以密钥的保密为基础。密钥的保密是对称密钥加密体制安全保密的关键，必须脱产保存并经由可靠的渠道传递。

对称密钥加密算法有多种，例如，DES（数据加密标准）、IDEA（国际数据加密算法）、Skipjack、3DES、GDES、New DES、Lucifer、FEAL N、LOKI 91、RC4、RC5等

1. DES算法

过程为：将要加密的明文分成64位的数据段作为输入，在使用根据64位密钥变化生成的52个子密钥，对输入的数据一次进行初始置换、16轮迭代、逆初始置换，然后得到64位密文。

解密过程与加密过程几乎相同，但是子密钥的使用顺序相反。其他算法完全一样。

2. IDEA算法

在加密运算中处理的数据段大小也是64位，但是所用的密钥长度为128位，而且采用更加复杂的加密算法，目的是保证他不会被轻易破解。

IDEA算法对数据的处理是以64位为单位的，在加密前把要加密的明文按每64位作为一个数据段进行分割然后分别加密。

解密过程与加密过程基本相似，所不同的就是解密子密钥的产生方式与加密子密钥的产生方式不一样。解密的其他运算过程同加密一样，也是把64位数据段分成4个16位的数据段，然后经过八轮迭代变换和议论输出变换，就可以得到对应的明文结果。

16.1.2 不对称密钥加密算法

对称密钥加密算法的加密、解密使用同样的密钥，由发送者和接收者同时保存，在加密和解密时使用相同的密钥。采用这种方法的主要问题是密钥的生成、导入、存储、管理、分发等过程比较复杂，特别是随着用户的增加，密钥的需求量成本增加，而在较大国模的信息系统中，大量密钥的分配与管理是一个难以解决的问题。

不对称密钥加密技术在对信息进行加密和解密时，需要分别采用两个不同的密钥，因此也成为双钥加密方法。它在运算中，先产生一对密钥，其中之一是保密密钥，由用户自己保存，不能向外界泄露，简称私钥；另一个为公开密钥，可对外公开，甚至可以在公共目录中列示，简称公钥，因此也成为公开密钥加密方法。

只有通过私钥才能解密用公钥加密的数据，同时使用私钥加密的数据只能使用公钥解密。

1. RSA加密过程

2. RSA数字签名

16.2 数字签名与数字水印

散列函数是一种公开的数学函数，运算的输入信息也可叫做报文，算列函数运算后所得到的结果成为散列码或者叫做消息摘要。三列函数具有如下一些特点：

1. 不同内容的报文具有不同的散列码，而一旦原始报文有任何改变，哪怕是改变一位信息，则通过散列函数计算后得到的散列码也将完全不同
2. 散列函数是单向的，即求解某一个报文的散列码非常容易，但是根据散列码来倒推原始报文是非常困难的。
3. 对于任何一个报文，无法预知它的散列码
4. 散列码具有固定的长度，不管原始报文的长度如何，通过散列函数运算后的散列码都具有一样的长度。

由于散列函数具有这些特征，因此散列函数可以用来检测报文的可靠性。接收者对收到的报文用与发送者相同的散列函数进行运算，如果得到与发送者相同的散列码，则可以认为报文没有被篡改，否则，报文就是不可信的。

常见的散列函数有MD5、SHA、HMAC等。

16.2.1 数字签名

主要由两个算法组成：签名算法和验证算法。通过使用签名算法签名一个消息，所得到的签名都能够通过一个验证算法来验证签名的真实性和有效性。

大致过程就是：信息的发送方对信息利用自己的私钥进行签名，接着发送方吧这个签名和信息一起发送给接收方。接收方瘦到信息后利用发送方的公钥来对其中的数字签名进行验证，确认其合法性。

1. RSA结合MD5数字签名

通过散列算法对原始数据进行散列，再对散列码进行共要加密就可以很好的实现数字签名，它的特点是：代表了文件的特征，具有唯一性。只要文件发生哪怕一位数据的改变，或者签名者有任何差别，数字签名的值也将随之而发生改变；不同的文件和签名者得到的是不同的数字签名。

RSA结合MD5数字签名的主要过程是：信息的发送方通过对信息进行散列运算生成一个消息摘要，接着发送方用自己的私钥对这个消息摘要进行加密，就形成发送方的数字签名。然后把这个数字签名作为信息的附件和信息一起发送给信息的接收方。接收方收到信息后，首先对瘦到的信息进行与发送者相同的散列运算得到一个消息摘要，接着再用发送方的公钥来对信息中附加的数字签名进行解密得到发送方计算出的散列码。如果两个散列码相同，那么接收方就能确认该信息和数字签名是由发送方发出的。通过数字签名能够实现对原始信息完整性的鉴别和发送方发送信息的不可抵赖性。

RSA用于数字区签名的一个重要的特点是能够证实信息发送发的身份及电子文件的可靠性和完整性，它对发送方和被发送方的信息都是独一无二的，具有可验证性和不可否镇的权威性等特点；另一个重要的特点是他通过在计算机之间交换数字证书就可以确定当事者就是他们所宣称的人。

2. 数字签名标准

DSS是美国国家标准与技术学位的数字签名标准。DSS为计算和验证数字签名指定了一个数字签名算法——DSA。DSA通过选择较小规格的参数减少数字签名的数据量，从而减少了存储空间和传输带宽。

DSS中指定SHA作为其散列算法，它对原始信息进行计算后产生160位的消息摘要，然后DSS把这一消息摘要与一个用作这个特殊签名的随机数作为输入送到数字签名算法中，经过运算生成数字签名。

16.2.2 数字新房

数字信封是公钥密码体制在实际中的一个应用，是用加密技术来保证只有规定的特定收信人才能阅读通信的内容。

在数字信封中，信息发送方采用对称密钥来加密信息内容，然后将此对称密钥用接收方的公开密钥来加密（这部分称数字信封），之后，将它和加密后的信息一起发送给接收方，接收方先用相应的私有密钥打开数字信封，得到对称密钥，然后利用对称密钥解开加密信息，这种技术的安全性相当高。

16.3 数字证书和密钥管理

16.3.1 密钥分配中心

一个方法是在一个信息系统中任意两个用户之间自己协商来选择不同的秘钥。

显然，对于有N个用户的这种通信系统中，每个用户需要保存（N-1）个秘钥，系统中总共要保存N*（N-1）/2个秘钥。在用户数量较少时，这样分配秘钥还比较简单、易用的，但是一旦用户多起来，系统中要保存的秘钥会急剧增多，让每个用户自己高效、安全的管理数量庞大的秘钥实际上是不可能的。

此外有一种非常有效的密钥自动分配方案是密钥分配中心（KDC）技术。

在KDC方案中，每一个用户都只保存自己的私钥SK和KDC的公钥PK，而在通信时在经由KDC获得其他用户的公钥PK或者紧紧在某一次通信中可以使用的对称秘钥加密算法的临时密钥K。

16.3.2 数字证书和公开密钥基础设施

公钥加密算法的密钥分配和对称密钥加密算法中密钥的分配要求有着很大的区别。在对称密钥加密体制中，要求将密钥从一方传送到另一方，并且保证只有通信的双方知道密钥，而不让其他任何一方知道密钥。

而在公钥加密体质中，则要求通信各方的私钥只有通信的一方知道，而其他任何一方都不能知道，同时每一方的公钥需要公开，其他任何一方都可以查看和提取。

在公钥加密体质中，私钥的分配相对容易，但是，公钥的发布和获取就需要采取合适的方法来进行，否则就很容易留下安全漏洞。

数字签名和公钥加密都存在这样的问题：如何保证公开密钥的持有者是真实的；大规模信息系统环境下公开密钥是如何产生、分发和管理的。要解决上述问题，就要用到数字证书和PKI（公开密钥基础设施）。

1. 数字证书

提供了一个在公钥和拥有相应私钥的实体之间建立关系的机制。

采用公钥体制，即利用一堆互相匹配的秘钥进行加密、解密。每个用户自己保存私钥，用它进行解密和签名；同时设定一个公钥，并由本人公开，为一组用户所共享，用于加密和验证签名。

数字证书的内容一般包括：唯一标识证书所有者的名称、唯一表示证书签发者的名称、证书所有者的公开密钥，证书签发这的数字签名、证书的有效期及证书的序列号等。

2. 公共密钥基础设施建设

PKI在系统中的作用就箱单股作为公共设施在社会生活中的作用，其目标是向广大的信息系统用户和应用程序提供公开密钥的管理服务。PKI是指由数字证书、证书颁发机构CA、以及对电子交易、通信等所涉及的各方的合法性进行检查和验证的其他注册机构组成的一套系统。

除了数字证书的有效期，证书撤销列表CRL是另一种数字证书有效期控制机制。当数字证书中认可的事实发生变化时，数字证书发布者必须使用某种机制来撤销以前发出、但现在失效的证书。证书发布者定期发布CRL，列出所有曾发布但当前已被撤销的证书号，证书的使用者依据CRL即可验证某证书是否已被撤销。

1. PKI的结构模型。PKI中油三类实体：管理实体、端实体和证书库。管理实体是PKI的核心，是PKI服务的提供者；端实体是PKI的用户，是PKI服务的使用者；证书库是一个分布式数据库，用于证书和CRL的存放和检索。
   CA和注册机构RA是两种管理实体。CA是PKI框架中唯一能够发布和撤销证书的实体，维护证书的生命周期；RA负责处理用户请求，在验证了请求的有效性后，代替用户向CA提交。RA可以单独实现，也可以合并在CA中实现。作为管理实体，CA和RA以证书方式向端实体提供公开密钥的分发服务。
   持有者和验证者是两种端实体。持有者是证书的拥有者，是证书所声明的事实上的主体。持有者向管理实体申请并获得证书，也可以在需要时请求撤销或更新证书。持有者使用证书声明自己的身份，从而获得相应的权利。验证者确认持有者所提供的证书的有效性和对方是否为该证书的真正拥有者，只有在成功鉴别之后才可与对方更进一步的交互。
   证书库可以用Web、FTP或目录等来实现。由于证书库中存取的对象是证书和CRL，其完整性由数字签名保证，因此对证书库的操作可以在无特殊安全保护的通道上传输。
   不同的实体间通过PKI操作完成证书的请求、确认、发布、撤销、更新和获取等过程。PKI操作分成存取操作和管理操作两类。其中，存取操作包括管理实体或端实体，吧证书和CRL存放到证书库，从证书库中读取证书和CRL；管理操作这是管理实体和端实体之间或管理实体与管理实体之间的交互，是为了完成证书的各项管理任务和建立证书链。
2. PKI层次模型。PKI框架可以分为三个层次。最底层为传输层，向上提供PKI报文的可靠传输，它可以使传输层协议或应用层协议。中间层是密码学服务层，向上提供加密、解密、数字签名、消息摘要等基本面膜学服务，可由RSA、MD5等方法实现。最高层是证书服务层，使用前面两层提供的加密和传输服务，向用户提供证书的请求、签发、发布、撤销和更新等服务。
   PLI的三类实体对这三层服务的使用各不相同。证书库不需要特殊的安全交互措施，所以进使用传输层服务来分发证书和CRL；管理实体和端实体使用证书服务器层构造PKI证书，使用密码学服务层来鉴别和保护交互信息，使用传输层服务传送信息。
3. X.509数字证书。具有如下一些突出的特点：
   
   • 支持多种算法。
   • 支持多种命名机制
   • 可以限制证书（公开密钥）的用途。
   • 定义证书遵循的策略
   • 控制信任关系的传递。

16.4 安全协议

16.4.1 IPSec协议简述

该协议把密码技术应用在网络层，以向信息的发送方和接收方提供源地址验证、数据传输的完整性、存取控制、保密性等安全服务，保护通信免造窃听、抵御网络攻击，而且更高层的应用层协议也可以直接或间接的使用这些安全服务，为其上层协议如TCP、UDP等提供透明的安全保护服务。

在IPv6中，IPSec协议是一个必备的组成部分，被强制实施；在IPv4中，它是一个可选的扩展协议。

IPSec协议对数据的加密以数据包而不是整个数据流为单位。

IPSec协议的基本工作原理是：发送方在发送数据前对数据实施加密，然后把密文数据发送到网络中区，开始传输。在整个传输过程中，数据都是以密文方式传输的，知道数据到达目的节点，才由接收方对密文进行解密，提取明文信息。

IPSec协议对网络层的通信使用了加密技术，它不是加密数据包的头部和尾部信息（如源地址、目的地址、端口号、CRC校验值等），而是对数据包中的数据进行加密。由于加密过程中发生在IP层，因此可以在不改变HTTP上层应用协议的情况下进行网络协议的安全加密，为通信提供透明的安全传输服务。

IPSec不是一个单独的协议，它包括应用于IP层上网络数据安全的一整套协议、主要包括IP认证头部协议AH、封装安全负载协议ESP、密钥交换协议IKE和用于网络认证及加密的一些算法等。

AH提供数据的完整性和认证，但不包括保密性；而ESP原则上只提供保密性，但也可以在ESP Header中选择适当的算法及模式来实现数据的完整性和认证。AH和ESP可分开使用也可以一起使用。IKE则提供加密算法、密钥等的协商。

1. 安全关联和安全策略

安全关联SA是指提供通信安全服务的发送方和接收方之间的一种单向关系。安全关联是构成IPSec的基础，它是进行通信的双方经协商建立起来的一种协定。安全关联的内容包含了IP数据包是否加密、认证，以及加密、认证采用的算法、密钥等相关信息。所有的SA记录都存放在安全关联数据库中，按散列方式存取。

安全策略定义了两个IPSec系统之间的安全通信特征，并决定在该通信中为数据包提供的安全服务。一个IPSec系统的所有安全策略都存放在安全策略数据库中，根据选择符进行检索。安全策略通常与SA合作，共同作用于通信的数据包。

2. AH

AH协议先将数据进行校验和加密，然后封装为IP包，从而实现无连接通信的数据完整性、数据源认证和防止重放攻击。AH能完成出数据加密外的所有ESP所能提供的工鞥呢。在认证机制上，它所覆盖的范围比ESP的广，包括对IP头中一些选项的认证。

AH使用的典型的认证算法是一种迭代型的消息摘要算法。AH中采用MD5算法，可以提供完整性服务。

3. ESP

通过对数据包的数据进行加密来提供传输数据的保密性，从而实现了数据完整性、数据源认证、数据保密性的安全服务。ESP是一个通用的、可扩展的安全机制，其加密认证算法主要由SA的相关数据项决定。接收者也可以通过在瘦到数据后检验数据包中的单向递增的序列号来确定数据包的合法性，防止重放攻击。

4. IP密钥交换

IKE是一个混合协议，使用了Internet安全关联和密钥管理协议ISAKMP、密钥确定协议Oakley和描述支持匿名和快速密钥刷新的密钥交换的SKEME协议。IKE除了实现通信双方的密钥交换，还是用ISAKMP实现IPSec的安全关联。

5. IPSec的工作模式

工作模式有两种：传输模式和隧道模式

传输模式首先将要传送的数据使用IPSec加密封装起来，再把相关的IPSec头插入IP头和被保护的数据之间封装起来。因为IP头没有加密，接收端收到封装的数据包时直接处理IP头，然后从IPSec头中读取SPI值得到相对的SA，在利用SA所定的解密参数解出所加密的数据。

在传输模式中，解密者就是目的地址端的使用者。

隧道模式首先使用SA的相关信息将IP的数据包全部加密，接下来在前面加上ESP Header，然后把它们作为数据为他们在加上一个新的IP头。接收端收到ESP封包后，使用ESP Header内容中的SPI值提供的SA，然后解出ESP Header后的装载数据，就可以取回原始的IP头与封包。

隧道模式可以在两个终端之间建立一个安全的隧道，经由这两个终端之间的通信均在这个隧道中进行，因此安全性较高。

16.4.2 SSL协议

SSL是用于安全传输数据的一种通信协议。采用公钥加密技术、对称密钥加密技术等保护两个应用之间的信息传输的机密性和完整性。但是SSL有一个不足，就是它本身不能保证传输信息的不可否认性。

SSL协议包括服务器认证、客户认证、SSL链路上的数据完整性、SSL链路上的数据保密性等几个方面，通过在浏览器和Web服务器之间建立一条安全的通道来保证Internet数据传递的安全性。

通过SSL建立的传输通道具有如下的基本安全性：

1. 通道是保密的，经过握手确定密钥之后，所有的消息被加密。
2. 通道是被认证的，通信中的服务器总是被认证，客户端可选认证。
3. 通道是可靠的，用MAC对传送的消息进行完整性检查，保证通道上数据的完整性。

SSL协议由SSL记录协议、SSL握手协议、SSL密码变更说明协议、SSL警告协议等组成。

1. SSL记录协议

在SSL记录协议中，所有要传输的数据都被封装在记录中，记录是由记录头和长度不为0的记录数据组成的。所有的SSL通信，包括握手消息、安全空白记录、应用数据等都需要使用SSL记录。

2. SSL协议记录头格式

包括的数据有记录头长度、记录数据长度、记录数据中是否有粘贴数据等。

3. SSL记录数据的格式

SLL记录数据包含三个部分：MAC数据和实际数据和站忒数据。

MAC数据哟鲸鱼数据完整性检查。计算MAC所用的散列函数由握手协议中的消息确定

4. SSL握手协议

建立在SSL记录协议智商，用于在实际的数据传输开始前，通信双方进行身份认证、协商加密算法，交换加密密钥等。SSL握手的过程可以分为两个阶段，第一阶段用于建立秘密的通信信道，第二阶段用于客户验证。

在SSL协议中，同时使用了对称密钥加密算法和公钥加密算法。SSL使用公钥加密算法使服务器端身份在客户端得到验证，并且传递用于绘画中对数据加密的对称密钥。然后再利用对称密钥在通信过程中对收到和发送的数据进行比较快速的加密，从而减小系统开销，保证通信效率。

16.4.3 PGP协议

是一套电子邮件加密方案，可以用来对邮件加密以防止非授权者阅读，还能对邮件加上数字签名而使收信人可以确认邮件确实是由发送方发出的。

PGP并不是新的加密算法或协议，它综合采用了多种加密算法。

1. PGP加密的原理

假设一个用户A想要发送一个加密的邮件给另一个用户B，那么加密的过程如下：

首先，用户A对要发送的邮件P运用MD5散列算法进行计算，生成一个128位的消息摘要，有了这个消息摘要就可以检验邮件信息是否完整、有没有被篡改。然后再通过RSA算法，运用A的私钥SKA对消息摘要进行加密，生成消息摘要的密文H。邮件P与经过加密的邮件摘要信息H共同构成新的报文P1，接着对P1进行ZIP压缩，称为压缩的报文P1.Z。在对P1.Z采用IDEA算法加密，这次加密使用一个一次性的密钥K，并且K必须经过RSA算法使用通信的另一方B的公开密钥PKB加密，与加密后的报文P2一起，在经过BASE64编码，得到一系列ASCII码，作为邮件内容发送到网络上。

用户B接收到A发来的加密的邮件后，执行解密过程：与加密过程相反，首先对邮件内容进行BASE64解码，再利用自己的私密密钥SKB，通过RSA算法解出IDEA的密钥K，再用词密钥会付出P1.Z，对P1.Z进行解压缩后还原出P1。接着把明文P和邮件信息摘要的密文H分离开来，并用A的公开密钥PKA解密H得到真正的邮件消息摘要。然后B自己也运用散列算法MD5对邮件明文P进行运算，生成一个128位的消息摘要，比较这两个摘要是否一致，如果一致，则表明P是A发来的邮件。

2. PGP的密钥管理机制

16.5 计算机病毒与防治

16.5.1 计算机病毒概述

是指编制或在计算机程序中插入的破坏计算机功能或者毁坏数据，影响计算机使用，并能自我复制的一组计算机指令或者程序代码。

1. 计算机病毒的特征

计算机病毒的传染性是指病毒具有把自身复制到其他系统货文件等宿主中区的能力，这是病毒的基本特征。非授权性是指病毒程序的执行不需要得到用户的同一，对用户来说是未知的。潜伏性是病毒生存的必要条件，即病毒潜伏在系统中而不被人们所发觉。破坏性是指病毒在一定条件下可以自动触发，并对计算机实施破坏，是病毒的表现特征。病毒破坏性的触发条件越多，则传染性越强，但同时其潜伏性降低。一个病毒必须具有传染性，但不一定需要拥有其他属性。

2. 计算机病毒的分类

按操作系统分，可分为攻击DOS系统的病毒，攻击Windows系统的病毒、攻击Unix\Linux的病毒、攻击OS/2系统的病毒、攻击Macintosh系统的病毒、攻击手机的病毒，其他操作系统上的病毒

按链接方式分，计算机病毒可分为源码型病毒、嵌入型病毒、Shell病毒、宏病毒、脚本型病毒、操作系统型病毒等。

按照破坏情况分，可分为良性病毒和恶性病毒

按传播媒介分，可分为单机病毒和网络病毒。

3. 计算机病毒的组成

病毒程序一般由传染模块、触发模块、破坏模块和主控模块组成，相应的完成病毒的传染、触发和破坏等任务。

1. 传染模块。是病毒进行扩散传播的模块，负责把计算机病毒从一个系统或文件传播到更多的系统或文件中区。每个病毒都有一个自我识别的标记，叫做传染标记。病毒程序传染系统或文件时，要把该传染标记写入系统或文件中某个特定区域，作为该系统或文件已被传染的标记，以防止重复传染，增强病毒的潜伏效果。传染模块的主要功能有：寻找一个可传染的系统或文件，检查该系统或文件中是否有传染标记，判断该系统或文件是否被传染；如果没有传染标记，则进行传染操作，将病毒代码植入宿主系统或文件内，完成一次传染。
2. 触发模块。主要检查预定触发条件是否满足，如果满足，则调用相应传染或破坏模块，进行传染和破坏动作。
3. 破坏模块。负责实施病毒的破坏动作。该模块有时又被称为表现模块。
4. 主控模块。在总体上控制病毒程序的运行。染毒程序运行时，首先运行的就是病毒的主控模块。

16.5.2 网络环境下的病毒发展新趋势

除了以往通过相互复制文件、系统之间交叉感染等方式外，目前的计算机病毒更多的通过网页、电子邮件、局域网共享、系统漏洞等方式在网络上进行自动传播。

16.5.3 计算机病毒的检测与清除

1. 特征码检测

就是在获取病毒样本后，提取出其特征码，然后通过该特征码对目标文件或内存等进行扫描。如果发现这种特征码，就说明感染了这种病毒，然后针对性的清除病毒。

2. 检验和检测

先计算正常文件的内容和正常的系统山区数据的校验和，将该校验和写入数据库中保存。检测时，检查文件现在内容的校验和与原来保存的是否一致，从而可以发现文件或扇区是否被感染，这种方法成校验和检验。

3. 行为监测

现阶段中被广泛研究和采用的通用病毒检测技术有病毒行为监测技术、启发式扫描技术和虚拟机技术。

常见的病毒行为特征有：对可执行文件进行写操作、写磁盘引导区、病毒程序与宿主程序的切换、程序自己重定位、通过搜索函数索引表来获取API函数地址等。

4. 启发式扫描

主要分析文件中的指令序列，根据统计知识，判断该文件可能被感染或没有被感染，从而有可能找到位置的病毒。因此，启发式扫描技术是一种概率方法，遵循概率理论的规律。

5. 虚拟机

自动变形病毒，也成为多态性病毒或多型（形）性病毒。自动变性病毒每次感染宿主时都会改变自身的程序代码和特征码，这类病毒的代表有“幽灵”病毒等。

虚拟机技术利用软件方法让病毒在一个虚拟的环境中，仿真一部分系统指令和功能调用，对病毒代码做解释执行，而且仿真运行不对系统产生实际的影响，即可获得程序运行的后果，并在此基础上对程序运行进行分析，进而判断是否存在病毒。

6. 病毒的清除

将病毒代码从宿主中取出，使之恢复为可正常运行的系统或程序，称为病毒清除。大多数情况下，采用反病毒软件或采用手工处理方式可以恢复受感染的文件或系统。

16.5.4 计算机病毒的预防

1. 一定要在计算机中安装反病毒软件
2. 不要轻易使用来历不明的或者没有经过确认的软件；
3. 电子邮件的附件应在检查病毒后再开启，并在发送邮件之前检查病毒；
4. 定期使用反病毒软件扫描系统
5. 确保所使用的反病毒软件的扫描引擎和病毒代码库为最新的，因为旧的扫描引擎和病毒代码库不会检查到新出现的病毒
6. 为防止引导型病毒对系统的破坏，应该在系统安装完成后立即只做系统应急启动盘，以便万一硬盘分区表遭到破坏时，能从应急盘启动，并用备份的引导区、分区表等直接进行恢复。
7. 对于一些重要的文件，要定期进行备份，以便万一系统遭受病毒破坏时能够从备份恢复。
8. 利用安全扫描工具定时扫描系统和主机。若发现漏洞，及时寻找解决方案，从而减少被病毒和蠕虫病毒感染的机会。
9. 使用反病毒软件时，最好先查毒，找到带毒文件后，再确定是否进行杀毒操作。
10. 建立本单位的计算机病毒防治管理制度，并对计算机用户进行反病毒培训。

16.6 身份认证和访问控制

访问控制是通过某种途径限制和云秀对资源的访问能力及范围的一种方法。并不能取代身份认证，它是建立在身份认证的基础上的。

访问控制技术包括如下几方面的内容：

1. 用户标识与认证。是一种基于用户的访问控制技术，是防治未经授权的用户进入系统的一种常规技术措施。
2. 逻辑访问控制。是基于系统的访问控制技术，用来控制特定的用户对特定资源的访问
3. 审计与跟踪
4. 公共访问控制

16.6 1 身份认证技术

是对系统的用户进行有效性、真实性验证。

1. 口令认证方式

使用口令认证方式，用户必须具有一个唯一的系统标识，并且保证口令刚在系统的使用和存储过程是安全的，同时口令在传输过程中不能被窃取、替换。另外特别要注意的是在认证前，用户必须确认认证这的真实身份，一方是把口令发给冒充的认证者。

使用口令的单向身份认证过程一般是：请求认证者和认证者之间建立安全连接、并确认认证者身份等；然后请求认证者向认证者发送认证请求，认证请求中心中必须包括请求认证者的ID和口令；认证者接受ID和口令，在用户数据库中找出请求认证的ID和口令；查找是否有此用户并比较两口令是否相同；最后向请求认证者发回认证结果。如果请求者的ID在认证者的用户数据库中，并且请求认证者发送的口令与数据库中相应的口令相同，则允许请求认证者通过认证。

2. 基于公钥签名的认证方式

是通过请求认证者与认证者（对于双向身份很正而言，双方互为请求认证者和认证者）之间对于一个随机数做数字签名与验证数字签名来实现的。这种方式中，认证双方的个人秘密信息不用再网络上传送，从而减少了口令等秘密泄露的风险。

采用数字签名技术认证与口令认证方式有一个很大的不同：口令认证方式通常在正式数据交换开始之前进行。认证一旦通过，双方即建立安全通道进行通信，此后的通信被认为是安全的，不再进行身份认证；而数字签名认证在每一次的请求和响应中进行，即接收信息的一方先从接收到的信息中验证发送者的身份信息，验证通过后才对收到的信息进行相应的处理。

使用公钥加密算法进行身份认证要求：请求认证者必须具有私钥实现数字签名的功能；认证者必须具有使用公钥验证数字签名的功能；认证者必须具有产生随机数的功能，而且随机数的质量必须达到一定要求。

3. 持卡认证方式

最早采用此卡，目前是IC卡。IC卡上一般分为不加密的公共区、加密的数据区等，有些还有自己的操作系统和微处理器。

一般IC卡与用户的个人PIN一起使用。在脱机系统中，PIN以加密的形式存于卡中，识别设备读出IC卡中的身份信息，然后将其中的PIN解密，与用户输入的PIN比较，以决定IC卡持有者是否合法。在联机系统中，PIN可不存在IC卡上，而存在主机系统中，鉴别时，系统将用户输入的PIN与主机的PIN比较，而由此认证其身份的合法性。

4. 基于人体生物特征的认证方式

是指通过计算机，利用人体固有的生物特征或行为特征进行个人身份鉴定。与传统的身份鉴别手段相比，基于生物特征的认证方式具有突出的优点：一是不会遗忘或丢失；二是防伪性能好，无法伪装；三是随时随地可用。能够用来鉴别身份的生物特征一般具有广泛性（每个人都应该具有这种特性）、唯一性（每个人拥有的特征应各不相同）、稳定性（所选择的特征应该不随时间变化而发生变化）和可采集性（所选择的特征应该便于采集、测量）。目前，可用于身份鉴别的生物特征主要有指纹、笔记、脸像、红外温、视网膜、手型、掌纹等。

5. 动态口令技术（一次性口令技术）

一次性口令是动态变化的密码，其变换来源于产生密码的运算因子。一次性口令的产生因子一般都采用双运算因子：一个是用户的私钥，代表用户身份的识别码，是固定不变的。二是变动因子，正是变动因子的不断变化，才能够产生动态的一次性口令。

当密码卡持有者将这个口令输入计算机时，系统中的认证服务器会根据相同的算法和动态因子计算出对应于该密码卡的认证口令，并把这个口令与密码卡产生的口令比对，进行身份真正。

6. PPP中的认证协议

点到点协议PPP提供了一种在点到点链路上封装网络层协议信息的标准方法。也定义了可扩展的链路控制协议。链路控制协议使用验证协议磋商机制，在链路层上传输网络层协议前验证链路的对端。

PPP包含如下几个部分：在串行链路上封装数据报的方法；建立、配置和测试数据链路连接的链路控制协议LCP；建立和配置不同网络层协议的一组网络控制协议NCP。

PPP协议定义了两种验证协议：密码验证协议PAP和挑战——握手验证协议CHAP，此外还有扩展认证协议EAP。

一个典型的PPP链路建立过程分为三个阶段：

1. 创建阶段。在这个阶段，将对基本的通信方式进行选择。链路两端通过LCP向对方发送配置信息，建立链路。在链路创建阶段，只是对验证协议进行选择，具体的用户验证过程在认证阶段实现。
2. 认证阶段。在这个阶段，客户端会将自己的身份发送给远端的接入服务器。该阶段使用一种安全的验证方式避免第三方窃取数据或冒充远程客户接管与客户端的连接。认证成功，则转到网络层协商阶段。如果认证失败，则链路终止。
3. 网络层协商阶段。认证阶段完成之后，PPP将调用在链路创建阶段选定的各种NCP协商高层协议问题。经过三个阶段之后，一条完整的PPP链路就建立起来了。

最常用的认证协议有PAP和CHAP，此外还有EAP

1. PAP。是一种简单的明文验证方式。网络接入服务器要求用户提供用户名和口令，PAP以明文方式返回用户信息，并且对回送或者重复验证和错误攻击没有保护措施。这种验证方式的安全性较差，第三方可以很容易的获取被传送的用户名和口令，并利用这些信息与网络接入服务器建立连接获取网络接入服务器提供的资源。所以，一旦用户密码被第三方窃取，PAP无法提供避免受到第三方攻击的保障措施。
2. CHAP。是一种加密的验证方式，能够避免建立连接时传送用户的明文密码。网络接入服务器向远程用户发送一个挑战口令，其中包括会话ID和一个任意生成的挑战子串。远程客户端使用MD5散列算法返回用户名和加密的挑战口令、会话ID及用户口令。

CHAP验证方式具有如下的优点：

1. 通过可变的挑战口令和随机的、重复的发挑战口令，CHAP防止了重放攻击。
2. 该认证方式依赖于认证这和对端共享的密钥，密钥不是通过链路发送的
3. 虽然该认证是单向的，但是在两个方向都进行CHAP协商，同一密钥可以很容易的实现交互认证。
4. 由于CHAP可以用在许多不同的系统认证中，因此可以用用户名作为索引，以便在一张大型密钥表中查找正确的密钥。这样也可以在一个系统中支持多个用户名——密钥对，在会话中随时改变密钥。

CHAP在设计上的要求

1. CHAP算法要求密钥长度必须至少是1字节，最好是散列算法所所选用的散列码的长度。所选用的散列算法，必须保证从已知挑战口令和响应值来确定密钥在计算上是不可行的。
2. 每一个挑战口令应该是唯一的
3. 每一个挑战口令应该是不可预测的
4. EAP。是一个用于PPP认证的通用协议，可以支持多种认证方法。EAP并不在链路控制阶段而是在认证阶段制定认证方法，这样认证方就可以在得到更多的信息后再确定使用什么认证方法。这种机制还允许PPP认证方简单的把收到的认证信息传给后方的认证服务器，由后方的认证服务器来实真正实现各种认证方法。

7. RADIUS协议

客户/服务器方式的安全认证协议，能在拨号网络中提供注册、验证功能。

该协议把拨号和认证这两种功能放在两个分离的服务器——网络接入服务器NAS和后台认证服务器RADIUS服务器上。在RADIUS服务器上存放有用户名和它们相应的认证信息的一个大数据库，来提供认证用户名和密码及向用户发送配置服务的相关信息。

RADIUS具有非常突出的特点：

1. RADIUS协议使用UDP进行传输，使用1812端口进行认证，以及认证通过后对用户授权，使用1813号端口对用户计费。
2. 支持多种认证方法，RADIUS能支持PAP、CHAP、UNIX Login及其他认证方法；
3. 支持认证转接，一个RADIUS服务器可以作为另一个RADIUS服务器的客户端向它要求认证，这叫做认证转接
4. 协议扩展性好，通过协议中变长的字符串能够进一步扩展RADIUS协议。
5. 认证信息都加密传输，安全性好。RADIUS服务器和接入服务器之间传递的认证信息用一个事先设置的口令进行加密，防止敏感信息泄露，因此安全性高。

16.6.2 访问控制技术

访问控制是在身份认证的基础上，根据不同身份的用户对用户的访问请求加以限制。

在访问控制过程中，一般把发出访问、存取请求的一方叫做主体，二八被访问的对象和资源称为客体。另外还有一套定义主体和客体之间相互关系，确定不同主体对不同客体的访问能力与权限的规则，叫做访问规则。一个完整的访问控制体系就是由上述三方面共同构成的。

1. 访问控制策略

一般可以划分为三类：自助控制访问DAC、强制访问控制MAC、基于角色的访问控制RBAC。

1. DAC。是目前计算机系统中实现最多的访问控制机制。它使主体可以自主的进行配置以决定其他的主体可以采取什么样的方式来访问其所拥有的一些资源，即一个拥有一定权限范围的主体可以直接或者间接地把权限授予其他的主体。
2. MAC。是系统统一采用某种访问权限的授予和撤销的策略，而且强制所有主体都必须服从这种访问权限的分配。由于过于强调系统的安全性能，虽然能够很好的控制系统的安全，但是它管理起来比较麻烦，工作量很大，也不够灵活
3. RBAC。DAC和MAC访问控制策略都有其特点，也有不足。而基于角色的访问控制则可以在克服以上两者的缺点的同时，提供一个良好的安全的系统环境，因而是面向企业的系统中一种十分有效的访问控制策略。

2. 访问许可的授权

对访问许可的授权有三种类型：

1. 等级型。把对客体的存取控制权限的修改能力划分成不同的等级，拥有高级别修改能力的主体可以把这种权限分配给比其级别低的主体。一次类推，从而将访问许可的授权关系组成一个树形结构。优点是树形结构与实际组织结构类似，并且可以由领导根据日常实际工作需要进行授权来对各级用户进行控制和管理。但是也有一个缺点，就是对同一个客体来说，可能存在多个主题有能力修改其存取控制权限。
2. 拥有型。这种类型对每一个客体都有一个拥有者，拥有者具有对所拥有的客体的全部控制权，并且可以任意修改其拥有的客体的访问控制表，并可其他主体授予或撤销其对客体的任何一种访问权限，但是拥有者无权将其对客体的访问控制的分配权授予其他主体。
3. 自由型。特点是一个客体的拥有者可以对任何主体授予对他所拥有的客体的访问权限，同时还可以把这种分配权授予其他主体而不受任何限制。这样，获得了这种授权的主体就可以吧这种分配权授予更多的主体而不受该客体的拥有者的限制。这样做安全性比较差，一般的系统中很少采用这种方式。

16.7 网络安全体系

16.7.1 OSI安全架构

是一个面向对象的、多层次的结构，它认为安全的网络应用是由安全的服务实现的，而安全服务又是由安全机制来实现的。

1. OSI安全服务

1. 对象认证服务。又可分为对等实体认证和信源认证，用于识别对等实体或信源的身份，并对身份的真实性、有效性进行证实。
2. 访问控制服务。防止越权使用通信网络中的资源。可以分为自主访问控制、强制访问控制、基于角色的访问控制。
3. 数据保密性服务。是针对信息泄露而采取的防御措施，包括信息保密、选择段保密、业务流保密等内容。是通过对网络中传输的数据进行加密来实现的。
4. 数据完整性服务。包括防止非法篡改信息，如修改、删除、插入、复制等。
5. 禁止否认服务。可以防止信息的发送者在事后否认自己曾经进行过的操作，即通过证实所有发生过的操作防止抵赖。具体的可以分为防止发送抵赖、防止递交抵赖和进行公证几个方面。

2. OSI安全机制

为了实现前面所述的OSI 5种安全服务，OSI安全架构建议采用如下8种安全机制。

1. 加密机制。即通过各种加密算法对网络中传输的信息进行加密。
2. 数字签名机制。是采用私钥进行数字签名，同时采用公开密钥加密算法对数字签名进行验证的方法。
3. 访问控制机制。可以根据系统中实现设计好的一系列访问规则判断主体对客体的访问是否合法。
4. 数据完整性机制。包括数据单元的完整性和数据单元序列的完整性两个方面。
5. 鉴别交换机制。以交换信息的方式来确定实体的身份，一般用于同级别的通信实体之间的认证，要实现鉴别交换常常用到如下技术：
   
   • 口令：由发送方提交，由接收方检测
   • 加密：将交换的信息加密，使得只有合法用户才可以解读
   • 实体的特征或所有权：例如，指纹识别，身份卡识别等。
6. 业务流填充机制。是设法使加密装置在没有有效数据传输时，还按照一定的方式连续的向通信线路上发送伪随机序列，并且这里发出的伪随机序列也是经过加密处理的。
7. 路由控制机制。
8. 公证机制。

3. OSI安全服务于安全机制之间的关系

不是一一对应的关系。

安全机制\安全服务	对象认证	访问控制	数据保密性	数据完整性	防止否认
加密	是		是	是
数字签名	是	是		是	是
访问控制		是
数据完整性				是	是
鉴别交换	是
业务流填充			是
路由控制			是
公证					是

16.7.2 VPN在网络安全中的应用

虚拟专用网络VPN是指利用不安全的公共网络如Internet作为传输媒介，通过一系列的安全技术处理，实现类似专用网络的安全性能，保证重要信息的安全传输的一种网络技术

1. VPN技术的优点

1. 网络通信安全。采用安全隧道灯技术提供安全的端到端的连接服务，通信时所传输的信息都是经过RSA不对称加密算法加密处理的，密钥则是通过Diffie-Hellman算法计算得出的，可以充分保证数据通信的安全。
2. 方便的扩充性。利用VPN技术实现企业内部专用网络，以及异地业务人员的远程接入等。
3. 方便的管理。
4. 节约成本显著

2. VPN的原理

实现VPN需要用到一系列关键的安全技术，包括

1. 安全隧道技术。即把传输的信息经过加密和协议封装处理后再嵌套装入另一种协议的数据包中送入网络中，像普通数据包一样进行传输。经过这样的处理，只有源端和目标端的用户对加密封装的信息能进行提取和处理，而对于其他用户而言，这些信息只是无意义的垃圾。
2. 用户认证技术。在连接开始之前先确认用户的身份，然后系统根据用户的身份进行相应的授权和资源访问控制。
3. 访问控制技术。由VPN服务的提供者与最终网络信息资源的提供者共同协商确定用户对资源的访问权限，以此实现基于用户的访问控制，实现对信息资源的保护。

安全隧道代理和管理中心组成安全传输平面STP，实现在Internet上安全传输和相应的系统管理功能。用户认证管理中心和密钥分配中心组成公共功能平面CFP，他是安全传输平面的辅助平面，主要向用户代理提供相对独立的用户身份认证与管理、密钥的分配与管理功能。

建立VPN通信时，VPN用户代理向安全隧道代理请求建立安全隧道，安全隧道代理接受后，在管理中心的控制和管理下载Internet上建立安全隧道，然后向用户提供同名的网络传输。VPN用户代理包括安全隧道终端功能、用户认证功能和访问控制功能三个部分，它们共同向上层应用提供完整的VPN服务。

1. 安全传输平面

实现在Internet上安全传输和相应的系统管理功能，这是由安全隧道代理和管理中心共同完成的。
1. 安全隧道代理。可以在管理中心的控制下将多段点到点的安全通路连接成一条端到端的安全隧道。它是VPN的主体，主要作用有：
- 建立与释放安全通道。
- 用户身份的验证
- 服务等级的协商
- 信息的透明传输
- 控制与管理安全隧道
2. VPN管理中心。是整个VPN的核心部分，与安全隧道代理直接联系，负责协调安全传输平面上的各安全隧道代理之间的工作，具体功能包括：
- 安全隧道的管理与控制。
- 网络性能的监控与管理

2. 公共功能平面

是安全传输平面的辅助平面，向VPN用户代理提供相对独立的用户身份认证与管理、密钥的分配与管理功能，分别由用户认证管理中心和VPN密钥分配中心完成。

1. 认证管理中心。提供用户身份认证和用户管理。用户认证就是以第三者身份客观的向VPN用户代理和安全隧道代理中的一方或双方提供用户身份的认证，以便它们能够相互确认对方的身份。
   用户管理是指与用户身份认证功能能直接相关的用户管理部分，即对个用户的信用程度和认证情况进行日志记录，并可在VPN与建立安全隧道双方进行服务等级的协商时参考。这里的管理是面向服务，而与用户权限、访问控制等方面有关的用户管理功能则不在此列。
2. 密钥分配中心。向需要进行身份验证和信息加密的双方提供密钥的分配、回收与管理功能。在VPN系统里，用户代理、安全隧道代理、认证管理中心等都是密钥分配中心的用户。

16.8 系统的安全性设计

16.8.1 物理安全问题与设计

物理安全包括物理设备本身是否安全可靠，还包括设备的位置与环境的而安全、限制物理访问、地域因素等几个方面。

信息系统的所有重要的物理设备、设施都应该放在专门的区域，并尽可能集中，同时严格限制外来人员访问，尽可能减少未经授权的访问。

物理安全还要求设计中注意物理设备的冗余备份。例如，核心设备或部件都应该是热备份系统，具有实时和准实时切换的能力。

物理安全还要求严格限制对网络信息点、线缆等网络基础设施及其所在地进行物理访问，要想访问必须经过专门的授权。

物理安全还包括环境方面的因素。

16.8.2 防火墙及其在系统安全中的应用

1. 防火墙的基本原理

防火墙通常使用的采用包过滤、状态检测、应用网关等几种方式控制网络连接。

包过滤防火墙是一种简单而有效的安全控制技术，根据在防火墙中预先定义的规则（允许或禁止与哪些源地址、目的地址、端口号有关的网络连接），对网络层和传输层的数据包进行检查，进而控制数据包的进出。优点是对用户透明、传输性能高。但是由于只能在网络层、传输层进行控制，安全控制的方式也只限于源地址、目的地址和端口号这几种，对于应用层的信息无法感知，因而只能进行较为初步的安全控制，对于拥塞控制、内存覆盖攻击或病毒等高层次的攻击手段，则无能为力

状态检测防火墙保持了包扩率防火墙的优点，所以性能较好，而且对应用透明。同时，改进了包过滤防火墙的缺点，在防火墙内部建立状态连接表，维护了连接，将进出网络的数据当成一个个的时间来处理。对于每一个网络连接，状态检测根据预先设置的安全规则，允许符合规则的连接通过，并在内存中记录下该连接的相关信息，生成状态表，对该连接的后续数据包，只要符合状态表，就可以通过。优点是，由于不需要对每个包进行规则检查，而是对一个连接的后续数据包通过散列算法，直接状态检查，从而使性能得到了较大提高。

与前两种不同，应用网关防火墙检查所有用用层的信息表，并将检查的内容信息放入决策过程，从而提高网络的安全性。然而，应用网关防火墙是通过打破客户机/服务器模式实现的，每个通信需要两个连接：一个是从客户端到防火墙，另一个是从防火墙到服务器。另外，每个网关需要一个不同的应用进程，或一个后台运行的服务程序，对每个新的应用必须添加针对此应用的应用程序，否则无法使用，所以通用性较差。

2. 防火墙的优点

1. 可以隔离网络，限制安全问题的扩散
2. 通过防火墙可以对网络中的安全进行集中化管理，简化网络安全管理的复杂度
3. 能够有效的记录Internet上的活动。

3. 正确使用防火墙

1. 防火墙虽然能够对来自外部网络的非法连接作很严格的限制，但是对来自本地网络内部的攻击却无从防范。
2. 即使对于来自外部的攻击，目前的任何防火墙也不能做到完全阻挡所有的非法入侵。
3. 防火墙不能防范病毒，无法抵御基于数据的攻击。
4. 防火墙不能防范全部的威胁，而只能防备已知的威胁。
5. 防火墙不能防范不通过它的链接。

16.8.3 入侵检测系统

通过对计算机网络或计算机系统中的若干关键点收集信息并对其进行分析，从中发现网络或系统中是否有违反安全策略的行为和被攻击的迹象。

1. 入侵检测技术

入侵检测系统的处理过程分为数据采集阶段、数据处理及过滤阶段、入侵分析及检测阶段、报告及响应阶段4个阶段。数据采集阶段主要收集目标系统中引擎提供的通信数据包和系统使用等情况。数据处理及过滤阶段是把采集到的数据转换为可以识别是否发生入侵的数据的阶段。入侵分析及检测阶段通过分析上一阶段提供的数据来判断是否发生入侵。这一阶段是整个入侵检测系统的核心阶段。报告及响应阶段针对上一阶段中得出的判断作出响应。如果被判断为发生入侵，系统将采取相应的响应措施，或者通知管理人员发生入侵，以便采取措施。

检测技术分为两类：

基于标识的检测技术，先定义出违背安全策略的事件的特征，然后对收集到的数据进行分析，通过判别这类特征是否在所收集到的数据中出现来判断是否受到入侵。非常类似杀毒软件的特征码检测，比较简单有效

基于异常的检测技术，先定义出一组系统“正常”情况的数值，然后将系统中运行的数值与所定义的“正常”情况比较，得出是否有被攻击的迹象。核心在于如何定义所谓的“正常”情况。

2. 入侵检测系统的种类和选用。

一般来说，入侵检测系统可分为主机型和网络型。

主机型入侵检测系统往往以系统日志、应用程序日志等作为数据源，也可以通过其他手段从所在的主机收集信息进行分析。保护的一般是其所在的主机系统。需要为不同平台开发不同的程序，而且会增加系统负荷，海奥在每一台主机安装，比较麻烦，但是可以充分利用操作系统本身提供的功能，并结合异常分析，更准确的报告攻击行为。

网络型入侵检测系统则以网络上的数据包作为数据源，通过在一台主机或网络设备上监听本网段内的所有数据包进行分析判断。一般会担负着保护整个网段的任务。这种系统应用十分简便：一个网段上只需要安装一个或几个这样的系统，便可以监测整个网段的情况，但是它不跨越多个物理网段，对于复杂结构的网络监测效果有一定的影响。

16.9 安全性规章

16.9.1 安全管理制度

16.9.2 计算机犯罪与相关法规

1. 计算机犯罪

是指针对和利用计算机系统，通过非法操作或以其他手段，对计算机系统的完整性或正常运行造成危害的行为。

犯罪对象是计算机系统或其中的数据。所谓非法操作，是指一切没有按照操作规程或超越授权范围而对计算机系统进行的操作。

1. 呈现出国际化趋势
2. 从犯罪针对的对象看，向全社会各单位和个人蔓延。
3. 从组织的形式上看，由个人范围向群体范围、组织犯罪发展；由单一目的的犯罪向综合性犯罪发展。
4. 从犯罪的主体上看，所涉及人员范围越来广泛，并呈现低龄化趋势。
5. 从危害程度看，后果越来越严重
6. 通过网络窃取机密将成为间谍活动的主要形式之一。

2. 我国的相关法律、法规

第十七章 系统的可靠性分析与设计

17.1 可靠性概述

与可靠性相关的概念主要有：可靠度、可用度、可维度、平均无故障时间、平均故障修复时间及平均故障间隔时间等。

1. 可靠度。系统的可靠度R(t)是指在t=0时系统正常的条件下，系统在时间区间[0,t]内能正常运行的概率
2. 可用度。系统的可用度A(t)是指系统在时刻t可运行的概率
3. 可维度。系统的可维度M(t)是系统失效后，在时间间隔内被修复的概率。
4. 平均无故障时间，可靠度为R(t)的系统平均无故障时间MTTF定义为从t=0时到故障发生时系统的持续运行时间的期望值
5. 平均故障修复时间。可用度为A(t)的系统平均故障修复时间MTTR可以用类似于求MTTF对的方法求得。
6. 平均故障间隔时间。MTBF常常能与MTTF发生混淆，因为两次故障（失败）之间必然有修复香味，因此MTBF中应包含MTTR。对于可靠度服从指数分布的同，从任意时刻到达故障的期望时间都是相等的。
   $$MTBF=MTTR+MTTF$$

17.2 系统故障模型

17.2.1 故障的来源以及表现

1. 失效：硬件的物理改变
2. 故障：由于部件的失效、环境的物理干扰、操作错误或不正确的设计引起的硬件或软件中的错误状态。
3. 错误（差错）：故障在程序或数据结构中的具体位置。错误与故障之间可能出现一定距离。故障或错误有如下几种表现形式：
   
   • 永久性：描述连续稳定的失效、故障或错误。在硬件中，永久性失效反应了不可恢复的物理改变。
   • 间歇性：描述那些由于不稳定的硬件或变化着的硬件或软件状态所引起的、仅仅偶然出现的故障或错误。
   • 瞬时性：描述那些由于暂时的环境条件引起的故障或错误。

一个故障可能是由物理失效、不适当的系统设计、环境影响或系统的操作员所引起。永久性失效会导致永久性故障。间歇性故障可能由不稳定、临界稳定或不正确的设计所引起。环境条件会造成瞬时性故障。所有这些故障都可能引起错误。不正确的设计和操作员失误会直接引起错误。由硬件的物理条件，不正确的硬件或软件设计，或不稳定但重复出现的环境条件所引起的故障可能是可检测的，并且可以通过替换或重新设计来修复；然而，由于暂时的环境条件所引起的故障是不能修复的，因为其硬件本身实际上并没有损坏。瞬时和间歇故障已经成为系统中的一个主要错误源。

17.2.2 几种常见的故障模型

1. 逻辑级的故障模型

固定型故障指电路中元器件的输入或输出等线的逻辑固定为0或固定为1。短路故障是指一个元件的输出线的逻辑值恒等于输入线的逻辑值；元件的开路故障是元件的输出线悬空，逻辑值可根据具体电路来决定。桥接故障是指两条不应相连的线连接在一起而发生的故障。

2. 数据结构级的故障

故障在数据结构上的表现成为差错。常见的差错如下。

• 独立差错：一个故障的影响表现为使一个二进制位发生改变。
• 算数差错：一个故障的影响表现为使一个数据的值增加或减少2i（i=0,1,2,3....)
• 单向差错：一个故障的影响表现为使一个二进制向量中的某些位朝一个方向（0或1）改变。

3. 软件故障和软件差错

软件故障是指软件设计过程中造成的与设计说明不一致的情况，在数据结构或程序数据中的表现称为软件差错。常见的软件差错有以下几种：

• 非法转移：程序执行了说明中不存在的转移
• 误转移：程序执行了尽管说明中存在，但依据当前控制数据不应进行的转移。
• 死循环：程序执行时间超过了规定界限。
• 空间溢出：程序使用的空间超过了规定界限。
• 数据执行：指令计数器指向数据单元。
• 无理数据：程序输出的数据不合理。

4. 系统级的故障模型

故障在系统级上的表现成为功能错误，即系统输出与系统设计说明的不一致。如果系统输出无故障保护机构，则故障在系统级上的表现就会造成系统失效。

17.3 系统配置方法

容错技术是保证系统在某些组成部分出现故障或差错时仍能正常工作的技术。

17.3.1 单机容错技术

是保证系统在某些组成部分出现故障或差错时仍能正常工作的技术。系统的故障可分为两类：一类是“致命的”，不可能自行修复；另一类是局部的，可能被修复。容错技术正是用于构造一种能够自动排除非致命性故障的系统，即容错系统。

在单机容错技术中，提高系统工作可靠性的方法主要有自检技术和冗余技术。容错又有多种形式，如硬件容错、软件容错、整机容错等。

1. 自检技术

自检是指系统在发生非致命性故障时能自动发现故障和确定故障的性质、部位，并自动采取措施更换和隔离产生故障的不见。自检需采用诊断技术，常用专门程序实现，属于程序设计的范围。容错系统的实现要求系统必须具有重复部件或备份部件，或具有不止一个完成某种功能的通道，因此自检技术长配合冗余技术使用。计算机的容错系统一把都需要应用自检技术。

2. 冗余技术

可分为硬件冗余、软件冗余、时间冗余、信息冗余等。冗余技术中最常用的两种方法是重复线路和备份线路。重复线路指用多个相同品种和规格的元件或构件并联起来，当做一个元件或构件使用，只要有一个不出故障，系统就能够正常工作。在并联工作时每一个构件的可靠性概率是互相独立的。备份线路与重复线路的差别是参加备份的构件并不接入系统，只有在处于工作状态的构件发生故障后才把输入和输出接到备份构件上来，同时切断故障构建的输入、输出。

17.3.2 双机热备份技术

是一种挼硬件结合的较高容错应用方案。该方案是由连哪个台服务器系统和一个外接共享磁盘矩阵列柜和响应的双机热备份软件组成。其中呢的外接共享磁盘矩阵列柜也可以没有，而是在各自的服务器中采取RAID（独立冗余磁盘阵列）卡。

在这个容错方案中，操作系统和应用程序安装在两台服务器的本地系统盘上，整个网络系统的数据是通过磁盘阵列集中管理和数据备份的。数据集中管理是通过双机热备份系统，将所有站点的数据直接从中央存储设备读取和存储，并由专业人员进行管理，极大地保护了数据的安全性和保密性。用户的数据存放在外接共享磁盘阵列中，在一台服务器出现故障时，备份主动替代主机工作，保证网络服务不间断。

双机热备份系统采用“心跳”方法保证系统与备用系统的联系。所谓“心跳”，指的是主、从系统之间相互按照一定的时间间隔发送通信信号，表明各自系统当前的运行状态。一旦“心跳”信号表示主机系统发生故障，或者备用系统无法收到主机系统的“心跳”信号，则系统的高可用管理软件认为主机系统发生故障，立即将系统资源转移到备份系统上，备用系统替代主机工作，已保证系统正常运行和网络服务不间断。

双机热备份方案中，根据两台服务器的工作方式可以有三种不同的工作模式，即，双机热备模式、双机互备模式和双机互工模式。

双机热备模式即目前通常所说的active/standby方式，active服务器处于工作状态；而standby服务器处于监控准备状态，服务器数据包括数据库数据同时往两台或多台服务器写入（通常各服务器采用RAID磁盘阵列卡），保证数据的即时同步。当active服务器出现故障时，通过软件侦测或手工方式将standby机器激活，保证应用在短时间内完全恢复正常使用。

双机互备模式，是两个相对独立的应用在两台机器上同时运行，但彼此均设为备机，当某一台服务器出现故障时，另一台服务器可以在短时间内将故障服务器的应用接管过来，从而保证了应用的持续性，但对服务器的性能要求比较高。

双机双工模式是集群的一种形式，两台服务器均处于活动状态，同时运行相同的应用，以保证整体系统的性能，也实现了负载均衡和互为备份，通常使用磁盘柜存储技术。

17.3.3 服务器集群技术

集群技术指一组相互独立的服务器在网络中组合成为单一的系统工作，并以单一系统的模式加以管理。大多数情况下，集群中所有计算机拥有一个共同的名称，集群内任一系统上运行的服务可被所有的网络客户使用

集群必须可以协调管理各分离的构件出现的错误和故障，并可透明的向集群中加入构件。一个集群包含多台（至少两台）共享数据存储空间的服务器。其中任何一台服务器运行应用时，应用数据被存储在共享的数据空间内。每台服务器的操作系统和应用程序文件存储在各自的本地储存空间上。

集群内各节点服务器通过一个内部局域网相互通信，当一台节点服务器发生故障时，这台服务器上所运行的应用程序将在另一个节点服务器上被自动接管。当一个应用服务发生故障时，应用服务将被重新启动或被被另一台服务器接管。当以上的任一故障发生时，客户都能很快连接到其他应用服务器上。

17.4 系统可靠性模型

17.4.1 时间模型

可靠性增长模型，基于这样一个假设：一个软件的中的故障数据在t=0时是常数，随着故障被纠正，故障数目逐渐减少。

17.4.2 故障植入模型

是一个面向错误数的数学模型，目的是以程序的错误数作为衡量可靠性的标准，基本假设如下：

1. 程序中的固有错误数是一个未知的常数。
2. 程序中的人为错误数按均匀分布随机植入
3. 程序中的固有错误数和人为错误被检测到的概率相同。
4. 检测到的错误立即改正

17.4.3 数据模型

对于一个预先确定的输入环境，软件的可靠度定义为在n次连续运行软件中软件完成指定任务的概率。

17.5 系统内的可靠性分析和可靠度计算

17.5.1 组合模型

是计算机容错系统可靠性能最长用哪个的方法。一个系统只要满足一下条件，就可以用组合模型来计算其可靠性。做如下假设：

1. 系统只有两种状态：运行状态和失效状态
2. 系统可以划分成若干个不重叠的部件，每个部件也只有两种状态：运行状态和失效状态
3. 部件的失效是独立的
4. 系统失效当且仅当系统中的剩余资源不满足系统运行的最低资源要求（系统的状态只依赖于部件的状态）时。
5. 已知每个部件的可靠性，可靠性指可用度或可靠度等概率参数。

组合模型的目标就是根据各部件的可靠性来计算系统的可靠度，基本思想如下：

1. 枚举所有系统状态

2. 计算每个系统状态的概率

3. 可靠性计算

17.5.2 马尔柯夫模型

两个核心概念是状态和状态转移。系统的状态表示了在任何瞬间用以描述该系统所必须知道的一切。

17.6 提高系统可靠性的措施

防止故障造成系统失效的两种技术是故障掩蔽技术和系统重组技术，故障掩蔽技术是指防止故障造成差错的各种技术，系统重组技术是防止差错导致系统失效的各种技术。故障掩蔽技术和系统重组技术是达到容错的两种基本途径。而他们又是建立在资源冗余的基础上的。资源冗余有硬件冗余、信息冗余、时间冗余和软件冗余4种形式。

17.6.1 硬件冗余

最常用的是三模冗余TMR，三个相同的模块接收三个相同的输入，产生的结果送至多数表决器。表决器的输出取决于三个输入的多数，若有一个故障模块，则另两个正常模块的输出可将故障模块的输出掩蔽，从而不再表决器输出产生差错。

17.6.2 信息冗余

是指通过在数据中附加冗余的信息以达到故障检测、故障掩蔽或容错的目的。

1. 海明校验码

基本的海明纠错码能纠正一位错。原理是基于重叠奇偶校验的概念：将原始数据位分成若干个重叠的组，每一组设一位奇偶校验位。由于位间有重叠，因此每位原始数据从属于多余一个组。而且每位原始数据的从属关系是不一样的，纠错时，根据哪些组的奇偶校验位出错，就可以唯一的确定是哪一位数据出错，将该位取反就完成了纠错。

2. 循环冗余校验码

17.7 备份与恢复

系统的数据备份就是在系统其它地方创建数据与程序的电子复制，为重建系统中被破坏的或不正确的数据提供条件，备份最常用的技术是数据转储和建立日志文件等。

数据转储可分为静态转储和动态转储。静态转储是指系统中无事务时进行的转储操作，动态转储是指转储操作和用户操作并发进行，而且转储工作不会影响事务的运行，但它不能保证副本中的数据正确有效。

建立日志文件是指把所有事务对系统的修改活动都登记下来。若发生了故障，对于静态转储，可以在重装后备系统之后，利用日志文件进行回复，避免重新运行事务；对于动态转储，可以把转储得到的副本和转储期间的日志文件结合起来进行故障恢复，使系统恢复正常工作状态。

备份通常分为联机备份和脱机备份两种方式。

脱机备份也叫冷备份，是一种静态转储技术，备份系统所有的物理文件和初始化文件。优点是在恢复过程中步骤最少，比热备份快并且出错机会少，定期的脱机备份加上一组好的重做日志可以把系统的数据恢复到有任何一个时间点上。

联机备份也叫热备份，是一种动态转储技术，由于只备份所需的文件，因而被看做是部分备份。在系统运行时执行。优点是可以实现完全的时间点恢复，同时由于数据库一直处于打开状态，减少了系统对物理资源的要求，改善了数据的执行；但联机备份比较复杂，需要对系统的核心有比较深刻的认识，对备份策略进行反复的测试，才能最终确定他的正确性和可用性。