【2022下架构真题第24题：红色】
24.在分布式系统中，中间件通常提供两种不同类型的支持，即（27)
A.数据支持和交互支持
B.交互支持和提供公共服务
C.数据支持和提供公共服务
D.安全支持和提供公共服务
解答：答案选择B。考察构件中间件的知识
在一个分布式系统中，中间件通常提供两种不同类型的支持：
1、交互支持，中间件协调系统中的不同组件之间的交互。
2、提供公共服务，即中间件提供对服务的可复用的实现。这些服务可能会被分布式系统中的很多组件所需要。
公共服务是指被不同组件需求的服务，不管这些组件的功能是什么。这些服务，你可以把这些服务看做是中间件容器提供的。可以在这个容器中部署你的组件并且这些组件可以访问和使用这些公共服务。答案选择B选项。
【2022下架构真题第12题：红色】
12.通常，嵌入式中间件没有统一的架构风格，根据应用对象的不同可存在多种类型，比较常见的是消息中间件和分布式对象中间件。以下有关消息中间件的描述中，不正确的是（ )。
A.消息中间件是消息传输过程中保存消息的一种容器
B.消息中间件具有两个基本特点：采用异步处理模式、应用程序和应用程序调用关系为松耦合关系
C.消息中间件主要由一组对象来提供系统服务，对象间能够跨平台通信
D.消息中间件的消息传递服务模型有点对点模型和发布﹣订阅模型之分
解答：答案选择C。
分布式对象中间件主要由一组对象来提供系统服务，对象间能够跨平台通信。这里不是消息中间件。
消息中间件是在消息的传输过程中保存信息的容器。消息中间件再将消息从它的源中继到它的目标时充当中间人的作用。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它为止，当然，消息队列保存消息也是有期限的。
消息中间件的特点：
(1）采用异步处理模式。
消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一条虚拟的通道（主题或队列）上，消息接收者则订阅或是监听该通道。一条信息可能最终转发给一个或多个消息接收者，这些接收者都无需对消息发送者做出同步回应。整个过程都是异步的。
(2）应用程序和应用程序调用关系为松耦合关系。
主要体现在如下两点：发送者和接受者不必了解对方、只需要确认消息；发送者和接受者不必同时在线。比如在线交易系统为了保证数据的最终一致，在支付系统处理完成后会把支付结果放到消息中间件里通知订单系统修改订单支付状态。两个系统通过消息中间件解耦。
消息中间件的传输模式：
(1）点对点模型
点对点模型用于消息生产者和消息消费者之间点到点的通信。消息生产者将消息发送到由某个名字标识的特定消费者。这个名字实际上对于消费服务中的一个队列( Queue )，在消息传递给消费者之前它被存储在这个队列中。队列消息可以放在内存中也可以是持久的，以保证在消息服务出现故障时仍然能够传递消息。
(2）发布﹣订阅模型（ Pub / Sub )
发布者／订阅者模型支持向一个特定的消息主题生产消息。
【2022下架构真题第28题：绿色】
28.领域驱动设计提出围绕（31）进行软件设计和开发，该模型是由开发人员与领域专家协作构建出的一个反映深层次领域知识的模型。
A.行为模型
B.领域模型
C.专家模型
D.知识库模型
解答：答案选择B。信息系统开发方法考察。
领域驱动设计强调领域模型的重要性，并通过模型驱动设计来保障领域模型与程序设计的一致。从业务需求中提炼出统一语言（ Ubiquitous Language )，再基于统一语言建立领域模型；这个领域模型会指导着程序设计以及编码实现；最后，又通过重构来发现隐式概念，并运用设计模式改进设计与开发质量。领域模型是由开发人员与领域专家协作构建出的一个反映深层次领域知识的模型。
领域模型其实就是领域需求 ，狭义上讲就是需求，只不过是与领域结合。
2022下架构真题第29题：绿色】
29.以下关于微服务架构与面向服务架构的描述中，正确的是（32)。
A.两者均采用去中心化管理
B.两者均采用集中式管理
C.微服务架构采用去中心化管理，面向服务架构采用集中式管理
D.微服务架构采用集中式管理，面向服务架构采用去中心化管理
解答：答案选择C。考察面向服务的架构。
微服务架构使用去中心化的扁平化管理方式，每个服务都是一个独立的应用程序，独立管理、使用独立的数据库、独立部署和独立运行。 SOA 是一种整体式架构，使用集中式的管理方式和统一的数据中心。答案选择 C 选项。
【2022下架构真题第31题：绿色】
32.以下有关构件特征的的描述，说法不正确的是（35)
A.构件是独立的部署单元
B.构件可作为第三方的组装单元
C.构件没有外部的可见状态
D.构件作为部署单元是可拆分的
解答：答案选择D。本题考察的是构件定义这个知识点。
构件的定义
定义1：
软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。
定义2：
构件是某系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系构语境内满足某清晰的功能。
定义3：
构件是一个独立发布的功能部分，可以通过其接口访问它的服务。
构件的特性：
1、独立部署单元；
2、作为第三方的组装单元；
3、没有（外部的）可见状态。
构件的特性只有以上三点， D 选项说法不正确，所以答案选 D 。
【2022下架构真题第32题：绿色】
32.在构件的定义中，(36）是一个已命名的一组操作的集合。
A.接口
B.对象
C.函数
D.模块
解答：答案选择A。
接口是一个已命名的一组操作的集合。构件的客户（通常是其他构件）通过这些访问点来使用构件提供的服务。通常来说，构件在不同的访问点有多个不同的接口。每一个访问点会提供不同的服务，以迎合不同的客户需求。强调构件接口规范的合约性非常重要，因为构件和它的客户是在互不知情的情况下分别独立开发的，是合约提供了保证两者成功交互的公共中间层。答案选择 A 选项。
【2022下架构真题第33题：红色】
33.在服务端构件模型的典型解决方案中，(37)较为适用于应用服务器。
A.EJB和COM+模型
B.EJB和Servlet模型
C.COM+和ASP模型
D.COM＋和Servlet
解答：答案选择A。考差了中间件概念知识点。
关于服务端构件模型的典型解决方案包括适用于应用服务器的 EJB 模型（Sun公司J2EE的一部分）和 COM ＋模型（微软公司），以及适用于 Web 服务器的 servlet 模型（基于Sun公司 JSP 技术）和 Visual Basic 及其他技术（基于微软公司 ASP 技术）微软的。 NET 框架还引入了一种新的同时适用于客户端和服务端的基于 CLI ( Command Line Interface ）的构件模型。所以答案选择A选项。
【2022下架构真题第34题：绿色】
34.以下有关构件演化的描述中，说法不正确的是（38)
A.安装新版本构件可能与现有系统发生冲突
B.构件通常也会经历一般软件产品具有的演化过程
C.解决遗留系统移植问题，还需要通过使用包裹器构件，更适配旧版软件
D.为安装新版本的构建，必须终止系统中所有已有版本构件后运行
解答：答案选择D。
构件技术体现了一种后期组装的思想。构件的逐渐成熟会进一步推后组装（或绑定）时间，但随之而来的是整个系统将变得越来越脆弱。构件通常也会经历一般软件产品具有的演化过程。安装新版本的构件将会与期望使用旧版本构件的现有系统发生冲突，甚至直接与现存的旧版本构件实例发生冲突。相对于已经实例化的构件，一个构件从构件库中被获取并实例化的时间越晚，潜在的版本冲突问题就会越严重。在分布式系统中，为安装新版本的构件实例而终止所有现有构件的运行是不现实的。不同版本的客户端和不同版本的构件实例之间的二进制互操作性需要在版本间二进制兼容性中就加以考虑。如何实现构件实例的在线版本升级仍然是一个非常活跃的研究领域。在实际配置中，必须考虑构件的不同版本实例共存于一个系统的情况。系统的升级就是一个重要的例子。除采用多版本共存技术之外，解决"遗留系统移植"问题还需要通过使用包裹器构件来适配旧版软件或解决系统不兼容性。综上， D选项的说法是不正确的，所以答案选 D 选项。
【2022下架构真题第40题：绿色】
40.在软件体系结构的建模与描述中，多视图是一种描述软件体系结构的重要途径，其体现了（44）的思想。其中，4+1模型是描述软体系结构的常用型，在该模型中，“1”指的是（45),
A.关注点分离
B.面向对象
C.模型驱动
D.UML
》
A.统一场景
B.开发视图
C.逻辑视图
D.物理视图
解答：答案选择A|A。
多视图表示从不同的视角描述特定系统的体系结构，从而得到多个视图，并将这些视图组织起来以描述整体模型。系统的每一个不同侧面的视图反映了一组系统相关人员所关注的系统的特定方面，多视图体现了关注点分离的思想。其中，4+1模型是描述软件体系结构的常用模型，"4+1"视图模型从逻辑视图、进程视图、物理视图、开发视图和场景来描述软件架构。每个视图只关心系统的一个侧面，结合在一起才能反映系统软件架构的全部内容。在该模型中，"1"指的是统一场景。所以第一空答案为 A 选项，第二空答案也为 A 选项。
【2022下架构真题第41题：黄色】
41.基于体系结构的软件设计（Architecture -Based Software Design . ABSD )方法是体系结构驱动，是指构成体系结构的（46）的组合驱动的。 ABSD方法是一个自项向下、递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生（47)
A.产品、功能需求和设计活动
B.商业、质量和功能需求
C.商业、产品和功能需求
D.商业、质量和设计活动
》
A.软件产品和代码
B.软件构件和类
C.软件构件和连接件
D.类和软件代码
解答：答案选择B|B。
基于架构的软件设计（ Architecture - Based Software Design , ABSD ）方法强调由商业(业务)、质量和功能需求的组合驱动软件架构设计。 ABSD 是一个自顶向下，递归细化的软件开发方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。它以软件系统功能的分解为基础，通过选择架构风格实现质量和商业需求，并强调在架构设计过程中使用软件架构模板。 ABSD方法有三个基础：第一个基础是功能分解，在功能分解中使用已有的基于模块的内聚和耦合技术。第二个基础是通过选择体系结构风格来实现质量和商业需求。第三个基础是软件模板的使用。所以第一空答案为 B 选项，第二空答案也为 B 选项
补充知识：
基于架构的软件设计ABSD
ABSD方法是架构驱动，强调由业务(商业--商业需求经提炼转为业务需求)、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。进一步来说，用例描述的是功能需求，质量属性场景描述的是质量需求(或侧重于非功能需求)。
使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成，就开始了软件设计。--从需求获取就可以开始软件设计了
ABSD方法有三个基础。
- 第一个基础是功能的分解，使用已有的基于模块的内聚和耦合技术；
- 第二个基础是通过选择架构风格来实现质量和业务需求；
- 第三个基础是软件模板的使用，软件模板利用了一些软件系统的结构。
ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，有助于降低架构设计的随意性。
架构设计是在需求之后，概设之前，是为了解决需求分析和软件设计质检的鸿沟问题，基于体系结构的软件开发过程六步：
定需求--->设计--->文档化--->复审--->实现--->演化
1.架构需求：重点是标识构件三步
需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。架构需求受技术环境和架构设计师的经验影响。需求过程主要是获取用户需求，标识系统中所要用到的构件，以前有类似的可从需求库里取出进行修改使用，提升效率。
先获取，生类图，类分组，类打包成构件，最后评审
标识构件
-------------------------------------------------------
需求获取--->|生成类图--->对类分组--->把类打包成构件|--->需求评审
| ------------------------------------------------------- |
| |
-----------------------------------------------------------------------------
0：N
（1）需求获取
架构需求一般来自三个方面，分别是 系统的质量目标 、 系统的业务目标 和 系统开发人员的业务目标 。软件架构需求获取过程主要是定义开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务上的功能需求。与此同时，还要获得软件质量属性，满足一些非功能需求。
（2）标识构件
标识构件过程为系统生成初始逻辑结构，包含大致的构件。这一过程又可分为三步来实现。
- 第一步：生成类图。生成类图的 CASE 工具有很多，例如 Rational Rose 就能自动生成类图。
- 第二步：对类进行分组。在生成的类图基础上，使用一些标准对类进行分组可以大大简化类图结构，使之更清晰。一般地，与其他类隔离的类形成一个组，由泛化关联的类组成一个附加组，由聚合或组合关联的类也形成一个附加组。
- 第三步：把类打包成构件。把在第二步得到的类簇打包成构件，这些构件可以分组合并成更大的构件。
（3）需求评审
组织一个由不同代表（如分析人员、客户、设计人员、测试人员）组成的小组，对架构需求及相关构件进行仔细的审查。审查的主要内容包括所获取的需求是否真实反映了用户的要求，类的分组是否合理，构件合并是否合理等。必要时，可以在“需求获取—标识构件—需求评审”之间进行迭代。
2.架构设计：需求阶段的标识构件映射成构件
架构需求用来激发和调整设计决策，不同的视图被用来表达与质量目标有关的信息。架构设计是一个迭代过程，如果要开发的系统能够从已有的系统中导出大部分，则可以使用已有系统的设计过程。
提出架构模型--->映射架构--->分析构件间相互作用--->产生架构--->设计评审
| |
-------------------------------------------------------------------
0：N
（1）提出软件架构模型
在建立架构的初期，选择一个合适的架构风格是首要的。在这个风格基础上，开发人员通过架构模型，可以获得关于架构属性的理解。此时，虽然这个模型是理想化的（其中的某些部分可能错误地表示了应用的特征），但是，该模型为将来的实现和演化过程建立了目标。
首先，选择合适的架构风格；其次，再风格的基础上通过架构模型来理解架构属性。
意义：提出的这个模型是将来实现和演化的目标。
（2）映射构件--------把已标识的构件映射到软件架构中
把在架构需求阶段已标识的构件映射到架构中，将产生一个中间结构，这个中间结构只包含那些能明确适合架构模型的构件。
把标识构件映射到架构中，产生的中间结构(中间结果的一种)，它包含了标识的和架构匹配的构件
（3）分析构件之间的相互作用
为了把所有已标识的构件集成到架构中，必须认真分析这些构件的相互作用和关系。
（4）产生软件架构
一旦决定了关键的构件之间的关系和相互作用，就可以在第 2 阶段得到的中间架构的基础上进行细化。
关键构件及其它们间的相互关系和作用确定了，在前面的中间架构基础上进行细化，产生软件架构。
（5）设计评审
一旦设计了软件架构，我们必须邀请独立于系统开发的外部人员对架构进行评审。
3.架构文档化
架构(体系结构)文档化：主要产出两种文档，即架构(体系结构)规格说明，测试架构(体系结构)需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败。
文档是在系统演化的每一个阶段，系统设计与开发人员的通信媒介，是为验证架构设计和提炼或修改这些设计（必要时）所执行预先分析的基础。
文档的完整性和质量是软件架构成功的关键因素。文档要从使用者的角度进行编写，必须分发给所有与系统有关的开发人员，且必须保证开发者手上的文档是最新的。
4.架构复审
架构设计、文档化和复审是一个迭代过程。
复审不过，则返回架构设计阶段进行 重新设计、文档化，再复审。
复审的目的是标识潜在的风险，以及早发现架构设计中的缺陷和错误，包括架构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求，等等。
5.架构实现
用实体来显示出架构。实现构件，构件组装成系统。
虚框部分是架构实现的过程，它是以复审后的文档化架构说明书(架构规格说明书)为基础的，每个构件必须满足软件架构中说明的对其他构件的责任。这些决定即实现的约束是在系统级或项目范围内做出的，每个构件上工作的实现者是看不见的。
按照设计提供的结构，通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成。
测试，包括单个构件的功能性测试和被组装应用的整体功能和性能测试。
(复审后的文档化架构说明书)
分析与设计--->构件实现--->构件组装--->系统测试
6.架构演化
对架构进行改变，按需求增删构件，使架构可复用。
用户需求变动，环境改变导致需求变化。
先分类，做计划，构件变动，更新作用，组装测试，评审，集成到架构
需求分类--->演化计划--->构件变动--->更新构件相互作用--->组装测试--->技术评审--->演化后架构
| |
---------------------------------------------------------------------------------
0:N
(1)需求变化归类
需求必须分类，把需求和已有的构件对应，找不到对应的(如新增的)也要标记好。
(2)架构演化计划
制定周密的计划，用于指导后续的演化。
(3)构件变动
根据前面的需求分类增删改构件
(4)更新构件间相互作用
增删改构件后，构件间的控制流必须更新
(5)构件组装和测试
通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成，形成新的架构。然后对组装后的系统的整体功能和性能进行测试。
(6)技术评审
评审组装后的架构是否反映需求变动，符合用户需求。如果不符合，则需要在第 2 到第 6 步之间进行迭代。
(7)演化后架构
产生演化后的架构在原来系统上所作的所有修改必须集成到原来的架构中。
真题
【2022下架构真题第42题：红色】
42.软件体系结构风格是描述某一特定应用领城中系统组织方式的惯用模式。其中，在批处理风格软件体系结构中，每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，并且数据必须是完整的，以（48）的方式传递，基于规则的系统包括规则集、规则解释器、规则数据选择器及（49)
A.迭代
B.整体
C.统一格式
D.递增
》
A.解释引擎
B.虚拟机
C.数据
D.工作内存
解答：答案选择B|D。重点关注。
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。其中，批处理风格的每一步处理都是独立的，并且每一步是顺序执行的。只有当前一步处理完，后一步处理才能开始。数据传送在步与步之间作为一个整体。（组件为一系列固定顺序的计算单元，组件间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在前一步结束后才能开始，数据必须是完整的，以整体的方式传递）
批处理的典型应用：
- (1）经典数据处理；
- (2）程序开发；
- (3) Windows 下的 BAT 程序就是这种应用的典型实例。
虚拟机风格的基本思想是人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样来增加架构的灵活性，虚拟机风格主要包括解释器和规则为中心两种架构风格。其中，基于规则的系统包括规则集、规则解释器、规则／数据选择器及工作内存。所以第一空答案为 B 选项，第二空答案为 D 选项。
补充一下架构风格知识：
改版前：PPT，14软件架构设计
【2022下架构真题第43题：黄色】
43.在软件架构复用中，(50）是指开发过程中，只要发现有可复用的资产，就对其进行复用。(51）是指在开发之前，就要进行规划，以决定哪些需要复用。
A.发现复用
B.机会复用
C.资产复用
D.过程复用
》
A.预期复用
B.计划复用
C.资产复用
D.系统复用
解答：答案选择A|D。第二空错选了B。
软件架构复用的类型包括机会复用和系统复用，机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用（有机会就用）。系统复用是指在开发之前，就要进行规划，以决定哪些需要复用(规划后系统性)。
【2022下架构真题第44题：绿色】
44.软件复用过程的主要阶段包括（52)
A.分析可复用的软件资产、管理可复用资产和使用可复用资产
B.构造/获取可复用的软件资产、管理可复用资产和使用可复用资产
C.构造／获取可复用的软件资产和管理可复用资产
D.分析可复用的软件资产和使用可复用资产
解答：答案选择B。考经验蒙对。
软件复用是指在软件开发过程中重复使用相同或相似软件元素的过程，是在软件开发中避免重复劳动的解决方案，它使得应用系统的开发不再采用一切从零开始的模式，而是以已有的工作模式为基础，充分利用过去应用系统开发中积累的知识和经验，从而将开发的重点集中于应用的特有构成成分。软件复用过程的主要阶段包括构造／获取可复用的软件资产、管理可复用资产和使用可复用资产。答案选择 B 选项。
【2022下架构真题第46题：绿色】
46.DSSA ( Domain Specific Software Architecture ）就是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构，实施 DSSA 的过程中包含了一个基本的活动。其中，领域模型是（53）阶段的主要目标。
A.领域设计
B.领域实现
C.领域分析
D.领域工程
解答：答案选择C。蒙对重点关注。------后面又关于DSSA的补充
特定领域软件架构（ Domain Specific Software Architecture , DSSA ）以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，其目标是支持一个特定领域中多个应用的生成。 DSSA 的基本活动包括领域分析、领域设计和领域实现。其中领域分析的主要目的是获得领域模型，领域模型描述领域中系统之间共同的需求，即领域需求；领域设计的主要目标是获得DSSA , DSSA 描述领域模型中表示需求的解决方案；领域实现的主要目标是依据领域模型和 DSSA 开发和组织可重用信息，并对基础软件架构进行实现。所以答案选择C选项。
46.软件系统质量属性（ Quality Attribute ）是一个系统的可测量或者可测试的属性，它被用来描述系统满足利益相关者需求的程度，其中，(54）关注的是当需要修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度，(55）关注的是当用户数和数据量增加时，软件系统维持高服务质量的能力。
A.可靠性
B.可测试性
C.可维护性
D.可重用性
》
A.可用性
B.可扩展性
C.可伸缩性
D.可移植性
解答：答案选择C|C。第二空错。
软件系统质量属性：
性能：指软件系统及时提供相应服务的能力。（速度、吞吐量、持续高速性）
安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
易用性：指软件系统易于被使用的程度。
可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
互操作性：与其他系统交换数据和相互调用服务的难易程度。
可靠性：在一定的时间内无故障运行的能力。
持续可用性：指系统长时间无故障运行的能力。与可靠性相关联，常将其纳入可靠性中。
鲁棒性：是指软件系统在一些非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等）下仍能够正常运行的能力。也称健壮性或容错性。
开发期质量属性：
易理解性：指设计被开发人员理解的难易程度。可扩展性：软件因适应需求变化而增加新功能的能力。也称为灵活性。
可重用性：指重用软件系统或某一部分的难易程度。可测试性：对软件测试以证明其满足需求规范的难易程度。
可维护性：当需要修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度。
可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。
47.为了精确描述软件系统的质量属性，通常采用质量属性场景（ Quality Attribute Scenario ）作为描述质量属性的手段。质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述，它由刺激源、刺激、环境、制品、(56）六部分组成。其中，想要学习系统特性、有效使用系统、使错误的影响最低、适配系统、对系统满意属于（57）质量属性场景的刺激。
A.响应和响应度量
B.系统和系统响应
C.依赖和响
D.响应和优先
》
A.可用性
B.性能
C.易用性
D.安全性
解答：答案选择A|C。
质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述，它由刺激源、刺激、环境、制品、响应和响应度量六部分组成。
刺激源：生成该刺激的实体（人、计算机系统或其他激励器）；
刺激：刺激到达系统时可能产生的影响（即需要考虑和关注的情况）；
环境：该刺激在某条件内发生。如系统可能正处于过载情况；
制品：系统中受刺激的部分（某个制品被刺激）；
响应：刺激到达后所采取的行动；
响应度量：当响应发生时，应能够以某种方式对应其度量，用于对是否满足需求的测试。所以第一空答案为 A 选项。
- 基于可用性质量属性场景的刺激为：错误：疏忽（构件对某输入未做出反映）、崩溃、时间不当（响应时间太早或太迟）、响应不当（以一个不正确的值来响应）。
- 基于可修改性质量属性场景的刺激为：增加／删除／修改／改变：功能、质量属性、容量。
- 基于性能质量属性场景的刺激为：定期事件、随机事件、偶然事件。
- 基于安全性质量属性场景的刺激为：试图：显示数据、改变／删除数据、访问系统服务、降低系统服务的可用性。
- 基于易用性质量属性场景的刺激为：学习系统特性、有效使用系统、使错误的影响最低、适配系统、对系统满意。
【2022下架构真题第48题：绿色】
48.改变加密级别可能会对安全性和性能产生非常重要的影响，因此在软件架构评估中，该设计决策是一个(58)。
A.敏感点
B.风险点
C.权衡点
D.非风险点
解答：答案选择C。送分题。
敏感点和权衡点是关键的架构决策。敏感点是一个或多个构件的特性。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。所以该设计决策是一个权衡点。所以答案为 C 选项。
【2022下架构真题第49题：红色】
49.效用树是采用架构权衡分析方法（ Architecture Trade off Analysis Method , ATAM ）进行架构评估的工具之一，其树形结构从根部到叶子节点依次为（59)。
A.树根、属性分类、优先级，质量属性场景
B.树根、质量属性、属性分类，质量属性场景
C.树根、优先级、质量属性、质量属性场景
D.树根、质量属性、属性分类，优先级
解答：答案选择B。错选择了C。
生成质量属性效用树过程：可以选取这样一棵树：根—质量属性﹣-属性分类（细分）—质量属性场景（叶）。修剪这棵树，保留重要场景（不超过50个），再对场景按重要性给定优先级（用 H / M / L 的形式），再按场景实现的难易度来确定优先级（用 H / M / L 的形式），这样对所选定的每个场景就有一个优先级对（重要度，难易度），如（ H , L ）表示该场景重要且易实现。
2022下架构真题第52题：红色】
52.在进行架构评估时，首先要明确具体的质量目标，并以之作为判定该架构优劣的标准。为得出这些目标而采用的机制叫做场景，场景是从（63）的角度对与系统的交互的简短措述。
A.用户
B.系统架构师
C.项目管理者
D.风险承担者
解答：答案选择D。选错在了用户。
场景（ scenarios )：在进行体系结构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。为得出这些目标而采用的机制叫做场景。场景是从风险承担者的角度对与系统的交互的简短描述。在体系结构评估中，一般采用刺激( stimulus )、环境（environment ）和响应（ response ）三方面来对场景进行描述。综上，答案为 D 选
SDN网络体系架构的三层模型：
协同应用层：这一层主要是体现用户意图的各种上层应用程序，此类应用程序称为协同层应用程序，典型的应用包括OSS（Operation support system 运营支撑系统）、Openstack等。传统的IP网络同样具有转发平面、控制平面和管理平面，SDN网络架构也同样包含这3个平面，只是传统的IP网络是分布式控制的，而SDN网络架构下是集中控制的。
控制层：控制层是系统的控制中心，负责网络的内部交换路径和边界业务路由的生成，并负责处理网络状态变化事件。
转发层：转发层主要由转发器和连接器的线路构成基础转发网络，这一层负责执行用户数据的转发，转发过程中所需要的转发表项是由控制层生成的
SDN的价值
第一，SDN为网络的使用、控制以及如何创收提供了更多的灵活性。
第二、SDN加快了新业务引入的速度。网络运营商可以通过可控的软件部署相关功能，而不必像以前那样等待某个设备提供商在其专有设备中加入相应方案。
第三、SDN降低了网络的运营费用，也降低了出错率，原因在于实现了网络的自动化部署和运维故障诊断，减少了网络的人工干预。
第四、SDN有助于实现网络的虚拟化，从而实现了网络的计算和存储资源的整合，最终使得只要通过一些简单的软件工具组合，就能实现对整个网络的控制和管理。
第五、SDN让网络乃至所有IT系统更好地以业务目标为导向。
构件、原子构件、模块、对象、构件接口：
1.构件是一个独立可交付的功能单元，外界通过接口访问其提供的服务。
2.构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模块和一组资源。原子
构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署，但是它也能够被单独
部署。构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被
单独部署。相反，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。
4.一个模块是不带单独资源的原子构件。
5.一个单独的包被编译成多个单独的类文件——每个公共类都有一个。
模块是一组类和可能的非面向对象的结构体，比如过程或者函数。
构件的特性是：
(1)独立部署单元；(2)作为第三方的组装单元；(3)没有(外部的)可见状态。
对象的特性是：(1)一个实例单元，具有唯一的标志。(2)可能具有状态，此状态外部可见。
(3)封装了自己的状态和行为。
一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。
将一个类拆分进行部署通常没什么意义。
构件接口
接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化七为参数化
操作的集合，而是关注输入输出的消息的标准化，它强调当机器在网络中互连时，标准的消息模式、格式、协议的重要性。
面向构件的编程(COP)
关注于如何支持建立面向构件的解决方案。“面向构件的编程需要下列基本的支持：
-—多态性(可替代性);
-—模块封装性(高层次信息的隐藏);
-—后期的绑定和装载(部署独立性);
-—安全性(类型和模块安全性)。
COM不支持任何形式的实现继承。
COM支持两种形式的对象组装：包含（Containment）和聚集（Aggregation）。
包含是一个对象拥有指向另一个对象的唯一引用。外部对象只是把请求转发给内部对象，所谓转发就是调用内部对象的方法。包含能重用内含于其他构件的实现，是完全透明的。如果包含层次较深，或者被转发的方法本身相对简单，包含会存在性能上的问题。因此 COM定义第二类重用形式，聚集。聚集直接把内部对象接口引用传给外部对象的客户，而不是再转发请求。保持透明性是很重要的，因为外部对象的客户无法辨别哪个特定接口是从内部对象聚集而来的。
【40-41】特定领域软件架构(Domam Specifie Sottware Architecture.DSSA)是指特定应用领域中为一组应用提供组织结构参考的标准软件架构。从功能覆盖的范围角度，（ ）定义了一个特定的系统族，包含整个系统族内的多个系统，可作为该领域系统的可行解决方案的一个通用软件架构；（ ）定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统族的特定部分功能。
A.垂直域
B.水平域
C.功能域
D.属性域
A.垂直域
B.水平域
C.功能域
D.属性域
垂直域关注的是通用特性；水平域关注的是共有部分。比如，在线教育系统和淘宝系统都有付费部分，这就是水平域；教育学习领域，在线教育系统和考研系统都有题库，考试等是垂直域。
某公司拟开发一个个人社保管理系统,该系统的主要功能需求是根据个人收入、家庭负担、身体状态等情况，预估计算个人每年应支付的社保金，该社保金的计算方式可能随着国家经济的变化而动态改变，针对上述需求描述,该软件系统适宜采用()架构风格设计,该风格的主要特点是()。
A.Layered system
B.Data flow
C.Event system
D.Rule-based system
A.将业务逻辑中频繁变化的部分定义为规则
B.各构件间相互独立
C.支持并发
D.无数据不工作
DA
随着国家经济的变化动态改变，是具有灵活变化的特征，应该是虚拟机风格里的，这里只有D基于规则系统符合，第二问是纯定义。
在架构评估过程中，评估人员所关注的是系统的质量属性。其中，（ ）是指系统的响应能力：即经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的（ ）。
A.安全性
B.性能
C.可用性
D.可靠性
A.个数
B.速度
C.消耗
D.故障率
答案选择B、A
用相应时间和吞吐率来衡量。
在一个分布式软件系统中，一个构件失去了与另一个远程构件的连接。在系统修复后，连接于30秒之内恢复，系统可以重新正常工作。这一描述体现了软件系统的（ ）。
A.安全性
B.可用性
C.兼容性
D.可移植性
B。可用性和可靠性都出现一般都选可用性。这里强调的是30秒内恢复连接，保证可用。
在架构评估中，场景是从（ ）的角度对与系统交互的描述，一般采用（ ）三方面来对场景进行描述。
A.系统设计者
B.系统开发者
C.风险承担者
D.系统测试者
》
A.刺激，环境，响应
B.刺激，制品，响应
C.刺激源，制品，响应
D.参与者，用例，视图
答案选择C、A。
场景是从风险承担者的角度对与系统的交互的简短描述。在体系结构评估中，一般采用刺激(stimulus)、环境(environment)和响应(response)三方面来对场景进行描述。
在架构评估中,（ ）是一个或多个构件(和或构件之间的关系的特性。改变加密级别的设计决策属于（ ），因为它可能会对安全性和性能产生非常重要的影响。
A敏感点
B非风险点
C.权衡点
D.风险点
A敏感点
B非风险点
C.权衡点
D.风险点
解析：答案选择A、C。
敏感点是一个或多个构件（和／或构件之间的关系）的特性。研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。
三层C/S架构中，（ ）是应用的用户接口部分，负责与应用逻辑间的对话功能；（ ）是应用的本体，负责具体的业务处理逻辑。
A.表示层
B.感知层
C.设备层
D.业务逻辑层
A.数据层
B.分发层
C.功能层
D.算法层
解析：答案选择A、C。
三层C/S体系结构是将应用功能分成表示层、功能层(业务层)和数据层三个部分。
分析本题考查软件架构脆弱性方面的基础知识。脆弱性表示人、事物、组织机构等面对波动性、随机性变化或者压力时表现出来的变化趋势，软件脆弱性是指软件中存在的弱点(或缺陷)，利用它可以危害系统安全策略，导致信息丢失、系统价值和可用性降低等。通常在软件设计时，分层架构由于其良好的可扩展性 和可维护性被广泛采纳。
分层架构也存在众多脆弱性问题，主要表现在以下两个方面:
- ①一旦某个底层发生错误，那么整个程序将会无法正常运行，如产生一些数据溢出、空 指针、空对象的安全问题，也有可能会得出错误的结果;
- ②将系统隔离为多个相对独立的层，这就要求在层与层之间引入通信机制，这种本来“直 来直去”的操作现在要层层传递，势必造成性能的下降。
分析本题考查软件构件的基础知识。如果把软件系统看成是构件的集合，那么从构件的外部形态来看，构成一个系统的构件可分为五类：
- 独立而成熟的构件得到了实际运行环境的多次检验；
- 有限制的构件提供了接口，指出了使用的条件和前提；
- 适应性构件进行了包装或使用了接口技术，把不兼容性、资源冲突等进行了处理，可以直接使用;
- 装配的构件在安装时，已经装配在操作系统、数据库管理系统或信息系统不同层次上，可以连续使用。
- 可修改的构件可以进行版本替换，如果对原构件修改错误、增加新功能，可以利用重新“包装”或写接口来实现构件的替换。
中间件提供平台和应用之间的通用服务，这些服务具有标准的程序接口和协议。
中间件的基本功能包括：
- 为客户端和服务器之间提供连接和通信
- 提供交易管理机制保证交易的一致性
- 提供应用的负载均衡和高可用性等
在软件架构中，从不同的视角描述特定系统的体系结构，从而得到多个视图，并将这些视图组织起来以描述整体的软件架构模型。因此，在考虑体系结构时，可以从不同的视角来检查，这促使软件设计师考虑体系结构的不同属性。例如，展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性。选择的特定视角或视图也就是逻辑视图、进程视图、实现视图和配置视图。使用逻辑视图来记录设计元素的功能和概念接口，设计元素的功能定义了它本身在系统中的角色，这些角色包括功能、性能等。
这里的上面的几句话是书中的原文，逻辑视图、进程视图、实现视图和配置视图这些是从视图和视角的角度来的，记住即可，
补充4+1视图：
架构4+1和UML4+1不同：架构是在开发视图描述，UML是在逻辑视图。
敏感点(sensitivity point)和权衡点(tradeoff point)是关键的体系结构决策。
敏感点是 一个或多个构件(和/或构件之间的关系)的特性。研究敏感点可使设计人员或分析员明确 在搞清楚如何实现质量目标时应注意什么。
权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。因此，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的 处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。
补充架构分析敏感点和权衡点：
敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。
风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念，即可能引起风险的因素，可称为风险点。某个做法如果有隐患，有可能导致一些问题，则为风险点；而如果某件事是可行的可接受的，则为非风险点。
软件架构评估在架构设计之后，系统设计之前，因此与设计、实现、测试都没有关系。评估的目的是为了评估所采用的架构是否能解决软件系统需求，但不是单纯的确定是否满足需求。
传统的二层C/S结构存在以下几个局限：
- 1.是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet
- 2.受限于供应商
- 3.软硬件的组合及集成能力有限:难以管理 大量的客户机。
因此，三层C/S结构应运而生。三层C/S结构是将应用功能分成表示层、功能层和数据层三部分，其解决方案是对这三 层进行明确分割，并在逻辑上使其独立。原来的数据层作为DBMS已经独立出来，将表示层 和功能层分离成各自独立的程序，使这两层间的接口简洁明了。三层C/S结构中，表示层是 应用的用户接口部分，它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的 数据，显示应用输出的数据。功能层相当于应用的本体，它是将具体的业务处理逻辑编入程 序中。数据层就是DBMS,负责管理对数据库数据的读写，
架构的基本需求主要是在满足功能属性的前提下，关注软件质量属性，架构设计则是为满足架构需求(质量属性)寻找适当的“战术”(即架构策略)。
软件属性包括功能属性和质量属性，但是，软件架构(及软件架构设计师)重点关注的是 质量属性。因为在大量的可能结构中，可以使用不同的结构来实现同样的功能性，即功能性在很大程度上是独立于结构的，架构设计师面临着决策(对结构的选择)，而功能性所关心的是它如何与其他质量属性进行交互，以及它如何限制其他质量属性。
常见的6个质量属性为可用性、可修改性、性能、安全性、可测试性、易用性。
质量属性场景是一种面向特定的质量属性的需求，由以下6部分组成:刺激源、刺激、环境、制品、 响应、响应度量。--- 刺激源在某个环境中发出刺激给制品，制品响应及响应多大程度。
题目中描述的人员管理系统在架构设计阶段，公司的架构师识别出3个核心质量属性场景，其中“网站在并发用户数量10万的负载情况下，用户请求的平均响应时间应小于3秒”这一场景主要与性能质量属性相关，通常可采用提高计算效率、减少计算开销、控制资源使用、资源调度、负载均衡等架构策略实现该属性:“主站宕机后，系统能够在10秒内自动切换至备用站点并恢复正常运行”主要与可用性质量属性相关，通常可采用Ping/Echo、心跳、异常检测、主动冗余、被动冗余、检查点等架构策略实现该属性;系统完成上线后，少量的外围业务功能和界面的调整与修改不超过10人·月”主要与可修改性质量属性相关。
补充架构评估的质量属性：
1、性能：指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内
系统所能处理的事件的个数。如响应时间、吞吐量。
设计策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度(仲裁)、 负载均衡 等。
2、可靠性：是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功
能特性的基本能力。如 MTTF、MTBF。
设计策略：心跳、Ping/Echo、冗余、选举、检查点等。
3、可用性：是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时
系统能够恢复正常的速度来表示。如故障间隔时间。
设计策略：心跳、Ping/Echo、冗余、选举、检查点等。
补充：可靠性和可用性都出现首选可用性。
4、安全性：是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务
的能力。如保密性、完整性、不可抵赖性、可控性。
设计策略：入侵检测、用户认证、用户授权、追踪审计。
5、可修改性：指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变
更为基准，通过考察这些变更的代价衡量。
设计策略：接口-实现分类、抽象、信息隐藏。
6、功能性：是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构
件的相互协作。
7、可变性：指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先
定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。
8、互操作性：作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。
为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。
基于构件的软件开发中，已有的构件分类方法可以归纳为三大类:
- (1)关键字分类法。根据领域分析的结果将应用领域的概念按照从抽象到具体的顺序逐次分解为树形或有向无回路图结构。--根据关键字逐次分解为树或有向无回路图
- (2)刻面分类法。利用Facet(刻面)描述构件执行的功能、被操作的数据、构件应用的语境或任意其他特征。---facet,从功能、数据、应用的语境或其他特征出发
- (3)超文本方法。基于全文检索技术，使得检索者在阅读文档过程中可以按照人类的联想思维方式任意跳转到包含相关概念或构件的文档。--链接
构件组装是将库中的构件经适当修改后相互连接或者将它们与当前开发项目中的软件元素相连接最终构成新的目标软件。
构件组装技术分类：大致可分为基于功能的组装技术、基于数据的组装技术和面向对象的组装技术。
面问服务的体系结构(Service-oriented Architecture，SOA)是一种软件系统设计方法，通过已经发布的和可发现的接口为终端用户应用程序或其他服务提供服务。企业服务总线(Enterprise Service Bus，ESB)是构建基于SOA解决方案时所使用基础架构的关键部分，是由中间件技术实现并支持SOA的一组基础架构功能。ESB支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。简而言之，ESB提供了连接企业内部及跨企业间新的和现有软件应用程序的功能，以一组丰富的功能启用管理和监控应用程序之间的交互。在SOA分层模型中，ESB用于组件层以及服务层之间，它能够通过多种通信协议连接并集成不同平台上的组件将其映射成服务层的服务。
SOA知识补充：
面向服务的架构SOA
面向服务的的架构简介
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。
在SOA中，服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。
SOA并不仅仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同服务。多个服务通过企业服务总线提出服务请求，由应用管理来进行处理，如下：
实施SOA的关键目标
实施SOA的关键目标是实现企业IT资产重用的最大化。
在实施SOA过程中要牢记以下特征：
- 可从企业外部访问、
- 随时可用(服务请求能被及时响应)、
- 粗粒度接口(粗粒度提供一项特定的业务功能，而细粒度服务代表了技术构件方法)、
- 服务分级、
- 松散耦合(服务提供者和服务使用者分离)、
- 可重用的服务及服务接口设计管理、
- 标准化的接口(WSDL、SOAP、XML是核心)、
- 支持各种消息模式、
- 精确定义的服务接口。
从基于对象到基于构件再到基于服务，架构越来越松散耦合，粒度越来越粗，接口越来越标准。
服务构件与传统构件区别四点：
- 服务构件粗粒度，传统构件细粒度居多；---服务构件比传统构件粒度粗
- 服务构件的接口是标准的，主要是WSDL接口，而传统构件常以具体API形式出现；---服务构件比api标准化
- 服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言；---服务构件的实现语言无关性，api绑定语言。
- 服务构件可以通过构件容器提供QoS的服务，而传统构件完全由程序代码直接控制。---服务构件有成套的体系质量相关，但是api都是简单的代码控制质量。
关键技术
SOA中应用的关键技术如下表。
发现服务
UDDI:用于Web服务注册和服务查找，描述了服务的概念，定义了编程的接口，供其他企业来调用。DISCO:发现公开服务的功能及交互协议。
描述服务
WSDL(WEB服务描述语言)协议：用于描述Web服务的接口和操作功能，描述网络服务。
消息格式层
SOAP为建立Web服务和服务请求之间的通信提供支持。
REST(Representational State Transfer,表述性状态转移)是一种只使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。
编码格式层
扩展标记语言(Extensible Markup Language,XML),用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。
SOA的实现方式
企业服务总线ESB
客户端(服务请求者)、基础架构服务(中间件)、核心集成服务(提供服务)。本质也是通过网络，有下列六点功能：
- 提供位置透明性的消息路由和寻址服务；
- 提供服务注册和命名的管理功能；
- 支持多种的消息传递范型；
- 支持多种可以广泛使用的传输协议；
- 支持多种数据格式及其相互转换；
- 提供日志和监控功能。
真题：
基于架构的软件开发模型(Architecture-BasedSoftware Design Model, ABSDM)把整个基于架构的软件过程划分为(架构)需求、设计、文档化、复审、实现、演化等6个子过程。绝大多数的架构都是抽象的，由一些概念上的构件组成。例如，层的概念在任何程序设计语言中都不存在。因此，要让系统分析师和程序员去实现架构，还必须得把架构进行文档化。文档是在系统演化的每一个阶段，系统设计与开发人员的通信媒介，是为验证架构设计和提炼或修改这些设计(必要时)所执行预先分析的基础。架构文档化过程的主要输出结果是(架构)需求规格说明和(测试架构需求的)质量设计说明书这两个文档。生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。
架构的基本需求主要是在满足功能属性的前提下关注软件质量属性，结构设计则是为满足架构需求(质量属性)寻找适当的战术。根据题干描述，其中“数据传递时延不大于1s，并提供相应的优先级管理”主要与性能质量属性相关，性能的战术有资源需求、资源管理和资源仲裁，此需求通常可采用资源仲裁。---并发只能是多个用户的，但是一个用户的延迟大于1秒也不行，采用资源调度相关的，它说提供了优先级有剥夺资源的情况，所以资源仲裁决定给谁资源。
架构策略实现该属性系统采用双机热备，主备机必须实时监测对方状态，以便完成系统的实时切换”主要与可用性质量属性相关，可用性的战术有错误检测、错误恢复和错误预防，此需求通常可采用错误检测中的心跳架构策略实现该属性;
系统应能够防止99%的黑客攻击”主要与安全性质量属性相关，安全性相关的战术有抵抗攻击、检测攻击和从攻击中恢复，此需求通常可采用检测攻击架构策略实现该属性。
在仓库风格中，有两种不同的构件:中央数据结构说明当前状态，独立构件在中央数据存储上执行”。
补充软件架构风格内容：
软件架构风格
<软件体系结构风格>是描述某一特定应用领域中系统组织方式的惯用模式。
架构风格定义一个系统家族，即一个架构定义一个词汇表和一组约束。
<词汇表>中包含一些构件和连接件类型，而这组<约束>指出系统是如何将这些构件和连接件组合起来的。
架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。
架构设计的一个核心问题是能否达到架构级的软件复用。
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
架构风格分类
数据流风格：面向数据流，按照一定的顺序从前向后执行程序，代表的风格有批处理序列、管道-过滤器。
调用/返回风格：构件之间存在互相调用的关系，一般是显式的调用，代表的风格有 主程序/子程序、面向对象、层次结构。
独立构件风格：构件之间是互相独立的，不存在显式的调用关系，而是通过某个事件触发、异步的方式来执行，代表的风格有进程通信、事件驱动系统(隐式调用)。
虚拟机风格：自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配，代表的风格有解释器、基于规则的系统。
仓库风格：以数据为中心，所有的操作都是围绕建立的数据中心进行的，代表的风格有数据库系统、超文本系统、黑板系统。
数据流风格
批处理序列：构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式传递。
管道-过滤器：每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理，产生输出数据流。前一个构件的输出作为后一个构件的输入，前后数据流关联。过滤器就是构件，连接件就是管道。
早期编译器就是采用的这种架构，要一步一步处理的，均可考虑此架构风格。
二者区别在于批处理前后构件不一定有关联，并且是作为整体传递，即必须前一个执行完才能执行下一个。管道-过滤器是前一个输出作为后一个输入，前面执行到部分可以开始下一个的执行。
调用返回风格
主程序/子程序：单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。过程调用作为交互机制，充当连接件的绝色。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。
面向对象：构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来，对象的行为体现在其接受和请求的动作。连接件即使对象间交互的方式，对象是通过函数和过程的调用来交互的。
层次结构：构件组成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的两层(通常只能影响上层)。
层次结构优点：
- 1、支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。
- 2、不同的层次处于不同的抽象级别，越靠近底层，抽象级别越高；越靠近顶层，抽象级别越低。
- 3、由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持。
缺点：
- 1、并不是每个系统都可以很容易的划分为分层的模式。
- 2、很难找到一个合适的、正确的层次抽象方法。
独立构件风格
进程通信：构件是独立的进程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程(方法)调用等。
事件驱动系统(隐式调用):构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。
主要优点：是为软件复用提供了强大的支持，为构件的维护和演化带来了方便；
缺点：是构件放弃了对系统计算的控制。
虚拟机风格
解释器：通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，缺点是执行效率低。
基于规则的系统：包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。
仓库风格/数据共享风格
数据库系统：构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。
黑板系统：包括知识源、黑板和控制三部分。
知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；
黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应式通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中(信号处理、问题规划和编译器优化等)。
超文本系统：构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。是一种非线性的网状信息组织方法，它以节点为基本单位，链作为节点之间的联想式关联。通常应用在互联网领域。
现代编译器的集成开发环境一般采用数据仓储(即以数据为中心的架构风格)架构风格进行开发，其中心数据就是程序的语法树。
闭环控制
当软件被用来操作一个物理系统时，软件与硬件之间可以粗略的表示为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态，适合于嵌入式系统，涉及连续的动作与状态。
C2风格
C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：
- (1)系统中的构件和连接件都有一个顶部和一个底部；
- (2)构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
- (3)一个连接件可以和任意数目的其它构件和连接件连接；
- (4)当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
层次架构风格
两层C/S、三层C/S、三层B/S
真题：
题目中提及“支持玩家自行创建战役地图”这说明系统要能应对“自定义”内容的解析，这需要用到解释器风格。“并发用户数量10000 人时用户请求要在1秒内得到响应”属于典型的性能属性，“对游戏系统进行二次开发的时间不超过 3 个月”属于可修改性属性。
特定领域软件架构(Domain Specific SoftwareArchitecture，DSSA)以一个特定问题领域为对象，形成(由领域参考模型、参考需求、参考架构等组成的)开发基础架构，其目标是支持一个特定领域中多个应用的生成。 DSSA 的基本活动包括领域分析、领域设计和领域实现。其中领域分析的主要目的是获得领域模型，领域模型描述领域中系统之间共同的需求，即领域需求;领域设计的主要目标是获得 DSSA，DSSA 描述领域模型中表示需求的解决方案;领域实现的主要目标是依据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。
补充知识：
特定领域软件架构DSSA
DSSA就是专用于一类特定类型的任务(领域)的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。
DSSA就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成。
垂直域：在一个特定领域中的通用的软件架构，是一个完整的架构。
水平域：在多个不同的特定领域之间的相同的部分的小工具(如购物和教育都有收费系统，收费系统即是水平域)。
DSSA的三个基本活动
领域分析：这个阶段的主要目标是获得领域模型(领域需求)。识别信息源，即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。
领域设计：这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求DSSA。
领域实现：这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。
参与DSSA的四种角色人员
领域专家：包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品，等等。
领域分析人员：由具有知识工程背景的有经验的系统分析员来担任。控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中。
领域设计人员：由有经验的软件设计人员来担任。根据领域模型和现有系统开发出DSSA,并对DSSA的准确性和一致性进行验证。
领域实现人员：由有经验的程序设计人员来担任。根据领域模型和DSSA,开发构件。
建立DSSA的过程
定义领域范围：领域中的应用要满足用户一系列的需求。
定义领域特定的元素：建立领域的字典，归纳领域中的术语，识别出领域中相同和不相同
的元素。
定义领域特定的设计和实现需求的约束：识别领域中的所有约束，这些约束对领域的设计
和实现会造成什么后果。
定义领域模型和架构：产生一般的架构，并描述其构件说明。
产生、搜集可复用的产品单元：为DSSA增加复用构件，使可用于新的系统。
以上过程是并发的、递归的、反复的、螺旋型的。
总结：首先确定范围，然后建字典归纳术语，识别约束，产生一般的架构，最后搜集可复用的产品单元。这个过程是并发、递归、反复、螺旋的
三层次模型
领域开发环境：领域架构师决定核心架构，产出参考结构、参考需求、架构、领域模型、开发工具。---架构师选择核心架构，然后给出参考的结构、需求、架构、领域模型以及工具等。
领域特定的应用开发环境：应用工程师根据具体环境来将核心架构实例化。
---应用工程师，就是设计者，根据具体的环境来实现核心架构。
应用执行环境：操作员实现实例化后的架构。---操作员，就是开发者，实现整个架构。
真题：
ATAM 被分为四个主要的活动领域(或阶段)，分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。
SAAM 分析评估体系结构的过程包括五个步骤，即场景开发、体系结构描述、单个场景评估、场景交互和总体评估。SAAM的主要输入问题是问题描述、需求声明和体系结构描述。
补充ATAM和SAAM等相关知识：
三种常用的评估方式
基于调查问卷(检查表)的方式：类似于需求获取中的问卷调查方式，只不过是架构方面的问卷，要求评估人员对领域熟悉。
基于度量的方式：制定一些定量来度量架构，如代码行数等。要制定质量属性和度量结果之间的映射，要求评估人员对架构熟悉。
基于场景的方式：主要方法。首先要确定应用领域的功能和软件架构的结构之间的映射，然后要设计用于体现待评估质量属性的场景(即4+1视图中的场景),最后分析软件架构对场景的支持程度。要求评估人员即对领域熟悉，也对架构熟悉。
从三个方面对场景进行设计：刺激(事件);环境(事件发生的环境);响应(架构响应刺激的过程)。
三种评估方式的比较：
由表可知，场景最不通用，度量要求对构架精确了解，调查问卷实施阶段最早，度量最客观。其中，基于场景的方式是主流，其有三种具体评估方法：
都是基于场景架构评估的方法，SAAM是基于场景的架构分析法，ATAM架构权衡分析法。
基于场景的架构分析方法SAAM
SAAM是一种 非功能质量属性 的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析
方法。SAAM的主要输入是问题描述、需求说明和架构描述。有下列六个步骤：
形成场景--->描述架构--->对场景分类和确定优先级--->对场景进行单个评估--->评估场景的相互作用--->形成总体评价。
场景形成，然后介绍架构，对场景分类排优先级，每个场景评估，然后评估场景产生的影响，最后归纳总结总体评价。
场景分为直接场景(直接可以实现的)和间接场景(该做哪些修改才能实现)。形成了场景之后，也可以对场景进行分类和单个评估，六个步骤有交叉点。
若要比较多个架构，就要形成权值，对多个架构的功能和数量进行比较。
架构权衡分析法 ATAM
让架构师明确如何 权衡多个质量目标 ，参与者有评估小组、项目决策者和其他项目相关人。
ATAM被分为四个主要的活动领域，分别是场景和需求收集、体系结构视图和场景实现、属性模
型构造和分析、折中。整个评估过程强调以 属性 作为架构评估的 核心 概念。主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。
描述和介绍阶段
1.描述ATAM方法---------------------------->2.描述业务动机------------------->3.描述架构------------->
评估小组负责人：评估方法 项目决策者：业务角度 首席设计师：架构
调查和分析阶段
4.确定架构方法---------->5.生成质量属性效用树-------------------------->6.分析架构方法----------->
架构设计师 评估小组,设计小组,管理人员,客代 评估小组
测试阶段
7.讨论场景和对场景分级------------->8.分析架构方法-------------->
项目干系人：投票 架构设计师
报告阶段
9.描述评审结果
评估小组负责人：评估方法
描述和介绍阶段
- 首先，由评估小组负责人来给大家讲解我们要用的ATAM方法的概念原理等等，对ATAM介绍；
- 然后，项目决策者从业务角度(商业)对架构提出要求，比如我用户量过多的时候不能访问不了，还得能及时处理不能影响我的客户的使用(可用性，性能等)；
- 最后，首席设计师/架构师还要给大家介绍一下要评估的架构是什么架构，与其他系统进行了什么交互等等。
调查和分析阶段
- 首先，架构设计师介绍架构使用的方法并分类；
- 然后，评估、设计小组等提取质量属性，并生成质量属性效用书；
- 最后，评估小组来进行分析评估，讨论实现场景的架构方法，以及风险决策、无风险决策、敏感点、权衡点，并对其进行分类。
测试阶段
项目干系人首先，带领大家集体讨论场景并设置优先级；然后，对讨论投票后的结果再次分析。
报告阶段
把以上得到的信息归纳总结，主要成果：
- 已编写了文档的架构方法；
- 经过讨论得到的场景集合及其优先级；
- 效用树；
- 所发现的有风险决策；
- 已编成文档的无风险决策；
- 所发现的敏感点和权衡点
个人理解：场景和需求的收集在2---4，架构视图和场景实现在5-----7，属性模型构造和分析在8，折中在9.
质量属性效用树在前面有图：根----质量属性-----分类细化属性-------场景(叶节点)
成本效益分析法 CBAM
用来对架构建立的成本来进行设计和建模，让决策者根据投资收益率来选择合适的架构，可以看
做对 ATAM的补充，在 ATAM 确定质量合理的基础上，再对效益进行分析。有下列步骤：
- 整理场景(确定场景，并确定优先级，选择三分之一优先级最高的场景进行分析);
- 对场景进行细化(对每个场景详细分析，确定最好、最坏的情况);
- 确定场景的优先级(项目干系人对场景投票，根据投票结果确定优先级);
- 分配效用(对场景响应级别确定效用表，建立策略、场景、响应级别的表格);
- 形成“策略-场景-响应级别的对应关系”;
- 确定期望的质量属性响应级别的效用(根据效用表确定所对应的具体场景的效用表);
- 计算各架构策略的总收益；
根据受成本限制影响的投资报酬率选择架构策略(估算成本，用上一步的收益减去成本，得出收
益，并选择收益最高的架构策略)。
软件重用分垂直式重用与水平式重用，垂直式重用是指局限于某一垂直领域的重用，如只在电力系统中用 到的构件;而水平式重用是指通用领域的重用，如标准函数库，任何软件都能用，所以是水平式重用。
EJB 分为会话 Bean、实体 Bean 和消息驱动Bean.
1、会话 Bean：用于实现业务逻辑，它可以是有状态的，也可以是无状态的。每当客户端请求时，容器就 会选择一个会话 Bean 来为客户端服务。会话Bean 可以直接访问数据库，但更多时候，它会通过实体 Bean实现数据访问,
2、实体 Bean：用于实现 O/R 映射，负责将数据库中的表记录映射为内存中的实体对象，事实上创建- 个实体 Bean 对象相当于新建一条记录，删除一个实体 Bean 会同时从数据库中删除对应记录，修改一个实体 Bean 时，容器会自动将实体Bean 的状态和数据库同步。
3、消息驱动 Bean ：是 EJB3.0 中引入的新的企业Bean，它基于 JMS 消息，只能接收客户端发送的JMS 消息 然后处理。MDB 实际上是一个异步的无状态会话 Bean，客户端调用 MDB 后无需等待，立刻返回，MDB 将异步处理客户请求。这适合于需要异步处理请求的场合，比如订单处理，这样就能避免客户端长时间的等待一个 方法调用直到返回结果
系统构件组装分为三个不同的层次：定制(Customization)、集成(Integration)、扩展(Extension)。这三个层次对应于构件组装过程中的不同任务。
伺服对象(Servant)：CORBA对象的真正实现负责完成客户端请求。
对象适配器(Object Adapter)：用于屏蔽 ORB 内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用 ORB 内部的某些功能。
对象请求代理(Object Request Broker)：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。
补充：
中间件技术-CORBA(公共对象请求代理体系结构)
OMG 组织制订了 OMA(Object Management Architecture,对象管理体系结构)参考模型，该模型描 述了 OMG规范所遵循的概念化的基础结构。OMA 由对象请求代理 ORB、对象服务、公共设施、域接口和应用接口这几个部分组成，其核心部分是对象请求代理 ORB(Object Request Broker)。
对象管理组织(OMG)基于 CORBA基础设施定义了四种构件标准。
实体(Entity)构件需要长期持久化并主要用于事务性行为，由容器管理其持久化。
加工(Process)构件同样需要容器管理其持久化，但没有客户端可访问的主键。
会话(Session)构件不需要容器管理其持久化，其状态信息必须由构件自己管理。
服务(Service)构件是无状态的。
CORBA对象可看作是一个具有对象标识、对象接口及对象实现的抽象实体。之所以称为抽象的， 是因为并没有硬性规定 CORBA 对象的实现机制一个 CORBA 对象的引用又称可互操作的对象引用 (Interoperable Object Reference)。从客户程序的角度看，IOR 中包含了对象的标识、接口类型及其他信息以查找对象实现。
对象标识(Object ID)是一个用于在 POA中标识一个CORBA对象的字符串。它既可由程序员指
派，也可由对象适配器自动分配，这两种方式都要求对象标识在创建它的对象适配器中必须具有唯一性。
POA(便携式对象适配器)是对象实现与 ORB其它组件之间的中介，支持由 Object Id 标识的对
象的名称空间，它将客户请求传送到伺服对象，按需创建子 POA,提供管理伺服对象的策略。
伺服对象(servant)是指具体程序设计语言的对象或实体，通常存在于一个服务程序进程之中。
客户程序通过对象引用发出的请求经过 ORB 担当中介角色，转换为对特定的伺服对象的调用。在一个 CORBA 对象的生命期中，它可能与多个伺服对象相关联，因而对该对象的请求可能被发送到不同的伺服对象。
J2EE 核心组成:
容器：Applet Container、Application Container、Web Container、 EJB Container
组件：Applet、Application、JSP/Servlet、EJB
容器和组件一一对应
服务：
- HTTP(Hypertext Transfer Protocol)超文本传输协议。
- RMI-lOP(Remote Method Invocation ober theInternet Inter-ORB Protocol):远程方法调用，融合了JavaRMl和 CORBA(Common Object RrquestBroker Architecture 公共对象请求代理体系结构)在使用 Application或 Web 端访问 EJB 端组件时使用。
- Java lDL(Java Interface Definition Language):Java接口定义语言，主要用于访问外部的 CORBA服务JTA(Java Transaction API):用于进行事务处理操作的 API。
- JDBC(Java Database Connectivity):为数据库操作提供的一组 API。
- JMS(Java MassageService):用于发送点对点消息的服务。
- JavaMail:用于发送邮件JAF(Java Activation Framework):用于封装传递的邮件数据
- JNDl(Java Naming and Directory InterfaceJAXP(Java API for XML Parsing ):专门用于XML解析操作的 API。
- JCA(J2EE Connector Architecture ):Java 连接器构架JAAS (Java Authenticati on and AuthorizationService)
- JSF (Java Server Faces)
- JSTL (JSP Standard Tag Library)
- SAAJ (SOAP with Attachments API for JAVA)
- JAXR (Java Apl for XML Registries)
构件的特性是:
(1)独立部署单元;
(2)作为第三方的组装单元;
(3)没有(外部的)可见状态。
一个构件可以包含多个类元素，但是一个类元素只能属于一个构 件。将一个类拆分进行部署通常没什么意义。
对象的特性是:
(1)一个实例单元，具有唯一的标志。
(2)可能具有状态，此状态外部可见。了自己的状态和行为。
(3)封装
对象是类的实例化。
接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化为参数化操作的 集合，而是关注输入输出的消息的标准化，它强调当机器在网络中互连时，标准的消息模式、格式、协议的重要性。这也是因特网(IP,UDP,TCP,SNMP等等)和 Web(HTTP, HTML,等等)标 准的主要做法。为了获得更广泛的语义，有必要在一个单一通用的消息格式语境中标准化消息模 式。这就是XML的思想。XML提供了一种统一的数据格式。
简单的分析：IDL是接口的定义语言，定义接口的那最重要的肯定是描述清楚接口，有一个统一的方式来，描述接口，让大家都简单易懂的理解。命名空间这个可以根模块最匹配其他的都不行。
IDL是一种接口定义语言，具体的定义会涉及到接口以及相关部分。文件包含的主要元素有:接口描述、模块定义、类型定义、常量定义、异常、值类型。接口描述是IDL文件中最核心的内容。由于IDL只是一种接口定义语言，最终还是要落地与语言对接的，所以IDL的数据类型要与实现语言进行映射。以Java为例，IDL接口映射为Java类而该接口的操作映射为相应的成员函数。模块定义映射为Java 语言中的包(Package)或C++的namespaces.
根据题目的意思，用户会注册自己的兴趣，然后系统也会把新闻按兴趣分类，如果某个新闻事件发生，可以通过事件来触发推送动作，将新闻推送给对其感兴趣的用户。这是典型的事件驱动系统应 用场景。
前面的：补充架构评估的质量属性
前面的：中间件技术-CORBA(公共对象请求代理体系结构)
POA是对象实现与ORB其它组件之间的中介，它将客户请求传送到伺服对象，按需创建子POA，提供管理伺服对象的策略。
CORBA对象可看作是一个具有对象标识、对象接口及对象实现的抽象实体。之所以称为抽象的，是因为并没有硬性规定CORBA对象的实现机制。由于独立于程序设计语言和特定ORB产品，一个CORBA对象的引用又称可互操作的对象引用(Interoperable ObjectReference)。从客户程序的角度看，IOR中包含了对象的标识、接口类型及其他信息以查找对象实现。
伺服对象(servant)是指具体程序设计语言的对象或实体，通常存在于一个服务程序进程之中。客户程序通过对象引用发出的请求经过ORB担当中介角色，转换为对特定的伺服对象的调用。在一个CORBA对象的生命期中，它可能与多个伺服对象相关联，因而对该对象的请求可能被发送到不同的伺服对象。
对象标识(Object ID)是一个用于在POA中标识一个CORBA对象的字符串。它既可由程序员指派也可由对象适配器自动分配，这两种方式都要求对象标识在创建它的对象适 配器中必须具有唯一性。
UDDl(Universal Description,Discovery&Integration)，UDDI用于Web服务注册和服务查找;
WSDL(Web Service Description Language)WSDL用于描述Web服务的接口和操作功能。SOAP(Simple Object Access Protocol)，SOAF为建立Web服务和服务请求之间的通信提供支持。BPEL(Business Process Execution LanguageFor Web Services)翻译成中文的意思是面向Web服务的业务流程执行语言，也有的文献简写成BPEL4WS，它是一种使用 Web 服务定义和执行业务流程的语言。使用BPEL，用户可以通过组合、编排和协调Web服务自上而下地实现面向服务BPEL 提供了一种相对简单的体系结构(SOA)。易懂的方法，可将多个 Web 服务组合到一个新的复合服务(称作业务流程)中。
前面的：面向服务的架构SOA
前面的：特定领域软件架构DSSA
可修改性(modifiability)是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具 体的变更为基准，通过考察这些变更的代价衡量可修改性。
可修改性包含四个方面。
- (1)可维护性(maintainability)。这主要体现在问题的修复上:在错误发生后“修复”软件系统。为可维护性做好准备的软件体系结构往往能做局部性的修改并能使对其他构件的负面影响最小化。
- (2)可扩展性(extendibiity)。这一点关注的是使用新特性来扩展软件系统，以及使用改进版本来替换 构件并删除不需要或不必要的特性和构件。为了实现可扩展性，软件系统需要松散耦合的构件。其 目标是实现一种体系结构，它能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的体系结构中也是必要的。
- (3)结构重组(reassemble)。这一点处理的是重新组织软件系统的构件及构件间的关系，例如通过 将构件移动到个不同的子系统而改变它的位置。为了支持结构重组，软件系统需要精心设计构件之间的关系。理想情况下，它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。
- (4)可移植性(portability)。可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语 言或编译器。为了实现可移植，需要按照硬件无关的方式组织软件系统，其他软件系统和环境被提 取出。可移植性是系统能够在不同计算环境下运行的能力。这些环境可能是硬件、软件，也可能是 两者的结合。在关于某个特定计算环境的所有假设都集中在一个构件中时，系统是可移植的。如果 移植到新的系统需要做些更改，则可移植性就是一种特殊的可修改性。
强调了自定义流程，然后按自定义流程来执行，这属于虚拟机风格的特征。
要求对业务功能灵活组合形成新的业务功能，就是有自定义类型的业务。自定义的业务 能正常执行，需要有虚拟机架构的支撑。目前备选答案中A与D都是虚拟机风格。而A主要适合于专家系统，所以应选D。
语音识别、知识推理等都是黑板系统的，首选肯定是它。
第三问，强调了1秒停滞，2秒内干嘛，所以是性能，性能的资源调度(仲裁)
引入对象管理层这不是相当于增加了一层，效率降低了，根层次化增加层数效率降低一个道理。
软件架构是降低成本、改进质量、按时和按需交付产品的关键因素，软件架构设计需要满足系统的 质量属性，如性能、安全性和可修改性等，软件架构设计需要确定组件之间的依赖关系，支持项目计划和管理活动，软件架构能够指导设计人员和实现人员的工作。一般在设计软件架构之初，会根 据用户需求，确定多个候选架构，并从中选择一个较优的架构，并随着软件的开发，对这个架构进 行微调以达到最佳效果。
ADL是一种形式化语言，在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。基于底层语义的工具为体系结构的表示、分析、演化、细化、设计过程等提供支持。
ADL即架构描述语言，其基本构成要素包括:组件、组件接口、连接件、架构配置。
- 组件(构件)是一个计算单元或数据存储。也就是说，组件是计算与状态存在的场所。在架构中，一个构件可能小到只有一个过程或大到整个应用程序。
- 连接件是用来建立组件间的交互以及支配这些交互规则的架构构造模块。
- 架构配置或拓朴是描述架构的组件与连接件的连接图
第一反应是闭环控制，温控调节、定速巡航都是经典的闭环控制风格。
过程控制又称闭环风格，该风格的最大特点是设定参数，并不断测量现有的实际数据，将实际值与 设定值进行比较，以确定接下来的操作。在本题中，定速巡航的场景正好符合这个模式。
自定义对象交互关系，虚拟机风格
第一反应，现代编译器的风格都是仓库(数据共享)风格
除了下面的定义变化外，前面的DSSA补充中，三层次模型中领域架构师产出也提到了参考结构、参考需求、参考架构、领域模型
简单地说，DSSA就是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构。对DSSA研究的角度、关心的问题不同导致了对DSSA的不同定义。
Hayes Roth对DSSA的定义如下:"DSSA就是专用于一类特定类型的任务(领域)的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合”。
Tracz的定义为:"DSSA就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构 等组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成”。
实施DSSA的过程中包含了一些基本的活动。虽然具体的DSSA方法可能定义不同的概念、步骤和产品等，但这些基本活动大体上是一致的。以下将分三个阶段介绍这些活动。
1领域分析 这个阶段的主要目标是获得领域模型领域模型描述领域中系统之间的共同的需求，即领域模型所 描述的需求为领域需求。在这个阶段中首先要进行一些准备性的活动，包括定义领域的边界。从而明确分析的对象;识别信息源，整个领域工程过程中信息的来源，可能的信息源包括现存系统、技 术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。当领域中存在大量系统时，需要选择它们的一个子集作为样本系统。对样本系统需求的考察将显示领城需求的一个变化范围。一些需求对所有被考察的系统是共同的，一些需求是单个系统所独有的。很多需求位于这两个极端之间，即被部分系统共享。
2领域设计 这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的 表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派 生出满足这些被建模的领域需求的DSSA，由于领域模型中的领域需求具有一定的变化性DSSA也要相应地具有变化性。它可以通过表示多选-的(alternative)、可选的(optional)解决方案等来做到这一点。模型和DSSA来组织的，因此在这个阶段通过获得DSSA，也就同时形成了重用基础设施的 规约。
3领域实现 这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有 系统中提取得到，也可能需要通过新的开发得到。它们依据领域模型和DSSA进行组织也就是领域 模型和DSSA定义了这些可重用信息的重用时机，从而支持了系统化的软件重用。这个阶段也可以看 作重用基础设施的实现阶段。
站在巨人的肩膀上：【软考系统架构设计师】2022下综合知识历年真题_计算无关模型(cim)
【软考系统架构设计师】2021年系统架构师综合知识真题及解析_ai芯片有别于通常处理器芯片,它应具备四种关键特征
