A 对，B对，C好像是分布式中间件吧，D对。选C

第一题，感觉肯定有交互支持，选B;第二B。实际答案：D和B。

在一个分布式系统中，中间件通常提供两种不同类型的支持：

（1）交互支持，中间件协调系统中的不同组件之间的交互。

（2）提供公共服务，即中间件提供对服务的可复用的实现。这些服务可能会被分布式系统中的很多组件所需要。公共服务是指被不同组件需求的服务，不管这些组件的功能是什么。这些服务，你可以把这些服务看做是中间件容器提供的。可以在这个容器中部署你的组件并且这些组件可以访问和使用这些公共服务。

微服务是去中心化，面向服务SOA是集中化管理；选C。正确答案选D，题干，不正确的。

构件特征：

1.构件是独立部署单元

2.可做第三方组装单元

3.没有对外可见的状态

 类只属于一个构件，但是一个构件可包含多个类

对象特征：

1.一个实例单元，具有唯一的标志

2.封装了自己的行为和状态

3.可能具有状态而且还对外可见。

选A。这个记住吧。

构件：一个独立可交付的功能单元，外界通过接口访问其提供的服务。

首选是服务端构件，能够做服务端构件的是EJB、COM+，做应用服务器的A吧。

其实能够做服务端构件模型的是EJB、COM+、Servlet 、ASP。

EJB（Enterprise Java Beans） 是运行在独立服务器上的组件。

COM+ 是 Microsoft 组件对象模型 (COM) 和 Microsoft Transaction Server (MTS) 的演变。COM+ 可用于开发适用于Windows的企业范围、任务关键型分布式应用程序。

Servlet（Server Applet）是Java Servlet的简称，称为小服务程序或服务连接器。

ASP即Active Server Pages，是Microsoft公司开发的服务器端脚本环境，可用来创建动态交互式网页并建立强大的web应用程序。

第二个明显选D

明显选A，A 

书上原话B，和B。

B，D

B，D

选B，先构造或获取，然后管理，最后找出可用的。

领域分析、设计、实现。分析获取领域需求也是领域模型，设计获得DSSA，实现是代码等实现DSSA。选C。

C比较贴合，C。

A，C

C

B，A。实际答案：B和D。

效用树，记住：树根-->质量属性-->质量属性分类-->质量属性场景

场景是从风险承担着角度来对系统交互的描述。

SDN软件定义网络，好像是用软件的方式配置网络，这种复杂的系统一般都是分层的，他应该没啥应用吧，选D；选D，构件不允许有对外可见的属性和状态。实际答案A和D。

SDN 架构包括业务层、控制层、转发层。名字可能变化，但是往业务/应用、转发、控制字眼上靠就行。

A

C和A。实际答案B和D。

COM不支持任何形式的实现继承。注意，COM没有定义或考虑单独的构件从内部如何去实现。构件可以由使用了实现继承的类组成。无论何种情况，缺少实现继承并不意味着缺少对重用的支持。为实现对象重用，COM 支持两种形式的对象组装：包含(Containment)和聚集(Aggregation)。

包含就是一种简单的对象组装技术，其含义是一个对象拥有指向另一个对象的唯一引用。从概念上来说，前者(称做外部对象)“包含”后者(称做内部对象)。外部对象只是把请求转发给内部对象。所谓转发，就是调用内部对象的方法，以实现对某个外部对象方法的调用。

 

包含相当于一个对象指向另一个对象的引用，比如A包含B，其他的想要调用就调用这个B，调用A，A把这个请求根据引用分配给B；

聚集是这样干的，A呢把B的引用暴漏出来，其他的想要调用B直接找到A暴漏出来的B的引用就行，这样A就不用再去分配传递请求了。

自定向下，选A，原话是软件构件和类，比较符合的是C。、

选C和B。B就不存，除非没别的选项不得以而为之。

A，物联网这么高大上的系统必须得分层啊，而且一般系统尤其是复杂点基本都分层。

A和B。

物联网分为多层，一般包括感知层、网络层、应用层等不同划分。

D，A。

