第五章 信息系统工程 (2024年详细解析版)

目录

• 5.1 软件工程
  • 5.1.1 架构设计
    • 5.1.1.1 什么是架构设计
    • 5.1.1.2 软件架构研究的主要内容
      • 5.1.1.2.1 软件架构风格
        • 5.1.1.2.1.1 管道/过滤器
        • 5.1.1.2.1.2 面向对象模式
        • 5.1.1.2.1.3 层次结构
        • 5.1.1.2.1.4 事件驱动模式
      • 5.1.1.2.2 软件架构评估
        • 软件架构评估的方式
  • 5.1.2 需求分析
    • 5.1.2.1 什么是软件需求
    • 5.1.2.2 需求的层次
      • 业务需求
      • 用户需求
      • 系统需求
    • 5.1.2.3 需求的特征
    • 5.1.2.4 需求过程
      • 需求获取
      • 需求分析(非常耗时,特别考验开发团队的能力)
      • 编写规约
      • 需求验证与确认
        • 5.1.2.4 1 结构化分析方法SA
          • 5.1.2.4 1.1 E-R图示例
          • 5.1.2.4 1.2 DFD图示例
          • 5.1.2.4 1.3 STD图示例
        • 5.1.2.4 2 面向对象分析方法OOA ( Object-Oriented Analysis )
  • 5.1.3 统一建模语言UML
    • 5.1.3.1 什么是UML?
    • 5.1.3.2 UML包含的三种结构
    • 5.1.3.3 UML中的事物
    • 5.1.3.4 UML 2.0中的14种图
      • 5.1.3.4.1 类图(Class diagram) ---- 最重要的
        • 5.1.3.4.1.1 依赖关系
        • 5.1.3.4.1.2 关联关系
        • 5.1.3.4.1.3 泛化关系
        • 5.1.3.4.1.4 实现关系
        • 5.1.3.4.1.5 聚合关系
        • 5.1.3.4.1.6 组合关系
        • 5.1.3.4.1.7 聚合和组合的区别
      • 5.1.3.4.2 对象图( Object diagram）----- 不重要
      • 5.1.3.4.3 包图（ Package diagrams ) ----- 不重要
      • 5.1.3.4.4 构件图（ Component diagram )
      • 5.1.3.4.5 组合结构图（ Composite structure diagram ) ----- 不考
      • 5.1.3.4.6 部署图（ Deployment diagram ）----- 考过
      • 5.1.3.4.7 用例图（ Use case diagrams ) ----- 非常重要
        • 5.1.3.4.7.1 用例之间的四种关系
        • 5.1.3.4.7.2 用例关系
      • 5.1.3.4.8 状态图 ( State machine diagrams )
      • 5.1.3.4.9 活动图（ Activity diagrams )
      • 5.1.3.4.10 顺序图 ( Sequence diagrams )
      • 5.1.3.4.11 通信图（ Communication diagrams )
      • 5.1.3.4.12 定时图（ Timing diagrams )
    • 5.1.3.5 交互概览图（ lnteraction overview diagrams )
    • 5.1.3.6 UML中的视图(记住标题)
  • 5.1.4 面向对象分析
    • 5.1.4.1 面向对象分析OOA
    • 5.1.4.2 面向对象设计OOD
    • 5.1.4.3 OOA到OOD转换(了解)
    • 5.1.4.4 构建用例模型的阶段
    • 5.1.4.5 类之间的关系
  • 5.1.5 软件设计
    • 5.1.5.1 软件设计
    • 5.1.5.2 设计原则：高内聚低耦合
    • 5.1.5.3 设计原则：高内聚低耦合
    • 5.1.5.4 面向对象软件设计七大原则
    • 5.1.5.5 设计模式
    • 5.1.5.6 软件设计
  • 5.1.6 软件实现
    • 5.1.6.1 软件配置管理
    • 5.1.6.2 软件配置管理
      • 5.1.6.2.1 程序设计语言
      • 5.1.6.2.2 程序设计风格
      • 5.1.6.2.3 程序复杂性度量
      • 5.1.6.2.4 编码效率
    • 5.1.6.3 软件测试
      • 5.1.6.3.1 软件测试模型
        • 5.1.6.3.1.1 V 模型
        • 5.1.6.3.1.2 W 模型
      • 5.1.6.3.2 按开发阶段划分
        • 5.1.6.3.2.1 单元测试
        • 5.1.6.3.2.2 集成测试
        • 5.1.6.3.2.3 系统测试
        • 5.1.6.3.2.4 验收测试
        • 5.1.6.3.2.5 概念辨析：α、β、入测试(了解)
      • 5.1.6.3.3 静、动态测试
        • 5.1.6.3.3.1 静态测试
        • 5.1.6.3.3.2 动态测试
        • 5.1.6.3.3.3 两者区别(静态测试反而在很多情况是必要的)
      • 5.1.6.3.4 黑、白盒测试
        • 5.1.6.3.4.1 黑盒测试(动态测试用到黑盒测试)
        • 5.1.6.3.4.2 白盒测试(白盒测试一般和静态测试相结合)
        • 5.1.6.3.4.3 两者之间的联系
        • 5.1.6.3.4.4 灰盒测试(知道基本概念就好)
  • 5.1.7 部署交付
    • 5.1.7.1 软件部署与交付
    • 5.1.7.2 持续交付(强调开发)
    • 5.1.7.3 持续部署(强调方便性)
      • 1）持续部署方案
      • 2）部署原则
      • 3）部署层次
      • 4）不可变服务器
      • 5）蓝绿部署和金丝雀部署
    • 5.1.7.4 部署与交付的新趋势
  • 5.1.8 过程管理(软件工程里工程三个方向:方法,工具,过程)
    • 5.1.8.1 基本概念
    • 5.1.8.2 成熟度模型 ( CSMM )
    • 5.1.8.3 成熟度等级
    • 5.1.8.4 能力域与成熟度等级的对应关系
• 5.2 数据工程
  • • 什么是数据工程？(就是数据库做的事情)
  • 5.2.1 数据建模
    • 5.2.1.1 什么是数据建模？
    • 5.2.1.2 数据模型
    • 5.2.1.2.1 概念模型
    • 5.2.1.2.2 逻辑模型
    • 5.2.1.2.3 物理模型
    • 5.2.1.3 数据建模过程
      • 1. 数据需求分析
      • 2. 概念模型设计
      • 3. 逻辑模型设计
      • 4. 物理模型设计
  • 5.2.2 数据标准化
    • 5.2.2.1 什么是数据标准化？
    • 5.2.2.2 元数据标准化
      • 元数据是关于数据的数据 ( Data About Data )
      • 元数据描述的对象
      • 元数据体系与元数据类型
    • 5.2.2.3 数据元标准化
      • 什么是数据元
      • 数据元由三部分组成：
      • 数据元提取方法
      • 数据元标准的制定过程
    • 5.2.2.4 数据模式标准化
      • 数据模式(就是数据模型)
      • 制定数据模式的任务
      • 数据模式的描述方式(数据建模的方式)
    • 5.2.2.5 数据分类与编码标准化
      • 数据分类
      • 数据编码：
      • 数据分类与编码标准化的作用
    • 5.2.2.6 数据标准化管理
      • ( 1 ）确定数据需求
      • ( 2 ）制定数据标准(企业有直接用,企业没有要制定,或者参考行业标准)
      • ( 3 ）批准数据标准
      • ( 4 ）实施数据标准
  • 5.2.3 数据运维
    • 5.2.3.1 数据存储
    • 5.2.3.2 数据备份
    • 5.2.3.3 数据容灾
    • 5.2.3.4 数据质量评价与控制
      • 1) 数据质量描述
      • 2) 数据质量评价过程
      • 3）数据质量评价方法
      • 4）数据质量控制
      • 5）数据清理
  • 5.2.4 数据开发利用
    • 5.2.4.1 数据集成
    • 5.2.4.2 数据挖掘
    • 5.2.4.3 数据服务
    • 5.2.4.4 数据可视化
    • 5.2.4.5 信息检索
      • 信息检索（ Information Retrieval ）定义
      • 信息检索的主要方法
      • 信息检索的常用技术(不完全独立,混合使用)
  • 5.2.5 数据库安全
    • 5.2.5.1 数据库安全威胁
    • 5.2.5.2 数据库安全对策
    • 5.2.5.3 数据库安全机制
• 5.3 系统集成
  • 5.3.1 集成基础
    • 5.3.1.1 什么是系统集成？
    • 5.3.1.2 系统集成基本原则
      • （ 1 ）开放性
      • （ 2 ）结构化
      • （ 3 ）先进性
      • （ 4 ）主流化
  • 5.3.2 网络集成
    • 5.3.2.1 网络集成分类
    • 5.3.2.2 网络集成内容解析
      • （ 1 ）传输子系统
      • （ 2 ）交换子系统
      • （ 3 ）安全子系统
      • （ 4 ）网管子系统
      • （ 5 ）服务器子系统
      • （ 6 ）网络操作系统
      • （ 7 ）服务子系统
  • 5.3.3 数据集成
    • 5.3.3.1 什么是数据集成？
    • 5.3.3.2 数据集成的层次
      • （ 1 ）基本数据集成。
      • （ 2 ）多级视图集成
      • （ 3 ）模式集成。
      • （ 4 ）多粒度数据集成
    • 5.3.3.3 异构数据集成(有难度)
      • 1) 异构数据集成的方法
      • 2 ) 开放数据库互联标准
      • 3) 基于XML的数据交换标准
      • 4) 基于JSON的数据交换格式
  • 5.3.4 软件集成
    • 5.3.4.1 CORBA
    • 5.3.4.2 COM（ 组件对象模型 ）
    • 5.3.4.3 DCOM与COM+
      • DCOM（分布式组件对象模型）
      • COM +
    • 5.3.4.4 .NET
    • 5.3.4.5 J2EE
  • 5.3.5 应用集成
    • 5.3.5.1 系统集成栈
    • 5.3.5.2 组织应用集成EAI
• 5.4 安全工程
  • 5.4.1 信息安全系统工程概述
    • 5.4.1.1 几个概念之间的关系
    • 5.4.1.2 信息安全系统体系架构(理解为主)
  • 5.4.2 信息安全系统工程体系架构(重点)
    • 5.4.2.1 ISSE - CMM 基础(介绍)
    • 5.4.2.2 ISSE 过程(细节)
      • 1 ) 工程过程
      • 2 ）风险过程
      • 3 ）保证过程
    • 5.4.2.3 ISSE - CMM 体系结构
      • 1）域维/过程域
      • 2）能力维/公共特性
      • 3）能力级别
• 5.5 单词汇总
• 附录

5.1 软件工程

什么是软件工程

• 软件工程（ Software Engineering ，简称为 SE )，是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。

5.1.1 架构设计

5.1.1.1 什么是架构设计

• 软件架构为软件系统提供了一个结构、行为和属性的高级抽象.(架构并不涉及非常具体的技术.)

• 构件: 组成部分
• 集成模式 : 很多构件组成到一块
• 拓扑结构 : 连接关系

5.1.1.2 软件架构研究的主要内容

• 软件架构描述: 什么是软件架构?
• 软件架构风格: 软件架构细节
• 软件架构评估: 软件架构是否合适?
• 软件架构的形式化方法: 如何把软件架构形式化表现出来?

软件架构设计的一个核心问题是能否达到架构级的软件复用.

5.1.1.2.1 软件架构风格

• 软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式 ( Idiomatic Paradigm ) 。(系统组织方式 : 信息系统由哪些部分如何组成.架构风格:  其他人员已经在同样一个应用领域反复使用的.)

• 架构风格定义了一个系统 “ 家族 ” ，即一个架构定义、二个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而约束指出系统是如何将这些构件和连接件组合起来的。(约束: 是什么情况下才能用这种架构风格)

• 架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统。(例如:搜索引擎,可以使用搜索引擎领域使用的通用架构风格)

