软考——架构师笔记
1、计算机基础(概率很小)
1.1、计算机系统基础
1、CPU的组成:CPU 主要由运算器、控制器、寄存器组和内部总线等部件组成。
2、运算器:由算术逻辑单元ALU(实现对数据的算术和逻辑运算)、累加寄存器AC(运算结果或源操作数的存放区)、数据缓冲寄存器DR(暂存内存的指令或数据)、和状态条件寄存器PSW(保存指令运行结果的条件码内容,如溢出标志等)组成。
3、控制器:由指令寄存器IR(暂存CPU执行指令)、程序计数器PC(存放指令执行地址)、地址寄存器AR(保存当前CPU所访问的内存地址)、指令译码器ID(分析指令操作码)等组成。
4、校验码:假设原始信息串为10110,CRC 的生成多项式为G(x)=x^4+x+1,求CRC 校验码。
结果为101101111。运算如下
1111(若余数不足则左边补3) ← 余数(CRC校验码)
5、指令集
6、流水线时间计算
流水线周期:指令分成不同执行段,其中执行时间最长的段为流水线周期。
流水线执行时间:1条指令总执行时间 +(总指令条数 - 1)* 流水线周期。
流水线吞吐率计算:吞吐率即单位时间内执行的指令条数。
公式:指令条数 / 流水线执行时间。
流水线的加速比计算:加速比即使用流水线后的效率提升度,即比不使用流水线快了多少倍,越高表明流水线效率越高。
公式:不使用流水线执行时间 / 使用流水线执行时间。
7、存储设备的存储速度
8、存储系统的地址映像方式的冲突概率,由高到低
直接映像 -> 组组相连映像 -> 全相连映像
1.2、操作系统(3-5)
1、操作系统的4个特征是并发性、共享性、虚拟性和不确定性。
2、操作系统功能:进程管理、文件管理、存储管理、设备管理和作业管理。
3、操作系统分类:批处理操作系统、分时操作系统、 实时操作系统、网络操作系统、分布式操作系统和微型计算机操作系统。
4、嵌入式系统特点
5、进程组成和状态
6、死锁产生的四个必要条件:资源互斥、每个进程占有资源并等待其他资源、系统不能剥夺进程资源、进程资源图是一个环路。(互斥是属性,不可以被破坏)
死锁资源计算:系统内有 n 个进程,每个进程都需要 R 个资源,那么其发生死锁的最大资源数为 n(R-1)。其不发生死锁的最小资源数为 n(R-1)+1。
7、索引文件
8、文件目录
相对路径:是从当前路径开始的路径。
绝对路径:是从根目录开始的路径。
全文件名 = 绝对路径 + 文件名。要注意,绝对路径和相对路径是不加最后的文件名的,只是单纯的路径序列。
9、位示图的计算
2、嵌入式系统(3-5)
1、微处理器分类
嵌入式微控制器 MCU:单片机。
嵌入式微处理器 MPU:只保留和嵌入式应用紧密相关的功能硬件,去除其他的冗余功能部分。
嵌入式数字信号处理器 DSP:用于信号处理方面的处理器,采用哈佛结构。可用于运算量大的系统。
嵌入式片上系统 SoC(片上系统):软硬一体、高度定制,是一个产品。
2、AI芯片的特点:新型的计算范式、训练和推断,大数据处理能力、可重构的能力。
3、总线
分类:单工、半双工、全双工。
4、串行总线的特点:
(1) 适宜长距离传输数据,由全双工和半双工之分。
(2)串行总线传输的波特率在使用中可以改变。
(3)接收和发送可以使用多种方式,比如程序查询和中断。
5、板级支持包(BSP)作为对硬件的抽象,实现硬件有关性,操作系统有关性。
6、RTOS(实时操作系统)可以根据应用环境的要求对内核进行裁剪和重配。
7、软件低功率设计一般采用:编译优化技术、软硬件协同设计和算法优化。
8、混成系统一般由离散分离组件和连续组件并行或串行组成,组件之间的行为由计算机模型进行控制。
3、数据库系统(3-5)
3.1数据库系统
1、三级模式-两级映像
◆ 内模式:管理如何存储物理的数据,对应具体物理存储文件。
◆ 模式:又称为概念模式,就是我们通常使用的基本表,根据应用、需求将物理数据划分成一张张表。
◆ 外模式:对应数据库中的视图这个级别,将表进行一定的处理后再提供给用户使用。
◆ 外模式—模式映像:是表和视图之间的映射,存在于概念级和外部级之间。若表中数据发生了修改,只需要修改此映射,而无需修改应用程序。
◆ 模式—内模式映像:是表和数据的物理存储之间的映射,存在于概念级和内部级之间。若改了数据存储方式,只需要修改此映射,而不需要去修改应用程序。
2、数据库设计
| 阶段 | 主要任务 | 输出物 |
|---|---|---|
| 需求分析 | 分析用户需求 | 数据流图、数据字典、需求说明书 |
| 概念设计 | 设计 E-R 图并合并 | 全局 E-R 图(解决三类冲突) |
| 逻辑设计 | 转关系模式 + 完整性约束 | 关系模型、用户视图 |
| 物理设计 | 存储结构 & 访问方式 | 物理 schema、索引策略 |
| 实施阶段 | 建库 + 编程 + 试运 | 可运行系统 |
| 运行维护 | 监控 + 优化 + 修改 | 持续改进的系统 |
🔴 分 E-R 图进行合并时,它们之间存在的冲突主要有以下 3 类:
◆ 属性冲突:同一属性可能会存在于不同的分 E-R 图中。
◆ 命名冲突:相同意义的属性,在不同的分 E-R 图上有着不同的命名;或是名称相同的属性在不同的分 E-R 图中代表着不同的意义。
◆ 结构冲突:同一实体在不同的分 E-R 图中有不同的属性;同一对象在某一分 E-R 图中被抽象为实体而在另一分 E-R 图中又被抽象为属性。
3.2 数据模型
1、关系模型:实体–联系模型,即ER图(描述概念数据模型)。
2、数据模型三要素:
数据结构 —— 所研究的对象类型的集合
数据操作 —— 对数据库中各种对象的实例允许执行的操作的集合
数据的约束条件 —— 一组完整性规则的集合
3、模型说明
| 术语 | 定义/说明 | 示例 |
|---|---|---|
| 实体 | 可区分的具体或抽象事物 | 学生、课程、订单 |
| 弱实体 | 依赖强实体存在 | “订单项”依赖“订单” |
| 属性 | 实体的特征 | 姓名、年龄、价格 |
| 码(Key) | 唯一标识实体的属性集 | 学号、身份证号 |
| 联系 | 实体间或实体内部的关系 | 学生选课、教师授课 |
| 联系类型 | 1:1, 1:N, M:N | 一人一卡(1:1),班级-学生(1:N),学生-课程(M:N) |
4、属性(二维表中的列,比如人员表中的姓名、年龄等)和元祖(二维表中的行,比如人员表中某人的数据)
3.3、关系代数
1、关系代数的交并差
| 运算 | 符号 | 含义 | SQL 对应语句 |
|---|---|---|---|
| 并 | ∪ | 去重合并 | UNION |
| 交 | ∩ | 取共同部分 | INTERSECT |
| 差 | − | S1 有但 S2 没有 | EXCEPT 或 MINUS |
2、自然连接的结果:显示全部的属性列,但是相同属性列只显示一次,显示两个关系模式中属性相同且值相同的记录。
3、笛卡尔积
S1 * S2,产生的结果包括 S1 和 S2 的所有属性列,并且 S1 中每条记录依次和 S2 中所有记录组合成一条记录,最终属性列为 S1 + S2 属性列,记录数为 S1 * S2 记录数。
◆ 投影:实际是按条件选择某关系模式中的某列,列也可以用数字表示。
◆ 选择:实际是按条件选择某关系模式中的某条记录。
4、笛卡尔积和自然连接的区别(注意符号)
| 特性 | 笛卡尔积 (×) | 自然连接 (⋈) |
|---|---|---|
| 定义 | 将两个关系 $ R $ 和 $ S $ 中的每一行与另一表的每一行进行强制组合。 | 在两个关系的公共属性上,选取值相等的行进行组合,并去除重复列。 |
| 连接条件 | 无条件。不需要任何匹配条件,直接暴力组合。 | 隐含条件。自动以同名属性作为连接条件(即 $ R.A = S.A $ )。 |
| 结果行数 | $ M \times N $ ( $ M $ 为表1行数, $ N $ 为表2行数)。 通常非常大,包含大量无意义数据。 |
$ \le M \times N $ 。 只保留匹配成功的行,通常远小于笛卡尔积。 |
| 结果列数 | $ C_1 + C_2 $ (两表列数之和,包含重复列)。 |
$ C_1 + C_2 - K $ ( $ K $ 为公共属性个数,重复列只保留一份)。 |
| 实际意义 | 数学基础运算,单独使用通常无业务意义(数据爆炸)。 | 具有明确的业务逻辑意义(如:学生选课、员工部门关联)。 |
3.4、函数和范式
1、函数依赖
2、函数依赖的公理系统
◆ 自反律:
若 Y ⊆ X ⊆ U,则 X → Y 为 F 所逻辑蕴含
◆ 增广律:
若 X → Y 为 F 所逻辑蕴含,且 Z ⊆ U,则 XZ → YZ 为 F 所逻辑蕴含
◆ 传递律:
若 X → Y 和 Y → Z 为 F 所逻辑蕴含,则 X → Z 为 F 所逻辑蕴含
◆ 合并规则:
若 X → Y,X → Z,则 X → YZ 为 F 所蕴涵
◆ 伪传递率:
若 X → Y,WY → Z,则 XW → Z 为 F 所蕴涵
◆ 分解规则:
若 X → Y,Z ⊆ Y,则 X → Z 为 F 所蕴涵
📌 Armstrong 公理系统的三大基本公理:
自反律 —— “子集必被决定”
增广律 —— “两边同加仍成立”
传递律 —— “链条可推导”
💡 应用示例:
假设 F = {A→B, B→C},根据传递律 ⇒ A→C
再根据合并规则 ⇒ A→BC
再根据分解规则 ⇒ A→B 且 A→C(已知)
3、键与约束
| 概念 | 定义简述 | 是否可为空 | 是否可重复 | 示例 |
|---|---|---|---|---|
| 超键 | 能唯一标识元组的属性集 | 否 | 否 | {学号, 姓名} |
| 候选键 | 最小超键(无冗余) | 否 | 否 | {学号} |
| 主键 | 从候选键中选定的一个 | 否 | 否 | 学号 |
| 外键 | 引用其他表主键的字段 | 是* | 是 | 课程表中的“教师编号” |
| 主属性 | 属于任一候选键的属性 | — | — | 学号、课程号 |
| 非主属性 | 不属于任何候选键的属性 | — | — | 姓名、成绩 |
◆ 实体完整性约束:即主键约束,主键值不能为空,也不能重复。
◆ 参照完整性约束:即外键约束,外键必须是其他表中已经存在的主键的值,或者为空。
◆ 用户自定义完整性约束:自定义表达式约束,如设定年龄属性的值必须在0到150之间。
4、三大范式
(1) 第一范式 1NF
关系中的每一个分量必须是一个不可分的数据项。通俗地说,第一范式就是表中不允许有小表的存在。
(2)第二范式 2NF
如果关系 R 属于 1NF,且每一个非主属性完全函数依赖于任何一个候选码,则 R 属于 2NF。
通俗地说,2NF 就是在 1NF 的基础上,表中的每一个非主属性不会依赖复合主键中的某一个列。如果存在复合主键则不属于第2NF。
(3)第三范式 3NF
在满足 1NF 的基础上,表中不存在非主属性对码的传递依赖。
5、模式分解判断
| 概念 | 含义 | 通俗解释 | 重要性 |
|---|---|---|---|
| 无损分解 (Lossless) | 分解后的表自然连接(Natural Join)能完全恢复原表,不多不少。 | 把一张大表拆成小表后,还能完美拼回去,没有产生虚假数据(多余行),也没丢数据。 | 必须满足!否则数据会出错。 |
| 有损分解 (Lossy) | 连接后产生了原表中不存在的元组(虚假数据)或丢失了数据。 | 拼回去的时候,多出了原本没有的“假记录”,或者少了一些记录。 | 绝对禁止。 |
| 保持函数依赖 (Preserve FD) | 原表上的所有函数依赖,都能在分解后的某个子表中单独验证。 | 拆表后,原来的规矩(如“学号→姓名”)在拆分后的某张小表里依然成立,不需要跨表连接就能检查。 | 尽量满足,为了维护数据完整性方便。 |
| 不保持函数依赖 | 某些依赖关系跨越了多个子表,必须连接后才能验证。 | 原来的规矩被拆散了,单看任何一张小表都发现不了违规,必须把表拼起来才能检查。 | 允许存在,但会增加维护成本。 |
| 判断类型 | 核心逻辑 | 快速判断技巧 | 结果含义 |
|---|---|---|---|
| 无损分解 | 自然连接 = 原表 | 两表分解:交集 → 差集 多表分解:画表格法 (Chase) |
✅ 必须 YES ❌ NO 则不可用 |
| 保持依赖 | 局部依赖并集 = 全局依赖 | 检查每个 X→Y 是否在同一子表,或通过子表间传递可推导 | ✅ 最好 YES ⚠️ NO 也可接受 (需应用层约束) |
解题小贴士
1、先算无损:如果是选择题,通常先利用“交集推差集”排除掉有损的选项。
2、再算依赖:对于剩下的选项,看有没有明显的依赖被切断(比如 A \rightarrow BA→B ,但 AA 在表 1, BB 在表 2,且中间没有桥梁)。
3.5 并发与事务
1、事务四大特性
(操作)原子性:要么全做,要么全不做。
(数据)一致性:事务发生后数据是一致的,例如银行转账,不会存在A账户转出,但是B账户没收到的情况。
(执行)隔离性:任一事务的更新操作直到其成功提交的整个过程对其他事务都是不可见的,不同事务之间是隔离的,互不干涉。
(改变)持续性:事务操作的结果是持续性的。
2、并发控制导致的问题
| 问题类型 | 发生场景 | 关键特征 | 是否涉及“未提交”数据 |
|---|---|---|---|
| 丢失更新 | 两个事务同时写同一数据 | 后提交者覆盖前者 → 更新丢失 | ❌ 否(都是已提交) |
| 不可重复读 | 一事务读→其他事务改→再读 | 同一事务内两次读取结果不一致 | ❌ 否(对方已提交) |
| 读脏数据 | 一事务读→其他事务改但未提交→回滚 | 读到的是中间临时状态 → 数据无效 | ✅ 是(对方未提交) |
3.6、分布式数据库
1、分布透明性
分片透明性:用户或应用程序不需要知道逻辑上访问的表具体是如何分块存储的。
位置透明性:应用程序不关心数据存储物理位置的改变。
逻辑透明性:用户或应用程序无需知道局部使用的是哪种数据模型。
复制透明性:用户或应用程序不关心复制的数据从何而来。
2、两阶段提交协议:表决阶段、执行阶段。
3、分布式数据库体系结构图
全局外模式:是对分布式数据库的最高层抽象。
全局概念模式:是分布式数据库的整体抽象,包含数据的特性和逻辑结构,是分布式数据库的全局概念视图。
分片模式:描述全局数据逻辑的划分视图。
分配模式(分布模式):模式局部逻辑的局部物理结构。
3.7、数据仓库
1、数据仓库是一个面向主题的、集成的、非易失的、且随时间变化的数据集合,用于支持管理决策。
2、特点:面向主题、集成的、相对稳定的、反映历史变化。
3、数据仓库的结构通常包含四个层次
- 数据源:是数据仓库系统的基础,是整个系统的数据源泉。
- 数据的存储与管理:是整个数据仓库系统的核心。
- OLAP(联机分析处理)服务器:对分析需要的数据进行有效集成,按多维模型组织,以便进行多角度、多层次的分析,并发现趋势。
- 前端工具:主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具以及各种基于数据仓库或数据集市的应用开发工具。
4、BI 系统主要包括数据预处理、建立数据仓库、数据分析和数据展现四个主要阶段。
(1)数据预处理:数据的抽取、转换和装载。
(2)建立数据仓库:用于处理海量数据。
(3)数据分析:一般采用OLAP(联机分析处理)和数据挖掘技术。联机分析处理能实现数据的上卷、下钻和选择分析。数据挖掘能利用隐藏的知识,通过建立分析模型预测企业未来的发展趋势。
(4)数据展示:完成数据处理的可视化。
3.8、redis缓存数据库
1、主从同步机制
全局同步
增量同步
4、计算机网络(3-5)
4.1、网络功能和分类
1、计算机网络的功能:数据通信、资源共享、管理集中化、实现分布式处理、负载均衡。
2、网络性能指标:速率、带宽(频带宽度或传送线路速率)、吞吐量、时延、往返时间、利用率。
3、网络非性能指标:费用、质量、标准化、可靠性、可扩展性、可升级性、易管理性和可维护性。
4、网络类型:总线型(利用率低、干扰大、价格低)、星型(交换机组成的局域网、中央单元负荷大)、环型(流动方向固定、效率低扩充难)、树型(总线型的扩充、分级结构)、分布式(任意节点连接、管理难成本高)。
5、OSI七层模型
| 层 | 功能 | 单位 | 协议 | 设备 |
|---|---|---|---|---|
| 1. 物理层 | 在链路上透明地传输位。需要完成的工作包括线路配置、确定数据传输模式、确定信号形式、对信号进行编码、连接传输介质。为此定义了建立、维护和拆除物理链路所具备的机械特性、电气特性、功能特性以及规程特性。 | 比特 | EIA/TIA RS-232、RS-449、V.35、RJ-45、FDDI | 中继器、集线器 |
| 2. 数据链路层 | 把不可靠的信道变为可靠的信道。为此将比特组成帧,在链路上提供点到点的帧传输,并进行差错控制、流量控制等。 | 帧 | SDLC、HDLC、LAPB、PPP、STP、帧中继等、IEEE802、ATM | 交换机、网桥 |
| 3. 网络层 | 在源节点–目的节点之间进行路由选择、拥塞控制、顺序控制、传送包,保证报文的正确性。网络层控制着通信子网的运行,因而它又称为通信子网层。 | IP分组 | IP、ICMP、IGMP、ARP、RARP | 路由器 |
| 4. 传输层 | 提供端–端间可靠的、透明的数据传输,保证报文顺序的正确性、数据的完整性。 | 报文段 | TCP、UDP | 网关 |
| 5. 会话层 | 建立通信进程的逻辑名字与物理名字之间的联系,提供进程之间建立、管理和终止会话的方法,处理同步与恢复问题。 | — | RPC、SQL、NFS | 网关 |
| 6. 表示层 | 实现数据转换(包括格式转换、压缩、加密等),提供标准的应用接口、公用的通信服务、公共数据表示方法。 | — | JPEG、ASCII、GIF、MPEG、DES | 网关 |
| 7. 应用层 | 对用户不透明的提供各种服务,如E-mail。 | 数据 | Telnet、FTP、HTTP、SMTP、POP3、DNS、DHCP等 | 网关 |
4.2、 TCP/IP协议
1、网络协议三要素:语法、语义、时序。
2、网络层协议:
IP:网络层最重要的核心协议,在源地址和目的地址之间传送数据报,无连接、不可靠。
ICMP:因特网控制报文协议,用于在 IP 主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。
ARP 和 RARP:地址解析协议,ARP 是将 IP 地址转换为物理地址,RARP 是将物理地址转换为 IP 地址。
IGMP:网络组管理协议,允许因特网中的计算机参加多播,是计算机用做向相邻多目路由器报告多目组成员的协议,支持组播。
3、传输层协议:
TCP:整个 TCP/IP 协议族中最重要的协议之一,在 IP 协议提供的不可靠数据基础上,采用了重发技术,为应用程序提供了一个可靠的、面向连接的、全双工的数据传输服务。一般用于传输数据量比较少,且对可靠性要求高的场合。
UDP:是一种不可靠、无连接的协议,有助于提高传输速率,一般用于传输数据量大,对可靠性要求不高,但要求速度快的场合
4、应用层协议:
基于 TCP 的 FTP、HTTP 等都是可靠传输。
基于 UDP 的 DHCP、DNS 等都是不可靠传输。
FTP:可靠的文件传输协议,用于因特网上的控制文件的双向传输。
HTTP:超文本传输协议,用于从 WWW 服务器传输超文本到本地浏览器的传输协议。使用 SSL 加密后的安全网页协议为 HTTPS。
SMTP 和 POP3:简单邮件传输协议,是一组用于由源地址到目的地址传送邮件的规则,邮件报文采用 ASCII 格式表示。
Telnet:远程连接协议,是因特网远程登录服务的标准协议和主要方式。
TFTP:不可靠的、开销不大的小文件传输协议。
SNMP:简单网络管理协议,由一组网络管理的标准协议,包含一个应用层协议、数据库模型和一组资源对象。该协议能够支持网络管理系统,泳衣监测连接到网络上的设备是否有任何引起管理员行关注的情况。(注:“泳衣”应为“用以”,属原文笔误)
DHCP:动态主机配置协议,基于 UDP,基于 C/S 模型,为主机动态分配 IP 地址,有三种方式:固定分配、动态分配、自动分配。
DNS:域名解析协议,通过域名解析出 IP 地址。
5、对应端口号
6、ip地址分类

