【高项第4版】【第5章】《信息系统工程》知识点梳理

5.1 软件工程

电气与电子工程师协会(Institute of Electrical and Electronics Engineers,IEEE)对软件工程的定义是：将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究。

软件工程由方法、工具和过程三个部分组成：

①软件工程方法是完成软件工程项目的技术手段，它支持整个软件生命周期；

②软件工程使用的工具是人们在开发软件的活动中智力和体力的扩展与延伸，它自动或半自动地支持软件的开发和管理，支持各种软件文档的生成；

③软件工程中的过程贯穿于软件开发的各个环节，管理人员在软件工程过程中，要对软件开发的质量、进度和成本进行评估、管理和控制，包括人员组织、计划跟踪与控制、成本估算、质量保证和配置管理等。

5.1.1 架构设计

1. 软件架构风格

五种常见的风格：数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。

拓展：

数据流风格包括批处理序列和管道/过滤器两种风格。批处理序列风格是将软件系统中的任务分成若干个连续的步骤，每个步骤都会产生输出数据，并传递给下一个步骤作为输入数据，以此类推，直到最终结果得出。管道/过滤器风格是将系统中的任务分成若干个独立的模块，每个模块只处理特定类型的数据，并将结果传递给下一个模块进行处理。

调用/返回风格包括主程序/子程序、数据抽象和面向对象，以及层次结构。主程序/子程序风格是一种自上而下的程序设计方式，主程序控制程序的执行流程，而子程序负责实现具体的功能。数据抽象和面向对象风格则强调数据和操作的封装，采用面向对象编程语言进行编写。层次结构风格是将系统划分为若干个层次，每个层次都有特定的功能，并且层次之间存在依赖关系。

独立构件风格包括进程通信和事件驱动的系统。进程通信风格是将软件系统分成若干个独立的进程或线程，每个进程或线程都运行在自己的地址空间中，通过消息传递或共享内存等方式进行通信。事件驱动的系统则是通过事件触发来完成任务，每个事件都会触发相应的处理程序进行处理。

虚拟机风格包括解释器和基于规则的系统。解释器风格是采用解释器对程序进行解释执行，不需要提前编译生成可执行文件。基于规则的系统则是将系统划分为若干个规则库，每个规则库都包含一系列规则，系统根据输入数据匹配相应的规则进行处理。

仓库风格包括数据库系统、黑板系统和超文本系统。数据库系统将数据以表格的形式存储在数据库中，并提供SQL语言进行查询和操作。黑板系统采用共享黑板的方式进行多个智能体之间的协作，每个智能体可以在黑板上留下自己的信息和推理结论。超文本系统则是一种基于超链接的文本展示方式，可以实现非线性的阅读体验。

2. 软件架构评估

软件架构设计是软件开发过程中至关重要的一步，缺乏合适的架构会影响软件的成功开发。不同类型的系统需要不同的架构，选择合适的架构对一个系统的成功至关重要。这一小节介绍了敏感点和权衡点的概念，敏感点是一个或多个构件的特性，权衡点则是影响多个质量属性的特性。

本小节还介绍了三种主要的软件架构评估方式：基于调查问卷的方式、基于场景的方式和基于度量的方式。其中，基于场景的方式最为常用，并分别介绍了架构权衡分析法、软件架构分析法和成本效益分析法。基于场景的评估方式通过分析软件架构对场景的支持程度来判断该架构对相应质量需求的满足程度，需要丰富的领域知识和对待评估软件架构的了解。

总之，软件架构设计和架构评估对于确保软件系统的良好质量具有至关重要的作用，需要专业的方法和技能来实施。

5.1.2 需求分析

1. 需求的层次

包含：业务需求、用户需求和系统需求。

QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。

拓展：KANO模型

2. 需求过程

需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等。

老知识点

1）需求获取

常见的需求获取方法：用户访谈、问卷调查、采样、情节串联板、联合需求计划等。

2）需求分析

结构化分析(Structured Analysis, SA)

使用结构化分析(Structured Analysis, SA)方法进行需求分析时，围绕数据字典这一核心，建立三个层次的模型，包括数据模型、功能模型和行为模型(也称为状态模型)。