A是分层，B是数据流，C是事件驱动，D是基于规则的系统。根据个人、家庭、神奇情况不同而不同，还要根据国家经济变化而变动，所以这些变化因素定成规则更好。

B，A。B

C，C。C，C。实际答案：C，C。A，C。

敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。

A和C。

表示层负责用户接口、功能层(业务逻辑层)负责功能处理、数据层负责数据持久存储，

顾名思义理解记忆。

B。这也是所有分层的缺点。

D。答案：B。

如果把软件系统看成是构件的集合，那么从构件的外部形态来看，构成一个系统的构件可分为五类：

• 独立而成熟的构件得到了实际运行环境的多次检验；
• 有限制的构件提供了接口，指出了使用的条件和前提；
• 适应性构件进行了包装或使用了接口技术，把不兼容性、资源冲突等进行了处理，可以直接使用；
• 装配的构件在安装时，已经装配在操作系统、数据库管理系统或信息系统不同层次上，可以连续使用；
• 可修改的构件可以进行版本替换，如果对原构件修改错误、增加新功能，可以利用重新“包装”或写接口来实现构件的替换。

A,B,D

A,B,C,D.答案：A,B,B,A。

A，B，C。答案：B，A，B。

A，B，A

A，D，B，C，D

A，B，D。

基于构件的软件开发中，已有的构建分类方法可以归纳为三大类：

(1)关键字分类法 。根据领域分析的结果将应用领域的概念按照从抽象到具体的顺序逐次分解为树形或有向无回路图结构。

(2)刻面分类法 。利用 Facet(刻面)描述构件执行的功能、被操作的数据、构件应用的语境或任意其他特征。

(3)超文本方法 。基于全文检索技术，使得检索者在阅读文档过程中可以按照人类的联想思维方式任意跳转到包含相关概念或构件的文档。

A。答案：C。

D，C，A

A，C。

面向服务的体系结构(Service-oriented Architecture,SOA)是一种软件系统设计方法， Service-oriented Architecture SOA) 通过已经发布的和可发现的接口为终端用户应用程序或其他服务提供服务。

企业服务总线(Enterprise Service Bus, ESB)是构建基于S0A 解决方案时所使用基础架 Enterprise Service Bus ESB) SOA 构的关键部分，是由中间件技术实现并支持 S0A的一组基础架构功能。ESB支持异构环境中的 SOA ESB 服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。简而言之，ESB提 ESB 供了连接企业内部及跨企业间新的和现有软件应用程序的功能，以一组丰富的功能启用管理和监控应用程序之间的交互。在SOA分层模型中，ESB用于组件层以及服务层之间，它能够通过 SOA ESB 多种通信协议连接并集成不同平台上的组件将其映射成服务层的服务。

A，A，C。

基于架构的软件开发模型(Architecture-Based Software Design Model, ABSDM)把整个基 (Architecture-Based Software Design Model, ABSDM) Based Software Design Model, ABSDM)

于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等6个子过程。绝大多数的架构都是抽象的，由一些概念上的构件组成。例如，层的概念在任何程序设计语言中都不存在。因此，要让系统分析师和程序员去实现架构，还必须得把架构进行文档化。

文档是在系统演化的每一个阶段，系统设计与开发人员的通信媒介，是为验证架构设计和提炼或修改这些设计(必要时)所执行预先分析的基础。架构文档化过程的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明书这两个文档。生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。

B，B，A，C，C，D。答案： B，C，A，C，C，A。

架构的基本需求主要是在满足功能属性的前提下，关注软件质量属性，结构设计则是为满足架构需求(质量属性)寻找适当的战术。

根据题干描述，其中“数据传递时延不大于1s,并提供相应的优先级管理”主要与性能质量属性相关， 性能的战术有资源需求、资源管理和资源仲裁 ，此需求通常可采用资源仲裁架构策略实现该属性；

“系统采用双机热备，主备机必须实时监测对方状态，以便完成系统的实时切换”主要与可用性质量属性相关， 可用性的战术有错误检测、错误恢复和错误预防 ，此需求通常可采用错误检测中的心跳架构策略实现该属性；