7、子网划分
子网划分:主机数之间相差太大了,不利于分配,我们一般采用子网划分的方法来划分网络:即自定义网络号位数,就能自定义主机号位数,就能根据主机个数来划分出最适合的方案,不会造成资源的浪费。
将主机号拿出几位作为子网号,就可以划分出多个子网。此时 IP 地址组成为:网络号 + 子网号 + 主机号。
网络号和子网号都为1,主机号都为0 → 这样的地址为子网掩码。
因此:
→ 主机数需要 -2(减去网络地址和广播地址)
→ 而子网数不用减(现代设备支持全0/全1子网)
8、子网计算
4.3、传输介质
1、双绞线分类:无屏蔽双绞线 UTP和屏蔽双绞线 STP。
无屏蔽双绞线 UTP:价格低,安装简单,但可靠性相对较低。
屏蔽双绞线 STP:比之 UTP 增加了一层屏蔽层,可以有效的提高可靠性,但对应的价格高,安装麻烦,一般用于对传输可靠性要求很高的场合。
2、网线类型
3、光纤类型
多模光纤 MMF:纤芯半径较大,因此可以同时传输多种不同的信号。光信号在光纤中以全反射的形式传播。采用发光二极管 LED作为光源。成本低,但传输效率和可靠性较低。适合短距离传输。
单模光纤 SMF:纤芯半径很小,一般只能传输一种信号模式。采用激光二极管 LD作为光源。只支持激光信号的传播。同样以全反射形式传播,但反射角很大,看起来像一条直线。成本高,但传输距离远、可靠性高。
4、通信方向:数据通信是指发送方发送数据到接收方,这个传输过程可以分类如下:
单工:只能由设备 A 发给设备 B,即数据流只能单向流动。
半双工:设备 A 和设备 B 可以互相通信,但是同一时刻数据流只能单向流动。
全双工:设备 A 和设备 B 在任意时刻都能互相通信。
5、传输方式
| 特性 | 串行传输 | 并行传输 |
|---|---|---|
| 数据线数量 | 1 根 | 多根 |
| 传输方式 | 1bit 依次发送 | 多bit 同时发送 |
| 适用场景 | 远距离、低速、广域网 | 短距离、高速、机内通信 |
| 典型应用 | USB、RS-232、以太网 | PCI 总线、内存总线、IDE |
6、交换方式
◆ 电路交换:通信一方进行呼叫,另一方接收后,在二者之间会建立一个专用电路。
特点为:面向连接、实时性高、链路利用率低,一般用于语音视频通信。
◆ 报文交换:以报文为单位,采用存储转发模式,有延时,但可靠性高,是面向无连接的。
◆ 分组交换:以分组为单位,也是存储转发模式。
因为分组长度比报文小,所以时延小于报文交换。
又可分为三种方式:
(1) 数据报:是当前主流的交换方式。各个分组携带地址信息,自由选择不同的路由路径传送到接收方。
接收方收到分组后再根据地址信息重新组装成原数据。
→ 面向无连接的,但是不可靠的。
(2)虚电路:
发送方发送一个分组,接收方收到后,二者之间就建立了一个虚拟的通信线路。
之后所有分组都通过这条线路传送;空闲时该线路也可传输其他数据。
→ 面向连接的,可靠的。
(3)信元交换:异步传输模式 ATM 采用的交换方式。
本质是按照虚电路方式进行转发,只不过信元是固定长度的分组。
4.4、网络规划与设计
1、三层模型将网络划分为核心层、汇聚层和接入层,每一层都有着特定的作用。
核心层:提供不同区域之间的最佳路由和高速数据传送;(转发)
汇聚层:将网络业务连接到接入层,并且实施与安全、流量、负载和路由相关的策略;
接入层:为用户提供了在本地网段访问应用系统的能力,还要解决相邻用户之间的互访需要。
2、建筑物综合布线系统PDS
4.5、廉价磁盘冗余阵列
◆ RAID即磁盘冗余阵列技术:将数据分散存储在不同磁盘中,可并行读取,可冗余存储,提高磁盘访问速度,保障数据安全性。
◆ RAID0:
将数据分散存储在不同磁盘中;磁盘利用率100%;访问速度最快;但没有提供冗余和错误修复技术 → 任一磁盘损坏,全部数据丢失!
◆ RAID1:
在成对的独立磁盘上产生互为备份的数据;增加存储可靠性,支持纠错/容错;
❗但磁盘利用率只有50%(一半空间用于镜像)。
◆ RAID5:
在所有磁盘上交叉存储数据及奇偶校验信息。(存储校验信息的盘是最小的)
→ 所有校验信息的总容量 = 一个磁盘的容量,
→ 但这些校验信息是分布式存储在不同的磁盘上(非集中存放)。
→ 支持读/写指针同时操作 → 提升并发性能。
4.6、其他
1、SDN 是 Software-Defined Networking(软件定义网络)的网络架构中包含:控制层、转发层和应用层。
5、系统配置和性能评价(1-2)
5.1、性能指标
1、 计算机
时钟频率(主频);运算速度;运算精度;内存的存储容量;存储器的存取周期;数据处理速率 PDR(processing data rate);吞吐量;各种响应时间;各种利用率;RASIS 特性(即:可靠性 Reliability、可用性 Availability、可维护性 Serviceability、完整性和安全性 Integrity and Security);平均故障响应时间;兼容性;可扩充性;性能价格比。
2、 路由器
设备吞吐量、端口吞吐量、全双工线速转发能力、背靠背帧数、路由表能力、背板能力、丢包率、时延、时延抖动、VPN 支持能力、内部时钟精度、队列管理机制、端口硬件队列数、分类业务带宽保证、RSVP、IP Diff Serv、CAR 支持、冗余、热插拔组件、路由器冗余协议、网管、基于 Web 的管理、网管类型、带外网管支持、网管粒度、计费能力 / 协议、分组语音支持方式、协议支持、语音压缩能力、端口密度、信令支持。
3、 网络
设备级性能指标;网络级性能指标;应用级性能指标;用户级性能指标;吞吐量。
4、操作系统
系统的可靠性、系统的吞吐率(量)、系统响应时间、系统资源利用率、可移植性。
5、数据库管理系统
衡量数据库管理系统的主要性能指标包括数据库本身和管理系统两部分,有:数据库的大小、数据库中表的数量、单个表的大小、表中允许的记录(行)数量、单个记录(行)的大小、表上所允许的索引数量、数据库所允许的索引数量、最大并发事务处理能力、负载均衡能力、最大连接数等等。
6、WEB服务器
最大并发连接数、响应延迟、吞吐量。
5.2、性能评价方法
1、性能评测的常用方法:时钟频率、指令执行速度、等效指令速度法、数据处理速率法。
2、基准程序法
把应用程序中用得最多、最频繁的那部分核心程序作为评价计算机性能的标准程序,称为基准测试程序。
(1)整数测试程序
(2)浮点测试程序
(3)SPEC 基准程序
(4)TPC 基准程序:TPC-C → 在线事务处理的基准程序,TPC-D → 决策支持的基准程序,TPC-E → 作为大型企业信息服务的基准程序
3、评价程序的准确程度排序
评测的准确程度依次递减:真实的程序 > 核心程序 > 小型基准程序 > 合成基准程序(最小)
4、阿姆达尔公式
6、信息系统基础知识(3)
6.1、信息系统概述
1、信息系统是由计算机硬件、网络和通信设备、计算机软件、信息资源、信息用户和规章制度组成的以处理信息流为目的的人机一体化系统。
2、信息系统的5个基本功能:输入、存储、处理、输出和控制。
3、诺兰模型:信息系统进化的阶段模型。将计算机信息系统的发展道路划分为6个阶段:
(1)、初始阶段:计算机刚进入企业时只作为办公设备使用,应用非常少。一般仅用于财务部门。
(2)、传播阶段:企业对计算机有了一定了解,想利用计算机解决工作中的问题,比如进行更多的数据处理,给管理工作和业务带来便利。会大幅度增加软件投入,盲目投入产生问题,效率低。
(3)、控制阶段:从整体上控制计算机信息系统的发展,在客观上要求组织协调、解决数据共享问题。信息系统呈现单点、分散的特点,系统和资源利用率不高。是计算机管理变为数据管理的关键。
(4)、集成阶段:在控制的基础上,企业开始重新进行规划设计,建立基础数据库,并建成统一的信息管理系统。使人、财、物等资源信息能够在企业集成共享,更有效地利用现有的IT系统和资源。
(5)、数据管理阶段:企业高层意识到信息战略的重要,信息成为企业的重要资源,企业的信息化建设也真正进入到数据处理阶段。使用统一平台,各部门、各系统基本实现资源整合和信息共享。
(6)、成熟阶段:信息系统已经可以满足企业各个层次的需求,从简单的事务处理到支持高效管理的决策。企业真正把IT与管理过程结合起来,将组织内部、外部的资源充分整合和利用。
4、信息系统的分类(低级到高级)
(1)、业务(数据)处理系统(TPS/DPS):随着企业业务需求的增长和技术条件的发展,人们逐步将计算机应用于企业局部业务(数据)的管理,如财会管理、销售管理、物资管理和生产管理等,即计算机应用发展到对企业的局部事务的管理。
(2)、管理信息系统(MIS):由人和计算机等组成的,能进行管理信息的收集、传输、存储、加工、维护和使用的系统。形成了对企业全局性的、整体性的计算机应用。能提供企业各级领导从事管理需要的信息,但其收集信息的范围还更多地侧重于企业内部。
(3)、决策支持系统(DSS):帮助决策者利用数据和模型去解决半结构化决策问题和非结构化决策问题的交互式系统。服务于高层决策的管理信息系统,按功能可分为专用DSS、DSS工具和DSS生成器。
(4)、专家系统(ES):一个智能计算机程序系统,其内部含有某个领域具有专家水平的大量知识与经验,能够利用人类专家的知识和解决问题的方法来处理该领域的问题。
(5)、办公自动化系统(OAS):人机结合的综合性办公事务管理系统,或称办公事务处理系统。该系统将当代各种先进技术和设备应用于办公室的办公活动中,使办公活动实现科学化、自动化,以达到改善工作环境、最大限度地提高办公事务工作质量和工作效率。
5、目前企业主要使用的信息化系统主要有ERP系统(企业资源管理)、WMS系统(仓储管理系统)、MES系统(也称之为SFC,即制造过程管理系统)和产品数据管理系统(PDM)。
6、信息系统的生命周期(产生、开发、运行、消亡)
(1)信息系统的产生阶段,也是信息系统的概念阶段或者是信息系统的需求分析阶段。这一阶段又分为两个过程,一是概念的产生过程,即根据企业经营管理的需要,提出建设信息系统的初步想法;二是需求分析过程,即对企业信息系统的需求进行深入地调研和分析,并形成需求分析报告。
(2)、信息系统的开发阶段:最重要、关键的阶段。包括总体规划、系统分析、系统设计、系统实施和系统验收这5个阶段。
- 总体规划阶段。信息系统总体规划是系统开发的起始阶段,它的基础是需求分析。作用主要有:指明信息系统在企业经营战略中的作用和地位;指导信息系统的开发;优化配置和利用各种资源,包括内部资源和外部资源。总体规划产出包括信息系统的开发目标、信息系统的总体架构、信息系统的组织结构和管理流程、信息系统的实施计划、信息系统的技术规范等。
- 系统分析阶段。目标是为系统设计阶段提供系统的逻辑模型。以企业的业务流程分析为基础,规划即将建设的信息系统的基本架构,它是企业的管理流程和信息流程的交汇点。内容主要包括组织结构及功能分析、业务流程分析、数据和数据流程分析、系统初步方案等。
- 系统设计阶段。根据系统分析的结果,设计出信息系统的实施方案。主要内容包括系统架构设计、数据库设计、处理流程设计、功能模块设计、安全控制方案设计、系统组织和队伍设计、系统管理流程设计等。
- 系统实施阶段。将设计阶段的结果在计算机和网络上具体实现,也就是将设计文本变成能在计算机上运行的软件系统。由于系统实施阶段是对以前的全部工作的检验,因此,系统实施阶段用户的参与特别重要。系统实施阶段以后,用户逐步变为系统的主导地位。
- 系统验收阶段。信息系统实施阶段结束以后,系统就要进入试运行。通过试运行,系统性能的优劣以及是否做到了用户友好等问题都会暴露在用户面前,这时就进入了系统验收阶段。
7、信息系统建设的原则:高层管理人员介入原则、用户参与开发原则、自顶向下规划原则、工程化原则、其他原则(创新性,整体性,发展性,经济性等)。
8、信息化需求:
(1)战略需求:关注的是组织如何通过信息化提升核心竞争力、实现长远发展目标。
(2)运作需求:这是连接战略与技术的桥梁,属于业务落地层面的需求。它关注的是为了实现战略目标,具体的业务过程、管理流程和组织结构需要发生什么变化。
(3)技术需求:系统在技术层面必须具备的能力、性能指标和基础设施要求。
9、信息化主要内容
- 信息技术的应用
- 信息资源
- 信息网络
- 信息技术和产业
- 信息化人才
- 信息化政策法规和标准规范
6.2、信息系统开发方法
1、结构化方法
由结构化分析(SA)、结构化设计(SD)和结构化程序设计(SP)三部分有机组合而成,其精髓是自顶向下、逐步求精和模块化设计。
结构化方法的主要特点
(1)开发目标清晰化。结构化方法的系统开发遵循“用户第一”的原则。
(2)开发工作阶段化。每个阶段工作完成后,要根据阶段工作目标和要求进行审查,这使各阶段工作有条不紊地进行,便于项目管理与控制。
(3)开发文档规范化。结构化方法每个阶段工作完成后,要按照要求完成相应的文档,以保证各个工作阶段的衔接与系统维护工作的遍历。
(4)设计方法结构化。在系统分析与设计时,从整体和全局考虑,自顶向下地分解;在系统实现时,根据设计的要求,先编写各个具体的功能模块,然后自底向上逐步实现整个系统。
◆ 结构化方法的不足和局限
(1)开发周期长:按顺序经历各个阶段,直到实施阶段结束后,用户才能使用系统。
(2)难以适应需求变化:不适用于需求不明确或经常变更的项目。
(3)很少考虑数据结构:结构化方法是一种面向数据流的开发方法,很少考虑数据结构。
◆ 结构化方法一般利用图形表达用户需求,常用工具有数据流图、数据字典、结构化语言、判定表以及判定树等。
2、原型化方法。也称为快速原型法,或者简称为原型法。它是一种根据用户初步需求,利用系统开发工具,快速地建立一个系统模型展示给用户,在此基础上与用户交流,最终实现用户需求的信息系统快速开发的方法。
原型法可以使系统开发的周期缩短、成本和风险降低、速度加快,获得较高的综合开发效益。
◆ 原型法是以用户为中心来开发系统的,用户参与的程度大大提高,开发的系统符合用户的需求,因而增加了用户的满意度,提高了系统开发的成功率。
◆ 由于用户参与了系统开发的全过程,对系统的功能和结构容易理解和接受,有利于系统的移交,有利于系统的运行与维护。
◆ 原型法的不足之处:开发的环境要求高。管理水平要求高。
3、面向对象方法
◆ 使用 OO 方法构造的系统具有更好的复用性,其关键在于建立一个全面、合理、统一的模型。
◆ 面向对象方法可以普遍适用于各类信息系统的开发。
◆ 当前,一些大型信息系统的开发,通常是将结构化方法和 OO 方法结合起来。
**4、面向服务的方法。**面向服务(Service-Oriented,SO)的方法:进一步将接口的定义与实现进行解耦,则催生了服务和面向服务(Service-Oriented, SO)的开发方法。
◆ 从应用的角度来看,组织内部、组织之间各种应用系统的互相通信和互操作性直接影响着组织对信息的掌握程度和处理速度。如何使信息系统快速响应需求与环境变化,提高系统可复用性、信息资源共享和系统之间的互操作性,成为影响信息化建设效率的关键问题,而 SO 的思维方式恰好满足了这种需求。
6.3、信息系统
1、业务处理系统TPS: 又可称为电子数据处理系统(EDP),最初级形式的信息系统。
(1)由于TPS的主要功能就是对企业管理中日常事务所发生的数据进行输入、处理和输出。因此,TPS的数据处理周期由5个阶段构成:数据输入、数据处理、数据库的维护、文件报表的生成和查询处理。
(2) 特点:TPS 是其他类型信息系统的信源产生器,企业在推进全面信息化的过程中往往是从开发 TPS 入手的。许多 TPS 是处于企业系统的边界,它是将企业与外部环境联系起来的“桥梁”。因此,TPS 性能的好坏将直接影响着组织的整体形象,是提高企业市场竞争力的重要因素。由于 TPS 面对的是结构化程度很高的管理问题,因此可以采用结构化生命周期法来进行开发。
2、管理信息系统MIS
◆ 由业务处理系统发展而成的,是在TPS基础上引进大量管理方法对企业整体信息进行处理,并利用信息进行预测、控制、计划、辅助企业全面管理的信息系统。
◆ 管理信息系统由四大部件组成,即信息源、信息处理器、信息用户和信息管理者。
◆ 根据各部件之间的联系可分为开环(不收集外部信息不反馈)和闭环(不断收集信息反馈调整)。
◆ 根据处理的内容及决策的层次来看,我们可以把管理信息系统看成一个金字塔式的结构。分为战略计划、管理控制和运行控制3层。
◆ 管理信息系统的功能:职能的完成往往是通过“过程”实现,过程是逻辑上相关活动的集合,因而往往把管理信息系统的功能结构表示成功能-过程结构,如下图。
3、决策支持系统DSS
◆ DSS 应当是一个交互式的、灵活的、适应性强的基于计算机的信息系统,能够为解决非结构化管理问题提供支持,以改善决策的质量。
◆ DSS 的基本模式反映DSS 的形式及其与“真实系统”、人和外部环境的关系,如图所示。其中管理者处于核心地位,运用自己的知识和经验,结合决策支持系统提供的支持,对其管理的“真实系统”进行决策。
◆ DSS的两种基本结构形式是两库结构和基于知识的结构,实际中的DSS 由这两种基本结构通过分解或增加某些部件演变而来。两库结构由数据库子系统、模型库子系统和对话子系统形成三角形分布的结构。
◆ 决策支持系统的总体功能是支持各种层次的人们进行决策。
4、专家系统ES
◆ 基于知识的专家系统简称为专家系统,是人工智能的一个重要分支。
◆ 专家系统不同于传统的应用程序和其他类型的人工智能问题求解程序。主要表现在以下5个方面:
(1)专家系统属于人工智能范畴,其求解的问题是半结构化或非结构化问题。
(2)专家系统模拟的是人类专家在问题领域的推理,而不是模拟问题领域本身。
(3)专家系统由3个要素组成:描述问题状态的综合数据库、存放启发式经验知识的知识库和对知识库的知识进行推理的推理机。三要素分别对应数据级、知识库级和控制级三级知识,而传统应用程序只有数据和程序两级结构。
(4)专家系统处理的问题是实际的问题,而不是纯学术的问题。
(5)从求解手段来看,专家系统专用性强,通用性差。
◆ 人工智能是一个极为广泛的领域,AI 的主要分支有专家系统、机器人技术、视觉系统、自然语言处理、学习系统和神经网络等。
◆ 专家系统的特点:超越时间限制、操作成本低廉、易于传递与复制、处理手段一致(不会因人而异)、善于克服难题、适用特定领域。
◆ 专家系统的组成
(1)知识库。用来存放系统求解实际问题的领域知识。知识库中的知识可分成两类:一类为事实性知识;另一类是启发性知识。
(2)综合数据库。是专家系统在执行与推理过程中用以存放所需要和产生的各种信息的工作存储器,因此,综合数据库又叫动态知识库,其内容在系统运行过程中是不断变化的。相应地把专家系统的知识库称为静态知识库。二者一起构成完整知识库。
(3)推理机。推理机和知识库一起构成专家系统的核心。推理机也被称为控制结构或规则解释器,通常包括推理机制和控制策略,是一组用来控制系统的运行、执行各种任务、根据知识库进行各种搜索和推理的程序模块。
(4)知识获取。主要有两方面功能:一是知识的编辑和求精;二是知识自学习。
(5)解释程序。是面向用户服务的,负责解答用户提出的各种问题。
(6)人机接口。通常包括两部分:一部分是专家系统与用户的接口;另一部分是专家系统与领域专家和知识工程师的接口。
5、办公自动化系统OAS
◆ OAS的主要功能
(1)事务处理。完成办公部分内的大量繁琐事情,又称为事务办公系统,分为单机处理系统和多机处理系统(通信、信息共享)。
(2)信息管理。对信息流的控制管理,主要包括信息的收集、加工、传递、交流、存取、提供、分析、判断、应用和反馈那些办公人员的综合性工作。可称为管理型办公系统,它能将事务型办公系统中各项孤立的事务处理通过信息交换和共享资源联系起来,获得准确、快捷、及时、优质的功效。管理型办公系统是一种分布式的处理系统,具有计算机通信和网络功能。
(3)辅助决策。可称为决策型办公系统,以经理型办公系统提供的大量信息作为决策工作的基础,建立起能综合分析、预测发展、判断利弊的计算机可运行的决策模型,根据原始数据信息,自动做出比较符合实际的决策方案。
◆ 办公自动化系统的组成:计算机设备、办公设备、数据通信及网络设备、软件系统。
6、企业资源规划ERP
◆ 企业有三大资源:物流(物流管理)、资金流(财务管理)、信息流(生产控制管理),现在一般认为人力资源(人力资源管理)是企业第四大资源。
◆ ERP的结构
(1)生产预测。市场需求是企业生存的基础,在ERP中首先需要对市场进行较准确的预测。预测主要用于计划,在ERP的5个层次的计划中,前3个层次计划,即经营计划、生产计划大纲和主生产计划的编制都离不开预测。
(2)销售管理(计划)。销售管理主要是针对企业的销售部门的相关业务进行管理。
(3)经营计划(生产计划大纲)。是根据经营计划的生产目标制定的,是对企业经营计划的细化,用以描述企业在可用资源的条件下,在一定时期中的产量计划。
(4)主生产计划。是对企业生产计划大纲的细化,说明在一定时期内的下计划:生产什么,生产多少和什么时候交货。主生产计划的编制以生产大纲为准,其汇总结果应当等同于生产计划大纲。
(5)物种需求计划。物料需求计划是对主生产计划的各个项目所需的全部制造件和全部采购件的网络支持计划和时间进度计划。它根据主生产计划对最终产品的需求数量和交货期,推导出构成产品的零部件及材料的需求数量和需求时期,再导出自制零部件的制作订单下达日期和采购件的采购订单发送日期,并进行需求资源和可用能力之间的进一步平衡。
(6)能力需求计划。是对物料需求计划所需能力进行核算的一种计划管理方法。旨在通过分析比较 MRP 的需求和企业现有生产能力,及早发现能力的瓶颈所在,为实现企业的生产任务而提供能力方面的保障。
(7)车间作业计划。是在MRP所产生的加工制造订单(即自制零部件生产计划)的基础上,按照交货期的前后和生产优先级选择原则以及车间的生产资源情况(如设备、人员、物料的可用性、加工能力的大小等),将零部件的生产计划以订单的形式下达给适当的车间。
(8)采购与库存管理。采购与库存管理是ERP的基本模块,其中采购管理模块是对采购工作,即从采购订单产生至货物收到的全过程进行组织、实施与控制,库存管理模块则是对企业物料的进、出、存进行管理。
(9)质量与设备管理。质量管理贯穿于企业管理的始终。设备管理是指依据企业的生产经营目标,通过一系列的技术、经济和组织措施,对设备寿命周期内的所有设备物资运动形态和价值运动形态进行的综合管理。
(10)财务管理。会计工作是企业管理的重要组成部分,是以货币的形式反映和监督企业的日常经济活动,并对这些经济业务的数据进行分类、汇总,以便为企业管理和决策提供必要的信息支持。企业财务管理是企业会计工作和活动的统称。
(11)ERP有关扩展应用模块。如客户关系管理、分销资源管理、供应链管理和电子商务等。这几个扩展模块本身也是一个独立的系统,在市场上它们常作为独立的软件产品进行出售和实施。
◆ ERP的功能:支持决策的功能、为处于不同行业的企业提供有针对性的IT解决方案、从企业内部的供应链发展为全行业和跨行业的供应链。
7、政府信息化和电子政务
◆ 电子政务的内容:G2G、G2B、G2C、B2G、C2G。G(government政府),B(business企业),C(citizen居民)
8、信息系统战略规划
9、电子商务
(1)B2B模式,企业对企业。
(2)B2C模式,企业对消费者。
(3)C2C,消费者对消费者。
(4)O2O即Online To Offline,含义是线上购买线下的商品和服务,实体店提货或享受服务。
9、企业应用集成EAI
1、集成类型
(1)表示集成:即界面集成,是最原始的集成,黑盒集成。将多个信息系统的界面集成在一起,统一入口,为用户提供一个看上去统一,但是由多个系统组成的应用系统的集成,例如桌面。
(2)数据集成:白盒集成,把不同来源、格式、特点性质的数据在逻辑上或者物理上有机的集中,从而为企业提供全面的数据共享。如数据仓库。
(3)控制集成(功能集成、应用集成):黑盒集成,业务逻辑层次的集成,可以借助于远程过程调用或远程方法调用、面向消息的中间件等技术,将多个应用系统功能进行绑定,使之像一个实时运行的系统一样接受信息输入和产生数据输出,实现多个系统功能的叠加。如钉钉。
(4)业务流程集成:即过程集成,最彻底的、综合的集成,这种集成超越了数据和系统,由一系列基于标准的、统一数据格式的工作流组成。当进行业务流程集成时,企业必须对各种业务信息的交换进行定义、授权和管理,以便于改进操作、减少成本、提高响应速度。
2、企业集成平台基本功能
(1)通信服务:它提供分布环境下透明的同步/异步通信服务功能,使用户和应用程序无需关心具体的操作系统和应用程序所处的网络物理位置,而以透明的函数调用或对象服务方式完成它们所需的通信服务要求。
(2)信息集成服务:它为应用提供透明的信息访问服务,通过实现异种数据库系统之间数据的交换、互操作、分布数据管理和共享信息模型定义(或共享信息数据库的建立),使集成平台上运行的应用、服务或用户端能够以一致的语义和接口实现对数据(数据库、数据文件、应用交互信息)的访问与控制。
(3)应用集成服务:它通过高层应用编程接口来实现对相应应用程序的访问,这些高层应用编程接口包含在不同的适配器或代理中,它们被用来连接不同的应用程序。
(4)二次开发工具:是集成平台提供的一组帮助用户开发特定应用程序(如实现数据转换的适配器或应用封装服务等)的支持工具,其目的是简化用户在企业集成平台实施过程中(特定应用程序接口)的开发工作。
(5)平台运行管理工具:它是企业集成平台的运行管理和控制模块,负责企业集成 平台系统的静态和动态配置、集成平台应用运行管理和维护、事件管理和出错管理等。
3、提供的服务从下至上为:通信服务、信息传递与转化服务、应用连接服务、流程控制服务。
7、系统安全(2-4)
7.1、安全概述
1、 信息安全包括5个基本要素:机密性、完整性、可用性、可控性与可审查性。
(1)机密性:确保信息不暴露给未授权的实体或进程。
(2)完整性:只有得到允许的人才能修改数据,并且能够判别出数据是否已被篡改。
(3)可用性:得到授权的实体在需要时可访问数据,即攻击者不能占用所有的资源而阻碍授权者的工作。
(4)可控性:可以控制授权范围内的信息流向及行为方式。
(5)可审查性:对出现的信息安全问题提供调查的依据和手段。
2、信息安全的范围包括:设备安全、数据安全、内容安全和行为安全。
(1)信息系统设备的安全是信息系统安全的首要问题,是信息系统安全的物质基础,它包括3个方面:设备的稳定性、可靠性、可用性。
(2)数据安全即采取措施确保数据免受未授权的泄露、篡改和毁坏,包括3个方面:数据的秘密性、完整性、可用性。
(3)内容安全是信息安全在政治、法律、道德层次上的要求,包括3个方面:信息内容政治上健康、符合国家法律法规、符合道德规范。
(4)信息系统的服务功能是指最终通过行为提供给用户,确保信息系统的行为安全,才能最终确保系统的信息安全。行为安全的特性包括:行为的秘密性、完整性、可控性。
3、信息的存储安全包括:信息使用的安全、系统安全监控、计算机病毒防治、数据的加密和防止非法的攻击等。
4、 网络安全
◆ 网络安全隐患体现在:物理安全性、软件安全漏洞、不兼容使用安全漏洞、选择合适的安全哲理。
◆ 网络安全威胁:非授权的访问、信息泄露或丢失、破坏数据完整性、拒绝服务攻击、利用网络传播病毒。
◆ 安全措施的目标:访问控制、认证、完整性、审计、保密。
5、信息安全系统的组成框架
(1)基础安全设备包括密码芯片、加密卡、身份识别卡等,此外还涵盖运用到物理安全的物理环境保障技术,建筑物、机房条件及硬件设备条件满足信息系统的机械防护安全,通过对电力供应设备以及信息系统组件的抗电磁干扰和电磁泄漏性能的选择性措施达到相应的安全目的。
(2)计算机网络安全指信息在网络传输过程中的安全防范,用于防止和监控未经授权破坏、更改和盗取数据的行为。通常涉及物理隔离,防火墙及访问控制,加密传输、认证、数字签名、摘要,隧道及VPN 技术,病毒防范及上网行为管理,安全审计等实现技术。
(3)操作系统安全是指操作系统的无错误配置、无漏洞、无后门、无特洛伊木马等,能防止非法用户对计算机资源的非法存取,一般用来表达对操作系统的安全需求。操作系统的安全机制包括标识与鉴别机制、访问控制机制、最小特权管理、可信通路机制、运行保障机制、存储保护机制、文件保护机制、安全审计机制,等等。
(4)数据库安全可粗略划分为数据库管理系统安全和数据库应用系统安全两个部分,主要涉及物理数据库的完整性、逻辑数据库的完整性、元素安全性、可审计性、访问控制、身份认证、可用性、推理控制、多级保护以及消除隐通道等相关技术。
(5)终端安全设备从电信网终端设备的角度分为电话密码机、传真密码机、异步数据密码机等。
7.2、信息安全技术
1、加密技术
(1)对称加密:数据的加密和解密的密钥(密码)是相同的,属于不公开密钥加密算法。其缺点是加密强度不高(因为密钥位数少),且密钥分发困难(因为密钥还需要传输给接收方,也要考虑保密性等问题)。优点是加密速度快,适合加密大数据。
加密算法:DES(64位)、3DES(128位)、AES、RC-5、IDEA。
(2)非对称加密:数据的加密和解密的密钥是不同的,分为公钥和私钥。是公开密钥加密算法。其缺点是加密速度慢。优点是安全性高,不容易破解。
加密算法:RSA(512位或1024位)、Elgamal、ECC、D-H。
◆ 非对称技术的原理是:发送者发送数据时,使用接收者的公钥作加密密钥,私钥作解密密钥,这样只有接收者才能解密密文得到明文。安全性更高,因为无需传输密钥。但无法保证完整性。
2、信息摘要
◆ 信息摘要:就是一段数据的特征信息,当数据发生了改变,信息摘要也会发生改变,发送方会将数据和信息摘要一起传给接收方,接收方会根据接收到的数据重新生成一个信息摘要,若此摘要和接收到的摘要相同,则说明数据正确。信息摘要是由哈希函数生成的。(防止篡改)
◆ 信息摘要的特点:不算数据多长,都会产生固定长度的信息摘要;任何不同的输入数据,都会产生不同的信息摘要;单向性,即只能由数据生成信息摘要,不能由信息摘要还原数据。
◆ 信息摘要算法:MD5(产生128位的输出)、SHA-1(安全散列算法,产生160位的输出,安全性更高)。
3、数字签名
◆ 数字签名:唯一标识一个发送方。
发送者发送数据时,使用发送者的私钥进行加密,接收者收到数据后,只能使用发送者的公钥进行解密,这样就能唯一确定发送方,这也是数字签名的过程。但无法保证机密性。
◆ 数字签名首先需要生成消息摘要,生成消息摘要的目的是防止篡改,对摘要进行加密的目的是防止抵赖。
4、公钥基础设施PKI
◆ 公钥基础设施PKI:是以非对称密钥加密技术为基础,以数据机密性、完整性、身份认证和行为不可抵赖性为安全目的,来实施和提供安全服务的具有普适性的安全基础设施。
(1)数字证书:一个数据结构,是一种由一个可信任的权威机构签署的信息集合。
公钥证书主要用于确保公钥及其与用户绑定关系的安全。这个公钥就是证书所标识的那个主体的合法的公钥。
(2)签证机构CA:负责签发证书、管理和撤销证书。是所有注册用户所信赖的权威机构,CA在给用户签发证书时要加上自己的数字签名,以保证证书信息的真实性。任何机构可以用CA的公钥来验证该证书的合法性。
5、访问控制
◆ 访问控制是指主体依据某些控制策略或权限对客体本身或是其资源进行的不同授权访问。访问控制包括3个要素,即主体、客体和控制策略。
(1)访问控制矩阵(ACM):是通过矩阵形式表示访问控制规则和授权用户权限的方法。主体作为行,客体作为列。
(2)访问控制表(ACL):目前最流行、使用最多的访问控制实现技术。每个客体有一个访问控制表,是系统中每一个有权访问这个客体的主体的信息。这种实现技术实际上是按列保存访问矩阵。
(3)能力表:对应于访问控制表,这种实现技术实际上是按行保存访问矩阵。
(4)授权关系表:每一行(或者说元组)就是访问矩阵中的一个非空元素,是某一个主体对应于某一个客体的访问权限信息。如果授权关系表按主体排序,查询时就可以得到能力表的效率;如果按客体排序,查询时就可以得到访问控制表的效率。
7.3、信息安全的抗攻击技术
◆ 为对抗攻击者的攻击,密钥生成需要考虑3个方面的因素:增大密钥空间、选择强钥(复杂的)、密钥的随机性(使用随机数)。
◆ 拒绝服务攻击有许多种,网络的内外部用户都可以发动这种攻击。内部用户可以通过长时间占用系统的内存、CPU处理时间使其他用户不能及时得到这些资源,而引起拒绝服务攻击;外部黑客也可以通过占用网络连接使其他用户得不到网络服务。
◆ 外部用户针对网络连接发动拒绝服务攻击主要有以下几种模式:消耗资源、破坏或更改配置信息、物理破坏或改变网络部件、利用服务程序中的处理错误使服务失效。
◆ 分布式拒绝服务DDoS攻击是传统DoS攻击的发展,攻击者首先侵入并控制一些计算机,然后控制这些计算机同时向一个特定的目标发起拒绝服务攻击。克服了传统DOS受网络资源的限制和隐蔽性两大缺点。
◆ 拒绝服务攻击的防御方式
(1)加强对数据包的特征识别,攻击者发送的数据包中是有一些特征字符串。通过搜寻这些特征字符串,就可以确定攻击服务器和攻击者的位置。
(2)设置防火墙监视本地主机端口的使用情况。如果发现端口处于监听状态,则系统很可能受到攻击。
(3)对通信数据量进行统计也可获得有关攻击系统的位置和数量信息。在攻击时,攻击数据的来源地址会发出超出正常极限的数据量。
(4)尽可能的修正已经发现的问题和系统漏洞。
◆ ARP欺骗
正常ARP原理:如图所示,主机A想知道局域网内主机B的MAC地址,那么主机A就广播发送ARP请求分组,局域网内主机都会收到,但只有B收到解析后知道是请求自己的MAC地址,所以只有B会返回单播的响应分组,告诉A自己的MAC地址。
A收到响应分组后,会建立一个B的IP地址和MAC地址映射,这个映射是动态存在的,如果一定时间AB不再通信,那么就会清空这个地址映射,下次如果还要通信,则重复这个过程。
◆ ARP欺骗原理:上述过程主机A是不管其有没有发送过请求广播分组的,而是只要收到了返回的分组信息,就会刷新IP地址和MAC地址的映射关系,这样就存在安全隐患。假设有主机C,模拟返回分组格式,构造正确的IP地址和自己的MAC地址映射,A收到后也会刷新映射关系,那么当A再次向B发送信息时,实际就发送到了C的MAC地址,数据就被C监听到了。
◆ ARP欺骗的防范措施:
① 在WinXP下输入命令:arp -s gate-way-ip gate-way-mac 固化ARP表,阻止ARP欺骗。
② 使用ARP服务器。通过该服务器查找自己的ARP转换表来响应其他机器的ARP广播。确保这台ARP服务器不被黑。
③ 采用双向绑定的方法解决并且防止ARP欺骗。
④ ARP防护软件——ARPGuard。
◆ DNS欺骗首先是冒充域名服务器,然后把查询的IP地址设为攻击者的IP地址,这样的话,用户上网就只能看到攻击者的主页,而不是用户想要取得的网站的主页了,这就是DNS欺骗的基本原理。也即改掉了域名和IP地址的对应关系。黑客是通过冒充DNS服务器回复查询IP。
◆ DNS欺骗的检测:
① 被动监听检测:通过旁路监听的方式,捕获所有DNS请求和应答数据包,并为其建立一个请求应答映射表。如果在一定的时间间隔内,一个请求对应两个或两个以上结果不同的应答包,则怀疑受到了DNS欺骗攻击。
② 虚假报文探测:采用主动发送探测包的手段来检测网络内是否存在DNS欺骗攻击者。如果向一个非DNS服务器发送请求包,正常来说不会收到任何应答,如果收到了应答包,则说明受到了攻击。
③ 交叉检查查询:在客户端收到DNS应答包之后,向DNS服务器反向查询应答包中返回的IP地址所对应的DNS名字,如果二者一致说明没有受到攻击,否则说明被欺骗。
◆ IP欺骗的原理和流程:
① 首先使被冒充主机host b的网络暂时瘫痪,以免对攻击造成干扰;
② 然后连接到目标机host a的某个端口来猜测ISN基值和增加规律;
③ 接下来把源址伪装成被冒充主机host b,发送带有SYN标志的数据段请求连接;
④ 然后等待目标机host a发送SYN+ACK包给已经瘫痪的主机,因为现在看不到这个包;
⑤ 最后再次伪装成主机host b向目标主机hosta发送的ACK,此时发送的数据段带有预测的目标机的ISN+1;
⑥ 连接建立,发送命令请求。
◆ IP欺骗的防范:虽然IP欺骗攻击有着相当难度,但这种攻击非常广泛,入侵往往由这里开始。预防这种攻击可以删除UNIX中所有的/etc/hosts.equiv、$HOME/.rhosts文件,修改/etc/inetd.conf文件,使得RPC机制无法应用。另外,还可以通过设置防火墙过滤来自外部而信源地址却是内部IP的报文。
◆ 端口扫描就是尝试与目标主机的某些端口建立连接,如果目标主机该端口有回复(见三次握手中的第二次),则说明该端口开放,即为“活动端口”。
◆ 扫描原理分类:
(1) 全TCP连接。这种扫描方法使用三次握手,与目标计算机建立标准的TCP连接。
(2) 半打开式扫描(SYN扫描)。在这种扫描技术中,扫描主机自动向目标计算机的指定端口发送SYN数据段,表示发送建立连接请求。
如果目标计算机的回应TCP报文中SYN=1 ACK=1,则说明该端口是活动的,接着扫描主机传送一个RST给目标主机拒绝建立TCP连接,从而导致三次握手的过程失败。
如果目标计算机的回应是RST,则表示该端口为“死端口”,这种情况下,扫描主机不用做任何回应。
(3) FIN扫描。依靠发送FIN来判断目标计算机的指定端口是否是活动的。
发送一个FIN=1的TCP报文到一个关闭的端口时,该报文会被丢掉,并返回一个RST报文。
但是,如果当FIN报文到一个活动的端口时,该报文只是被简单的丢掉,不会返回任何回应。
从FIN扫描可以看出,这种扫描没有涉及任何TCP连接部分。因此,这种扫描比前两种都安全,可以称之为秘密扫描。
(4) 第三方扫描。第三方扫描又称“代理扫描”,这种扫描是利用第三方主机来代替入侵者进行扫描。这个第三方主机一般是入侵者通过入侵其他计算机而得到的,该“第三方”主机常被入侵者称之为“肉鸡”。这些“肉鸡”一般为安全防御系数极低的个人计算机。
◆ 强化TCP/IP堆栈以抵御拒绝服务攻击
(1)同步包风暴 (SYN Flooding):利用TCP协议缺陷发送大量伪造的TCP连接请求,使得被攻击者资源耗尽。
三次握手,进行了两次,不进行第三次握手,连接队列处于等待状态,大量这样的等待,会占满全部队列空间,使得系统挂起。可以通过修改注册表防御SYN Flooding攻击。
(2)ICMP 攻击。ICMP 协议本身的特点决定了它非常容易被用于攻击网络上的路由器和主机。比如,前面提到的“Ping of Death”攻击就是利用操作系统规定的ICMP数据包的最大尺寸不超过64KB这一规定,达到使TCP/IP堆栈崩溃、主机死机的效果。可以通过修改注册表防御ICMP攻击。
(3)SNMP 攻击。SNMP还能被用于控制这些设备和产品,重定向通信流,改变通信数据包的优先级,甚至断开通信连接。总之,入侵者如果具备相应能力,就能完全接管你的网络。可以通过修改注册表项防御。
系统漏洞扫描指对重要计算机信息系统进行检查,发现其中可能被黑客利用的漏洞。包括基于网络的漏洞扫描(通过网络远程扫描主机)、基于主机的漏洞扫描(在目标系统安装了代理扫描)。
7.4、信息安全的保证体系和评估方法
1、5大等级
◆ 第一级 用户自主保护级:本级的计算机信息系统可信计算基通过隔离用户与数据,使用户具备自主安全保护的能力。本级实施的是自主访问控制,即计算机信息系统可信计算机定义和控制系统中命名用户对命名客体的访问。
◆ 第二级 系统审计保护级:本级的计算机信息系统可信计算基实施了粒度更细的自主访问控制,它通过登录规程、审计安全性相关事件和隔离资源,使用户对自己的行为负责。在自主访问控制的基础上控制访问权限扩散。
◆ 第三级 安全标记保护级:本级的计算机信息系统可信计算基具有系统审计保护级所有功能。此外,还提供有关安全策略模型、数据标记以及主体对客体强制访问控制的非形式化描述;具有准确地标记输出信息的能力;消除通过测试发现的任何错误。本级的主要特征是计算机信息系统可信计算基对所有主体及其所控制的客体(例如:进程、文件、段、设备)实施强制访问控制。
◆ 第四级 结构化保护级:本级的计算机信息系统可信计算基建立于一个明确定义的形式化安全策略模型之上,它要求将第三级系统中的自主和强制访问控制扩展到所有主体与客体。此外,还要考虑隐蔽通道。对外部主体能够直接或间接访问的所有资源(例如:主体、存储客体和输入输出资源)实施强制访问控制。
◆ 第五级 访问验证保护级:本级的计算机信息系统可信计算基满足访问监控器需求。访问监控器仲裁主体对客体的全部访问。访问监控器本身是抗篡改的;必须足够小,能够分析和测试。与第四级相比,自主访问控制机制根据用户指定方式或默认方式,阻止非授权用户访问客体。访问控制的粒度是单个用户。访问控制能够为每个命名客体指定命名用户和用户组,并规定他们对客体的访问模式。没有存取权的用户只允许由授权用户指定对客体的访问权。
2、风险评估的基本要素为脆弱性、资产、威胁、风险和安全措施。
3、风险评估实施前,应该考虑:
(1) 确定风险评估的范围。
(2) 确定风险评估的目标。
(3) 建立适当的组织结构。
(4) 建立系统性的风险评估方法。
(5) 获得最高管理者对风险评估策划的批准。
7.5、网络安全技术和协议
◆ 防火墙是在内部网络和外部因特网之间增加的一道安全防护措施,分为网络级防火墙和应用级防火墙。
◆ 网络级防火墙层次低,但是效率高,因为其使用包过滤和状态监测手段,一般只检验网络包外在(起始地址、状态)属性是否异常,若异常,则过滤掉,不与内网通信,因此对应用和用户是透明的。
◆ 但是这样的问题是,如果遇到伪装的危险数据包就没办法过滤,此时,就要依靠应用级防火墙,层次高,效率低,因为应用级防火墙会将网络包拆开,具体检查里面的数据是否有问题,会消耗大量时间,造成效率低下,但是安全强度高。
◆ 入侵检测系统IDS
防火墙技术主要是分隔来自外网的威胁,却对来自内网的直接攻击无能为力,此时就要用到入侵检测IDS技术,位于防火墙之后的第二道屏障,作为防火墙技术的补充。
◆ 不同于防火墙,IDS入侵检测系统是一个监听设备,没有跨接在任何链路上,无须网络流量流经它便可以工作。因此,对IDS的部署,唯一的要求是:IDS应当挂接在所有所关注流量都必须流经的链路上。因此,IDS在交换式网络中的位置一般选择在:(1) 尽可能靠近攻击源。(2) 尽可能靠近受保护资源。
◆ 入侵防御系统IPS
IDS和防火墙技术都是在入侵行为已经发生后所做的检测和分析,而IPS是能够提前发现入侵行为,在其还没有进入安全网络之前就防御。
在**安全网络之前的链路上挂载入侵防御系统IPS,可以实时检测入侵行为,**并直接进行阻断,这是与IDS的区别,要注意。
◆ 杀毒软件
用于检测和解决计算机病毒,与防火墙和IDS要区分,计算机病毒要靠杀毒软件,防火墙是处理网络上的非法攻击。
◆ 蜜罐系统
伪造一个蜜罐网络引诱黑客攻击,蜜罐网络被攻击不影响安全网络,并且可以借此了解黑客攻击的手段和原理,从而对安全系统进行升级和优化。
◆ 网络协议
◆ SSL协议:安全套接字协议,被设计为加强Web安全传输(HTTP/HTTPS/)的协议,安全性高,和HTTP结合之后,形成HTTPS安全协议,端口号为443。
◆ SSH协议:安全外壳协议,被设计为加强Telnet/FTP安全的传输协议。
◆ SET协议:安全电子交易协议主要应用于B2C模式(电子商务)中保障支付信息的安全性。SET协议本身比较复杂,设计比较严格,安全性高,它能保证信息传输的机密性、真实性、完整性和不可否认性。SET协议是PKI框架下的一个典型实现,同时也在不断升级和完善,如SET 2.0将支持借记卡电子交易。
◆ Kerberos协议:是一种网络身份认证协议,该协议的基础是基于信任第三方,它提供了在开放型网络中进行身份认证的方法,认证实体可以是用户也可以是用户服务。这种认证不依赖宿主机的操作系统或计算机的IP地址,不需要保证网络上所有计算机的物理安全性,并且假定数据包在传输中可被随机窃取和篡改。
7.6、数字信封技术

