Channy's blog

//Description： 记录系统架构中的一些概念和方法，备考软考系统架构设计师。主要参考书籍《系统架构设计师》（2009，2022）。整个笔记共分两部分：第一部分为知识点总结，第二部分为笔记及经验。

[toc]

系统架构设计师真题

综合知识

第1章 绪论

1.1 系统架构概述

架构分析常用的方法有：软件架构分析方法SAAM、架构权衡分析法ATAM、成本效益分析法CBAM、基于场景的架构再工程SBAR、架构层次的软件可维护性预测ALPSM、软件架构评估模型SAEM等, 架构设计是指生成一个满足用户需求的软件架构过程。 架构设计常用的方法有：从工件描述中提取架构描述的工件驱动(artifact-drnven)方法:从用例导出架构抽象的用例驱动(use case-driven);从模式导出架构抽象的模式驱动(paterm-driven)方法:从领域模型导出架构抽象的域驱动(domain-driven)方法以及从设计过程中获得架构质量属性需求的属性驱动设计(attribute-driven design)方法等。 架构测试着重于仿真系统模型、解决架构层的主要问题。由于测试的抽象层次不同,架构测试策略分为单元、子系统、集成和验收测试等阶段的测试策略。测试方法主要包括架构测试覆盖方法、组件设计正确性验证方法和基于CHAM的架构动态语义验证方法等。

通常软件开发模型可分为三种：以软件需求完全确认为前提的瀑布模型;在软件开发初期只能提供基本需求为前提的渐进式开发模型(如螺旋模型等);以形式化开发方法为基础的变换模型。

1.1.2 软件架构的常用分类及建模方法(论)

软件架构的常用分类：

比较典型的架构模型包括分层架构、事件驱动架构、微核架构、微服务架构和云架构等五类。

系统架构的常用建模方法：

架构师在进行软件架构设计时,必须掌握软件架构的表示方法,即如何对软件架构建模。根据建模的侧重点的不同,可以将软件架构的模型分成4种:结构模型、框架模型、动态模型和过程模型。

机器语言的指令格式：

机器语言指令是一种二进制代码,由操作码和操作数两部分组成。

UML

UML中有4种关系:依赖、关联、泛化和实现。

  1. 依赖是两个事物间的语义关系,其中一个事物(独立事物)发生变化会影响另一个事物(依赖事物)的语义。在图形上,把一个依赖画成一条可能有方向的虚线,如图2-29所示。
  2. 关联是一种结构关系,它描述了一组链,链是对象之间的连接。聚集是一种特殊类型的关联,它描述了整体和部分间的结构关系。关联和聚集的图形化表示如图2-30和图2-31所示。 在关联上可以标注重复度和角色。
  3. 泛化是一种特殊/一般关系,特殊元素(子元素)的对象可替代一般元素(父元素)的对象。用这种方法,子元素共享了父元素的结构和行为。在图形上,把一个泛化关系画成一条带有空心箭头的实线,它指向父元素,如图2-32所示。
  4. 实现是类元之间的语义关系,其中一个类元指定了由另一个类元保证执行的契约。在两种情况下会使用实现关系:一种是在接口和实现它们的类或构件之间:另一种是在用例和实现它们的协作之间。在图形上,把一个实现关系画成一条带有空心箭头的虚线,如图2-33所示。 按照图本身具有的特点,可以把图形划分为5类视图,分别是用例视图、逻辑视图、进程视图、实现视图和部署视图,其中的用例视图居于中心地位。 按照软件工程“自项向下、逐步求精”的原则,软件生命周期可分为可行性分析、需求分析、体系结构设计、详细设计、编码和测试发布6个阶段,形式化方法贯穿软件工程整个生命周期。

    2.7 多媒体

    视音频压缩方法目前,视音频压缩方法有上百种,这些方法总体上可归类为有损(Lossy)压缩和无损(Losless)压缩两类。无损压缩也即压缩前和解压缩后的数据完全一致。多数的无损压缩都采用RLE行程编码算法。而有损压缩意味着解压缩后的数据与压缩前的数据不一致,在压缩的过程中要丢失一些人眼和人耳不敏感的图像或音频信息,这些丢失的信息是不可恢复的。无损压缩常见的格式有WAV、 PCM、 TTA、FLAC、AU、APE、TAK和WavPack (WV)等;有损压缩常见的格式有MP3、Windows Media Audio (WMA)、OggVorbis (OGG)等。

    2.8 系统工程

    系统工程是运用系统方法,对系统进行规划、研究、设计、制造、试验和使用的组织管理技术。 系统之系统(System of System,SoS)适用于其系统元素本身也是系统的情况。这些系统之系统带来了大规模跨学科问题,涉及多重、混合和分布式的系统。这些部件系统的互操作集台通常能产生单个系统无法单独达成的结果。

    2.8.4 基于模型的系统工程

    基于模型的系统工程(Model-Based Systems Engineering, MBSE) MBSE的三大支柱分别是建模语言、建模工具和建模思路。

    2.9 系统性能

    SAr_加速比.png 1.基准测试程序 大多数情况下,为测试新系统的性能,用户必须依靠评价程序来评价机器的性能。下面列出了4种评价程序,它们评测的准确程度依次递减:真实的程序、核心程序、小型基准程序和合成基准程序。 把应用程序中用得最多、最频繁的那部分核心程序作为评价计算机性能的标准程序,称为基准测试程序(benchmark)。基准测试程序有整数测试程序Dhrystone、浮点测试程序Linpack、Whetstone基准测试程序、SPEC基准测试程序和TPC基准程序。

    第3章 信息系统基础知识

    3.1 信息系统概述

    一般来说,信息系统的生命周期分为4个阶段,即产生阶段、开发阶段、运行阶段和消亡阶段。 信息系统的开发阶段是信息系统生命周期中最重要和关键的阶段。该阶段又可分为5个阶段,即,总体规划、系统分析、系统设计、系统实施和系统验收阶段。

    3.1.6 信息系统开发方法

    1.结构化方法 结构化方法是由结构化系统分析和设计组成的一种信息系统开发方法,是目前最成熟、应用最广泛的信息系统开发方法之一。它假定被开发的系统是一个结构化的系统。 2.原型法 原型法是一种根据用户需求,利用系统开发工具,快速地建立一个系统模型展示给用户, 在此基础上与用户交流,最终实现用户需求的信息系统快速开发的方法。 3.面向对象方法 面向对象方法是对客观世界的一种看法,它是把客观世界从概念上看成一个由相互配合、协作的对象所组成的系统。信息系统开发的面向对象方法的兴起是信息系统发展的必然趋势。 数据处理包括数据与处理两部分。 4.面向服务的方法 面向对象的应用构建在类和对象之上,随后发展起来的建模技术将相关对象按照业务功能进行分组,就形成了构件的概念。对于跨构件的功能调用,则采用接口的形式暴露出来。进一步将接口的定义与实现进行解耦,则催生了服务和面向服务的开发方法。

    3.2 业务处理系统(TPS)

    数据处理TPS中常见的数据处理方式有两种,一种是批处理方式;另一种是联机事务处理方式。

    3.3 管理信息系统(MIS)

    3.4 决策支持系统(DSS)(论)

    3.4.3 决策支持系统的特点

    (1)决策支持系统面向决策者,系统在开发中遵循的需求和操作是设计系统的依据和原则。 系统的收集、存储和输出的一切信息,都是为决策者服务。 (2)决策支持系统支持对半结构化问题的决策。半结构化问题的复杂性致使传统的计算机信息系统,如电子数据处理系统、管理信息系统都难以解决,而决策支持系统则可以辅助决策者对决策信息过程和方案进行较系统且全面的分析。 (3)决策支持系统的作用是辅助决策者、支持决策者。由于决策过程的复杂性和决策过程中的重要作用,系统不可能取代人而做出决策。在整个决策过程中系统不可能也不应该提供答案,也不应该强加给决策者预先规定的决策顺序。 (4)决策支持系统体现决策过程的动态性。用户或用户通过模型,根据决策层次、决策环境、问题理解、知识积累等多方面变化的情况来动态地确定问题的解答,并在决策的动态运行过程中完善和调整系统。 (5)决策支持系统提倡交互式处理。通过人、机对话的方式将决策人的经验、观念和判断纳入系统,进而将人们主观的、经验的判断与客观的信息反映相结合,最后确定决策方案。

    3.4.4 决策支持系统的组成

  5. 数据的重组和确认
  6. 数据字典的建立
  7. 数据挖掘和智能体
  8. 模型建立

    3.5 专家系统(ES)

    3.6办公自动化系统OAS

    3.7 企业资源规划(ERP)

    ERP中的企业资源包括企业的“三流”资源,即物流资源、资金流资源和信息流资源。 ERP实际上就是对这“三流”资源进行全面集成管理的管理信息系统。

    3.8 典型信息系统架构模型

    企业战略教据模型分为数据库模型和数据仓库模型,数据库模型用来描述日常事务处理中数据及其关系:数据仑库模型则描述企业高层管理决策者所需信息及其关系。在企业信息化过程中,数据库模型是基础,一个好的数据库模型应该客观地反映企业生产经营的内在联系。数据库是办公自动化、计算机辅助管理系统、开发与设计自动化、生产过程自动化、lntranet的基础和环境。 新的方法。