• 软件架构风格包括：

  • 数据流风格 ：批处理序列、管道/过滤器
  • 调用/返回风格 ：主程序/子程序、数据抽象、面向对象、层次结构
  • 独立构件风格 ：进程通信、事件驱动的系统
  • 虚拟机风格 ：解释器、基于规则的系统
  • 仓库风格 ：数据库系统、黑板系统、超文本系统

5.1.1.2.1.1 管道/过滤器

• 每个构件都有一组输入/输出，构件读取输入的数据流，经过内部处理后，产生输出数据流，该过程主要完成输入流的变换及增量计算。通常将这里的构件成称为过滤器.(例如:搜索引擎搜索信息系统管理师教程,过滤器对其过滤,划分成信息系统,管理师,视频,再输出给下一个过滤器(过滤器相当于一段小的执行程序))

• 需要协调 : 需要多个过滤器摆放组合
• 性能下降 : 同一批数据处理需要涉及到很多步骤,会引起性能下降.
• 实现复杂 : 过滤器组成部分很多,实现就会复杂.

5.1.1.2.1.2 面向对象模式

• 典型应用是基于构件的软件开发 ( CBD )

5.1.1.2.1.3 层次结构

• 采用层次化组织方式，将复杂问题逐步分层。每一层都为上一层提供服务并使用下一层提供的功能。(需要层层调用,不能夸层调用,一般操作系统如此使用,应用软件也可以这样使用.)

5.1.1.2.1.4 事件驱动模式

• 构件并不直接调用过程，而是触发一个或多个事件。系统中的其他构件可以注册相关的事件，触发一个事件时，系统会自动调用注册了该事件的构件过程，即触发事件会导致另一构件中过程的调用.(系统中提供的可视化交互,都是采用事件驱动模式)

使用事件驱动系统的典型应用包括各种图形界面工具(背一下).

5.1.1.2.2 软件架构评估

• 架构的选择往往是一个系统设计成败的关键。在架构评估过程中，评估人员最关注的是系统的质量属性（ 可用性、可修改性、性能、安全性、可测试性易用性 )

• 敏感点 : 只影响一个属性,比如 : 请了高级的设计,使得界面美观,就只影响美观这一件事,不影响其他的安全,性能的属性,这种就是敏感点.
• 权衡点 : 影响多个属性, 比如 : 安全性就是权衡点 , 安全性验证太多,就会影响系统的反应时间,系统的性能,开发成本提高了,安全性一个属性影响方方面面,这就是权衡点,更加复杂,更加考研系统架构.

软件架构评估的方式

• 从目前已有的软件架构评估技术来看，可以归纳为三类评估方式

• 调查问卷法 : 是调查需求的常用手段.可以是纸质版,也可以是电子版.(主观的)
• 度量法 : 客观的,相应速度,客观数据显示
• 场景评估法 : 对重要场景进行评估
  • 场景评估法分析软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度(了解)

• 基于场景的方式
  • 从三方面来对场景进行捕述
    • 刺激（ STIMULUS ）：解释或描述项目干系人怎样引发与系统的交互(用户如何与系统进行交互)
    • 环境 ( ENVIRONMENT ）：刺激发生时的情况 ( 当前系统情况)
    • 响应（ RESPONSE ）：系统是如何通过架构对刺激作出反应的(系统反馈信息)

5.1.2 需求分析

5.1.2.1 什么是软件需求

• 软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望(用户对新系统各个方面的期望)
• IEEE：软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明

(总结)软件需求就是系统必须完成的事以及必须具备的品质(或特性)

5.1.2.2 需求的层次

业务需求

• 反映企业或客户对系统高层次的目标要求，通常来自项目投资人、客户、客户单位的管理人员、市场营销部门或产品策划部门等

用户需求

• 用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么

系统需求

• 从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等

  • 功能需求：规定了开发人员必须在系统中实现的软件功能，通常通过系统特性的描述表现出来的(软件系统必须实现的功能)
  • 非功能需求：系统必须具备的属性或品质，如，可修改性、可维护性、效率等(完成任务过程中要体现哪些特性.)
  • 设计约束：限制条件或补充规约，通常是对系统的约束说明，如，必须采用国产数据库系统，必须运行在UNIX下(设计系统必须遵守的.)

5.1.2.3 需求的特征

• 可追踪性 : 形成的所有需求,要放到需求追踪矩阵表格里,根据需求跟踪矩阵去追踪哪个需求完成到什么程度.
• 无歧义性 : 不能需求提出不同的人有不同的理解是不行的.
• 可验证性考试考察过.

5.1.2.4 需求过程

需求获取

• 确定和理解项目干系人的需求和约束的过程·方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等·

需求分析(非常耗时,特别考验开发团队的能力)

• 提炼、分析和审查已经获取到的需求，以确保所有项目干系人清楚各项需求的含义，发现遗漏和不足

• 需求分析方法包括SA方法和OOA方法等

编写规约

• 形成软件需求规格说明书(英文缩写,SRS)，是干系人对需求的共同理解，是开发的基础。
• GB/T 8567-2006 提供了SRS的文档模板和编写指南

需求验证与确认

• 在系统分析阶段检测SRS中的错误，节省时间和资金一一般通过需求评审和需求测试工作来对需求进行验证

5.1.2.4 1 结构化分析方法SA

• 结构化分析 ( Structured Analysis ) 是软件工程中的一种方法，其建立的模型的核心是数据字典。结构化分析有三个层次的模型：

5.1.2.4 1.1 E-R图示例

• 实体-关系图

5.1.2.4 1.2 DFD图示例

• 数据流图.

5.1.2.4 1.3 STD图示例

• 状态转换图 : 非常细节的系统状态变迁.

5.1.2.4 2 面向对象分析方法OOA ( Object-Oriented Analysis )

• 运用OO方法对问题域进行分析和理解，找出描述问题域和系统功能所需的类和对象，最终产生OOA模型

5.1.3 统一建模语言UML

5.1.3.1 什么是UML?

• 统一建模语言（UML，Unified Modeling Language）是一个通用的可视化建模语言，它是面向对象分析和设计的一种标准化表示，用于对软件进行描述、可视化处理、构造和建立软件系统的文档

• UML的特点：

  • 支持需求分析开始的软件开发全过程
  • UML不是一种可视化的程序设计语言，是一种可视化的建模语言
  • 是一种建模语言规格说明，是面向对象分析与设计的一种标准表示
  • 不是过程，也不是方法
  • 简单并且可扩展，具有扩展和专有化机制，便于扩展，无需对核心概念进行修改

5.1.3.2 UML包含的三种结构

5.1.3.3 UML中的事物

5.1.3.4 UML 2.0中的14种图

5.1.3.4.1 类图(Class diagram) ---- 最重要的

• 类图用来显示系统中的类、接口、协作以及它们之间的静态结构和关系，是UML中最常见的图。

• 类图的3个基本组成部分：类名、属性、方法

• 类之间的关系：

  • 泛化
  • 关联
  • 依赖
  • 实现
  • 聚合 (组合)

5.1.3.4.1.1 依赖关系

• 依赖 ( Dependency ) ：对象之间最弱的一种关联方式，是临时性的关联。代码中一般指由局部变量、函数参数、返回值建立的对于其他对象的调用关系。
• 在类图使用带箭头的虚线表示，箭头从使用类指向被依赖的类.

5.1.3.4.1.2 关联关系

• 关联（ Association ）：对象之间一种引l用关系，比如客户类与订单类之间的关系。这种关系通常使用类的属性表达。
• 在类图使用带箭头的实线表示，箭头从使用类指向被关联的类。可以是单向和双向.

5.1.3.4.1.3 泛化关系

• 泛化 ( generalization )：表示is-a的关系，是对象之间耦合度最大的一种关系子类继承父类的所有细节。直接使用语言中的继承表达。(子类自动继承父类的属性和方法,这种特性叫做继承,这种关系用泛化关系表达,图像是子类指向父类用空心三角形,泛化也叫继承.)
• 在类图中使用带三角箭头的实线表示，箭头从子类指向父类

5.1.3.4.1.4 实现关系

• 实现（ Realization ）：在类图中就是接口和实现的关系
• 在类图中使用带三角箭头的虚线表示，箭头从实现类指向接口

5.1.3.4.1.5 聚合关系

• 聚合 ( Aggregation ）：表示 has-a 的关系，是一种不稳定的包含关系，没有整体，局部也可单独存在。(松散的表示整体部分关系,离开整体部分还是可以存在.例如: 员工离职还可以去其他公司继续干活)
• 在类图使用空心的菱形表示，菱形从局部指向整体

5.1.3.4.1.6 组合关系

• 组合 ( Composition ）：表示 contains-a 的关系，是一种强烈的包含关系，比聚合关系更强，部分不能脱离整体存在(强烈的包含关系,例如 : 你跟父母的关系就是一般无法脱离的组合关系 .)
• 在类图使用实心的菱形表示，菱形从局部指向整体

5.1.3.4.1.7 聚合和组合的区别

• 聚合关系是 “ has-a ” 关系，组合关系是 “ contains-a " 关系；
• 聚合关系表示整体与部分的关系比较弱，而组合比较强;
• 聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。

5.1.3.4.2 对象图( Object diagram）----- 不重要

• 描述一组对象及它们之间的关系。描述的是参与交互的各个对象在交互过程中某一时刻的状态，可以被看作是类图在某一时刻的快照.

5.1.3.4.3 包图（ Package diagrams ) ----- 不重要

• 为了简单地表示出复杂的类图，可以把类组合成包packages。一个包是UML上有逻辑关系的元件的集合

5.1.3.4.4 构件图（ Component diagram )

• 表示系统中构件与构件之间，类或接口与构件之间的关系图。
• 其中，构建图之间的关系表现为依赖关系，定义的类或接口与类之间的关系表现为依赖关系或实现关系

5.1.3.4.5 组合结构图（ Composite structure diagram ) ----- 不考

• 描述系统中某一部分(构件或类)的内部结构，包括该部分与系统其它部分的交互点.

5.1.3.4.6 部署图（ Deployment diagram ）----- 考过

• 也称配置图，用来显示系统中软件和硬件的物理架构。它描述了运行时的硬件结点，以及在这些结点上运行的软件组件的静态视图。

5.1.3.4.7 用例图（ Use case diagrams ) ----- 非常重要

• 用例图展现系统功能用例图 , 主要用来描述 “ 用户、需求、系统功能单元 ” 之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。

• 用例图所包含的元素如下：

  • 1. 参与者 ( Actor )
    • 表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示
  • 2. 用例 ( Use Case)
    • 用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示

  • 3.子系统 ( Sub system )

    • 用来展示系统的一部分功能这部分功能联系紧密

5.1.3.4.7.1 用例之间的四种关系

5.1.3.4.7.2 用例关系

关联（ Association ）

• 表示参与者与用例之间的通信，任何一方都可发送或接受消息。

**泛化（ Inheritance ) **

• 通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的.

**包含 ( Include ) **

• 包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。

**扩展（ Extend ) **

• 扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能，

5.1.3.4.8 状态图 ( State machine diagrams )

• 状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模

5.1.3.4.9 活动图（ Activity diagrams )

• 活动图是一个特殊的流程图，集中在一个单独过程动作流程。活动图告诉我们活动之间的依赖关系

5.1.3.4.10 顺序图 ( Sequence diagrams )

• 展现了一组对象或参与者以及它们之间可能发送的消息，顺序图是强调消息的时间次序的交互图.

5.1.3.4.11 通信图（ Communication diagrams )

• UML早期版本称为协作图，是一种交互图，所显示消息与顺序图相似，但是它更侧重于对象间的联系，而顺序图强调消息的先后顺序.

5.1.3.4.12 定时图（ Timing diagrams )

• 用来显示随时间变化，一个或多个元素的值或状态的更改。它强调消息跨越不同对象或参与者的实际时间.

