Skip to content

第5章 信息系统工程

5.1 软件工程

软件工程由三个部分组成:

  • 方法: 完成软件工程项目的技术 手段,它支持整个软件生命周期
  • 工具: 人们在开发软件的活动中智力和体 力的扩展与延伸,它自动或半自动地支持软件的开发和管理,支持各种软件文档的生成;
  • 过程: 贯穿于软件开发的各个环节,管理人员在软件工程过程中,要对软件开发的质量、进度和成本进行评估、管理和控制,包括人员组织、计划跟踪与控制、成本估算、质量保 证和配置管理等

5.1.1 架构设计

1、 软件架构风格:

  1. 数据流风格 。 数据流风格包括批处理序列和管道/过滤器两种风格。
  2. 调用/返回风格。调用/返回风格包括主 程序/子程序、数据抽象和面向对象,以及层次结构。
  3. 独立构件风格。独立构件风格包括进 程通信和事件驱动的系统 。
  4. 虚拟机风格 。 虚拟机风格包括解释器和基于规则的系统 。
  5. 仓库风格 。 仓库风格包括数据库系统、黑板系统和超文本系统 。

软件架构评估

  • 敏感点(Sensitivity Point) 是一个或多个构件(或之间的关系)的特性
  • 权衡点 (Trade-offPoint)。权衡点是影响多个质量属性的特性,是多个质量属性的敏感点

2、三类主要的软件架构评估方式:

  • 基于调查问卷(或检查表)的方式
  • 基于场景的方式(最为常用):分析软件架构对场景的支持程度,从而判断该架构对这一场景所代表的质量需求的满足程度。例如,用一系列对软件的修改来反映易修改性方面的需求,用一系列攻击性操作来代表安全性方面的需求等
  • 基于度量的方式

基于场景的方式主要包括:

  • 架构权衡分析法(ArchitectureTrade-offAnalysisMethod, ATAM)、
  • 软件架构分析法( Software Architecture Analysis Method, SAAM)
  • 成本效益分析法( Cost Benefit Analysis Method, CBAM)

在架构评估中,一般采用三方面来对场景进行描述:

  • 剌激( Stimulus)
  • 环境( Environment)
  • 响应( Response)

5.1.2 需求分析

3、 软件需求包括:

  • 业务需求
  • 用户需求
  • 系统需求

4、 质量功能部署QFD将软件需求分为三类:

  • 常规需求
  • 期望需求
  • 意外需求

5、 需求过程主要包括:

  • 需求获取:用户访谈、问卷调查、采样、情节串 联板、联合需求计划
  • 需求分析
  • 需求规格说明书编制:软件需求规格说明书(Software Requirement Specification, SRS)
  • 需求验证与确认,活动内容包括:
    • SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征:
    • SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的:
    • 需求是完整的和高质量的:
    • 需求的表示在所有地方都是一致的:
    • 需求为继续进行系统设计、实现和测试提供了足够的基础。

6、 使用结构化分析( Structured Analysis, SA)方法进行需求分析, 其建立的模型的核心是 数据字典。 围绕这个核心, 有三个层次的模型:

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

7、 面向对象的分析( Object-Oriented Analysis, OOA)方法中, 构建用例模型一般需要经历四个阶段, 分别是识别参与者、 合并需求获得用例、细化用例描述和调整用例模型。

软件需求规格说明书( Software Requirement Specification, SRS)是需求开发活动的产物, 编制该文档的日的是使项目干系人与开发团队对系统的初始规定有 一个共同的理解,使之成为 整个开发工作的基础

统一建模语言(UnifiedModelingLanguage, UML) 的结构包括三个部分:

  • 构造块
  • 规则
  • 公共机制

UML主要有四种关系:

  • 依赖(Dependency) : 依赖是两个事物之间的语义关系,其中一个事物发生变化会影响另一个事物的语义 。
  • 关联( Association) : 关联描述一组对象之间连接的结构关系
  • 泛化( Generalization): 泛化是一般化和特殊化的关系,描述特殊元素的对象可替换一般元素的对象 。
  • 实现(Realization) : 实现是类之间的语义关系,其中的一个类指定了由另一个类保证执行的契约 。

UML2.0包括 14种图

  • 类图(Class Diagram):一组类
  • 对象图(ObjectDiagram):一组对象
  • 构件图(Component Diagram):构件和连接件
  • 组合结构图:结构化类
  • 用例图:用例
  • 顺序图(序列图):交互图,可能发送的消息
  • 通信图(协作图):交互图,收发消息
  • 定时图(计时图):交互图,实际时间
  • 状态图:状态机
  • 活动图:控制流和数据流
  • 部署图:配置
  • 制品图:物理结构
  • 包图:组织单元
  • 交互概览图:混合物