几种常用的企业信息化方法

(1) 业务流程重构方法。企业业务流程重构的中心思想是,在信息技术和网络技术迅猛发展的时代,企业必须重新审视企业的生产经营过程,利用信息技术和网络技术,对企业的组织结构和工作方法进行“彻底的、根本性的”重新设计,以适应当今市场发展和信息社会的需求。 (2) 核心业务应用方法。任何一家企业,要想在市场竞争的环境中生存发展,都必须有自己的核心业务,否则,必然会被市场所淘汰。当然,不同的企业,其核心业务是不同的。比如一个石油生产企业,原油的勘探开发生产就是它的核心业务。围绕核心业务应用计算机技术和网络技术是很多企业信息化成功的秘诀。 (3) 信息系统建设方法。对大多数企业来说,建设信息系统是企业信息化的重点和关键。 因此,信息系统建设成了最具普遍意义的企业信息化方法。 (4)主题数据库方法。主题数据库就是面向企业业务主题的数据库,也就是面向企业的核心业务的数据库。有些企业,特别是在业务数量浩繁,流程错综复杂的大型企业里,建设覆盖整个企业的信息系统往往很难成功。但是,各个部门的局部开发和应用又有很大弊端,会造成系统分割严重,形成许多“信息孤岛”,造成大量的无效或低效投资。在这样的企业里,应用主题数据库方法推进企业信息化无疑是一个投入少、效益好的方法。 (5)资源管理方法。计算机技术和网络技术的应用为企业资源管理提供了强大的能力。目前,; 流行的企业信息化的资源管理方法有很多,最常见的有企业资源计划(Entermrise Resource Planning,ERP)、供应链管理(Supply Chain Management,SCM)等。 (6)人力资本投资方法。人力资本的概念是经济学理论发展的产物。人力资本与人力资源的主要区别是人力资本理论把一部分企业的优秀员工看作是一种资本,能够取得投资收益。人力资本投资方法特别适用于那些依靠智力和知识而生存的企业,例如,各种咨询服务、软件开发等企业,

第4章 信息安全技术基础知识

4.1 信息安全基础知识

信息安全包括5个基本要素:机密性、完整性、可用性、可控性与可审查性 (1)机密性:确保信息不暴露给未授权的实体或进程。 (2)完整性:只有得到允许的人才能修改数据,并且能够判别出数据是否已被篡改。 (3)可用性:得到授权的实体在需要时可访问数据,即攻击者不能占用所有的资源而阻碍授权者的工作。 (4)可控性:可以控制授权范围内的信息流向及行为方式。 (5)可审查性:对出现的信息安全问题提供调查的依据和手段。 信息安全的范围包括:设备安全、数据安全、内容安全和行为安全。

4.2 信息系统安全的作用与意义

4.3 信息安全系统的组成框架

信息系统安全系统框架通常由技术体系、组织机构体系和管理体系共同构建。 从实现技术上来看,信息安全系统涉及基础安全设备、计算机网络安全、操作系统安全、数据库安全、终端设备安全等多方面技术。 管理是信息系统安全的灵魂。信息系统安全的管理体系由法律管理、制度管理和培训管理3个部分组成。所谓“三分技术,七分管理”。 (1)法律管理是根据相关的国家法律、法规对信息系统主体及其与外界关联行为的规范和约束。 (2)制度管理是信息系统内部依据系统必要的国家、团体的安全需求制定的一系列内部规章制度 (3)培训管理是确保信息系统安全的前提

4.4 信息加解密技术

数据字典(Data Dictionary)

是一种用户可以访问的记录数据库和应用程序元数据的目录。 数据字典是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑等进行定义和描述, 其目的是对数据流程图中的各个元素做出详细的说明。简而言之,数据字典是描述数据的信息集合,是对系统中使用的所有数据元素定义的集合。

软件质量保证