5.1.3.5 交互概览图（ lnteraction overview diagrams )

• 各种图的组合：
  • 活动图
  • 顺序图
  • 通信图的混合

5.1.3.6 UML中的视图(记住标题)

• 进程视图 : 细节性比较强的,例如:工业控制系统涉及.
• 用例视图 : 以用例为主.

5.1.4 面向对象分析

5.1.4.1 面向对象分析OOA

• 面向对象分析OOA将运用面向对象的方法分析问题域，建立基于对象、消息的业务模型，形成对客观世界和业务本身的正确认识

• OOA的主要目标是：

  • 描述用户需要
  • 建立创建软件设计的基础
  • 定义软件完成后可被确认的一组需求

5.1.4.2 面向对象设计OOD

• OOD是OOA的延续，对分析阶段给出的问题域模型，用面向对象方法设计出软件基础架构（ 概要设计 ）和完整的类结构（ 详细设计 ），以实现业务功能。

• OOD的主要任务是对类和对象的设计，包括类的属性方法以及类之间的关系

• OOD的结果是设计模型

OOD强调可维护性和可复用性.

5.1.4.3 OOA到OOD转换(了解)

• 1. 设计用例实现方案
  • 针对分析模型中的用例设计实现方案，实现方案用UML交互图表示
• 2. 设计技术支撑设施
  • 这些设施可为多种业务需求的实现提供公共服务，例如数据的持久存储服务、安全控制服务和远程访问服务等
• 3. 设计用户界面
  • 针对分析模型中的领域概念模型以及引进的新类，完整、精确地确定每个类的属性和操作，并完整地标示类之间的关系

科普

序号	名称	解析
1	OOA	面向对象分析方法
2	OOD	面向对象设计
3	OOP	面向对象的程序设计
4	OOT	软件开发领域面向对象的测试

5.1.4.4 构建用例模型的阶段

5.1.4.5 类之间的关系

5.1.5 软件设计

5.1.5.1 软件设计

• 软件设计是定义一个系统的架构、组件、接口和其他特征的过程，并得到这个过程的结果(架构设计师层次非常高的软件设计)

• 软件设计阶段：

  • 软件架构设计（ 概要设计 ）：描述软件的组织和结构，标识各种不同的组件
  • 软件详细设计：详细的描述各个组件，使之能被构造

• 软件设计方法：

  • 结构化设计SD：是一种面向数据流的方法，它以SRS和SA阶段所产生的DFD和数据字典为基础，是自顶向下、逐步求精和模块化的过程
  • 面向对象设计OOD：面向对象方法已可维护性和可用性为设计基础，更接近现实世界、更自然

5.1.5.2 设计原则：高内聚低耦合

• 内聚性又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。

5.1.5.3 设计原则：高内聚低耦合

• 耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。

5.1.5.4 面向对象软件设计七大原则

• 依赖接口编程 : 针对接口编程
• 接口隔离 : 要把接口按功能分到不同的模块里,而不是写在一起
• 迪米特法则 : 一个类调用另一个类,最好对其一无所知更好.
• 合成复用原则 : 尽量使用整体部分关系.
• 单一职责原则 : 一个类里写一个功能

5.1.5.5 设计模式

• 设计模式（ Design pattern ）代表了最佳的实践，它使人们可以方便地复用成功的软件设计。每一个模式描述了一个不断重复发生的问题，以及该问题的解决方案.(更具体设计的时候,采用)

• 设计模式的基本要素

  • 模式名称
  • 问题描述
  • 目的
  • 解决方案
  • 效果
  • 实例代码
  • 相关设计模式

5.1.5.6 软件设计

• 创建模式 : 一个系统里尽量少的出现对象.
• 结构型模式 : 整个系统里涉及到很多内部的对象,对象怎么结合在一起.
• 行为模式 : 对象和对象之间交互
• 能做到把模式和其分类对应上

5.1.6 软件实现

5.1.6.1 软件配置管理

• 软件配置管理通过标识产品的组成元素、管理和控制变更、验证、记录和报告配置信息，来控制产品的演进和完整性。软件配置管理与软件质量保证活动密切相关，可以帮助达成软件质量保证目标。(最早在软件需求就开始做软件配置了.)

• 软件配置管理活动包括

  • 软件配置管理计划
  • 软件配置标识
  • 软件配置控制
  • 软件配置状态记录
  • 软件配置审计
  • 软件发布管理与交付

• 详细内容参见第19章《配置与变更管理》----- 此处住主要是了解为主,详细记忆在19章

5.1.6.2 软件配置管理

5.1.6.2.1 程序设计语言

• 人和计算机通信需使用程序设计语言。编码就是把软件设计的结果翻译成计算机可“ 理和别 ” 的形式-------用某种程序设计语言书写的程序。
• 程序设计语言的特性和编码途径会对程序的可靠性、可读性、可测试性和可维护性产生深远的影响。

5.1.6.2.2 程序设计风格

• 阅读程序是软件开发和维护过程中的一个重要组成部分，读程序的时间比写程序的时简还要多，应使程序真有食好的风格。应尽量从编码原则的角度提高程序的可读性，改善程序的质量。
• 程序设计风格包括4个方面：源程序文档化、数据说明、语包结构和输入/输出方法。

5.1.6.2.3 程序复杂性度量

• 定量度量程序复杂程度的方法很有价值，把程序的复杂度乘以适当的常数即可估算出软件市故障的数量及软件并发时的工作量
• 定量度量的结构可以用于比较两个不同设计或两种不同算法的优劣。
• 程序的定量的复杂程度可以作为模块规模的精确限度。

5.1.6.2.4 编码效率

• ① 程序效率：指程序的执行速度及程序所需占用的内存空间
• ② 算法效率：源程序的效率与详细设计阶段确定的算法的效率直接相关。算法效率反映为程序的执行速度和存储容量的要求(可以通过上边的定量度量.越是分析型应用,对算法要求越高)
• ③ 存储效率：存储容量对软件设计和编码的制约很大，要选择可生成较短目标代码且存储压缩性能优良的编译程序，有时需要采用汇编程序提高软件的时间与空间效率。提高存储效率的关键是程序的简单化。
• ④ I/O效率：分为两种类型：一种是面向人（ 操作员 ）的输入/输出；另一种是面向设备的输入/输出。如果操作员能够十分方便、简单地输入数据，或者能够十分直观、一目了然地了解输出信息，则可以说面向人的输入/输出是高效的。至于面向设备的输入/输出，主要考虑设备本身的性能特性。

5.1.6.3 软件测试

• 软件测试是为评价和改进产品质量、识别产品缺陷和问题而进行的活动，是在将软件交付给客户之前所必须完成的重要步骤。

• 软件测试的目的

  • 1. 验证软件是否满足软件需求规格说明和软件设计所规定的功能、性能及其软件质量特性的要求
  • 2. 通过测试发现软件错误(最终目的)
  • 3. 为软件质量的评价提供依据

5.1.6.3.1 软件测试模型

• 所谓测试模型（Test Model），是测试和测试对象的基本特征、基本关系的抽象

• 软件测试过程的主要模型(普遍使用前两种)：

  • V 模型
  • W 模型
  • H 模型
  • X 模型
  • 前置测试模型

5.1.6.3.1.1 V 模型

• V 模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系
• V 模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系

• 验收测试: 跟系统测试一样,主要针对的是需求分析定义的需求说明书,验证用户提出的需求是否满足了.

• 整体测试和开发一一对应像一个V一样,V的左边是开发,右边是测试.

• 优点(了解)：

  • 包含了底层测试（ 单元测试 ）和高层测试（ 系统测试 )
  • 清楚的标识了开发和测试的各个阶段
  • 自上而下逐步求精，每个阶段分工明确，便于整体项目的把控

• 缺点(了解)：

  • 自上而下的顺序导致了测试工作在编码之后，就导致错误不能及时的进行修改
  • 需求、设计阶段的不能及时发现
  • 质量控制和测试效率不高

5.1.6.3.1.2 W 模型

• 相对 V 模型，W模型增加了软件各开发阶段中同步进行的验证和确认测试活动。
• W 模型相当两个V模型的叠加，一个是开发的 V，一个是测试的 V，由于在项目中开发和测试的是同步进行，相当于两个 V 是并列、同步进行的，测试在一定程度上是随着开发的进展而不断向前进行。

• 在V模型的基础上演变的,相当于两个V模型的叠加.
• W模型优于V模型就是在每个环节做完马上验证,而V模型是开发完了再测试,出了问题需要推倒重做.

W 模型体现了 “ 尽早地和不断地进行软件测试 ” 的基本原则

• 优点(了解)：

  • 开发伴随着整个开发周期，需求和设计同样要测试
  • 更早的介入测试，可以发现初期的缺陷，修复成本低
  • 分阶段工作，方便项目整体管理

• 缺点(了解)：

  • 开发和测试依然是线性的关系，需求的变更和调整依然不方便
  • 如果没有文档，无法执行w模型
  • 无法支持迭代、自发性

5.1.6.3.2 按开发阶段划分

5.1.6.3.2.1 单元测试

• 又称模块测试，是针对软件设计的最小单元（ 即程序模块 ）进行正确性检验的工作，单元测试必须是可重复的

• 单元测试的原则

  • 应该尽早进行软件单元测试。(最好编码之后马上进行.)
  • 应该保证单元测试的可重复性。
  • 尽可能采用测试自动化的手段来支持单元测试活动。

• 单元测试的主要内容

  • 单元功能测试。
  • 单元接口测试。
  • 单元局部数据结构测试。
  • 单元中重要的执行路径测试。
  • 单元的各类错误处理路径测试。
  • 单元边界条件测试。

由程序员为自己的代码编写单元测试.(就是编写测试用例)

5.1.6.3.2.2 集成测试

• 又称组装测试、联合测试、子系统测试或部件测试，是在单元测试的基础上,将所有模块按照设计要求组装成子系统或系统进行的测试活动

• 关注的是模块间的接口(集成测试关注的是接口)，接口之间的数据传递关系，依据是系统的高层设计（架构设计或概要设计）

• 集成测试的目的

  • 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失。
  • 一个模块的功能是否会对另一个模块的功能产生不利的影响。
  • 各个子功能组合起来，能否达到预期要求的父功能。
  • 全局数据结构是否有问题。
  • 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
  • 在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统

最好由不属于该软件开发组的软件设计人员承担，以提高集成测试的效果.(从集成测试开始,系统测试,验收测试,最好都是由第三方进行.)

• 集成测试的策略(了解)

  • 非增值式策略：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序。该方法简单，允许多个测试人员并行工作，对人力、物力资源利用率较高，缺点是为每个模块准备相应的驱动模块成本较高并且集成后难以对错误定位和纠正

  • 增值式策略，这种集成方式又称渐增式组装。首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。该方法可较早发现并定位模块间的接口错误，但测试周期比较长，可同时投入的人力物力受限

5.1.6.3.2.3 系统测试

• 统测试的目的是在真实系统工作环境下通过与系统的需求定义作比较，检验完整的软件配置项能否和系统正确连接，发现软件与系统设计文档或软件开发合同规定不符合或与之矛盾的地方

• 系统测试的对象不仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下进行测试

• 系统测试更多是站在用户的角度上对系统做功能性的验证，同时还对系统进行一些非功能性的验证，包括压力测试、安全性测试、容错测试、恢复性测试等。(不重要情况下,系统测试和验收测试可以合二为一,正规的是由开发企业做系统测试,用户做验收测试.)

测试依据是产品系统的需求规格说明书、各种规范、标准和协议(协议就是合同)等.

• 系统测试阶段划分

  • 测试计划
  • 测试设计
  • 测试实施
  • 测试执行
  • 测试评估

• 系统测试的意义：

  • 1. 系统测试的环境是软件真实运行环境的最逼真模拟，整个系统的时序匹配等，在这种运行环境下能得到比较全面的暴露
  • 2. 系统测试由系统人员组织，从系统完成任务的角度测试，软件在系统测试下获得了系统任务下直接的“测试实例”，这对检验软件是否满足系统任务要求是非常有意义的

