【软考系统架构设计师】2016年下系统架构师论文写作历年真题

【软考系统架构设计师】2016年下系统架构师论文写作历年真题

2016年下系统架构师试题一（系统架构评估）

论软件系统架构评估
对于软件系统，尤其是大规模的复杂软件系统来说，软件的系统架构对于确保最终系统的质量具有十分重要的意义，不恰当的系统架构将给项目开发带来高昂的代价和难以避免的灾难。对一个系统架构进行评估是为了：分析现有架构存在的潜在风险，检验设计中提出的质量需求，在系统被构建之前分析现有系统架构对于系统质量的影响，提出系统架构的改进方案。架构评估是软件开发过程中的重要环节。
请围绕“论软件系统架构评估”论题，依次从以下3个方面进行论述。
1.概要叙述你所参与架构评估的软件系统，以及在评估过程中所担任的主要工作。
2.分析软件系统架构评估中所普遍关注的质量属性有哪些？详细阐述每种质量属性的具体含义。
3.详细说明你所参与的软件系统架构评估中，采用了哪种评估方法，具体实施过程和效果如何。

• 架构所关注的质量属性主要包括：性能、可用性、可修改性、安全性。

1. 性能
   性能是指系统的响应能力，即需要多长时间，才能对某个事件作出响应，或者在某段事件内系统所能处理的事件个数。通常用单位时间内所处理事务的数量或系统完成某个事物处理所需的时间来对性能进行定量表示。
2. 可靠性
   是软件系统在应用或者系统错误面前，在意外或者错误使用的情况下维持软件系统的功能特征的基本能力。
3. 可用性
   可用性是系统能够正常运行的时间比例。
   经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
4. 安全性
   安全性是指系统向合法用户提供服务的同时，能够阻止非授权用户使用的企图或拒绝服务的能力。
5. 可修改性
   是指能够快速地以较高的性能价格比对系统进行变更的能力，包括可维护性，可扩展性，结构重构，可移植性。
6. 功能性
   是系统所能完成所期望的工作的能力。一项任务的完成需要系统中，许多或大多数构件的相互协作。
7. 可变性
   是指体系结构经扩充或变更而成为新体系结构的能力。
8. 互操作性
   互操作性是指作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。如程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题

• 现软件评估中的主要评估方法包括SAAM（Scenarios-based Architecture Analysis Method）和ATAM（Architecture Tradeoff Analysis Method，体系结构权衡分析方法）。

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方法、描述商业动机、描述体系结构、确定体系结构方法、生成质量属性效用树、分析体系结构方法、讨论和分级场景、描述评估结果

2016年下系统架构师试题二（设计模式）

论软件设计模式及其应用
软件设计模式（Software Design Pattern）是一套被反复使用的、多数人知晓的、经过分类编目的代码设计经验的总结。使用设计模式是为了重用代码以提高编码效率、增加代码的可理解性、保证代码的可靠性。软件设计模式是软件开发中的最佳实践之一，它经常被软件开发人员在面向对象软件开发过程中所采用。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在实际应用中都有相应的原型与之相对，每种模式都描述了一个在软件开发中不断重复发生的问题，以及对应该原型问题的核心解决方案。
请围绕“论软件设计模式及其应用”论题，依次从以下三个方面进行论述。
1．概要叙述你参与分析和开发的软件系统，以及你在项目中所担任的主要工作。
2．说明常用的软件设计模式有哪几类？阐述每种类型特点及其所包含的设计模式。
3．详细说明你所参与的软件系统开发项目中，采用了哪些软件设计模式，具体实施效果如何

1. 创建型模式
   关键字：抽象实例化的过程；
   该类模式是对对象实例化过程的抽象，它通过采用抽象类所定义的接口，封装了系统中对象如何创建，组合等信息。
   所包括的模式：
   Abstract Factory（抽象工厂）
   Factory Method（工厂方法）
   Builder（建造者）
   Prototype（原型）
   Singleton（单例）