(论) 软件质量保证(Software Quality Assurance, SQA)是建立一套有计划,有系统的方法,来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。 软件质量保证的关注点集中在于一开始就避免缺陷的产生。质量保证的主要目标是: (1)事前预防工作,例如,着重于缺陷预防而不是缺陷检查。 (2)尽量在刚刚引入缺陷时即将其捕获,而不是让缺陷扩散到下一个阶段。 (3)作用于过程而不是最终产品,因此它有可能会带来广泛的影响与巨大的收益。 (4)贯穿于所有的活动之中,而不是只集中于一点。 软件质量保证的主要任务是以下3个方面 (1)SQA审计与评审。SQA审计包括对软件工作产品、软件工具和设备的审计,评价这几项内容是否符合组织规定的标准。SQA评审的主要任务是保证软件工作组的活动与预定的软件过程一致,确保软件过程在软件产品的生产中得到遵循。 (2)SQA报告。SQA人员应记录工作的结果,并写入到报告之中,发布给相关的人员。 SQA报告的发布应遵循三条原则:SQA和高级管理者之间应有直接沟通的渠道:SQA报告必须发布给软件工程组,但不必发布给项目管理人员;在可能的情况下向关心软件质量的人发布SOA报告。 (3)处理不符合问题。这是SQA的一个重要的任务,SQA人员要对工作过程中发现的问题进行处理及时向有关人员及高级管理者反映。

第6章 数据库设计基础知识

6.1 数据库基本概念

6.1.2 数据模型

数据库的基础结构是数据模型,是用来描述数据的一组概念和定义。数据模型的三要素是数据结构、数据操作和数据的约束条件。 SAr_ 数据库系统体系结构.png

6.2 关系数据库

  1. 函数依赖 数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系,是现实世界属性间联系和约束的抽象,是数据内在的性质,是语义的体现。函数依赖则是一种最重要、最基本的数据依赖。
  2. 关系的完整性约束 关系的完整性约束共分为3类:实体完整性、参照完整性(也称引用完整性)和用户定义完整性 (1)实体完整性(Entity lntegrity)。实体完整性规则要求每个数据表都必须有主键,而作为主键的所有字段,其属性必须是唯一且非空值。 (2)参照完整性(Referential lntegrity)。现实世界中的实体之间往往存在某种联系,在关系模型中实体及实体间的联系是用关系来描述的,这样自然就存在着关系与关系间的引用。 (3)用户定义完整性(User Defined lntegrity)。就是针对某一具体的关系数据库的约束条件,反映某一具体应用所涉及的数据必须满足的语义要求,由应用的环境决定。

    6.3 数据库设计

    数据库设计(Database Design)属于系统设计的范畴。通常把使用数据库的系统统称为数据库应用系统,把对数据库应用系统的设计简称为数据库设计。目前主流的数据库系统多数为关系数据库系统,所以本节的论述基本是关系数据库的设计。 (1)用户需求分析。数据库设计人员采用一定的辅助工具对应用对象的功能、性能、限制等要求进行科学的分析。 (2)概念结构设计。概念结构设计是对信息分析和定义,如视图模型化、视图分析和汇总。 对应用对象精确地抽象、概括而形成独立于计算机系统的企业信息模型。描述概念模型的较理想的工具是E-R图。 (3)逻辑结构设计。将抽象的概念模型转化为与选用的DBMS产品所支持的数据模型相符合的逻辑模型,它是物理结构设计的基础。包括模式初始设计、子模式设计、应用程序设计、模式评价以及模式求精, (4)物理结构设计。是逻辑模型在计算机中的具体实现方案。 (5)数据库实施阶段。数据库设计人员根据逻辑设计和物理设计阶段的结果建立数据库, 编制与调试应用程序,组织数据入库,并进行试运行。 (6)数据库运行和维护阶段。数据库应用系统经过试运行即可投入运行,但该阶段需要不断地对系统进行评价、调整与修改。

    6.3.2 数据需求分析

    分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析(Strnuctured Analysis,SA)方法从最上层的系统组织机构入手,采用逐层分解的方式分析系统,并把每一层用数据流图和数据字典描述。 (1) 信息要求 (2)处理要求。 (3)系统要求

    6.4 应用程序与数据库的交互

    6.5 NoSQL数据库(论)

    一般可以将NoSOL数据库分为以下4种类型。

  3. 列式存储数据库
  4. 键值对存储数据库
  5. 文档型数据库
  6. 图数据库