5.1.6.3.2.4 验收测试

• 在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，也称为交付测试、发布测试或确认测试，决定是否接收系统。(客户最终是否接收系统)

• 验收测试是按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，验收测试结果(下边四点考过)：

  • 1. 测试项目通过
  • 2. 测试项目没有通过，并且不存在变通方法，需要作很大的修改
  • 3. 测试项目没有通过，但存在变通方法，在维护后期或下一个版本改进
  • 4. 测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说清楚，应该修改测试计划

测试依据是项目任务书或合同、供需双方约定的验收依据文档.

• 验收测试内容(了解)

  • 易用性测试
  • 兼容性测试
  • 安装测试
  • 文档（如用户手册、掉操作手册等）测试

• 验收测试完成标准如下

  • 完全执行了验收测试计划中的每个测试用例
  • 在验收测试中发现的错误已经得到修改并且通过了测试
  • 完成软件验收测试报告

• 验收测试需要注意以下几点。

  • 1. 必须编写正式的、单独的验收测试计划
  • 2. 验收测试必须在实际的用户运行环境中运行(比较重要)
  • 3. 由用户和测试部门共同执行比较好

5.1.6.3.2.5 概念辨析：α、β、入测试(了解)

• α、β、入 常用来表示软件测试过程中的三个阶段：
  • α 是第一阶段，一般只供内部测试使用；
  • β 是第二个阶段，已经经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用；(用户到部署好的环境来测试,一般到这里就OK了,严格 的在做第三个)
  • 入 是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行。

5.1.6.3.3 静、动态测试

5.1.6.3.3.1 静态测试

• 静态测试是指不运行程序，通过人工对程序和文档进行分析与检查；又称为静态分析技术(没有运行程序,基本就是看文档和代码是否符合规范.)

• 测试对象

  • 需求说明书
  • 设计说明书
  • 程序源代码
  • 用户手册等

• 手段

  • 代码检查
  • 静态结构分析
  • 代码质量度量

• 静态测试可以由人工进行，也可以借助软件工具自动进行

(需要背记)静态测试的重要性 : 静态测试能有效发现 30%～70% 的逻辑设计和编码错误.

5.1.6.3.3.2 动态测试

• 动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。

• 动态方法指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率结果与预期结果的差异，并分析运行效率和健壮性等性能

• 方法组成

  • 编写测试用例
  • 执行程序
  • 分析程序的输出结果

5.1.6.3.3.3 两者区别(静态测试反而在很多情况是必要的)

• 静态测试是用于预防的，动态测试是用于校正
• 多次的静态测试比动态测试要效率高
• 静态测试综合测试程序代码
• 在相当短的时间里，静态测试的覆盖率能达到100%，而动态测试经常是只能达到50%左右
• 动态测试比静态测试更花时间
• 静态测试比动态测试更能发现Bug
• 静态测试的执行可以在程序编码编译前，动态测试只能在编译后才能执行

5.1.6.3.4 黑、白盒测试

5.1.6.3.4.1 黑盒测试(动态测试用到黑盒测试)

• 也称功能测试，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，主要针对软件界面和软件功能进行测试。

• 黑盒测试法试图发现下列错误

  • 功能不正确或遗漏
  • 界面错误
  • 输入和输出错误
  • 数据库访问错误
  • 性能错误
  • 初始化和终止错误等

如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试法发现不了.

• 从理论上讲，黑盒测试只有采用穷举输入测试，但完全测试是不可能的，需要通过制定测试案例指导测试的实施

• 黑盒测设计方法包括(早起考过,2024以后可能不大会考了.知道哪些是属于黑盒的就好了)

  • 等价类划分法
  • 边界值分析法
  • 错误推测法
  • 因果因法
  • 判定表法
  • 正交试验设计法
  • 功能图法场景分析法

5.1.6.3.4.2 白盒测试(白盒测试一般和静态测试相结合)

• 又称结构测试，把程序看成装在一个透明的白盒子里，清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明书的规定正常进行。

• 目的：通过检查软件内部的逻辑结构，对软件中逻辑路径进行覆盖的测试可以覆盖全部代码、分支、路径和条件。

• 白盒测试的优点

  • 可以检查内存的泄露
  • 可以检查异常处理分支语句是否正确
  • 执行了多少逻辑，可以作为衡量测试是否完整的一个指标

白盒测试主要用于单元测试

• 白盒测试方法主要有控制流测试、数据流测试和程序变异测试等。

• 静态白盒测试技术

  • 人工代码检查
  • 静态结构分析
  • 静态质量度量

• 动态白盒测试 ( 结构测试 )(每个输入在代码里的流程,是否考虑了所有的流程,关键字记住覆盖两字,就是白盒测试)

  • 主要是覆盖测试（语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件/判定覆盖和路径覆盖）

5.1.6.3.4.3 两者之间的联系

• 用白盒测试验证单元的基本功能，用黑盒测试的思考方法设计测试用例
• 黑盒测试中使用白盒测试的手段，常称为 “ 灰盒测试 ”
• 白盒测试需要对程序的内部实现十分熟悉，黑盒测试是完全基于对系统需求的了解
• 仅仅使用白盒测试，或者仅仅使用黑盒测试都不能系统地全面测试一个软件

5.1.6.3.4.4 灰盒测试(知道基本概念就好)

• 介于白盒测试与黑盒测试之间的测试。关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试详细、完整，只是通过一些表征的现象、事件、标志来判断丙部的运行状态。

• 优点：

  • 能够进行基于需求的覆盖测试和基于程序路径覆盖的测试
  • 测试结果可以对应用程序内部路径，便于Bug的定位、分析和解决
  • 能够保证设计的黑盒测试用例的完整性，防止遗漏软件的一些不常用的功能或功能组答
  • 能够减少需求或设计不详细或不完整对测试造成的影响

• 缺点：

  • 投入的时间比黑盒测试大概多20%～40%的时间(这里需要有印象)
  • 对测试人员的要求比黑盒测试高；灰盒测试要求测试人员清楚系统内部由哪些模块构成，模块芝间如荷协作
  • 不如白盒测试深入
  • 不适用于简单的系统。如果某个系统简单到只有一个模块，没必要进行灰盒测试

5.1.7 部署交付

5.1.7.1 软件部署与交付

• 软件部署与交付是软件生命周期中的一个重要环节，属于软件开发的后期活动，即通过配置、安装和激活等活动来保障软件制品的后续运行。

• 软件系统部署的管理代价占到整个软件管理开销的大部分。其中软件配置是整个部署过程中的主要错误来源。(强调配置管理的重要性.)

• 部署与交付常见问题：

  • 分支余导致合并困难；
  • 缺陷过多导致阻塞测试；
  • 开发环境、测试环境、部署环境不统一导致的未知错误
  • 代码提交版本混乱无法回溯
  • 等待上线周期过长
  • 项目部署操作复杂经常失败
  • 上线之后出现问题需要紧急回滚
  • 架构设计不合理导致发生错误之后无法准确定位等困境

5.1.7.2 持续交付(强调开发)

• 持续交付是一系列开发实践方法，用来确保让代码能够快速、安全地部署到生产环境中。持续交付是一个完全自动化的过程，应做到一键部署。(传统交付就是一次性交付,比如:瀑布模型,在敏捷模式下,提早交付,提早为客户带来价值,有十个模块,先部署两个,持续交付,持续部署.强调自动化的过程,运维强调自动化的问题,例如:docker实现了这种自动化部署.)

• 持续交付方案：

  • 在需求阶段，抛弃了传统的需求文档的方式，使用便于开发人员理解的用户故事
  • 在开发测试阶段，做到持续集成，让测试人员尽早进入项目开始测试
  • 在运维阶段，打通开发和运维之间的通路，保持开发环境和运维环境的统
  • ......

• 持续交付的优势：

  • 能够有效缩短提交代码到正式部署上线的时间，降低部署风险
  • 能够自动、快速地提供反馈，及时发现和修复缺陷
  • 让软件在整个生命周期内都处于可部署的状态
  • 能够简化部署步骤，使软件版本更加清晰
  • 能够让交付过程成为一种可靠的、可预期的、可视化的过程

• 评价软件交付能力的指标：

  • 1. 仅涉及一行代码的改动需要花费多少时间才能部署上线，这也是核心指标
  • 2. 开发团队是否在以一种可重复、可靠的方式执行软件交付

5.1.7.3 持续部署(强调方便性)

1）持续部署方案

• 容器技术目前是部署中最流行的技术，常用的持续部署方案有 Kubernetes + Docker 和 Matrix 系统两种。容器技术的优点：
  • 上手简单，轻量级架构，体积很小
  • 集合性更好，能更容易对环境和软件进行打包复制和发布
  • 为部署带来巨大改进，简化了复制和部署问题、精准将环境的各种依赖进行完整打包

2）部署原则

• 部署包全部来自统一的存储库
• 所有的环境使用相同的部署方式
• 所有的环境使用相同的部署脚本
• 部署流程编排阶梯式晋级，即在部署过程中需要设置多个检查点，便于进行回滚操作
• 整体部署由运维人员执行
• 仅通过流水线改变生产环境，防止配置漂移
• 不可变服务器
• 部署方式采用蓝绿部署或金丝雀部署

3）部署层次

• 部署的目的并不是部一个可工作的软件，而是部署一套可正常运行的环境。完整的镜像部薯包括个环节：Build - Ship - Run。

  • Build ：跟传统的编译类似，将软件编译形成RPM包或者Jar包(jar包放入到部署好的环境里)
  • Ship ：则是将所需的第三方依赖和第三方插件安装到环境(jar包和依赖包放入部署好的环境里)
  • Run ：就是在不同的地方启动整套环境(docker镜像封装好,到处部署镜像)

• 制作完成部署包之后，每次需要变更软件或者第三方依赖以及插件升级的时候，不需要重新打包，直接更新部署包即可.

4）不可变服务器

• 不可变服务器是一种部署模式，指除了更新和安装补丁程序以外，不对服务器进行任何更改。在早期阶段,软件的部署是在物理机上进行的，每一台服务器的网络、存储，软件环境都是不同的，物理机的不稳定是让环境重构变得异常困难。后来逐渐发展为虚拟机部署，在虚拟机上借助流程化的部署能较好地构建软件环境，但是第三方依赖库的重构不稳定为整体部署带来了困难。现阶段使用容器部署不但继承和优化了虚拟机部署的优点，而且很好地解决了第三方依赖库的重构问题，容器部署就像一个集装箱，直接把所有需要的内容全部打包并进行复制和部署。(使用容器可以不修改服务器本身)

5）蓝绿部署和金丝雀部署

• 在部署原则中提到两大部署方式为蓝绿部署和金丝雀部署。

  • 蓝绿部署是指在部署的时候准备新旧两个部署版本，通过域名解析切换的方式将用户使用环境切换到新版本中，当出现问题的时候，可以快速地将用户环境切回旧版本，并对新版本进行修复和调整。(有新旧两个版本,新版本可以运行,旧版本也可以运行,新版本尝试部署,如果新版本部署失败,可以很快的切换回旧版本)

  • 金丝雀部署是指当有新版本发布的时候，先让少量用户使用新版本，并且观察新版本是否存在问题。如果出现问题，就及时处理并重新发布；如果一切正常，就稳步地将新版本适配给所有的用户。(先让一个部门的访问新版本,没问题,再让其他部门访问,都没问题,再切换到新版本)

5.1.7.4 部署与交付的新趋势

• 工作职责和人员分工的转变：

  • 软件开发人员运用自动化开发工具进行持续集成，进一步将交付和部署扩展，而原来的手工运维工作也逐渐被分派到了开发人员的手里。运维人员的工作也从重复枯燥的手工作业转化为开发自动化的部署脚本，并逐步并入开发人员的行列之中。(deovs,开发运维)