2. 结构型模式
   关键字：组合类和对象获得更大结构。
   该类模式主要用于如何组合已有的类和对象以获得更大的结构，一般借鉴封装，代理，继承等概念将一个或多个类或对象进行组合，封装，以提供统一的外部视图或新的功能。
   所包括的模式：
   Adapter（适配器）
   Bridge（桥接）
   Composite（组合）
   Decorator（装饰）
   Faqade（外观）
   Flyweight（享元）
   Proxy（代理）

3. 行为型模式
   关键字：对象之间职责的分配
   该类模式主要用于对象之间的职责及提供的服务的分配，它不仅描述对象或类的模式，还描述它们之间的通信模式，特别是描述一组对等的对象怎样相互协作以完成其中任一对象都无法单独完成的任务
   所包括的模式：
   Chain of Responsibility（职责链）、Command（命令）
   Interpreter（解释器）
   Iterator（迭代器）
   Mediator（中介者）
   Memento（备忘录）
   Observer（观察者）
   State（状态）
   Strategy（策略）
   TemplateMethod（模板方法）
   Visitor（访问者）

2016年下系统架构师试题三（数据访问层设计）

论数据访问层设计技术及其应用
在信息系统的开发与建设中，分层设计是一种常见的架构设计方法，区分层次的目的是为了实现“高内聚低耦合”的思想。分层设计能有效简化系统复杂性，使设计结构清晰，便于提高复用能力和产品维护能力。一种常见的层次划分模型是将信息系统分为表现层、业务逻辑层和数据访问层。信息系统一般以数据为中心，数据访问层的设计是系统设计中的重要内容。数据访问层需要针对需求，提供对数据源读写的访问接口；在保障性能的前提下，数据访问层应具有良好的封装性、可移植性，以及数据库无关性。
请围绕“论数据访问层设计技术及其应用”论题，依次从以下三个方面进行论述。
1．概要叙述你参与管理和开发的与数据访问层设计有关的软件项目，以及你在其中所担任的主要工作。
2．详细论述常见的数据访问层设计技术及其所包含的主要内容。

1. 在线访问
   该模式是基本的数据访问模式，在软件系统中不存在专门的数据访问层，由业务程序直接读取数据，与后台数据源进行交互。
2. Data Access Object
   DAO模式是标准J2EE设计模式之一，该模式将底层数据访问操作与高层业务逻辑分离开。具体的DAO类包含访问特定数据源数据的逻辑。
3. Data Transfer Object
   DTO是经典EJB设计模式之一。DTO本身是一组对象或是数据的容器，它需要跨越不同进程或者网络的边界来传输数据。这类对象通常本身不包括具体的业务逻辑，对象内部仅进行一些诸如内部一致性检查和基本验证之类的方法。
4. 离线数据模型
   是以数据为中心，数据从数据源获取后，将按照某种预定义的结构（如IBM SDO的Data图表结构或ADO.NET中的关系结构）存放在系统中，成为应用的中心。其特点是：
   ①离线，数据操作独立于后台数据源；
   ②与XML集成，数据可以方便地与XML格式文档相互转换。
5. 对象/关系映射（Object/Relation Mapping）
   ORM是一种工具、中间件或平台，它能够帮助将应用程序中的数据转换成关系数据库中的记录；或者是将关系数据库中的记录转换成应用程序中代码便于操作的对象，使得程序员在开发过程中仅仅面对一个对象的概念，降低了对程序员数据库知识的要求，简化了数据库相关的开发工作。
   数据访问层的技术主要在于数据映射的问题如Hibernate或iBATIS的应用。

• Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，它将POJO与数据库表建立映射关系，是一个全自动的ORM框架，hibernate可以自动生成SQL语句，自动执行，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。 Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序使用，也可以在Servlet/JSP的Web应用中使用，最具革命意义的是，Hibernate可以在应用EJB的J2EE架构中取代CMP，完成数据持久化的重任。

• iBATIS一词来源于“internet”和“abatis”的组合，是一个由Clinton Begin在2002年发起的开放源代码项目。于2010年6月16号被谷歌托管，改名为MyBatis。是一个基于SQL映射支持Java和.NET的持久层框架

