系统架构设计师备考

操作系统

某文件系统文件存储采用文件索引节点法。假设文件索引节点中有 8 个地址项 iaddr[0]~iaddr[7] ，每个地址项大小为 4 字节，其中地址项iaddr(0]~iaddr[5] 为直接地址索引， iaddr[6]是一级间接地址索引， iaddr[7]是二级间接地址索引，磁盘索引块和磁盘数据块大小均为 4KB,该文件系统可表示的单个文件最大长度是 (7) KB 。若要访问 iclsClient.dll 文件的逻辑块号分别为 6 、 520 和 1030 ，则系统应分别采用 (8) 。

（ 7 ） A.1030 B. 65 796 C.1049606 D. 4198424

（ 8 ） A. 直接地址索引、一级间接地址索引和二级间接地址索引
B. 直接地址索引、二级间接地址索引和二级间接地址索引
C. 一级间接地址索引、一级间接地址索引和二级间接地址索引
D. 一级间接地址索引、二级间接地址索引和二级间接地址索引

每个磁盘索引块可存放 4096/4=1024 个物理块地址。共 6 + 1024 + 1024² = 1 049 606 个物理块，单个文件的逻辑块号为 0 ～ 1 049 605 。而磁盘数据块大小为4 字节，所以单个文件最大长度是 4 198 424KB 。若要访问文件的逻辑块号分别为 6 、 520 和 1030 ，分别对应系统管理的一级间接地址索引、一级间接地址索引和二级间接地址索引范围。参考答案（ 7 ） D （ 8 ） C

数据库

数据库的安全机制中，通过提供 (5) 供第三方开发人员调用进行数据更新，从而证数据库的关系模式不被第三方所获取。

A. 索引 B. 视图 C. 存储过程 D. 触发器

存储过程是数据库所提供的一种数据库对象，通过存储过程定义一段代码，提供给应程序调用来执行。从安全性的角度考虑，更新数据时，通过提供存储过程让第三方调用，需要更新的数据传入存储过程，而在存储过程内部用代码分别对需要的多个表进行更新，而避免了向第三方提供系统的表结构，保证了系统的数据安全。

软件工程

敏捷开发

方法名称	简介
极限编程 Extreme Programming, XP	轻量级、灵巧的软件开发方法，近螺旋式的开发认为任何软件项目都可以从4个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。将开发过程分解为小周期，通过积极的交流和反馈进行调整。
水晶系列方法 Crystal	由Alistair Cockburn提出的敏捷方法系列，以人为中心，发展机动性方法。包含共性的核心元素，每个成员都有独特的角色、过程模式、工作产品和实践。根据项目和环境选择最合适的Crystal家族成员。
Scrum	迭代式增量软件开发过程，侧重于项目管理。使用产品Backlog管理需求，将开发过程分为短的迭代周期。在每个迭代结束时递交可交付的产品增量，最终提交最终的软件产品。
特征驱动开发方法 FDD Feature Driven Development,	迭代的开发模型，认为有效的软件开发需要人、过程和技术。定义6种关键的项目角色，根据项目大小可以重复。有5个核心过程：开发

系统架构设计

软件架构概念

软件架构设计与生命周期