• 大数据和云计算基础设施的普及进一步给部署带来新的飞跃

  • 云计算的出现使得计算机本身也可以进行自动化创建和回收，这种环境管理的范畴将得到进一步扩充。部署和运维工作也会脱离具体的机器和机房，可以在远端进行，部署能力和灵活性出现了质的飞跃。(云端部署可以脱离机房的限制.)

• 研发运维的融合

  • 减轻运维的压力，把运维和研发融合在一起。(运维角度讲可以减少压力)

5.1.8 过程管理(软件工程里工程三个方向:方法,工具,过程)

5.1.8.1 基本概念

• 软件过程能力：是组织基于软件过程、技术、资源和人员能力达成业务目标的综合能力。包括治理能力、开发与交付能力、管理与支持能力、组织管理能力等方面。(软件过程:开发软件系统的过程,要遵守一些规则.包括软件管理的能力.)

• 软件过程能力成熟度：是指组织在提升软件产品开发能力或软件服务能力过程中，各个发展阶段的软件能力成熟度。(怎么评价组织在软件开发过程上能力强?强到什么程度?需要用一个程度模型去进行评价.)

• 常见的软件过程管理方法和实践

  • 能力成熟度模型集成（ Capability Maturity Model Integration，CMMI )(国际标准)
  • 中国电子工业标准化技术协会发布的 T/CESA 1159《软件过程能力成熟度模型》( Software Process Capability Maturity Model ）团体标准，简称CSMM。(国有标准)

5.1.8.2 成熟度模型 ( CSMM )

• 软件过程能力成熟度模型旨在通过提升组织的软件开发能力帮助顾客提升软件的业务价值，层次结构如图所示

• 背记:能力域

5.1.8.3 成熟度等级

• CSMM 定义了5个等级，总体特征如表所示

• 记住解释
• 初次级,基本不主动管理,能够勉强交付系统就行.
• 项目规范级: 有一个项目管理框架,定义好的规范,每一个项目都按流程规范走.
• 组织改进级: 就是持续改进
• 量化提升级: 有严格的数据支撑.
• 创新引领级: 在行业中处于领先地位.

5.1.8.4 能力域与成熟度等级的对应关系

• 成熟度等级,企业参加评级,应该重点关注哪些能力子域.

5.2 数据工程

什么是数据工程？(就是数据库做的事情)

• 数据工程是信息系统的基础工程。围绕数据的生命周期，规范数据从产生到应用的全过程

• 数据工程的目标：为信息系统的运行提供可靠的数据保障和服务，为信息系统之间的数据共享提供安全、高效的支撑环境，为信息系统实现互连、互通，互操作提供有力的数据支撑。

• 数据工程的主要研究内容

  • 数据建模
  • 数据标准化
  • 数据运维
  • 数据开发利用
  • 数据安全

5.2.1 数据建模

5.2.1.1 什么是数据建模？

• 数据建模：

  • 是对现实世界中具体的人、物、活动和概念进行抽象、表示和处理，变成计算机可处理的数据，也就是把现实世界中的数据从现实世界抽象到信息世界和计算机世界。

• 数据建模内容：

  • 主要研究如何运用关系数据库设计理论，利用数据建模工具，建立既能正确反映客观世界，又便于计算机处理的数据模型。

• 数据模型划分为三类·

  • 概念模型
  • 逻辑模型
  • 物理模型

5.2.1.2 数据模型

5.2.1.2.1 概念模型

• 概念模型也称信息模型，按用户的观点来对数据和信息建模，不依赖于具体的计算机系统，也不对应某个具体的DBMS，它是概念级别的模型(知识概念跟计算机没什么关系)

• 概念模型的基本元素如表所示：

• 对概念模型要求

  • 概念模型是对现实世界的抽象和概括，它应该真实、充分地反映现实世界中事物和事物之间的联系，有丰富的语义表达能力，能表达用户的各种需求

  • 概念模型应简洁、明晰、独立于机器、容易理解，方便数据库设计人员与用户交换意见，使用户能够积极参与数据库的设计工作

  • 概念模型应易于变动。当应用环境和应用要求改变时，容易修改和补充概念模型

  • 概念模型应容易向关系、层次或网状等各种数据模型转换，易于从概念模型导出与DBMS相关的逻辑模型

5.2.1.2.2 逻辑模型

• 逻辑模型是在概念模型的基础上确定模型的数据结构，主要的数据结构有层次模型、网状模型、关系模型 、面向对象模型和对象关系模型.

• 关系模型的基本元素包括关系、关系的属性、视图等。关系模型是在概念模型的基础上构建的，关系模型与概念模型的对应关系如表：

关系数据模型的操作包括查询、插入、删除和更新数据，这些操作必须满足关系的完整性约束条件。关系的完整性约束包括：实体完整性、参照完整性(考试考过)和用户定义的完整性。前两者必须满足。

5.2.1.2.3 物理模型

• 物理数据模型是在逻辑数据模型的基础上，考虑各种具体的技术实现因素，进行数据库体系结构设计，真正实现数据在数据库中的存放。

• 物理数据模型的内容包括：

  • 确定所有的表和列
  • 定义外键用于确定表之间的关系
  • 基于性能的需求可能进行反规范化处理

• 物理模型的基本元素包括表、字段、视图、索引l、存储过程、触发器等。其中表、字段和视图等元素与逻辑模型中基本元素有一定的对应关系。

5.2.1.3 数据建模过程

1. 数据需求分析

• 分析用户对数据的需要和要求，采用数据流图作为工具，描述系统中数据的流动和变化，强调数据流和处理过程。

2. 概念模型设计

• 将需求分析得到结果抽象为概念模型，其任务是确定实体和数据及其关联。

3. 逻辑模型设计

• 逻辑模型设计主要指关系模型结构的设计，关系模型由一组关系模式组成一个关系模式就是一张二维表，逻辑模型设计的任务就是将概念模型中实体、属性和关联转换为关系模型结构中的关系模式。

4. 物理模型设计

• 针对具体的DBMS进行物理模型设计，使数据模型走向数据存储应用环节考虑的主要问题包括命名、确定字段类型和编写必要的存储过程与触发器等。

5.2.2 数据标准化

5.2.2.1 什么是数据标准化？

• 数据标准化主要为复杂的信息表达、分类和定位建立相应的原则和规范，使其简单化、结构化和标准化，从而实现信息的可理解、可比较和可共享，为信息在异构系统之间实现语义互操作提供基础支撑。

• 数据标准化的主要内容

  • 元数据标准化
  • 数据元标准化
  • 数据模式标准化
  • 数据分类与编码标准化
  • 数据标准化管理

数据标准化是实现数据共享的基础.

5.2.2.2 元数据标准化

元数据是关于数据的数据 ( Data About Data )

• 在信息界，元数据被定义为提供关于信息资源或数据的一种结构化数据是对信息资源的结构化描述。其实质是用于描述信息资源或数据的内容覆盖范围、质量、管理方式、数据的所有者、数据的提供方式等有关的信息。(就是描述表的信息,比如字段名,字段长度,字段类型这些.)

元数据描述的对象

• 单一的全文、目录、图像、数值型数据以及多媒体 ( 声音、动态图像 )
• 多个单一资源组成的资源集合
• 资源的生产、加工、使用、管理、技术处理、保存等过程及其过程中产生的参数的描述

元数据体系与元数据类型

• 根据信息对象从产生到服务的生命周期、元数据描述和管理内容的不同以及元数据作用的不同，元数据可以分为多种类型

5.2.2.3 数据元标准化

• 开放系统互连环境（ Open Systems Interconnection Environment，OSIE ）四个基本要素（硬件、软件、通信和数据）中的三个要素（硬件、软件和通信），己经或正在制定相应的标准。

• 国际标准化组织ISO提出了数据元标准的概念，要求按共同约定的规则进行统一组织、分类和标识数据，规范统一数据的含义、表示方法和取值范围等保证数据从产生的源头就具备一致性。

什么是数据元

• 数据元是数据库、文件和数据交换的基本数据单元(数据元也叫数据元素)。数据元通过一组属性描述其定义、标识、表示和允许值的数据单元，是不可再分的最小数据单元

数据元由三部分组成：

• ① 对象：是可以对其界限和含义进行明确的标识，且特性和行为遵循相同规则的观念、抽象概念或现实世界中事物的集合。对象类在面向对象的模型中与类相对应，在实体-关系模型中与实体对应，如学员、教员、军事院校等。

• ② 特性：一个对象类的所有成员所共有的特征。它用来区别和描述对象，构成对象类的内涵。对应于面向对象模型或实体-关系模型中的属性，如身高、体重、血压、脉搏、血型等。

• ③ 表示：可包括值域、数据类型、表示类类（可选的）和计量单位四部分，其中任何一部分发生变化都成为不同的表示。

数据元提取方法

• 1、自上而下（ Top-Down ）提取法

  • 适用于新建系统。在流程和功能分析的基础上，通过建模分析，确立关心的 “ 对象 ” 。在概念数据模型和逻辑数据模型的基础上，分析提取数据元及其属性。(需求分析,建模或者OOA,从用户信息表分析出出生日期,年龄等数据)

• 2、自下而上（ Down-Top ）提取法

  • 也称逆向工程，适用于已建系统。依据数据元标准化方法，对信息系统及相关资源的数据，在分析、梳理的基础上，归纳整理出数据元；根据数据元的实际应用，阐明并写出相关数据元在采集、存储和交换过程中各个属性以及属性的约束要求；描述和定义各个属性所需要的属性描述符及其约束要求；根据给定的命名表示规范形成数据元。(直接从已有的信息表直接抽取,底层有字段,哪些适合数据元)

数据元标准的制定过程

• 如何制定数据元标准,步骤从上到下看一下

5.2.2.4 数据模式标准化

数据模式(就是数据模型)

• 是数据的概念、组成、结构和相互关系的总称，反映人类对客观世界的主观认知。人们认知不同，造成了在相同领域有不同的数据模式存在。为了保证信息共享，需要一个统一的数据模式作为数据共享与交换的基础。

制定数据模式的任务

• 1. 对数据的内容、组成、结构以及各部分的相互关系进行统一规范
• 2. 按照数据库理论对数据进行了规范化处理，有利于减少数据余

数据模式的描述方式(数据建模的方式)

• 图描述方法：常用的有IDEF1X方法和UML图，主要用来描述数据集中的实体和实体之间的相互关系

• 数据字典形式：用来描述模型中的数据集、单个实体、属性的摘要信息

5.2.2.5 数据分类与编码标准化

数据分类

• 根据内容的属性或特征，将数据按一定的原则和方法进行区分和归类，并建立起一定的分类体系和排列顺序。(企业所有系统使用统一的分类标准.)
  • 分类对象分类对象由若干个被分类的实体组成
  • 分类依据取决于分类对象的属性或特征
  • 分类应符合交叉性、双重或多重性的原则

数据编码：

• 将事物或概念（编码对象）赋予具有一定规律和易于计算机、人识别处理的符号，形成代码元素集合。(企业任何出现编码的地方都统一了,比如:省会编码.)
  • 代码元素就是赋予编码对象的符号，即编码对象的代码值。所有类型的数据都能够进行编码。

数据分类与编码标准化的作用

• 是简化信息交换、实现信息处理和信息资源共享的重要前提
• 是建立各种信息管理系统的重要技术基础和信息保障依据

5.2.2.6 数据标准化管理

• 数据标准化的过程

( 1 ）确定数据需求

• 产生数据需求及相关的元数据、域值等文件。在确定数据需求时应考虑现行的法规、政策，以及现行的数据标准。

( 2 ）制定数据标准(企业有直接用,企业没有要制定,或者参考行业标准)

• 处理 “ 确定数据需求 ” 阶段提出的数据需求。如果现有的数据标准不能满足该数据需求，可以建议制定新的数据标准，也可建议修改或者封存已有数据标准。推荐的、新的或修改的数据标准记录于数据字典中。这个阶段将产星供审查和批灌的成套建议。

( 3 ）批准数据标准

• 数据管理机构对提交的数据标准建议、现行数据标准的修改或封存建议进行审查。一经批准，该数据标准将扩充或修改数据模型。

( 4 ）实施数据标准

• 涉及在各信息系统中实施和改进已批准的数据标准。

5.2.3 数据运维

5.2.3.1 数据存储

• 数据存储就：根据不同的应用环境，通过采取合理、安全、有效的方式将数据保存到物理介质上，并能保证对数据实施有效的访问。

• 数据存储两方面：

  • ① 数据临时或长期驻留的物理媒介
  • ② 保证数据完整安全存放和访问而采取的方式或行为

• 数据存储介质：是数据存储的载体，是数据存储的基础。存储介质的类型主要有磁带、光盘和磁盘三种。

• 存储管理的主要内容.(管理标题知道)

5.2.3.2 数据备份

• 数据备份是为了防止电于用户操作失误、系统故障等意外原因导致的数据丢失，而将整个应用系统的数据或一部分关键数据复制到其他荐储介质上的过程。

• 数据备份目的 : 保证当应用系统的数据不可用时,可以利用备份的数据进行恢复,尽量减少损失.

• 数据备份结构(了解)

  • DAS 备份结构
  • 基于 LAN 的备份结构
  • LAN-FREE 备份结构
  • SERVER - FREE 备份结构

• 备份策略：完全备份(系统进行全量备份,每天晚上把整个系统全部备份了)、差异备份(运行上个月最大备份,这个月十五天的到今天截止跟最大的全量备份比,做了哪些增删改,把每天的增删改跟全量比都记下来,数据丢失把全量备份+15天差异备份一恢复,消耗大,比增量快)和增量备份(把上个月最大备份和这个月15天每天的备份都运行一遍,就是全部备份了)。

• 硬件基础：备份服务器、RAID和磁带机

• 备份软件：操作系统自带的软件、专业备份软件

5.2.3.3 数据容灾

• 一切引起系统非正常停机的事件都可以称为灾难，包括不可预料、不可抗拒的自然灾害，系统软硬件故障、人为误操作和恶意攻击等。

• 容灾类型

  • 应用容灾用于克服灾难对系统的影响，保证应用服务的完整、可靠和安全等一系列要求，使得用户在任何情况下都能得到正常的服务；
  • 数据容灾则关注于保证用户数据的高可用性，在灾难发生时能够保证应用系统中的数据尽量少丢失或不丢失，使得应用系统能不间断地运行或尽快地恢复正常运行。

• 容灾系统主要指标：

  • RPO ( Recovery Point Object ) ：当灾难发生时允许丢失的数据
  • RTO ( Recovery Time Object ) ：系统恢复的时间

数据容灾是应用容灾的子集，也是容灾的基础而数据备份是数据容灾的基础.(数据备份是数据容灾的基础)

5.2.3.4 数据质量评价与控制

1) 数据质量描述

• 数据质量可以通过数据质量元素来描述，类数据质量元素分为数据质量定量元素和数据质量非定量元素。(评价数据好不好,可以用定量方法,也可以用非定量的方法)

2) 数据质量评价过程

3）数据质量评价方法

• 直接评价法：通过将数据与内部或外部的参照信息，如理论值等进行对比确定数据质量
• 间接评价法：利用数据相关信息，对数据源、采集方法等的描述推断或评估数据质量

4）数据质量控制

• 前期控制：包括数据录入前的质量控制、数据录入过程中的实时质量控制

• 后期控制：数据录入完成后的后处理质量控制与评价

• 依据建库流程可分为(了解)：

  • 前期控制：是在提交成果（即数据入库）之前对所获得的原始数据与完成的工作进行检查，进一步发现和改正错误。
  • 过程控制：实施减少和消除误差和错误的实用技术和步骤，主要应用在建库过程中，用来对获得的数据在录入过程中进行属性的数据质量控制。
  • 系统检测：在数据入库后进行系统检测，设计检测模板，利用检测程序进行系统自检。
  • 精度评价：对入库属性数据用各种精度评价方法进行精度分析，为用户提供可靠的属性数据。

5）数据清理

• 也称数据清洗。是将数据库精简以除去重复记录，并使剩余部分转换成符合标准的过程。数据清理的三个步骤(下边三个要背记住)：
  • 数据分析：从数据中发现控制数据的一般规则，比如字段域、业务规则等
  • 数据检测：根据预定义的清理规则及相关数据清理算法，检测数据是否正确
  • 数据修正：是指手工或自动地修正检测到的错误数据或重复的记录

5.2.4 数据开发利用

5.2.4.1 数据集成

• 数据集成是将驻留在不同数据源中的数据进行整合，向用户提供统一的数据视图（一般称为全局模式），使得用户能以透明的方式访问数据。
• 数据集成的目标是充分利用已有数据，在尽量保持其自治性的前提下，维护数据源整体上的一致性，提高数据共享利用效率。
• 典型的数据集成系统模型 , 如图所示 :

5.2.4.2 数据挖掘

• 数据挖掘是指从大量数据中提取或“挖掘”知识，即从大量的、不完全的有噪声的、模糊的、随机的实际数据中，提取隐含在其中的、人们不知道的、却是潜在有用的知识。
• 数据挖掘的目标是发现隐藏于数据之后的规律或数据间的关系，从而服务于决策(例如:通过大数据发现,啤酒和尿布会被同时购买,以前人们不知道这件事,现在通过大数据挖掘发现了,这就是隐藏在数据之后的规律.)

数据挖掘与传统数据分析不同

• ① 两者分析对象的数据量有差异，数据挖掘所需的数据量比传统数据分析所需的数据量大，数据量越大，数据挖掘的效果越好;

• ② 两者运用的分析方法有差异，传统数据分析主要运用统计学的方法、手段对数据进行分析，而数据挖掘综合运用数据统计、人工智能、可视化等技术对数据进行分析;(涉及神经网络,还会涉及到生物医学)

• ③ 两者分析侧重有差异，传统数据分析通常是回顾型和验证型的，通常分析已经发生了什么，而数据挖掘通常是预测型和发现型的，预测未来的情况，解释发生的原因;

• ④ 两者成熟度不同，传统数据分析由于研究较早，其分析方法相当成熟，而数据挖掘除基于统计学等方法外，部分方法仍处于发展阶段。

5.2.4.3 数据服务

• 数据服务包括如下内容：

  • （1）数据目录服务：用来快捷地发现和定位所需数据资源的一种检索服务是实现数据共享的重要基础功能服务之一

  • （2）数据查询与浏览及下载服务：是网上数据共享服务的重要方式，用户使用数据的方式有查询数据和下载数据两种。

  • （3）数据分发服务：数据的生产者通过各种方式将数据传送到用户的过程通过分发，能够形成数据从采集、存储、加工、传播向使用流动，实现数据的价值。分发服务的核心内容包括数据发布、数据发现、数据评价和数据获取。

5.2.4.4 数据可视化

• 数据可视化（Data Visualization）运用计算机图形学和图像处理技术，将数据转换成为图形或图像在屏幕上显示出来，并能进行交互处理，它涉及多个领域，是一门综合性的学科。

• 计算机视觉 : 就是通过摄像头对事务进行识别,就像人眼看到一样.
• 计算机图形学 : 与计算机视觉相反,是把计算机内的模型,渲染成人类可识别的物品.

常见数据可视化表现方式

• 一维数据可视化 : 指的是文本表格,人类可以直接理解的.
• 二维数据可视化 : 手机或者网页打开的地图
• 三维数据可视化 : 比二维更加高级的版本
• 多维数据可视化 : 把多维降到二维或者三维
• 时态数据可视化 : 有一个维度必须是时间轴
• 层次数据可视化 : 高项中的WBS,企业的组织分解结构,数据结构的树
• 网络数据可视化 : 数据之间不是严格的层次结构,可以互相交叉,数据之间是网状关系.图数据库.

5.2.4.5 信息检索

信息检索（ Information Retrieval ）定义

• 广义的信息检索：将信息按一定的方式组织和存储起来，然后根据用户需求查找出特定信息的技术

• 狭义的信息检索：用户查找特定信息这部分，即按照用户的检索需求，利用已有的检索工具或数据库，从中找出特定信息的过程。

信息检索的主要方法

• （1）全文检索。以文本数据为主要处理对象，根据数据资料的内容而不是外在特征来实现的信息检索手段。(需要配合专有的图文检索工具.)
• （2）字段检索。把检索对象按一定标准在不同字段中进行著录，并把不同字段作为检索依据。(类似根据关键字检索)
• （3）基于内容的多媒体检索。按检索内容可分为图像检索、视频检索和声音检索等。(对图片声音进行检索)
• （4）数据挖掘。从大量的、不完全的、模糊的、随机的数据中，提取隐含在其中且人们事先不知道的潜在、有用的信息和知识的过程。(数据分析最高的层级,也是属于信息检索的)

信息检索的常用技术(不完全独立,混合使用)

• （1）布尔逻辑检索技术。严格意义上的布尔检索法是指利用布尔逻辑运算符连接各个检索词，然后由计算机进行相应的逻辑运算，以找出所需信息的方法。(好几个条件进行与或非组合.)

• （2）截词检索技术。截词检索技术是指用截断的词的一个局部进行检索，并认为凡是满足这个词局部的所有字符的信息，都为命中的信息。截词符用 “ ？” 或 ” * ” 表示（ 不同系统、不同数据库，其代表的含义有所不同 ）。(关键词里命中了,都认为是截词检索.)

• （3）临近检索技术。临近检索又称位置检索，主要是通过检索式中的专门符号来规定检索词在结果中的相对位置。在某些情况下，若不限制检索词之间的位置关系则会造成误检，影响查准率。(用于精确检索.)

• （4）限定字段检索技术。限定字段检索即指定检索词在记录中出现的字段。检索时，计算机只对限定字段进行匹配运算，以提高检索效率和查准率。(按字段检索,可以配合上边三个进行检索.)

• （5）限制检索技术。限制检索是通过限制检索范围，达到优化检索的方法。限制检索的方式有很多种，例如进行字段检索，使用限制符，采用限制检索命令等。(可以结合上述几种检索.)

5.2.5 数据库安全

5.2.5.1 数据库安全威胁

• 数据库安全分类及说明.

• 非授权的信息泄露 : 没授权的用户可以看到信息了.
• 非授权的数据修改 : 没有修改权限,结果把数据修改了.
• 拒绝服务 : 网络安全里的常规攻击手段,对服务的接口进行海量的访问,导致正常的访问,无法访问.
• 人为错误 : 人无意间忽略看安全策略, 导致威胁了.
• 授权用户 : 系统用户造成的威胁
• 恶意代理 : 外部威胁就是病毒或者黑客.

5.2.5.2 数据库安全对策

• 防止非法的数据访问 : 设密码或者限制IP访问.
• 防止推导 : 通过A数据库推导出B数据库信息,或者更细节的信息.
• 保证数据库的完整性 : 保证的是数据库的数据的完整性
• 保证数据的操作完整性 : 数据库的ACID,还有事务的回滚.
• 审计和日志 : 定期审核日志
• 标识和认证 : 登录机制可以保证
• 机密数据管理 : 有的用户可以访问全量数据,有的用户不能访问用户的手机号等信息(笔者:是不是可以认为是数据的脱敏处理)
• 多级保护 : 数据集合可以分为多个安全级别,不同安全级别对应不同用户的用户权限.不同用户可以访问不同数据.
• 限界 : 可以把数据分成不同的通道,不同用户可以访问不同通道位置的数据.

5.2.5.3 数据库安全机制

• 数据库安全机制是用于实现数据库的各种安全策略的功能集合，这些安全机制来实现安全模型，进而实现保护数据库系统安全的目标。

• 数据库安全机制包括

  • 用户的身份认证
  • 存取控制
  • 数据库加密
  • 数据审计
  • 推理控制 : 不要让用户通过已知数据推导出未知相关的数据.

5.3 系统集成

5.3.1 集成基础

5.3.1.1 什么是系统集成？

• 系统集成指计算机系统的集成，包括计算机硬件平台、网络系统、系统软件、工具软件、应用软件的集成，围绕这些系统的相应咨询、服务和技术支持。

• 系统集成以计算机有关技术储备为基础，以可靠的产品为工具，用以实现某一特定的计算机系统功能组合的工程行为。

• (重点关注)网络信息系统的系统集成 ：运用先进的计算机与通信技术，将支持各个信息孤岛的小运行环境集成统一在一个大运行环境之中。

• 系统集成的内容：

  • 技术环境的集成
  • 数据环境的集成
  • 应用程序的集成

5.3.1.2 系统集成基本原则

（ 1 ）开放性

• 系统硬软件平台、通信接口、软件开发工具、网络结构的选择要遵循工业开放标准。只有开放的系统才能满足可互操作性、可移植性以及可伸缩性的要求，不断地为系统的扩展、升级创造条件。(使用通用的,开放的平台)

（ 2 ）结构化

• 把一个复杂系统分解成相对独立和简单的子系统，每一个子系统又分解成更简单的模块，这样自顶向下逐层模块化分解，直到底层每一个模块都是可具体说明和可执行的为止。

（ 3 ）先进性

• 先进性有两层意义：目前先进性和未来先进性。系统的先进性建立在技术先进性之上。系统的先进性还表现在系统设计的先进性。

（ 4 ）主流化

• 系统构成的每一个产品应属于该产品发展的主流，有可靠的技术支持，有成熟的使用环境，并具有良好的升级发展势头。

5.3.2 网络集成

5.3.2.1 网络集成分类

• 技术角度：网络集成不仅涉及不同厂家的网络设备和管理软件，也会涉及异构和异质网络系统的互联问题。

• 管理角度：每个组织的管理方式和管理思想干差万别，实现向网络化管理的转变会面临许多人为的因素。计算机网络集成的体系框架 , 如图所示 :

5.3.2.2 网络集成内容解析

（ 1 ）传输子系统

• 传输是网络的核心，是网络信息的 “ 公路 ” 和 " 血管 ” 。无线传输介质：无线电波、微波、红外线等；有线传输介质：双绞线、同轴电缆、光纤等。

（ 2 ）交换子系统

• 网络交换分为局域网交换技术、城域网交换技术和广域网交换技术。

（ 3 ）安全子系统

• 网络安全关注内容：使用防火墙技术 , 防止外部的侵犯；使用数据加密技术 , 防止任何人从通信信道窃取信息；访问控制，主要是通过设置口令、密码和访问权限保护网络资源。

（ 4 ）网管子系统

• 配置好网络以后，必须对其进行有效的管理，确保网络能连续不断地满足组织的需要。网管关键的任务是保证网络的良好运行，我出瓶颈并解决它。

（ 5 ）服务器子系统

• 服务器是网络中的关键设备。选择网络服务器时要考虑的因素：
  • ① CPU的速度和数量；
  • ② 内存容量和性能；
  • ③ 总线结构和类型；
  • ④ 磁盘容量和性能；
  • ⑤ 容错性能；
  • ⑥ 网络接口性能；
  • ⑦ 服务器软件等。

（ 6 ）网络操作系统

• 主要任务是调度和管理网络资源，并为网络用户提供统一、透明使用网络资源的手段。网络资源包括网络服务器、工作站、打印机、网桥、 路由器、交换机、网关、共享软件和应用软件等。

（ 7 ）服务子系统

• 网络服务是网络应用最核心的问题。主要包括互联网服务、多媒体信息检索、信息点播、信息广播、远程计算和事务处理以及其他信息服务等。

5.3.3 数据集成

5.3.3.1 什么是数据集成？

• 数据集成是运用一定的技术手段将系统中的数据按一定的规则组织成为一个整体，使得用户能有效地对数据进行操作
• 数据集成的主要对象：系统中各种异构数据库中的数据(异构的数据库指的是异构的数据源)
• 数据仓库技术是数据集成的关键(需要背记)

数据集成是数据共享和辅助决策的基础.

5.3.3.2 数据集成的层次

• 数据集成可以分为基本数据集成、多级视图集成、模式集成和多粒度数据集成四个层次。

（ 1 ）基本数据集成。

• 通用标识符问题是基本数据集成的最难问题之一，处理办法包括：

  • 隔离：保证实体的每次出现都指派一个唯一标识符。(不同系统里的张三,要认定是不同的人)
  • 调和：确认哪些实体是相同的，并且将该实体的各次出现合并起来。(不同子系统里张三的身份证号码是唯一的认定他是同一个人)

• 当目标元素有多个来源时，指定某一系统在冲突时占主导地位。数据丢失问题是最常见的问题之一，通常的解决办法是为丢失的数据产生一个非常接近实际的估计值来进行处理。

（ 2 ）多级视图集成

• 多级视图机制有助于对数据源之间的关系进行集成(最底层数据层提升一个中间数据层,用户共有信息做一个表,在中间层之上再做一个视图层,内存视图就是在中间的某几处再抽象一次,就是多级视图集成.)：

  • 底层数据表示方式为局部模型的局部格式，如关系和文件
  • 中间数据表示为公共模式格式，如扩展关系模型或对象模型
  • 高级数据表示为综合模型格式。

• 视图的集成化过程为两级映射：

  • ① 数据从局部数据库中，经过数据翻译、转换并集成为符合公共模型格式的中间视图;
  • ② 进行语义冲突消除、数据集成和数据导出处理，将中间视图集成为综合视图。

（ 3 ）模式集成。

• 属于数据库设计问题(就是模型集成,把不同数据源里的数据集成统一了.)

  • 实际应用中，数据源的模式集成和数据库设计仍有相当的差距，如命名、单位、结构和抽象层次等冲突问题无法照搬模式设计的经验
  • 模式集成的基本框架如属性等价、关联等价和类等价等最终归于属性等价。

（ 4 ）多粒度数据集成

• 是异构数据集成中最难处理的问题，理想的多粒度数据集成模式是自动逐步抽象。

  • 数据综合（ 或数据抽象 ）：由高精度数据经过抽象形成精度较低但是粒度较大的数据，实际上是特征提取和归并的过程。(常用)
  • 数据细化：通过由一定精度的数据获取精度较高的数据，实现该过程的主要途径有：时空转换、相关分析或者由综合中数据变动的记录进行恢复。

5.3.3.3 异构数据集成(有难度)

1) 异构数据集成的方法

• 过程式方法：根据一组信息需求，采用一种点对点（ Ad - hoc ）的设计方法来集成数据。关键是设计一套合适的软件模块来存取数据源。(一对一的,单独为系统设计方法,把这个系统的数据进行集成.)

• 声明式方法：通过一套合适的语言来对多个数据源的数据进行建模，构建—个统一的数据表示，基于这一数据表示来对整体系统数据进行查询。声明式方法要重点考虑两个关键问题：相关领域的概念化建模和基于这一概念化表示的推理可行性。(有一堆的异构数据库,建立统一的映射规则(声明式),统一对这部分异构的数据进行处理.)

• 利用中间件集成异构数据库：不需要改变原始数据的存储和管理方式。各数据库仍完成各自的任务，中间件为异构数据源提供一个高层次的检索服务。(做数据声明,可以使用第三方设计好的中间件做集成)

2 ) 开放数据库互联标准

• 开放式数据库互联（ Open Database Connectivity，ODBC ）是一种用来在数据库系统之间存取数据的标准应用程序接口，基于C语言。(访问数据库通过协议访问(ODBC),通过协议访问异构数据库,通过统一的协议接口访问数据库,无需关心到底访问的是什么数据库.)

• JDBC ( Java Database Connectivity，Java数据库连接)，Java体系中的数据库访问中间件，是由Java语言编写的类和接口组成。

• 另一种提取数据的方法是针对不同的数据源编写专用的嵌入式C接口程序，这样可提高数据的提取速度。

3) 基于XML的数据交换标准