8、软件工程(12-15)
8.1、软件工程概述
1、软件开发生命周期:
(1)软件定义时期:包括可行性研究和详细需求分析过程,任务是确定软件开发工程必须完成的总目标,具体可分成问题定义、可行性研究、需求分析等。
(2)软件开发时期:就是软件的设计与实现,可分成概要设计、详细设计、编码、测试等。
(3)软件运行和维护:就是把软件产品移交给用户使用。
2、软件系统的文档可以分为用户文档和系统文档两类,用户文档主要描述系统功能和使用方法,并不关系这些功能是怎样实现的;系统文档描述系统设计、实现和测试等各方面的内容。
3、软件工程过程是指为获得软件产品包括以下4个方面活动:
(1) P (Plan) —— 软件规格说明。规定软件的功能及其运行时的限制。
(2) D (Do) —— 软件开发。开发出满足规格说明的软件。
(3) C (Check) —— 软件确认。确认开发的软件能够满足用户的需求。
(4) A (Action) —— 软件演进。软件在运行过程中不断改进以满足客户新的需求。
4、软件系统工具通常可以按软件过程活动将软件工具分为:
软件开发工具:需求分析工具、设计工具、编码与排错工具、测试工具等。需求分析工具可分为基于自然语言或图形描述的工具和形式化需求定义语言的工具。
软件维护工具:版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
软件管理和软件支持工具:项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。
5、软件设计四个活动:数据设计、架构(体系结构)设计、人机界面(接口)设计和过程设计。
- (软件)结构设计:定义软件系统各主要部件之间的关系。
- 数据设计:将模块转换成数据结构的定义。好的数据设计将改善程序结构和模块的划分,降低过程复杂性。
- 人机界面(接口)设计:软件内部,软件和操作系统之间以及软件和人之间如何通信。
- 过程设计:系统结构部件转换成软件的工程描述。
6、软件开发环境(SDE)由软件工具集和环境集成机制构成。
软件开发环境应支持多种集成机制,例如,平台集成、数据集成、界面集成、控制集成和过程集成。
集成机制根据功能的不同,可划分为环境信息库、过程控制与消息服务器、环境用户界面三个部分。
- 环境信息库:是软件开发环境的核心,用于存储与系统开发相关的信息,并支持信息的交流与共享。
- 过程控制与消息服务器:实现过程集成和控制集成的基础。
- 环境用户界面:包括环境总界面和由他实现统一控制的各环境部件及工具的界面。
8.2、能力成熟度模型CMM和CMMI


8.3、软件过程模型
1、瀑布模型(SDLC):瀑布模型是一个经典的软件生命周期模型,一般将软件开发分为:可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码(含单元测试)、测试、运行维护等几个阶段。
瀑布模型特点
(1) 从上一项开发活动接受该项活动的工作对象作为输入。
(2) 利用这一输入,实施该项活动应完成的工作内容。
(3) 给出该项活动的工作成果,作为输出传给下一项开发活动。
(4) 对该项活动的实施工作成果进行评审。若其工作成果得到确认,则继续进行下一项开发活动;否则返回前一项,甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件。
2、螺旋模型
1、螺旋模型是一个演化软件过程模型,将原型实现的迭代特征与线性顺序(瀑布)模型中控制的和系统化的方面结合起来。在螺旋模型中,软件开发是一系列的增量发布。
2、开发过程具有周期性重复的螺旋线状。四个象限分别标志每个周期所划分的四阶段:制订计划、风险分析、实施工程和客户评估。螺旋模型强调了风险分析,特别适用于庞大而复杂的、高风险的系统。

3、原型模型
1、原型化模型第一步就是创建一个快速原型,能够满足项目干系人与未来的用户可以与原型进行交互,再通过与相关干系人进行充分的讨论和分析,最终弄清楚当前系统的需求,进行了充分的了解之后,在原型的基础上开发出用户满意的产品。
2、原型法认为在很难一下子全面准确地提出用户需求的情况下,原型应当具备的特点如下:
(1) 实际可行
(2) 具有最终系统的基本特征
(3) 构造方便、快速,造价低。原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的。
4、V模型
速记:单编、集详、系概、验需。
5、增量模型
1、增量模型:首先开发核心模块功能,而后与用户确认,之后再开发次核心模块的功能,即每次开发一部分功能,并与用户需求确认,最终完成项目开发,优先级最高的服务最先交付。
2、特点:但由于并不是从系统整体角度规划各个模块,因此不利于模块划分。难点在于如何将客户需求划分为多个增量。与原型不同的是,增量模型的每一次增量版本都可作为独立可操作的作品,而原型的构造一般是为了演示。
6、喷泉模型
1、喷泉模型:是一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性。
2、基于构件的开发模型CBSD:利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件,也可以是商品化成品软件构件。
特点是增强了复用性,在系统开发过程中,会构建一个构件库,供其他系统复用,因此可以提高可靠性,节省时间和成本。
7、形式化方法模型
形式化方法模型:建立在严格数学基础上的一种软件开发方法,主要活动是生成计算机软件形式化的数学规格说明。
8、敏捷模型

1、主要敏捷方法:
(1) 极限编程(XP)。基础和价值观是交流、朴素、反馈和勇气,即任何一个软件项目都可以从4个方面入手进行改善:加强交流;从简单做起;寻求反馈;勇于实事求是。
XP 是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期:通过积极的交流、反馈以及其他一系列的方法,开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。
XP提倡测试先行,为了将以后出现bug的几率降到最低。
(2) 水晶系列方法。与XP方法一样,都有以人为中心的理念,但在实践上有所不同。其目的是发展一种提倡“机动性的”方法,包含具有共性的核心元素,每个都含有独特的角色、过程模式、工作产品和实践。
(3) 并列争球法(Scrum)。是一种迭代的增量化过程,把每段时间(如30天)一次的迭代称为一个“冲刺”(Sprint),并按需求的优先级别来实现产品,多个自组织和自治的小组并行地递增实现产品。
(4) 特性驱动开发方法(FDD)。是一个迭代的开发模型。认为有效的软件开发需要3个要素:人、过程和技术。有5个核心过程:开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。
9、统一过程模型(RUP)


10、逆向工程
1、软件复用是将已有软件的各种有关知识用于建立新的软件,以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用,被复用的知识专指程序,后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。
2、逆向工程:软件的逆向工程是分析程序,力图在比源代码更高抽象层次上建立程序的表示过程,逆向工程是设计的恢复过程。逆向工程的四个级别:
实现级:包括程序的抽象语法树、符号表、过程的设计表示。(编码)
结构级:包括反映程序分量之间相互依赖关系的信息,例如调用图、结构图、程序和数据结构。(设计)
功能级:包括反映程序段功能及程序段之间关系的信息,例如数据和控制流模型。(功能)
领域级:包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息,例如E-R模型。(需求)
其中,领域级抽象级别最高,完备性最低;实现级抽象级别最低,完备性最高。
实现级和结构级跟程序员有关,功能级和领域级跟用户有关。
3、重构是指在同一抽象级别上转换系统描述形式。
4、设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
5、再工程是指在逆向工程所获得信息的基础上,修改或重构已有的系统,产生系统的一个新版本。再工程是对现有系统的重新开发过程,包括逆向工程、新需求的考虑过程和正向工程三个步骤。它不仅能从已存在的程序中重新获得设计信息,而且还能使用这些信息来重构现有系统,以改进它的综合质量。在利用再工程重构现有系统的同时,一般会增加新的需求,包括增加新的功能和改善系统的性能。
6、正向工程是指不仅从现有系统中恢复设计信息,而且使用该信息去改变或重构现有系统,以改善其整体质量。
11、软件活动
- 软件描述
- 软件开发
- 软件有效性验证
- 软件演化
8.4、软件需求
1、软件需求:是指用户对系统在功能、行为、性能、设计约束等方面的期望。
是指用户解决问题或达到目标所需的条件或能力,是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力,以及反映这些条件或能力的文档说明。
2、需求类型
业务需求:反映企业或客户对系统高层次的目标要求,通常来自项目投资人、客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。
用户需求:描述的是用户的具体目标,或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式,对用户使用的场景进行整理,从而建立用户需求。
系统需求:从系统的角度来说明软件的需求,包括功能需求、非功能需求和设计约束等。
(1)功能需求:也称为行为需求,规定了开发人员必须在系统中实现的软件功能,用户利用这些功能来完成任务,满足业务需要。
(2)非功能需求:指系统必须具备的属性或品质,又可以细分为软件质量属性(如可维护性、可靠性、效率等)和其他非功能需求。
(3)设计约束:也称为限制条件或补充规约,通常是对系统的一些约束说明,例如必须采用国有自主知识产权的数据库系统,必须运行在UNIX操作系统之下等。
三种需求类型,业务需求最抽象,系统需求最具体。

3、需求获取
需求获取:是一个确定和理解不同的项目干系人的需求和约束的过程。
常见的需求获取法包括:
(1) 用户访谈:1对1-3,有代表性的用户。其形式包括结构化和非结构化两种。
(2) 问卷调查:用户多,无法一一访谈。
(3) 采样:从种群中系统地选出有代表性的样本集的过程。样本数量 = 0.25 × (可信度因子 / 错误率)²
(4) 情节串联板:一系列图片,通过这些图片来讲故事。
(5) 联合需求计划(JRP):通过联合各个关键用户代表、系统分析师、开发团队代表一起,通过有组织的会议来讨论需求。
(6) 需求记录技术:任务卡片、场景说明、用户故事、Volere白卡。

4、需求分析
需求分析:一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性,因此,需要分析人员把杂乱无章的用户要求和期望转化为用户需求,这就是需求分析的工作。
需求分析的任务
(1) 绘制系统上下文范围关系图
(2) 创建用户界面原型
(3) 分析需求的可行性
(4) 确定需求的优先级
(5) 为需求建立模型
(6) 创建数据字典
(7) 使用QFD(质量功能部署)
结构化的需求分析
结构化特点:自顶向下,逐步分解,面向数据。
三大模型:功能模型(数据流图)、行为模型(状态转换图)、数据模型(E-R图) 以及数据字典。