• 实体关系图(E-R图)表示数据模型
• 数据流图(Data Flow Diagram, DFD)表示功能模型
• 状态转换图(State Transform Diagram, STD)表示行为模型

E-R图主要描述实体、属性，以及实体之间的关系；

DFD从数据传递和加工的角度，描述系统内各个部件的功能和数据在它们之间传递的情况，说明系统所完成的功能；

STD通过描述系统的状态和引起系统状态转换的事件，表示系统的行为，指出特定事件执行哪些动作。

面向对象的分析(Object-Oriented Analysis, OOA)

基本任务是运用面向对象的(Object-Oriented, OO)方法，对问题域进行分析和理解，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。

OOA模型包括用例模型和分析模型，用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模；分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统行为（动态模型）。

3）需求规格说明书编制

软件需求规格说明书(Software Requirement Specification, SRS)是软件开发过程中最重要的文档之一，其目的是为了使项目干系人与开发团队对系统的初始规定有一个共同的理解，成为整个开发工作的基础。

国家标准GB/T8567《计算机软件文档编制规范》提供了SRS的文档模板和编写指南，其中规定SRS应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。

拓展，一个完整的SRS应当包含以下内容：

1. 引言：包括文档的目的、范围、定义、缩写、参考资料等信息；
2. 业务需求：对业务需求进行详细描述，包括业务流程、功能需求、性能需求、界面需求等；
3. 系统需求：对系统需求进行详细描述，包括系统架构、数据结构、算法等；
4. 非功能需求：对非功能需求进行详细描述，包括安全性、可靠性、可用性、可维护性等；
5. 数据需求：对数据需求进行详细描述，包括数据结构、数据格式、数据存储方式等；
6. 接口需求：对与外部系统接口的需求进行详细描述；
7. 总体设计要求：对总体设计要求进行详细描述，包括技术架构、分层结构、处理流程等；
8. 测试要求：对测试要求进行详细描述，包括测试方法、测试数据、测试环境等；
9. 项目计划：对项目计划进行详细描述，包括项目时间表、人员分配、任务安排等；
10. 其他信息：其他需要在SRS中记录的重要信息。

一份好的SRS应当具有完整性、准确性、清晰性、可验证性和可追踪性，可以作为开发团队和客户、用户之间沟通和协作的重要参考文档。

国家标准GB/T9385《计算机软件需求说明编制指南》也给出了一个详细的SRS写作大纲，可以作为SRS写作的参考。SRS的编制是需求开发活动的产物，在任何规模和性质的软件项目中都不应该缺少。

4）需求验证与确认

在系统分析阶段，对SRS进行验证和确认可以节省大量时间和资金。验证和确认活动内容包括对SRS描述的系统行为和特征是否正确，软件需求是否从系统需求、业务规格和其他来源正确推导而来，需求是否完整、高质量、表示一致以及是否为继续进行系统设计、实现和测试提供了足够的基础。

需求评审和需求测试工作是常见的需求验证方式，通过技术评审可以发现二义性或不确定性的需求，并提供达成共识的方法；同步进行需求测试能及早发现问题，从而在需求开发阶段以较低的代价解决这些问题。

3. UML

UML的结构包括构造块、规则和公共机制三个部分。

1）UML中的事物

建模元素，包括结构事物（Structural Things）、行为事物（Bchavioral Things，也称动作事物）、分组事物（Grouping Things）和注释事物（Annotational Things，也称注解事物）。

UML有七种结构事物，分别是类、接口、协作、用例、活动类、构件和节点；

UML有两种主要的行为事物，分别是交互（内部活动），状态机；

2）UML中的关系

UML用关系把事物结合在一起，主要有四种关系依赖、关联、泛化、实现：

• 依赖(Dependency): 描述两个事物之间的语义关系，其中一个事物的变化可能会影响另一个事物的语义。例如，一个汽车对象需要使用轮胎对象，因此汽车对象对轮胎对象具有依赖关系。
• 关联(Association): 描述一组对象之间连接的结构关系。这种关系非常常见，例如，在一个学校系统中，教师对象和学生对象之间可以建立关联关系，因为教师对象可以拥有多个学生对象。
• 泛化(Generalization): 描述一般元素和特殊元素之间的关系，也就是继承关系。特殊元素可以替换一般元素，因为它们具有相同的基本属性和方法，同时还具有自己的独特特征。例如，动物类是一般元素，而猫、狗、鸟等具体动物类则是特殊元素，因为它们都继承了动物类的基本属性和方法，并且拥有自己的特定属性和方法。
• 实现(Realization): 描述了类之间的语义关系，其中一个类指定了由另一个类保证执行的契约。例如，在一个银行系统中，银行账户类可能实现了可提取现金接口，因为银行账户对象需要能够提取现金，而可提取现金接口规定了提取现金的所有方法。