目前业界对于NoSOL开没有一个明确的范围和定又,但是它们普遍存在下面一些共同特征:

  1. 易扩展:去掉了关系数据库的关系型特性。数据之间无关系,这样就非常容易扩展。
  2. 大数据量,高性能:NoSQL数据库都具有非常高的读写性能,尤其在大数据量下。这得益于它的无关系性,数据库的结构简单。
  3. 灵活的数据模型:NoSQL无须事先为要存储的数据建立字段,随时可以存储自定义的数据格式,
  4. 高可用:NoSOL在不太影响性能的情况下, 就可以方便地实现高可用的架构,有些产品通过复制模型也能实现高可用。

    6.5.2 体系框架

    NoSOL整体框架分为4层,由下至上分为数据持久层(Data Persistence)、数据分布层(Data Distribution Model)、数据逻辑模型层(Data Logical Model)和接口层(Interface),层次之间相辅相成,协调工作。 ***

    第7章 系统架构设计基础知识

    7.1 软件架构概念

    体系结构描述语言(Architecture Description Language, ADL)

    7.2 基于架构的软件开发方法(论)

    基于体系结构的软件设计(Architecture-Based Software Design,ABSD) SAr_体系结构开发模型.png ABSD方法有3个基础。第1个基础是功能的分解。在功能分解中,ABSD方法使用己有的基于模块的内聚和耦合技术。第2个基础是通过选择体系结构风格来实现质量和商业需求。 第3个基础是软件模板的使用,软件模板利用了一些软件系统的结构。

  5. 视角与视图 考虑体系结构时,要从不同的视角(Perspective)来观察对架构的描述,这需要软件设计师考虑体系结构的不同属性。例如,展示功能组织的静态视角能判断质量特性,展示并发行为的动态视角能判断系统行为特性,因此,选择的特定视角或视图(如逻辑视图、进程视图、实现视图和配置视图)可以全方位的考虑体系结构设计。使用逻辑视图来记录设计元素的功能和概念接口,设计元素的功能定义了它本身在系统中的角色,这些角色包括功能、性能等。
  6. 用例和质量场景 用例已经成为推测系统在一个具体设置中的行为的重要技术,用例被用在很多不同的场合, 用例是系统的一个给予用户一个结果值的功能点,用例用来捕获功能需求。 在使用用例捕获功能需求的同时,人们通过定义特定场景来捕获质量需求,并称这些场景为质量场景。这样一来,在一般的软件开发过程中,人们使用质量场景捕获变更、性能、可靠性和交互性,分别称之为变更场景、性能场景、可靠性场景和交互性场景。质量场景必须包括预期的和非预期的场景。

    7.2.9 体系结构的演化

    体系结构演化是使用系统演化步骤去修改应用,以满足新的需求。主要包括以下6个步骤。 1.需求变化归类首先必须对用户需求的变化进行归类,使变化的需求与己有构件对应。对找不到对应构件的变动,也要做好标记,在后续工作中,将创建新的构件,以对应这部分变化的需求。 2.制订体系结构演化计划在改变原有结构之前,开发组织必须制订一个周密的体系结构演化计划,作为后续演化开发工作的指南。 3.修改、增加或删除构件在演化计划的基础上,开发人员可根据在第1步得到的需求变动的归类情况,决定是否修改或删除存在的构件、增加新构件。最后,对修改和增加的构件进行功能性测试。 4.更新构件的相互作用随着构件的增加、删除和修改,构件之间的控制流必须得到更新。 5.构件组装与测试通过组装支持工具把这些构件的实现体组装起来,完成整个软件系统的连接与合成,形成新的体系结构。然后对组装后的系统整体功能和性能进行测试。 6.技术评审e 对以上步骤进行确认,进行技术评审。评审组装后的体系结构是否反映需求变动、符合用户需求。如果不符合,则需要在第2到第6步之间进行迭代。 在原来系统上所做的所有修改必须集成到原来的体系结构中,完成一次演化过程。

    7.3 软件架构风格

    7.3.1 软件架构风格概述

    软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族,即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的。体系结构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件体系结构风格的研究和实践促进对设计的重用,一些经过实践证实的解决方案也可以可靠地用于解决新的问题。

    7.3.2 数据流体系结构风格

    • 批处理
    • 管道-过滤器

      7.3.3 调用返回体系结构风格

      调用/返回风格是指在系统中采用了调用与返回机制。 调用/返回体系结构风格主要包括主程序/子程序风格、面向对象风格、层次型风格以及客户端/服务器风格。

    • 主程序/子程序
    • 面向对象
    • 层次型
    • 客户端/服务器

      7.3.4 以数据为中心的体系结构风格

    • 仓库
    • 黑板

      7.3.5 虚拟机体系结构风格

    • 解释器
    • 规则系统

      7.3.6 独立构件体系结构风格

      独立构件风格主要强调系统中的每个构件都是相对独立的个体,它们之间不直接通信,以降低耦合度,提升灵活性。独立构件风格主要包括进程通信和事件系统风格。

    • 进程通信: 在进程通信结构体系结构风格中,构件是独立的过程,连接件是消息传递,这种风格的特点是构件通常是命名过程,消息传递的方式可以是点到点、异步或同步方式及远程过程调用等。
    • 事件系统 (基于事件的隐式调用风格) SAr_批处理体系结构风格示意图.png

      7.4 软件架构复用

      软件复用是指系统化的软件开发过程:开发一组本的软件构造模块,以覆盖不同的需求/ 体系结构之间的相似性,从而提高系统开发的效率、质量和性能。软件复用是一种系统化的软件开发过程,通过识别、开发、分类、获取和修改软件实体,以便在不同的软件开发过程中重复的使用它们。

      7.5 特定领域软件体系结构(论)

      简单地说,DSSA (Domain Specific Software Architecture)就是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构。对DSSA研究的角度、关心的问题不同导致了对DSSA的不同定义。

      7.5.2 DSSA的基本活动

  7. 领域分析 这个阶段的主要目标是获得领域模型。
  8. 颁域设计 这个阶段的主要目标是获得DSSA。
  9. 领域实现 这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。

    7.5.3 参与DSSA的人员

    参与DSSA的人员可以划分为4种角色:领域专家、领域分析人员、领域设计人员和领域实现人员。

    第8章 系统质量属性与架构评估

    8.1 软件系统质量属性(案)

    评估方法所普遍关注的质量属性有以下几种,

  10. 性能：性能(Performance)是指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段事件内系统所能处理的事件的个数。经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量表示。性能测试经常要使用基准测试程序。
  11. 可靠性：可靠性(Reliability)是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性是最重要的软件特性,通常用来衡量在规定的条件和时间内,软件完成规定功能的能力。可靠性通常用平均失效等待时间(Mean Time To Failure, MTTF)和平均失效间隔时间(Mean Time Between Failure, MTBF)来衡量。在失效率为常数和修复时间很短的情况下,MTTF和MTBF几乎相等。可靠性可以分为两个方面。
  12. 可用性：可用性(Availability)是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
  13. 安全性：安全性(Security)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性可根据系统可能受到的安全威胁类型来分类。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。其中,机密性保证信息不泄露给未授权的用户实体或过程;完整性保证信息的完整和准确,防止信息被非法修改:不可否认性是指信息交换的双方不能否认其在交换过程中发送信息或接收信息的行为:可控性保证对信息的传播及内容具有控制的能力,防止为非法者所用。
  14. 可修改性：可修改性(Modifability)是指能够快速地以较高的性价比对系统进行变更的能力。通常以某些具体的变更为基准,通过考查这些变更的代价来衡量可修改性。可修改性包含以下4个方面。
  15. 功能性：功能性(Functionality)是系统能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
  16. 可变性：可变性(Changeability)是指架构经扩充或变更而成为新架构的能力。这种新架构应该符合预先定义的规则,在某些具体方面不同于原有的架构。当要将某个架构作为一系列相关产品(例如,软件产品线)的基础时,可变性是很重要的。
  17. 互操作性：作为系统组成部分的软件不是独立存在的,通常与其他系统或自身环境相互作用。为了支持互操作性,软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题,这种互操作性也影响应用的软件架构,

    8.2 系统架构评估(论)

    系统架构评估的方法通常可以分为3类:基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。 (1)基于调查问卷或检查表的方法。该方法的关键是要设计好问卷或检查表,充分利用系统相关人员的经验和知识,获得对架构的评估。该方法的缺点是在很大程度上依赖于评估人员的主观推断。 (2)基于场景的评估方法。基于场景的方式由卡耐基梅隆大学软件工程研究所首先提出并应用在架构权衡分析法(Architecthure Tradeof Analysis Mehod, ATAM)和软件架构分析方法(Software Architecture Analysis Method, SAAM)中。它是通过分析软件架构对场景(也就是对系统的使用或修改活动)的支持程度,从而判断该架构对这一场景所代表的质量需求的满足程度。 (3)基于度量的评估方法。它是建立在软件架构度量的基础上的,涉及3个基本活动,首先需要建立质量属性和度量之间的映射原则,然后从软件架构文档中获取度量信息,最后根损映射原则分析推导出系统的质量属性,

    • 敏感点(Sensitivity Point)和权衡点(Tradeof Point)。敏感点和权衡点是关键的架构决策。敏感点是一个或多个构件(和/或构件之间的关系)的特性。研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么。权衡点是影响多个质量属性的特性是多个质量属性的敏感点。

      8.2.2 系统架构评估方法

  18. SAAM方法 SAAM (Scenarios-based Architecture Analysis Method) (3) 质量属性。这一方法的基本特点是把任何形式的质量属性都具体化为场景,但可修改性是SAAM分析的主要质量属性。 SAAM分析评估架构的过程包括5个步骤，即场景开发、架构描述、单个场景评估、场景交互和总体评估。
  19. ATAM方法 架构权衡分析方法(Architecture Tradeof Analysis Method,ATAM)是在SAAM的基础上发展起来的,主要针对性能、实用性、安全性和可修改性,在系统开发之前,对这些质量属性进行评价和折中。 (6)方法的活动。ATAM被分为4个主要的活动领域(或阶段),分别是场景和需求收集、架构视图和场景实现、属性模型构造和分析、折中。 3.CBAM方法 在大型复杂系统的构建过程中,经济性通常是需要考虑的首要因素。因此,需要从经济角度建立成本、收益、风险和进度等方面教件的“经济”模型。成本效益分析法(the Cost Benefit Analysis Method,CBAM)是在ATAM上构建,用来对架构设计决策的成本和收益进行建模, 是优化此类决策的一种手段。CBAM的思想就是架构策略影响系统的质量属性,反过来这些质量属性又会为系统的项目干系人带来一些收益(称为“效用”),CBAM协助项目干系人根据其投资回报(Retum On lnvestment,RO)选择架构黄略。CBAM在ATAM结束时开始,它实际上使用了ATAM评估的结果。

    8.3 ATAM方法架构评估实践

    SAr_ATAM.png 1) 胡佛(Hoover)事件架构 2) 银行(banking)事件架构

    第9章 软件可靠性基础知识

    9.1 软件可靠性基本概念

    9.1.2 软件可靠性的定量描述

  20. 规定时间
  21. 失效概率
  22. 可靠度
  23. 失效强度
  24. 平均失效前时间
  25. 平均恢复前时间(Mean Time To Restoration MTTR)
  26. MTBF (Mean Time Between Failures,平均故障间隔时间)

    9.2 软件可靠性建模

    9.2.2 软牛可靠性的建模方法

    一个软件可靠性模型通常(但不是绝对)由以下几部分组成。 (1)模型假设。模型是实际情况的简化或规范化,总要包含若干假设,例如测试的选取代表实际运行剖面,不同软件失效独立发生等, (2)性能度量。软件可靠性模型的输出量就是性能度量,如失效强度、残留缺陷数等。在软件可靠性模型中性能度量通常以数学表达式给出。 (3)参数估计方法。某些可靠性度量的实际值无法直接获得,例如残留缺陷数,这时需通过一定的方法估计参数的值,从而间接确定可靠性度量的值。当然,对于可直接获得实际值的可靠性度量,就无须参数估计了。 (4)数据要求。一个软件可靠性模型要求一定的输入数据,即软件可靠性数据。不同类型的软件可靠性模型可能要求不同类型的软件可靠性数据。