数据字典DD:数据流图描述了系统的分解,但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工,以及组成数据流或文件的数据项做出说明。
常用的加工逻辑描述方法有结构化语言、判定表和判定树3种。
5、需求定义
需求定义(软件需求规格说明书SRS):是需求开发活动的产物,编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解,使之成为整个开发工作的基础。
需求定义方法
(1)严格定义也称为预先定义,需求的严格定义建立在以下的基本假设之上。
(2)原型方法,迭代的循环型开发方式。
6、需求验证
需求验证:也称为需求确认,目的是与用户一起确认需求无误,对需求规格说明书SAS进行评审和测试,包括两个步骤:
需求评审:正式评审和非正式评审。
需求测试:设计概念测试用例。
需求验证通过后,要请用户签字确认,作为验收标准之一,此时,这个需求规格说明书就是需求基线,不可以再随意更新,如果需要更改必须走需求变更流程。
7、需求管理
(1)定义需求基线:通过了评审的需求说明书就是需求基线,下次如果需要变更需求,就需要按照流程来一步步进行。在客户和开发者之间形成一个需求约定,是需求开发和需求管理之间的桥梁。
(2)需求变更和风险
主要关心需求变更过程中的需求风险管理,带有风险的做法有:无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。
(3)变更产生的原因:外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。
(4)变更控制委员会CCB:也称为配置控制委员会,其任务是对建议的配置项变更做出评价、审批,以及监督已经批准变更的实施。
(5)需求跟踪:正向跟踪和反向跟踪
正向跟踪:需求到产品。
反向跟踪:产品到需求。
(6)需求变更流程
- 问题分析和变更描述
- 变更分析和成本计算
- 变更实现
(7)需求工程
需求工程包括需求开发和需求管理。
需求开发包括需求获取、需求分析、需求定义、需求验证。
需求管理包括变更控制、版本控制、需求追踪和需求状态追踪。
8.5、处理流程设计
1、流程表示工具
(1)程序流程图(Program Flow Diagram, PFD) 用一些图框表示各种操作,它独立于任何一种程序设计语言,比较直观、清晰,易于学习掌握。任何复杂的程序流程图都应该由顺序、选择和循环结构组合或嵌套而成。
(2)IPO图也是流程描述工具,用来描述构成软件系统的每个模块的输入、输出和数据加工。
(3)N-S图容易表示嵌套和层次关系,并具有强烈的结构化特征。但是当问题很复杂时,N-S图可能很大,因此不适合于复杂程序的设计。
(4)问题分析图(PAD)是一种支持结构化程序设计的图形工具。PAD具有清晰的逻辑结构、标准化的图形等优点,更重要的是,它引导设计人员使用结构化程序设计方法,从而提高程序的质量。
(5)业务流程重组BPR是对企业的业务流程进行根本性的再思考和彻底性的再设计,从而获得可以用诸如成本、质量、服务和速度等方面的业绩来衡量的显著性的成就。
(6)业务流程管理BPM
BPM是一种以规范化的构造端到端的卓越业务流程为中心,以持续的提高组织业务绩效为目的的系统化方法。
BPM与BPR管理思想最根本的不同就在于流程管理并不要求对所有的流程进行再造。构造卓越的业务流程并不是流程再造,而是根据现有流程的具体情况,对流程进行规范化的设计。
流程管理包含三个层面:规范流程、优化流程和再造流程。
8.6、系统设计
(1)系统设计主要目的:为系统制定蓝图,在各种技术和实施方法中权衡利弊,精心设计,合理地使用各种资源,最终勾画出新系统的详细设计方法。
不同开发阶段对应不同的图:
- 需求分析阶段:数据流图。
- 概要设计阶段:模块结构图、层次图和HIPO图。
- 详细设计阶段:程序流程图、伪代码、盒图。
(2)系统设计方法:结构化设计方法,面向对象设计方法。
(3)系统设计的主要内容:概要设计、详细设计。
- 概要设计:将软件需求转化为数据结构和软件系统结构。
- 详细设计:过程设计,通过对结构细化,得到软件详细数据结构和算法。
(4)概要设计基本任务:又称为系统总体结构设计,是将系统的功能需求分配给软件模块,确定每个模块的功能和调用关系,形成软件的模块结构图,即系统结构图。
(5)详细设计的基本任务:模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计(代码、输入/输出格式、用户界面)、编写详细设计说明书、评审。
(6)系统设计基本原理:抽象化;自顶而下,逐步求精;信息隐蔽;模块独立(高内聚,低耦合)。
(7)系统设计原则::保持模块的大小适中;尽可能减少调用的深度;多扇入,少扇出;单入口,单出口;模块的作用域应该在模块之内;功能应该是可预测的。
(8)系统设计基本原理:抽象、模块化、信息隐蔽、模块独立。
(9)衡量模块独立程度的标准有两个:耦合性和内聚性。
(10)内聚程度从低到高如下表所示:
| 内聚分类 | 定义 | 记忆关键字 |
|---|---|---|
| 偶然内聚 | 一个模块内的各处理元素之间没有任何联系 | 无直接关系 |
| 逻辑内聚 | 模块内执行若干个逻辑上相似的功能,通过参数确定该模块完成哪一个功能 | 逻辑相似、参数决定 |
| 时间内聚 | 把需要同时执行的动作组合在一起形成的模块 | 同时执行 |
| 过程内聚 | 一个模块完成多个任务,这些任务必须按指定的过程执行 | 指定的过程顺序 |
| 通信内聚 | 模块内的所有处理元素都在同一个数据结构上操作,或者各处理使用相同的输入数据或者产生相同的输出数据 | 相同数据结构、相同输入输出 |
| 顺序内聚 | 一个模块中的各个处理元素都密切相关于同一功能且必须顺序执行,前一个功能元素的输出就是下一个功能元素的输入 | 顺序执行、输入为输出 |
| 功能内聚 | 最强的内聚,模块内的所有元素共同作用完成一个功能,缺一不可 | 共同作用、缺一不可 |
速记:最高的内聚是:功能内聚 -> 顺序内聚 -> 通信内聚。
(11)耦合程度从低到高如下表所示:
| 耦合分类 | 定义 | 记忆关键字 |
|---|---|---|
| 无直接耦合 | 两个模块之间没有直接的关系,它们分别从属于不同模块的控制与调用,不传递任何信息 | 无直接关系 |
| 数据耦合 | 两个模块之间有调用关系,传递的是简单的数据值,相当于高级语言中的值传递 | 传递数据值调用 |
| 标记耦合 | 两个模块之间传递的是数据结构 | 传递数据结构 |
| 控制耦合 | 一个模块调用另一个模块时,传递的是控制变量,被调用模块通过该控制变量的值有选择的执行模块内的某一功能 | 控制变量、选择执行某一功能 |
| 外部耦合 | 模块间通过软件之外的环境联合(如 I/O 将模块耦合到特定的设备、格式、通信协议上)时 | 软件外部环境 |
| 公共耦合 | 通过一个公共数据环境相互作用的那些模块间的耦合 | 公共数据结构 |
| 内容耦合 | 当一个模块直接使用另一个模块的内部数据,或通过非正常入口转入另一个模块内部时 | 模块内部关联 |
速记:最高的耦合是:内容耦合 -> 公共耦合 -> 外部耦合。
8.7、系统测试和调试
1、系统测试是为了发现错误而执行程序的过程,成功的测试是发现了至今尚未发现的错误的测试。
2、软件测试方法可分为静态测试和动态测试。
◆ 静态测试:指被测试程序 不在机器上运行,而采用 人工检测和计算机辅助静态分析的手段 对程序进行检测,包括对文档的静态测试和对代码的静态测试。
对文档的静态测试主要以 检查单 的形式进行,而对代码的静态测试,包括 桌前检查、代码审查、代码走查 的方式。使用这种方法能够有效地发现 30%–70% 的逻辑设计和编码错误。
◆ 动态测试:指在计算机上 实际运行程序 进行软件测试,一般采用白盒测试和黑盒测试方法。
黑盒测试法:功能性测试,不了解软件代码结构,根据功能设计用例,测试软件功能。
白盒测试法:结构性测试,明确代码流程,根据代码逻辑设计用例,进行用例覆盖。
3、测试阶段
(1) 单元测试:也称为模块测试,测试的对象是 可独立编译或汇编的程序模块、软件构件或OO软件中的类(统称为模块),测试依据是 软件详细设计说明书。
(2) 集成测试:目的是 检查模块之间,以及模块和已集成的软件之间的接口关系,并验证已集成的软件是否符合设计要求。测试依据是 软件概要设计文档。
(3) 系统测试:测试对象是完整的、集成的计算机系统;测试的目的是在真实系统工作环境下,验证完成的软件配置项能否和系统正确连接,并满足系统/子系统设计文档和软件开发合同规定的要求。测试依据是 用户需求或开发合同。
主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等,其中,最重要的工作是进行功能测试与性能测试。功能测试主要采用黑盒测试方法;性能测试主要指标有响应时间、吞吐量、并发用户数和资源利用率等。
性能测试主要包括强度测试、负载测试、并发测试和可靠性测试。
- 强度测试:是在系统资源特别低的情况下考查软件系统极限运行的情况。
- 负载测试:用来测试超负荷环境中程序是否能够承担,确定在各种工作负载下系统的性能,测试当负载逐渐增加时,系统各项性能指标的变化情况。
- 压力测试:通过确定系统的瓶颈或不能接受的性能点,来获取系统所能提供的最大服务级别的测试。负载测试和压力测试相结合称为负载压力测试。
- 容量测试:并发测试也称为容量测试,主要用来测试系统可同时处理的最大在线用户数量。
(4) 确认测试:主要用于 验证软件的功能、性能和其他特性是否与用户需求一致。根据用户的参与程度,通常包括以下类型:
内部确认测试:主要由 软件开发组织内部按照SRS进行测试。
Alpha测试:用户在开发环境下进行测试。
Beta测试:用户在实际使用环境下进行测试,通过改测试后,产品才能交付用户。
验收测试:针对SRS,在交付前以用户为主进行的测试。
(5) 配置项测试:测试对象是 软件配置项,测试目的是 检验软件配置项与SRS的一致性。测试的依据是SRS。在此之间,应确认被测软件配置项已通过单元测试和集成测试。
(6) 回归测试:测试目的是 测试软件变更之后,变更部分的正确性和对变更需求的符合性,以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。
(7)自动化测试也称脚本测试,测试类型如下
- 线性脚本:录制手工执行的测试用例。
- 结构化脚本:类似于结构化程序设计,具有各种逻辑结构、函数调用功能。
- 共享脚本:可以被多个测试用例使用的脚步。
- 数据驱动脚步:将测试输入到独立的(数据)文件中,而不是存储在脚本中。可以针对不同的数据输入实现多个测试用例。
- 关键字驱动脚步:是数据驱动脚本的逻辑扩展,采用一些关键字指定要执行的任务。
4、测试用例的设计
(1)黑盒测试用例
- 等价类划分
- 边界值划分
- 错误推测
- 因果图
(2)白盒测试用例
- 语句覆盖 SC:逻辑代码中的 所有语句都要被执行一遍,覆盖层级最低,因为执行了所有的语句,不代表执行了所有的条件判断。
- 判定覆盖 DC:逻辑代码中的 所有判断语句的条件的真假分支都要覆盖一次。
- 条件覆盖 CC:针对每一个判断条件内的 每一个独立条件都要执行一遍真和假。
- 条件判定组合覆盖 CDC:同时满足判定覆盖和条件覆盖。
- 路径覆盖:逻辑代码中的 所有可行路径都覆盖了,覆盖层级最高。
覆盖层级:路径覆盖 > 条件判定组合覆盖 CDC > 判定覆盖 DC(条件覆盖 CC) > 语句覆盖 SC。



5、调试
◆ 测试是发现错误,调试是找出错误的代码和原因。
◆ 调试需要确定错误的准确位置;确定问题的原因并设法改正;改正后要进行回归测试。
◆ 调试的方法有:蛮力法、回溯法(从出错的地方开始,向回找)、原因排除法(找出所有可能的原因,逐一进行排除,具体包括演绎法、归纳法、二分法)。
6、软件度量
◆ 软件的两种属性:外部属性指面向管理者和用户的属性,可直接测量,一般为性能指标。内部属性指软件产品本身的的属性,如可靠性等,只能间接测量。
◆ McCabe度量法:又称为环路复杂度,假设有向图中 有向边数为m,节点数为n,则此有向图的环路复杂度为 m−n+2。
8.7、系统转换和系统维护
1、遗留系统是指任何基本上 不能进行修改和演化以满足新的变化了的业务需求的信息系统。
2、系统转换
◆ 系统转换是指 新系统开发完毕,投入运行,取代现有系统的过程,需要考虑多方面的问题,以实现与老系统的交接,有以下三种转换计划:
- 直接转换:现有系统被新系统直接取代了,风险很大,适用于新系统不复杂,或者现有系统已经不能使用的情况。优点是节省成本。
- 并行转换:新系统和老系统并行工作一段时间,新系统经过试运行后再取代,若新系统在试运行过程中有问题,也不影响现有系统的运行,风险极小,在试运行过程中还可以比较新老系统的性能,适用于大型系统。缺点是耗费人力和时间资源,难以控制两个系统间的数据转换。
- 分段转换:分期分批逐步转换,是直接和并行转换的集合,将大型系统分为多个子系统,依次试运行每个子系统,成熟一个子系统,就转换一个子系统。同样适用于大型项目,只是更耗时,而且现有系统和新系统间混合使用,需要协调好接口等问题。
◆ 数据转换与迁移:将数据从旧数据库迁移到新数据库中。有三种方法:系统切换前通过工具迁移、系统切换前采用手工录入、系统切换后通过新系统生成。
3、系统维护
◆ 系统的可维护性可以定义为 维护人员理解、改正、改动和改进这个软件的难易程度,其评价指标如下:
(1)易分析性。软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。
(2)易改变性。软件产品使指定的修改可以被实现的能力,实现包括编码、设计和文档的更改。
(3)稳定性。软件产品避免由于软件修改而造成意外结果的能力。
(4)易测试性。软件产品使已修改软件能被确认的能力。
(5)维护性的依从性。软件产品遵循与维护性相关的标准或约定的能力。
◆ 系统维护包括硬件维护、软件维护和数据维护,其中 软件维护类型如下:
- 正确性维护:发现了bug而进行的修改。
- 适应性维护:由于外部环境发生了改变,被动进行的对软件的修改和升级。
- 完善性维护:基于用户主动对软件提出更多的需求,修改软件,增加更多的功能,使其比之前的软件功能、性能更高,更加完善。
- 预防性维护:对未来可能发生的bug进行预防性的修改。
8.8、系统移植
移植工作大体上分为计划阶段、准备阶段、转换阶段、测试阶段、验证阶段。
1、计划阶段,在计划阶段,要进行现有系统的调查整理,从移植技术、系统内容(是否进行系统提炼等)、系统运行三个方面,探讨如何转换成新系统,决定移植方法,确立移植工作体制及移植日程。
2、准备阶段,在准备阶段要进行移植方面的研究,准备转换所需的资料。该阶段的作业质量将对以后的生产效率产生很大的影响。
3、转换阶段,这一阶段是将程序设计和数据转换成新机器能根据需要工作的阶段。提高转换工作的精度,减轻下一阶段的测试负担是提高移植工作效率的基本内容。
4、测试阶段,这一阶段是进行程序单元、工作单元测试的阶段。在本阶段要核实程序能否在新系统中准确地工作。所以,当有不能准确工作的程序时,就要回到转换阶段重新工作。
5、验证阶段,这是测试完的程序使新系统工作,最后核实系统,准备正式运行的阶段。
8.9、净室软件工程
1、净室软件工程是一种 应用数学与统计学理论以经济的方式生产高质量软件的工程技术,力图通过 严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。净室方法不是先制作一个产品,再去消除缺陷,而是 要求在规约和设计中消除错误,然后以“净”的方式制作,可以降低软件开发中的风险,以合理的成本开发出高质量的软件。
2、净室软件工程(CSE)的理论基础主要是函数理论和抽样理论。
3、净室工程应用技术手段:
统计过程控制下的增量式开发。
基于函数的规范与设计。
正确性验证。CSE的核心。
统计测试和软件认证。
4、净室软件工程在使用过程的一些缺点:
(1)CSE太理论化,需要更多的数学知识。其正确性验证的步骤比较困难且比较耗时。
(2)CSE 开发小组不进行传统的模块测试,这是不现实的。
(3)CSE也会带有传统软件工程的一些弊端。
8.10、基于构件的软件工程
1、基于构件的软件工程(CBSE)是一种基于 分布对象技术、强调通过 可复用构件设计与构造软件系统 的软件复用途径。CBSE 体现了 “购买而不是重新构造” 的哲学,将软件开发的重点从程序编写转移到了基于已有构件的组装。用于 CBSE 的构件应该具备以下特征:
(1)可组装型:对于可组装的构件,所有外部交互必须通过公开定义的接口进行。同时它还必须对自身信息的外部访问。
(2)可部署性:软件必须是自包含的,必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是二进制形式,无须在部署前编译。
(3)文档化:构件必须是全文档化的,用户根据文档来判断构件是否满足需求。
(4)独立性:构件应该是独立的,应该可以在无其他特殊构件的情况下进行组装和部署,如确实需要其他构件提供服务,则应显示声明。
(5)标准化:构件标准化意味着在 CBSE 过程中使用的构件必须符合某种标准化的构件模型。
构件模型定义了构件实现、文档化以及开发的标准,其包含的模型要素为:
- 接口。构件通过构件接口来定义,构件模型规定应如何定义构件接口以及在接口定义中应该包含的要素,如操作名、参数以及异常等。
- 使用信息。为使构件远程分布和访问,必须给构件一个特定的、全局唯一的名字或句柄。构件元数据是构件本身相关的数据,比如构件的接口和属性信息。
- 部署。构件模型包括一个规格说明,指出应该如何打包构件使其部署成为一个独立的可执行实体。部署信息中包含有关包中内容的信息和它的二进制构成的信息。
2、构件模型提供了一组被构件使用的通用服务,这种服务包括以下两种:
平台服务:允许构件在分布式环境下通信和互操作。
支持服务:这是很多构件需要的共性服务。例如,构件都需要的身份认证服务。
中间件实现共性的构件服务,并提供这些服务的接口。
3、CBSE过程是支持基于构件组装的软件开发过程,过程中的6个主要活动:系统需求概览、识别候选构件、根据发现的构件修改需求、体系结构设计、构件定制与适配、组装构件创建系统。
4、CBSE过程与传统软件开发过程不同点:
(1)CBSE 早期需要完整的需求,以便尽可能多地识别出可复用的构件。
(2)在过程早期阶段根据可利用的构件来细化和修改需求。如果可利用的构件不能满足用户需求,就应该考虑由复用构件支持的相关需求。
(3)在系统体系结构设计完成后,会有一个进一步的对构件搜索及设计精化的活动。可能需要为某些构件寻找备用构件,或者修改构件以适合功能和架构的要求。
(4)开发就是将已经找到的构件集成在一起的组装过程。
5、构件组装是指构件相互直接集成或是用专门编写的“胶水代码”将它们整合在一起来创造一个系统或另一个构件的过程。常见的组装构件有以下3种组装方式:
(1)顺序组装。通过按顺序调用已经存在的构件,可以用两个已经存在的构件来创造一个新的构件。如上一个构件输出作为下一个构件的输入。
(2)层次组装。这种情况发生在一个构件直接调用自另一个构件所提供的服务时。被调用的构件为调用的构件提供所需的服务。二者之间接口匹配兼容。
(3)叠加组装。这种情况发生在两个或两个以上构件放在一起来创建一个新构件的时候。这个新构件合并了原构件的功能,从而对外提供了新的接口。外部应用可以通过新接口来调用原有构件的接口,而原有构件不互相依赖,也不互相调用。这种组装类型适合于构件是程序单元或者构件是服务的情况。
6、构件组装的三种不兼容问题(通过编写适配器解决):
(1)参数不兼容。接口每一侧的操作有相同的名字,但参数类型或参数个数不相同。
(2)操作不兼容。提供接口和请求接口的操作名不同。
(3)操作不完备。一个构件的提供接口是另一个构件请求接口的一个子集,或者相反。
7、构件组装成软件系统的过程可分为三个不同的层次:定制、集成和扩展。
9、面向对象技术(3-5)
9.1、面向对象开发概念
1、对象:由 数据及其操作所构成的封装体,是系统中用来描述客观事务的一个实体,是构成系统的一个基本单位。一个对象通常可以由 对象名、属性和方法 3个部分组成。
2、类:现实世界中 实体的形式化描述,类将该实体的属性(数据)和操作(函数)封装在一起。对象是类的实例,类是对象的模板。
◆ 类可以分为三种:实体类、接口类(边界类)和控制类。
- 实体类的对象表示 现实世界中真实的实体,如人、物等。
- 接口类(边界类)的对象 为用户提供一种与系统合作交互的方式,分为人和系统两大类:人的接口可以是显示屏、窗口、Web 窗体、对话框、菜单、列表框、其他显示控制、条形码、二维码或者用户与系统交互的其他方法。系统接口涉及到把数据发送到其他系统,或者从其他系统接收数据。
- 控制类的对象用来 控制活动流,充当协调者。
3、抽象:通过 特定的实例抽取共同特征以后形成概念的过程。它强调 主要特征,忽略次要特征。一个对象是现实世界中一个实体的抽象,一个类是一组对象的抽象,抽象是一种单一化的描述,它强调给出与应用相关的特性,抛弃不相关的特性。
4、封装:是一种 信息隐蔽技术,将相关的概念组成一个单元模块,并通过一个名称来引用。面向对象封装是将数据和基于数据的操作封装成一个整体对象,对数据的访问或修改只能通过对象对外提供的接口进行。
5、继承:表示 类之间的层次关系(父类与子类),这种关系使得某类对象可以继承另外一类对象的特征,又可分为单继承和多继承。
6、多态:不同的对象收到同一个消息时产生完全不同的结果。包括:
参数多态(不同类型参数多种结构类型)
包含多态(父子类型关系)
过载多态(类似于重载,一个名字不同含义)
强制多态(强制类型转换)
四种类型。多态由继承机制支持,将通用消息放在抽象层,具体不同的功能实现放在低层。
7、接口:描述对操作规范的说明,其 只说明操作应该做什么,并没有定义操作如何做。
8、消息:体现 对象间的交互,通过它向目标对象发送操作请求。
9、覆盖:子类在原有父类接口的基础上,用 适合于自己要求的实现去置换父类中的相应实现。即在子类中重定义一个与父类同名同参的方法。
10、函数重载:与覆盖要区分开,函数重载与子类父类无关,且函数是 同名不同参数。
11、绑定是一个把 过程调用和响应调用所需要执行的代码加以结合 的过程。
在一般的程序设计语言中,绑定是在 编译时进行的,叫作 静态绑定。动态绑定则是在 运行时进行的,因此,一个给定的过程调用和代码的结合直到调用发生时才进行。
9.2、面向对象开发
1、面向对象的分析:是为了 确定问题域,理解问题。包含五个活动:认定对象、组织对象、描述对象间的相互作用、确定对象的操作、定义对象的内部信息。
2、面向对象需求建模:
3、面向对象的设计:是 设计分析模型和实现相应源代码,设计问题域的解决方案,与技术相关。OOD同样应遵循抽象、信息隐蔽、功能独立、模块化等设计准则。
4、面向对象的分析模型主要由 顶层架构图、用例与用例图、领域概念模型 构成;
设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。
5、面向对象的设计原则:
(1)单一责任原则。就一个类而言,应该 仅有一个引起它变化的原因。即,当需要修改某个类的时候原因有且只有一个,让一个类只做一种类型责任。
(2)开放-封闭原则。软件实体(类、模块、函数等)应该是 可以扩展的,即开放的;但是不可修改的,即封闭的。
(3)里氏替换原则。子类型必须能够替换掉他们的基类型。即,在任何父类可以出现的地方,都可以用子类的实例来赋值给父类型的引用。
(4)依赖倒置原则。抽象不应该依赖于细节,细节应该依赖于抽象。即,高层模块不应该依赖于低层模块,二者都应该依赖于抽象。
(5)接口分离原则。不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。即:依赖于抽象,不要依赖于具体,同时在抽象级别不应该有对于细节的依赖。这样做的好处就在于可以最大限度地应对可能的变化。
6、面向对象软件的测试可分为下列4个层次进行:
- 算法层。测试 类中定义的每个方法,基本上相当于传统软件测试中的单元测试。
- 类层。测试封装在 同一个类中的所有方法与属性之间的相互作用。在面向对象软件中类是基本模块,因此可以认为这是面向对象测试中所特有的模块测试。
- 模板层。测试 一组协同工作的类之间的相互作用,大体上相当于传统软件测试中的集成测试,但是也有面向对象软件的特点(例如,对象之间通过发送消息相互作用)。
- 系统层。把 各个子系统组装成完整的面向对象软件系统,在组装过程中同时进行测试。
9.3、统一建模语言UML
1、UML(统一建模语言):是一种 可视化的建模语言,而非程序设计语言,支持从需求分析开始的软件开发的全过程。
2、从总体上来看,UML的结构包括构造块、规则和公共机制三个部分。
(1)构造块。UML有三种基本的构造块,分别是 事物(thing)、关系(relationship)和图(diagram)。事物是UML的重要组成部分,关系把事物紧密联系在一起,图是多个相互关联的事物的集合。
(2)公共机制。公共机制是指达到特定目标的公共UML方法。
(3)规则。规则是构造块如何放在一起的规定。
3、关联关系
◆ 依赖:一个事物的语义依赖于另一个事物的语义的变化而变化。
◆ 关联:是一种结构关系,描述了一组链,链是对象之间的连接。分为 组合和聚合,都是 部分和整体的关系,其中组合事物之间关系更强。两个类之间的关联,实际上是两个类所扮演角色的关联,因此,两个类之间可以有多个由不同角色标识的关联。
◆ 泛化:一般/特殊的关系,子类和父类之间的关系
◆ 实现:一个类元指定了另一个类元保证执行的契约。