设计阶段是S A研究关注的最早和最多的阶段，这一阶段的S A研究主要包括： S A 模型的描述、 S A模型的设计与分析方法，以及对 S A 设计经验的总结与复用等。有关S A模型描述的研究分为3个层次。 (1)SA的基本概念，即S A模型由哪些元素组成，这些组成元素之间按照何种原则组织。传统的设计概念只包括构件(软件系统中相对独立的有机组成部分，最初称为模块)以及一些基本的模块互联机制。随着研究的深入，构件间的互联机制逐渐独立出来，成为与构件同等级别的实体，称为连接子。现阶段的S A描述方法是构件和连接子的建模。近年来，也有学者认为应当把Aspect等引入S A模型。 (2)体系结构描述语言 (Architecture Description Language,ADL), 支持构件、连接子及其配置的描述语言就是如今所说的体系结构描述语言。 ADL 对连接子的重视成为区分 ADL和其他建模语言的重要特征之一。典型的 ADL 包括UniCon、Rapide、Darwin、Wright、C2 SADL、Acme、xADL、XYZ/ADL和 ABC/ADL等。 (3)SA模型的多视图表示，从不同的视角描述特定系统的体系结构，从而得到多个视图，并将这些视图组织起来以描述整体的S A模型。多视图作为一种描述S A的重要途径，也是近年来S A研究领域的重要方向之一。系统的每一个不同侧面的视图反映了一组系统相关人员所关注的系统的某一特定方面，多视图体现了关注点分离的思想。把体系结构描述语言和多视图结合起来描述系统的体系结构，使系统更易于理解，方便系统相关人员之间进行交流，并且有利于系统的一致性检测以及系统质量属性的评估。学术界已经提出若干多视图的方案，典型的包括4+1模型(逻辑视图、进程视图、开发视图、物理视图，加上统一的场景)、 Hofmesiter的4视图模型(概念视图、模块视图、执行视图和代码视图)、 CMU-SEI 的Views and Beyond模型(模块视图、构件和连接子视图、分配视图)等。此外，工业界也提出了若干多视图描述S A模型的标准，如 IEEE标准1471-2000(软件密集型系统体系结构描述推荐实践)、开放分布式处理参考模型 (RM-ODP)、统一建模语言 (UML) 以及IBM 公司推出的Zachman框架等。需要说明的是，现阶段的 ADL大多没有显式地支持多视图，并且上述多视图并不一定只是描述设计阶段的模型。

考虑体系结构时，要从不同的视角(Perspective) 来观察对架构的描述，这需要软件设计师考虑体系结构的不同属性。例如，展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性，因此，选择的特定视角或视图(如逻辑视图、进程视图、实现视图和配置视图)可以全方位的考虑体系结构设计。使用逻辑视图来记录设计元素的功能和概念接口，设计元素的功能定义了它本身在系统中的角色，这些角色包括功能、性能等。

基于体系结构的开发模型

如果采用传统的软件开发模型，软件体系结构的建立应位于需求分析之后，概要设计之前。传统软件开发模型存在开发效率不高，不能很好地支持软件重用等缺点。 ABSD模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化6个子过程。

体系结构需求

体系结构需求用来激发和调整设计决策，不同的视图被用来表达与质量目标有关的信息。

体系结构需求：需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。需求过程主要是获取用户需求，标识系统中所要用到的构件。如果以前有类似的系统体系结构的需求，可以从需求库中取出，加以利用和修改，以节省需求获取的时间。

需求获取：需求获取过程主要是定义开发人员必须实现的软件功能，同时还要获得软件质量属性，满足一些非功能需求。需求一般来自3个方面
- 系统的质量目标
- 系统的商业目标
- 系统开发人员的商业目标。
标识构件：该过程为系统生成初始逻辑结构，包含大致的构件。
1. 生成类图。生成类图
2. 对类进行分组。使用一些标准对类进行分组可以大大简化类图结构，使之更清晰。一般地，与其他类隔离的类形成一个组，由概括关联的类组成一个附加组，由聚合或合成关联的类也形成一个附加组。
3. 把类打包成构件。把在第2步得到的类簇打包成构件，这些构件可以分组合并成更大的构件。
架构需求评审：组织一个由不同代表(如分析人员、客户、设计人员和测试人员)组成的小组，对体系结构需求及相关构件进行仔细地审查。审查的主要内容包括所获取的需求是否真实地反映了用户的要求；类的分组是否合理，构件合并是否合理等。必要时，可以在“需求获取一标识构件一需求评审”之间进行迭代。

体系结构设计

体系结构设计是一个迭代过程，如果要开发的系统能够从已有的系统中导出大部分，则可以使用已有系统的设计过程。

提出软件体系结构模型。选择一个合适的体系结构风格，在这个风格的基础上，通过体系结构模型，获得关于体系结构属性的理解。为将来的实现和演化过程建立目标。这个模型是理想化的(其中的某些部分可能错误地表示了应用的特征)。
把已标识的构件映射到软件体系结构中。把在体系结构需求阶段已标识的构件映射到体系结构中，将产生一个中间结构，这个中间结构只包含那些能明确适合体系结构模型的构件。 3.分析构件之间的相互作用。为了把所有已标识的构件集成到体系结构中，必须认真分析这些构件的相互作用和关系。 4.产生软件体系结构。一旦决定了关键构件之间的关系和相互作用，就可以在第2阶段得到的中间结构的基础上进行精化。 5.设计评审。邀请独立于系统开发的外部人员对体系结构进行评审。

