《第5章-信息系统工程(合集篇)》
- 章节说明
- 1 软件工程
- 1.1 架构设计
- 1.2 需求分析
- 1.3 软件设计
- 1.4 软件实现
- [补充第三版教材内容]
- 1.5 部署交付
- 2 数据工程
- 2.1 数据建模
- 2.2 数据标准化
- 2.3 数据运维
- 2.4 数据开发利用
- 2.5 数据库安全
- 3 系统集成
- 3.1网络集成
- 3.2 数据集成
- 3.3 软件集成
- 3.4 应用集成
- 3.5 安全工程
章节说明
65%为新增内容, 预计选择题考5分,案例和论文不考;本章与第三版教材一样的内容以楷体字进行标注!
1 软件工程
1.1 架构设计
1、软件架构设计的一个核心问题是能否达到架构级的软件复用
。
2、通用软件架构:数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。
风格类型 | 解释说明 |
---|---|
数据流风格 | 批 处理整修构风格和管 道/过滤器两种风格【批管】 (21下9) |
调用/返回风格 | 主 程序/子 程序、数据抽象 和面向对象,以及层 次结构【主子抽象层面】 (19上7) |
独立构件风格 | 进程 通信和事 件驱动的系统【进程办事】 (18上7) |
虚拟机风格 | 解释 器和基于规则 的系统【解释规则】 |
仓库风格 | 数据库 系统、,黑 板系统、超 文本系统【库黑超】 |
3、在架构评估过程中,评估人员所关注的是系统的质量
属性。(17下7)
4、敏感点是一个或多个构件(和/或构件之间的关系)的特性,权衡点是影响多个质量属
性的特性,是多个质量属性的敏感点。
5、基于场景的方式主要包括:架构权衡分析法(ATAM)、软件架构分析法(SAAM)和成本 效益分析法(CBAM)
中。在架构评估中,一般采用刺激、环境和响应三方面来对场景进行描述。 刺邀是场景中解释或描述项目干系人怎样引发与系统的交互部分,环境描述的是刺激发生时的情况,响应是指系统是如何通过架构对刺激作出反应的。
6、基于场景的方式
分析软件架构对场景的支持程度,从而判断该架构对这一场景所代表的质量需求的满足程度。
1.2 需求分析
1、需求层次
包括业务需求、用户需求
和系统需求
。(18下7)
需求类型 | 解释说明 |
---|---|
业务需求 | 反映企业或客户对系统高层次的目标要求,通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门 |
用户需求 | 描述的是用户的具体目标,或用户要求系统必须能完成的任务。也就是说,用户需求描述了用户能使用系统来做些什么(19上10) |
系统需求 | 从系统的角度来说明软件的需求,包括功能需求、非功能需求和设计约束 |
2、质量功能部署(QFD)
是一种将用户要求转化成软件需求的技术,其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标,QFD
将软件需求分为三类,分别是常规需求
、期望需求
和意外需求
。(21上9)
(1)常规需求:用户认为系统应该做到的功能或性能,实现越多用户会越满意。
(2)期望需求:用户想当然认为系统应具备的功能或性能,但并不能正确描述自己想要
得到的这些功能或性能需求。如果期望需求没有得到实现,会让用户感到不满意。
(3)意外需求:也称为兴奋需求,是用户要求范围外的功能或性能(但通常是软件开发人员
很乐意赋予系统的技术特性),实现这些需求用户会更高兴,但不实现也不影响其购买的决策。
3、需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认
等。
过程 | 具体内容 |
---|---|
需求获取 | 求获取只有与用户的有效合作才能成功。常见的需求获取方法包括用户访谈、 问卷调查、采样、情节串联板、联合需求计划 等。 |
需求分析 | 1.一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性,因此,需要分析人员把杂乱无章的用户要求和期望转化为用户需求,这就悬霜条分析的工作。 2.需求分析对已经获取到的需求进行提炼、分析和审查,以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方。 3.面向对象的分析98k模型包括 用例模型 和分析模型 |
需求规格说明书的编制 | **软件需求规格则书(SRS)**是需求开发活动的产物,编制该文档的目的是使项目干系人与立团队对系统的初始规定有一个共同的理解 。 |
需求验证与确认 | 一般通过需求评审 和需求测试 工作来对需求进行验证。👉 需求评审 :对SRS进行技术评审 :二义性的或不确定性的需求,为项目干系人提供在需求问题上达成共识的方法。👉 需求测试 :及早发现问题,从而在需求开发阶段以较低的代价解决这些问题。 |
4、使用SA方法进行需求分析,其建立的模型的核心是数据字典
,围绕这个核心,有三个
层次的模型,分别是数据模型、功能模型和行为模型
(也称为状态模型)。(22上9)
模型 | 表示图形 | 表示图形的作用 |
---|---|---|
数据模型 | 实体联系图(E-R图) | 描述实体、属性,以及实体之间的关系 【实数】 |
功能模型 | 数据流图(DFD) | 从数据传递和加工的角度,利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况, 来说明系统所完成的功能 【能流】:(19下7) (20下8) |
行为模型 | 状态转换图(STD) | 通过描述系统的状态和引起系统状态转换的事件,来表示系统的行为,指出作为特定事件的结果将执行哪些动作 【形状】 |
4、UML的结构包括构造块、规则
和公共机制
三个部分
5、UML中的事物也称为建模元素,包括结构事物、行为事物
(也称动作事物)、分组事物
和注释事物
(也称注解事物)。
6、UML中的关系
(1)依赖
:是两个事物之间的语义关系,其中一个事物发生变化会影响另一个事物的语义。
(2)关联
:描述一组对象之间连接的结构关系。分为组合和聚合,都是部分和整体的关系, 其中组合事物之间关:系更强,部分和整体之间有共同的生命周期。
(3)泛化
:一般/特殊的关系,子类和父类之间的关系。继承关系是泛化关系的反关系, 也就是说,子类继承了父类,而父类则是子类的泛化
(4)实现
:是类之间的语义关系,一个类元指定了另一个类元保证执行的契约。
7、UML14 种图(18 上 27)
图形 | 描述 |
---|---|
用例图 | 描述一组用例、参与者 及它们之间的关系 。 |
类图 | 展现了一组对象、接口、协作和它们之间的关系。是最常见的图 。类图给出了系统的静态设计视图,活动类的类图给出了系统的静态进程视图 |
对象图 | 描述一组对象 及它们之间的关系。描述了在类图中所建立的事物实例的静态快照。 |
构件图 | 描述一个封装的类和它的接口、端口,以及由内嵌的构件 和连接件 构成的内部结构 |
组合结构图 | 描述结构化类(例如,构件或类)的内部结构 ,包括结构化类与系统其余部分的交互点。用于画出结构化类的内部内容 |
顺序图(序列图) | 一种交互图,交互图展现了一种交互,它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图 。顺序图是强调消息的时间次序 的交互图 |
通信图(协作图) | 一种交互图,它强调收发消息的对象或参与者的结构组织。顺序图强调的是时序 , 通信图强调的是对象之间的组织结构 |
定时图(计时图) | 一种交互图,它强调消息跨越不同对象或参与者的实际时间 ,而不仅仅只是关心消息的相对顺序(17下26) |
状态图 | 描述一个状态机 ,它由状态、转移、事件和活动组成。给出了对象的动态视图(18下27) |
活动图 | 将进程或其他计算结构展示为计算内部一步步的控制流和数据流 。活动图专注于系统敖力法视图。它对系统的功能建模和业务流程建模特别重要,并强调对象间的控制流程 |
部署图 | 描述对运行时的处理节点及在其中生存的构件的配置 。部署图给出了架构的静态部署视图 ,通常一个节点包含一个或多个部署图 |
制品图 | 描述计算机中一个系统的物理结构 |
包图 | 描述由模型本身分解而成的组织单元,以及它们之间的依赖关系 |
交互概览图 | 是活动图和顺序图的混合物。 |
8、UML5个系统视图:【记忆口诀:裸线不用进】
序 | UML系统视图 | 解释说明 |
---|---|---|
1 | 逻辑视图 | 也称为设计 视图,它表示了设计模型中在架构方面具有重要意义的部分, 即类、子系统、自和用例实现的子集(17下27) |
2 | 实现视图 | 对组成基于系统的物理代码 的文件和构件进行建模 |
3 | 部署视图 | 把构件部署到一组物理节点 上,表示软件到硬件的映射和分布结构 |
4 | 用例视图 | 是最基本的需求分析 模型 |
5 | 进程视图 | 是可执行线程 和进程 作为活动类的建模,它是逻辑视图的一次执行实例, 描述了并发与同步 结构 |
9、面向对象分析阶段的核心工作是建立系统的用例模型与分析模型
。
10、在00A方法中,构建用例模型一般需要经历四个阶段,分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型
,其中前三个阶段是必须的。
11、用例之间关系
(1)包含关系
:当可以从两个或两个以上的用例中提取公共行为时,应该使用包含关系来表示它们。
(2)扩展关系
:是如果一个用例明显地混合了两种或两种以上的不同场景,即根据情况可能发生多种分支,则可以将这个用例分为一个基本用例和一个或多个扩展用例,这样使描述可能更加清晰
(3)泛化关系
:当多个用例共同拥有一种类似的结构和行为的时候,可以将它们的共性抽象成为父用例,其他的用例作为泛化关系中的子用例。父子关系、一般和特殊关系
。
12、类之间关系有关联、依赖、泛化、聚合、组合和实现
关系 | 解释说明 |
---|---|
关联 | 提供了不同类的对象之间 的结构关系,它在一段时间内将多个类的实例连接在一起。 现的是对象实例之间的关系,而不表示两个类之间的关系。(19上23) |
依赖 | 两个类A和B,如果B的变化可能会引起A的变化,则称类A依赖于类B |
泛化 | 描述了一般事物 与该事物中的特殊种类 之间的关系,也就是父类与子类 之间的关系。 继承关系是泛化关系的反关系,子类继承了父类,而父类则是子类的泛化 |
共享聚集 | 简称为聚合关系,它表示类之间的整体与部分的关系 ,其含义是"部分”可能同时属于多个“整体“部分"与"整体”的生命周期可以不相同。例如,汽车和车轮就是聚合关系,车子坏了,车轮还可以用;车轮坏了,可以再换一个新的。 |
组合聚集 | 简称为组合关系,它也是表示类之间的整体与部分的关系 。与聚合关系的区别在于,组合关系中的“部分Ng杷属于一个“整体”,“部分”与“整体”的生命周期相同,“部分”随着“整体”的创建而创建,也随着“整体”的消亡而消亡。例:一个公司包含多个部门, 它们之间的关系就是组合关系。公司一旦倒闭,也就没有部门了。 |
实现关系 | 将说明和实现联系起来 。接口是对行为而非实现的说明,而类中则包含了实现的结构。 一个或多个类可以实现一个接口,而每个类分别实现接口中的操作。 |
1.3 软件设计
1、结构化设计SD是一种面向数据流
的方法,它以SRS和SA阶段所产生的DFD和数据字
典等文档为基础,是一个自顶向下、逐步求精
和模块化
的过程。SD方法的基本思想是将软件设
计成由相对独立且具有单一功能的模块组成的结构,分为概要设计和详细设计两个阶段;
2 、在SD中,需要遵循一个基本的原则:高内聚,低耦合
。
♦ 内聚
表示模块内部各成分之间的联系程度;
♦ 耦合
表示模块之间联系的程度。
3、面向对象设计(00D)是00A方法的延续,其基本思想包括抽象、封装
和可扩展性
。其
中可扩展性主要通过继承
和多态
来实现。(18下26)
4、设计模式是前人经验的总结,它使人们可以方便地复用成功的软件设计。设计模式包
含模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等基本要素。
(1)根据处理范围不同,设计模式可分为类模式
和对象模式
;
♦ 类模式
处理类和子类
之间的关系,这些关系通过继承建立,在编译时刻就被确定下来, 属于静态
关系;
♦ 对象模式
处理对象
之间的关系,这些关系在运行时刻变化,更具动态
性。
(2)根据目的和用途不同,设计模式分为创建型摸式、结构型模式、行为型模式。
模式 | 主要用于 | 包括的模式 |
---|---|---|
创建型模式 | 创建对象 | 工厂方法/抽象工厂/原型/单例/建造者模式 |
结构型模式 | 处理类或对象的组合 | 适配器/桥接/组合/装饰/外观/享元/代理模式 |
行为型模式 | 描述类或对象的交互以及职责的分配 | 职责链/命令/解释器/迭代器/中介者/备忘录/观察者/状态/策略/模板方法/访问者 模式 (18下8) |
1.4 软件实现
1、软件配置管理活动包括软件配置管理
计划
、软件配置标
识、软件配置控
制、软件配置状态
记录、软件配置
审计、软件发
布管理与交
付等活动
。【口诀:计时制,状态审计不符】
序 | 配置管理活动 | 解释说明 |
---|---|---|
1 | 软件配置管理计划 | 明确软件配置控制任务 |
2 | 软件配置标识 | 识别要控制的配置项 |
3 | 软件配置控制 | 管理软件生命周期中的变更 |
4 | 软件配置状态记录 | 标识、收集、维护并报告配置管理的配置状态信息 |
5 | 软件配置审计 | 独立评价 软件产品和过程是否遵从已有的规则、标准、指南、计划和流程而进行的活动 |
6 | 软件发布管理和交付 | 需要创建特定的交付版本,完成此任务的关键是软件库 |
2、软件编码就是把软件设计的结果翻译成计算机改以“理解和识别”的形式一用某种程序设计语言书写的程序。
3、软件测试的目的是验证软件是否满足软件开发合同或项目开发计划、系统/子系统设计文档、SRS、软件设计说明和软件产品说明等除的软件质量要求。通过测试发现软件缺陷,为软件产品的质量测量和评价提供依据。(19上9)
测试分类 | 静态测试 | 文档 | 检查单 |
代码 | 桌前检查、代码走查和代码审查 | ||
动态测试 | 黑盒 | 等价类划分、边界值分析等 | |
白盒 | 逻辑覆盖 |
区别:(18 上 9) (19 下 9) (21 下 11)
测试类型 | 作用阶段 | 特征 | 常用技术和方法 |
---|---|---|---|
白盒测试(结构测试) | 用于单元测试 | 考虑程序内部结构 和处理算法 | 测试的方法有控制流测试、数据流测试和程序变异测试 等最常用的技术是逻辑覆盖 ,主要的覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件/判定覆盖和路径覆盖 |
黑盒测试(功能测试) | 用于集成测试、确认测试和系统测试 | 完全不考虑(或不了解)程序的内部结构和处理算法 | 等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法等。 |
[补充第三版教材内容]
软件测试分单元测试、集成测试、确认测试、系统测试、配置项测试和回归测试等
👉 ①单元测试:也称为模块测试,测试的对象是可独立编译或汇编的程序模块、软件构件或oo软件中的类(统称为模块),其目的是检查每个模块能否正确地实现设计说明中的功能、性能、接口和其他设计约束等条件,发现模块内可能存在的各种差错。
👉 ②集成测试:目的是检查模块之间,以及模块和已集成的软件之间的接口关系,并验证已
集成的软件是否符合设计要求。
👉③确认测试:主要用于验证软件的功能、性能和其他特性是否与用户需求一致。根据用户的参与程度,通常包括以下类型:(18下10)
♦内部确认测试:主要由软件开发组织内部按照SRS进行测试。
♦Alpha测试和Beta测试:Alpha测试是由用户在开发环境下进行测试;(21上11)Beta测试是由用户在实际使用环境下进行测试。在通过Beta测试后,才能把产品发布或交付给用户。
♦ 验收测试:指针对5限石交付前以用户为主进行的测试。其测试对象为完整的、集
成的计算机系统蓝一
👉 ④系统测试:对象是完整的、集成的计算机系统,系统测试的目的是在真实系统工作环境
下,验证完整的软件配置项能否和系统正确连接,并满足系统/子系统设计文档和软件开发
合同规定的要公
👉 ⑤配置项测试:测试的对象是软件配置项,目的是检验软件配置项与SRS的一致性。
👉⑥回归测试:目的是测试软件变更之后,变更部分的正确性和对变更需求的符合性,以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。(22下8)
1.5 部署交付
1、软件开发完成后,必须部署在最终用户的正式运行环境,交付给最终用户使用。这些活动包括软件打包、安装、配置、测试、集成和更新
等。是一个持续不断
的过程
2、持续部署
阶段 | 具体内容 |
---|---|
软件部署与交付 | 软件部署与交付属于软件开发的后期活动,即通过配置、安装和激活等活动来保障软件制品的后续运行。部署技术影响着整个软件过程的运行效率和成本投入, 软件系统部署的管理代价占到整个软件管理开销的大部分。 |
持续交付 | 1.持续交付提供了一套更为完善的解决传统软件开发流程的方案,主要体现在: 👉 在需求阶段:抛弃了传统的需求文档的方式,使用便于开发人员理解的用户故事; 👉 在开发测试阶段:做到持续集成,让测试人员尽早进入项目开始测试; 👉 在运维阶段:打通开发和运维之间的通路,保持开发环境和运维环境的统一。 |
2.持续交付具备的优势主要包括: 👉 能够有效缩短提交代码到正式部署上线的时间,降低部署风险; 👉 能够自动、快速地提供反馈,及时发现和修复缺陷; 👉 让软件在整个生命周期内都处于可部署的状态; 👉 能够简化部署步骤,使软件版本更加清晰; 👉 能够让交付过程成为一种可靠的、可预期的、可视化的过程。 | |
持续部署 | 1.容器技术目前是部署中最流行的技术,常用持续部署方案Kubemetes+Docker和Matrix系统两种 |
部署层次 | 1.部署层次:首先要明确部署的目的并不是部署一个可工作的软件,而是部署一套可正常运行的环境。 |
2.完整的镜像部署包括三个环节:Build—Ship—Run。 👉 Build:将软件编译形成RPM包或者Jar包; 👉 Ship:将所需的第三方依赖和第二方插件安装到环境中; 👉 Run:在不同的地方启动整套环境。 | |
3.制作完成部署包之后,每次需要变更软件或者第三方依赖以及插件升级的时候, 不需要重新打包,直接更新部署包即可。 | |
4.不可变服务器是一种部署模式,是指除了更新和安装补丁程序以外,不对服务器进行任何更改。 | |
5.在部署原则中提到两大部署方式为蓝绿部署和金丝雀部署。 👉 蓝绿部署是指在部署的时候准备新旧两个部署版本,通过域名解析切换的方式将用户使个境切换到新版本中,当出现问题的时候,可以快速地将用户环境切切回旧版本,并对新版本进行修复和调整。 👉 金丝雀部署是指当有新版本发布的时候,先让少量用户使用新版本,并且观察购床是否存在问题。如果出现问题,就及时处理并重新发布;如果一切正常,就稳步地将新版本适配给所有的用户。 |
3、软件过程能力是组织基于软件过程、技术、资源
和人员
能力达成业务目标的综合能力。 包括治理能力、开发与交付能力、管理与支持能力、组织管理能力
等方面。
4、成熟度模型CSMM模型由4个能力域、20个能力子域、161个能力要求组成。
能力域 | 能力子域 |
---|---|
治理 | 战略与治理、目标管理 |
开发与交付 | 需求、设计、开发、测试、部署、服务、开源应用 |
管理与支持 | 项目策划、项目监控、项目结项、质量保证、风险管理、配置管理、供应商管理 |
组织管理 | 过程管理、人员能力管理、组织资源管理、过程能力管理 |
5、成熟度等级的总体特征
等级 | 结果特征 | |
---|---|---|
1级 | 初始级 | 软件过程和结果具有不确定性 |
2级 | 项目规范级 | 项目基本可按计划实现预期的结果 |
3级 | 组织改进级 | 在组织范围内能够稳定地实现预期的项目目标 |
4级 | 量化提升级 | 在组织范围内能够量化地管理和实现预期的组织和项目目标 |
5级 | 创新引领级 | 通过技术和管理的创新,实现组织业务目标的持续提升,引领行业发展 |
能力域与成熟度对应关系
2 数据工程
2.1 数据建模
1、根据模型应用目的不同,可以将数据模型划分为三类:概念
模型
、逻辑
模型
和物理
模型
。
模型 | 解释说明 |
---|---|
概念模型 | 也称信息模型,它是按用户的观点来对数据和信息建模,也就是说,把现实世界中的客观对象抽象为某一种信息结构,这种信息结构不依赖于具体的计算机系统,也不对应某个具体的DBMS.它是概念级别的模型 |
逻辑模型 | 1.目前主要的数据结构有层次模型、网状模型、关系模型、面向对象模型和对象关系模型 。其中,关系模型 成为目前好要的一种逻辑数据模型。2.关系数据模型的数据操作主要包括 查询、插入、删除 和更新数据 ,这些操作必须满足关系的完整性约束条件。3.关系的完整性约束包括三大类型: 实体完整性、参照完整性 和用户定义的完整性 。 |
物理模型 | 物理数据模型是在逻辑数据模型的基础上,考虑各种具体的技术实现因素 ,进行数据库体系结构设,真正实现数据在数据库中的存放 。物理数据模型的内容包括确定所有的表和列,定义外键用于确定表之间的关系,基于性能的需求可能进行反规范化处理等内容。物理模型的基本元素包括表、字段、视图、索引、存储过程、触发器 等,其中表、 字段和视图等元素与逻辑模型中基本元素有一定的对应关系 |
2、数据建 模过程包括数据需求分析、概念模型设计、逻辑模型设计
和物理模型设计
等过程。
数据建模过程 | 具体内容 |
---|---|
数据需求分析 | 用户需求一数据流图 |
概念模型设计 | 将需求分析得到结果抽象为概念模型的过程就是概念模型设计,其任务是确定实体和数据及其关联,建名逻辑模型,关系模式 |
逻辑模型设计 | 建立概念模型 ,其任务是确定实体和数据及其关联即E-R图 |
物理模型设计 | 将数据模型转换为真正的数据库结构,还需要针对具体的DBMS进行物理模型设计,使数据模型走向数据存储应用环节,主要问题包括命名、确定字段类型和编写必要的存储过程与触发器 等 |
2.2 数据标准化
1、数据标准化是实现数据共享的基础。使得数据简单化、结构化和标准化。
2、数据标准化的主要内容包括元数据标准化、数据元标准化、数据模式标准化、数据分类与编码标准化
和数据标准化管理
。
过程 | 解释说明 |
---|---|
元数据标准化 | 元数据是关于数据的数据。元数据被定义为提供关于信息资源或数据的一种结构化数据,是对信息资源的结构化描述。其实质是用于描述信息资源或数据的内容、 覆盖范围、质量、管理方式、数据的所有者、数据的提供方式等有关的信息。 |
数据元标准化 | 开放系统互连环境(OSIE)四个基本要素(硬件、软件、通信和数据)中的三个要素(硬件、软件和通信) |
1.数据元:是数据库、文件和数据交换的基本数据单元。数据库或文件由记录或元组等组成,而记录或元组则由数据元组成.由对象、特性和表示组成。 2.数据元提取:方法有两种:自上而下(Top-Down)和自下而上(Down-Top)提取法。对于新建系统的数据元提取,一般适用“自上而下”的提取法。 3.数据元标准 | |
数据模式标准化 | 1.本质:规范化处理,减少冗余2.数据模式的描述方式主要有图描述方法和数据字典方法。图描述方法常用的有IDEFIX方法和UML图,主要用来描述数据集中的实体和实体之间的相互关系;数据字典形式用来描述模型中的数据集、单个实体、属性的摘要信息。 |
数据分类和编码标准化 | 就是把数据分类与编码工作纳入标准化工作的领域,按标准化的要求和工作程序, 将各种数据按照科学的原则进行分类以编码,经有关方面协商一致,由主管机构批准、注册,以标准的形式发Q作为共同遵守的准则和依据,并在其相应的级别范围内宣贯和推行。 |
数据标准化管理 | 包括确定数据需求、制定数据标准、批准数据标准和实施数据标准四个阶段 |
1.确定数据需求:将产生数据需求及相关的元数据、域值等文件。 2.制定数据标准:要处理“确定数据需求”阶段提出的数据需求。如果现有的数据标准不能满足该数据需求,可以建议制定新的数据标准,也可建议修改或者封存已有数据标准。 3.批准数据标准:数据管理机构对提交的数据标准建议、现行数据标准的修改或封存建加行审查一经批准,该数据标准将扩充或修改数据模型。 4.实施数据标准:涉及在各信息系统中实施和改进已批准的数据标准。 |
2.3 数据运维
过程 | 解释说明 |
---|---|
数据存储 | 就是根据不同的应用环境,通过采取合理、安全、有效的方式将数据保存到物理介质上,并能保证对数据实施有效的访问 |
数据备份 | 1.数据备份是为了防止由于用户操作失误、系统故障等意外原因导致的数据丢失, 而将整个应用系统的数据或一部分关键数据复制到其他存储介质上的过程。 2.数据备份结构可以分为四:DAS备份结构、基于LAN的备份结构、LANFREE备份结构和SERVER-FREE备份结构。 3.常见的备份策略主要有三种:完全备份、差分备份和增量备份。 |
数据容灾 | 1.根据容灾系统保护对象的不同,容灾系统分为应用容灾和数据容灾两类。 👉应用容灾用于克服灾难对系统的影响,保证应用服务的完整、可靠和安全等一系列要求,使得用户在任何情况下都能得到正常的服务; 👉 数据容灾关注于保证用户数据的高可用性,在灾难发生时能够保证应用系统中数据尽量少丢失或不丢失,使得应用系统能不间断地运行或尽快地恢复正常运行。 2.衡量容灾系统有两个主要指标:RPO和RTO,其中RPO代表了当灾难发生时允许丢失的数据量;而RTO则代表了系统恢复的时间。 |
数据质量与评价控制 | 1.数据质量描述:数据质量可以通过数据质量元素来描述,数据质量元素分为数据质量定量元素和数据质量非定量元素。 2.数据质量评价过程 3.数据质量评价方法:直接评价法和间接评价法: 👉 直接评价法:通过将数据与内部或外部的参照信息,如理论值等进行对比。确定数据质量。 👉 间接评价法利用数据相关信息,如数据只对数据源、采集方法等的描述推断或评估数据质量。 4.数据质量控制:分成前期控制和后期控制两个大部分。 👉前期控制包括数据录入前的质量控制、数据录入过程中的实时质量控制; 👉 后期控制为数据录入完成后的后处理质量控制与评价。 依据建库流程可分为:前期控制、过程控制、系统检测、精度评价 5,数据清理:三个步骤:数据分析一数据检测一数据修正 👉 数据分析:是指从数据中发现控制数据的一般规则,比如字段域、业务规则等, 通过对数据的分析,定义出数据清理的规则,并选择合适的清理算法。 👉 数据检测:是指根据预定义的清理规则及相关数据清理算法,检测数据是否正确,比如是否满足字段域业务规则等,或检测记录是否重复。 👉 数据修正:是指手工或自动地修正检测到的错误数据或重复的记录 |
2.4 数据开发利用
1、数据开发利用包括数据集成、数据挖掘和数据服务(目录服务、查询服务、浏览和下 载服务、数据分发服务)、数据可视化、信息检索
等。
过程 | 解释说明 |
---|---|
数据集成 | 1.将驻留在不同数据源中的数据进行整合,向用户提供统一的数据视图,使得用户能以透明的方式访问数据2.数据集成的目标就是充分利用已有数据,在尽量保持其自治性的前提下,维护数据源整体上的一致性,提高数据共享利用效率。实现数据集成的系统称为数据集成系统,它为用户提供了统一的数据源访问接口,用于执行用户对数据源的访问请求。 |
数据挖掘 | 1.从大量数据中提取或“挖掘”知识,即从大量的、不完全的、有噪声的、模糊的、 随机的实际数据中,提取隐含在其中的、人们不知道的、却是潜在有用的知识。 2.数据挖掘主要任务: 数据总结、关联分析、分类和预测、聚类分析和孤立点分析 。3.数据挖掘流程: 确定分析对象、数据准备、数据挖掘、结果评估与结果应用 五阶段 |
数据服务 | 数据服务主要包括数据且受服务、数据查询与浏览及下载服务、数据分发服务。 1 . 数据目录服务 :建立目录方便检索服务。2. 数据查询与浏览及下载服务 :是网上数据共享服务的重要方式,用户使用数据的方式有查询数据和下载数据两种。3. 数据分发服务 :是指数据的生产者通过各种方式将数据传送到用户的过程。 |
数据可视化 | 1.指将抽象的事物或过程变成图形图像的表示方法 2.可视化的表现方式分为七类:一维数据可视化、二维数据可视化、三维数据可视化、 多维数据可视化、时态数据可视化、层次数据可视化和网络数据可视化。 |
信息检索 | 1.信息检索的方法:全文检索、字段检索、基于内容的多媒体检索、数据挖掘 。2.信息检索的常用技术包括 布尔逻辑检索技术、截词检索技术、临近检索技术、限定字段检索技术、限制检索技术 等。 |
2.5 数据库安全
1、数据库安全对策
安全对策 | 要点 |
---|---|
防止非法的数据访问 | 数据库管理系统必须根据用户或应用的授权 来检查访问请求,以保证仅允许授权的用户访问数据库 |
防止推导 | 指的是用户通过授权访问的数据,经过推导得出机密信息,而按照安全策略, 该用户是无权访问此机密信息的 |
保证数据库的完整性 | 是保护数据库不受非授权修改 ,以及不会因为病毒、系统中的错误等导致的存储数据破坏。这种保护通过访问控制、备份/恢复以及一些专用的安全机制共同实现 |
保证数据的操作完整性 | 定位于在并发事务中保证数据库中数据的逻辑一致性 。由并发管理器子系统负责 |
保证数据的语义完整性 | 在修改数据时,保证新值在一定范围内符合逻辑上的完整性。对数据值的约束通过完整性约束来描述。 |
审计和日志 | 审计和日志是有效的威慑和事后追查、分析工具 |
标识和认证 | 标识和认证是授权、审计等的前提条件是第一道安全防线 |
机密数据管理 | 对于同时保存机密和公开数据的数据库而言,访问控制主要保证机密数据的保密性,仅允许授权用户的访问。这些用户被赋予对机密数据进行一系列操作的权限,并且禁止传播这些权限。 |
多级保护 | 将数据划分不同保密级别,户只能访问拥有的权限所对应级别的数据 |
限界 | 限界的意义在于防止程序之间出现非授权的信息传递 |
2、数据库安全机制包括用户的身份认证、存取控制、数据库加密、数据审计、推理控制
等内容。
3 系统集成
3.1网络集成
安全对策 | 要点 |
---|---|
传输子系统 | 1.常用的无线 传输介质主要包括无线电波、微波、红外线 等2.常用的 有线 传输介质主要包括双绞线、同轴电缆、光纤 等 |
交换子系统 | 网络按所覆盖的区域可分为局域网、城域网 和广域网 ,由此网络交换也可以分为局域网交换技术、城域网交换技术和广域网交换技术。 |
3.2 数据集成
1、数据集成是将参与数据库的有关信息在逻辑上集成为一个属书异构分布式数据库的全局概念模式,以达到信息共享的目的。数据集成可以分为基本数据集成、多级视图集成、模式集成
和多粒度数据集成
四个层次。
集成类型 | 要点 |
---|---|
基本数据集成 | 由于同一业务实体存在于多个系统源中,并且没有明确的办法确认这些实体是同一实体时,就会产生这类问题。通用标识符问题 是数据集成时遇到的最难的问题之一。 处理该问题的办法包括: 🫱 隔离 :保证实体的每次出现都指派一个唯一标识符。🫱 调和 :确认哪些实体是相同的,并且将该实体的各次出现合并起来。 |
多级视图集成 | 多级视图机制有助于对数据源之间的关系进行集成: 🫱 底层数据 表示方式为局部模型的局部格式 ,如关系和文件;中间数据 表示为公共模式格式,如扩展关系模型 或对象模型;高级数据 表示为综合模型格式 。 🫱 视图的集成化过程 为两级映射 :①数据从局部数据库中 ,经过数据翻译、转换并集成为符合公共模型格式的中间视图;②进行语义冲突消除、数据集成和数据导出处理 ,将中间视图集成为综合视图 |
模式集成 | 决数据库的冲突比如命名、结构等。 |
多粒度数据集成 | 数据综合(或数据抽象)指由高精度数据经过抽象形成精度较低但是粒度较大的数据。其作用过程为从多个较高精度的局部数据中,获得较低精度的全局数据。在这个过程中,要对各局域中的数据进行综合,提取其主要特征。 数据综合集成的过程是 特征提取和归并 的过程。数据细化指通过由一定精度的数据获取精度较高的数据,实现该过程的主要途径有:时空转换,相关分析或者由综合中数据变动的记录进行恢复。数据集成是最终实现数据共享和辅助决策的基础。 |
2、异构数据集成
集成类型 | 要点 |
---|---|
异构数据集成的方法 | 过程式方法和声明式方法 |
开放数据库互联标准 | |
基于XML的数据交换标准 | |
基于JSON的数据交换格式 | 一种轻量级的交换方式 |
3.3 软件集成
1、软件构件标准:公共对象请求代理结构(CORBA)、COM、DCOM与COM+、.NET、 J2EE应用架构
等标准。
类型 | 要点 |
---|---|
CORBA | OMG的目的则是为宁将对象和分布式系统技术集成为一个可相互操作的统一结构,此结构既支持现有的平台也将支持未来的平台集成 |
COM | COM技术要达到的基本目标是:即使对象是由不同的开发人员用不同的编程语言实现的,在开发软件系统时,仍能够有效地利用已经存在于其他已有软件系统中的对象;同时,也要使当前所开发的对象便于今后开发其他软件系统时进行重用。 |
DCOM 与COM+ | 1 .DCOM作为COM的扩展,不仅继承了 COM优点,而且针对分布环境还提供了一些新的特性,如位置透明性、网络安全性、跨平台调用等。 2.COM+为COM的 新发展或COM更高层次上的应用 ,其底层结构仍然以COM为基础,几乎包容了 COM的所有内容 。COM+倡导了一种新的概念,它把COM组件软件提升到应用层而不再是底层的软件结构,通过操作系统的各种支持,使组件对象模型建立在应用层上,把所有组件的底层细节留给操作系统。因此,COM+与操作系统的结合更加紧密。 |
.NET | .NET开发框架在通用语言运行环境基础上,给开发人员提供了完善的基础类库、 数据库访问技术及网络开发技术,开发者可以使用多种语言快速构建网络应用 |
J2EE | J2EE为搭建具有可伸缩性、灵活性、易维护性的组织系统提供了良好的机制。J2EE的体系结构可以分为客户端层、服务器端组件层、EJB层和信息系统层 。 |
3.4 应用集成
1、应用集成
或组织应用集成(EAI)
是指将独立的软件应用连接起来,实现协同工作。对
应用集成的技术要求大致有:
(1)具有应用间的互操作性
:应用的互操作性提供不同系统间信息的有意义交换,即信息
的语用交换,而不仅限于语法交换和语义交换。此外,它还提供系统间功能服务的使用功能, 特别是资源的动态发现和动态类型检查。
(2)具有分布式环境中应用的可移植性
提供应用程序在系统中迁移的潜力并且不破坏应用所提供的或正在使用的服务。这种迁移包括静态的系统重构或重新安装以及动态的系统重构。
(3)具有系统中应用分布的透明性
:分布的透明性屏蔽了由系统的分布所带来的复杂性。 它使应用编程者不必关心系统是斗布的还是集中的,从而可以集中精力设计具体的应用系统, 这就大大减少了应用集成编程的复杂性。
2、可以帮助协调连接各种应用的组件有:
(1)应用编程接刊(API)
:API是定义不同软件交互方式的程序和规则,可以支持应用之间相互通信。API利用特定的数据结构,帮助开发人员快速访问其他应用的功能。
(2)事件驱动型操作
:当触发器(即事件)启动一个程序或一组操作时,系统就会执行事件驱动型操作。
(3)数据映射
:将数据从一个系统映射到另一个系统,可以定义数据的交换方式,从而简化后续的数据导出、分组或分析工作。
3.5 安全工程
1、信息安全系统三维空间包括安全机制、网络参考模型和安全服务
(22下64)
(1) X轴
是’‘安全机制
”。安全机制可以理解为提供某些安全服务,利用各种安全技术和
技巧,所形成的一个较为完善的结构体系。
(2) Y轴
是’‘OSI网络参考模型
”。
(3) Z轴
是’'安全服务
”。
由X、Y、Z三个轴形成的信息安全系统三维空间就是信息系统的“安全空间: 随着网络的逐层扩展,这个空间不仅范围逐步加大,安全的内涵也就更丰富,达到具有认证、权限、完整、 加密和不可否认
五大要素,也叫作“安全空间”的五大属性。
2、安全机制包含基础设施实体安全、平台安全、数据安全、通信安全、应用安全、运行 安全、管理安全、授权和审计安全、安全防范体系
等。
3、安全服务包括对等实体认证服务、数据保密服务、数据完整性服务、数据源点认证服务、禁止否认服务和犯罪证据提供服务
等。
(1)对等实体认证服务:用于两个开放系统同等层中的实体建立链接或数据传输时,对
对方实体的合法性、真实性进行确认,以防假冒。
(2)数据保密服务:包括多种保密服务,为了防止网络中各系统之间的数据被截获或被
非法存取而泄密,提供密码加密保护。数据保密服务可提供链接方式和无链接方式两种数据保密,同时也可对用户可选字段的数据进行保护。
(3)数据完整性服务:用以防止非法实体对交换数据的修改、插入、删除以及在数据交
换过程中的数据丢失。
(4)数据源点认证服务:用于确保数据发自真正的源点,防止假冒。
(5)禁止否认服务:用以防止发送方在发送数据后否认自己发送过此数据,接收方在收到数
据后否认自己收到过此数据或伪造接收数据,由两种服务组成:不得否认发送和不得否认接收。
(6)犯罪证据提供服务:指为违反国内外法律法规的行为或活动,提供各类数字证据、 信息线索等。
4、安全技术主要涉及加密、数字签名技术、防控控制、数据完整性、认证、数据挖掘等。
5、信息安全系统的建设主要包括:硬件工程、软件工程、通信及网络工程、数据存储与灾备工程、系统工程、测试工程、密码工程和组织信息化工程
等。
6、信息安全系统建设是遵从组织所制定的安全策略进行的。而安全策略由组织和组织的客户和服务对象、集成商、安全产品开发者、密码研制单位、独立评估者和其他相关组织共同协
商建立。因此信息安全系统工程活动必须要与其他外部实体进行协调。
7、信息安全系统工程应该吸纳被管理的成熟规范部分
,这些安全管理包括物理安全、 计算机安全、网络安全、通信安全、输入/输出产品的安全、操作系统安全、数据库系统安全、 数据安全、信息审计安全、人用套、管理安全和辐射安全等。
8、信息安全系统工程在/累熟度模型(ISSE-CMM)是一种衡量信息安全系统工程实施能 力
的方法,是使用面向工程过程
的一种方法。(22上63)
9、ISSE-CMM主要灌用于工程
组织
、获取
组织
和评估
组织
。
工程过程 | 包含 |
---|---|
工程组织 | 系统集成商、应用开发商、产品提供商和服务提供商 |
获取组织 | 采购系统、产品以及从外部/内部资源和最终用户 |
评估组织 | 认证组织、系统授权组织、系统和产品评估组织 |
11、ISSE将信息安全系统工程实施过程分解为:工程
过程
、风险
过程
和保证
过程
。(21下63)
12、信息安全系统工程能力成熟度模型,下表熟悉看看就好!
级别 | 公共特性 |
---|---|
Level 1—非正规实施级 | 一执行基本实施 |
Level 2—规划和跟踪级 | 规划执行、规范化执行、验证执行、跟踪执行 |
Level 3—充分定义级 | 定义标准化过程、执行已定义的过程、协调安全实施(21上65) |
Level 4—量化控制级 | 建立可测度的质量目标、对执行情况实施客观管理 |
Leve I 5—持续改进级 | 改进组织能力、改进过程的效能 |