4、UML图
5、类图
6、对象图
7、用例图
8、序列图
顺序图的条件分支序列片段:
Alt:用于条件分支,有多个互斥的条件。
Opt:用于可选行为,只有一个条件。
Loop:用于循环操作,根据条件重复执行。
Break:用于中断行为,根据条件跳出当前片段。
Par:用于并行操作,多个消息序列同时执行。
Critical:用于临界区,确保操作的原子性。
Neg:用于不应发生的行为,表示错误情况。
Ref:用于引用其他顺序图,实现模块化和重用。
9、通信图
10、状态图
11、活动图
12、构件图(组件图)
13、部署图
14、4+1视图
(1)逻辑视图(设计视图):它表示了设计模型中在架构方面具有重要意义的部分,即类、子系统、包和用例实现的子集。
(2)进程视图:进程视图是可执行线程和进程作为活动类的建模,它是逻辑视图的一次执行实例,描述了并发与同步结构。
(3)实现视图(开发视图):实现视图对组成基于系统的物理代码的文件和构件进行建模。
(4)部署视图(物理视图):部署视图把构件部署到一组物理节点上,表示软件到硬件的映射和分布结构。
(5)用例视图(+1)用例视图是最基本的需求分析模型。
9.4、补充SysML图
1、SysML图(SysML Diagrams)是系统建模语言(Systems Modeling Language, SysML)中用于可视化描述复杂系统不同方面的图形化工具。
2、SysML 是基于 UML(统一建模语言)扩展而来的,专门用于系统工程领域(如航空航天、汽车、医疗设备等),旨在支持硬件、软件、数据、人员、流程和设施的跨学科建模。
| 类别 | 图表名称 | 英文缩写 | 主要用途 |
|---|---|---|---|
| 1. 需求图 (Requirements) |
需求图 | RD | SysML 独有。用于捕获、组织和管理系统需求,并追踪需求与设计、测试之间的关联(如“满足”、“验证”关系)。 |
| 2. 结构图 (Structure) |
块定义图 | BDD | 定义系统的层级结构、组件(块)及其分类关系(类似组织结构图)。 |
| 内部块图 | IBD | 展示组件内部的连接关系,包括端口、接口和数据/能量流(类似电路接线图)。 | |
| 参数图 | PD | SysML 独有。用于定义数学约束和性能参数,支持系统性能分析和仿真(如计算重量、功耗)。 | |
| 包图 | PKD | 用于组织和管理模型元素,保持模型的条理清晰(类似文件夹结构)。 | |
| 3. 行为图 (Behavior) |
活动图 | AD | 描述系统的操作流程、算法逻辑或业务流程(类似流程图)。 |
| 状态机图 | SMD | 描述系统或组件在不同事件触发下的状态变化(如“开机”、“运行”、“故障”状态)。 | |
| 序列图 | SD | 描述组件之间随时间变化的消息交互顺序(类似时序对话)。 | |
| 用例图 | UCD | 描述系统与外部用户(参与者)之间的功能交互场景。 |
💡 关键区别:
需求图 (RD) 和 参数图 (PD) 是 SysML 特有的,UML 中没有,这是为了弥补软件工程语言在系统工程需求管理和物理性能分析上的不足。
SysML 去掉了 UML 中一些过于侧重软件实现的图(如组件图、部署图、通信图等),使语言更简洁通用。
3、需求图



需求图的7种关系
| 关系名称 | 方向 (箭头指向) | 定义 | 典型应用 |
|---|---|---|---|
| 派生需求 ( «deriveReqt») |
子需求 → 父需求 | 表示低层需求是从高层需求通过逻辑推导、计算或分解得出的。 | 将“整车加速<8秒”推导为“发动机功率>200马力”。 |
| 细化 ( «refine») |
细化元素 → 被细化需求 | 表示模型元素(如用例、设计块)或更详细的需求为原需求提供了更具体的描述或实现细节。 | 用“驱动模块设计图”来具体阐述“最大加速度需求”。 |
| 满足 ( «satisfy») |
设计元素 → 需求 | 表示某个设计模型元素(通常是块/组件)实现了该需求的功能要求。 | “电池管理系统”模块满足了“续航时间>500km”的需求。 |
| 验证 ( «verify») |
测试用例 → 需求 | 表示某个测试用例用于检验该需求是否被正确实现。 | “高温环境测试脚本”验证了“电池耐热性”需求。 |
| 追踪 ( «trace») |
源需求 → 目标需求 | 表示两个需求之间存在逻辑关联或依赖,用于确保需求链的完整性,但无严格推导关系。 | 将“用户操作需求”关联到对应的“系统功能需求”,防止需求遗漏。 |
| 复制 ( «copy») |
副本需求 → 原始需求 | 表示当前需求是另一个需求的副本,用于在不同上下文中重用同一需求定义。 | 在子系统图中引用整车图中的“通用安全标准”需求。 |
| 包含(复合) ( Containment) |
父需求 ⊃ 子需求 (图形嵌套) |
表示层次化分解,父需求在逻辑上由一组子需求组成,通常表现为图形上的包含关系。 | “车辆性能需求”大框内包含“加速”、“制动”、“操控”等子需求小框。 |
9.5、设计模式
1、架构模式:软件设计中的高层决策,例如C/S结构就属于架构模式,架构模式反映了开发软件系统过程中所作的基本设计决策。
2、设计模式:每一个设计模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复劳动。设计模式的核心在于提供了相关问题的解决方案,使得人们可以更加简单方便的复用成功的设计和体系结构。四个基本要素:模式名称、问题(应该在何时使用模式)、解决方案(设计的内容)、效果(模式应用的效果)。
3、惯用法:是最低层的模式,关注软件系统的设计与实现,实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式,即语言的惯用法。例如引用一计数就是C++语言中的一种惯用法。
4、设计模式
| 创建型设计模式 | 定义 | 记忆关键字 |
|---|---|---|
| Abstract Factory 抽象工厂模式 |
提供一个接口,可以创建一系列相关或相互依赖的对象,而无需指定它们具体的类 | 抽象接口 |
| Builder 构建器模式 |
将一个复杂类的表示与其构造相分离,使得相同的构建过程能够得出不同的表示 | 类和构造分离 |
| Factory Method 工厂方法模式 |
定义一个创建对象的接口,但由子类决定需要实例化哪一个类。使得子类实例化过程推迟 | 子类决定实例化 |
| Prototype 原型模式 |
用原型实例指定创建对象的类型,并且通过拷贝这个原型来创建新的对象 | 原型实例,拷贝 |
| Singleton 单例模式 |
保证一个类只有一个实例,并提供一个访问它的全局访问点 | 唯一实例 |
| 结构型设计模式 | 定义 | 记忆关键字 |
|---|---|---|
| Adapter 适配器模式 |
将一个类的接口转换成用户希望得到的另一种接口。它使原本不相容的接口得以协同工作 | 转换,兼容接口 |
| Bridge 桥接模式 |
将类的抽象部分和它的实现部分分离开来,使它们可以独立的变化 | 抽象和实现分离 |
| Composite 组合模式 |
将对象组合成树型结构以表示“整体-部分”的层次结构,使得用户对单个对象和组合对象的使用具有一致性 | 整体-部分,树形结构 |
| Decorator 装饰模式 |
动态的给一个对象添加一些额外的职责。它提供了用子类扩展功能的一个灵活的替代,比派生一个子类更加灵活 | 附加职责 |
| Façade 外观模式 |
定义一个高层接口,为子系统中的一组接口提供一个一致的外观,从而简化了该子系统的使用 | 对外统一接口 |
| Flyweight 享元模式 |
提供支持大量细粒度对象共享的有效方法 | 细粒度,共享 |
| Proxy 代理模式 |
为其他对象提供一种代理以控制这个对象的访问 | 代理控制 |
| 行为型设计模式 | 定义 | 记忆关键字 |
|---|---|---|
| Chain of Responsibility 职责链模式 |
通过给多个对象处理请求的机会,减少请求的发送者与接收者之间的耦合。将接收对象链接起来,在链中传递请求,直到有一个对象处理这个请求 | 传递请求、职责、链接 |
| Command 命令模式 |
将一个请求封装为一个对象,从而可用不同的请求对客户进行参数化,将请求排队或记录请求日志,支持可撤销的操作 | 日志记录、可撤销 |
| Interpreter 解释器模式 |
给定一种语言,定义它的文法表示,并定义一个解释器,该解释器用来根据文法表示来解释语言中的句子 | 解释器,虚拟机 |
| Iterator 迭代器模式 |
提供一种方法来顺序访问一个聚合对象中的各个元素而不需要暴露该对象的内部表示 | 顺序访问,不暴露内部 |
| Mediator 中介者模式 |
用一个中介对象来封装一系列的对象交互。它使各对象不需要显式地相互调用,从而达到低耦合,还可以独立的改变对象间的交互 | 不直接引用 |
| Memento 备忘录模式 |
在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,从而可以在以后将该对象恢复到原先保存的状态 | 保存,恢复 |
| Observer 观察者模式 |
定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动更新 | 通知、自动更新 |
| State 状态模式 |
允许一个对象在其内部状态改变时改变它的行为 | 状态变成类 |
| Strategy 策略模式 |
定义一系列算法,把它们一个个封装起来,并且使它们之间可互相替换,从而让算法可以独立于使用它的用户而变化 | 算法替换 |
| Template Method 模板方法模式 |
定义一个操作中的算法骨架,而将一些步骤延迟到子类中,使得子类可以不改变一个算法的结构即可重新定义算法的某些特定步骤 | — |
| Visitor 访问者模式 |
表示一个作用于某对象结构中的各元素的操作,使得在不改变各元素的类的前提下定义作用于这些元素的新操作 | 数据和操作分离 |

- 类模式:用于处理类与子类之间的关系,这些关系通过继承来建立,是静态的,在编译时刻便确定下来了。GoF中的工厂方法、(类)适配器、模板方法、解释器属于该模式。
- 对象模式:用于处理对象之间的关系,这些关系可以通过组合或聚合来实现,在运行时刻是可以变化的,更具动态性。GoF 中除了以上 4 种,其他的都是对象模式
10、项目管理(大概率不会考)
10.1、项目管理
1、进度管理就是采用科学的方法,确定进度目标,编制进度计划和资源供应计划,进行进度控制,在与质量、成本目标协调的基础上,实现工期目标。
2、具体来说,包括以下过程:
(1)活动定义
(2)活动排序
(3)活动资源估算
(4)活动历时估算
(5)进度计划编制
(6)进度控制
3、进度描述图
3、关键路径法
关键路径(核心路劲):是项目的最短工期,**但却是从开始到结束时间最长的路径。**进度网络图中可能有多条关键路径,因为活动会变化,因此关键路径也在不断变化中。
关键活动:关键路径上的活动,最早开始时间 = 最晚开始时间。
通常,每个节点的活动会有如下几个时间:
(1)最早开始时间(ES),某项活动能够开始的最早时间。
(2)最早结束时间(EF),某项活动能够完成的最早时间。EF = ES + 工期
(3)最迟结束时间(LF)。为了使项目按时完成,某项活动必须完成的最迟时间。
(4)最迟开始时间(LS)。为了使项目按时完成,某项活动必须开始的最迟时间。LS = LF - 工期
4、总浮动时间:在不延误项目完工时间且不违反进度制约因素的前提下,活动可以从最早开始时间推迟或拖延的时间量,就是该活动的进度灵活性。正常情况下,关键活动的总浮动时间为零。
◆ 总浮动时间 = 最迟开始 LS - 最早开始 ES 或 最迟完成 LF - 最早完成 EF 或 关键路径 - 非关键路径时长。
5、自由浮动时间:是指在不延误任何紧后活动的最早开始时间且不违反进度制约因素的前提下,活动可以从最早开始时间推迟或拖延的时间量。
◆ 自由浮动时间 = 紧后活动最早开始时间的最小值 - 本活动的最早完成时间。
10.2、软件配置管理
1、配置管理是为了系统地控制配置变更,在系统的整个生命周期中维持配置的完整性和可跟踪性,而标识系统在不同时间点上配置的学科。
2、配置管理包括6个主要活动:制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。
3、典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据,它们经评审和检查通过后进入配置管理。
4、配置项可以分为基线配置项和非基线配置项两类,例如,基线配置项可能包括所有的设计文档和源程序等;非基线配置项可能包括项目的各类计划和报告等。
5、 所有配置项的操作权限应由 CMO(配置管理员)严格管理,基本原则是:基线配置项向开发人员开放读取的权限;非基线配置项向 PM、CCB 及相关人员开放。
6、配置项的状态可分为**“草稿”“正式”和“修改”**三种。配置项刚建立时,其状态为“草稿”。配置项通过评审后,其状态变为“正式”。此后若更改配置项,则其状态变为“修改”。当配置项修改完毕并重新通过评审时,其状态又变为“正式”。
7、配置项版本管理:在项目开发过程中,绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”,所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本,避免发生版本丢失或混淆等现象,并且可以快速准确地查找到配置项的任何版本。
10.3、质量管理
1、质量是软件产品特性的综合,表示软件产品满足明确(基本需求)或隐含(期望需求)要求的能力。质量管理是指确定质量方针、目标和职责,并通过质量体系中的质量计划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动;
2、主要包括以下过程:
(1)质量规划:识别项目及其产品的质量要求和标准,并书面描述项目将如何达到这些要求和标准的过程。
(2)质量保证:一般是每隔一定时间(例如,每个阶段末)进行的,主要通过系统的质量审计(软件评审)和过程分析来保证项目的质量。
(3)质量控制:实时监控项目的具体结果,以判断它们是否符合相关质量标准,制订有效方案,以消除产生质量问题的原因。
10.4、风险管理
1、风险管理就是要对项目风险进行认真的分析和科学的管理,这样,是能够避开不利条件、少受损失、取得预期的结果并实现项目目标的,能够争取避免风险的发生或尽量减小风险发生后的影响。但是,完全避开或消除风险,或者只享受权益而不承担风险是不可能的。
◆ 风险管理计划编制:如何安排与实施项目的风险管理,制定下列各步的计划。
◆ 风险识别:识别出项目中已知和可预测的风险,确定风险的来源、产生的条件、描述风险的特征以及哪些项目可以产生风险,形成一个风险列表。
◆ 风险定性分析:对已经识别的风险进行排序,确定风险可能性与影响、确定风险优先级、确定风险类型。
◆ 风险定量分析:进一步了解风险发生的可能性具体由多大,后果具体由多严重。包括灵敏度分析、期望货币价值分析、决策树分析、蒙特卡罗模拟。
◆ 风险应对计划编制:对每一个识别出来的风险来分别制定应对措施,这些措施组成的文档称为风险应对计划。包括消极风险(避免策略、转移策略、减轻策略);积极风险(开拓、分享、强大)。
◆ 风险监控:监控风险计划的执行,检测残余风险,识别新的风险,保证风险计划的执行,并评价这些计划对减少风险的有效性。
2、在信息系统项目中,从宏观上来看,风险可以分为项目风险、技术风险和商业风险。
3、 项目风险是指潜在的预算、进度、个人(包括人员和组织)、资源、用户和需求方面的问题,以及它们对项目的影响。项目复杂性、规模和结构的不确定性也构成项目的(估算)风险因素。项目风险威胁到项目计划,一旦项目风险成为现实,可能会拖延项目进度,增加项目的成本。
4、技术风险是指潜在的设计、实现、接口、测试和维护方面的问题。此外,规格说明的多义性、技术上的不确定性、技术陈旧、最新技术(不成熟)也是风险因素。技术风险威胁到待开发系统的质量和预定的交付时间。如果技术风险成为现实,开发工作可能会变得很困难或根本不可能。
5、 商业风险威胁到待开发系统的生存能力,主要有以下5种不同的商业风险:
(1)市场风险。开发的系统虽然很优秀但不是市场真正所想要的。
(2)策略风险。开发的系统不再符合企业的信息系统战略。
(3)销售风险。开发了销售部门不清楚如何推销的系统。
(4)管理风险。由于重点转移或人员变动而失去上级管理部门的支持。
(5)预算风险。开发过程没有得到预算或人员的保证。
11、系统架构设计(20)
11.1、软件架构概述
1、从需求分析到软件设计之间的过渡过程称为软件架构。只要软件架构设计好了,整个软件就不会出现坍塌性的错误,即不会崩溃。
2、架构设计就是需求分配,将满足需求的职责分配到组件上。
3、软件架构为软件系统提供了一个结构、行为和属性的高级抽象,由构件的描述、构件的相互作用(连接件)、指导构件集成的模式以及这些模式的约束组成。
4、软件架构不仅指定了系统的组织结构和拓扑结构,并且显示了系统需求和构件之间的对应关系,提供了一些设计决策的基本原理。
5、解决好软件的复用、质量和维护问题,是研究软件架构的根本目的。
6、软件架构设计包括提出架构模型,产生架构设计和进行设计评审等活动,是一个迭代的过程。架构设计主要关注软件组件的结构、属性和交互作用,并通过多种视图全面描述特定系统的架构。
7、软件架构能够在设计变更相对容易的阶段,考虑系统结构的可选方案,便于技术人员与非技术人员就软件设计进行交互,能够展现软件的结构、属性与内部交互关系。
8、软件架构是项目干系人进行交流的手段,明确了对系统实现的约束条件,决定了开发和维护组织的组织结构,制约着系统的质量属性。
9、软件架构使推理和控制的更改更加简单,有助于循序渐进的原型设计,可以作为培训的基础。
10、软件架构是可传递和可复用的模型,通过研究软件架构可能预测软件的质量。
11.2、软件架构设计与生命周期
1、需求分析阶段。需求分析和 SA 设计面临的是不同的对象:一个是问题空间;另一个是解空间。从软件需求模型向 SA 模型的转换主要关注两个问题:如何根据需求模型构建 SA 模型。如何保证模型转换的可追踪性。
2、设计阶段。是 SA 研究关注的最早和最多的阶段,这一阶段的 SA 研究主要包括:SA 模型的描述、SA 模型的设计与分析方法,以及对 SA 设计经验的总结与复用等。有关 SA 模型描述的研究分为 3 个层次:SA 的基本概念(构件和连接子)、体系结构描述语言 ADL、SA 模型的多视图表示。
ADL组成部分:组件、组件接口、连接件和架构配置。
3、实现阶段。最初 SA 研究往往只关注较高层次的系统设计、描述和验证。为了有效实现 SA 设计向实现的转换,实现阶段的体系结构研究表现在以下几个方面:
(1)研究基于 SA 的开发过程支持,如项目组织结构、配置管理等。
(2)寻求从 SA 向实现过渡的途径,如将程序设计语言元素引入 SA 阶段、模型映射、构件组装、复用中间件平台等。
(3)研究基于 SA 的测试技术。
4、构件组装阶段。在 SA 设计模型的指导下,可复用构件的组装可以在较高层次上实现系统,并能够提高系统实现的效率。在构件组装的过程中,SA 设计模型起到了系统蓝图的作用。研究内容包括如下两个方面:
(1)如何支持可复用构件的互联,即对 SA 设计模型中规约的连接子的实现提供支持。
(2)在组装过程中,如何检测并消除体系结构失配问题。
在构件组装阶段的失配问题主要包括:由构件引起的失配、由连接子引起的失配、由于系统成分对全局体系结构的假设存在冲突引起的失配等。
5、部署阶段。SA 对软件部署作用如下:
(1)提供高层的体系结构视图来描述部署阶段的软硬件模型。
(2)基于 SA 模型可以分析部署方案的质量属性,从而选择合理的部署方案。
6、后开发阶段。是指软件部署安装之后的阶段。这一阶段的 SA 研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。
(1)动态软件体系结构。现实中的软件具有动态性,体系结构会在运行时发生改变。
运行时变化包括两类:软件内部执行所导致的体系结构改变;软件系统外部的请求对软件进行的重配置。
包括两个部分的研究:体系结构设计阶段的支持、运行时刻基础设施的支持。
(2)体系结构恢复与重建。对于现有系统在开发时候没有考虑 SA 的情况,从这些系统中恢复或重构体系结构。从已有的系统中获取体系结构的重建方法分为 4 类:手工体系结构重建、工具支持的手工重建、通过查询语言来自动建立聚集、使用其他技术(如数据挖掘等)。
11.3、构件
1、构件是一个独立可交付的功能单元,外界通过接口访问其提供的服务。可以利用容器管理自身对外的可见状态。
2、构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模块和一组资源。原子构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署,但是它也能够被单独部署。
3、构件和原子构件之间的区别在于,大多数原子构件永远都不会被单独部署,尽管它们可以被单独部署。相反,大多数原子构件都属于一个构件家族,一次部署往往涉及整个家族。
4、一个模块是不带单独资源的原子构件。
5、一个单独的包被编译成多个单独的类文件——每个公共类都有一个。
6、模块是一组类和可能的非面向对象的结构体,比如过程或者函数。
7、构件的特性是:
(1)独立部署单元;
(2)作为第三方的组装单元;
(3)没有(外部的)可见状态。
一个构件可以包含多个类元素,但是一个类元素只能属于一个构件。
将一个类拆分进行部署通常没什么意义。
8、对象的特性是:
(1)一个实例单元,具有唯一的标志。
(2)可能具有状态,此状态外部可见。
(3)封装了自己的状态和行为。
9、构件接口
接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化为参数化操作的集合,而是关注输入输出的消息的标准化,它强调当机器在网络中互连时,标准的消息模式、格式、协议的重要性。
10、面向构件的编程(COP)
关注于如何支持建立面向构件的解决方案。“面向构件的编程需要下列基本的支持:
——多态性(可替代性);
——模块封装性(高层次信息的隐藏);
——后期的绑定和装载(部署独立性);
——安全性(类型和模块安全性)。”
11、构件技术就是利用某种编程手段,将一些人们所关心的,但又不便于让最终用户去直接操作的细节进行了封装,同时对各种业务逻辑规则进行了实现,用于处理用户的内部操作细节。目前,国际上常用的构件标准主要有三大流派:
12、EJB (Enterprise Java Bean) 规范由 Sun 公司制定,有三种类型的 EJB,分别是会话 Bean(Session Bean)、实体 Bean(Entity Bean) 和消息驱动 Bean(Message-driven Bean)。EJB 实现应用中关键的业务逻辑,创建基于构件的企业级应用程序。
13、COM、DCOM、COM+ :COM 是微软公司的。DCOM 是 COM 的进一步扩展,具有位置独立性和语言无关性。COM+ 并不是 COM 的新版本,是 COM 的新发展或是更高层次的应用。
COM支持两种形式的对象封装:包含和聚集。
- 包含:一个外部对象拥有指向一个内部对象的唯一引用。
- 聚集:之间把内部对象接口引用传给外部对象的客户,而不是再转发请求。
14、COBRA 标准主要分为三个层次:对象请求代理、公共对象服务和公共设施。
最底层是对象请求代理 ORB,规定了分布对象的定义(接口)和语言映射,实现对象间的通讯和互操作,是分布对象系统中的“软总线”;
在 ORB 之上定义了很多公共服务,可以提供诸如并发服务、名字服务、事务(交易)服务、安全服务等各种各样的服务;
最上层的公共设施则定义了组件框架,提供可直接为业务对象使用的服务,规定业务对象有效协作所需的协定规则。
15、构件分类
- 关键字分类法:根据领域分析的结果将应用领域的概念按照从抽象到具体的顺序逐次分解为树形或有向无回路图结构。
- 刻面分类法:利用Facet描述构件执行的功能、被操作的数据、构件应用的语境或任意其他特征。
- 超文本方法:使得检索者在阅读文档过程中可以按照人类的联想思维方式任意跳转到包含相关概念或构件的文档。
16、构件组装技术:基于功能的构件组装技术、基于数据的构件组装技术、面向对象的构件组装技术。
11.4、软件架构风格
1、软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族,即一个架构定义、一个词汇表和一组约束。词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的。
2、架构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用,一些经过实践证实的解决方案也可以可靠地用于解决新的问题。
3、架构设计的一个核心问题是能否达到架构级的软件复用。
4、架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
5、数据流风格:面向数据流,按照一定的顺序从前向后执行程序,代表的风格有 批处理序列、管道-过滤器。
- 批处理序列:构件为一系列固定顺序的计算单元,构件之间只通过数据传递交互。每个处理步骤是一个独立的程序,每一步必须在其前一步结束后才能开始,数据必须是完整的,以整体的方式传递。
- 管道-过滤器:每个构件都有一组输入和输出,构件读取输入的数据流,经过内部处理,产生输出数据流。前一个构件的输出作为后一个构件的输入,前后数据流关联。过滤器就是构件,连接件就是管道。
- 二者区别在于批处理前后构件不一定有关联,并且是作为整体传递,即必须前一个执行完才能执行下一个。管道-过滤器是前一个输出作为后一个输入,前面执行到部分可以开始下一个的执行。
6、调用/返回风格:构件之间存在互相调用的关系,一般是显式的调用,代表的风格有 主程序/子程序、面向对象、层次结构。
-
主程序/子程序:单线程控制,把问题划分为若干个处理步骤,构件即为主程序和子程序,子程序通常可合成为模块。过程调用作为交互机制,充当连接件的角色。
-
面向对象:构件是对象,对象是抽象数据类型的实例。连接件即使对象间交互的方式,对象是通过函数和过程的调用来交互的。
-
层次结构:构件组成一个层次结构,连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务,使用下一层的服务,只能见到与自己邻接的层。修改某一层,最多影响其相邻的两层(通常只能影响上层)。
◆ 层次结构优点:
- 支持基于可增加抽象层的设计,允许将一个复杂问题分解成一个增量步骤序列的实现。
- 不同的层次处于不同的抽象级别,越靠近底层,抽象级别越高。
- 由于每一层最多只影响两层,同时只要给相邻层提供相同的接口,允许每层用不同的方法实现,同样为软件复用提供了强大的支持。
◆ 缺点:
- 并不是每个系统都可以很容易的划分为分层的模式。
- 很难找到一个合适的、正确的层次抽象方法。
7、独立构件风格:构件之间是互相独立的,不存在显式的调用关系,而是通过某个事件触发、异步的方式来执行,代表的风格有 进程通信、事件驱动系统(隐式调用)。
-
进程通信:构件是独立的进程,连接件是消息传递。构件通常是命名过程,消息传递的方式可以是点对点、异步或同步方式,以及远程过程(方法)调用等。
-
事件驱动系统(隐式调用):构件不直接调用一个过程,而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册,当某个事件被触发时,系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程,它们之间交互的连接件往往是以过程之间的隐式调用来实现的。
主要优点是为软件复用提供了强大的支持,为构件的维护和演化带来了方便;缺点是构件放弃了对系统计算的控制。
8、虚拟机风格:自定义了一套规则供使用者使用,使用者基于这个规则来开发构件,能够跨平台适配,代表的风格有 解释器、基于规则的系统。
- 解释器:通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构,以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机,可以仿真硬件的执行过程和一些关键应用,缺点是执行效率低。
- 基于规则的系统:包括规则集、规则解释器、规则/数据选择器和工作内存,一般用在人工智能领域和DSS中。