9、 UML5个系统视图:

  • 逻辑视图: 逻辑视图也称为设计视图, 它表示了设计模型中在架构方面具有重要意义的 部分, 即类、子系统、包和用例实现的子集
  • 进程视图: 进程视图是可执行线程和进程作为活动类的建模, 它是逻辑视图的一次执行 实例,描述了并发与同步结构
  • 实现视图: 实现视图对组成基于系统的物理代码的文件和构件进行建模
  • 部署视图 : 部署视图 把 构件部署到 一 组物理节点上,表 示软 件到硬件的映射和分布 结构
  • 用例视图 : 用例视图是最基本的需求分析模型

【记忆口诀:裸线不用进】

OOA 和 OOD 的区别: OOA 模型独 立于具体实现 ,即不 考虑与系统具体实 现有 关 的 因素

OOA方法中构 建用例模型一般需要经历四个阶段:

  • 识别参与者
  • 合并需求获得用例
  • 细化用例描述
  • 调整用例模型

OOA 模型包括:

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

10、 类之间的主要关系有:

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

5.1.3 软件设计

结构化设计 (Structured Design, SD)是一种面向数据流的方法,它 以 SRS 和 SA 阶段所产 生的 DFD和数据字典等文档为基础, 是一个自顶向下、 逐步求精和模块化的过程。

11、 在SD(结构化设计方法)中, 需要遵循一个基本的原则:高内聚, 低耦合

12、 面向对象设计(OOD) 是OOA方法的延续, 其基本思想包括抽象、 封装和可扩展性, 其中可扩展性主要通过继承和多态来实现。

常用 的 OOD 原则包括 :

  • 单职原则 : 设计功能单一的类。本原则与结构化方法的高内聚原则是一致的 。
  • 开闭原则 : 对扩展开放,对修改封闭。
  • 李氏替换原则 : 子类可以替换父类。
  • 依赖倒置原则:要依赖于抽象,而不是具体实现:要针对接口编程,不要针对实现 编程。
  • 接口隔离原则:使用多个专门的接口比使用单 一 的总接口要好。
  • 组合重用原则:要尽量使用组合,而不是继承关系达到重用目的。
  • 迪米特原则(最少知识法则): 一个对象应 当对其他对象有尽可能少的了解 。 本原则与结构化方法的低耦合原则是一致的。

13、 类模式处理类和子类之间的关系, 属于静态关系;对象模式处理对象之间的关系, 更具动态性。

根据处理范围不同,设计模式可分为:

  • 类模式
  • 对象模式

根据目的和用途不同, 设计模式可分为:

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

5.1.4 软件实现

15、 软件配置管理活动包括:

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

程序设计风格包括 4 个方面:

  • 源程序文档化
  • 数据说明
  • 语句结构
  • 输入/输出方法

软件测试方法可分为:

  • 静态测试:文档、代码
  • 动态测试
    • 自盒测试/结构测试: 单元测试、逻辑覆盖
    • 黑盒测试/功能测试: 集成测试

16、 对文档的静态测试主要以检查单的形式进行, 对代码的静态测试一般采用桌前检查、 代码走查和代码审查。

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

5.1.5 部署交付

18、 容器技术目前是部署中最流行的技术, 常用的持续部署方案有Kubernetes+Docker和Matrix系统两种。

19、 完整的镜像部署包括三个环节:Build—Ship—Run。

20、 在部署原则中提到两大部署方式为:

  • 蓝绿部署: 是指在部署的时候准备新旧两个部署版本通过域名解析切换的方式将用户使用环境切换到新版本中,当出现问题的时候,可以快速地将用户环境切回旧版本,并对新版本进行修复和调整。
  • 金丝雀部署: 是指当有新版本发布的时候,先让少量用户使用新版本,并且观察新版本是否存在问题。如果出现问题,就及时处理并重新发布:如果一切正常,就稳步地将新版本适配给所有的用户。

5.1.6 过程管理

21、 软件过程能力包括:

《软件过程能力成熟度模型 》 (Software Process Capability Maturity Model)团体标准,简称 CSMM

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

能力域能力子域
治理包括战略与治理、目标管理能力子域,用于确定组织的战略、产品的方向、组织 的业务目标,并确保目标的实现
开发与交付包括需求、设计、开发、测试、部署、服务、开源应用能力子域,这些能 力子域确保通过软件工程过程交付满足需求的软件,为顾客与利益干系人增加价值
管理与支持包括项目策划、项目监控、项目结项、 质量保证、风险管理、配置管理、 供应商管理能力子域,这些能力子域覆盖了软件开发项目的全过程,以确保软件项目能 够按照既定的成本、进度和质量交付,能够满足顾客与利益干系人的要求
组织管理包括过程管理、人员能力管理、组织资源管理、过程能力管理能力子域,对 软件组织能力进行综合管理