3）UML2.0中的图

类图、对象图、构件图、组合结构图、用例图、顺序图、通信图、定时图、状态图、活动图、部署图、制品图、包图、交互概览图。

4）UML视图

逻辑视图、进程视图、实现视图、部署视图、用例视图

4. 面向对象分析

1）用例模型

OOA方法的四个阶段，识别参与者、合并需求并获得用例、细化用例描述和调整用例模型。

2）分析模型

该小节介绍了分析模型的作用和构建过程，其中领域模型是构建分析模型的重要基础，也称为概念模型或域模型。

在建立分析模型的过程中，需要定义概念类，确定类之间的关系，为类添加职责，建立交互图等。其中，类之间的主要关系有关联、依赖、泛化、聚合、组合和实现等。

这些关系在UML中有不同的表示方式，例如关联需注明关系的名称、角色、多重性和导向性。具体来说，关联表示不同类的对象之间的结构关系，依赖表示一个类对另一个类的变化敏感，泛化表示父类与子类之间的关系，聚合和组合表示类之间整体与部分的关系，实现表示类和接口之间的联系。

举个例子来说，假设我们要开发一个在线商城系统，我们可以从用例模型中获得灵感，如“用户查找商品”就是一个用例，它可以产生一个顺序图，描述用户和商品类之间如何进行交互。

同时，通过领域模型，我们可以找到代表事物与概念的对象，如“用户”、“商品”、“订单”等概念类。通过定义这些概念类，并确定它们之间的关系，例如“用户可以查找商品”，“商品可以被添加到订单中”，我们就可以建立分析模型，来描述这个在线商城系统的基本逻辑结构。

5.1.3软件设计

1. 结构化设计

是一种面向数据流的方法，分为概要设计和详细设计。

概要设计又称为总体结构设计，形成软件的模块结构图，即系统结构图。

根据任务的不同，详细设计又可分为多种，例如，输入/输出设计、处理流程设计、数据存储设计、用户界面设计、安全性和可靠性设计等。

遵循的基本原则：高内聚，低耦合。

2. 面向对象设计

本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。

OOD原则包括：单职原则、开闭原则、李式替换原则、依赖倒置原则、接口隔离原则、组合重用原则、迪米特原则（最知识法则）。

3. 设计模式

设计模式可分为类模式和对象模式。

模式处理类和子类之间的关系，属于静态关系；对象模式处理对象之间的关系更具动态性。

设计模式可分为创建型(Creational)模式、结构型(Structural)模式和行为型(Behavioral)模式三种：

• ①创建型模式主要用于创建对象，包括工厂方法模式、抽象工厂模式、原型模式、单例模式和建造者模式等；
• ②结构型模式主要用于处理类或对象的组合，包括适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式等；
• ③行为型模式主要用于描述类或对象的交互以及职责的分配，包括职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式等。

5.1.4 软件实现

1. 软件配置管理

通过标识产品的组成元素、管理和控制变更、验证、记录和报告配置信息，来控制产品的演进和完整性。

软件配置管理活动包括软件配置管理计划、软件配置标识、软件配置控制、软件配置状态记录、软件配置审计、软件发布管理与交付等活动。

2. 软件编码

编码的几个重要方面：程序设计语言、程序设计风格、程序复杂度度量、以及编码效率。

• 程序设计语言是人和计算机通信的最基本工具，选择一种适当的程序设计语言对提高编码的质量有重要作用。
• 程序设计风格包括源程序文档化、数据说明、语句结构和输入/输出方法等方面，应尽量从编码原则的角度提高程序的可读性和质量。
• 程序复杂度度量是定量化衡量软件性质的方法之一，可以估算出软件中故障的数量及软件开发时的工作量，是比较不同设计或算法优劣的重要参考。
• 编码效率主要包括程序效率、算法效率、存储效率和IO效率等方面，要注意提高程序执行速度及所需占用的内存空间、选择可生成较短目标代码且存储压缩性能优良的编译程序，并在开发过程中注重程序的简单化。