9、仓库风格:以数据为中心,所有的操作都是围绕建立的数据中心进行的,代表的风格有 数据库系统、超文本系统、黑板系统。
-
数据库系统:构件主要有两大类,一类是中央共享数据源,保存当前系统的数据状态;另一类是多个独立处理单元,处理单元对数据元素进行操作。
-
黑板系统:包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元,提供解决问题的知识。知识源响应黑板的变化,也只修改黑板;黑板是一个全局数据库,包含问题域解空间的全部状态,是知识源相互作用的唯一媒介;知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中(信号处理、问题规划和编译器优化等)。
-
超文本系统:构件以网状链接方式相互连接,用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。是一种非线性的网状信息组织方法,它以节点为基本单位,链作为节点之间的联想式关联。通常应用在互联网领域。
现代编译器的集成开发环境一般采用数据仓库(即以数据为中心的架构风格)架构风格进行开发,其中心数据就是程序的语法树。
在仓库风格中,有两种不同的构件,其中,中央数据结构说明当前状态,独立构件在中央数据存储上执行。
10、闭环控制
当软件被用来操作一个物理系统时,软件与硬件之间可以粗略的表示为一个反馈循环,这个反馈循环通过接受一定的输入,确定一系列的输出,最终使环境达到一个新的状态,适合于嵌入式系统,涉及连续的动作与状态。
11、C2
C2体系结构风格可以概括为:通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下:
(1) 系统中的构件和连接件都有一个顶部和一个底部;
(2) 构件的顶部应连接到某连接件的底部,构件的底部则应连接到某连接件的顶部,而构件与构件之间的直接连接是不允许的;
(3) 一个连接件可以和任意数目的其它构件和连接件连接;
(4) 当两个连接件进行直接连接时,必须由其中一个的底部到另一个的顶部。
12、总结
11.5、层次架构风格
1、两层C/S架构(胖客户端):客户端和服务器都有处理功能,现在已经不常用,原因有:开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一、软件移植困难、软件维护和升级困难、新技术不能轻易应用、安全性问题、服务器端压力大难以复用。
2、三层C/S架构(瘦客户端):将处理功能独立出来,表示层和数据层都变得简单。表示层在客户机上,功能层在应用服务器上,数据层在数据库服务器上。即将两层C/S架构中的数据从服务器中独立出来了。其优点下面四点:
◆ 各层在逻辑上保持相对独立,整个系统的逻辑结构更为清晰,能提高系统和软件的可维护性和可扩展性;
◆ 允许灵活有效的选用相应的平台和硬件系统,具有良好的可升级性和开放性;
◆ 各层可以并行开发,各层也可以选择各自最适合的开发语言;
◆ 功能层有效的隔离表示层与数据层,为严格的安全管理奠定了坚实的基础,整个系统的管理层次也更加合理和可控制。
◆ 三层C/S架构设计的关键在于各层之间的通信效率,要慎重考虑三层间的通信方法、通信频度和数据量,否则即使分配给各层的硬件能力很强,性能也不高。
3、三层B/S架构
是三层C/S架构的变种,将客户端变为用户客户端上的浏览器,将应用服务器变为网络上的WEB服务器,又称为0客户端架构,虽然不用开发客户端,但有很多缺点:
- B/S架构缺乏对动态页面的支持能力,没有集成有效的数据库处理功能;
- 安全性难以控制;
- 在数据查询等响应速度上,要远远低于C/S架构;
- 数据提交一般以页面为单位,数据的动态交互性不强,不利于OLTP应用。
◆ 混合架构风格
内外有别模型:企业内部使用C/S,外部人员访问使用B/S。
查改有别模型:采用B/S查询,采用C/S修改。
混合架构实现困难,且成本高。
4、富互联网应用RIA
◆ 弥补三层B/S架构存在的问题,RIA是一种用户接口,比用HTML实现的接口更加健壮,且有可视化内容,本质还是网站模式,其优点如下:
- RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性;
- RIA简化并改进了B/S架构的用户交互;
- 数据能够被缓存在客户端,从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。
◆ 本质还是0客户端,借助于高速网速实现必要插件在本地的快速缓存,增强页面对动态页面的支持能力,典型的如小程序。
5、MVC架构
(1) 控制器(Controller):是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据,控制用户输入,并向模型发送数据。
(2) 模型(Model):是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。模型表示业务数据和业务逻辑。
(3) 视图(View):是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。是用户看到并与之交互的界面。视图向用户显示相关的数据,并能接收用户的输入数据,但是它并不进行任何实际的业务处理。
6、MVP
MVP 是把 MVC 中的 Controller 换成了 Presenter(呈现),目的就是为了完全切断 View 跟 Model 之间的联系,由 Presenter 充当桥梁,做到 View-Model 之间通信的完全隔离。
MVP 特点:
- M、V、P 之间双向通信。
- View 与 Model 不通信,都通过 Presenter 传递。Presenter 完全把 Model 和 View 进行了分离,主要的程序逻辑在 Presenter 里实现。
- View 非常薄,不部署任何业务逻辑,称为“被动视图”(Passive View),即没有任何主动性,而 Presenter 非常厚,所有逻辑都部署在那里。
- Presenter 与具体的 View 是没有直接关联的,而是通过定义好的接口进行交互,从而使得在变更 View 时候可以保持 Presenter 的不变,这样就可以重用。

7、MVVM
MVVM 模式和 MVC 模式类似,主要目的是分离视图(View)和模型(Model),有几大优点:
-
低耦合:视图(View)可以独立于 Model 变化和修改。一个 ViewModel 可以绑定到不同的 “View” 上,当 View 变化的时候 Model 可以不变,当 Model 变化的时候 View 也可以不变。
-
可重用性:可以把一些视图逻辑放在一个 ViewModel 里面,让很多 View 重用这段视图逻辑。
-
独立开发:开发人员可以专注于业务逻辑和数据的开发(ViewModel),设计人员可以专注于页面设计。
-
可测试:界面向来是比较难于测试的,而现在测试可以针对 ViewModel 来写。

11.6、面向服务的架构风格
1、SOA(面向服务的架构)
-
SOA是一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通信,不涉及底层编程接口和通信模型。
-
在SOA中,服务是一种为了满足某项业务需求的操作、规则等的逻辑组合,它包含一系列有序活动的交互,为实现用户目标提供支持。
-
SOA并不仅仅是一种开发方法,还具有管理上的优点:管理员可直接管理开发人员所构建的相同服务。多个服务通过企业服务总线提出服务请求,由应用管理来进行处理,如下:

-
实施SOA的关键目标是实现企业IT资产重用的最大化,在实施SOA过程中要牢记以下特征:
- 可从企业外部访问、随时可用(服务请求能被及时响应)
- 粗粒度接口(粗粒度提供一项特定的业务功能,而细粒度服务代表了技术构件方法)
- 服务分级、松散耦合(服务提供者和服务使用者分离)
- 可重用的服务及服务接口设计管理
- 标准化的接口(WSDL、SOAP、XML是核心)
- 支持各种消息模式、精确定义的服务接口
-
从基于对象到基于构件再到基于服务,架构越来越松散耦合,粒度越来越粗,接口越来越标准。
-
基于服务的构件与传统构件的区别有四点:
- 服务构件粗粒度,传统构件细粒度居多;
- 服务构件的接口是标准的,主要是WSDL接口,而传统构件常以具体API形式出现;
- 服务构件的实现与语言是无关的,而传统构件常绑定某种特定的语言;
- 服务构件可以通过构件容器提供QoS的服务,而传统构件完全由程序代码直接控制。
SOA 中应用的关键技术如下表:
| 功能 | 协议 |
|---|---|
| 发现服务 | UDDI、DISCO |
| 描述服务 | WSDL、XML Schema |
| 消息格式层 | SOAP、REST |
| 编码格式层 | XML(DOM, SAX) |
| 传输协议层 | HTTP、TCP/IP、SMTP等 |
-
UDDI:是一套基于 WEB 的、分布式的、为 WebService 提供的、信息注册中心的实现标准规范,同时也包含一组使企业能将自身提供的 WebService 注册,以便别的企业能够发现的访问协议的实现标准,用于 WEB 服务注册统一描述、发现及集成。
-
WSDL(Web Service 描述语言):将 Web 服务描述定义为一组服务访问点,客户端可以通过这些服务访问点对包含面向文档信息或面向过程调用的服务进行访问(类似远程调用),用于描述服务。
-
SOAP(简单对象访问协议):是用于交换 XML 编码信息的轻量级协议,用于传递信息。
-
XML(可扩展标记语言):是 WebService 平台中表示数据的基本格式,用于数据交换。
2、WEB Service
-
服务提供者、服务注册中心(中介,提供交易平台,可有可无)、服务请求者。服务提供者将服务描述发布到服务注册中心,供服务请求者查找,查找到后,服务请求者将绑定查找结果。如图
-
服务注册表
- 服务注册:应用开发者(服务提供者)在注册表中公布服务的功能。
- 服务位置:服务使用者(服务应用开发者),帮助他们查询注册服务,寻找符合自身要求的服务。
- 服务绑定:服务使用者利用检索到的服务接口来编写代码,所编写的代码将与注册的服务绑定,调用注册的服务,以及与它们实现互动。

3、ESB
-
企业服务总线ESB:简单来说是一根管道,用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务,ESB做了消息的转化、解释以及路由的工作,以此来让不同的服务互联互通。
-
包括:客户端(服务请求者)、基础架构服务(中间件)、核心集成服务(提供服务)。
◆ ESB特点:
- SOA的一种实现方式,ESB在面向服务的架构中起到的是总线作用,将各种服务进行连接与整合;
- 描述服务的元数据和服务注册管理;
- 在服务请求者和提供者之间传递数据,以及对这些数据进行转换的能力,并支持由实践中总结出来的一些模式如同步模式、异步模式等;
- 发现、路由、匹配和选择的能力,以支持服务之间的动态交互,解耦服务请求者和服务提供者。高级一些的能力,包括对安全的支持、服务质量保证、可管理性和负载平衡等。

11.7、软件架构复用
◆软件产品线是指一组软件密集型系统,它们共享一个公共的、可管理的特性集,满足某个特定市场或任务的具体需要,是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。
◆软件架构复用的类型包括机会复用和系统复用。机会复用是指开发过程中,只要发现有可复用的资产,就对其进行复用。系统复用是指在开发之前,就要进行规划,以决定哪些需要复用。
◆可复用的资产包括:需求、架构设计、元素、建模与分析、测试、项目规划、过程方法和工具、人员、样本系统、缺陷消除。
◆复用的基本过程主要包括3个阶段:首先构造 / 获取可复用的软件资产,其次管理这些资产(构件库),最后针对特定的需求,从这些资产中选择可复用的部分,以开发满足需求的应用系统。
11.8、特定领域软件架构
1、DSSA
◆DSSA就是专用于一类特定类型的任务(领域)的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。
◆DSSA就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础,其目标就是支持在一个特定领域中多个应用的生成。
◆垂直域:在一个特定领域中的通用的软件架构,是一个完整的架构。
◆水平域:在多个不同的特定领域之间的相同的部分的小工具(如购物和教育都有收费系统,收费系统即是水平域)。
2、DSSA的三个基本活动
领域分析:这个阶段的主要目标是获得领域模型(领域需求)。识别信息源,即整个领域工程过程中信息的来源,可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等,在此基础上就可以分析领域中系统的需求,确定哪些需求是领域中的系统广泛共享的,从而建立领域模型。
领域设计:这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案,它不是单个系统的表示,而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后,就可以派生出满足这些被建模的领域需求DSSA。
领域实现:这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到,也可能需要通过新的开发得到。
3、参与DSSA的四种角色人员
领域专家:包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。提供关于领域中系统的需求规约和实现的知识,帮助组织规范的、一致的领域字典,帮助选择样本系统作为领域工程的依据,复审领域模型、DSSA等领域工程产品,等等。
领域分析人员:由具有知识工程背景的有经验的系统分析员来担任。控制整个领域分析过程,进行知识获取,将获取的知识组织到领域模型中。
领域设计人员:由有经验的软件设计人员来担任。根据领域模型和现有系统开发出DSSA,并对DSSA的准确性和一致性进行验证。
领域实现人员:由有经验的程序设计人员来担任。根据领域模型和DSSA,开发构件。
4、建立DSSA的过程
定义领域范围:领域中的应用要满足用户一系列的需求。
定义领域特定的元素:建立领域的字典,归纳领域中的术语,识别出领域中相同和不相同的元素。
定义领域特定的设计和实现需求的约束:识别领域中的所有约束,这些约束对领域的设计和实现会造成什么后果。
定义领域模型和架构:产生一般的架构,并描述其构件说明。
产生、搜集可复用的产品单元:为DSSA增加复用构件,使可用于新的系统。
以上过程是并发的、递归的、反复的、螺旋型的。
5、三层次模型
◆领域开发环境:领域架构师决定核心架构,产出参考结构、参考需求、架构、领域模型、开发工具。
◆领域特定的应用开发环境:应用工程师根据具体环境来将核心架构实例化。
◆应用执行环境:操作员实现实例化后的架构。

11.9、基于架构的软件开发
1、ABSD方法是架构驱动,强调由业务、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构,采用用例和质量属性场景来描述需求。进一步来说,用例描述的是功能需求,质量属性场景描述的是质量需求(或侧重于非功能需求)。
展示功能组织的静态视角判断质量属性,展示并发行为的动态视角能判断系统行为特性。
ABSD中四种视图(不同于4+1视图)分别是逻辑视图、进程视图、实现视图和配置视图。
在 ABSD 的语境下,配置视图 对应于通用 4+1 模型中的 物理视图 或 部署视图
2、使用ABSD方法,设计活动可以从项目总体功能框架明确就开始,这意味着需求获取和分析还没有完成,就开始了软件设计。
3、ABSD方法有三个基础。第一个基础是功能的分解,使用已有的基于模块的内聚和耦合技术;第二个基础是通过选择架构风格来实现质量和业务需求;第三个基础是软件模板的使用,软件模板利用了一些软件系统的结构。
4、 ABSD方法是递归的(自顶向下),且迭代的每一个步骤都是清晰定义的。因此,不管设计是否完成,架构总是清晰的,有助于降低架构设计的随意性。
5、基于架构的软件开发过程可分为下列六步:(体系结构)需求、设计、文档化、复审、实现、演化。
(1) 架构需求:重在掌握标识构件的三步,如下左图。
◆需求获取:体系结构需求一般来自三个方面,分别是系统的质量目标、系统的商业目标和系统开发人员的商业目标。
◆标识构件:为系统生成初始逻辑结构,标识大致的构件。包括图中三个步骤。
(2) 架构设计:将需求阶段的标识构件映射成构件,进行分析,如下右图。
(3) 架构(体系结构)文档化:主要产出两种文档,即架构(体系结构)规格说明,测试架构(体系结构)需求的质量设计说明书。文档是至关重要的,是所有人员通信的手段,关系开发的成败。
(4) 架构复审:由外部人员(独立于开发组织之外的人,如用户代表和领域专家等)参加的复审,复审架构是否满足需求,质量问题,构件划分合理性等。若复审不过,则返回架构设计阶段进行重新设计、文档化,再复审。
(5) 架构实现:用实体来显示出架构。实现构件,构件组装成系统,如下左图:
(6) 架构演化:对架构进行改变,按需求增删构件,使架构可复用,如下右图:
11.10、软件系统的质量属性和架构评估
1、可以将软件系统的质量属性分为开发期质量属性和运行期质量属性2个部分。
-
开发期质量属性主要指在软件开发阶段所关注的质量属性,主要包含6个方面。
(1) 易理解性:指设计被开发人员理解的难易程度。
(2) 可扩展性:软件因适应新需求或需求变化而增加新功能的能力,也称为灵活性。
(3) 可重用性:指重用软件系统或某一部分的难易程度。
(4) 可测试性:对软件测试以证明其满足需求规范的难易程度。
(5) 可维护性:当需要修改缺陷、增加功能、提高质量属性时,识别修改点并实施修改的难易程度。
(6) 可移植性:将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。 -
运行期质量属性主要指在软件运行阶段所关注的质量属性,主要包含7个方面。
(1) 性能:性能是指软件系统及时提供相应服务的能力,如速度、吞吐量和容量等的要求。
(2) 安全性:指软件系统同时兼顾向合法用户提供服务,以及阻止非授权使用的能力。
(3) 可伸缩性:指当用户数和数据量增加时,软件系统维持高服务质量的能力。例如,通过增加服务器来提高能力。
(4) 互操作性:指本软件系统与其他系统交换数据和相互调用服务的难易程度。
(5) 可靠性:软件系统在一定的时间内持续无故障运行的能力。
(6) 可用性:指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误,恶意攻击,高负载等问题的影响。
(7) 鲁棒性:是指软件系统在非正常情况(如用户进行了非法操作、相关的软硬件系统发生了故障等)下仍能够正常运行的能力,也称健壮性或容错性。
2、质量属性
1、性能:指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。
设计策略:优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。
2、可靠性:是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF、MTTR。
设计策略:心跳、Ping/Echo、冗余、选举。
3、可用性:是系统能够正常运行的时间比例,经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。
设计策略:心跳、Ping/Echo、冗余、选举。
4、安全性:是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。
设计策略:入侵检测、用户认证、用户授权、追踪审计。
5、可修改性:指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准,通过考察这些变更的代价衡量。
设计策略:接口-实现分类、抽象、信息隐藏。
6、功能性:是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
7、可变性:指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则,在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时,可变性是很重要的。
8、互操作性:作为系统组成部分的软件不是独立存在的,经常与其他系统或自身环境相互作用。为了支持互操作性,软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题,也影响应用的软件体系结构。
9、信息隐蔽式开发整体程序结构时使用的法则,通过信息隐蔽可以提高软件的可修改性,可测试性和可移植性。
3、质量属性场景是一种面向特定质量属性的需求。它由6部分组成:
· 刺激源(Source):这是某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)。
· 刺激(Stimulus):该刺激是当刺激到达系统时需要考虑的条件。
· 环境(Environment):该刺激在某些条件内发生。当激励发生时,系统可能处于过载、运行或者其他情况。
· 制品(Artifact):某个制品被激励。这可能是整个系统,也可能是系统的一部分。
· 响应(Response):该响应是在激励到达后所采取的行动。
· 响应度量(Measurement):当响应发生时,应当能够以某种方式对其进行度量,以对需求进行测试。
可修改性质量属性场景描述实例:
| 场景要素 | 可能的情况 |
|---|---|
| 刺激源 | 最终用户、开发人员、系统管理员 |
| 刺激 | 希望增加、删除、修改、改变功能、质量属性、容量等 |
| 环境 | 系统设计时、编译时、构建时、运行时 |
| 制品 | 系统用户界面、平台、环境或与目标系统交互的系统 |
| 响应 | 查找架构中需要修改的位置,进行修改且不会影响其他功能,对所做的修改进行测试,部署所做的修改 |
| 响应度量 | 根据所影响元素的数量度量的成本、努力、资金;该修改对其他功能或质量属性所造成影响的程度 |
4、敏感点:是指为了实现某种特定的质量属性,一个或多个构件所具有的特性。
5、权衡点:是影响多个质量属性的特性,是多个质量属性的敏感点。
6、风险点与非风险点不是以标准专业术语形式出现的,只是一个常规概念,即可能引起风险的因素,可称为风险点。某个做法如果有隐患,有可能导致一些问题,则为风险点;而如果某件事是可行的可接受的,则为非风险点。
7、软件架构评估在架构设计之后,系统设计之前,因此与设计、实现、测试都没有关系。评估的目的是为了评估所采用的架构是否能解决软件系统需求,但不是单纯的确定是否满足需求。
8、在架构评估中,场景是从风险承担者的角度对于系统交互的描述,一般采用刺激、环境、响应三方面来对场景进行描述。
8、三种常用的评估方式
◆基于调查问卷(检查表)的方式:类似于需求获取中的问卷调查方式,只不过是架构方面的问卷,要求评估人员对领域熟悉。
◆基于度量的方式:制定一些定量指标来度量架构,如代码行数等。要制定质量属性和度量结果之间的映射,要求评估人员对架构熟悉。
◆基于场景的方式:主要方法。首先要确定应用领域的功能和软件架构的结构之间的映射,然后要设计用于体现待评估质量属性的场景(即4+1视图中的场景),最后分析软件架构对场景的支持程度。要求评估人员即对领域熟悉,也对架构熟悉。从三个方面对场景进行设计:刺激(事件);环境(事件发生的环境);响应(架构响应刺激的过程)。
| 评估方式 | 调查问卷或检查表 | 场景 | 度量 | |
|---|---|---|---|---|
| 调查问卷 | 检查表 | |||
| 通用性 | 通用 | 特定领域 | 特定系统 | 通用或特定领域 |
| 评估者对架构的了解程度 | 粗略了解 | 无限制 | 中等了解 | 精确了解 |
| 实施阶段 | 早 | 中 | 中 | 中 |
| 客观性 | 主观 | 主观 | 较主观 | 较客观 |
9、基于场景的架构分析方法SAAM
SAAM是一种非功能质量属性的架构分析方法,是最早形成文档并得到广泛应用的软件架构分析方法。
◆特定目标。SAAM的目标是对描述应用程序属性的文档,验证基本的架构假设和原则。
◆质量属性。这一方法的基本特点是把任何形式的质量属性都具体化为场景,但可修改性是SAAM分析的主要质量属性。
◆架构描述。SAAM用于架构的最后版本,但早于详细设计。架构的描述形式应当被所有参与者理解。
◆功能、结构和分配被定义为描述架构的3个主要方面。
◆方法活动。SAAM的主要输入是问题描述、需求声明和架构描述。下图描绘了SAAM分析活动的相关输入及评估过程。包括5个步骤,即场景开发、架构描述、单个场景评估、场景交互和总体评估。

10、架构权衡分析法ATAM,让架构师明确如何权衡多个质量目标,参与者有评估小组、项目决策者和其他项目相关人。
◆ ATAM被分为四个主要的活动领域,分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。整个评估过程强调以属性作为架构评估的核心概念。主要针对性能、可用性、安全性和可修改性,在系统开发之前,对这些质量属性进行评价和折中。