• XML即是交换标准,也是一种文件格式.
• 优势：
  • 能够描述各种数据格式，无论其是结构化的还是半结构化的；
  • 易于发布和进行数据交换，集成后的数据可以方便地以多种格式发布并便于在应用之间交换数据；

4) 基于JSON的数据交换格式

• 在开发客户端与服务端的应用当时，随着 AJAX 技术的兴起, JSON ( JavaScript Object Notation ) 作为一种轻量级的数据交换格式，以其易于阅读和编写的优点，被广泛应用。

5.3.4 软件集成

• 怎么把不同的组件集成到系统里.

5.3.4.1 CORBA

• CORBA（ Common Object Request Broker Architecture, 公共对象请求代理体系结构 ）是由 OMG（ 对象管理组织 Object Management Group ）组织制订的一种标准的面向对象应用程序体系规范(知道可以进行软件集成即可,很少使用)

• 以 CORBA 为基础，利用 JINI 技术，可以结合各类电子产品成为网络上的服务资源，使应用集成走向更广阔的应用领域，同时 Object Web 把 CORBA 的技术带入了 Internet 世界。

• ORBA 自动匹配许多公共网络任务，例如对象登记、定位、激活、多路请求、组帧和错误控制、参数编排和反编排、操作分配等。

5.3.4.2 COM（ 组件对象模型 ）