“系统应能够防止99%黑客攻击”主要与安全性质量属性相关， 安全性相关的战术有抵抗攻击、检测攻击和从攻击中恢复 ，此需求通常可采用检测攻击架构策略实现该属性。

D，C。答案： B，A。

属于教程原话：“在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行”。

自定义的地图、对象及之间关系，灵活定义当然是虚拟机风格，虚拟机包含解释器和基于规则系统，所以B更贴合；性能A；D可修改。

B，C。

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

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

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

断电，不影响使用，可用性A，心跳冗余，选举，投票表决，ping/echo等，所以C；D性能，性能实现方式：提高计算效率，减少开销，控制资源使用，资源调度，负载均衡，资源需求，资源管理，资源仲裁等等。所以D；B安全性，实现方法：入侵检测、追踪审计、用户授权、认证等，所以A。

C，C。

• ATAM 被分为四个主要的活动领域(或阶段),分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。
• SAAM 分析评估体系结构的过程包括五个步骤，即场景开发、体系结构描述、单个场景评估、场景交互和总体评估。SAAM 的主要输入问题是问题描述、需求声明和体系结构描述。

JAVA Bean，实体bean保存数据，会话bean创建管理销毁会话，消息驱动bean消息传递交互。

D，B，A。答案： A、B、D。

B。最后一般是演化，扩展和演化意思一致，演化包括扩展了。实际答案选C。

系统构件组装分为三个不同的层次：定制(Customization)、集成(Integration)、扩展(Extension)。这三个层次对应于构件组装过程中的不同任务。

A。答案D。这个可以只记住答案EJB、Servlet、JSP是基本的，再就是Applet和Application Client.

• J2EE核心组成：
• 容器：Applet Container、Application Container、Web Container、EJB Container
• 组件：Applet、Application、JSP/Servlet、EJB服务
• HTTP(Hypertext Transfer Protocol)超文本传输协议
• RMI-IIOP(Remote Method Invocation ober the Internet Inter-ORB Protocol):远程方 法调用，融合了JavaRMI和CORBA(Common Object Rrquest Broker Architecture公共对象 请求代理体系结构)在使用Application或Web端访问EJB端组件是使用
• Java IDL(Java Interface Definition Language):Java接口定义语言，主要用于访问外部的CORBA服务
• JTA(Java Transaction API):用于进行事务处理操作的API JDBC(Java Database Connectivity):为数据库操作提供的一组API JMS(Java Massage Service):用于发送点对点消息的服务JavaMail:用于发送邮件
• JAF(Java Activation Framework):用于封装传递的邮件数据
• JNDI(Java Naming and Directory Interface)
• JAXP(Java API for XML Parsing ):专门用于XML解析操作的API
• JCA(J2EE Connector Architecture):Java连接器构架JAAS(Java Authenticati on and Authorization Service)JSF(Java Server Faces)
• JSTL (JSP Standard Tag Library)
• SAAJ(SOAP with Attachments API for JAVA)
• JAXR(Java ApI for XML Registries)

B 。它不管参数，管的是输入输出的标准化，即消息内容的标准化，协议的标准化。

C，A。

IDL 是一种接口定义语言，具体的定义会涉及到接口以及相关部分。

文件包含的主要元素有：接口描述、模块定义、类型定义、常量定义、异常、值类型。接口描述是IDL文件中最核心的内容。

由于 IDL只是一种接口定义语言，最终还是要落地与语言对接的，所以 IDL的数据类型要与实现语言进行映射 。以 Java 为例，IDL 接口映射为 Java 类，而该接口的操作映射为相应的成员函数。

模块定义映射为Java语言中的包(Package)或C++的 namespaces。

B，C，C；A。

书上的原话：

根据基于软件架构的设计的定义，基于软件架构的设计(Architecture Based Software Development,ABSD)强调由商业、质量和功能需求的组合驱动软件架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。进一步来说，用例描述的是功能需求，质量属性场景描述的是质量需求(或侧重于非功能需求)。

B，C，C。共有的结构和语义特性。语音识别，知识推理，问题复杂，解空间大，求解过程不确定这都是经典的数据共享风格(仓库)中的黑板系统。