3. 软件测试

根据国家标准GB/T15532《计算机软件测试规范》，软件测试的目的是为了验证软件是否满足软件开发合同或项目开发计划、系统/子系统设计文档、SRS、软件设计说明和软件产品说明等规定的软件质量要求，并通过测试发现软件缺陷，为软件产品的质量测量和评价提供依据。

软件测试方法可分为静态测试和动态测试。

• 静态测试是指通过人工检测和计算机辅助静态分析的手段对被测试程序进行检测，包括对文档的静态测试和对代码的静态测试；
• 动态测试是指在计算机上实际运行程序进行软件测试，一般采用白盒测试和黑盒测试方法。

静态测试主要采用桌前检查、代码走查和代码审查等方法，能够有效地发现逻辑设计和编码错误。

白盒测试又称为结构测试，主要用于软件单元测试中。按照程序内部逻辑结构设计测试用例，检测程序中的主要执行通路是否都能按预定要求正确工作。白盒测试方法中，最常用的技术是逻辑覆盖，即使用测试数据运行被测程序，考查对程序逻辑的覆盖程度。

黑盒测试又称为功能测试，主要用于集成测试、确认测试和系统测试中。将程序看作是一个不透明的黑盒，完全不考虑(或不了解)程序的内部结构和处理算法，而只检查程序功能是否能按照SRS的要求正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息(例如，文件和数据库等)的完整性等。黑盒测试根据SRS所规定的功能来设计测试用例。

一般包括等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法等。

5.1.5 部署交付

1. 软件部署交付

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

2. 持续交付

持续交付是一个完全自动化的过程，能够让代码快速、安全地部署到生产环境中，并提供一套更为完善的解决传统软件开发流程的方案。

持续交付具备的优势包括缩短提交代码到正式部署上线的时间、降低部署风险、及时发现和修复缺陷、使软件版本更加清晰、可靠的、可预期的、可视化的过程。

对于评价互联网公司的软件交付能力，通常使用仅涉及一行代码的改动需要花费多少时间才能部署上线这一核心指标，以及开发团队是否在以一种可重复、可靠的方式执行软件交付。当前国内外主流互联网组织的部署周期都以分钟为单位，高频率的部署代表着能够更快更好地响应客户需求。

互联网巨头组织单日的部署频率都在8000次以上，部分组织达20000次以上。

3. 持续部署

持续交付中的关键点：持续部署方案、部署原则、部署层次、不可变服务器以及蓝绿部署和金丝雀部署。

• 在持续部署方案中，容器技术是最流行的技术之一，主要优点包括上手简单、轻量级架构、更集合性和更精准的环境依赖打包。
• 在部署原则中，需要遵循多个原则，如统一存储库、相同的部署方式、编排阶梯式回滚、仅运维人员执行等。在部署层次中，部署的目标是部署一套可正常运行的环境，完整的镜像部署包括Build、Ship和Run三个环节。
• 在不可变服务器中，除了更新和安装补丁程序以外，不对服务器进行任何更改，这种部署模式已经成为一种趋势。
• 在部署方式中，蓝绿部署指准备新旧两个部署版本，并通过域名解析切换的方式将用户使用环境切换到新版本中，而金丝雀部署则是先让少量用户使用新版本并观察是否存在问题。

4. 部署与交付的新趋势

持续集成、持续交付和持续部署的出现及流行反映了新的软件开发模式与发展趋势。

• 主要表现为工作职责和人员分工的转变、大数据和云计算基础设施的普及以及研发运维的融合。随着持续集成、持续交付和持续部署的流行，软件开发人员逐渐使用自动化开发工具进行持续集成，并进一步将交付和部署扩展，原来的手工运维工作也逐渐被分派到了开发人员的手里。
• 此外，大数据和云计算基础设施的普及也为部署带来了新的飞跃，使得计算机本身也可以进行自动化创建和回收，环境管理的范畴将得到进一步扩充。部署能力和灵活性也出现了质的飞跃。
• 最后，研发运维的融合减轻了运维的压力，把运维和研发融合在一起。

