【希赛网】软考高级系统架构每日一题总结

前言

为了准备软考高级，考前20天刷大量希赛网每日一题，以下题目都来自希赛网~

总结自身的错题以及可记忆的题~

个别分类可能不正确

基础知识

CRC校验码：

（中间的模2除法是异或操作）

最后的余数结果为CRC校验码

需求定义

分为定义和原型

定义适用于需求已全面获取，需求较为明确，如果达不到则使用原型。

1、求分析阶段:数据流图。

2、概要设计阶段:模块结构图、层次图和HIPO图。

3、详细设计阶段:程序流程图、伪代码、图。

UML2.0中---共定义了14种图。

其中结构图（静态图）包括:类图、对象图、构件图、部署图、制品图、包图、组合结构图;
行为图（动态图）包括:用例图、顺序图、通信图(协作图)、定时图、交互概览图、活动图、状态图。

配置项是构成产品配置的主要元素，配置项主要有以下两大类:

属于产品组成部分的工作成果:如需求文档、设计文档、源代码和测试用例等;
属于项目管理和机构支撑过程域产生的文档:如工作计划、项目质量报告和项目跟踪报告等。

如果单纯问配置项

知识产权与标准化

在著作权法中规定:署名权、修改权 、保护作品完整权的保护期是不受时间限制的，也就是永久保护。

而发表权、使用权和获得报酬权的保护期限为:作者终生及其死亡后的50年(第50年的12月31日)。

软件著作权中规定:开发软件所用的思想、处理过程、操作方法或者数学概念不受保护。

软件开发

从开发风范上看，可分为自顶向下的开发方法和自底向上的开发方法

"先对最高层次中的问题进行定义、设计、编程和测试，而将其中未解决的问题作为一个子任务放到下一层次中去解决"------自顶向下的开发
"根据系统功能要求，从具体的器件、逻辑部件或者相似系统开始，通过对其进行相互连接、修改和扩大，构成所要求的系统"------是自底向上的开发

从性质上看，可分为形式化方法和非形式化方法。

形式化方法是一种具有坚实数学基础的方法，从而允许对系统和开发过程做严格处理和论证，适用于那些系统安全级别要求极高的软件的开发
非形式化方法则不把严格性作为其主要着眼点，通常以各种开发模型的形式得以体现。

设计模式