22、 成熟度级别:

  • 1级初始级
  • 2级项目规范级
  • 3级组织改进级
  • 4级量化提升级
  • 5级创新引领级

5.2 数据工程

5.2.1 数据建模

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

23、 根据模型应用目的不同, 可以将数据模型划分为三类:

  • 概念模型:(信息模型)概念模型也称信息模型,它是按用户的观点来对数据和信息建模,也就是说,把现实世界中的客观对象抽象为某一种信息结构,这种信息结构不依赖于具体的计算机系统,也不对应某个具体的DBMS.
  • 逻辑模型
  • 物理模型:考虑具体的技术实现因素,目标是如何用数据库模式来实现逻辑数据模型,以及真正地保存数据

概念模型

从概念模型导出与DBMS相关的逻辑模型

逻辑模型的数据结构有:

  • 层次模型
  • 网状模型
  • 关系模型:目前最重要的一种逻辑数据模型
  • 面向对象模型
  • 对象关系模型

25、 数据建模过程包括:

  • 数据需求分析
  • 概念模型设计
  • 逻辑模型设计
  • 物理模型设计

5.2.2 数据标准化

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

26、 数据标准化的主要内容包括

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

27、 数据标准化阶段的具体过程包括四个阶段(v4-P153):

  • 确定数据需求。将产生数据需求及相关的元数据、域值等文件。在确定数据需 求时应考虑现行的法规、政策,以及现行的数据标准。
  • 制定数据标准。要处理“确定数据需求”阶段提出的数据需求。如果现有的数据 标准不能满足该数据需求,可以建议制定新的数据标准,也可建议修改或者封存己有数据标准。 推荐的、新的或修改的数据标准记录于数据字典中 。 这个阶段将产生供审查和批准的成套建议。
  • 批准数据标准。数据管理机构对提交的数据标准建议、现行数据标准的修改 或封存建议进行审查。 一经批准,该数据标准将扩充或修改数据模型。
  • 实施数据标准。 在各信息系统中实施和改进己批准的数据标准。

5.2.3 数据运维

28、 当前最常见的数据备份结构可以分为四种:

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

29、 常见的备份策略主要有三种:

  • 完全备份
  • 差分备份
  • 增量备份

30、 根据容灾系统保护对象的不同, 容灾系统分为两类:

  • 应用容灾
  • 数据容灾

31、 数据质量评价方法分为:

  • 直接评价法
  • 间接评价法

32、 数据产品的质量控制分成两个大部分:

  • 前期控制
  • 后期控制

33、 数据清理主要包括三个步骤:

  • 数据分析
  • 数据检测
  • 数据修正

5.2.4 数据开发利用

1、数据挖掘流程一般包括五个阶段:

  • 确定分析对象
  • 数据准备
  • 数据挖掘
  • 结果评估
  • 结果应用

35、 数据服务主要包括:

  • 数据目录服务
  • 数据查询与浏览及下载服务
  • 数据分发服务

36、 可视化的表现方式可分为七类:

  • 一维数据可视化
  • 二维数据可视化
  • 三维数据可视化
  • 多维数据可视化
  • 时态数据可视化
  • 层次数据可视化
  • 网络数据可视化

37、 信息检索(Information Retrieval)的主要方法:

  • 全文检索
  • 字段检索
  • 基于内容的多媒体检索
  • 数据挖掘

38、 信息检索的常用技术包括布尔逻辑检索技术、 截词检索技术、 临近检索技术、 限定字段检索技术、限制检索技术等。

5.2.5 数据库安全

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

5.3 系统集成

5.3.1 集成基础

39、 系统集成工作在技术上需要遵循的基本原则包括:

  • 开放性
  • 结构化
  • 先进性
  • 主流化

41、 异构数据集成方法归纳起来主要有两种, 分别是过程式方法和声明式方法。

42、 代表性的软件构件标准:公共对象请求代理结构(CORBA)、COM、DCOM与COM+、 .NET、J2EE应用架构等标准。

对应用集成的技术要求大致有:

  • 具有应用间的互操作性
  • 具有分布式环境中应用的可移植性
  • 具有系统中应用分布的透明性

49、 信息安全系统工程应该吸纳安全管理的成熟规范部分, 这些安全管理包括物理安全、 计算机安全、网络安全、 通信安全、 输入/输出产品的安全、 操作系统安全、 数据库系统安全、 数据安全、 信息审计安全、 人员安全、 管理安全和辐射安全等。