5.1.6 过程管理

常见的软件过程管理方法和实践包括国际常用的能力成熟度模型集成(Capability Maturity Model Integration,CMMI,详见本书20.5.1节)和中国电子工业标准化技术协会发布的T/CESA 1159《软件过程能力成熟度模型》(Software Process Capability Maturity Model)团体标准，简称CSMM。

1.  成熟度模型

CSMM模型由4个能力域、20个能力子域、161个能力要求组成：

• 治理：包括战略与治理、目标管理能力子域，用于确定组织的战略、产品的方向、组织的业务目标，并确保目标的实现。
• 开发与交付：包括需求、设计、开发、测试、部署、服务、开源应用能力子域，这些能力子域确保通过软件工程过程交付满足需求的软件，为顾客与利益干系人增加价值。

• 管理与支持：包括项目策划、项目监控、项目结项、质量保证、风险管理、配置管理、供应商管理能力子域，这些能力子域覆盖了软件开发项目的全过程，以确保软件项目能够按照既定的成本、进度和质量交付，能够满足顾客与利益干系人的要求。

• 组织管理：包括过程管理、人员能力管理、组织资源管理、过程能力管理能力子域，对软件组织能力进行综合管理。

2. 成熟度等级

CSMM定义了5个等级，从初始级到创新引领级。每一级都有其结果特征和行为特征，高等级的特征是在低等级的基础上进行的。

• 1级初始级是指软件过程和结果具有不确定性，在此基础上实现初步交付和项目管理活动。
• 2级项目规范级是指项目可以按计划实现预期结果，基于选择和定义的管理规范执行软件开发和管理的基础过程。
• 3级组织改进级在项目范围内能够稳定地实现预期的项目目标，通过建立和持续改进组织标准过程和过程资产等措施来实现持续改进。
• 4级量化提升级在组织范围内能够量化地管理和实现预期的组织和项目目标，使用统计分析技术进行管理，并采用有效的数据分析技术来识别和解决目标实现的问题以达成其目标。
• 5级创新引领级通过技术和管理的创新，实现组织业务目标的持续提升，引领行业发展，并能将自身软件能力建设的经验作为行业最佳案例进行推广。

5.2 数据工程

5.2.1数据建模

1.数据模型

1）概念模型

概念模型基本元素：实体、属性、域、键、关联。

2）逻辑模型

数据结构有层次模型、网状模型、关系模型、面向对象模型和对象关系模型。其中，关系模型成为目前最重要的一种。

3）物理模型

物理数据模型的目标是如何用数据库模式来实现逻辑数据模型，以及真正地保存数据。物理模型的基本元素包括表、字段、视图、索引、存储过程、触发器等，其中表、字段和视图等元素与逻辑模型中基本元素有

一定的对应关系。

2.数据建模过程

数据建模是指将现实世界的数据需求转换为可管理和操作的数据库结构的过程。

数据建模过程包括四个阶段：数据需求分析、概念模型设计、逻辑模型设计和物理模型设计。

• 在数据需求分析阶段，需要充分调查用户实际要求，采用数据流图作为工具来描述系统中数据的流动和变化，以确定用户对数据的需求。
• 在概念模型设计阶段，需要将需求分析得到的结果抽象为概念模型，确定实体和数据及其关联。
• 在逻辑模型设计阶段，需要在概念模型的基础上进行逻辑模型的设计，将实体、属性和关联转换为关系模型结构中的关系模式。
• 在物理模型设计阶段，需要根据具体的DBMS进行物理模型设计，使数据模型走向数据存储应用环节。物理模型设计要考虑命名、确定字段类型和编写必要的存储过程与触发器等问题。

整个数据建模过程需要充分沟通和交流，确保最终数据库结构能够满足用户的实际需求。

5.2.2 数据标准化

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

数据标准化的主要内容包括数据元、数据元标准化、数据模式标准化、数据分类与编码标准化和数据标准化管理。

5.2.3 数据运维

数据存储、数据备份、数据容灾、数据质量评价与控制、数据质量控制、数据清理。

5.2.4 数据开发利用

包含数据集成、数据挖掘和数据服务(目录服务、查询服务、浏览和下载服务、数据分发服务)、数据可视化、信息检索等。