体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有 效地组织成一个完整的系统。对软件体系结构风格的研究和实践促进对设计的重用，一些经过实践 证实的解决方案也可以可靠地用于解决新的问题。例如，如果某人把系统描述为“客户/服务器”模 / 式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。

语音识别是黑板风格的经典应用场景。

输入某个构件，经过内部处理，产生数据输出的系统，正是管道-过滤器中过滤器的职能，把多个过 滤器使用管道相联的风格为管道-过滤器风格。

A。根据用户的注册兴趣推送，新闻系统不断更新，出来新的新闻了，根据注册的兴趣选择性推送

C

B，D，C，C，B，A

性能： 提高计算效率，减少开销，控制资源使用，资源调度，负载均衡，资源需求，资源管理，资源仲裁等等

安全性：入侵检测、追踪审计、用户授权、认证等。

分析：面向构件的编程，能想到的就是构件特性：独立部署单元，作为第三方组装单元，没有状态；还有就是面向构件的编程，构件或购买或自建，组装在一起。C排除，多态，好像无关；D排除，事务管理无关；A排除，继承性好像无关，选B

书上的话，要记住：

面向构件的编程(COP)关注于如何支持建立面向构件的解决方案。一个基于一般 OOP风格的 COP定义如下(Szyperski,1995):“面向构件的编程需要下列基本的支持：

——多态性(可替代性);

——模块封装性(高层次信息的隐藏);

——后期的绑定和装载(部署独立性);

——安全性(类型和模块安全性)。

 

多态性允许构件在不影响其他部分的情况下被替换，这增加了系统的灵活性和可维护性。

模块封装性则确保了构件内部的数据和实现细节不被外部直接访问，从而提高了系统的安全性和稳定性。

D，C。蒙对了。。。

POA是对象实现与ORB其它组件之间的中介，它将客户请求传送到伺服对象，按需创建子 POA,提供管理伺服对象的策略。CORBA对象可看作是一个具有对象标识、对象接口及对象实现的抽象实体。之所以称为抽象的，是因为并没有硬性规定 CORBA对象的实现机制。由于独立于程序设计语言和特 定ORB产品，一个CORBA对象的引用又称可互操作的对象引用(Interoperable Object Reference，IOR)。从客户程序的角度看，IOR 中包含了对象的标识、接口类型及其他信息以查找对象实现。

 

伺服对象(servant)是指具体程序设计语言的对象或实体，通常存在于一个服务程序进程之中。客户程序通过对象引用发出的请求经过ORB担当中介角色，转换为对特定的伺服对象的调用。在一个 CORBA 对象的生命期中，它可能 与多个伺服对象相关联，因而对该对象的请求可能被发送到不同的伺 服对象。

  

对象标识(0bject ID)是一个用于在POA中标识一个CORBA 对象的字符串。它既可由程序员指派，也可由对象适配器自动分配，这两种方式都要求对象标识在创建它的对象适 配器中必须具有唯一性。

A

UDDI是发现注册，WSDL是描述服务，SOAP是消息格式，BPEL好像是功能的编排。

C，D。

A；C，C；C。答案： A；C，C，D。

可修改性(modifiability)是指能够快速地以较高的性能价格比对系统进行变更的能力。通常(modifiability)以某些具 体的变更为基准，通过考察这些变更的代价衡量可修改性。可修改性包含四个方面。

• (1) 可维护性(maintainability)。这主要体现在问题的修复上：在错误发生后“修复”软件系(maintainability)统。为可维护性做好准备的软件体系结构往往能做局部性的修改并能使对其他构件的负面影响最小化。
• (2)可扩展性(extendibility)。这一点关注的是使用新特性来扩展软件系统，以及使用改进版本来替换构件并删除不需要或不必要的特性和构件。为了实现可扩展性，软件系统需要松散耦合的构件。其目标是实现一种体系结构，它能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的体系结构中也是必要的。
• (3)结构重组(reassemble)。这一点处理的是重新组织软件系统的构件及构件间的关系，例如通过 将构件移动到一个不同的子系统而改变它的位置。为了支持结构重组，软件系统需要精心设计构件之间的关系。理想情况下，它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。
• (4)可移植性(portability)。可移植性使软件系统适用于多 种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植，需要按照硬件无关的方式组织软件系统，其他软件系统和环境被提取出。可移植性是系统能够在不同计算环境下运行的能力。这些环境可能是硬件、软件，也可能是两者的结合。在关于某个特定计算环境的所有假设都集中在一个构件中时，系统是可移植的。如果 移植到新的系统需要做些更改，则可移植性就是一种特殊的可修改性。