11、成本效益分析法CBAM,用来对架构建立的成本来进行设计和建模,让决策者根据投资收益率来选择合适的架构,可以看做对ATAM的补充,在ATAM确定质量合理的基础上,再对效益进行分析。有下列步骤:
◆整理场景(确定场景,并确定优先级,选择三分之一优先级最高的场景进行分析);
◆对场景进行细化(对每个场景详细分析,确定最好、最坏的情况);
◆确定场景的优先级(项目干系人对场景投票,根据投票结果确定优先级);
◆分配效用(对场景响应级别确定效用表,建立策略、场景、响应级别的表格);
◆形成“策略-场景-响应级别的对应关系”;
◆确定期望的质量属性响应级别的效用(根据效用表确定所对应的具体场景的效用表);
◆计算各架构策略的总收益;
◆根据受成本限制影响的投资报酬率选择架构策略(估算成本,用上一步的收益减去成本,得出收益,并选择收益最高的架构策略)。
12、其他评估方法(仅了解)
-
SAEM方法。将软件架构看作一个最终产品以及设计过程中的一个中间产品,从外部质量属性和内部质量属性两个角度来阐述它的评估模型,旨在为软件架构的质量评估创建一个基础框架。
◆外部属性指用户定义的质量属性,而内部属性指开发者决定的质量属性。该软件架构评估模型包含以下几个流程。
(1)对待评估的质量属性进行规约建模。
(2)为外部和内部的质里属性创建度量准则,先从评估目的(如软件架构比较、最终产品的质量预测),评估角度(如开发者、用户、维护者),评估环境(架构作为最终产品或设计中间产品)出发来定义架构评估的目标,再根据目标相关的属性来提出问题,然后回答每个问题并提出相应的度量准则。
(3)评估质量属性,包括数据收集、度量和结果分析3个活动。
-
SAABNet方法。是一种用来表达和使用定性知识以辅助架构的定性评估。该方法来源于人工智能,允许不确定、不完整知识的推理。该方法使用BBN来表示和使用开发过程中的知识,包含定性和定量的描述,其中定性的描述是所有结点的图,定量的描述是每个结点状态相关的条件概率。其中的变量可分为3类,即架构质量属性变量(如可维护性、灵活性等)、质量属性的度量准则变量(如容错性、响应性等)和架构特征变量(如继承深度、编程语言等),高层抽象的质量属性变量分解为低层抽象的度量准则变量,度量准则变量则分解为更低层抽象的架构特征变量。
-
SACMM方法。是一种软件架构修改的度量方法。
-
SASAM方法。通过对预期架构(架构设计阶段的相关描述材料)和实际架构(源代码中执行的架构)进行映射和比较来静态地评估软件架构。
-
ALRRA方法。是一种软件架构可靠性风险评估方法,该方法使用动态复杂度准则和动态耦合度准则来定义组件和连接件的复杂性因素,其中,动态复杂度准则在某个场景的执行中分析组件的动态行为来度量组件的复杂性,动态耦合度准则在某个场景的执行中分析连接件的消息传递协议来度量连接件的复杂性。利用失效模式和影响分析(FMEA)技术。
-
AHP(层次分析法)方法。是对定性问题进行定量分析的一种简便、灵活而又实用的多准则决策方法。AHP方法的特点是把复杂问题中的各种因素通过划分为相联系的有序层次使之条理化,并在一般情况下通过两两对比,根据一定客观现实的主观判断结构,把专家意见和分析者的客观判断结果直接、有效地结合起来,将一定层次上元素的某些重要性进行定量描述,之后利用数学方法计算反映每一层次元素的相对重要性次序的权值,并最后通过所有层次之间的总排序计算所有元素的相对权重及对权重进行排序。
-
COSMIC+UML方法。基于度量模型来评估软件架构可维护性的方法。针对不同表达方式的软件架构,采用统一的软件度量COSMIC方法来进行度量和评估。该方法主要是为了辅助分析软件架构的演化方案是否可行,并在开源软件DCMMS的软件架构UML组件图上得以验证。
11.11、中间件技术
1、中间件:在一个分布式系统环境中处于操作系统和应用程序之间的软件,可以在不同的技术之间共享资源,将不同的操作系统、数据库、异构的网络环境以及若干应用结合成一个有机的协同工作整体。
◆中间件位于客户机/服务器的操作系统之上,管理计算机资源和网络通信,有如下特点:
(1)中间件是一类软件,而非一种软件;
(2)中间件不仅仅实现互连,还要实现应用之间的互操作;
(3)中间件是基于分布式处理的软件,最突出的特点是其网络通信功能。
◆中间件的任务是使应用程序开发变得更容易,通过提供统一的程序抽象,隐藏异构系统和分布式系统下低级别编程的复杂度。
2、主要的中间件有五类:
◆数据库访问中间件:通过一个抽象层访问数据库,从而允许使用相同或相似的代码访问不同的数据库资源。典型的技术如Windows平台的ODBC和Java平台的JDBC等。
◆远程过程调用(RPC):是一种广泛使用的分布式应用程序处理方法。一个应用程序使用RPC来“远程”执行一个位于不同地址空间内的过程,从效果上看和执行本地调用相同。
◆面向消息中间件(MOM):利用高效可靠的消息传递机制进行平台无关的数据交流,并可基于数据通信进行分布系统的集成。通过提供消息传递和消息排队模型,可在分布环境下扩展进程间的通信,并支持多种通信协议、语言、应用程序、硬件和软件平台。典型的产品如IBM的MQSeries。
◆分布式对象中间件:随着对象技术与分布式计算技术的发展,两者相互结合形成了分布式对象技术,并发展成为当今软件技术的主流方向。典型的产品如OMG的CORBA、Sun的RMI/EJB、Microsoft的DCOM等。
- CORBA构件模型中可移植对象适配器POA的作用是在底层传输平台与接收调用并返回结果的对象实现之间进行协调。伺服对象Servant是最终完成客户请求的服务对象实现。对象请求代理ORB的作用是为用户提供与其他分布式网络环境中对象通信的接口。
- OMG接口定义语言IDL文件包括六种不同的元素(接口描述、模块定义、类型定义、常量定义、异常、值类型),接口描述是一个IDL文件最核心的内容,模块定义将映射为Java语言中的包或C++语言中的命名空间。
◆事务中间件:也称事务处理监控器(TPM)最早出现在大型机上。事务处理监控程序位于客户和服务器之间,完成事务管理与协调、负载平衡、失效恢复等任务,提高系统的整体性能。
3、软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。软件元素包括需求分析文档、设计文档、程序代码、测试用例和领域知识。
11.12、典型应用架构
1、J2EE核心技术
◆ J2EE 平台采用了多层分布式应用程序模型,实现不同逻辑功能的应用程序被封装到不同的构件中,处于不同层次的构件被分别部署到不同的机器中。
◆客户层组件:J2EE应用程序可以是基于web方式的,也可以是基于传统方式的静态的HTML(标准通用标记语言下的一个应用)页面和Applets是客户层组件
◆ web 层组件:J2EE web层组件可以是JSP 页面或Servlet。
◆业务层组件:业务层代码的逻辑用来满足特定领域的业务逻辑处理。
◆信息系统层:企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资源计划(ERP),大型机事务处理,数据库系统,和其它的遗留信息系统。例如,J2EE 应用组件可能为了数据库连接需要访问企业信息系统。
◆ J2EE应用系统支持5种不同类型的构件模型:Applet、Servlet、JSP、EJB、Application Client。
◆ 四层结构
2、JSP+Servlet+JavaBean+DAO
◆ JSP:用于显示、收集数据的部分。作为MVC中的视图V。
◆ Servlet:作为业务逻辑层,用于处理复杂的业务逻辑,如验证数据、实例化JavaBean、调用DAO连接数据库等。作为MVC中的控制器C。在其中会调用Service方法处理服务。
◆ JavaBean:用于数据的封装,方便将查询结果在servlet与jsp页面之间进行传递等。
◆ DAO:用于连接数据库及进行数据库的操作如:查询、删除、更改等。
DAO与JavaBean合在一起为MVC中的模型M。
◆基本流程:JSP发一个数据到servlet,servlet收到后做下解析再根据数据调用相应的service去服务,service如果有要调用数据库就通过DAO跟数据库交互,使用javaBean完成封装,返回结果给servlet,servlet再返回给JSP。
重量级与轻量级之争
◆重量级框架占用资源过多,在开发的过程中效率很低;大部分时间花在配置、运行的过程中,修改复杂;单元测试也比较麻烦。但在大量运行过程中会表现出优异的效果,也即开发麻烦,运行性能高。
◆轻量级框架提高了开发的速度;立即可以看到结果;做单元测试非常简单;大量线程可供参考的开源代码。开发简单,但运行性能低。
◆.NET平台
.NET框架处于操作系统和.NET应用语言之间,只适用于微软系统,而J2EE支持跨平台,任何安装了JVM的平台。
◆.NET和J2EE之争
1、JVM(将所有JAVA代码都编译为字节码,由JVM解释执行)和CLR(.NET核心技术,类似于JVM,生成中间代码CLR,编译执行)。
2、对多层分布式应用的支持,二者都支持多层分布式应用程序的开发:在表示层的平台支持上,J2EE客户端支持多个平台,.NET只能在微软系统上运行,也正是因此,.NET会对微软系统上的应用进行优化;在业务层,J2EE占优势,因为有许多开源的项目和代码供参考,开发就变得简单;在数据层,二者都支持多种数据库,都非常优秀。
3、安全性,由于JAVA在.NET之后出来,借鉴了.NET优点,JAVA在运行时动态验证,.NET是静态全面验证,二者都非常优秀,不分上下。
4、应用程序的部署,J2EE的部署相对来说较复杂,针对不同的系统要特别布置。
5、可移植性,显然J2EE占优势,一次开发,到处运行。
6、外部支持:J2EE占优势,得到了很多厂家的支持,.NET只是微软一家。
12、软件可靠性基础(2)
12.1、软件可靠性基本概念
1、可靠性
◆软件可靠性是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。
◆软件可靠性和硬件可靠性区别
(1)复杂性:软件复杂性比硬件高,大部分失效来自于软件失效。
(2)物理退化:硬件失效主要是物理退化所致,软件不存在物理退化。
(3)唯一性:软件是唯一的,每个COPY版本都一样,而两个硬件不可能完全一样。
(4)版本更新周期:硬件较慢,软件较快。
◆软件可靠性的定量描述
- 规定时间:自然时间、运行时间、执行时间(占用CPU)。
- 失效概率:软件运行初始时为0,随着时间增加单调递增,不断趋向于1。
- 可靠度:软件系统在规定的条件下、规定的时间内不发生失效的概率。等于1-失效概率。
- 失效强度:单位时间软件系统出现失效的概率。
- 平均失效前时间(MTTF):平均无故障时间,发生故障前正常运行的时间。
- 平均恢复前时间(MTTR):平均故障修复时间,发生故障后的修复时间。
- 平均故障间隔时间(MTBF):失效或维护中所需的平均时间,包括故障时间以及检测和维护设备的时间。MTBF=MTTF+MTTR。
◆系统可用性=MTTF/(MTTF+MTTR)*100%。
2、串并连系统可靠性
3、可靠性测试的意义
(1)软件失效可能造成灾难性的后果。
(2)软件的失效在整个计算机系统失效中的比例较高。
(3)软件可靠性技术很不成熟,加剧了软件可靠性问题的重要性。
(4)软件可靠性问题是造成费用增长的主要原因之一。
(5)软件对生产活动和社会生活的影响越来越大,从而增加了软件可靠性问题在软件工程领域乃至整个计算机工程领域的重要性。
◆广义的软件可靠性测试是指为了最终评价软件系统的可靠性而运用建模、统计、试验、分析和评价等一系列手段对软件系统实施的一种测试。
◆狭义的软件可靠性测试是指为了获取可靠性数据,按预先确定的测试用例,在软件的预期使用环境中,对软件实施的一种测试。它是面向缺陷的测试,以用户将要使用的方式来测试软件。

12.2、软件可靠性建模
◆软件可靠性模型是指为预计或估算软件的可靠性所建立的可靠性框图和数学模型。
◆从技术的角度来看,影响软件可靠性的主要因素包括:运行环境、软件规模、软件内部结构、软件的开发方法和开发环境、软件的可靠性投入。
◆一个软件可靠性模型通常(但不是绝对)由以下几部分组成:
(1)模型假设。模型是实际情况的简化或规范化,总要包含若干假设,例如测试的选取代表实际运行剖面,不同软件失效独立发生等。
(2)性能度量。软件可靠性模型的输出量就是性能度量,如失效强度、残留缺陷数等。在软件可靠性模型中性能度量通常以数学表达式给出。
(3)参数估计方法。某些可靠性度量的实际值无法直接获得,例如残留缺陷数,这时需通过一定的方法估计参数的值,从而间接确定可靠性度量的值。
(4)数据要求。一个软件可靠性模型要求一定的输入数据,即软件可靠性数据。
◆绝大多数的模型包含3个共同假设:
(1)代表性假设。是指可以用测试产生的软件可靠性数据预测运行阶段的软件可靠性行为。
(2)独立性假设。此假设认为软件失效是独立发生于不同时刻,一个软件失效的发生不影响另一个软件失效的发生。
(3)相同性假设。此假设认为所有软件失效的后果(等级)相同,即建模过程只考虑软件失效的具体发生时刻,不区分软件的失效严重等级。
◆软件的可靠性模型分类
-
种子法模型。利用捕获-再捕获抽样技术估计程序中的错误数,在程序中预先有意“播种”一些设定的错误“种子”,然后根据测试出的原始错误数和发现的诱导错误的比例,来估计程序中残留的错误数。
-
失效率类模型。用来研究程序的失效率。
-
曲线拟合类模型。用回归分析的方法研究软件复杂性、程序中的缺陷数、失效率、失效间隔时间。
-
可靠性增长模型。这类模型预测软件在检错过程中的可靠性改进,用增长函数来描述软件的改进过程。
-
程序结构分析模型。是根据程序、子程序及其相互间的调用关系,形成一个可靠性分析网络。
-
输入域分类模型。选取软件输入域中的某些样本“点”运行程序,根据这些样本点在“实际”使用环境中的使用概率的测试运行时的成功/失效率,推断软件的使用可靠性。
-
执行路径分析方法模型。分析方法与上面的模型相似,先计算程序各逻辑路径的执行概率和程序中错误路径的执行概率,再综合出该软件的使用可靠性。
-
非齐次泊松过程模型。是以软件测试过程中单位时间的失效次数为独立泊松随机变量,来预测在今后软件的某使用时间点的累计失效数。
-
马尔可夫过程模型。
-
贝叶斯模型。是利用失效率的试验前分布和当前的测试失效信息,来评估软件的可靠性。
12.3、软件可靠性管理
◆软件可靠性管理是软件工程管理的一部分,它以全面提高和保证软件可靠性为目标,以软件可靠性活动为主要对象,是把现代管理理论用于软件生命周期中的可靠性保障活动的一种管理形式。
◆软件可靠性管理的内容包括软件工程各个阶段的可靠性活动的目标、计划、进度、任务和修正措施等。可靠性各阶段设计任务如下:
◆需求分析阶段:确定可靠性目标、分析影响因素、确定验收标准、制定框架、制定文档编写规范、制定初步计划、确定数据收集规范。
◆概要设计阶段:确定可靠度量度、制定详细验收方案、可靠性设计、收集数据、调整计划、明确后续阶段详细计划、编制文档。
◆详细设计阶段:可靠性设计、预测、调整计划、收集数据、明确后续阶段详细计划、编制文档。
◆编码阶段:可靠性测试(单元)、排错、调整计划、收集数据、明确后续阶段详细计划、编制文档。
◆测试阶段:可靠性测试(集成和系统)、排错、可靠性建模、评价、调整计划、收集数据、明确后续阶段详细计划、编制文档。
◆实施阶段:可靠性测试(验收)、排错、收集数据、调整模型、评价、编制文档。
12.4、软件可靠性设计
◆实践证明,保障软件可靠性最有效、最经济、最重要的手段是在软件设计阶段采取措施进行可靠性控制。
◆可靠性设计其实就是在常规的软件设计中,应用各种方法和技术,使程序设计在兼顾用户的功能和性能需求的同时,全面满足软件的可靠性要求。
◆软件可靠性设计原则:
(1)软件可靠性设计是软件设计的一部分,必须在软件的总体设计框架中使用,并且不能与其他设计原则相冲突。
(2)软件可靠性设计在满足提高软件质量要求的前提下,以提高和保障软件可靠性为最终目标。
(3)软件可靠性设计应确定软件的可靠性目标,不能无限扩大化,并且排在功能度、用户需求和开发费用之后考虑。
◆软件可靠性设计技术主要有容错设计、检错设计和降低复杂度设计等技术。
◆提高系统可靠性的技术可以分为避错(排错)技术和容错技术。避错是通过技术评审、系统测试和正确性证明等技术,在系统正式运行之前避免、发现和改正错误。
◆容错是指系统在运行过程中发生一定的硬件故障或软件错误时,仍能保持正常工作而不影响正确结果的一种性能或措施。容错技术主要是采用冗余方法来消除故障的影响。
◆冗余是指在正常系统运行所需的基础上加上一定数量的资源,包括信息、时间、硬件和软件。冗余是容错技术的基础,通过冗余资源的加入,可以使系统的可靠性得到较大的提高。主要的冗余技术有结构冗余(静态、动态、混合)、信息冗余、时间冗余和冗余附加4种。
◆软件容错的主要方法是提供足够的冗余信息和算法程序,使系统在实际运行时能够及时发现程序设计错误,采取补救措施,以提高系统可靠性,保证整个系统的正常运行。
◆软件容错技术主要有N版本程序设计、恢复块方法和防卫式程序设计等。
◆N版本程序设计:其设计思想是用N个具有相同功能的程序同时执行一项计算,结果通过多数表决来选择。其中N个版本的程序必须由不同的人独立设计,使用不同的方法、设计语言、开发环境和工具来实现,目的是减少N个版本的程序在表决点上相关错误的概率。
◆恢复块设计(动态冗余):动态冗余又称为主动冗余,它是通过故障检测、故障定位及故障恢复等手段达到容错的目的。其主要方式是多重模块待机储备,当系统检测到某工作模块出现错误时,就用一个备用的模块来替代它并重新运行。各备用模块在其待机时,可与主模块一样工作,也可以不工作。前者叫热备份系统(双重系统),后者叫冷备份系统(双工系统、双份系统)。

◆双机容错技术:是一种软硬件结合的容错应用方案。该方案是由两台服务器和一个外接共享磁盘阵列及相应的双机软件组成。
◆双机容错系统采用“心跳”方法保证主系统与备用系统的联系。所谓心跳,是指主从系统之间相互按照一定的时间间隔发送通信信号,表明各自系统当前的运行状态。一旦心跳信号表明主机系统发生故障,或者备用系统无法收到主系统的心跳信号,则系统的高可用性管理软件认为主系统发生故障,立即将系统资源转移到备用系统上,备用系统替代主系统工作,以保证系统正常运行和网络服务不间断。
◆工作模式:双机热备模式;双机互备模式;双机双工模式。
◆集群技术就是将多台计算机组织起来进行协同工作,它是提高系统可用性和可靠性的一种技术。在集群系统中,每台计算机均承担部分计算任务和容错任务,当其中一台计算机出现故障时,系统使用集群软件将这台计算机从系统中隔出离去,通过各计算机之间的负载转嫁机制完成新的负载分担,同时向系统管理人员发出警报。集群系统通过功能整合和故障过渡,实现了系统的高可用性和可靠性。
◆特点:可伸缩性、高可用性、可管理性、高性价比、高透明性。
◆分类:高性能计算集群、负载均衡集群、高可用性集群。
◆负载均衡是集群系统中的一项重要技术,可以提高集群系统的整体处理能力,也提高了系统的可靠性,最终目的是加快集群系统的响应速度,提高客户端访问的成功概率。集群的最大特征是多个节点的并行和共同工作,如何让所有节点承受的负荷平均,不出现局部过大负载或过轻负载的情况,是负载均衡的重要目的。
◆比较常用的负载均衡实现技术主要有以下几种:
(1)基于特定软件的负载均衡(应用层)。很多网络协议都支持重定向功能,例如,基于HTTP重定向服务,其主要原理是服务器使用HTTP重定向指令,将一个客户端重新定位到另一个位置。服务器返回一个重定向响应,而不是返回请求的对象。客户端确认新地址然后重发请求,从而达到负载均衡的目的。
(2)基于DNS的负载均衡属于传输层负载均衡技术,其主要原理是在DNS服务器中为同一个主机名配置多个地址,在应答DNS查询时,DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果,将客户端的访问引导到不同的节点上去,使得不同的客户端访问不同的节点,从而达到负载均衡的目的。
(3)基于NAT的负载均衡。将一个外部IP地址映射为多个内部IP地址,对每次连接需求动态地转换为一个内部节点的地址,将外部连接请求引到转换得到地址的那个节点,上从而达到负载均衡的目的。
(4)反向代理负载均衡。将来自Internet上的连接请求以反向代理的方式动态地转发给内部网络上的多个节点进行处理,从而达到负载均衡的目的。
(5)混合型负载均衡。
12.5、软件可靠性测试与评价
◆软件可靠性测试由可靠性目标的确定、运行剖面的开发、测试用例的设计、测试实施、测试结果的分析等主要活动组成。
◆测试步骤:定义软件运行剖面(为软件的使用行为建模)——设计可靠性测试用例——实施可靠性测试。
◆软件可靠性评价3个过程:选择可靠性模型、收集可靠性数据、可靠性评估和预测。
◆选择可靠性模型考虑因素:模型假设的适用性、预测的能力与质量、模型输出值能否满足可靠性评价需求、模型使用的简便性。
◆可靠性数据的收集:可靠性数据主要是指软件失效数据,是软件可靠性评价的基础,主要是在软件测试、实施阶段收集的。应采用的解决方法:及早确定所采用的的可靠性模型、制订可实施性较强的可靠性数据收集计划、重视软件测试数据的整理和分析、充分利用数据库来完成可靠性数据的存储和统计分析。
◆可靠性评估和预测:判断是否达到了可靠性目标;如未能达到要再投入多少;在软件系统投入实际运行一年或若干时间后,经过维护、升级和修改,软件能否达到交付或部分交付用户使用的可靠性水平。辅助方法:失效数据的图形分析法、试探性数据分析技术。
13、软件架构的演化和维护(2)
13.1、软件架构演化和定义
◆软件架构的演化和维护就是对架构进行修改和完善的过程,目的就是为了使软件能够适应环境的变化而进行的纠错性修改和完善性修改等,是一个不断迭代的过程,直至满足用户需求。
◆本质上讲,软件架构的演化就是软件整体结构的演化,演化过程涵盖软件架构的全生命周期,包括软件架构需求的获取、软件架构建模、软件架构文档、软件架构实现以及软件架构维护等阶段。
◆软件架构演化的重要性体现在:一是架构是整个系统的骨架,是软件系统具备诸多好的特性的保障;二是软件架构作为软件监图为人们宏观管控软件系统的整体复杂性和变化性提供了一条有效途径。
◆软件架构的演化能降低软件演化的成本的原因:
(1)对系统的软件架构进行的形式化、可视化表示提高了软件的可构造性,便于软件演化。
(2)软件架构设计方案涵盖的整体结构信息、配置信息、约束信息等有助于开发人员充分考虑未来可能出现的演化问题、演化情况和演化环境。
(3)架构设计时对系统组件之间的耦合描述有助于软件系统的动态调整。
◆软件架构的定义包含组件、连接件、约束三大要素,这类软件架构演化主要关注的就是这三者之间的添加、修改和删除等。
13.2、面向对象软件架构演化
◆对象演化:在顺序图中,组件的实体是对象,会对架构设计的动态行为产生影响的演化只包括 AddObject (AO) 和 DeleteObject (DO) 两种。
◆ AO 表示在顺序图中添加一个新的对象。这种演化一般是在系统需要添加新的对象来实现某种新的功能,或需要将现有对象的某个功能独立以增加架构灵活性的时候发生。
◆ DO 删除顺序图中现有的一个对象。这种演化一般在系统需要移除某个现有的功能,或需要合并某些对象及其功能来降低架构的复杂度的时候发生。
◆消息演化:将消息演化分为 AddMessage (AM)、DeleteMessage (DM)、SwapMessageOrder (SMO)、OverturnMessage (OM)、ChangeMessageModule (CMM) 5 种。
◆ AM 增添一条新的消息,产生在对象之间需要增加新的交互行为的时候。DM 删除当前的一条消息,产生在需要移除某个交互行为的时候,是 AM 的逆向演化。SMO 交换两条消息的时间顺序,发生在需要改变两个交互行为之间关系的时候。OM 反转消息的发送对象与接收对象,发生在需要修改某个交互行为本身的时候。CMM 改变消息的发送或接收对象,发生在需要修改某个交互行为本身的时候。
◆复合片段演化:复合片段是对象交互关系的控制流描述,表示可能发生在不同场合的交互,与消息同属于连接件范畴。复合片段的演化分为 AddFragment (AF)、DeleteFragment (DF)、FragmentTypeChange (FTC) 和 FragmentConditionChange (FCC)。
◆ FCC 改变复合片段内部执行的条件,发生在改变当前控制流的执行条件时。自动机中与控制流执行条件相对应的转移包括两个,一个是符合条件时的转移,另一个是不符合条件时的转移,因此每次发生 FFC 演化时会同时修改这两个转移的触发事件。
◆ AF 在某几条消息上新增复合片段,发生在需要增添新的控制流时。复合片段所产生的分支是不同类型的。
◆ DF 删除某个现有的复合片段,发生在需要移除当前某段控制流时。DF 与 AF 互为逆向演化过程。
◆ FTC 改变复合片段的类型,发生在需要改变某段控制流时。类型演化意味着交互流程的改变,一般伴随着条件、内部执行序列的同时演化,可以视为复合片段的删除与添加的组合。
◆约束演化:即直接对约束信息进行添加和删除。
◆ AC (Add Constraint) 直接添加新的约束信息,会对架构设计产生直接的影响,需要判断当前设计是否满足新添加的约束要求。
◆ DC (Delete Constraint) 直接移除某条约束信息,发生在去除某些不必要条件的时候,一般而言架构设计均会满足演化后的约束。
13.3、软件架构演化方式的分类
◆3种典型的分类方法;
(1)按照软件架构的实现方式和实施粒度分类:基于过程和函数的演化、面向对象的演化、基于组件的演化和基于架构的演化。
(2)按照研究方法将软件架构演化方式分为4类:第1类是对演化的支持,如代码模块化的准则、可维护性的指示(如内聚和耦合)、代码重构等;第2类是版本和工程的管理工具;第3类是架构变换的形式化方法,包括系统结构和行为变换的模型,以及架构演化的重现风格等;第4类是架构演化的成本收益分析,决定如何增加系统的弹性。
(3)针对软件架构的演化过程是否处于系统运行时期,可以将软件架构演化分为静态演化和动态演化。
◆软件架构的演化时期包括:设计时演化、运行前演化、有限制运行时演化、运行时演化。
◆软件架构静态演化主要是在设计时演化以及运行前演化。与此相对应的维护方法有3类:更正性维护、适应性维护和完善性维护。
◆软件的静态演化一般包括如下5个步骤。
· 软件理解:查阅软件文档,分析软件架构,识别系统组成元素及其之间的相互关系,提取系统的抽象表示形式。
· 需求变更分析:静态演化往往是由于用户需求变化、系统运行出错和运行环境发生改变等原因所引起的,需要找出新的软件需求与原有的差异。
· 演化计划:分析原系统,确定演化范围和成本,选择合适的演化计划。
· 系统重构:根据演化计划对系统进行重构,使之适应当前的需求。
· 系统测试:对演化后的系统进行测试,查找其中的错误和不足之处。
◆一次完整软件架构演化过程可以看作经过一系列原子演化操作组合而成。所谓原子演化操作是指基于UML模型表示的软件架构,在逻辑语义上粒度最小的架构修改操作。每经过一次原子演化操作,架构会形成一个演化中间版本。
◆架构演化的可维护性度量基于组件图表示的软件架构,在较高层次上评估架构的某个原子修改操作对整个架构所产生的影响。这些原子修改操作包括增加/删除模块间的依赖、增加/删除模块间的接口、增加/删除模块、拆分/聚合模块等。
◆架构演化的可靠性评估基于用例图、部署图和顺序图,分析在架构模块的交互过程中某个原子演化操作对交互场景的可靠程度的影响。这些原子修改操作包括增加/删除消息、增加/删除交互对象、增加/删除/修改消息片段、增加/删除用例执行、增加/删除角色等。
◆动态演化是在系统运行期间的演化,需要在不停止系统功能的情况下完成演化,较之静态演化更加困难。具体发生在有限制的运行时演化和运行时演化阶段。
◆架构的动态演化主要来自两类需求:
①软件内部执行所导致的体系结构改变,例如,许多服务器端软件会在客户请求到达时创建新的组件来响应用户需求;
②软件系统外部的请求对软件进行的重配置,例如,操作系统在升级时无须重新启动,在运行过程中就完成对体系结构的修改。
◆软件的动态性分为3个级别:
①交互动态性,要求数据在固定的结构下动态交互;
②结构动态性,允许对结构进行修改,通常的形式是组件和连接件实例的添加和删除,这种动态性是研究和应用的主流;
③架构动态性,允许软件架构的基本构造的变动,即结构可以被重定义,如新的组件类型的定义。
◆根据所修改的内容不同,软件的动态演化主要包括以下4个方面。
· 属性改名:目前所有的ADL都支持对非功能属性的分析和规约,而在运行过程中,用户可能会对这些指标进行重新定义(如服务响应时间)。
· 行为变化:在运行过程中,用户需求变化或系统自身服务质量的调节都将引发软件行为的变化。
· 拓扑结构改变:如增删组件,增删连接件,改变组件与连接件之间的关联关系等。
· 风格变化:一般软件演化后其架构风格应当保持不变,如果非要改变软件的架构风格,也只能将架构风格变为其衍生风格,如两层C/S到三层C/S。
◆目前,实现软件架构动态演化的技术主要有两种:采用动态软件架构(DSA)和进行动态重配置(DR)。DSA是指在运行时刻会发生变化的系统框架结构,允许在运行过程中通过框架结构的动态演化实现对架构的修改;DR从组件和连接件的配置入手,允许在运行过程中增删组件,增删连接件,修改连接关系等操作。
◆实现软件架构动态演化的基本原理是使DSA在可运行应用系统中以一类有状态、有行为、可操作的实体显式地表示出来,并且被整个运行环境共享,作为整个系统运行的依据。也就是说,运行时刻体系结构相关信息的改变可用来触发、驱动系统自身的动态调整。
◆系统必须提供SA动态演化的一些相关功能:保存当前软件架构信息的功能、设置监控机制监视系统有无需求变化、保证演化操作原子性。
◆DSA实施动态演化大体遵循以下4步:①捕捉并分析需求变化;②获取或生成体系结构演化策略;③根据步骤2得到的演化策略,选择适当的演化策略并实施演化;④演化后的评估与检测。
◆基于软件动态重配置的软件架构动态演化主要是指在软件部署之后对配置信息的修改,常常被用于系统动态升级时需要进行的配置信息修改。一般来说,动态重配置可能涉及的修改有:
①简单任务的相关实现修改;
②工作流实例任务的添加和删除;
③组合任务流程中的个体修改;
④任务输入来源的添加和删除;
⑤任务输入来源的优先级修改;
⑥组合任务输出目标的添加和删除;
⑦组合任务输出目标的优先级修改等。
◆动态重配置模式:主从模式、中央控制模式、客户端/服务器模式、分布式控制模式。
13.4、软件架构演化原则
- 演化成本控制原则
- 进度可控原则
- 风险可控原则
- 主体维持原则:保证软件系统主体行为稳定。
- 系统总体结构优化原则
- 平滑演化原则:演化速率趋于稳定。
- 目标一致原则
- 模块独立演化原则
- 影响可控原则
- 复杂性可控原则
- 有利于重构原则
- 有利于重用原则
- 设计原则遵从性原则:判断架构设计原则是否被破坏。
- 适应新技术原则
- 环境适应性原则
- 标准依从性原则
- 质量向好原则
- 适应新需求原则
13.5、软件架构演化评估方法
◆根据演化过程是否已知可将评估过程分为:演化过程已知的评估和演化过程未知的评估。
◆演化过程已知的评估其目的在于通过对架构演化过程进行度量,比较架构内部结构上的差异以及由此导致的外部质量属性上的变化,对该演化过程中相关质量属性进行评估。
◆架构演化评估的执行过程如图所示。图中A0和An表示一次完整演化前后的相邻版本的软件架构。每经过一次原子演化,即可得到一个架构中间演化版本Ai。对每个中间版本架构进行度量,得到架构Ai的质量属性度量值Qi。D(i-1, i)是版本间的质量属性距离。
◆基于度量的架构演化评估方法,其基本思路在于通过对演化前后的软件架构进行度量,比较架构内部结构上的差异以及由此导致的外部质量属性上的变化。具体包括:架构修改影响分析、监控演化过程、分析关键演化过程。
◆当演化过程未知时,我们无法像演化过程已知时那样追踪架构在演化过程中的每一步变化,只能根据架构演化前后的度量结果逆向推测出架构发生了哪些改变,并分析这些改变与架构相关质量属性的关联关系。
13.6、大型网站架构演化


