2017年系统架构设计师案例分析试题加答案(1)

2017年系统架构设计师案例分析试题加答案（1）
系统架构设计师考试属于软考中的一项高级资格考试，考试分综合知识、案例分析和论文3个科目。

下午的案例分析是考试的一大难点，希赛小编为大家整理了几道系统架构设计师案例分析试题，希望对大家有所帮助。

阅读以下关于软件系统架构选择的说明，回答问题。

希赛公司欲针对Linux操作系统开发一个KWIC(KevWordinContext)检索系统。

该系统接收用户输入的查洵关键字，依据字母顺序给出相关帮助文档并根据帮助文档内容进行循环滚动阅读。

在对KWIC系统进行需求分析时，公司的业务专家发现用户后续还有可能采用其他方式展示帮助内容。

根据目前需求，公司的技术人员决定通过重复剪切帮助文档中的第一个单词并将其插入到行尾的方式实现帮助文档内容的循环滚动，后续还将采用其他的方法实现这一功能。

在对KWIC系统的架构进行设计时，公司的架构师王工提出采用共享数据的主程序-子程序的架构风格，而李工则主张采用管道-过滤器的架构风格。

在架构评估会议上，大家从系统的算法变更、功能变更、数据表示变更和性能等方面对这两种方案进行评价，最终采用了李工的方案。

1、在实际的软件项目开发中，采用恰当的架构风格是项目成功的保证。

请用200字以内的文字说明什么是软件架构风格，并对主程序-子程序和管道-过滤器这两种架构风格的特点进行描述。

2、请完成表中的空白部分(用+表示优、-表示差)，对王工和李工提出的架构风格进行评价，并指出采用李工方案的原因。

3、规划图是李工给出的架构设计示意图，请将恰当的功能描述填入图中的(1)～(4)。

参考答案
1、软件架构风格是拙述特定软件系统组织方式的惯用模式。

组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。

主程序-子程序架构风格中，所有的计算构件作为子程序协作工作，并由一个主程序顺序地调用这些子程序，构件通过共享存储区交换数据。

管道-过滤器架构风格中，每个构件都有一组输入和输出，构件接受数据输入，经过内部处理，然后产生数据输出。

这里的构件称为过滤器，构件之间的连接件称为数据流传输的管道。

[解析]
本题是一道架构设计方面的试题，考查的内容是常见架构风格的选用。

这就涉及不同架构风格的优势、劣势、应用场合的比较分析。

考查架构风格的基本概念与主程序-子程序、管道-过滤器的特点。

这一空属于送分题，难度较低。

①软件架构风格的概念软件架构设计的一个核心问题是能否使用重复的架构模式，即能否达到架构级的软件重用。

也就是说，能否在不同的软件系统中，使用同一架构。

基于这个目的，学者们开始研究和实践软件架构的风格和类型问题。

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式(idiomaticparadigm)。

架构风格定义了一个系统“家族”，即一个架构定义、一个词汇表和一组约束。

词汇表中包含一些构件和连接件类型，而约束指出系统是如何将这些构件和连接件组合起来的。

架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统。

按这种方式理解，软件架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。

对软件架构风格的研究和实践促进了对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。

架构风格的不变部分使不同的系统可以共享同一个实现代码。

只要系统是使用常用的、规范的方法来组织，就可使别的设计师很容易地理解系统的架构。

例如，如果某人把系统描述为客户/服务器模式，则不必给出设计细节，相关人员立刻就会明白系统是如何组织和工作的。

②主程序与子程序Garlan和Shaw对通用软件架构风格进行了分类，他们将软件架构分为数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。

题目中的主程序-子程序架构风格属于调用/返回风格，管道-过滤器架构风格属于数据流风格。

主程序-子程序是单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。

过程调用作为交互机制，即充当连接件的角色。

调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。

③管道-过滤器在管道-过滤器风格的软件架构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。

这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。

因此，这里的构件被称为过滤器，这种风格的连接件就像是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。