总结：可维护(错误修复)、可扩展(新特性，改进)、结构重组(重组构件间关系，如位置变化)、可移植(多种平台(软硬件，界面，系统，语言，编译器等))

A

A，A

控制者首先定义清洁流程，一般是提供选项(任务)然后根据需要自我定义流程，偏向于规则系统，事件触发的这个是事件驱动(独立构件的)，但是选项没有，所以选C。业务灵活组合，肯定是虚拟机风格，但虚拟机风格有基于规则系统和解释器，基于规则系统比较复杂高大上，一般用于决策支持DSS、专家系统ES、人工智能这些，公司的web业务没这么复杂，选D

C。语音识别，黑板系统，经典。

A，C，D，A，B，B。

C，引入一层效率自然降低。

A，B；B。答案： A，B，C。质量属性，性能只是其中一个质量属性。

D；B，C。答案： B；B，C。

ADL：即架构描述语言，其基本构成要素包括：组件、组件接口、连接件、架构配置。

组件(构件)是一个计算单元或数据存储。也就是说，组件是计算与状态存在的场所。在架构中，一个构件可能小到只有一个过程或大到整个应用程序。连接件是用来建立组件间的交互以及支配这些交互规则的架构构造模块。架构配置或拓朴是描述架构的组件与连接件的连接图。

C

C

B，D。

B；B，D。

现代编译器基本都是数据共享(仓库)风格。根据语义和理解选交互作用和视图(4+1)

C ,D ,B 

B，A，C，B，B，C。

A，D。

被分为四个主要的活动领域(或阶段),分别是场景和需求收集、体系结构视图和场景实 现、 属性模型构造和分析、 折中。体系结构权衡分析方法 是在 SAAM的基础上发展 起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之 前，对这些质量属性进行评价和折中。

• (1)特定目标：ATAM的目标是在考虑多个相互影响的质量属性ATAM的情况下，从原则上提供一种理解软件体系结构的能力的方法。对于特定的软件体系结构，在系统开发之前，可以使用ATAM方法确定在多个质量属性之间折中的必要性。
• (2)质量属性：ATAM方法分析多个相互竞争的质量属性。开始时考虑的是系统的可修改性、安全性、性能和可用性。

• (3)风险承担者：在场景、需求收集有关的活动中，ATAM方法需要所有系统相关人员的参与。 
• (4)体系结构描述：体系结构空间受到历史遗留系统、互操作性和以前失败的项目约束。在五个基本结构的基础上进行体系结构描述，这五个结构是从Kruchten的4+1视图派生而来的。其中逻辑视图被分为 Kruchten 4 + 1功能结构和代码结构。这些结构加上它们之间适当的映射可以完整地描述一个体系结构。用一组消息顺序图显示运行时的交互和场景，对体系结构描述加以注解。ATAM 方法被用于体系结构设计中， ATAM或被另一组分析人员用于检查最终版本的体系结构。
• (5)评估技术：可以把 ATAM方法视为一个框架，该框架依赖于质量属性，可以使用不同的分析技术。它集成了多个优秀的单一理论模型，其中每一个都能够高效、实用地处理属性。该方法使用了场景技术。从不同的体系结构角度，有三种不同类型的场景，分别是用例(包括对系统典型的使用，还用于引出信息)、增长场景(用于涵盖与它的系统修改)、探测场景(用于涵盖那些可能会对系统造成压迫的极端修改)。

软件架构设计不能管理系统的复杂性吧，只能降低复杂性，选D。需求模型转架构模型，可追踪性为首要吧，选C。

实际答案： C，C。