体系结构文档化

要让系统分析员和程序员去实现体系结构，还必须将体系结构进行文档化。文档是在系统演化的每一个阶段，系统设计与开发人员的通信媒介，是为验证体系结构设计和提炼或修改这些设计(必要时)所执行预先分析的基础。

过程的主要输出结果是两个文档：

体系结构规格说明
测试体系结构需求的质量设计说明书。

生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。文档的完整性和质量是软件体系结构成功的关键因素。文档要从使用者的角度进行编写，必须分发给所有与系统有关的开发人员，且必须保证开发者手上的文档是最新的。

软件架构风格

软件体系结构设计的一个核心目标是达到体系结构级的软件重用。基于这个目标，主要任务是研究和实践软件体系结构风格和类型问题。

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

对软件体系结构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。例如，如果某人把系统描述为“客户/服务器”模式，则不必给出设计细节，人们立刻就会明白系统是如何组织和工作的。

数据流体系结构风格
- 批处理体系结构风格
- 管道-过滤器体系结构风格：把系统分解为几个序贯的处理步骤，步骤之间通过数据流连接，每个处理步骤由一个过滤器 (Filter) 实现，处理步骤之间的数据传输由管道 (Pipe) 负责。基本构件是过滤器，连接件是数据流传输管道，将一个过滤器的输出传到另一过滤器的输入。
调用/返回体系结构风格
- 主程序/子程序风格
- 面向对象体系结构风格
- 层次型体系结构风格
- 客户端/服务器体系结构风格
以数据为中心的体系结构风格
- 仓库体系结构风格
- 黑板体系结构风格
虚拟机体系结构风格：人为构建一个运行环境，解析与运行自定义的一些语言，来增加架构的灵活性。
- 解释器体系结构风格：解释引擎完成解释工作，存储区包含将被解释的代码，一个记录解释引擎当前工作状态的数据结构、记录源代码被解释执行进度的数据结构。
- 规则系统体系结构风格
独立构件体系结构风格
- 进程通信体系结构风格
- 事件系统体系结构风格

软件架构复用

特定领域软件体系结构

特定领域软件体系结构的主要目的是在一组相关的应用中共享软件体系结构。

DSSA(Domain Specific Software Architecture) 就是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构。

DSSA的基本活动

活动	描述
领域分析	主要目标是获得领域模型。领域模型描述领域中系统之间的共同需求，
领域设计	主要目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。
领域实现	主要目标是依据领域模型和DSSA 开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。领域模型和 DSSA定义了这些可重用信息的重用时机，从而支持了系统化的软件重用。

以上过程是一个反复的、逐渐求精的过程。在实施领域工程的每个阶段中，都可能返回到以前的步骤，对以前的步骤得到的结果进行修改和完善，再回到当前步骤，在新的基础上进行本阶段的活动。

领域分析阶段中首先要进行一些准备性的活动，包括定义领域的边界，从而明确分析的对象。识别信息源，即整个领域工程过程中信息的来源。可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等。在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。当领域中存在大量系统时，需要选择它们的一个子集作为样本系统。对样本系统的需求地考察将显示领域需求的一个变化范围。一些需求对所有被考察的系统是共同的，一些需求是单个系统所独有的。很多需求位于这两个极端之间，即被部分系统共享。
领域设计阶段的主要目标是获得DSSA。建立了领域模型之后，就可以派生出满足这些被建模的领域需求的DSSA, 由于领域模型中的领域需求具有一定的变化性， DSSA 也要相应地具有变化性。它可以通过多选一的 (Alternative)、可选的(Optional) 解决方案等来做到这一点。因此在这个阶段通过获得DSSA, 也就同时形成了重用基础设施的规约。
领域实现这个阶段也可以看作重用基础设施的实现阶段。

系统质量属性与架构评估

系统架构评估中的重要概念