5.2.5 数据处理安全

1.数据库安全威胁

数据库中不同用户通过数据库管理系统访问同一组数据集合，虽然消除了不一致的问题和减少了数据冗余，但也增加了数据库面临更严重的安全威胁的风险。

数据库安全威胁主要包括非授权的信息泄露、非授权的数据修改、拒绝服务、自然或意外灾害等多个维度。这些威胁方式可能是无意的系统软硬件错误，也可能是人为错误，有意滥用自己的特权或使用病毒、特洛伊木马和后门等恶意程序造成威胁。在数据库安全保护过程中，需要采取多种措施，例如加强用户身份认证、实施访问授权控制、加密存储和传输数据、定期备份和恢复数据库、监测和防范安全威胁等等，以提高数据库的安全性。

2.数据库安全对策

数据库安全对策，其重点在于保障数据库安全，确保数据的机密性、完整性和可用性等。

其中防止非法的数据访问是数据库安全的关键需求之一，通过访问控制来检查访问请求，确保只有授权的用户才能访问数据库，同时还需考虑推导问题，防止用户从统计聚合信息中推导得到原始个体信息，以保护数据的安全。

另外，保证数据库的完整性和数据操作的完整性也很重要，需要使用备份/恢复等方法来保证数据的一致性。

审计和日志记录可以有效的威慑和事后追查、分析，标识和认证也是授权、审计等的前提条件。

机密数据管理需针对不同情况，采取不同的访问控制措施，防止机密数据遭到非法泄露。

多级保护则用于将数据划分为不同的保密级别，赋予用户对应的数据访问权限。

最后，需要限制程序之间的信息传递，以避免非授权的信息泄露。

3. 数据库安全机制

数据库安全机制包括用户的身份认证、存取控制、数据库加密、数据审计、推理控制等内容。

5.3 系统集成

5.3.1 集成基础

系统集成的工作包括技术环境、数据环境和应用程序三个方面的集成，目的是将不同的系统连接起来，构成一个完整的组织级系统。

在技术上需要遵循的基本原则包括开放性、结构化、先进性和主流化。

• 开放性指的是要选择工业开放标准，以便实现互操作和移植性；
• 结构化强调系统设计的模块化和层次化；
• 先进性指的是采用先进的技术以确保系统的优势和生存周期；
• 主流化强调系统构成的每一个产品都应属于该产品发展的主流，具有良好的升级发展势头。

5.3.2网络集成

在网络集成的体系框架中，重要的几个方面包括传输子系统、交换子系统、安全子系统、网管子系统、服务器子系统、网络操作系统和服务子系统。

1. 传输子系统是网络中的核心，决定了网络信息传输的质量和速度。目前常用的传输介质包括无线传输介质和有线传输介质。
2. 交换子系统根据覆盖的区域可分为局域网、城域网和广域网，针对不同的交换范围使用不同的交换技术。
3. 安全子系统主要关注网络安全问题，如使用防火墙技术、数据加密技术和访问控制来保护网络资源。
4. 网管子系统用于管理网络，确保网络连续不断地满足组织的需要，并解决网络“瓶颈”问题。
5. 服务器子系统是网络中的关键设备，用于向工作站提供资源和服务，并负责协调管理这些资源。
6. 网络操作系统的主要任务是调度和管理网络资源，并为网络用户提供统一、透明使用网络资源的手段。
7. 服务子系统主要包括互联网服务、多媒体信息检索、信息点播、信息广播、远程计算和事务处理以及其他信息服务等。

5.3.3 数据集成

1.数据集成层次

数据集成层次主要包括基本数据集成、多级视图集成、模式集成和多粒度数据集成四个层次。

• 在基本数据集成中，需要解决通用标识符问题和数据丢失问题，其处理办法包括隔离、调和以及产生接近实际的估计值来进行处理。
• 多级视图集成机制有助于对数据源之间的关系进行集成，采用两级映射将数据从局部数据库中经过数据翻译、转换并集成为符合公共模型格式的中间视图，以及进行语义冲突消除、数据集成和数据导出处理，将中间视图集成为综合视图。
• 模式集成是数据库设计问题，但数据源的模式集成和数据库设计仍有相当的差距，需要解决命名、单位、结构和抽象层次等冲突问题。
• 多粒度数据集成是异构数据集成中最难处理的问题，理想的多粒度数据集成模式是自动逐步抽象，通过数据综合和数据细化实现特征提取和归并的过程。