• COM 对象是一种二进制代码对象，其代码形式是 DLL 或 EXE 执行代码。COM 直接注册在Windows 的系统库中，可以作为该应用程序中的其他部分，还可以单独为其他应用程序系统提供服务。(微软集成的一款软件集成工具.)

• COM 技术的基本目标：不同开发人员、不同编程语言实现的对象互相连接；便于重用。

• COM的特征

  • 面向对象
  • 客户机/服务器
  • 语言无关性
  • 进程透明性
  • 可重复性

5.3.4.3 DCOM与COM+

DCOM（分布式组件对象模型）

• DCOM 是 COM 的扩展，针对分布环境提供了一些新特性，如位置透明性、网络安全性、跨平台调用等。(在不同的机器之间,调用对方的组件.)

• DCOM 通过 RPC 协议，使用户通过网络可以以透明的方式调用远程机器上的远程服务.

COM +

• COM + 为 COM 的新发展或 COM 更高层次上的应用，把 COM 组件软件提升到应用层而不再是底层的软件结构，与操作系统的结合更加紧密。

• COM + 标志着组件技术达到了一个新的高度，把目标指向了更为广阔的组织内部网，甚至互联网。

5.3.4.4 .NET

• .NET 是基于一组开放的互联网协议推出的一系列的产品、技术和服务。(上述三个是小型的,大的开发平台就是微软的.Net)
• .NET开发框架在通用语言运行环境基础上，给开发人员提供了完善的基础类库、数据库访问技术及网络开发技术，开发者可以使用多种语言快速构建网络应用。

5.3.4.5 J2EE

• J2EE 架构是使用Java技术开发组织级应用的一种事实上的工业标准。具有可伸缩性、灵活性、易维护性的特点。

• J2EE 的体系结构可以分为

  • 客户端层
  • 服务器端组件层
  • EJB层
  • 信息系统层(应该是数据访问层)

5.3.5 应用集成

5.3.5.1 系统集成栈

• 网络集成解决语法的问题(语法就是词语的基本规则,没有网络集成连通讯都不成,无法识别说的话是真的假的对的错的,根本就无法传递信息.)
• 数据集成解决语义的问题(要对数据进行清理,保证每个子系统的数据表示的意义统一,要数据有意义,解决语义的问题,大家之间互相理解.)
• 应用集成解决语用的问题(不同的系统能够互相调用,实现各自的需求,各个系统能真的互相调用.)

