高级系统架构师
单选题采用以架构为核心的软件开发方法，在建立软件架构的初期，首要任务是选择一个合适的（1），在此基础上，开发人员通过架构模型，可以获得关于（2）的理解，为将来的架构实现与演化过程建立了目标。 空白（1）处应选择（）A 分析模式B 设计模式C 架构风格D 架构标准
题目
分析模式
设计模式
架构风格
架构标准
相似问题和答案
第1题：
ANSI/IEEE 1471-2000是对软件密集型系统的架构进行描述的标准。在该标准中，（ ）这一概念主要用于描述软件架构模型。在此基础上，通常采用（ ）描述某个利益相关人（Stakeholder）所关注架构模型的某一方面。（ ）则是对所有利益相关人关注点的响应和回答。
A.上下文 B.架构风格 C.组件 D.视图 A.环境 B.资源 C.视角 D.场景 A.架构 B.系统 C.模型 D.使命
第2题：
采用以架构为核心的软件开发方法，在建立软件架构的初期，首要任务是选择一个合适的（ ），在此基础上，开发人员通过架构模型，可以获得关于（ ）的理解，为将来的架构实现与演化过程建立了目标。
A.分析模式 B.设计模式 C.架构风格 D.架构标准 A.架构需求 B.架构属性 C.架构优先级 D.架构约束
第3题：
试题（45）
软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动，是一个迭代的过程。以下关于软件架构设计活动的描述，错误的是 （45） 。
（45）
A. 在建立软件架构的初期，一般需要选择一个合适的架构风格
B. 将架构分析阶段已标识的构件映射到架构中，并分析这些构件之间的关系
C. 软件架构设计活动将已标识构件集成到软件架构中，设计并实现这些构件
D. 一旦得到了详细的软件架构设计，需要邀请独立于系统开发的外部人员对系统进行评审
试题（45）分析
软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动，是一个迭代的过程，在建立软件架构的初期，一般需要选择一个合适的架构风格，并将架构分析阶段已标识的构件映射到架构中，并分析这些构件之间的关系，一旦得到了详细的软件架构设计，需要邀请独立于系统开发的外部人员对系统进行评审。一般来说，软件架构设计活动将已标识构件集成到软件架构中，设计这些构件，但不予以实现。
参考答案
（45） C
第4题：
软件架构设计包括提出架构模型，产生架构设计和进行设计评审等活动，是一个迭代的过程。架构设计主要关注软件组件的结构、属性和（ ），并通过多种（ ）全面描述特定系统的架构。
A.实现方式 B.交互作用 C.设计方案 D.测试方式 A.对象 B.代码 C.文档 D.视图
第5题：
论软件架构建模技术与应用
软件架构用来处理软件高层次结构的设计和实施，它以精心选择的形式将若干结构元素进行装配，从而满足系统的主要功能和性能需求。软件架构设计的首要问题是如何表示软件架构，即如何对软件架构建模。根据建模的侧重点不同，可以将软件架构模型分为结构模型、框架模型、动态模型、过程模型和功能模型。Kruchten在1995年提出了“4+1”视图模型，将5种模型有机地统一在了一起。
请围绕“软件架构建模技术与应用”论题，依次从以下三个方面进行论述。
1．概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。
2．简要叙述“4+1”视图模型的主要内容。结合你参与项目的实际情况，详细说明该项目需求及所涉及的软件架构（包括使用到的视图模型、创建的架构模型及使用的建模工具等）。
3．说明该项目软件架构的实施效果，分析其是否满足了项目的需求并说明原因。
写作要点
一、简要叙述所参与管理和开发的软件项目，并明确指出在其中承担的主要任务和开展的主要工作。
二、简要叙述“4+1”视图模型的主要内容。
1、“4+1”视图模型从5个不同的视角来描述软件架构，每个视图只关心系统的1个侧面，5个视图结合在一起才能反映系统的软件结构的全部内容。这5个不同的视角包括逻辑视图、开发视图、进程视图、物理视图和场景。
逻辑视图。逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。在OO技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。
开发视图。开发视图也称为模块视图，在UML中被称为实现视图，它主要侧重于软件模块的组织和管理。开发视图要考虑软件内部的需求。
进程视图。进程视图侧重于系统的运行特性，主要关注一些非功能性需求。进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的功能抽象如何适应进程结构等，它也定义了逻辑视图中的各个类的操作具体是在哪一个线程中被执行。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。
物理视图。物理视图在UML中被称为部署视图，主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装和通信等问题。
场景。场景可以看作是那些重要系统活动的抽象，它使4个视图有机联系起来。场景对应UML中的用例视图。
2、结合实际项目，详细说明项目软件架构的内容。这部分内容应包括：在设计软件架构时，分别使用了“4+1”视图中的哪些视图，每个视图中包含的模型有哪些等。
三、说明该项目软件架构的实施效果，分析其是否满足了项目的需求并说明原因。
（1）加解密API：数据库管理系统提供可在SQL语句中调用的加解密API，应用可以利用这些API构建自己的基础架构，对数据进行加密保护。
（2）透明加密：安全管理员为数据库敏感字段选择加密方式及密钥强度，应用访问受保护数据时只需使用口令打开或关闭密钥表，对数据的加密和解密由数据库管理系统自动完成。
加解密API方式的灵活性强，但构建和管理复杂；而透明加密方式管理简单，应用程序负担轻，但灵活性较差。用户要求尽可能减少安全管理与应用程序的负担，因此应选择透明加密方式。
第6题：
论基于架构的软件设计方法及应用 基于架构的软件设计（Architecture-Based Software Design，ABSD）方法以构成软件架构的商业、质量和功能需求等要素来驱动整个软件开发过程。ABSD是一个自顶向下，递归细化的软件开发方法，它以软件系统功能的分解为基础，通过选择架构风格实现质量和商业需求，并强调在架构设计过程中使用软件架构模板。采用ABSD方法，设计活动可以从项目总体功能框架明确后就开始，因此该方法特别适用于开发一些不能预先决定所有需求的软件系统，如软件产品线系统或长生命周期系统等，也可为需求不能在短时间内明确的软件项目提供指导。
请围绕“基于架构的软件开发方法及应用”论题，依次从以下三个方面进行论述。 1. 概要叙述你参与开发的、采用ABSD方法的软件项目以及你在其中所承担的主要工作。 2. 结合项目实际，详细说明采用ABSD方法进行软件开发时，需要经历哪些开发阶段？每个阶段包括哪些主要活动？ 3. 阐述你在软件开发的过程中都遇到了哪些实际问题及解决方法。
一、论文中要具体介绍项目的背景与总体需求、系统所采用的技术路线以及你所承担的实际工作。
二、采用ABSD方法进行软件开发时，需要经历架构需求、架构设计、架构文档化、架构复审、架构实现和架构演化六个阶段。
1. 架构需求阶段需要明确用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。其主要活动包括需求获取、标识构件和架构评审。
（1）需求获取活动需要定义开发人员必须实现的软件功能，使得用户能够完成他们的任务，从而满足功能需求。与此同时，还要获得软件质量属性，满足一些非功能性需求。
（2）标识构件活动首先需要获得系统的基本结构，然后对基本结构进行分组，最后将基本结构进行打包成构件。
（3）架构需求评审活动组织一个由系统涉众（用户、系统分析师、架构师、设计实现人员等）组成的小组，对架构需求及相关构件进行审查。审查的主要内容包括所获取的需求是否真实反映了用户需求，构件合并是否合理等。
2. 架构设计阶段是一个迭代过程，利用架构需求生成并调整架构决策。主要活动包括提出架构模型、将已标识的构件映射到架构中、分析构件之间的相互作用、产生系统架构和架构设计评审。
3. 架构文档化的主要活动是对架构设计进行分析与整理，生成架构规格说明书和测试架构需求的质量设计说明书。
4. 在一个主版本的软件架构分析之后，需要安排一次由外部人员（客户代表和领域专家）参加的架构复审。架构复审需要评价架构是否能够满足需求，质量属性需求是否在架构中得以体现、层次是否清晰、构件划分是否合理等。从而标识潜在的风险，及早发现架构设计中的缺陷和错误。
5. 架构实现主要是对架构进行实现的过程，主要活动包括架构分析与设计、构件实现、构件组装和系统测试。
6. 架构演化阶段主要解决用户在系统开发过程中发生的需求变更问题。主要活动包括架构演化计划、构件变动、更新构件的相互作用、构件的组装与测试和技术评审。
三、在软件开发的过程中可能遇到的问题包括：在架构需求获取过程中如何对捕获的架构需求进行筛选和优先级排序；在架构复审过程中如何解决评审人员的意见不一致问题；在架构实现过程中如何根据项目组实际情况选择开发语言与开发平台；在架构演化过程中如何筛选并处理用户的需求变更，等等。
第7题：
试题一论模型驱动架构在系统开发中的应用 模型驱动架构(Model Driven Architecture，MDA)是对象管理组织提出的软件体系架构方法学，它基于UML以及一系列工业标准，能够支持基于可视化模型驱动的软件设计、内容存储与交换。MDA核心思想是抽象出与实现技术无关、完整描述业务功能的核心平台无关模型(PIM)，然后针对不同实现技术制定多个映射规则，通过映射规则和辅助工具将PIM转换成与具体实现技术有关的平台相关模型(PSM)，最后完成PSM到代码的转换。通过PIM和PSM，MDA分离业务建模与底层实现技术，降低技术变迁对业务模型带来的影响。
请围绕“模型驱动架构在系统开发中的应用”论题，依次从以下三个方面进行论述。
1．简要叙述你参与管理和开发的、与MDA相关的软件开发项目以及你所担任的主要工作。
2．简要分析模型驱动架构能够为软件开发带来哪些好处，详细论述采用模型驱动架构进行开发的过程。
3．具体阐述你参与管理和开发的项目中使用模型驱动架构的情况与实际开发效果。
试题一写作要点
1、模型驱动架构能够为软件开发带来的好处
（1）模型驱动架构将开发人员的注意力转移到了平台无关模型中，可以避免陷入到具体的实现细节当中去，从而简化了系统开发的工作量，提高了软件的开发效率。
（2）对于多种流行平台，很多工具会支持从平台无关模型到平台相关模型的转换；对于将来可能出现的新技术和平台，确定了平台表示及公共中间件的概念和功能，利用转换规则快速实现平台无关模型到新技术平台的迁移，提高了系统的可移植性。
（3）利用模型驱动架构中基于平台无关模型的桥接器，实现了多个平台相关模型之间跨平台的相互通信，加强了互操作性。
（4）对于系统变更，通过修改平台无关模型并重新生成平台相关模型和代码，能够降低系统维护的成本。
（5）平台无关模型帮助团队成员之间提高沟通效率并减少错误，自动生成代码能够保证代码的质量和一致性，确保了软件的质量。
（6）使用模型驱动架构时，功能和架构独立定义，针对新技术，能够利用原有的设计产生对应的实现，延长了系统的生命周期。
2、模型驱动架构的开发过程
（1）使用平台无关模型从如何以最好的方式支持商业逻辑的角度对系统进行建模，开发人员根据用户需求和其它因素对平台无关模型进行精化，以使它能够更加精确地描述系统。
（2）将平台无关模型转换到一个或多个特定技术相关的平台相关模型，对于每种特定的技术都会生成独立的平台相关模型。
（3）根据技术特性对生成的平台相关模型进行修改以满足程序设计人员的要求，这些修改可以反映到平台无关模型中去。
（4）对平台相关模型不断精化，以指导代码生成器生成质量更高的程序代码。
（5）最后将每个平台相关模型转换到代码，进行后续的完善和系统测试。
3、结合项目的实际情况，具体阐述你参与管理和开发的项目中使用模型驱动架构的情况，包括平台无关模型构建、平台相关模型的技术方案选择和实际开发效果及分析。
第8题：
● 软件架构文档是对软件架构的正式描述，能够帮助与系统有关的开发人员更好地理解软件架构。软件架构文档的写作应该遵循一定的原则。以下关于软件架构文档写作原则的叙述中，错误的是 （49） 。
（49）
A. 架构文档应该从架构设计者的角度进行编写
B. 应该保持架构文档的即时更新，但更新不要过于频繁
C. 架构文档中的描述应该尽量避免不必要的重复
D. 每次架构文档修改，都应该记录修改的原则
试题（49）分析
软件架构文档是对软件架构的一种描述，帮助程序员使用特定的程序设计语言实现软件架构。软件架构文档的写作应该遵循一定的原则，这些原则包括：文档要从使用者的角度进行编写；必须分发给所有与系统有关的开发人员；应该保持架构文档的即时更新，但更新不要过于频繁；架构文档中描述应该尽量避免不必要的重复：每次架构文档修改都应该记录进行修改的原则。
参考答案
（49）A
第9题：
软件架构为软件系统提供了一个结构、行为和属性的高级抽象模式。“4+1”视图模型指用5个视图组成的模型来描述软件架构。其中，(50)描述了软件的静态组织结构，支持软件开发的内部需求。
A．物理视图
B．逻辑视图
C．进程视图
D．开发视图
解析：软件架构是指大型、复杂软件系统结构的设计、规格说明和实施。它以规范的形式装配若干结构元素，从而描述出系统的主要功能和性能要求，同时表述其他非功能性需求(如可靠性、可扩展性、可移植性和可用性等)。软件架构为软件系统提供了一个结构、行为和属性的高级抽象模式，可以使用公式“软件架构={构成系统的元素，指导元素集成的形式，关系和约束}”来表达。
“4+1”视图模型用5个视图组成的模型来描述软件架构。该模型包含5个主要视图及其实现的功能如表7-7所示。
第10题：
论软件系统架构评估 对于软件系统，尤其是大规模的复杂软件系统来说，软件的系统架构对于确保最终系统的质量具有十分重要的意义，不恰当的系统架构将给项目开发带来高昂的代价和难以避免的灾难。对一个系统架构进行评估，是为了：分析现有架构存在的潜在风险，检验设计中提出的质量需求，在系统被构建之前分析现有系统架构对于系统质量的影响，提出系统架构的改进方案。架构评估是软件开发过程中的重要环节。
请围绕“论软件系统架构评估”论题，依次从以下三个方面进行论述。 1．概要叙述你所参与架构评估的软件系统，以及在评估过程中所担任的主要工作。 2．分析软件系统架构评估中所普遍关注的质量属性有哪些？详细阐述每种质量属性的具体含义。 3．详细说明你所参与的软件系统架构评估中，采用了哪种评估方法，具体实施过程和效果如何。
一、首先用400-600字的篇幅简要叙述作者参与开发的软件系统的概要和所担任的工作。
二、架构所关注的质量属性主要包括：性能、可用性、可修改性、安全性。
1、性能
性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。
2、可用性
可用性（availability）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
3、安全性
安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
4、可修改性
可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。
三、架构评估方法主要从SAAM与ATAM中选择。
1、SAAM评估方法
SAAM的分析和评估目的、评估参与者、评估活动或过程以及评估结果说明如下。
（1）评估目的
SAAM (Scenario-based Architecture Analysis Method)目的是验证基本的体系结构假设和原则，评估体系结构固有的风险。SAAM 指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突。SAAM不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。
（2）评估参与者
风险承担者、记录人员、软件体系结构设计师
（3）评估活动或过程
SAAM分析评估体系结构的过程包括六个步骤，即形成场景、描述体系结构、场景的分类和优先级确定、间接场景的单个评估、场景相互作用的评估、总体评估。
（4）评估结果
SAAM评估的主要有形输出包括：
1）把代表了未来可能做的更改的场景与构架对应起来，显现出构架中未来可能会表现出较高复杂性的地方，并对每个这样的更改的预期工作量做出评估。
2）理解系统的功能，对多个构架所支持的功能和数量进行比较。
如果所评估的是一个框架，SAAM评估将指明框架中未能满足其修改性需求的地方，有时还会指出一种效果更好的设计。SAAM评估也能对两个或者三个备选构架进行比较，明确其中那一个能够较好地满足质量属性需求，而且做的更改较少、不会在未来导致太多的复杂的问题。
2、ATAM评估方法
ATAM的分析和评估目的、评估参与者、评估活动或过程以及评估结果说明如下。
（1）评估目的
ATAM（Architecture Tradeoff Analysis Method ），即构架权衡分析方法的评估目的是依据系统质量属性和商业需求评估设计决策的结果。ATAM希望揭示出构架满足特定质量目标的情况，使我们更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标。
（2）评估参与者
1）评估小组。该小组是所评估构架项目外部的小组，通常由3~5人组成。该小组的每个成员都要扮演大量的特定角色。他们可能是开发组织内部的，也可能是外部的。
2）项目决策者，对开发项目具有发言权，并有权要求进行某些改变，他们包括项目管理人员，重要的客户代表，构架设计师等。
3）构架涉众（stakeholders）。包括关键模块开发人员、测试人员、用户等。
（3）评估活动或过程
整个ATAM评估过程包括九个步骤，按其编号顺序分别是描述ATAM方法、描述商业动机、描述体系结构、确定体系结构方法、生成质量属性效用树、分析体系结构方法、讨论和分级场景、描述评估结果。