架构师考点汇总
较集中知识点
待调整
质量属性
功能性 （Functionality）、性能（Performance）、 可靠性 （Reliability）、可用性（Availability）、安全性（Security）、 互操作性（Inter-operation）
易用性（Usability）、可测试性（Testability）、可变性（Changeability）、可修改性（Modification）、健壮性（Robustness）
共11个属性， 记忆：
效用树 4个重要组成：
安全性、可用性、可修改性、性能 －－》记忆：安用改性
有提到 6 个的：安用改性测易
其它的次要：功测靠操易变壮
风险点、非风险点、敏感点与权衡点
系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
敏感点是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。
敏感点和权衡点都是在软件架构中所做的关键决策，不同的是，敏感点决策只影响一个软件质量属性，而权衡点则同时影响多个质量属性，有时不同属性间还会互相冲突，比如选择不同的加密方式同时影响性能和安全性，所以需要权衡。
风险承担者是指那些关心软件架构，个人利益受软件架构好坏影响的人，在项目管理领域也称为项目干系人或涉众。这照些人整体上又可以分为系统的生产者和系统的消费者。生产者包括架构师，开发人员，维护人员，测试人员等；消费者包括客户，最终用户等。
构架设计方案应让各风险承担者积极参与评估
10）功能性
功能性是系统所能完成所期望工作的能力。
1）性能
性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。
代表参数：响应时间、吞吐量
设计策略：增加计算资源、改善资源需求（减少计算复杂度等）、资源 调度（先进先出队列、优先级队列等）、资源管理（并发、数据复制等）。
2）可用性
可用性（availability）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
代表参数：故障间隔时间
设计策略：冗余、心跳、Ping/Echo、异常。
3）安全性
安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
设计策略：抵御攻击（授权、认证和限制访问等）、追踪审计、信息隐藏、攻击检测（入侵检测等）、从攻 击中恢复（部分可用性策略）。
4）可修改性
可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。
设计策略：软件模块泛化、 限制模块之间通信、使用中介和延迟绑定。局部化变更、防止连锁反应、推迟绑定时间
6）健壮性
健壮性是指在处理或环境中，系统能够承受压力或变更的能力。
7）可变性
可变性是指体系结构经扩充或变更成为新体系结构的能力。
8）易用性
易用性是衡量用户使用一个软件产品完成指定任务的难易程度。
分离用户接口、支持用户主动、用户模型
9）可测试性
可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提 下，进行测试设计、测试执行的能力。
11）互操作性
互操作性是指系统与外界或系统与系统之间的相互作用能力。
5）可靠性
可靠性（Reliability）是指产品在规定的条件下和规定的时间内完成规定功能的能力。其子特性包括成熟性，容错性，易恢复性，可靠性，依从性。
5.1.影响因素：
运行环境（软件可靠性的定义是相对于运行环境的）；软件规模；软件内部结构（内部结构越复杂，包含的缺陷数就可能越多）；软件的开发方法和开发环境；软件的可靠性投入等。
5.2.遵循原则：1、软件可靠性设计是软件设计的一部分，必须在软件的总体设计框架中使用，并且不能与其他设计
原则相冲突。2、软件可靠性设计在满足提高软件质量要求的前提下，以提高和保障软件可靠性为最终目标。3、软件可靠性设计应确定软件的可靠性目标，不能无限扩大，并且排在功能、用户需求、开发费用之后考虑。
5.3.可靠性分析方法： 在软件可靠性设计之前和软件可靠性设计过程中，都需要采用软件可靠性分析和预|测方法，来确定当前系统中的主要可靠性因素和目标。常见的软件可靠性分析方法包括故障树分析方法、失效模式与效应分析方法等。
故障树分析方法：一种自顶向下的软件可靠性分析方法，即从软件系统不希望发生的事件（顶 事件)，特别是对人员和设备的安全及可靠性产生重大影响的事件开始，向下逐步追查导致顶事件发生的原因，直至基本事件（底事件)，从而确定软件故障原因的各种可能组合方式和（或）发生概率。基本的步骤是软件故障树的建立、定性分析和定量分析。
失效模式与效应分析方法：在软件开发阶段的早期，通过识别软件失效模式，分析造成的后果，研究分析各种失效模式产生的原因，寻找消除和减少其有害后果的方法，以便尽早发现潜在的问题，并采取相应的措施,从而提髙软件的可靠性和安全性。SFMEA的分析对象可以是开发早期阶段的高层次的子系统、部件，也可以是详细设计阶段的单元、模块。对于不同的分析对象，其软件失效模式是不同的，采用的SFMEA分析方法也不同，前者采用系统级分析方法（systemFMEA)，后者为详细级分析方法（detailedFMEA)。其基本的步骤是系统定义、软件失效模式分析、软件失效原因分析、软件失效影响分析、改进措施分析。
5.4.设计策略：(1)容错设计（N版本程序设计、恢复块方法 、冗余设计、双机热备或集群系统 ） (2)检错设计 (3)降低复杂度设计
(1)错设计技术：对于软件失效后果特别严重的场合，如飞机的飞行控制系统、空中交通管制系统等，采用容错设计技术。常见的容错设计技术有三种：恢复块设计、N版本程序设计和冗余设计。(a)恢复块设计：选择一组软件操作作为容错设计单元，把普通的程序块变成恢复块。一个恢复块包含有若千个功能相同、设计差异的程序块文本，一个运行文本，多个备份文本，构成“动态冗余”，一旦运行文本出现故障，则用备份文本替换。软件容错的恢复块方法就是使软件包含有一系列恢复块。(b)N版本程序设计：N版本程序的核心是通过设计出多个模块或不同版本，对于相同初始条件和相同输入的操作结果，实现多数表决，防止其中某一软件模块/版本的故障提供错误的服务，以实现软件容错。 (c)冗余设计：在一套完整的软件系统之外，设计一种不同路径、不同算法或不同实现方法的模块或系统作为备份，在出现故障时可以使用冗余的部分进行替换，从而维持软件系统的正常运行。缺点是费用和资源的消耗会有所增加。
(2)检错技术：在软件系统中，无需在线容错的地方，或不能采用冗余设计技术的部分，如果对可靠性要求较高，故障有可能导致严重的后果时，一般采用检错技术，在软件出现故障后能及时发现并报警，其缺点是不能自动解决故障。
(3)降低复杂度设计：软件复杂性与软件可靠性有着密切的关系，是产生软件缺陷的重要根源。在设计时考虑降低软件的复杂性，是提高软件可靠性的有效方法。降低复杂度设计的思想是在保证实现软件功能的基础上，简化软件结构，缩短程序代码，优化软件数据流向，降低软件复杂度，从而提高软件可靠性。
属性效用树示例：
质量属性 属性求精 场景
安全性 访问的安全性 在web服务中，应该有防火墙保护，防止网络上的非法数据请求**( M, H )**
安全性 数据的完整性 当出现异地订票点同时需要对通一张票请求操作时，系统必须保证数据库内数据的完整性**(H, L)**
可用性 异常检测和抛出 用户企图输入不符合系统条件的查询或者订购不存在的票务的时候，系统必须检测出，并且抛出相应的异常，转入挂起操作
可修改性 信息管理 为了适应变化得票务数据，系统必须提供一个后台管理界面**( M, L )**
性能 等待时间 用户在界面上进行票务查询或者进行订购操作的时候，系统必须在规定的时间内做出反应，不能出现用户无故长时间等待的情况。( H, M )
高项中出现的质量特性：
架构评估方法
传统软件架构评估方法按评估形式，一般分为三种:
一是调查问卷法，即直接请对系统架构了解的专家学者对系统架构做出主观评估。
二是度量法，即将软件系统架构完全量化，通过一些客观的数字指标来评估架构的好坏。
三是场景评估法，即挑选出重要的系统使用场景(一系列有序的使用或修改系统的步骤，即系统涉众如何使用系统的 )，根据不同场景中各架构的表现分别作评估，主客观程度介于前面两种方法之间。
场景评估法划分：架构权衡分析法ATAM(Architachture Tradeoff Analysis Method)，软件架构分析法SAAM，成本效益分析法CBAM。
ATAM通过理解体系结构方法来分析体系结构，评估过程分9个步骤
1- 描述ATAM方法 ATAM描述
即评估小组负责人向参加会议的风险承担者介绍ATAM评估方法，让大家清楚接下来要做什么，每个人的角色和任务。
2- 描述业务动机 商业动机表述
项目经理从业务角度介绍系统的概况，一般包括业务环境，背景，业务约束条件，技术约束，质量属性需求等内容。
3- 描述体系结构 软件架构表述
首席设计师或设计小组对体系结构进行详略适当的介绍。包括技术约束，与本统交互的其他系统，用以满足质量属性要求的体系结构方法（功能，模块，进程，硬件）。
4- 确定体系结构方法 确认架构方式
由设计师确定体系结构方法，由分析小组捕获，但不进行分析。
5- 生成质量属性效用树 生成效用树
评估小组，设计小组，管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些目标设置优先级和细化。
6- 分析体系结构方法 分析构架方式
7- 讨论分级场景 确定场景及其优先级
8- 分析体系结构方法 进一步分析架构方式
9- 描述评估结果 得出结论
SAAM（软件系统架构分析方法），它也是一种基于场景的评估方法，最早用于分析体系结构的可修改性，后来也用于其他质量属性的评估。相比于SAAM，要简单许多，主要包括如下6个步骤：
形成场景
描述体系结构
对场景进行分类和确定优先级
对间接场景进行单个评估
评估场景的相互作用
形成总体评价
下面分别给大家说明一下。
1.形成场景
指的是风险承担者们集中在一起，集体讨论，提出一个个系统需求场景。记录人员把这些场景记录在册，形成文档的过程。
2.描述体系结构
指的是体现结构设计师，对待评估的体系结构进行适当的描述，包括静态属性和动态特征，可以用自然语言也可以用形式化手段，以让参加评估的所有人员都能充分理解。
这一步骤和上一个形成场景的步骤可以合并在一起，重复进行多次。
3.对场景进行分类和确定优先级
系统可分为直接场景和间接场景，直接场景指的是本体系结构可以直接支持的场景，即不需要对体系结构做任何修改即可直接实现。
另外一种间接场景则是需要对现有体系结构做些更改才能支持的场景。
最后用投票的方法，确定间接场景的重要性优先级，以便大家将有限的时间花在最重要的事情上。
4.对间接场景进行单个评估
就是将选出来的重要场景与体系结构描述对应起来。体系结构设计师具体说明体系结构需要做哪些修改变更才能适用间接场景的要求，并估计这些变更的代价。
最后形成一份全部场景的总结性列表。
列表字段包括：场景编号、场景描述、直接/间接、需要做的更改、更改/新增构建数量、更改工作量估计
5.评估场景的相互作用
当两个或多个间接场景需要修改到同一个构建时，这时场景就在这个构件上出现了相互作用，需要特别评估。
出现这种情况，往往是设计方案中功能分配不合理，或者是设计文档未能充分说明体系结构。
6.形成总体评价
最后，评估人员对场景和场景间的相互作用做一个总体的权衡和评价。通过各个场景权重与分值得出一个总体的评价，从多个体系结构，或者一个体系结构的不同设计方案选择出一个最优的方案。
评价程序评价机器性能
小型基准程序：代码行数比较少，通常是测试算法；
真实程序：所有程序全部测评，准确性最高；
核心程序：真实程序中具有代表性的代码；
合成基准程序：人为合成基准程序，准确性最低。
设计原则
开闭原则：对扩展开放，对修改关闭。
里氏替换原则：在使用父类的地方，都能使用其子类，不需要进行修改（反过来不成立）。
最少知识：一个软件实体应该尽可能少的与其他实体相互作用。
依赖倒置：抽线不依赖于细节，细节依赖于抽象。针对接口编程，不针对实现编程。
测试相关
软件集成测试也称为组装测试、联合测试(对于子系统而言，则称为部件测试)。它将已通过单元测试的模块集成在一起，主要测试模块之间的协作性。从组装策略而言，可以分为一次性组装测试和增量式组装(包括自项向下、自底向上及混合式)两种。集成测试计划通常是在软件概要设计阶段完成的，集成测试一般采用黑盒测试方法。
根据国家标准GB／T 15532-2008，软件测试可分为单元测试、集成测试、配置项测试、系统测试、验收测试和回归测试等类别。
单元测试：也称为模块测试，测试对象为模块。测试模块的功能，性能等是否达到标准。其目的是检查每个模块能否正确地实现设计说明中的功能、性能、接口和其他设计约束等条件，发现模块内可能存在的各种差错。（白盒测试， 依据：软件的详细设计）；
集成测试：目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。模块与模块之间，软件与集成之间的（黑盒测试，依据：软件的概要设计）；
系统测试：对象是完整的、集成的计算机系统。目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统／子系统设计文档和软件开发合同规定的要求。在真实系统中，验证配置项是否和系统能成功连接，达到规定要求（依据：用户需求或开发合同）；
常见的系统测试主要有恢复测试、安全性测试、压力测试、性能测试、可靠性测试、可用性测试、可维护性测试和安装测试。不包括路径测试。
配置项测试：对象是软件配置项。目的是检验软件配置项与软件需求规格说明的一致性。
确认测试：主要验证软件的功能、性能和其他特性是否与用户需求一致。验收测试是指针对软件需求规格说明，在交付前以用户为主进行的测试。
回归测试：测试软件变更后的正确性；目的是测试软件变更之后，变更部分的正确性和对变更需求的复合型，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。
白盒测试：也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。 白盒测试逻辑驱动方法：语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 条件组合覆盖 路径覆盖
黑盒测试：一种从软件外部对软件实施的测试，也称功能测试或基于规格说明的测试。其基本观点是：任何程序都可以看作是从输入定义域到输出值域的映射，这种观点将被测程序看作一个打不开的黑盒，黑盒里面的内容(实现)是完全不知道的，只知道软件要做什么。因无法看到盒子中的内容，所以不知道软件是如何实现的，也不关心黑盒里面的结构，只关心软件的输入数据和输出结果。主要根据功能需求设计测试用例，进行测试。常用方法：等价类划分 边界值分析 因果图 决策表分析
灰盒测试：是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。
静态测试工具可用于对软件需求、结构设计、详细设计和代码进行评审、走查和审查。
静态测试工具可对软件的复杂度分析、数据流分析、控制流分析和接口分析提供支持。
静态测试包括对文档的静态测试和对代码的静态测试。对代码的静态测试包括控制流分析、数据流分析、接口分析和表达式分析。
动态测试需要运行被测试系统，并设置探针，向代码生成的可执行文件中插入检测代码，可用于软件的覆盖分析和性能分析，也可用于软件的模拟、建模、仿真测试和变异测试等。
软件维护：
1 正确性(改正性、纠错性)维护。改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。
2 适应性维护。在使用过程中，外部环境(新的硬、软件配置)、数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质)可能发生变化。为使软件适应这种变化，而去修改软件的过程就称为适应性维护。
3 完善性维护。在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动称为完善性维护。
4 预防性维护。这是指为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。
速记：预适改完
遗留系统策略
遗留系统的演化可以采用淘汰、继承、改造和集成四种策略
①淘汰策略。第四象限为低水平、低价值区，即遗留系统的技术含量较低，且具有较低的业务价值。
②继承策略。第二象限为低水平、高价值区，即遗留系统的技术含量较低，已经满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业的业务尚紧密依赖该系统。
③改造策略。第一象限为高水平、高价值区，即遗留系统的技术含量较高，本身还有强大的生命力。系统具有较高的业务价值，基本上能够满足企业业务运作和决策支持的需要。
④集成策略。第三象限为高水平、低价值区，即遗留系统的技术含量较高，但其业务价值较低，可能只完成某个部门(或子公司)的业务管理。
象限：
业务价值高 继承 改造
业务价值低 淘汰 集成
技术水平低 技术水平高
杂项
统一过程（UP/RUP）具有三个显著特征：用例驱动、以体系结构为中心、迭代和增量。
ABSD（基于架构的软件开发）架构驱动的：商业、质量、功能需求。
ABSD描述软件架构：视角、视图；
ABSD描述需求：用例，质量场景；
ABSD三个基础：功能分解、架构风格的选择、软件模板的使用；
DSSA（特定领域软件架构）的基本活动：
领域分析：获取领域模型【获取领域需求】；
领域设计：获取DSSA【能够适应领域中多个系统需求的一个高层次设计】；
领域实现：依据领域模型及DSSA开发和组织可重用信息。
仓库风格两种不同构件。
中央数据结构说明当前状态。独立构件在中央数据存储上执行。（速记：中状，构中）
