201711架构论文真题
第 1 题
论软件系统建模方法及其应用
软件系统建模（Software System Modeling）是软件开发中的重要环节，通过构建软件系统模型可以帮助系统开发人员理解系统、抽取业务过程和管理系统的复杂性，也可 以方便各类人员之间的交流。软件系统建模是在系统需求分析和系统实现之间架起的一 座桥梁，系统开发人员按照软件系统模型开发出符合设计目标的软件系统，并基于该模型进行软件的维护和改进。
请围绕“论软件系统建模方法及其应用”论题，依次从以下三个方面进行论述。
1.概要叙述你参与的软件系统开发项目以及你所担任的主要工作。
2.说明软件系统开发中常用的建模方法有哪几类？阐述每种方法的特点及其适用范围。
3. 详细说明你所参与的软件系统开发项目中，采用了哪些软件系统建模方法，具体 实施效果如何。
答案与解析
- 试题难度：较难
- 知识点：论文写作>系统建模
- 试题答案：
- 试题解析：
一、应结合自己参与的信息系统项目，说明在其中所承担的工作。
二、需要较为详细地说明目前各种常见的信息系统建模方法的核心思想，并对每种方法所创建的模型进行简要描述。
（1）结构化建模方法。
结构化建模方法是以过程为中心的技术，可用于分析一个现有的系统以及定义新系统的业务需求。结构化建模方法所绘制的模型称为数据流图（DFD）。对于流程较为稳定的系统可考虑结构化建模方法。
（2）信息工程建模方法（或数据库建模方法）。
信息工程建模方法是一种以数据为中心，但过程敏感的技术，它强调在分析和研究过程需求之前，首先研究和分析数据需求。信息工程建模方法所创建的模型被称为实体联系图（ERD）。主要用于数据建模。
（3）面向对象建模方法。
面向对象建模方法将“数据”和“过程”集成到被称为“对象”的结构中，消除了数据和过程的人为分离现象。面向对象建模方法所创建的模型被称为对象模型。随着面向对象技术的不断发展和应用，形成了面向对象的建模标准，即UML（统一建模语言）。UML定义了几种不同类型的模型图，这些模型图以对象的形式共建一个信息系统或应用系统。目前比较常用的建模方法。
三、论文中需要结合项目实际工作，详细论述在项目中是如何使用所选定的信息系统建模方法创建系统的逻辑模型和物理模型，并详细说明实施效果。
第 2 题
论软件架构风格
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。体系结构风格反应了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
请围绕“论软件架构风格”论题，依次从以下三个方面进行论述。
1.概要叙述你参与分析和设计的软件系统开发项目以及你所担任的主要工作。
2.软件系统开发中常用的软件架构风格有哪些？详细阐述每种风格的具体含义。
3.详细说明你所参与分析和设计的软件系统是采用什么软件架构风格的，并分析采 用该架构风格设计的原因。
答案与解析
- 试题难度：一般
- 知识点：论文写作>软件架构设计
- 试题答案：
- 试题解析：
一、结合自己所参与的软件项目，概要介绍该项目的背景及主要内容，并明确指出在其中所承担的主要任务和开展的主要工作。
二、常见的架构风格5大类，至少选2-3个类进行说明。（注意本部分内容虽然题目要求是详细论述，但实际上不是文章的重心，问题3才是结合项目的详细论述部分）
Garlan和Shaw将软件架构风格分为五大类，数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。其中：
（1）数据流风格包括批处理序列架构风格和管道/过滤器架构风格；
（2）调用/返回风格包括主程序/子程序架构风格、数据抽象和面向对象架构风格和层次结构架构风格；
（3）独立构件风格包括进程通信架构风格和事件驱动的架构风格；
（4）虚拟机风格包括解释器架构风格和基于规则的系统；
（5）仓库风格包括数据库架构风格和黑板架构风格。
其他的还有特定领域软件架构、状态转移等以及分布式处理等。其中分布式架构风格中有客户机/服务器风格、浏览器/服务器风格、CORBA、DCOM、EJB。
每一种具体的软件结构风格的模型如下：
1．数据流风格包括批处理序列和管道/过滤器架构风格。
（1）批处理序列架构风格。组件为一系列固定顺序的计算单元，组件间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在前一步结束后才能开始，数据必须是完整的，以整体的方式传递。
（2）管道/过滤器架构风格。每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流，经过处理，产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，包括通过计算和增加信息丰富数据，通过浓缩和删除精炼数据，通过改变记录方式转化数据，递增地转化数据等。在输入被完全消费之前，输出便产生了。这里构件被称为过滤器，连接件就是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。
2．调用/返回风格包括主程序/子程序架构风格、数据抽象和面向对象架构风格以及层次结构架构风格。
（1）主程序/子程序架构风格。单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。调用关系具有层次性，其语义逻辑表现为子程序的正确性取决于它调用的子程序的正确性。
（2）数据抽象和面向对象架构风格。这种风格的构件是对象。对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来。对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式，对象是通过函数和过程的调用来交互的。对象具有封装性，一个对象的改变不会影响其他对象。对象拥有状态和操作，也有责任维护状态。这种结构风格中包含有封装、交互、多态、集成、重用等特征。
（3）层次结构架构风格。层次系统组织成一个层次结构。构件在一些层实现了虚拟机。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。这个风格的特点是每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。大的问题分解为若干个渐进的小问题，逐步解决，隐藏了很多复杂度。修改一层，最多影响两层，而通常只能影响上层。上层必须知道下层的身份，不能调整层次之间的顺序。
3．独立构件风格包括进程通信架构风格和事件驱动的架构风格
（1）进程通信架构风格。构件是独立的过程，连接件是消息传递。这种风格的特点是构件通常是命名过程，消息传递的方式可以是点对点、异步和同步方式、以及远过程调用等
（2）事件驱动的架构风格。构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程的调用。这种风格中的构件是非命名的过程，它们之间交互的连接件往往是以过程之间的隐式调用（Implicit Invocation）来实现的。基于事件的隐式调用风格的主要优点是为软件重用提供了强大的支持，为构件的维护和演化带来了方便，其缺点是构件放弃了对系统计算的控制。
4．虚拟机风格包括解释器架构风格和基于规则的系统
（1）解释器架构风格。一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。其缺点是执行效率较低。
（2）基于规则的系统。基于规则的系统包括规则集、规则解释器、规则/数据选择器以及工作内存。
5．仓库风格包括数据库架构风格和黑板架构风格
（1）数据库架构风格。数据库架构是库风格最常见的形式。构件主要有两大类，一个是中央共享数据源，保存当前系统的数据状态，另一个是多个独立处理元素，处理元素对数据元素进行操作。
（2）黑板架构风格。黑板架构包括知识源、黑板、控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识，知识源响应黑板上的变化，也只修改黑板。黑板是一个全局数据库，包含解域的全部状态，是知识源互相作用的唯一媒介。知识源响应是通过黑板状态的变化来控制。黑板通常应用在对于解决问题没有确定性算法的系统中，例如信号处理、问题规划、编译器优化等软件系统的设计中。
三、问题中明确要求回答选择架构的原因，其实是要求考生在组织论文时，说明作者选择架构的依据是什么，而各种架构应用在作者担任的项目中，有何优势与劣势。当这些内容分析清楚之后，合适的架构自然浮出水面来了。然后附带性的讲一讲架构的内容，架构具体内容与设计都已不是重心。最后谈一谈整体效果收尾。
第 3 题
论无服务器架构及其应用
近年来，随着信息技术的迅猛发展和应用需求的快速更迭，传统的多层企业应用系统架构面临越来越多的挑战，已经难以适应这种变化。在这一背景下，无服务器架构（Serverless Architecture） 逐渐流行，它强调业务逻辑由事件触发，具有短暂的生命周期，运行于无状态的轻量级容器中，并且由第三方代为管理。采用无服务器架构，业务逻辑以功能即服务 （Function As a Service, FAAS） 的方式形成多个相互独立的功能组件，以标准接口的形式向外提供服务；同时，不同功能组件间的逻辑组织代码将存储在通用的基础设施管理平台中，业务代码仅在调用时才激活运行，当响应结束后占用的资源便会释放。
请围绕“无服务器架构及其应用”论题，依次从以下三个方面进行论述。
1.概要叙述你参与分析和设计的软件系统开发项目以及你所担任的主要工作。
2.与传统的企业应用系统相比较，基于无服务器架构的应用系统具有哪些特点，请列举至少3个特点，并进行解释。
3. 结合你具体参与分析和设计的软件开发项目，描述该软件的架构，说明该架构是如何采用无服务器架构模式的，并说明在采用无服务器架构后软件开发过程中遇到的实际问题和解决方案。
答案与解析
- 试题难度：较难
- 知识点：论文写作>软件架构设计
- 试题答案：
- 试题解析：
一、结合自己所参与的软件项目，概要介绍该项目的背景及主要内容，并明确指出在其中所承担的主要任务和开展的主要工作。
二、问题2要求回答一些知识类型的问题，需要的知识内容如下：
首先值得说明的是无服务器架构并不是不再需要服务器，只是开发人员不再需要担心基础设施，因为一切都由云提供商负责。使用这种方法，开发人员只需部署适当的代码，其他一切由云提供商自动管理。
在传统的Web应用程序架构中，你必须管理基础架构，并确保其满足可扩展性和安全性需求。例如，客户端在一边，服务器在另一边。客户端发送一个“请求”，服务器回复“响应”。但是，如果无法满足应用程序需求，则很快就要扩展服务器端了。
无服务器模型提供了完全不同的方法。与传统架构不同，无服务架构在无状态计算容器中运行，这些容器是事件触发的，短暂的（只能持续一次调用），并由第三方完全管理。就像一个“黑盒子”，这个服务你只需上传代码并实时自动处理。当一个请求进来时，就会运行你的Lambda功能的容器。
在成本方面，使用无服务器模型，通常仅支付服务请求和运行代码所需的计算时间。计费以100毫秒为单位进行计量，使其具有成本效益，并且易于自动从每天几个请求到每秒数千次都可以。
无服务器架构的优点包括：
（1）降低运营成本：无服务架构本质上是一个外包解决方案。基础设施不会消失。然而，与常规云服务相比，事实上，只需要根据流量规模和形式支付需要的计算量，这可能会大大节省运营成本，特别是对于具有不同变化的早期和动态应用负载要求。
（2）可扩展性强：可扩展性强在云服务领域并不新鲜，但无服务架构将其提升到一个全新的水平。无服务架构的缩放功能不仅可以降低计算成本，还可以减少运行管理，因为缩放是自动的。使用无服务器，无需明确添加和删除实例到服务器阵列，并让供应商为你扩展应用程序。由于云计算提供商根据每个请求执行扩展，所以甚至不需要考虑在内存不足之前可以处理多少并发请求的问题。
（3）分离问题：无服务器几乎迫使你实施关注模型的分离，通过该分离将应用程序分成不同的部分，以使每个部分都解决一个单独的问题。
（4）隔离进程：在无服务器环境中，每个Lambda函数都完全隔离。如果其中一个功能关闭，它不影响其他功能，它不会导致服务器崩溃。
无服务器架构的缺点包括：
（1）缺乏控制权：通过任何外包策略，你都可以将某些系统的控制权给第三方供应商。由于系统停机，意外的限制，成本的变化，功能的丧失，强制的API升级等，这种缺乏控制可能会显现出来。此外，如果需要专门的服务器进行专门的流程，那么必须自己运行这个专门的服务器。一个无服务器架构，在大多数情况下，提供商业化的基础设施，将以广义的方式运行你的流程。
（2）长时间运行流程的高成本：如果你的进程持续运行很长时间，则可能会需要运行自己的服务器。因为这不仅涉及到成本，还涉及到拥有的技能或者想要投入运行自己的服务器的专注；在评估这些解决方案时，请考虑所有这些方面。
（3）供应商锁定将基础架构管理完全外包给无服务器提供商，无疑将自己锁定到该供应商。每个供应商都有自己的标准和编程框架，不容易改变。在几乎每一种情况下，无论从供应商使用的无服务器功能，将由另一个供应商进行不同的实现。如果要切换供应商，几乎肯定需要更新操作工具（部署，监控等），可能还需要更改代码。
三、结合项目经验详细论述无服务器架构的应用，并分析效果如何，哪些方面做得好，哪些方面做得不好。
第 4 题
论软件质量保证及其应用
软件质量保证（Software Quality Assurance, SQA）是指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，这些活动贯穿于软件生产的整个生命周期。质量保证人员负责质量保证的计划、监督、记录、分析及报告工作，辅助软件开发人员得到高质量的最终产品。
请围绕“软件质量保证及其应用”论题，依次从以下三个方面进行论述。
概要叙述你参与管理和开发的软件项目以及你在其中所担任的主要工作。
详细论述软件质量保证中常见的活动有哪些？阐述每个活动的主要内容。
结合你具体参与管理和开发的实际项目，说明是如何实施软件质量保证的各项活动，说明其实施过程及应用效果。
答案与解析
- 试题难度：较难
- 知识点：论文写作>项目管理
- 试题答案：
- 试题解析：一、应结合自己参与的信息系统项目，说明在其中所承担的工作。
二、问题2涉及到一些知识性内容，需要的素材如下：
质量保证是指定期评估项目总体绩效，建立项目能达到相关质量标准的信心。质量保证对项目的最终结果负责，而且还要对整个项目过程承担质量责任；质量控制是指监测项目的总体结果，判断它们是否符合相关质量标准，并找出如何消除不合格绩效的方法。
软件质量保证（Software Quality Assurance, SQA）是指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，这些活动贯穿于软件生产的各个阶段即整个生命周期。SQA由各项任务构成，这些任务的参与者有两种人，分别是软件开发人员和质量保证人员。前者负责技术工作，后者负责质量保证的计划、监督、记录、分析及报告工作。软件开发人员通过采用可靠的技术、方法和措施，进行正式的技术评审，执行软件测试来保证软件产品的质量。质量保证人员则辅助软件开发人员得到高质量的最终产品。
美国卡耐基•梅隆大学软件工程研究所推荐了一组有关质量保证的计划、监督、记录、分析及报告的SQA活动，这些活动由一个独立的SQA小组执行。
（1）制订SQA计划。SQA计划在制订项目计划时制订，由相关部门审定。它规定了软件开发小组和质量保证小组需要执行的质量保证活动。有关该计划的详细内容，请阅读《系统分析师教程》20.7.2节。
（2）参与开发该软件项目的软件过程描述。软件开发小组为将要开展的工作选择软件过程，SQA小组则要评审过程说明，以保证该过程与企业政策、内部的软件标准、外界所制订的标准以及项目开发计划的其他部分相符。
（3）评审。评审各项软件工程活动，核实其是否符合已定义的软件过程。SQA小组识别、记录和跟踪所有偏离过程的偏差，核实其是否已经改正。
（4）审计。审计指定的软件工作产品，核实其是否符合已定义的软件过程中的相应部分。SQA小组对选出的产品进行评审，识别、记录和跟踪出现的偏差，核实其是否已经改正，定期向项目负责人报告工作结果。
（5）记录并处理偏差。确保软件工作及工作产品中的偏差已被记录在案，并根据预定规程进行处理。偏差可能出现在项目计划、过程描述、采用的标准或技术工作产品中。
（6）报告。记录所有不符合部分，并向上级管理部门报告。跟踪不符合的部分直到问题得到解决。
除了进行上述活动外，SQA小组还需要协调变更的控制与管理，并帮助收集和分析软件度量的信息。
三、结合具体参与的项目，从上面写到的几个方面来展开论述说明自己是如何进行质量保证工作的。最后总结效果，并指出不足，给出改进意见。