六大类	说明
单---职责原则	设计目的单---的类。
开放封闭原则	对扩展开放，对修改封闭。李氏(Liskov)）替换原则:子类可以替换父类。
依赖倒置原则	要依赖于抽象，而不是具体实现;针对接口编程，不要针对实现编程。
接口隔离原则	使用多个专门的接口比使用单---的总接口要好。
组合重用原则	要尽量使用组合，而不是继承关系达到重用目的。
迪米特(Demeter）原则(最少知识法则)	一个对象应当对其他对象有尽可能少的了解。

设计模式类别

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

Singleton 单例模式，属于创建型

Memento是备忘录模式，属于行为型

Bridge是桥接，特点是实现接口与实现分离

类别	说明
工厂方法模式	定义了一个创建对象的抽象方法，由子类决定要实例化的类
抽象工厂模式	定义了一个接口用于创建相关或有依赖关系的对象族，而无需明确指定具体类
单例模式	确保一个类最多只有一个实例，并提供一个全局访问点
建造者模式	封装一个复杂对象构造过程，并允许按步骤构造。
原型模式	通过复制现有实例来创建新的实例，无需知道相应类的信息
适配器模式	适配器模式将某个类的接口转换成客户端期望的另一个接口表示，目的是消除由于接口不匹配所造成的类的兼容性问题。
装饰器模式	动态的将新功能附加到对象上。在对象功能扩展方面，它比继承更有弹性
代理模式	代理模式给某一个对象提供一个代理对象，并由代理对象控制对原对象的引用
外观模式	隐藏了系统的复杂性，并向客户端提供了一个可以访问系统的接口
桥接模式	将抽象部分与它的实现部分分离，使它们都可以独立地变化
组合模式	将对象组合成树形结构以表示"部分-整体"的层次结构
享元模式	通过共享的方式高效的支持大量细粒度的对象
策略模式	策略模式定义了一系列算法，并将每个算法封装起来，使他们可以相互替换，且算法的变化不会影响到使用算法的客户
模板方法模式	定义一个操作中算法的骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变算法的结构即可重定义该算法的某些特定步骤
观察者模式	定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新
迭代子模式	提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示
责任链模式	如果有多个对象有机会处理请求，责任链可使请求的发送者和接受者解耦，请求沿着责任链传递，直到有一个对象处理了它为止
命令模式	将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开
备忘录模式	该模式又叫快照模式
状态模式	表示各种状态的对象和一个行为随着状态对象改变而改变的 context 对象
访问者模式	将作用于某种数据结构中的各元素的操作分离出来封装成独立的类，使其在不改变数据结构的前提下可以添加作用于这些元素的新的操作，为数据结构中的每个元素提供多种访问方式。它将对数据的操作与数据结构进行分离
中介者模式	中介者模式又叫调停模式，它是迪米特法则的典型应用

软件工程

实现级:包括程序的抽象语法树、符号表过程的设计表示。
结构级:包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构。
功能级:包括反映程序段功能及**程序段之间关系的信息，**例如数据和控制流模型。
领域级:包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如实体关系模型。

环路复杂度计算（Mccabe）：

第一种：V(G) = E - N + 2，E为流图边条数，N为结点数

第二种：V(G) = P + 1，P为判定节点数

按照传统的软件生命周期方法学，可以把软件生命周期划分为软件定义、软件开发、软件运行与维护三个阶段。

瀑布模型 的特点是因果关系 紧密相连，前一个阶段工作的结果后一个阶段工作的输入。或者说，每一个阶段都是建筑在前一个阶段正确结果之上,前一个阶段的错漏会隐蔽地带到后一个阶段。

这种错误有时甚至可能是灾难性的。因此每一个阶段工作完成后,都要进行审查和确认，这是非常重要的。
管道过滤器风格 ：输入某个构件,经过内部处理，产生数据输出的系统，正是管道过滤器中过滤器的职能，把多个过滤器使用管道相联的风格为管道过滤器风格。
解释器：

例题：某企业内部现有的主要业务功能经封装为Web服务。为了拓展业务范围，需要将现有的业务功能进行多种组合，形成新的业务功能。针对业务灵活组合这一要求，采用( )架构风格最为合适。
中介者模式 ：根据题干描述，该系统需要能够支持不同芯片之间的数据交互,并能够独立改变芯片之间的数据交互过程。

这种情况下，可以引入一个中介层,通过中介层屏蔽不同芯片之间的两两交互。

传统的编译器一般采用数据流架构风格, 在这种架构中,每个构件都有一组输入和输出，数据输入构件,经过内部处理，然后产生数据输出。

编译处理过程中，会分步将源代码一次次的处理，最终形成目标代码，这与数据流架构风格相当吻合。

顺序批处理是强调把数据整体处理的
IDE是一种集成式的开发环境，在这种环境中，多种工具是围绕同一数据进行处理，这种情况适合用数据共享架构风格。
IDE环境是一种交互式编程，在修改程序代码后，会同时触发语法高亮显示、语法错误提示、程序结构更新等多种功能的调用与结果呈现。在做一件事情时，同时触发一系列的行为，这是典型的隐式调用风格(事件驱动系统)。
"使IDE能够生成符合新操作系统要求的运行代码"，这一要求是可以通过适配策略满足的,像设计模式中的适配器模式便是采用适配的方式，形成一致的接口。

软件需求开发的最终文档经过评审批准后，则定义了开发工作的需求基线(baseline) 。

这个基线在用户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定(agreement) ,它是需求开发和需求管理之间的桥梁。

软件设计包括体系结构设计、接口设计、数据设计和过程设计。

结构设计:义软件系统各主要部件之间的关系。
数据设计:将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分,降低过程复杂性。
接口设计(人机界面设计) :软件内部,软件和操作系统之间以及软件和人之间如何通信。
过程设计:系统结构部件转换成软件的过程描述。确定软件各个组成部分内的算法及内部数据结构,并选定某种过程的表达形式来描述各种算法。

软件系统工具的种类繁多，很难有统一的分类方法。

通常可以按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。

软件开发工具:需求分析工具、设计工具、编码与排错工具。
软件维护工具:版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
软件管理和软件支持工具:项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。

时间管理的过程包括: .

1、活动定义

2、活动排序

3、活动的资源估算

4、活动历时估算

5、制定计划

6、进度控制

软件开发环境(software development environment)是支持软件产品开发的软件系统。

它由软件工具集和环境集成机制构成

前者用来支持软件开发的相关过程、活动和任务年

后者为工具集成和软件开发、维护和管理提供统一的支持，它通常包括数据集成、控制集成和界面集成。

数据集成机制提供了存储或访问环境信息库的统一的数据接口规范
界面集成机制采用统一的界面形式，提供统一的操作方式
控制集成机制支持各开发活动之间的通信、切换、调度和协同工作。

需求管理是一个对系统需求变更、了解和控制的过程

需求管理过程与需求开发过程相互关联，当初始需求导出的同时就启动了需求管理计划，一旦形成了需求文档的初稿，需求管理活动就开始了。

关于需求管理过程域内的原则和策略，可以参考:

需求管理的关键过程领域不涉及收集和分析项目需求，而是假定已收集了软件需求，或者已由更高一级的系统给定了需求。
开发人员在向客户以及有关部门承诺某些需求之前，应该确认需求和约束条件、风险、偶然因素、假定条件等。
关键处理领域同样建议通过版本控制和变更控制来管理需求文档。

为实现对象重用，COM支持两种形式的对象组装

在包含重用形式下，一个外部对象拥有指向一个内部对象的唯一引用，外部对象只是把请求转发给内部对象。
在聚焦重用形式下，直接把内部对象的接口弓|用传给外部对象的客户，而不再转发请求。

传统软件工程方法学采用结构化设计方法(SD) ，从工程管理角度结构化设计分为两步:

概要设计:将软件需求转化为数据结构和软件系统结构。
详细设计:过程设计,通过对结构细化，得到软件详细数据结构和算法。

RUP的三个核心特点是:以架构为中心，用例驱动,增量与迭代。

其中增量与迭代的好处是:

降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。
4 . 由于用户的需求并不能在一开始就作出完全的界定, 它们通常是在后续阶段中不断细化的。因此,迭代过程这种模式使适应需求的变化会更容易些。

面向对象的分析模型主要由顶层架构图 、用例与用例图、领域概念模型构成;

设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图 、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。

软件测试

黑盒测试也称为功能测试，要于集成测试,确认测试和系统测试阶段

黑盒测试根据软件需求规格说明所规定的功能来设计测试用例，包括功能分解、等价类划分、边界值分析、判定表因果图、状态图、随机测试、错误推测和正交试验法等。

在设计测试用例时,等价类划分 是用得最多的一种黑盒测试方法。

所谓等价类就是某个输入域的集合,对每一个输入条件确定若干个有效等价类和若干个无效等价类，分别设计覆盖有效等价类和无效等价类的测试用例。

无效等价类是来测试非正常的输入数据的,所以要为每个无效等价类设计一个测试用例。
边界值分析通过选择等价类边界作为测试用例，不仅重视输入条件边界，而且也必须考虑输出域边界。在实际测试工作中，将等价类划分法和边界值分析结合使用，能更有效地发现软件中的错误。
因图方法是从用自然语言书写的程序规格说明的描述中找出因(输入条件)和果(输出或程序状态的改变)，可以通过因果图转换为判定表。
正交试验设计法，就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最的测试覆盖率。

静态测试是指被测试程序不在机器上运行,而采用人工检测和计算机辅助静态分析的手段对程序进行检测。

静态测试包括对文档的静态测试和对代码的静态测试。

对文档的静态测试主要以检查单的形式进行
而对代码的静态测试一般采用桌前检查 (Desk Checking)、代码审查和代码走查。
经验表明，使用这种方法能够有效地发现30% ~70%的逻辑设计和编码错误。

与之对应的动态测试是利用计算机运行得到测试结果的方式进行测试。动态测试中的黑盒测试不关注程序的内部结构,只从程序块的功能、输入、输出角度分析问题,设计测试用例并展开测试工作。

确认测试中，需要'确认"的，是用户需求。所以这种测试有一个显著的特点，就是测试必须要有用户的参与。

Alpha测试(a测试)是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员(有的地方又说可以让测试人员进行)成。
Beta测试(β测试)是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。Beta测试是在开发者无法控制的环境下进行的软件现场应用。

根据测试目的不同，性能测试主要包括压力测试、负载测试、并发测试和可靠性测试等。

强度测试 :是在系统资源特别低的情况下考查软件系统极限运行情况。
负载测试 :用于测试系统超负荷环境中程序是否能够承担，确定在各种工作负载下系统的性能，测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试 :通过确定系统的瓶颈或不能接收的性能点 ，来获得系统能够提供的最大服务级别的测试。
负载测试和压力测试可以结合进行，统称为负载压力测试。
容量测试 :并发测试也称为容量测试，主要用于测试系统可同时处理的在线最大用户数量。

架构

特定领域软件架构(Domain Specific Software Architecture，DSSA)

以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，其目标是支持一个特定领域中多个应用的生成。

DSSA的基本活动包括领域分析、领域设计和领域实现。

领域分析的主要目的是获得领域模型，领域模型描述领域中系统之间共同的需求，即领域需求;
领域设计的主要目标是获得DSSA（也就是获得特定领域软件架构），DSSA描述领域模型中表示需求的解决方案;
领域实现的主要目标是依据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。

J2EE架构中

在一个典型的基于MVC(Model View Controller)的J2EE应用中

系统的界面由JSP构件实现
分发客户请求、有效组织其他构件为客户端提供服务的控件器由Servlet构件实现
数据库相关操作由Entity Bean构件实现
系统核心业务逻辑由Session Bean构件实现

语音识别、知识推理等问题复杂，解空间很大、求解过程不确定的这一类软件系统，通常会采用黑板架构风格

对于因数据输入某个构建，经过内部处理，产生数据输出的系统，通过采用管道-过滤器架构风格。

架构构建的三个特点：

独立部署单元;
作为第三方的组装单元;
没有(外部的)可见状态。

根据基于软件架构的设计的定义，基于软件架构的设计(Architecture Based Software Design，ABSD）强调由商业、质量和功能需求的组合驱动软件架构设计。

ABSDM模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现、演化等六个子过

程。

它强调采用视角和视图 来描述软件架构

采用用例和质量场景来描述质量需求。

补充另外一个视图：

"4+1"视图中的"4"，

4 指的是:逻辑视图、开发视图、过程视图、物理视图

"1"指的是场景视图。

场景视图又称为用例视图，显示外部参与者观察到的系统功能。
逻辑视图从系统的静态结构和动态行为角度显示系统内部如何实现系统的功能。
开发视图又称为实现视图，显示的是源代码以及实际执行代码的组织结构。
处理视图又称为过程视图，显示程序执行时并发的状态。
物理视图展示软件到硬件的映射。

在RUP中采用"4+ 1"视图模型来描述软件系统的体系结构。

"4+1"视图包括逻辑视图、实现视图、进程视图、部署视图和用例视图。

分析人员和测试人员关心的是系统的行为,因此会侧重于用例视图;
最终用户关心的是系统的功能，因此会侧重于逻辑视图;程序员关心的是系统的配置、装配等问题，因此会侧重于实现视图;
系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程视图;
系统工程师关心的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署视图。

构件组装技术大致可分为（不包括构件组装技术）

基于功能的组装技术
基于数据的组装技术
面向对象的组装技术

系统架构组装分为三个不同的层次：

定制
集成
扩展

UDDI (Universal Description, Discovery & Integration)，UDDI用于Web服务注册和服务查找;
WSDL (Web Service Description L anguage)，WSDL用于描述Web服务的接口和操作功能;
SOAP (Simple Object Access Protocol)， SOAP为建立Web服务和服务请求之间的通信提供支持。
BPEL (Business Process Execution L anguage For Web Services)翻译成中文的意思是面向Web服务的业务流程执行语言，它是一种使用Web服务定义和执行业务流程的语言。
使用BPEL,用户可以通过组合、编排和协调Web服务自.上而下地实现面向服务的体系结构(SOA)。BPEL 提供了相对简单易懂的方法，可将多个Web服务组合到一个新的复合服务(称作业务流程)中。

一、架构需求 :需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。架构需求受技术环境和架构设计师的经验影响。
需求过程主要是获取用户需求，标识系统中所要用到的构件。如果以前有类似的系统架构的需求，我们可以从需求库中取出,加以利用和修改，以节省需求获取的时间，减少重复劳动，提高开发效率。
二、架构设计:架构需求用来激发和调整设计决策,不同的视图被用来表达与质星目标有关的信息。架构设计是一个迭代过程，如果要开发的系统能够从已有的系统中导出大部分,则可以使用己有系统的设计过程。
三、架构文档化:绝大多数的架构都是抽象的,由一些概念上的构件组成。例如，层的概念在任何程序设计语言中都不存在。因此，要让系统分析师和程序员去实现架构,还必须得把架构进行文档化。

文档是在系统演化的每一个阶段，系统设计与开发人员的通讯媒介，为验证架构设计和提炼或修改这些设计(必要时)所执行预先分析的基础。
架构文档化过程的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明书这两个文档。
生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。
软件架构的文档要求与软件开发项目中的其他文档是类似的。
文档的完整性和质量是软件架构成功的关键因素。软件架构文档应该从使用者的角度进行书写,针对不同背景的人员采用不同的书写方式，并将文档分发给相关人员。
架构文档要保持较新，但不要随时保证文档最新，要保持文档的稳定性。

四、架构复审:架构设计、文档化和复审是一个迭代过程。从这个方面来说，在一个主版本的软件架构分析之后，要安排一次由外部人员(用户代表和领域专家)参加的复审。

复审的目的是标识潜在的风险,及早发现架构设计中的缺陷和错误，包括架构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等等。
由外部人员进行复审的目的是保证架构的设计能够公正地进行检验，使组织的管理者能够决正式实现架构。

五、架构实现:所谓实现"就是要用实体来显示出一个软件架构，即要符合架构所描述的结构性设计决策，分割成规定的构件,按规定方式互相交互。
六、架构演化 :在构件开发过程中,最终用户的需求可能还有变动。
在软件开发完毕,正常运行后，由一个单位移植到另一个单位,需求也会发生变化。
在这两种情况下，就必须相应地修改软件架构，以适应新的变化了的软件需求。

从本质上看,需求和软件架构设计面临的是不同的对象: 一个是问题空间;另一个是解空间。保持两者的可追踪性和转换，一直是软件工程领域追求的目标。从软件需求模型向SA模型的转换主要关注两个问题:

如何根据需求模型构建软件架构模型;
如何保证模型转换的可追踪性。

构件的特性是:

(1) 独立部署单元;

(2) 作为第三方的组装单元;

(3) 没有(外部的)可见状态。

一个构件可以包含多个元素但是一个元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。

对象的特性是: （注意是对象，不是构件）

(1) 一个实例单元，具有唯一的标志。

(2) 可能具有状态，此状态外部可见。

(3) 封装了自己的状态和行为。

ATAM被分为四个主要的活动区域，分别是场景和需求收集、 架构视图和场景实现、属性模型构造和分析、属性模型折中。

闭环结构的软件通常由几个协作构件共同构成，且其中的主要构件彼此分开，能够进行替换与重用,但闭环结构通常适用于处理简单任务(如机器装配等)，不适于复杂任务。
分层结构的特点是通过引入抽象层，在较低层次不确定的实现细节在较高层次会变得确定，并能够组织层间构件的协作，系统结构更加清晰。

体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

质量属性

"系统主站断电后，能够在2分钟内自动切换到备用站点，并恢复正常运行"，表达的是在出问题后的恢复能力，属于可用性 范畴。主动冗余是提高可用性的有效手段。
"在并发用户数不超过1000人时，用户的交易请求应该在0.5s内完成"，这是对性能的量化指标，属于性能的范畴。有效的资源调度能提升性能。
"系统应该能够抵挡恶意用户的入侵行为，并进行报警和记录"，这是安全方面的要求，在系统中，一般会用日志记录相关信息，然后通过对日志进行追踪审计能了解相关情况。

性能(performance) 是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

可用性(availability)是系统能够正常运行的时间比例。经常用两次故障之间的时间长度 或在出现故障时系统能够恢复正常的速度来表示。

安全性(security) 是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。

可靠性:产品在规定的条件和规定的时间内,完成规定功能的能力。

常考质量属性及相应设计策略如下:

性能：指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理的事件的个数。
代表参数:响应时间、吞嘬
设计策略:优先级队列、资源调度
可用性:是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
代表参数:故障间隔时间
设计策略:冗余、心跳线
安全性:是指系统在向合法用户提供服务的同时能够阻非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、可否认性及可控性等特性。
设计策略:追踪审计、检测攻击
可修改性: 是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。
主要策略:信息隐藏
可靠性: 是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本能力。主要考虑两个方面:容错、健壮性。
代表参数: MTTF、 MTBF
设计策略:冗余、心跳线

不同策略主要针对一个或多个软件质量属性，其中

Ping/Echo主要提高系统的可用性
限制访问主要提高系统的安全性;
运行时注册主要提高系统的可修改性;
接口-实现分离主要提高系统的可修改性;
主动冗余提高系统的可用性;
队列调度主要提高系统的性能;
信息隐藏主要提高系统的可修改性;
记录-回放主要提高系统的可测试性

质量评估

风险点、非风险点、敏感点和权衡点是进行软件架构评价的关键步骤。

其中敏感点 是实现一个特定质量属性的关键特征，该特征为一个或多个软件构件所共有。

系统权衡点会影响一个或多个属 性，并对于多个属性来说都是敏感点。基于该定义，可以看出"改变加密的级别可能会对安全性和性能都产生显著的影响 "正是---个对系统权衡点的描述。

数据库

数据库容灾属于系统安全和应用安全考虑范畴

数据仓库4大特点:

面向主题:数据按主题组织。
集成性:消除了源数据中的不一致性，提供整个企业的一致性全局信息。
相对稳定性(非易失的) :主要进行查询操作,只有少的修改和删除操作(或是不删除)。
反映历史变化(随着时间变化) :记录了企业从过去某-时刻到当前各个阶段的信息，可对发展历程和未来趋势做定分析和预测。

所谓的两个阶段是指:第一阶段: 准备阶段(表决阶段)和第二阶段:提交阶段(执行阶段)。

准备阶段:事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息, 每个参与要么直接返回失败(如权限验证失败)，要么在本地执行务,写体地的redo和undo日志,但不提交,达到一种"万事俱备,只欠东风"的状态。
提交阶段:如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback) 消息;否则，发送提交(Commit) 消息;参与者根据协调者的指令执行提交或者回滚操作,释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

计算机网络

网络系统生命周期划分为5个阶段：需求规范、通信规范、逻辑网络设计、物理网络设计、实施阶段。

网络逻辑结构设计是体现网络设计核心思想的关键阶段,在这一阶段根据需求规范和通信规范,选择一种比较适宜的网络逻辑结构,基于该逻辑结构实施后续的资源分配规划、安全规划等内容。
物理网络设计是对逻辑网络设计的物理实现，通过对设备的具体物理分布、运行环境等的确定,确保网络的物理连接符合逻辑连接的要求。在这一阶段,网络设计者需要确定具体的软硬件、连接设备、布线和服务。
现有网络体系分析的工作目的是描述资源分布，以便于在升级时尽量保护已有投资,通过该工作可以使网络设计者掌握网络现在所处的状态和情况。
需求分析阶段有助于设计者更好地理解网络应该具有什么功能和性能，最终设计出符合用户需求的网络,它为网络设计提供依据。

RAID5的容量，计算公式为最小的盘容量 * （n-1）个盘

例题：

假如有3块容量是80G的硬盘做RAID 5阵列，则这个RAID 5的容量是(160G ) ;

而如果有2块80G的盘和1块40G的盘，此时RAID 5的容量是(80G)。

协议	说明
IPSec	IP网络提供安全性的协议和服务的集合，它是VPN（Virtual Private Network，虚拟专用网）中常用的一种技术
L2TP	是一种工业标准的Internet隧道协议，功能大致和PPTP协议类似，比如同样可以对网络数据流进行加密
PGP	是一种工业标准的Internet隧道协议，功能大致和PPTP协议类似，比如同样可以对网络数据流进行加密
PPTP	与L2TP都属于动态IP连接好的隧道协议

核心层
汇聚层完成路由汇总和协议转换功能
数据包过滤与策略路由的功能是由汇聚层来完成的
接入层应提供---部分管理功能，例如MAC地址认证、计费管理等
接入层负责收集用户信息，例如用户IP地址、MAC地址、访问日志等

嵌入式

设计考虑 硬件无关性 才能保证软件良好的移植性

嵌入式实时操作系统兼具嵌入式操作系统的特点和实时操作系统的特点。（没有通用性的特点）

嵌入式操作系统主要有以下特点:

微型化
代码质量高
专业化
实时性强
可裁减、可配置

实时操作系统的最核心特点是实时性强。

信息系统

数据集成的目的是实现不同系统的数据交流与共享，是进行其他更进一步集成的基础。
应用系统的集成是实现不同系统之间的互操作,使得不同应用系统之间能够实现数据和方法的共享
业务流程的集成使得在不同应系统中的流程能够无缝连接，实现流程的协调运作和流程信息的充分共享。

企业战略数据模型分为数据库模型和数据仓库模型

数据库模型用来描述日常事务处理中的数据及其关系
数据仓库模型则描述企业高层管理决策者所需信息及其关系。

关键成功因素法(CSF) :分析找出使得企业成功的关键因素,然后再围绕这些关键因素来确定系统的需求,并进行规划。

在现行系统中，总存在着多个变影响系统目标的实现，若干个因素是关键的和主要的(即关键成功因素)。通过对关键成功因素的识别，找出实现目标所需的关键信息集合,从而确定系统开发的优先次序 。关键成功因素来自于组织的目标，通过组织的目标分解和关键成功因素识别、性能指标识别，一直到产生数据字典。

企业信息化建设是通过IT技术 的部署来提高企业的生产运维效率,从而降低经营成本。这个过程中业务流程的管理与知识的挖掘 是重要的活动。因为在进行信息化过程中，由于计算机技术的引入，使得企业原本手工化的业务流程需要优化，从而适应计算机化的快速处理。

同时从企业已积累的资源库中,挖掘有价值的信息，也是信息化建设的点，这些知识的挖掘，能给企业带来丰厚的利润。

集成管理是企业信息资源管理的主要内容之一。实行企业信息 资源集成的前提是对企业历史上形成的企业信息功能的集成，其核心是对企业内部和外部信息流 的集成，实施的基础是各种信息手段的集成。

通过集成管理实现企业信息系统各要素的优化组合,使信息系统各要素之间形成强大的协同作用,从而最大限度地放大企业信息的功能，实现企业可持续发展的目的。

商业智能的核心技术包括:数据仓库、数据挖掘、联机分析处理。

系统配置与性能评价

在Web服务器的测试中，反映其性能的指标主要有:最大并发连接数、响应延迟、连接速度和吞吐量等。（不包括链接正确跳转）
常见的Web服务器性能评测方法有基准性能测试、压力测试和可靠性测试（不包括功能测试、黑白盒测试）。

系统安全分析与设计

数字证书上的签名，可以通过CA对数字证书的签名来核实有效性。这个动作是用来验证网站的真伪而不能验证客户方的真伪。

SNMPv3把对网络协议的安全威胁分为主要的和次要的两类。

标准规定安全模块必须提供防护的两种主要威胁是:

修改信息:就是某些未经授权的实体改变了进来SNMP报文,企图实施未经授权的管理操作，或者提供虚假的管理对象。
假冒:即未经授权的用户冒充授权用户的标识，企图实施管理操作。

必须提供防护的两种次要威胁是:

修改报文流:由于SNMP协议通常是基于无连接的传输服务，重新排序报文流、延迟或重放报文的威胁都可能出现。这种威胁的危害性在于通过报文流的修改可能实施非法的管理操作。
消息泄露: SNMP弓|擎之间交换的信息可能被偷听，对于这种威胁的防护应采取局部的策略。

不必提供防护的威胁包括:

拒绝服务:因为在很多情况下拒绝服务和网络失效无法区别，所以可以由网络管理协议来处理,安全子系统不必采取措施。
通信分析:即由第三者分析管理实体之间的通信规律，从而获取需要的信息。于通常都是由少数管理站来管理整个网络的，所以管理系统的通信模式是可预见的，防护通信分析就没有多大作用了。

操作系统

信号量S的物理意义

S大于等于0，代表系统资源可用数

S小于0，其绝对值代表等待资源的进程数。

数学

答案：

关键路径题目：

其中，作业C所需的时间，乐观估计为5天，最可能为14天，保守估计为17天。假设其他作业都按计划进度实施，为使该项目按进度计划如期全部完成。作业C ( )。

A.必须在期望时间内完成

B.必须在14天内完成

C.比期望时间最多可拖延1天

D.比期望时间最多可拖延2天

答案：

首先使用3点估算法计算出C的所需天数: (5+14*4+17) /6=13。

然后构造网络图,计算关键路径,关键路径为: ABDEG,长度27, C不在关键路径上。进-步计算C的总时差,会发现C的总时差为2,所以C可以比期望时间最多拖延2天。