软件架构设计不能捕获需求，软件架构设计是在需求捕获并进行分析之后开展的工作。

A，D，A。答案： A，D，C。

4+1”视图模型从五个不同的视角来描述软件架构，每个视图只关心系统的一个侧面，五个视图结合在一起才能反映软件架构的全部内容。

• (1)逻辑视图。逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图 中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能 分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在00技术中，通过抽 象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。逻辑视图中使用的风 格为面向对象的风格，在设计中要注意保持一个单一的、内聚的对象模型贯穿整个系统。
• (2)开发视图。开发视图也称为模块视图，在UML中被称为实现视图，它主要侧重于软件模块的组织和管理。开发视图要考虑软件内部的需求，例如，软件开发的容易性、软件复用和软件的通用 性，要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统I/0关系的模型图和子系统图来描述。
• (3)进程视图。进程视图侧重于系统的运行特性，主要关注一些非功能性需求，例如，系统的性能和可用性等。进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的功能抽象 如何适合进程结构等，它也定义了逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进 程视图可以描述成多层抽象，每个级别分别关注不同的方面。
• (4)物理视图。物理视图在 UML中被称为部署视图，它主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装和通信等问题。当软件运行于不同的物理节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活 性，当环境改变时，对系统其他视图的影响最小化。
• (5)场景。场景可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。场景视图对应 UML中的用例视图。在开发软件架构时，它可以帮助架 构设计师找到构件及其相互关系。同时，架构设计师也可以用场景来分析一个特定的视图，或描述 不同视图的构件之间是如何相互作用的。场景可以用文本表示，也可以用图形表示。

下面是题目选项中几种UML图的解释，从中可以了解题目所描述的，是哪一种UML图。

• (1)对象图(object diagram)。对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。

• (2)活动图(activity diagram)。活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调 对象间的控制流程。
• (3)状态图(state diagram)。状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。
• (4)类图(class diagram)。类图描述一组类、接口、协作和它们之间的关系。在00系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。

状态图：描述单个对象在多个用例中的动态行为，包含了对象的具体活动，状态，转换，事件，动作等等。

‌

B，C；B，C。专家是提供知识的，分析人员获取知识，然后分析并应用到(映射)领域模型(需求)上，设计人员根据领域模型(需求)和现有系统开发DSSA（目前也是文档上的架构），当然也需要对DSSA的准确性和一致性验证。

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

• 1、领域专家 领域专家可能包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及 项目管理的有经验的软件工程师等。领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品，等等。 DSSA领域专家应该熟悉该领域中系统的软件设计和实现、硬件限制、未来的用户需求及技术走向等。
• 2、领域分析人员领域分析人员应由具有知识工程背景的有经验的系统分析员来担任。领域分析人员的主要任务包括控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模 型中，根据现有系统、标准规范等验证领域模型的准确性和一致性，维护领域模型。领域分析人员应熟悉软件重用和领域分析方法；熟悉进行知识获取和知识表示所需的技术、语言和 工具；应具有一定的该领域的经验，以便于分析领域中的问题及与领域专家进行交互；应具有较高 的进行抽象、关联和类比的能力；应具有较高的与他人交互和合作的能力。
• 3、领域设计人员 领域设计人员应由有经验的软件设计人员来担任。领域设计人员的主要任务包括控制整个软件设计过程，根据领域模型和现有的系统开发出 DSSA,对 DSSA的准确性和一致性进行验证，建立领域模型和 DSSA之间的联系。领域设计人员应熟悉软件重 DSSA用和领域设计方法；熟悉软件设计方法；应有一定的该领域的经验，以 便于分析领域中的问题及与领域专家进行交互。
• 4、领域实现人员 领域实现人员应由有经验的程序设计人员来担任。领域实现人员的主要任务包括根据领域模型和 DSSA,或者从头开发可重用构件，或者利用再工程的 DSSA技术从现有系统中提取可重用构件，对可重用构件进行验证，建立 DSSA与可重用构件间的联系。领域实现人员应熟悉软件重用、领域实现及软件再工程技术；熟悉程序设计；具有一定的该领域的经验。