互操作性指的是能在对等层次上进行有效的信息交换.

5.3.5.2 组织应用集成EAI

• 应用集成或组织应用集成（ EAI ）：将独立的软件应用连接起来，实现协同工作。(EAI:企业各种应用能够集成.)

• EAI 作用：提高运营效率，实现工作流自动化，增强不同部门和团队之间协作。

• EAI 技术要求：

  • 应用间的互操作性
  • 分布式环境中应用的可移植性(SOA就是可以实现这种可移植性.)
  • 系统中应用分布的透明性

EAI关键在于：独立应用之间实现实时双向通信和业务数据流(工作流和业务流是EAI的难点.)

• EAI 中用到的组件：

  • 应用编程接口（ API ）：API 是定义不同软件交互方式的程序和规则，可以支持应用之间相互通信。(老的系统应用包装成API,供其他系统的调用.)

  • 事件驱动型操作：当触发器（ 即事件 ）启动一个程序或一组操作时，系统就会执行事件驱动型操作。(把各个系统的业务流集中到一起,有一个系统里发生了一件事,一件事情的提交,其他系统也会跟着修改)

  • 数据映射：将数据从一个系统映射到另一个系统，可以定义数据的交换方式，从而简化后续的数据导出、分组或分析工作。(一个地方的数据修改,会同步修改其他相关系统的修改.)

5.4 安全工程

• 从安全过程模型的角度讲安全问题.

5.4.1 信息安全系统工程概述

5.4.1.1 几个概念之间的关系

• 信息安全系统工程就是要建造一个信息安全系统，它是整个信息系统工程的一部分，而且最好是与业务应用信息系统工程同步进行.

• 左边业务系统,右边信息安全系统.

5.4.1.2 信息安全系统体系架构(理解为主)

• X 轴是 “ 安全机制 ” 。安安全机制可以理解为提供某些安全服务，利用各种安全技术和技巧，所形成的一个较为完善的结构体系。如“平台安全”机制，实际上就是指安全操作系统、安全数据库、应用开发运营的安全平台以及网络安全管理监控系统等。

• Y 轴是 " OSI 网络参考模型 " 信息安全系统的许多技术、技巧都是在网络的各个层面上实施的，离开网络信息系统的安全也就失去意义.

• Z轴是 “ 安全服务 ” 。安全服务就是从网络中的各个层次提供给信息应用系统所需要的安全服务支持。如对等实体认证服务、访问控制服务、数据保密服务等.

5.4.2 信息安全系统工程体系架构(重点)

5.4.2.1 ISSE - CMM 基础(介绍)

• 信息安全系统工程（ Information Security System Engineering，ISSE ）是二门系统工程学，它的主要内容是确定系统和过程的安全风险，并且使安全风险降到最低或使其得到有效控制。

• ISSE 能力成熟度模型，（ ISSE Capability Maturity Model，ISSE-CMM ）是一种衡量信息安全系统工程实施能力的方法，是使用面向工程过程的一种方法。

• ISSE - CMM 建立在统计过程控制理论基础上。ISSE-CMM模型抽取了这样一组 “ 好的 ” 工程，实施并定文了过程的 “ 能力 ”

• ISSE - CMM 模型覆盖了：

  • 整个生命周期，包括工程开发、运行、维护和终止；
  • 管理、组织和工程活动等的组织；
  • 与基他规范如系统、软件、硬件、人的因素、测试工程、系统管理、运行和维护等规范异行的箱查作用；
  • 与其他组织 ( 包括获取、系统管理、认证、认可和评估组织 ) 的相互作用。

• ISSE-CMM 主要适用于：

  • 工程组织：系统集成商、应用开发商、产品提供商和服务提供商等。作用：自我评估.
  • 获取组织：采购系统、产品以及从外部/内部资源和最终用户处获取服务的组织。作用：判别供应组织或产品可信任性.
  • 评估组织：认证组织、系统授权组织、系统和产品评估组织等。作用：评估被评组织整体能力.

5.4.2.2 ISSE 过程(细节)

• ISSE 实施过程分解为：工程过程 ( Engineering Process )、风险过程 ( Risk Process ) 和保证过程 ( Assurance Process ) 三个基本的部分。

  • 工程过程与其他工程一起来确定安全策略和实施解决方案；(跟信息安全相关的工程过程)
  • 风险过程识别出所开发的产品或系统风险，并对这些危险进行优先级排序；
  • 保证过程建立起解决方案的可信性并向用户转达这种安全可信性(确保有信息搭建出安全的系统)

1 ) 工程过程

• ISSE 包括概念、设计、实现、、测试、部署、运行、维护、退出的完整过程，如图所示(把信息安全的过程和软件的过程相结合.)

• 上图是小的五个过程.非常重要
• 五个过程域(PA)

2 ）风险过程

• 一个有害事件由威胁、脆弱性和影响三个部分组成。
• 风险管理是调查和量化风险的过程，并建立组织对风险的承受级别，风险管理过程如图所示。

• 威胁是外部的威胁,脆弱性是系统内部的哪个地方做的不够好,威胁和脆弱性做的都不好,才会对系统造成威胁.

脆弱性包括可被威胁利用的资产性质。如果不存在脆弱性和威胁，则不存在有害事件，也就不存在风险.

3 ）保证过程

• 保证过程是指安全需求得到满足的可信程度，这种信心来自于措施及其部署的正确性和有效性。保证过程如图所示：

• 只有两个过程域: 验证和证实安全,建立保证论据.

5.4.2.3 ISSE - CMM 体系结构

• ISSE - CMM 的体系结构采用两维设计，其中一维是 “ 域 ”（ Domain ），另一维是 “ 能力 ”（ Capability )(进行两种维度的划分分类)

1）域维/过程域

• 过程域（ Process Area，PA ）覆盖了信息安全工程所有主要领域。每个域由6个基本实施（ Base Practice ，BP ）组成，基本实施定义了获得过程域目标的必要步骤。(过程域,可以看作是一组活动.核心是过程域,实现过程域要有基本实施,基本实施是行业内最佳实践,每个PA对应很多BP,两者是多对一的关系,过程类,对PA进行分类.)

• 两类过程域:

2）能力维/公共特性

• 通用实施（ Generic Practices，GP ）分组到公共特性（ Common Feature , CF ) ,公共特性分为5个级别，依次表示增强的组织能力。“ 能力 ” 维的通用实施按成熟性排序，高级别的通用实施位于能力维的高端。(通用实施:通用的最佳实践,好多最佳实践组成公共特性,很多公共特性组成最终的需要认证的能力,能力级别除了五级还有一个零级的混乱级别.)

• 每个公共特性包括一个或多个通用实施, 通用实施可应用到每一个过程域, 第一个公共特性 " 执行基本实施 " 除外 .(每个级别对应多个公共特性,每个公共特性有很多通用实施来构成)

公共特性的成熟度等级定义

• 公共特性是关于通用实施的逻辑分组.

3）能力级别

• ISSE - CMM 的实施按公共特性进行组织，并按级别进行排序。对每一个过程域能力级别的确定，均需执行一次评估过程。

• 这意味着不同的过程域能够可能位于不同的能力级别上。

5.5 单词汇总

序号	单词	简写	翻译	描述
1	Software Engineering	SE	软件工程
2	Idiomatic Paradigm		惯用模式
3		CBD	基于构件的软件开发
4	Sensitivity Point		敏感点
5	Trade-off Point		权衡点
6	EventObject		事件基类
7	PhaseEvent		阶段事件类
8	FacesEvent		Faces事件类
9	ActionEvent		动作事件类
10	ValueChangeEvent		值改变事件类
11	stimulus		刺激
12	environment		环境
13	response		响应
14		ATAM	架构权衡分析法
15		SAAM	软件架构分析法
16		CBAM	成本效益分析法
17	Object-Oriented Analysis	OOA	面向对象分析方法
18	Object Oriented	OO	面向对象
19	Software Requirements Specification	SRS	软件需求规格说明书
20	Structured Analysis	SA	结构化分析方法
21	Entity Relationship Diagram	E-R图	实体-联系图
22	Data Flow Diagram	DFD	数据流图
23	State Transform Diagram	STD	状态转换图
24	Unified Modeling Language	UML	统一建模语言
25	Class diagram		类图
26	object diagram		对象图
27	Package diagrams		包图
28	Component diagram		构件图
29	Composite structure diagram		组合结构图
30	Deployment diagram		部署图
31	Artifact diagram		制品图
32	Use case diagrams		用例图
33	Activity diagrams		活动图
34	Statemachine diagrams		状态图
35	Sequence diagrams		顺序图
36	Communication diagrams		通信图
37	Timing diagrams		定时图
38	Interaction overview diagrams		交互概览图
39	Dependency		依赖
40	Association		关联
41	generalization		泛化
42	Realization		实现
43	Aggregation		聚合
44	Composition		组合
45	Actor		参与者
46	Use Case		用例
47	Sub system		子系统
48	Inheritance		继承
49	Include		包含
50	Extend		扩展
51	Logical View		逻辑视图
52	Implementation View		实现视图
53	Use Case View		用例视图
54	Process View		进程视图
55	Deployment View		部署视图
56	Object Oriented Design	OOD	面向对象设计
57	Use Case Specification		用例规约
58	Structured Design	SD	结构化设计
59	Open Close Principle		开闭原则	对扩展开放，对修改关闭
60	Liskov Substitution Principle		里氏代换原则	任何基类可以出现的地方，子类一定可以出现
61	Dependence Inversion Principle		依赖倒置原则	针对接口编程，依赖于抽象而不依赖于具体
62	Interface Segregation Principle		接口隔离原则	使用多个隔离的接口，比使用单个接口要好
63	Demeter Principle		迪米特法则，又称最少知道原则	一个实体应当尽量少地与其他实体发生相互作用
64	Composite Reuse Principle		合成复用原则	尽量使用合成/聚合的方式，而不是使用继承
65	Single Response Principle	SRP	单一职责原则	设计功能单一的类，不要在一个类中实现多个功能
66	Design pattern		设计模式
67	Test Model		测试模型
68	Static Testing		静态测试
69	Dynamic Teesting		动态测试
70	Capability Maturity Model Integration	CMMI	能力成熟度模型集成
71	Software Process Capability Maturity Model	CSMM	软件过程能力成熟度模型
72	Data About Data		元数据
73	Open Systems Interconnection Environment	OSIE	开放系统互连环境
74	Top-Down		自上而下
75	Down-Top		自下而上
76	Recovery Point Object	RPO		当灾难发生时允许丢失的数据
77	Recovery Time Object	RTO		系统恢复的时间
78	Data Visualization		数据可视化
79	Geographic Information System	GIS	地理信息系统
80	Information Retrieval		信息检索
81	Open Database Connectivity	ODBC	开放式数据库互联
82	Java Database Connectivity	JDBC	Java数据库连接
83	JavaScript Object Notation	JSON
84	Common Object Request Broker Architecture	CORBA	公共对象请求代理体系结构
85	Object Management Group	OMG	对象管理组织
86		EAI	组织应用集成
87		API	应用编程接口
88	Information Security System Engineering	ISSE	信息安全系统工程
89	ISSE Capability Maturity Model	ISSE-CMM	ISSE 能力成熟度模型	一种衡量信息安全系统工程实施能力的方法，是使用面向工程过程的一种方法。
90	Engineering Process		工程过程
91	Risk Process		风险过程
92	Assurance Process		保证过程
93	Domain		域
94	Capability		能力
95	Process Area	PA	过程域
96	Base Practice	BP	基本实施
97	Generic Practices	GP	通用实施
98	Common Feature	CF	公共特性

附录

• 教材音频版,可以不用看书,听着语音听完本章的教材

序号	章节	链接
1	第5章信息系统工程	https://www.bilibili.com/video/BV1ptpZeJEmz/?spm_id_from=333.999.0.0&vd_source=0bb2dec1aa524e2dda1f4e45974694e9