2.异构数据集成

异构数据集成是指将多个不同结构和格式的数据源整合成一个统一的视图，以提供更好的数据访问支持。在进行异构数据集成时，需要考虑到数据完整性、约束完整性、语义冲突等问题。

异构数据集成主要有两种方法：过程式方法和声明式方法。过程式方法是从信息需求出发，设计了一套软件模块来存取数据源并封装数据源，通过中介者合并和一致化多个Wrappers和其他Mediator传过来的数据。声明式方法则通过一套合适的语言对多个数据源进行建模，构建一个统一的数据表示，并基于该表示进行查询，并通过一套有效的推理机制来对数据源进行存取。

此外，还可以使用中间件来集成异构数据库，中间件位于数据层和应用层之间，向下协调各数据库系统，向上为访问集成数据的应用提供统一的数据模式和数据访问的通用接口。

在实现异构数据源的集成过程中，需要解决原始数据的提取问题。这方面可以采用开放式数据库互联(ODBC)和专用的嵌入式C接口程序来提取数据。此外，在使用中间件时，需要为中间件选择全局数据模式，来统一异构数据源的数据模式。

当前，JSON作为一种轻量级的数据交换格式，被越来越多地应用到各个项目中，取代了以前广泛使用的XML。

5.3.4 软件集成

软件构件标准：公共对象请求代理结构(Common Object Request Broker Architecture,CORBA)、COM、DCOM与COM+、.NET、J2EE应用架构等标准。

5.3.5 应用集成

由于分布式系统中存在大量的异构网络和各种计算机产品，因此实现不同系统之间的信息交互和应用集成需要研究多项新的关键技术。

在这个过程中，互操作性是非常重要的。

互操作性指的是不同构件之间信息交换的有效性，能够在对等层次上进行有意义的信息交换。

而可移植性则指的是一个子系统能够从一个环境移植到另一个环境，而不破坏所提供或正在使用的服务。

应用集成（EAI）指将独立的软件应用连接起来，实现协同工作，并提高运营效率，增强不同部门和团队之间的协作。

应用集成技术要求具有应用间的互操作性、分布式环境中应用的可移植性以及系统中应用分布的透明性。在实现应用集成方面，各种组件，如应用编程接口(API)、事件驱动型操作、数据映射等都起到了重要的协调作用。

5.4 安全工程

5.4.1 工程概述

信息安全系统工程是为了建造一个信息安全系统而组织实施的工程。它是整个信息系统工程的一部分，与业务应用信息系统工程同步进行。信息安全系统工程主要围绕信息安全内容展开，包括信息安全风险评估、信息安全策略制定、信息安全需求确定、信息安全系统总体设计、信息安全系统详细设计、信息安全系统设备选型、信息安全系统工程招投标、密钥密码机制确定、资源界定和授权、信息安全系统施工中需要注意防泄密问题以及施工中后期的信息安全系统测试、运营、维护的安全管理等问题。

信息安全系统与业务应用信息系统不可混为一谈，两者的功能、操作流程、管理方式、人员要求、技术领域等都有很大的不同。信息安全系统服务于业务应用信息系统，但也不能脱离业务应用信息系统而存在。

同时，需要区分几个相关术语，包括信息系统、业务应用信息系统、信息安全系统、信息系统工程、业务应用信息系统工程和信息安全系统工程等。其中，业务应用信息系统是支撑业务运营的计算机应用信息系统，信息系统工程即建造信息系统的工程，包括信息安全系统工程和业务应用信息系统工程。信息安全系统工程是为了建设好信息安全系统的特殊需要而组织实施的工程。它是信息系统工程的一部分。

在信息化深入发展的背景下，信息安全系统工程将越来越重要。因为信息系统可以安全地建设成一个没有信息安全子系统的信息系统，但这样会留下相当大的隐患。因此，信息安全系统工程明确了建设信息安全系统的目标，将有助于保障业务应用信息系统的正常运营。

5.4.2 安全系统