敏感点 (Sensitivity Point) 和权衡点 (Tradeoff Point)。敏感点和权衡点是关键的架构决策。敏感点是一个或多个构件(和/或构件之间的关系)的特性。研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。
风险承担者 (Stakeholders) 或者称为利益相关人。系统的架构涉及很多人的利益，这些人都对架构施加各种影响，以保证自己的目标能够实现。
场景 (scenarios)。在进行架构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该架构优劣的标准。为得出这些目标而采用的机制称之为场景。场景是从风险承担者的角度对与系统的交互的简短描述。在架构评估中，一般采用刺激 (Stimulus)、环境(Environment) 和响应 (Response) 三方面来对场景进行描述。

系统架构评估方法

SAAM

SAAM(Scenarios-based Architecture Analysis Method) 是一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛使用的软件架构分析方法。最初用于比较不同软件体系的架构，以分析系统架构的可修改性，后来实践证明它也可用于其他质量属性如可移植性、可扩充性等，最终发展成了评估一个系统架构的通用方法。

特定目标。目标是对描述应用程序属性的文档，验证基本的架构假设和原则。此外，该分析方法有利于评估架构固有的风险。 SAAM 指导对架构的检查，使其主要关注潜在的问题点，如需求冲突，或仅从某一参与者观点出发得出的不全面的系统设计。 SAAM 不仅能够评估架构对于特定系统需求的使用能力，也能被用来比较不同的架构。
评估技术。场景技术。场景代表了描述架构属性的基础，描述了各种系统必须支持的活动和可能存在的状态变化。
质量属性。这一方法的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是 SAAM 分析的主要质量属性。
风险承担者。 SAAM 协调不同参与者之间感兴趣的共同方面，作为后续决策的基础，达成对架构的共识。
架构描述。 SAAM 用于架构的最后版本，但早于详细设计。架构的描述形式应当被所有参与者理解。功能、结构和分配被定义为描述架构的3个主要方面。
方法活动。主要输入是问题描述、需求声明和架构描述。分析评估架构的过程包括5个步骤：

步骤	描述
场景开发	通过各类风险承担者协商讨论，开发一些任务场景，体现系统所支持的各种活动。
架构描述	用一种易于理解的、合乎语法规则的架构描述软件架构，体现系统的计算构件、数据构件以及构件之间的关系(数据和控制)。
单个场景评估	对场景(直接场景和间接场景)生成一个关于特定架构的场景描述列表。
场景交互	通过对场景交互的分析，能得出系统中所有场景对系统中的构件所产生影响的列表。
总体评估	对场景和场景间的交互作一个总体的权衡和评价。

ATAM

架构权衡分析方法 (Architecture Tradeoff Analysis Method,ATAM) 是在SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

特定目标。 ATAM 的目标是在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件架构的能力的方法。对于特定的软件架构，在系统开发之前，可以使用ATAM方法确定在多个质量属性之间折中的必要性。
质量属性。 ATAM 方法分析多个相互竞争的质量属性。开始时考虑的是系统的可修改性、安全性、性能和可用性。
风险承担者。在场景、需求收集相关活动中， ATAM 方法需要所有系统相关人员的参与。
架构描述。架构空间受到历史遗留系统、互操作性和以前失败的项目约束。架构描述基于5种基本结构来进行，这5种结构是从Kruchten 的4+1视图派生而来的。其中逻辑视图被分为功能结构和代码结构。这些结构加上它们之间适当的映射可以完整地描述一个架构。用一组消息顺序图表示运行时的交互和场景，对架构描述加以注解。 ATAM方法被用于架构设计中，或被另一组分析人员用于检查最终版本的架构
评估技术。可以把 ATAM方法视为一个框架，该框架依赖于质量属性，可以使用不同的分析技术。它集成了多种优秀的单一理论模型，其中每种都能够高效、实用地处理属性。该方法使用了场景技术。从不同的架构角度，有3种不同类型的场景，分别是用例(包括对系统典型的使用、引出信息)、增长场景(用于涵盖那些对它的系统的修改)、探测场景(用于涵盖那些可能会对系统造成过载的极端修改)。ATAM 还使用定性的启发式分析方法 (Qualitative Analysis Heuristics), 在对一个质量属性构造了一个精确分析模型时要进行分析，定性的启发式分析方法就是这种分析的粗粒度版本。