13.7、软件架构维护
◆软件架构维护过程一般涉及架构知识管理、架构修改管理和架构版本管理。
◆软件架构知识管理是对架构设计中所隐含的决策来源进行文档化表示,进而在架构维护过程中帮助维护人员对架构的修改进行完善的考虑,并能够为其他软件架构的相关活动提供参考。
◆架构知识的定义:架构知识 = 架构设计 + 架构设计决策。即需要说明在进行架构设计时采用此种架构的原因。
◆架构知识管理侧重于软件开发和实现过程所涉及的架构静态演化,从架构文档等信息来源中捕捉架构知识,进而提供架构的质量属性及其设计依据以进行记录和评价。
◆在软件架构修改管理中,一个主要的做法就是建立一个隔离区域保障该区域中任何修改对其他部分的影响比较小,甚至没有影响。为此,需要明确修改规则、修改类型,以及可能的影响范围和副作用等。
◆软件架构版本管理为软件架构演化的版本演化控制、使用和评价等提供了可靠的依据,并为架构演化量化度量奠定了基础。
14、未来信息综合技术(2-3)
14.1、物理信息系统
◆信息物理系统(CPS)是控制系统、嵌入式系统的扩展与延伸,其涉及的相关底层理论技术源于对嵌入式技术的应用与提升。
◆CPS 通过集成先进的感知、计算、通信、控制等信息技术和自动控制技术,构建了物理空间与信息空间中人和、机、物、环境、信息等要素相互映射、适时交互、高效协同的复杂系统,实现系统内资源配置和运行的按需响应、快速迭代、动态优化。
◆CPS的本质就是构建一套信息空间与物理空间之间基于数据自动流动的状态感知、实时分析、科学决策、精准执行的闭环赋能体系,解决生产制造、应用服务过程中的复杂性和不确定性问题,提高资源配置效率,实现资源优化。
-
CPS 的体系架构
(1) 单元级CPS。是具有不可分割性的CPS最小单元,是具备可感知、可计算、可交互、可延展、自决策功能的CPS 最小单元,一个智能部件、一个工业机器人或一个智能机床都可能是一个CPS 最小单元。
(2) 系统级CPS。多个最小单元(单元级)通过工业网络(如工业现场总线、工业以太网等),实现更大范围、更宽领域的数据自动流动,实现了多个单元级cps 的互联、互通和互操作,进一步提高制造资源优化配置的广度、深度和精度。包含互联互通、即插即用、边缘网关、数据互操作、协同控制、监视与诊断等功能。其中互连互通、边缘网关和数据互操作主要实现单元级CPS 的异构集成;即插即用主要在系统级CPS 实现组件管理,包括组(单元级CPS)的识别,配置,更新和删除等功能;协同控制是指对多个单元级CPS 的联动和协同控制等;监视与诊断主要是对单元级CPS 的状态实时监控和诊断其是否具备应有的能力。
(3) SoS级。多个系统级CPS 的有机组合构成SoS 级CPS。例如,多个工序(系统的CPS)形成一个车间级的CPS 或者形成整个工厂的CPS。主要实现数据的汇聚,从而对内进行资产的优化和对外形成运营优化服务。其主要功能包括:数据存储、数据融合、分布式计算、大数据分析、数据服务,并在数据服务的基础上形成了资产性能管理和运营优化服务。
-
CPS 的技术体系
◆CPS 技术体系主要分为CPS 总体技术、CPS 支撑技术、CPS 核心技术。
◆CPS 总体技术主要包括系统架构、异构系统集成、安全技术、试验验证技术等,是CPS 的顶层设计技术;
◆CPS 支撑技术主要包括智能感知、嵌入式软件、数据库、人机交互、中间件、SDN(软件定义网络)、物联网、大数据等,是基于CPS 应用的支撑;
◆CPS 核心技术主要包括虚实融合控制、智能装备、MBD、数字孪生技术、现场总线、工业以太网、CAX\MES\ERP\PLM\CRM\SCM 等,是CPS 的基础技术。
◆上述技术体系可以分为四大核心技术要素即 “一硬” (感知和自动控制)、 “一软” (工业软件)、 “一网” (工业网络)、 “一平台” (工业云和智能服务平台)。其中感知和自动控制是CPS实现的硬件支撑;工业软件固化了CPS 计算和数据流程的规则,是CPS 的核心;工业网络是互联互通和数据传输的网络载体;工业云和智能服务平台是CPS 数据汇聚和支撑上层解决方案的基础,对外提供资源管控和能力服务。
CPS的典型应用场景:
(1) 智能设计。在产品及工艺设计、工厂设计过程中的大部分工作都可以在虚拟空间中进行仿真,并实现迭代和改进。包括产品及工艺设计、生产线/工厂设计。
(2) 智能生产。CPS 可以打破生产过程的信息孤岛现象,实现设备的互联互通,实现生产过程监控,合理管理和调度各种生产资源,优化生产计划,达到资源和制造协同,实现 “制造” 到 “智造” 的升级。包块设备管理、生产管理、柔性制造。
(3) 智能服务。通过CPS 按照需要形成本地与远程云服务相互协作、个体与群体、群体与系统的相互协同一体化工业云服务体系,能够更好地服务于生产,解决装备运行日益复杂、使用难度日益增大的困扰,实现智能装备的协同优化,支持企业用户经济性、安全性和高效性经营目标落地。包括健康管理、智能维护、远程征兆性诊断、协同优化、共享服务。
(4) 智能应用。将设计者、生产者和使用者的单调角色转变为新价值创造的参与者,并通过新型价值链的创建反馈到产业链的转型,从根本上调动各个参与者的积极性,实现制造业转型。包括无人装备、产业链互动、价值链共赢。
◆CPS建设路径:CPS体系设计、单元级CPS 建设、系统级CPS 建设和SoS 级CPS 建设阶段。
14.2、人工智能
◆人工智能(AI)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能,感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。
◆人工智能的目标是了解智能的实质,并生产出一种新的能以人类智能相似的方式做出反应的智能机器。该领域的研究包括机器人、自然语言处理、计算机视觉和专家系统等。
◆根据人工智能是否能真正实现推理、思考和解决问题,可以将人工智能分为弱人工智能和强人工智能。
◆人工智能关键技术
-
自然语言处理(NLP)。研究实现人与计算机之间用自然语言进行有效通信的各种理论和方法。主要包括机器翻译(从一种自然语言到另外一种自然语言的翻译)、语义理解(利用计算机理解文章篇章内容,并回答相关问题)和问答系统(让计算机像人类一样用自然语言与人交流)等。
-
计算机视觉。是使用计算机模仿人类视觉系统的科学,让计算机拥有类似人类提取、处理、理解和分析图像以及图像序列的能力,将图像分析任务分解为便于管理的小块任务。
-
知识图谱。就是把所有不同种类的信息连接在一起而得到的一个关系网络,提供了从 “关系” 的角度去分析问题的能力。一般用于反欺诈、不一致性验证等问题。
-
人机交互(HCI)。主要研究人和计算机之间的信息交换。
-
虚拟现实或增强现实(VR/AR)。以计算机为核心的新型视听技术。结合相关科学技术,在一定范围内生成与真实环境在视觉、听觉等方面高度近似的数字化环境
-
机器学习(ML)。是以数据为基础,通过研究样本数据寻找规律,并根据所得规律对未来数据进行预测。目前,机器学习广泛应用于数据挖掘、计算机视觉、自然语言处理、生物特征识别等领域。
◆按照学习模式的不同,机器学习可分为监督学习、无监督学习、半监督学习、强化学习。其中,监督学习需要提供标注的样本集,无监督学习不需要提供标注的样本集,半监督学习需要提供少量标注的样本,而强化学习需要反馈机制。
◆监督学习是利用已记的有限训练数据集,通过某种学习策略/方法建立一个模型,从而实现对新数据/实例的标记(分类)/映射。在自然语言处理、信息检索、文本挖掘、于写体辨识、垃圾邮件侦测等领域获得了广泛应用。
◆无监督学习是利用无标记的有限数据描述隐藏在未标记数据中的结构/规律。无监督学习不需要以人工标注数据作为训练样本,这样不仅便于压缩数据存储、减少计算量、提升算法速度,还可以避免正负样本偏移引起的分类错误问题。无监督学习主要用于经济预测、异常检测、数据挖掘、图像处理、模式识别等领域。
◆半监督学习可以利用少量的标注样本和大量的未标识样本进行训练和分类,从而达到减少标注代价、提高学习能力的目的。半监督学习的算法首先试图对未标识数据进行建模,在此基础上再对标识的数据进行预测。例如,图论推理算法或者拉普拉斯支持向量机等。
◆强化学习可以学习从环境状态到行为的映射,使得智能体选择的行为能够获得环境的最大奖赏,最终目标是使外部环境对学习系统在某种意义下的评价最佳。在机器人控制、无人驾驶、工业控制等领域获得成功应用。
◆按照学习方法的不同,机器学习可分为传统机器学习和深度学习。区别在于,传统机器学习的领域特征需要手动完成,且需要大量领域专业知识;深度学习不需要人工特征提取,但需要大量的训练数据集以及强大的GPU 服务器来提供算力。
◆传统机器学习从一些观测(训练)样本出发,试图发现不能通过原理分析获得的规律,实现对未来数据行为或趋势的准确预测。在自然语言处理、语音识别、图像识别、信息检索等许多计算机领域获得了广泛应用。
◆深度学习是一种基于多层神经网络并以海量数据作为输入规则的自学习方法,依靠提供给它的大量实际行为数据(训练数据集),进行参数和规则调整。深度学习更注重特征学习的重要性。
◆机器学习的常见算法还包括迁移学习、主动学习和演化学习。
◆迁移学习是指当在某些领域无法取得足够多的数据进行模型训练时,利用另一领域数据获得的关系进行的学习。主要在变量有限的小规模应用中使用,如基于传感器网络的定位、文字分类和图像分类等。
◆主动学习通过一定的算法查询最有用的未标记样本,并交由专家进行标记,然后用查询到的样本训练分类模型来提高模型的精度。
◆演化学习基于演化算法提供的优化工具设计机器学习算法,针对机器学习任务中存在大量的复杂优化问题,应用于分类、聚类、规则发现、特征选择等机器学习与数据挖掘问题中。算法通常维护一个解的集合,并通过启发式算子来从现有的解产生新解,并通过挑选更好的解进入下一次循环,不断提高解的质量。
◆人工智能目前典型应用:chatgpt
14.3、机器人
◆机器人技术已经准备进入4.0时代。所谓机器人4.0时代,就是把云端大脑分布在各个地方,充分利用边缘计算的优势,提供高性价比的服务,把要完成任务的记忆场景的知识和常识很好地组合起来,实现规模化部署。特别强调机器人除了具有感知能力实现智能协作,还应该具有一定的理解和决策能力,进行更加自主的服务。
◆我们目前的服务机器人大多可以做到物体识别和人脸识别。在机器人4.0时代,我们需要加上更强的自适应能力。
◆机器人4.0的核心技术
-
云 - 边 - 端的无缝协同计算。云 - 边 - 端一体的机器人系统是面向大规模机器人的服务平台,信息处理和生成主要在云 - 边 - 端上分布处理完成。通常情况下,云侧可以提供高性能的计算和知识存储,边缘侧用来进一步处理数据并实现协同和共享。机器人端只用完成实时操作的功能。
-
持续学习与协同学习。希望机器人可以通过少量数据来建立基本的识别能力,然后可以自主地去找到更多的相关数据并进行自动标注。然后用这些自主得到的数据来对自己已有的模型进行重新训练来提高性能。
-
知识图谱。需要更加动态和个性化的知识;需要和机器人的感知与决策能力相结合。
-
场景自适应。主动观察场景内人和物之间的变化,预测可能发生的事件,从而影响之后的行动模式。这个技术的关键问题在于场景预测能力。就是机器人通过对场景内的各种人和物进行细致的观察,结合相关的知识和模型进行分析,并预测之后事件即将发生的时间,改变自己的行为模式。
-
数据安全。既要保证端到端的安全传输,也要保障服务器端的安全存储。
◆如果按照要求的控制方式分类,机器人可分为操作机器人、程序机器人、示教再现机器人、智能机器人和综合机器人。
-
操作机器人。典型代表是在核电站处理放射性物质时远距离进行操作的机器人。
-
程序机器人。可以按预先给定的程序、条件、位置进行作业。
-
示教再现机器人。机器人可以将所教的操作过程自动地记录在磁盘、磁带等存储器中,当需要再现操作时,可重复所教过的动作过程。示教方法有直接示教与遥控示教两种。
-
智能机器人。既可以进行预先设定的动作,还可以按照工作环境的改变而变换动作。
-
综合机器人。由操纵机器人、示教再现机器人、智能机器人组合而成的机器人,如火星机器人。整个系统可以看作是由地面指令操纵的操作机器人。
◆如果按照应用行业来分,机器人可分为工业机器人、服务机器人和特殊领域机器人。
14.4、边缘计算
◆边缘计算将数据的处理、应用程序的运行甚至一些功能服务的实现,由网络中心下放到网络边缘的节点上。在网络边缘侧的智能网关上就近采集并且处理数据,不需要将大量未处理的原生数据上传到远处的大数据平台。
◆采用边缘计算的方式,海量数据能够就近处理,大量的设备也能实现高效协同的工作,诸多问题迎刃而解。因此,边缘计算理论上可满足许多行业在敏捷性、实时性、数据优化、应用智能,以及安全与隐私保护等方面的关键需求。
◆边缘计算的业务本质是云计算在数据中心之外汇聚节点的延伸和演进,主要包括云边缘、边缘云和云化网关三类落地形态;以 “边云协同” 和 “边缘智能” 为核心能力发展方向;软件平台需要考虑导入云理念、云架构、云技术,提供端到端实时、协同式智能、可信赖、可动态重置等能力;硬件平台需要考虑异构计算能力。
(1) 云边缘:是云服务在边缘侧的延伸,逻辑上仍是云服务,主要的能力提供依赖于云服务或需要与云服务紧密协同。
(2) 边缘云:是在边缘侧构建中小规模云服务能力,边缘服务能力主要由边缘云提供。
(3) 云化网关:以云化技术与能力重构原有嵌入式网关系统,云化网关在边缘侧提供协议/接口转换、边缘计算等能力,部署在云侧的控制器提供边缘节点的资源调度、应用管理与业务编排等能力。
◆边缘计算具有以下特点:
(1) 联接性:联接性是边缘计算的基础。所联接物理对象的多样性及应用场景的多样性,需要边缘计算具备丰富的联接功能。
(2) 数据第一入口:边缘计算作为物理世界到数字世界的桥梁,是数据的第一入口,拥有大量、实时、完整的数据,可基于数据全生命周期进行管理与价值创造,将更好的支撑预测性维护、资产效率与管理等创新应用。
(3) 约束性:边缘计算产品需适配工业现场相对恶劣的工作条件与运行环境,如防电磁、防尘、防爆、抗振动、抗电流/电压波动等。在工业互联场景下,对边缘计算设备的功耗、成本、空间也有较高的要求。
(4) 分布性:边缘计算实际部署天然具备分布式特征。这要求边缘计算支持分布式计算与存储、实现分布式资源的动态调度与统一管理、支撑分布式智能、具备分布式安全等能力。
◆边云协同:边缘计算与云计算各有所长,云计算擅长全局性、非实时、长周期的大数据处理与分析,能够在长周期维护、业务决策支撑等领域发挥优势;边缘计算更适用局部性、实时、短周期数据的处理与分析,能更好地支撑本地业务的实时智能化决策与执行。
◆边缘计算既靠近执行单元,更是云端所需高价值数据的采集和初步处理单元,可以更好地支撑云端应用;反之,云计算通过大数据分析优化输出的业务规则或模型可以下发到边缘侧,边缘计算基于新的业务规则或模型运行。
◆主要包括六种协同:
(1) 资源协同:边缘节点提供计算、存储、网络、虚拟化等基础设施资源、具有本地资源调度管理能力,同时可与云端协同,接受并执行云端资源调度管理策略,包括边缘节点的设备管理、资源管理以及网络连接管理。
(2) 数据协同:边缘节点主要负责现场/终端数据的采集,按照规则或数据模型对数据进行初步处理与分析,并将处理结果以及相关数据上传给云端:云端提供海量数据的存储、分析与价值挖掘。
(3) 智能协同:边缘节点按照AI 模型执行推理,实现分布式智能;云端开展AI 的集中式模型训练,并将模型下发边缘节点。
(4) 应用管理协同:边缘节点提供应用部署与运行环境,并对本节点多个应用的生命周期进行管理调度;云端主要提供应用开发、测试环境,以及应用的生命周期管理能力。
(5) 业务管理协同:边缘节点提供模块化、微服务化的应用/数字孪生/网络等应用实例;云端主要提供按照客户需求实现应用/数字孪生/网络等的业务编排能力。
(6) 服务协同:边缘节点按照云端策略实现部分ECSaaS 服务,通过ECSaaS 与云端SaaS的协同实现面向客户的按需SaaS服务;云端主要提供SaaS 服务在云端和边缘节点的服务分布策略,以及云端承担的SaaS 服务能力。
◆边缘计算的应用场合:智慧园区、安卓云与云游戏、视频监控、工业互联网、Cloud VR。
14.4、数字孪生体
◆数字孪生体技术是跨层级、跨尺度的现实世界和虚拟世界建立沟通的桥梁。
◆数字孪生体是现有或将有的物理实体对象的数字模型,通过实测、仿真和数据分析来实时感知、诊断、预物理实体对象的状态,通过优化和指令来调控物理实体对象的行为,通过相关数字模型间的相互学习来进化自身,同时改进利益相关方在物理实体对象生命周期内的决策。
◆关键技术
-
建模。建模的目的是将我们对物理世界的理解进行简化和模型化。而数字孪生体的目的或本质是通过数字化和模型化,用信息换能量,以使少的能量消除各种物理实体、特别是复杂系统的不确定性。需求指标、生存期阶段和空间尺度构成了数字孪生体建模技术体系的三维空间。
-
仿真。如果说建模是模型化我们对物理世界或问题的理解,那么仿真就是验证和确认这种理解的正确性和有效性。所以,数字化模型的仿真技术是创建和运行数字孪生体、保证数字孪生体与对应物理实体实现有效闭环的核心技术。
仿真是将包含了确定性规律和完整机理的模型转化成软件的方式来模拟物理世界的一种技术。只要模型正确,并拥有了完整的输入信息和环境数据,就可以基本准确地反映物理世界的特性和参数。 -
其他技术。VR、AR以及MR等增强现实技术、数字线程、系统工程和MBSE、物联网、云计算、雾计算、边缘计算、大数据技术、机器学习和区块链技术。
◆数字孪生体主要应用于制造、产业、城市和战场。
14.5、云计算
◆云计算概念的内涵包含两个方面:平台和应用。平台即基础设施,其地位相当于PC 上的操作系统,云计算应用程序需要构建在平台之上;云计算应用所需的计算与存储通常在 “云端” 完成,客户端需要通过互联网访问计算与存储能力。
◆云计算的服务方式
-
软件即服务(SaaS)。在 SaaS 的服务模式下,服务提供商将应用软件统一部署在云计算平台上,客户根据需要通过互联网向服务提供商订购应用软件服务,服务提供商根据客户所订购软件的数量、时间的长短等因素收费,并且通过标准浏览器向客户提供应用服务。
-
平台即服务(PaaS)。在 PaaS 模式下,服务提供商将分布式开发环境与平台作为一种服务来提供。这是一种分布式平台服务,厂商提供开发环境、服务器平台、硬件资源等服务给客户,客户在服务提供商平台的基础上定制开发自己的应用程序,并通过其服务器和互联网传递给其他客户。
-
基础设施即服务(IaaS)。在 IaaS 模式下,服务提供商将多台服务器组成的“云端”基础设施作为计量服务提供给客户。具体来说,服务提供商将内存、I/O 设备、存储和计算能力等整合为一个虚拟的资源池,为客户提供所需要的存储资源、虚拟化服务器等服务。
◆在灵活性方面,SaaS → PaaS → IaaS 灵活性依次增强。
◆在方便性方面,IaaS → PaaS → SaaS 方便性依次增强。
◆云计算的部署模式
-
公有云。在公有云模式下,云基础设施是公开的,可以自由地分配给公众。企业、学术界与政府机构都可以拥有和管理公用云,并实现对公有云的操作。公有云能够以低廉的价格为最终用户提供有吸引力的服务,创造新的业务价值。
-
社区云。在社区云模式下,云基础设施分配给一些社区组织所专有,这些组织共同关注任务、安全需求、政策等信息。云基础设施被社区内的一个或多个组织所拥有、管理及操作。“社区云”是“公有云”范畴内的一个组成部分。
-
私有云。在私有云模式下,云基础服务设施分配给由多种用户组成的单个组织。它可以被这个组织或其他第三方组织所拥有、管理及操作。
-
混合云。混合云是公有云、私有云和社区云的组合。由于安全和控制原因,并非所有的企业信息都能放置在公有云上,因此企业将会使用混合云模式。
14.6、大数据
◆大数据是指其大小或复杂性无法通过现有常用的软件工具,以合理的成本并在可接受的时间内对其进行捕获、管理和处理的数据集。这些困难包括数据的收入、存储、搜索、共享、分析和可视化。
◆大数据的特点:大规模、高速度、多样化、可变性、复杂性等。
◆大数据分析的分析步骤,大致分为数据获取 / 记录、信息抽取 / 清洗 / 注记、数据集成 / 聚集 / 表现、数据分析 / 建模和数据解释5个主要阶段。
◆大数据的应用领域:制造业、服务业、交通行业、医疗行业。
15、知识产权和标准化
15.1、知识产权概述
◆知识产权是指公民、法人、非法人单位对自己的创造性智力成果和其他科技成果依法享有的民事权。是智力成果的创造人依法享有的权利和在生产经营活动中标记所有人依法所享有的权利的总称。包含著作权、专利权、商标权、商业秘密权、植物新品种权、集成电路布图设计权和地理标志权等。
◆无体性:知识产权的对象是没有具体形体,是智力创造成果,是一种抽象的财富。
◆专有性:指除权利人同意或法律规定外,权利人以外的任何人不得享有或使用该项权利。
◆地域性:指知识产权只在授予其权利的国家或确认其权利的国家产生,并且只能在该国范围内受法律保护,而其他国家则不受保护。
◆时间性:仅在法律规定的期限内受到保护,一旦超过期限,权利自行消灭,相关知识产品即成为整个社会的共同财富,为全人类所共同使用。
15.2、保护期限

15.3、知识产权人的缺点


15.4、侵权判定

15.5、标准划分
根据标准制定机构和适用范围的不同,可分为国际标准、国家标准、行业标准、区域/地方标准和企业标准
(1) 国际标准:是指国际标准化组织(ISO)、国际电工委员会(IEC)和国际电信联盟(ITU)制定的标准,以及国际标准化组织确认并公布的其他国际组织制定的标准。国际标准在世界范围内统一使用,提供各国参考。
(2) 国家标准:是指由国家标准化主管机构制定或批准发布,在全国范围内统一适用的标准。比如:GB–中华人民共和国国家标准;强制性国家标准代号为 GB,推荐性国家标准代号为 GB/T,国家标准指导性文件代号为 GB/Z,国军标代号为 GJB。ANSI (American National Standards Institute) —美国国家标准协会标准;
(3) 行业标准:是由某个行业机构、团体等制定的,适用于某个特定行业业务领域的标准。比如:IEEE—美国电气电子工程师学会标准;GA–公共安全标准;YD–通信行业标准;
(4) 区域/地方标准:是由某一区域/地方内的标准化主管机构制定、批准发布的,适用于某个特定区域/地方的标准。比如:EN–欧洲标准;
(5) 企业标准:是企业范围内根据需要协调、统一的技术要求、管理要求和工作要求所制定的标准,适用于本企业内部的标准。一般以 Q 字开头,比如 Q/320101 RER 007–2012,其中 320101 代表地区,RER 代表企业名称代号,001 代表该企业该标准的序号,2012 代表年号。
16、其他架构
16.1、大数据架构
1、Lambda架构

2、Kappa架构


3、Lambda架构和Kappa架构的对比和选择
4、大数据架构设计案例分析
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐


所有评论(0)