A。涉及需求是否满足以及质量需求是否满足，一般来说用户不是首选，用户只能确定他提了那些需求，至于质量需求用户并不太懂，系统拥有者也是同用户，测试人员更不关心，也不是在复审阶段参与的。当然了，复审也是需要用户(这一类人)参与的，毕竟也需要确认需求的。

实际答案选B。基础不牢固。

架构复审一词来自于ABSD。在ABSD中，架构设计、文档化和复审是一个迭代过程。从这个方面来 说，在一个主版本的软件架构分析之后，要安排一次由外部人员(用户代表和领域专家)参加的复审。复审的目的是标识潜在的风险，及早发现架构设计中的缺陷和错误，包括架构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设 计是否满足功能与性能的要求等等。由外部人员进行复审的目的是保证架构的设计能够公正地进行检验，使组织的管理者能够决定正式 实现架构。

C，C，A，B，D，A

敏感点：一个或多个构建的特性；权衡点：影响多个质量属性的特性，多个质量属性的敏感点。

题目明确说明了对系统性能和安全性产生影响，对这两个质量属性影响，所以是权衡点D。

前半段说的是功能，并设置多少时间并且能接受，非风险点。选B。

B，B。答案：C，B。

ATAM是建立在SAAM基础上的。SAAM主要关注可修改性，其他的属性也可以，但主要还是可修改性。它研究的主要是些文档。

A，A，B；C。

软件系统架构是关于软件系统的结构、行为和属性的高级抽象。在描述阶段，其对象是直接构成系统的抽象组件以及各个组件之间的连接规则，特别是相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体类或者对象。软件系统架构不仅指定了软件系统的组织结构和拓扑结构，而且显示了系统需求和构成组件之间的对应关系，包括设计决策的基本方法和基本原理。

件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。例如，如果某人把系统描述为“客户/服务器”模式，则不必给出设计细节，我们立刻会明白系统是如何组织和工 作的。

C。答案D。

A，B。答案：B，C。

A，C，A，B，D。答案：B，C，A，B，D

“使IDE 能够生成符合新操作系统要求的运行代码”,这一要求是可以通过适配策略满足的，像设计模式中的适配器模式便是采用适配的方式，形成一致的接口。

“模拟新操作系统的运行环境”是典型的虚拟机架构风格的特长。

C，C，D，D，A。答案： A，C，D，B，C。

2 基于架构的软件开发方法

ABSD方法有3个基础。第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块 的内聚和耦合技术。第二个基础是通过选择体系结构风格来实现质量和业务需求。第三个基础是软 件模板的使用。软件模板利用了一些软件系统的结构。 ABSDM模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现、演化等六个子过程。

 

架构需求规格说明    和      测试架构需求的质量设计说明书。

A的架构需求说明书(需求说明书)和需求规格说明书(需求规格说明书)区别：

1.需求说明书是用户需求，需要跟用户确认的，对外的。

2.需求规格说明书是系统需求，对内的

软件架构的文档要求与软件开发项目中的其他文档是类似的。文档的完整性和质量是软件架构成功的关键因素。软件架构文档应该从使用者的角度进行书写，针对不同背景的人员采用不同的书写方式，并将文档分发给相关人员。 架构文档要保持较新，但不要随时保证文档最新，要保持文档的稳定性 。

C，A，A，D，B，D，C。答案： C， A，C，D，A，D，C。

A，C，D。

以上的解析明白了：

1.数据流风格：分批处理和管道-过滤器，管道-过滤器是非整体传输的，过滤器（构件）不能与其他过滤器共享数据，管道（连接件）是传数据流的，非整体；批处理是整体数据传输的。

2.经典例子：Unixshell编写的程序，传统编译器。

目前经典的理解是：基于规则的都是比较高大上的，用于人工智能，DSS、ES等这些，只有没有解释器的情况下，才选基于规则的。本题目描述的肯定是虚拟机风格，它下面就这两个具体风格。

还是利用经典的理解，题目的业务灵活组合，那肯定是虚拟机风格了，基于规则的是高大上的AI、DSS、ES等，解释器能普适一些，它两个都在选解释器。

D，B。

​​​​​​​

C，D

C