X轴是“安全机制”；Y轴是“OSI网络参考模型”；Z轴是“安全服务”。

1. 安全机制

安全机制是保障信息系统安全的重要手段，主要包括基础设施实体安全、平台安全、数据安全、通信安全、应用安全、运行安全、管理安全、授权和审计安全、安全防范体系等九个方面。

1. 其中，基础设施实体安全主要涉及机房、场地、设施、动力系统等物理环境的保护；
2. 平台安全主要包括操作系统、网络基础设施、通用基础应用程序漏洞检测与修复等方面；
3. 数据安全主要涉及介质与载体安全保护、数据访问控制、数据完整性、数据可用性、数据监控和审计、数据存储与备份安全等方面；
4. 通信安全主要包括通信线路和网络基础设施安全性测试与优化、设置身份鉴别机制、测试各项网络协议运行漏洞等方面；
5. 应用安全主要包括业务软件的程序安全性测试、业务交往的防抵赖测试、业务资源的访问控制验证测试、应用系统的可靠性和可用性测试等方面；
6. 运行安全主要包括应急处置机制和配套服务、网络系统安全性监测、系统升级和补丁提供、跟踪最新安全漏洞及通报等方面；
7. 管理安全主要涉及人员、培训、应用系统、软件、设备、文档、数据、操作、运行、机房等方面；
8. 授权和审计安全主要是实现授权服务管理，提供用户身份到应用授权的映射功能，实现与实际应用处理模式相对应的访问控制机制；
9. 安全防范体系则是使得组织具有较强的应急事件处理能力，主要包括预警、保护、检测、反应、恢复和反击六个环节。

为了更好地保障信息安全，组织可以采取WPDRRC能力模型，并从人员、技术、政策三大要素来构建宏观的信息网络安全保障体系结构的框架，并确保日常和异常情况下的信息安全工作持续、有序地开展。

2. 安全服务

安全服务主要是为了保障网络交互过程中数据的安全性、真实性和完整性。

包括对等实体认证服务、数据保密服务、数据完整性服务、数据源点认证服务、禁止否认服务和犯罪证据提供服务。

• 其中，对等实体认证服务用于确认通信双方的合法性；
• 数据保密服务通过密码加密等方式保障数据的保密性；
• 数据完整性服务防止数据在传输过程中被非法篡改或丢失；
• 数据源点认证服务确保数据来自真实的源点；
• 禁止否认服务则避免了通信双方在数据传输后否认相关操作；
• 犯罪证据提供服务则为违反法律行为提供数字证据等信息线索。

5.4.4工程体系架构

1.ISSE-CMM基础

ISSE-CMM主要用于指导信息安全系统工程的完善和改进，使信息安全系统工程成为一个清晰定义的、成熟的、可管理的、可控制的、有效的和可度量的学科。

ISSE-CMM主要适用于工程组织(Engineering Organizations)、获取组织(Acquiring Organizations)和评估组织(Evaluation Organizations)。

2.ISSE过程

工程过程(Engineering Process)、风险过程(Risk Process)和保证过程(Assurance Process)三个基本的部分。

• 工程过程是一个包括概念、设计、实现、测试、部署、运行、维护、退出的完整过程，与其他系统工程组进行紧密合作。
• 风险过程是降低信息系统运行风险的过程，包括威胁评估、脆弱性评估、影响评估和风险量化。
• 保证过程是指信息安全系统工程实施过程可重复性的结果质量，包括建立保证论据和验证和证实安全等活动。

3.ISSE-CMM体系结构

ISSE-CMM是一种适用于信息安全系统工程范围内决定信息安全工程组织的成熟性的体系结构。

该体系结构采用两维设计，其中一维是“域”，另一维是“能力”。域维包括11个信息安全工程过程域，覆盖了信息安全工程所有主要领域。

能力维包括五个级别的通用实施，被称为公共特性，代表组织能力的增强。ISSE-CMM的实施按公共特性进行组织，并按级别进行排序，能力级别代表工程组织的成熟度级别。

该模型的目标是从管理和制度化突出信息安全工程的基本特征，以落实安全策略。

通过设置这两个相互依赖的维，ISSE-CMM在各个能力级别上覆盖了整个信息安全活动范围，可以帮助组织评估和改进信息安全工程能力。