• Hibernate的调优方案：
  制定合理的缓存策略；
  尽量使用延迟加载特性；
  采用合理的Session管理机制；
  使用批量抓取，设定合理的批处理参数（batch_size）；
  进行合理的O/R映射设计。

• Mybatis调优方案：
  MyBatis在Session方面和Hibernate的Session生命周期是一致的，同样需要合理的Session管理机制。MyBatis同样具有二级缓存机制。 MyBatis可以进行详细的SQL优化设计。

2016年下系统架构师试题四（微服务架构）

论微服务架构及其应用
近年来，随着互联网行业的迅猛发展，公司或组织业务的不断扩张，需求的快速变化以及用户量的不断增加，传统的单块（Monolithic）软件架构面临着越来越多的挑战，已逐渐无法适应互联网时代对软件的要求。在这一背景下，微服务架构模式（Microservice Architecture Pattern）逐渐流行，它强调将单一业务功能开发成微服务的形式，每个微服务运行在一个进程中；采用HTTP等通用协议和轻量级API实现微服务之间的协作与通信。这些微服务可以使用不同的开发语言以及不同数据存储技术，能够通过自动化部署工具独立发布，并保持最低限制的集中式管理。
请围绕“论微服务架构及其应用”论题，依次从以下三个方面进行论述。
1.概要叙述你参与管理和开发的、采用微服务架构的软件开发项目及在其中所担任的主要工作。
2.与单块架构相比较，微服务架构有哪些特点？请列举至少4个特点并进行说明。
3.结合你参与管理和开发的软件开发项目，描述该软件的架构，说明该架构是如何采用微服务架构模式的，并说明在采用微服务架构后，在软件开发过程中遇到的实际问题和解决方案

• 微服务架构具有如下的特点

1. 通过服务实现组件化
   单个微服务实现简单，能够聚焦一个指定的业务功能或业务需求。
2. 功能明确，易于理解
   微服务能够被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果，并降低沟通成本。
3. 围绕业务功能构建开发团队
   采用微服务架构，可以围绕业务功能构建开发团队，这样更符合企业的分工与组织结构，便于管理。
4. 支持多种开发语言与多种平台
   不同的微服务能使用不同的语言开发，运行在不同的操作系统平台上，通过标准的协议和数据格式进行交互与协作。
5. 离散化数据管理
   在微服务架构中，无法创建或维护统一的数据模型或结构，全局数据模型将在不同的系统之间有所区别，需要进行数据模型的离散化管理。
6. 基础设施自动化
   微服务强调以灵活的方式集成自动部署，通过持续集成工具实现基础设施自动化。

• 微服务的特点追加说明

1. 微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。
2. 微服务是利用组织的服务投资组合，然后基于业务领域功能分解它们，在看到服务投资组合之前，它还是一个业务领域。
3. 微服务这一概念出现于2012年，是因软件作者Martin Fowler而流行，它承认这并没有精确地定义出这一架构形式，虽然围绕业务能力、自动化部署、终端智能以及语言和数据的分散控制有一些常见的特性。
4. 开源工作流平台“Imixs-Workflow”发布了一款新的微服务架构，作为工作流来管理解决方案。Imixs的微服务（ Imixs-Microservice）提供了一个工作流封装成微服务架构。这一服务可以独立于其背后的技术，绑定到任何业务应用中去。这允许业务应用改变业务逻辑时，不用更改任何代码。这业务目标可以通过工作流模型控制。
5. Imixs的微服务是基于Imixs的工作流引擎（ Imixs-Workflow Engine）的复杂功能构建的，它可以以多种不同的方法来控制业务数据。Imixs的微服务可以发送电子邮件推送消息、日志业务交换，还可以确保所有类型业务数据的安全。
6. Imixs的工作流模型可以给业务处理模型（Imixs-Workflow Modeller）中的每种状态单独的设计一个ACL。这许可了高度复杂的业务应用程序，并在每个流程实例周围驻起了安全层。