此风格特别重要的过滤器必须是独立的实体，它不能与其他的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。

一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。

规划图是管道与过滤器风格的示意图。

一个典型的管道-过滤器架构的例子是以UNIXShell编写的程序。

UNIX既提供一种符号，以连接各组成部分(UNIX的进程)，又提供某种进程运行时机制以实现管道。

另一个著名的例子是传统的编译器。

传统的编译器一直被认为是一种管道系统，在该系统中，一个阶段(包括词法分析、语法分析、语义分析和代码生成)的输出是另一个阶段
的输入。

管道-过滤器风格的软件架构具有许多很好的特点。

·使得软构件具有良好的隐蔽性和高内聚、低耦合的特点。

·允许设计师将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成。

·支持软件重用。

只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来。

·系统维护和增强系统性能简单。

新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉。

·允许对一些如吞吐量、死锁等属性的分析。

·支持并行执行。

每个过滤器作为一个单独的任务完成，因此可与其他任务并行执行。

但是，这样的系统也存在着若干不利因素。

·通常导致进程成为批处理的结构。

这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计师必须将每个过滤器看成一个完整的从输入到输出的转换。

·不适合处理交互的应用。

当需要增量地显示改变时，这个问题尤为严重。

·因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

2、
根据题干描述：“用户后续还有可能采用其他方式展示帮助内容”，因此KWIC系统对功能变更要求较高。

根据题干描述：“……，后续还将采用其他的方法实现这一功能”，因此KWIC系统对实现某一个功能的算法变更要求较高。

KWIC是一个支持用户交互的窗口界面程序，因此对性能要求并不高。

KWIC系统显示的帮助内容为文本，数据的表示基本不变，因此对数据表示变更要求不高。

综合上述分析，可以看出应该采用李工提出的管道-过滤器架构风格。

子程序和管道-过滤器优缺点对比。

这两种风格的优缺点包括多方面的很多内容，但要应对该题，并不需要我们面面俱到地把每一个细节记清楚。

只要了解两者的核心思想即可。

本问题的核心是对两种架构风格在算法变更、功能变更、数据表示变更和性能等方面的特点进行比较。

其中共享数据的主程序-子程序在算法变更方面灵活性较差，算法变更时一般需要重新编译整个系统；在功能变更方面也比较差；在数据表示方面，当需要变更时，也意味着程序传递参数的变化以及整个程序的调
整，表现比较差；在性能方面，由于整个程序处在一个紧耦合的状态，因此性能较高。

管道-过滤器架构风格在算法变更方面实现比较简单，只需要修改过滤器的实现即可；在功能变更方面也比较简单；在数据表示方面，需要同时改变数据格式和过滤器的结构，相对比较复杂；在性能方面，由于整个系统是松耦合连接在一起的，因此性能不太高。

根据题干描述：“用户后续还有可能采用其他方式展示帮助内容”，因此KWIC系统对功能变更要求较高；根据题干描述：“…，后续还将采用其他的方法实现这一功能”，因此KWIC系统对实现某一个功能的算法变更要求较高；KWIC是一个支持用户交互的窗口界面程序，因此对性能要求并不高；KWIC系统的显示帮助内容为文本，数据的表示基本不变，因此对数据表示变更要求不高。

针对这些考虑，可以看出应该采用管道-过滤器的架构风格。

3、完整的架构示意图如图所示。

是补充架构设计示意图。

其实这个图要表现出来的，无非就是利用管道-过滤器架构，需要处理的信息的操作有哪些，按什么顺序排列。

根据题干中的关键描述“……接收用户输入的查询关键字，依据
字母顺序给出相关帮助文档并根据帮助内容进行循环滚动阅读……”和“××公司的技术人员决定通过重复剪切帮助文档中的第一个单词并将其插入到行尾的方式实现帮助文档内容的循环滚动……”，可以看出整个系统的流程是：输入→文档检索→查询结果按字母排序→剪切行首单词→单词插入行尾→输出。