软件的可靠性模型分类

种子法模型。 失效率类模型。 曲线拟合类模型。 可靠性增长模型。 程序结构分析模型。 输入域分类模型。 执行路径分析方法模型非齐次泊松过程模型。 马尔可夫过程模型。 贝叶斯分析模型。

9.3 软件可靠性管理

  1. 需求分析阶段
  2. 概要设计阶段
  3. 详细设计阶段
  4. 编码阶段
  5. 测试阶段
  6. 实施阶段

    9.4 软件可靠性设计(论)

    设计原则 (1)软件可靠性设计是软件设计的一部分,必须在软件的总体设计框架中使用,并且不能与其他设计原则相冲突。 (2)软件可靠性设计在满足提高软件质量要求的前提下,以提高和保障软件可靠性为最终目标。 (3)软件可靠性设计应确定软件的可靠性目标,不能无限扩大化,并且排在功能度、用户需求和开发费用之后考虑。 可靠性设计概念被广为引用,但并没有多少人能提出非常实用并且广泛运用的可靠性设计技术。一般来说,被认可的且具有应用前景的软件可靠性设计技术主要有容错设计、检错设计和降低复杂度设计等技术。

    • 容错设计技术 对于软件失效后果特别严重的场合,如飞机的飞行控制系统、空中交通管制系统及核反应推安全控制系统等,可采用容错设计方法。常用的软件容错技术主要有恢复块设计、N版本程序设计和冗余设计3种方法
    • 检错技术 在软件系统中,对无须在线容错的地方或不能采用冗余设计技术的部分,如果对可靠性要求较高,故障有可能导致严重的后果。一般采用检错技术,在软件出现故障后能及时发现并报警,提醒维护人员进行处理。检错技术实现的代价一般低于容错技术和冗余技术,但它有一个明显的缺点,就是不能自动解决故障,出现故障后如果不进行人工干预,将最终导致软件系统不能正常运行。 采用检错设计技术要着重考虑几个要素:检测对象、检测延时、实现方式和处理方式。
    • 降低复杂度设计 前面讲到,软件和硬件最大的区别之一就是软件的内部结构比硬件复杂得多,人们用软件复杂度来定量描述软件的复杂程度。软件复杂性常分为模块复杂性和结构复杂性。模块复杂性主要包含模块内部数据流向和程序长度两个方面,结构复杂性用不同模块之间的关联程度来表示。
    • 系统配置技术 通常在系统配置中可以采用相应的容错技术,通过系统的整体来提供相应的可靠性,主要有双机热备技术和服务器集群技术
    • 系统配置技术 通常在系统配置中可以采用相应的容错技术,通过系统的整体来提供相应的可靠性,主要有双机热备技术和服务器集群技术。

      9.5 软件可靠性测试

      9.6 软件可靠性评价(论)

      这个过程包含如下3个方面。 (1)选择可靠性模型。 (2)收集可靠性数据。 (3)可靠性评估和预测。

      怎样选择可靠性模型

  7. 模型假设的适用性
  8. 预测的能力与质量
  9. 模型输出值能否满足可靠性评价需求
  10. 模型使用的简便性

    可靠性数据的收集

    目前,关于数据的收集工作,存在许多有待解决的问题。 (1)可靠性数据的规范不统一,对软件进行度量的定义混乱不清。例如,时间、缺陷、失效和模型结构等的定义就相当含糊,缺乏统一的标准。这样就使得在进行软件可靠性数据的收集时,目标不明确,甚至无从下手。 (2)数据收集工作的连续性不能保证。可靠性数据的收集是连续的、长期的过程,而且需要投入一定的资金、人力、时间,往往这些投入会在软件的开发计划中被忽略,以至于不能保证可靠性数据收集工作的正常进行。 (3)缺乏有效的数据收集手段。进行数据收集同样需要方便实用的工具,然而除了在可靠性测试方面有了一些可用的数据收集工具外,其他方面的工具还十分缺乏。 (4)数据的完整性不能保证。即使可靠性活动计划做得再周密,收集到的数据仍有可能是不完全的,而且遗漏的数据往往会影响到可靠性评价的结果, (5)数据质量和准确性不能保证。不完全的排错及诊断,使收集的数据中含有不少虚假的成分,它们不能正确反映软件的真实状况。使用不准确的可靠性数据进行的可靠性评价,误差有可能会比利用可靠性模型进行预测产生的误差大一个数量级,这说明数据质量的重要性。

    软件可靠性的评估和预测

    软件可靠性评价技术和方法主要依据选用的软件可靠性模型,其来源于统计理论。软件可靠性评估和预测以软件可靠性模型分析为主,但也要在模型之外运用一些统计技术和手段对可靠性数据进行分析,作为可靠性模型的补充、完善和修正。这些辅助方法如下。 (1)失效数据的图形分析法。运行图形处理软件失效数据,可以直观地帮助人们进行分析, 图形指标如下。 ①累积失效个数图形。 ②单位时间段内的失效数的图形, ③失效间隔时间图形 (2)试探性数据分析技术(Exploratory Data Analysis,EDA)。 对于失效数据图形进行一定的数字化分析,能发现和揭示出数据中的异常。对可靠性分析有用的信息如下。 ①循环相关, ②短期内失效数的急剧上升。 ③失效数集中的时间段。 这种分析方法常可以发现因排错引入新的缺陷、数据收集的质量问题及时间域的错误定义等问题

    第10章 软件架构的演化和维护

    10.1 软件架构演化和定义的关系

    为了适应用户的新需求,业务环境和运行环境的变化等,软件架构需要不断地进行自身的演化,也就是说软件架构的演化就是为了维持软件架构自身的有用性。

    10.2 面向对象软件架构演化过程

    10.2.1 对象演化

    在顺序图中,组件的实体为对象。组件本身包含了众多的属性,如接口、类型、语义等, 这些属性的演化是对象自身的演化,对于描述对象之间的交互过程并无影响。因此,会对架构设计的动态行为产生影响的演化只包括AddObject (AO)和DeleteObject (DO)两种。

    10.2.2 消息演化

    消息是顺序图中的核心元素,包含了名称、源对象、目标对象、时序等信息。这些信息与其他对象或消息相关联,产生的变化会直接影响到对象之间的交互,从而对架构的正确性或时态属性产生影响。另外,消息自身的属性,如接口、类型等,产生的变化不会影响到对象之间交互的过程,则不考虑其发生的演化类型。因此,我们将消息演化分为AddMessage (AM)、DeleteMessage (DM)、SwapMessageOrder (SMO)、OverturnMessage (OM)、ChangeMesageModule (CMM)5种

    10.2.3 复合片段演化

    复合片段是对象交互关系的控制流描述,表示可能发生在不同场合的交互,与消息同属于连接件范畴。复合片段本身的信息包括类型、成立条件和内部执行序列,其中内部执行序列的演化等价于消息序列演化。通常,会产生分支的复合片段包括ref、loop、break、 alt、 opt、 par, 其余的复合片段类型并不会产生分支,因此主要考虑这些会产生分支的复合片段所产生的演化。 复合片段的演化分为AddFragment (AF)、DeleteFragment (DF)、FragmentTypeChange (FTC) 和FragmentConditionChange (FCC),如图10-3所示。

    10.2.4 约束演化

    顺序图中的约束信息以文字描述的方式存储于对象或消息中,如通常可以用TL来描述时态属性约束。约束演化对应着架构配置的演化,一般来源于系统属性的改变。

    10.3 软件架构演化方式的分类(论)

    (1)按照软件架构的实现方式和实施粒度分类:基于过程和函数的演化、面向对象的演化、基于组件的演化和基于架构的演化。 (2)按照研究方法将软件架构演化方式分为4类(Jefiey M.Bames等人的分类方法):第1类是对演化的支持,如代码模块化的准则、可维护性的指示(如内聚和耦合)、代码重构等; 第2类是版本和工程的管理工具,如CVS和 COCOMO:第3类是架构变换的形式方法,包括系统结构和行为变换的模型,以及架构润化的重现风格等:第4类是架构演化的成本收益分析, 决定如何增加系统的弹性。 (3)针对软件架构的演化过程是否处于系统运行时期,可以将软件架构演化分为静态演化(Static Evolution)和动态演化(Dynamic Evolution),前者发生在软件架构的设计、实现和维护过程中,软件系统还未运行或者处在运行停止状态;后者发生在软件系统运行过程中。

    10.3.2 软件架构静态演化

    SAr_静态演化过程模型.png

    10.3.3 软件架构动态演化

    1)软件动态性的等级。 CarlosE.Cuesta等人将软件的动态性分为3个级别(见图10-6):①交互动态性(Interactive Dynamism),要求数据在固定的结构下动态交互:②结构动态性(Structural Dynamism),允许对结构进行修改,通常的形式是组件和连接件实例的添加和删除,这种动态性是研究和应用的主流:③架构动态性(Architectural Dynamism),允许软件架构的基本构造的变动,即结构可以被重定义,如新的组件类型的定义。 2)动态演化的内容 根据所修改的内容不同,软件的动态演化主要包括以下4个方面。

    • 属性改名:目前所有的ADL都支持对非功能属性的分析和规约,而在运行过程中,用户可能会对这些指标进行重新定义(如服务响应时间)。
    • 行为变化;在运行过程中,用户需求变化或系统自身服务质量的调节都将引发软件行为的变化。诸如,为了提高安全级别而更换加密算法:将HTTP协议改为HTTPS协议;组件和连接件的替换和重新配置,
    • 拓扑结构改变:如增删组件,增删连接件,改变组件与连接件之间的关联关系等。
    • 风格变化:一般软件演化后其架构风格应当保持不变,如果非要改变软件的架构风格, 目前,实现软件架构动态演化的技术主要有两种:采用动态软件架构(Dynamic Sofitware Architecture, DSA)和进行动态重配置(Dynamic Reconfiguration,DR)。DSA是指在运行时刻会发生变化的系统框架结构,允许在运行过程中通过框架结构的动态演化实现对架构的修改; DR从组件和连接件的配置入手,允许在运行过程中增删组件,增删连接件,修改连接关系等操作。二者从不同的侧面对软件和架构的动态演化进行研究,尚无明确的分类。 DSA实施动态演化大体遵循以下4步:①捕捉并分析需求变化;②获取或生成体系结构演化策略:(③根据步骤2得到的演化黄略,选择适当的演化黄略并实施演化:④演化后的评估与检测。完成这4个步骤还需要DSA描述语言和演化工具的支持。 5.动态重配置 基于软件动态重配置的软件架构动态演化主要是指在软件部署之后对配置信息的修改,常常被用于系统动态升级时需要进行的配置信息修改。一般来说,动态重配置可能涉及的修改有; ①简单任务的相关实现修改;②工作流实例任务的添加和删除;③组合任务流程中的个体修改; ④任务输入来源的添加和删除:⑤任务输入来源的优先级修改:⑥组合任务输出目标的添加和删除:⑦组合任务输出目标的优先级修改等。

      10.4 软件架构演化原则

      10.5 软件架构演化评估方法

      10.6 大型网站系统架构演化实例

      第11章 未来信息综合技术

      11.1 信息物理系统技术概述

      信息物理系统(Cyber-Physical Systems,CPS)

      11.2 人工智能技术概述

      11.3 机器人技术概述

      机器人40主要有以下几个核心技术:包括云-边-端的无缝协同计算、持续学习与协同学习、知识图谱、场景自适应和数据安全。

      11.4 边缘计算概述

      11.5 数字孪生体技术概述

      数字孪生体技术是跨层级、跨尺度的现实世界和虚拟世界建立沟通的桥梁,是第四次工业革命的通用目的技术和核心技术体系之一,是支撑万物互联的综合技术体系,是数字经济发展的基础,是未来智能时代的信息基础设施。未来十年将成为“数字孪生体时代”。 建模、仿真和基于数据融合的数字线程是数字孪生体的三项核心技术。

      11.6 云计算和大数据技术概述

      3.云计算的部署模式 根据NIST的定义,云计算从部署模式上看可以分为公有云、社区云、私有云和混合云四种类型。 ***

      第12章 信息系统架构设计理论与实践

      12.1 信息系统架构基本概念及发展

      信息系统架构(Infomation System Architecture,ISA)则是指对某一特定内容里的信息进行统筹、规划、设计、安排等一系列有机处理的活动。它的主体对象是信息,由信息建筑师来加以设计结构、决定组织方式以及归类,好让使用者与用户容易寻找与管理的一项艺术与科学。

      12.2 信息系统架构

      1.信息系统物理结构 按照信息系统硬件在空间上的拓扑结构,其物理结构一般分为集中式与分布式两大类。 几种常用的信息系统结构模式,可以供应用系统设计时参考。这些模式主要包括:单机应用系统、两层/多层CS、MVC结构、面向服务的SOA与多服务集合和数据交换总线等。

      12.3 信息系统架构设计方法

      12.4 信息系统架构案例分析

      第13章 层次式架构设计理论与实践(论)

      13.1 层次式体系结构概述

      SAr_常用的层次式架构.png

      13.2 表现层框架设计

      SAr_MVC设计模式.png

      13.3 中间层架构设计

      13.4 数据访问层设计(论)

      13.4.1 5种数据访问模式

  11. 在线访问
  12. DataAccess Object
  13. Data Transfer Object
  14. 离线数据模式
  15. 对象/关系映射(Object/Relation Mapping, O/R Mapping)

    13.5 数据架构规划与设计

    13.6 物联网层次架构设计

    物联网可以分为三个层次,底层是用来感知数据的感知层,即利用传感器、二维码、RFID 等设备随时随地获取物体的信息。第二层是数据传输处理的网络层,即通过各种传感网络与互联网的融合,将对象当前的信息实时准确地传递出去。第三层则是与行业需求结合的应用层, 即通过智能计算、云计算等将对象进行智能化控制。

    13.7 层次式架构案例分析

    第14章 云原生架构设计理论与实践

    14.1 云原生架构产生背景

    14.2 云原生架构内涵

    14.2.2 云原生架构原则(论)

  16. 服务化原则
  17. 弹性原则
  18. 可观测原则
  19. 韧性原则
  20. 所有过程自动化原则
  21. 零信任原则
  22. 架构持续演进原则

    14.2.3 主要架构模式

  23. 服务化架构模式
  24. Mesh化架构模式
  25. Serverless模式
  26. 存储计算分离模式
  27. 分布式事务模式
  28. 可观测架构
  29. 事件驱动架构

    14.3 云原生架构相关技术

    14.4 云原生架构案例分析

    第15章 面向服务架构设计理论与实践

    15.1 SOA的相关概念

    15.1.1 SOA的定义

    面向服务的体系结构(Service-Oriented Architecture,SOA)

    15.2 SOA的发展历史

    15.2.3 SOA的微服务化发展(论)

    SOA与微服务的区别在于如下几个方面: (1)微服务相比于SOA更加精细,微服务更多地以独立的进程的方式存在,互相之间并无影响; (2)微服务提供的接口方式更加通用化,例如 HTTP RESTful方式,各种终端都可以调用, 无关语言、平台限制; (3)微服务更倾向于分布式去中心化的部署方式,在互联网业务场景下更适合。

    15.3 SOA的参考架构(论)

    从服务为中心的视角来看,企业集成的架构分为6大类 (1)业务逻辑服务(Business Logic Service):包括用于实现业务逻辑的服务和执行业务逻辑的能力,其中包括业务应用服务(Busines Application Service)、业务伙伴服务(Partner Service)以及应用和信息资产(Application and Information asset)。 (2)控制服务(Control Service):包括实现人(People)、流程(Process)和信息(Infor mation)集成的服务,以及执行这些集成逻辑的能力。 (3)连接服务6(Connectivity Service):通过提供企业服务总线提供分布在各种架构元素中服务间的连接性。 (4)业务创新和优化服务(Business Innovation and Optimization Service):用于监控业务系统运行时服务的业务性能,并通过及时了解到的业务性能和变化,采取措施适应变化的市场。 (5)开发服务(Development Service):贯彻整个软件开发生命周期的开发平台,从需求分析,到建模、设计、开发、测试和维护等全面的工具支持。 (6)IT服务管理(IT Service Management):支持业务系统运行的各种基础设施管理能力或服务,如安全服务、目录服务、系统管理和资源虚拟化。

    15.4 SOA主要协议和规范

    15.4.1 UDDI协议

    UDDI(统一描述、发现和集成协议)计划是一个广泛的、开放的行业计划,它使得商业实体能够彼此发现:定义它们怎样在Intemet上互相作用,并在一个全球的注册体系架构中共享信息。UDDI是这样一种基础的系统构筑模块,它使商业实体能够快速、方便地使用它们自身的企业应用软件来发现合适的商业对等实体,并与其实施电子化的商业贸易。

    15.4.2 WSDL规范

    WSDL (Web Services Description Language,Web服务描述语言),是一个用来描述Web服务和说明如何与Web服务通信的XML语言。

    15.4.3 SOAP协议

    SOAP是在分散或分布式的环境中交换信息的简单的协议,是一个基于XML的协议。它包括4个部分:SOAP封装(Envelop),定义了一个描述消息中的内容是什么,是谁发送的,谁应当接收并处理它以及如何处理它们的框架:SOAP编码规则(Encoding Rules),用于表示应用程序需要使用的数据类型的实例:SOAP RPC表示(RPC Representation)是远程过程调用和应答的协定;SOAP绑定(Binding)是使用底层协议交换信息。

    15.4.4 REST规范

    REST是Roy Thomas Fielding博士在他的一篇论文中提出的一个概念,在这篇论文中设计了一种新的互联网软件架构风格,REST的设计不只是要适用于互联网环境,而是一个普遍的设计理念,目的是为了让不同的软件或者应用程序在任何网络环境下都可以进行信息的互相传递。

    15.5 SOA设计的标准要求(论)

    15.6 SOA的作用

    SOA对于实现企业资源共享,打破“信息孤岛”的步骤如下。 (1)把应用和资源转换成服务。 (2)把这些服务变成标准的服务,形成资源的共享。

    15.7 SOA的设计原则

    15.8 SOA的设计模式

    15.8.4 微服务模式(论)

    微服务架构将一个大型的单个应用或服务拆分成多个微服务,可扩展单个组件而不是整个应用程序堆栈,从而满足服务等级协议。微服务架构围绕业务领域将服务进行拆分,每个服务可以独立进行开发、管理和迭代,彼此之间使用统一接口进行交流,实现了在分散组件中的部署、管理与服务功能,使产品交付变得更加简单,从而达到有效拆分应用,实现敏捷开发与部署的目的。 常见的微服务设计模式有聚合器微服务设计模式、代理微服务设计模式、链式微服务设计模式、分支微服务设计模式、数据共享微服务设计模式、异步消息传递微服务设计模式等。

    15.9 构建SOA架构时应该注意的问题

    15.10 SOA实施的过程

    第16章 嵌入式系统架构设计理论与实践

    16.1 嵌入式系统概述

    16.2 嵌入式系统软件架构原理与特征

    16.3 嵌入式系统软件架构设计方法

    16.3.2 属性驱动的软件设计方法

    嵌入式系统,尤其是安全攸关的系统与通常的软件系统的最大不同点就是高质量属性始终贯穿于整个产品的全生命周期中。属性驱动的软件设计(Atribute-Driven Design,ADD》是把组质量属性场景作为输入,利用对质量属性实现与架构设计之间的关系的了解(如体系结构风格、质量战术等)对软件架构进行设计的一种方法。

    16.3.3实时系统设计方法

    嵌入式系统具有众多自身的特性,这些特性通常和应用场景密切相关,而实时特性常被各类具各控制能力的系统所采用,比如工业控制、航空航天和轨道交通等领域中的嵌入式系统应同时具备高可靠性、高安全性、强实时性等。系统的实时性是这些嵌入式系统的核心特性, 对实时系统,其设计方法也有它的自身特点。实时系统设计方法(Design Approach for Real Time System,DARTS)常被应用于嵌入式系统的软件设计中。

    16.4 嵌入式系统软件架构案例分析

    第17章 通信系统架构设计理论与实践

    17.1 通信系统概述

    17.2 通信系统网络架构

    17.2.4 存储网络架械

    一般来说,计算机访问磁盘存储有3种方式: (1)直连式存储(Direct Atached Storage, DAS):计算机通过I/O端口直接访问存储设备的方式。 (2)网络连接的存储(Network Atached Storage NAS):计算机通过分布式文件系统访问存储设备的方式 (3)存储区域网络(Storage Area Network,SAN):计算机通过构建的独立存储网络访问存储设备的方式。 1.软件定义网络 软件定义网络(Software Defined Network, SDN)

    17.3 网络构建关键技术

    17.4 网络构建和设计方法

    17.5 通信网络构建案例分析

    第18章 安全架构设计理论与实践

    18.1 安全架构概述

    对于信息系统来说,威胁可以是针对物理环境、通信链路、网络系统、操作系统、应用系统以及管理系统等方面。物理安全威胁是指对系统所用设各的威胁,如自然灾害、电源故障、操作系统引导失败或数据库信息丢失、设备被盗/被毁造成数据丢失或信息泄露:通信链路安全威胁是指在传输线路上安装窃所装置或对通信链路进行干扰:网络安全威胁是指由于互联网的开放性、国际化的特点,人们很容易通过技术手段窃取互联网信息,对网络形成严重的安全威胁;操作系统安全威胁是指对系统平台中的软件或硬件芯片中植入威胁,如“木马”和“陷阱门”、BIOS的万能密码;应用系统安全威胁是指对于网络服务或用户业务系统安全的威胁, 也受到“木马”和“陷阱门”的威胁:管理系统安全威胁是指由于人员管理上疏忽而引发人为的安全漏洞,如人为的通过拷贝、拍照、抄录等手段盗取计算机信息。

    18.2 安全模型

    当前比较被公认的模型有:状态机模型(State Machine Model)、Bel-LaPadula (BLP)模型、Biba模型、Clark-Wilson (CWM)模型、ChineseWal模型,以及信息流模型(Information Flow Model)、非干涉模型(Noninterference Model)、格子模型(Latice Model)、 Brewer and Nash模型和Graham-Denning模型等。这里简要介绍典型的五种安全模型。

    18.3 系统安全体系架构规划框架

    因此根据网络中风险威胁的存在实体划分出5个层次的实体对象:应用、存储、主机、网络和物理。

    18.4 信息安全整体架构设计(WPDRRC模型)

    WPDRRC模型有6个环节和3大要素。 6个环节包括:预警、保护、检测、响应、恢复和反击,它们具有较强的时序性和动态性, 能够较好地反映出信息系统安全保障体系的预警能力、保护能力、检测能力、响应能力、恢复能力和反击能力。 3大要素包括:人员、策略和技术。人员是核心,策略是桥梁,技术是保证。

    18.5 网络安全体系架构设计(论)

    鉴别(Authentication)的基本目的是防止其他实体占用和独立操作被鉴别实体的身份。鉴别提供了实体声称其身份的保证,只有在主体和验证者的关系背景下,鉴别才是有意义的。鉴别有两种重要的关系背景:一是实体由申请者来代表,申请者与验证者之间存在着特定的通信关系(如实体鉴别);二是实体为验证者提供数据项来源。 鉴别的方式主要基于以下5种。 (1)已知的,如一个秘密的口令。 (2)拥有的,如1C卡、令牌等。 (3)不改变的特性,如生物特征。 (4)相信可靠的第三方建立的鉴别(递推)。 (5)环境(如主机地址等)。

    18.5.3 访问控制框架访问控制(Access Control)决定开放系统环境中允许使用哪些资源、在什么地方适合阻止未授权访问的过程。在访问控制实例中,访问可以是对一个系统(即对一个系统通信部分的一个实体)或对一个系统内部进行的。

    18.6 数据库系统的安全设计

    18.7 系统架构的脆弱性分析

    18.8 安全架构设计案例分析

    第19章 大数据架构设计理论与实践

    19.1 传统数据处理系统存在的问题

    19.2 大数据处理系统架构分析

    19.3 Lambda架构

    19.4 Kappa架构

    19.5 Lambda架构与Kappa架构的对比和设计选择

    19.6 大数据架构设计案例分析

    第20章 系统架构设计师论文写作要点

补充
旧版教材

第3章 信息系统基础知识

3.3 信息化的典型应用

3.3.4 客户关系管理在企业的应用

客户关系管理 (Customer Relationship Management, CRM) CRM的核心思想就是以客户为中心。 CRM是一套先进的管理思想及技术手段,它通过将人力资源、业务流程与专业技术进行有效的整合,最终为企业涉及到客户或消费者的各个领域提供了完美的集成,使得企业可以更低成本、更高效率地满足客户的需求,并与客户建立起基于学习性关系基础上的一对一营销模式,从而让企业可以最大程度提高客户满意度及忠诚度。