常用的面向对象设计 (OOD)原则包括 :

  • 单职原则 : 设计功能单一的类。本原则与结构化方法的高内聚原则是一致的 。
  • 开闭原则 : 对扩展开放,对修改封闭。
  • 李氏替换原则: 子类可以替换父类。
  • 依赖倒置原则: 要依赖于抽象,而不是具体实现:要针对接口编程,不要针对实现编程。
  • 接口隔离原则: 使用多个专门的接口比使用单 一 的总接口要好。
  • 组合重用原则: 要尽量使用组合,而不是继承关系达到重用目的。
  • 迪米特原则(最少知识法则): 一个对象应当对其他对象有尽可能少的了解 。 本原则与结构化方法的低耦合原则是一致的。

持续交付具备的优势 主要包括:

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

数据集成 就是将驻留在不同数据源中的数据进行整合,向用户提供统一的数据视图 (一般 称为全局模式) , 使得用户能以透明的方式访问数据 。数据集成属于白盒集成

5.3.2 网络集成

计算机网络集成的 一般体系框架

5.3.3 数据集成

数据集成可以分为四个层次:

  • 基本数据集成: 面临的问题很多
  • 多级视图集成: 有助于对数据源之间的关系进行集成
  • 模式集成
  • 多粒度数据集成: 是异构数据集成中最难处理的问题

开放式数据库互联( Open Database Connectivity, ODBC) 是一种用来 在数据库系统之间存取数据的标准应用程序接口

5.3.4 软件集成

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

软件集成技术:

  • 表示集成:黑盒集成
  • 数据集成
  • 控制集成:(功能集成、应用集成、黑盒集成)灵活性更高
  • 业务流程集成:过程集成
  • 企业之间的应用集成

5.3.5 应用集成

对应用集成的技术要求大致有:

  • 具有应用间的互操作性 : 应用的互操作性提供不同系统间信息的有意义交换,即信息的 语用交换,而不仅限于语法交换和语义交换。此外,它还提供系统间功能服务的使用功 能,特别是资源的动态发现和动态类型检查 。
  • 具有分布式环境中应用的可移植性:提供应用程序在系统中迁移的潜力并且不破坏应用 所提供的或正在使用的服务 。 这种迁移包括静态的系统重构或重新安装以及动态的系统 重构。
  • 具有系统中应用分布的透明性 : 分布的透明性屏蔽了由系统的分布所带来的复杂性 。 它 使应用编程者不必关心系统是分布的还是集中的,从而可以集中精力设计具体的应用系 统,这就大大减少了应用集成编程的复杂性 。

5.4 安全工程

5.4.1 工程概述

5.4.2 安全系统

信息安全保障系统一般简称为信息安全系统,它是“信息系统”的 一个部分,用于保证 “业务应用信息系统”正常运营。

44、 信息安全三维空间:

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

45、 认证、 权限、 完整、 加密和不可否认五大要素, 也叫作“安全空间” 的五大属性。

安全服务包括:

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

安全机制包含:

  • 基础设施实体安全
  • 平台安全
  • 数据安全
  • 通信安全
  • 应用安全
  • 运行安全
  • 管理安全
  • 授权和审计安全
  • 安全防范体系

安全技术主要涉及:加密、数字签名技术、防控控制、数据完整性、认证、数据挖掘等

5.4.3 工程基础

信息安全系统工程活动离不开其他相关工程, 主要包括:硬件工程、 软件工程、 通信及网络工程、数据存储与灾备工程、 系统工程、 测试工程、 密码工程和组织信息化工程等。

5.4.4 工程体系架构

信息系统安全工程 (information Security System Engineering, ISSE) 是一门系统工程学, 它的主要 内容是确定系统和过程的安全风险 ,并且使安全风险降到最低或使其得到有效控制 。

50、 信息安全系统工程能力成熟度模型(ISSE-CMM) 是一种衡量信息安全系统工程实施能力的方法,是使用面向工程过程的一种方法。

51、 ISSE-CMM主要适用于:

  • 工程组织
  • 获取组织
  • 评估组织

52、 ISSE将信息安全系统工程实施过程分解为(保工风):

  • 工程过程
  • 风险过程
  • 保证过程

53、 公共特性的成熟度等级:

  • Level 1—非正规实施级
  • Level 2—规划和跟踪级
  • Level 3—充分定义级
  • Level 4—量化控制级
  • Level 5—持续改进级

一个有害事件由威胁、脆弱性和影响三个部分组成