《系统架构设计师》论文真题汇编

试卷预览

1 问答题 1分

论软件系统架构评估及其应用

对于软件系统，尤其是大规模复杂软件系统而言，软件系统架构对于确保最终系统的质量具有十分重要的意义。在系统架构设计结束后，为保证架构设计的合理性、完整性和针对性，保证系统质量，降低成本及投资风险，需要对设计好的系统架构进行评估。架构评估是软件开发过程中的重要环节。

请围绕“软件系统架构评估及其应用”论题，依次从以下三个方面进行论述。

1.概要叙述你所参与管理或开发的软件项目，以及你在其中所承担的主要工作。

2.详细阐述有哪些不同的软件系统架构评估方法，并从评估目标、质量属性和评估活动等方面论述其区别。

3.详细说明你所参与的软件开发项目中，使用了哪种评估方法，具体实施过程和效果如何 。

查看答案 开始考试

正确答案：

本题解析：

一、应结合自己参与的信息系统项目，说明在其中所承担的工作。

二、详细阐述有哪些不同的软件系统架构评估方法，并从评估目标、质量属性和评估活动等方面论述其区别 。

常见的系统体系架构分析方法有 SAAM 和 ATAM 。

SAAM （Scenarios-based Architecture Analysis Method） 是一种非功能质量属性的体系架构分析方法，最初用于比较不同的体系架构，分析架构的可修改性，后来也用于其他的质量属性，如可移植性、可扩充性等 。

（1）特定目标：对描述应用程序属性的文档，验证基本体系结构假设和原则 。SAAM不仅能够评估体系结构对于特定系统需求的适用能力，也能被用来比较不同的体系结构 。

（2）评估活动： SAAM 的过程包括五个步骤，即场景开发、体系结构描述、单个场景评估、场景交互和总体评估 。

ATAM （ Architecture Tradeoff Analysis Method） 是在 SAAM 的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中 。

（1）特定目标：在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件体系结构的能力的方法，使用该方法确定在多个质量属性之间折中的必要性 。

（2） 评估活动：分为四个主要的活动领域，分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。

三、第三个问题要根据项目的实际情况来写自己是怎么做的，遇到什么样的问题，如何解决的。同时文章收尾要对效果进行评价。

2 问答题 1分

围绕“论软件测试中缺陷管理及其应用”论题，依次从以下三个方面进行论述。

1.概要叙述你参与管理和开发的软件项目以及承担的工作

2.详细论述常见的缺陷种类及级别，论述缺陷管理和基本流程

3.结合你具体参与管理和开发的实际项目，说明是如何进行缺陷管理的。请具体说明实施过程及应用效果。

查看答案 开始考试

正确答案：

本题解析：

一、应结合自己参与的信息系统项目，说明在其中所承担的工作。

二、软件缺陷定义：

（1）软件未达到需求规格说明书的功能；

（2）软件出现了需求规格说明书指明不会出现的错误；

（3）软件功能超出需求规格说明书的范围；

（4）软件未达到需求规格说明书未指出但应达到的目标；

（5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。

缺陷类型：

（1）设计缺陷：由于软件设计或代码实现所产生的功能或流程的问题。

（2）界面问题：系统页面的展示的问题。

（3）数据问题：系统数据的来源，处理及处理结果的问题。

（4）需求问题：软件需求测试发现的问题，也包括之后需求变更的问题。

（5）安装部署：软件安装部署过程的错误。

（6）性能问题：软件性能相关的缺陷。

（7）文档问题：用户使用手册，软件帮助文档等出现的问题

（8）常识问题：系统用户的正常使用习惯相关问题。

（9）安全问题：系统漏洞安全问题。

（10）优化建议：针对操作过程逻辑或界面显示的优化性建议。

（11）其他：除前面分类的其他问题

严重程度定义

注：严重等级由创建者在创建缺陷时根据此定义来选择，之后都不能随意更改。

优先级的定义

注：立刻、紧急、尽快的问题都要求在系统上线前解决。

缺陷处理过程：

正常处理过程

（1）创建问题

在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项，详细请参考5.4和5.5。

（2）指派问题

创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。

如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。

（3）确认问题

通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。

当创建者收到确认指派时，需要进行及时确认。如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。

如果问题确认指派次数大于6次时，需要进入“争议处理”流程，详细请参考5.2。

（4）解决问题

此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。

开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。

如果Bug无法解决或修改影响比较大，可申请进入“延期解决”流程，请参考5.2中延期处理部分。

（5）验证问题

创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过，则可关闭Bug；如果验证不通过，则激活此Bug，系统将自动指派回给解决者。

验证通过准则：相同的操作步骤，进行一定次数的验证测试都没有发生。

验证不通过准则：相同的操作步骤，全部或部分实际结果还会发生，验证不通过则激活Bug。

（6）关闭问题

通过验证的Bug，验证者需要注明验证结果并进行关闭操作，系统将指派给Closed。

如果关闭状态的Bug在之后版本又会发生，则激活此Bug，系统将自动指派回给解决者。

特别处理过程

（1）客户问题

客户反馈的问题可以由客户直接反馈或项目经理、市场部等了解到的客户问题，经确认后的Bug提交到测试管理系统，按照以上处理流程进行处理，由创建者或测试组进行跟踪验证关闭。

创建客户问题时，创建者需要在Bug标题开头标记为[客户问题]，测试组负责检查和更正。

（2）争议处理

当开发和测试工程师对某问题有争议并且多次沟通无果时（暂定为6次），可以注明双方的理由，并指派给项目经理进行处理。

项目经理可以召开评审会议，或者直接与双方沟通了解，并根据项目情况给出专业意见和最终决定。开发和测试工程师根据项目经理的最终决定执行。

（3）延期解决

当开发工程师对确认Bug进行解决时，发现或评估其解决时间紧或风险比较大等，可以说明原因或理由并指派给项目经理来确认。

项目经理可以召开评审会议，或者直接沟通了解，并根据项目情况给出最终决定。如果不同意，项目经理将此Bug指派回开发工程师，开发工程师继续分析和解决。如果同意，项目经理需要在Bug标题开头标记为[延期解决]和在处理状态选择“延期解决”，然后注明解决时间计划并指派回开发工程师，开发工程师根据解决时间计划来规划和解决此Bug。

三、第三个问题要根据项目的实际情况来写自己是怎么做的，遇到什么样的问题，如何解决的。同时文章收尾要对效果进行评价。

3 问答题 1分

请围绕“论云原生架构及其应用”论题，依次从以下三个方面进行论述。

1.概要叙述你参与管理和开发的软件项目以及承担的主要工作；

2.服务化，弹性，可观测性和自动化是云原生架构的四类设计原则，请简要对这四类设计原则的内涵进行阐述；

3.具体阐述你参与管理和开发的项目是如何向采用云原生架构的，并且围绕上述四类设计原则详细论述在项目设计与实现过程中遇到了哪些实际问题，是如何解决的。

大纲：近年来，随着数字化转型不断深入，科技创新与业务不断融合，各行各业正在从大工业时代以容器和微服务架构为代表的云原生技术作为云计算服务的新模式已经逐渐成为企业持续发展的主流选择。

查看答案 开始考试

正确答案：

本题解析：

一、应结合自己参与的信息系统项目，说明在其中所承担的工作。

二、从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

上图展示了在代码中通常包括三部分：业务代码、三方软件、处理非功能特性的代码。其中“业务代码”指实现业务逻辑的代码；“三方软件”是业务代码中依赖的所有三方库，包括业务库和基础库；“处理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码。三部分中只有业务代码是核心，是对业务真正带来价值的，另外两个部分都只算附属物，但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强，使得今天的软件构建变得越来越复杂，对开发人员的技能要求也越来越高。云原生架构相比较传统架构进了一大步，从业务代码中剥离了大量非功能性特性（不会是所有，比如易用性还不能剥离）到 IaaS 和 PaaS 中，从而减少业务代码开发人

员的技术关注范围，通过云厂商的专业性提升应用的非功能性能力。

云原生架构原则：

云原生架构本身作为一种架构，也有若干架构原则作为应用架构的核心架构控制面，通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。

1、 服务化原则：

当代码规模超出小团队的合作范围时，就有必要进行服务化拆分了，包括拆分为微服务架构、小服务（Mini Service）架构，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免迭代频繁模块被慢速模块拖慢，从而加快整体的进度和稳定性。同时服务化架构以面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。

分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等，本质上都是基于服务流量（而非网络流量）的控制策略，所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系，标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治理，不管这些服务是基于什么语言开发的。

2、弹性原则：

大部分系统部署上线需要根据业务量的估算，准备一定规模的机器，从提出采购申请，到供应商洽谈、机器部署上电、软件部署、性能压测，往往需要好几个月甚至一年的周期；而这期间如果业务发生变化了，重新调整也非常困难。弹性则是指系统的部署规模可以随着业务量的变化自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。好的弹性能力不仅缩短了从采购到上线的时间，让企业不用操心额外软硬件资源的成本支出（闲置成本），降低了企业的 IT 成本，更关键的是当业务规模面临海量突发性扩张的时候，不再因为平时软硬件资源储备不足而“说不”，保障了企业收益。

3、可观测原则：

今天大部分企业的软件规模都在不断增长，原来单机可以对应用做完所有调试，但在分布式环境下需要对多个主机上的信息做关联，才可能回答清楚服务为什么宕机、哪些服务违反了其定义的 SLO、目前的故障影响哪些用户、最近这次变更对哪些服务指标带来了影响等等，这些都要求系统具备更强的可观测能力。可观测性与监控、业务探活、APM 等系统提供的能力不同，前者是在云这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，让一次 APP 点击背后的多次服务调用的耗时、返回值和参数都清晰可见，甚至可以下钻到每次三方软件调用、SQL 请求、节点拓扑、网络响应等，这样的能力可以使运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得前所未有的关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。

4、自动化原则：

技术往往是把“双刃剑”，容器、微服务、DevOps、大量第三方组件的使用，在降低分布式复杂性和提升迭代速度的同时，因为整体增大了软件技术栈的复杂度和组件规模，所以不可避免地带来了软件交付的复杂性，如果这里控制不当，应用就无法体会到云原生技术的优势。通过 IaC（Infrastructure asCode）、GitOps、OAM（Open Application Model）、Kubernetes operator 和大量自动化交付工具在 CI/CD 流水线中的实践，一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。

三、第三个问题要根据项目的实际情况来写自己是怎么做的，遇到什么样的问题，如何解决的。?

4 问答题 1分

论数据分片技术及其应用

数据分片就是按照一定的规则，将数据集划分成相互独立正交的数据子集。然后将数据子集分布到不同的节点上，通过设计合理的数据分片规则，可将系统中的数据分布在不同的物理数据库中，达到提升应用系统数据处理速度的目的。

请围绕“论数据分片技术及其应用”论题，依次从以下三个方面进行论述。

1.概要叙述你参与管理和开发软件的项目以及承担的工作

2. Hash分片，一致性Hash分片和按照数据范围分片是三种常用的数据分片方式

3.具体阐述你参与管理和开发的项目，且采用了哪些分片方式，并且具体说明其实现过程和应用效果。

查看答案 开始考试

正确答案：

本题解析：

一、应结合自己参与的信息系统项目，说明在其中所承担的工作。

二、Redis数据分片方案

1、范围分片：按数据范围值来做分片。如：按用户编号分片，0-999999映射到实例A；1000000-1999999映射到实例B。

2、hash分片：通过对key进行hash操作，可以把数据分配到不同实例，这类似于取余操作，余数相同的，放在一个实例上。

3、一致性hash分片：hash分片的改进，可以有效解决重新分配节点带来的无法命中问题。

Redis的持久化解决方案

Redis的持久化主要有两种方式：RDB和AOF。

RDB：传统数据库中快照的思想。指定时间间隔将数据进行快照存储。

AOF：传统数据库中日志的思想，把每条改变数据集的命令追加到AOF文件末尾，这样出问题了，可以重新执行AOF文件中的命令来重建数据集。

三、第三个问题要根据项目的实际情况来写自己是怎么做的，遇到什么样的问题，如何解决的。同时文章收尾要对效果进行评价。

5 问答题 1分

论企业集成平台的架构设计

企业集成平台是一个支持复杂信息环境下信息系统开发、集成和协同运行的软件支撑环境，它基于企业各种经营业务的信息特征，在异构分布环境（操作系统、网络、数据库）下为应用提供一致的信息访问和交互手段，对其上运行的应用进行管理，为应用提供服务，并支持各种特定领域应用系统的集成。

请围绕“企业集成平台的架构设计”论题，依次从以下三个方面进行论述。

1、简要叙述你参与管理和开发的企业集成平台项目以及你在其中所承担的主要工作。

2、请说明企业集成平台的基本功能，并结合项目实际，详细说明所设计的企业集成平台的架构，以及实现时用到了哪些关键技术。

3、具体说明所设计的企业集成平台的使用情况，最终实施效果如何。

查看答案 开始考试

正确答案：

本题解析：

写作要点

一、企业集成平台的基本功能

（1）通信服务。提供分布环境下透明的同步/异步通信服务功能，使用户和应用程序无需关心具体的操作系统和应用程序所处的网络物理位置，而以透明的函数调用或对象服务方式完成它们所需的通信服务要求。

（2）信息集成服务。为应用提供透明的信息访问服务，通过实现异种数据库系统之间的数据交换、互操作、分布数据管理和共享信息模型定义，使集成平台上运行的应用、服务或客户端能够以一致的语义和接口实现对数据的访问与控制。

（3）应用集成服务。通过高层应用编程接口来实现对相应应用程序的访问。这些接口以函数或对象服务的方式向平台的组件模型提供信息，用户无需对原有系统进行修改，只要在原有系统的基础上加上相应的访问接口就可以将现有的、用不同技术实现的系统互联起来，通过为应用提供数据交换和访问操作，使各种不同的系统能够相互协作。

（4）提供对二次开发的支持。集成平台需要提供一组帮助用户开发特定应用程序的支持工具，简化用户在企业集成平台实施过程中的开发工作。

（5）平台运行管理。需要提供企业集成平台的运行管理和控制模块，负责企业集成平台系统的静态和动态配置、集成平台应用运行管理和维护、事件管理和出错管理等。通过命名服务、目录服务、平台的动态静态配置，以及其中的关键数据的定期备份等功能来维护整个服务平台的系统配置及稳定运行。

二、结合项目实际说明你所设计的企业集成平台的架构。对架构的说明应包括从架构层面上如何支持业务流程编写与管理；如何向用户提供功能与信息服务；如何集成业务伙伴的功能；如何与底层数据库、现有系统等进行交互，等等。在实现企业集成平台时所使用的关键技术包括：

（1）数据交换格式。企业集成中常用的数据交换格式有：EDI、XML、STEP、PDML

（2）分布式集成应用基础框架。主要的有CORBA、J2EE、Web Service

（3）实现数据集成的常用模式。数据联邦、数据复制和基于接口的数据集成

（4）实现应用集成的常用模式。适配器集成、信使集成、面板集成、代理集成模式

三、需要具体说明你所设计的企业应用集成平台的使用情况，包括如何采用集成平台为企业应用提供一致的信息访问和交互手段，如何对在平台上运行的应用进行管理，如何为应用提供服务等。针对每种使用场景，需要详细说明最终的实施效果。

6 问答题 1分

论模型驱动架构在系统开发中的应用

模型驱动架构（Model Driven Architecture，MDA）是对象管理组织提出的软件体系架构方法学，它基于UML以及一系列工业标准，能够支持基于可视化模型驱动的软件设计、内容存储与交换。MDA核心思想是抽象出与实现技术无关、完整描述业务功能的核心平台无关模型（PIM），然后针对不同实现技术制定多个映射规则，通过映射规则和辅助工具将PIM转换成与具体实现技术有关的平台相关模型（PSM），最后完成PSM到代码的转换。通过PIM和PSM，MDA分离业务建模与底层实现技术，降低技术变迁对业务模型带来的影响。

请围绕“模型驱动架构在系统开发中的应用”论题，依次从以下三个方面进行论述。

（1）简要叙述你参与管理和开发的、与MDA相关的软件开发项目以及你所担任的主要工作。

（2）简要分析模型驱动架构能够为软件开发带来哪些好处，详细论述采用模型驱动架构进行开发的过程。

（3）具体阐述你参与管理和开发的项目中使用模型驱动架构的情况与实际开发效果。

查看答案 开始考试

正确答案：

本题解析：

一、模型驱动架构能够为软件开发带来的好处

（1）模型驱动架构将开发人员的注意力转移到了平台无关模型中，可以避免陷入到具体的实现细节当中去，从而简化了系统开发的工作量，提高了软件的开发效率；

（2）对于多种流行平台，很多工具会支持从平台无关模型到平台相关模型的转换；对于将来可能出现的新技术和平台，确定了平台表示及公共中间件的概念和功能，利用转换规则快速实现平台无关模型到新技术平台的迁移，提高了系统的可移植性；

（3）利用模型驱动架构中基于平台无关模型的桥接器，实现了多个平台相关模型之间跨平台的相互通信，加强了互操作性；

（4）对于系统变更，通过修改平台无关模型并重新生成平台相关模型和代码，能够降低系统维护的成本；

（5）平台无关模型帮助团队成员之间提高沟通效率并减少错误，自动生成代码能够保证代码的质量和一致性，确保了软件的质量；

（6）使用模型驱动架构时，功能和架构独立定义，针对新技术，能够利用原有的设计产生对应的实现，延长了系统的生命周期。

二、模型驱动架构的开发过程

（1）使用平台无关模型从如何以最好的方式支持商业逻辑的角度对系统进行建模，开发人员根据用户需求和其他因素对平台无关模型进行精化，以使它能够更加精确地描述系统；

（2）将平台无关模型转换到一个或多个特定技术相关的平台相关模型，对于每种特定的技术都会生成独立的平台相关模型；

（3）根据技术特性对生成的平台相关模型进行修改以满足程序设计人员的要求，这些修改可以反映到平台无关模型中去；

（4）对平台相关模型不断精化，以指导代码生成器生成质量更高的程序代码；

（5）最后将每个平台相关模型转换到代码，进行后续的完善和系统测试。

三、结合项目的实际情况，具体阐述你参与管理和开发的项目中使用模型驱动架构的情况，包括平台无关模型构建、平台相关模型的技术方案选择和实际开发效果及分析。

7 问答题 1分

论大规模分布式系统缓存设计策略

大规模分布式系统通常需要利用缓存技术减轻服务器负载、降低网络拥塞、增强系统可扩展性。缓存技术的基本思想是将客户最近经常访问的内容在缓存服务器中存放一个副本，当该内容下次被访问时，不必建立新的数据请求，而是直接由缓存提供。良好的缓存设计，是一个大规模分布式系统能够正常、高效运行的必要前提。在进行大规模分布式系统开发时，必须从一开始就针对应用需求和场景对系统的缓存机制进行全面考虑，设计一个可伸缩的系统缓存架构。

请围绕“大规模分布式系统缓存设计策略”论题，依次从以下三个方面进行论述。

1. 概要叙述你参与实施的大规模分布式系统开发项目以及你所担任的主要工作。

2. 从不同的用途和应用场景考虑，请详细阐述至少两种常见的缓存工作模式，并说明每种工作模式的适应场景。

3. 阐述你在设计大规模分布式系统的缓存机制时遇到了哪些问题，如何解决。

查看答案 开始考试

正确答案：

本题解析：

一、论文中要具体介绍项目的总体需求（特别是应用需求中对缓存机制的要求）、系统的逻辑与物理架构、采用的技术等内容和担任的实际工作。

二、从不同的用途和应用场景来考虑，大体上可以将缓存分为三种工作模式，即单实例缓存模式（Single Instance）、复制模式（Replication Cache）和分区模式（Partition Cache）。每种工作模式都有其适应的场景和优缺点。

1. 单实例模式。单实例模式是一种较为简单的缓存模式，多个应用服务器共享一个中央的缓存服务器。通过共享缓存的数据，能够极大提高系统的性能。该模式的主要限制在于缓存服务器的内存大小和节点增加之后服务器的处理能力和网络带宽。该模式的适应场景是：对缓存的要求比较简单；系统的吞吐量和数据量不大；性能要求不高；

2. 复制模式。复制模式将缓存的数据复制到多台机器上，对于单一缓存服务器性能出现问题的情况下，可以通过缓存复制的方式将压力分解到多个缓存服务器。该模式的工作原理是：缓存客户端可以访问自己的缓存服务器，多个缓存服务器之间的数据是彼此同步的，对于性能要求更高的场景，这样的部署架构能够获得更高的吞吐能力。该模式的适应场景是：数据量不是特别大；需要极高的性能；数据改动的频率不是特别大。

3. 分区模式。当需要缓存的数据已经超过一台服务器的内存上限时，可以考虑采用分区模式对数据进行线性缩放，也就是通过增加缓存服务器来解决数据增长和压力增加的情况。在分区模式中，其架构是无分享架构（Shared Nothing Architecture, SNA），每个节点之间数据彼此独立，一个节点出现故障后不会影响到其他节点。在出现某个节点宕机或者其他故障的情况下，致使这部分的分区缓存无法使用，并不妨碍其他数据节点数据的正常工作。该模式的适应场景是：总体数据量较大，已经超出了单个缓存服务器的内存上限；系统缓存要求具有很大的可伸缩性；客户端数量庞大，单个客户端对缓存数据的数据量要求不大。

三、进行大规模分布式系统缓存机制设计时可能遇到的问题包括如何缓存服务器的工作模式选择；高可用性的设计考虑；缓存一致性与分布式算法；对象状态同步的考虑；缓存钝化/激活/过期和初始化，等等。

8 问答题 1分

论基于DSSA的软件架构设计与应用

软件架构设计的一个重要课题是如何解决软件重用问题。特定领域软件架构（Domain Specific Software Architecture， DSSA）是一种有效实现特定领域软件重用的手段。按照Tracz的说法，DSSA就是一个特定的问题领域中由领域模刑、参考需求、参考架构等组成的开发基础架构，其目标就是支持一个特定领域中多个应用的生成。

DSSA的基本活动包括领域分析、领域设计和领域实现。领域分析的主要目的是获得领域模型，领域模型描述领域中系统之间共同的需求，即领域需求；领域设计的主要目标是获得DSSA， DSSA描述领域模型中表示需求的解决方案：领域实现的主要目标是依据领域模型和DSSA开发和组织可重用信息。

请围绕“基于DSSA的软件架构设计与应用”论题，依次从以下三个方面进行论述。

1.概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。

2.就你所熟悉的领域，请给出针对该特定领域，在基于DSSA的软件设计开发中所涉及的领域模型、参考需求和参考架构以及相应的支持环境或设施。

3.具体阐述你参与管理和开发的项目中使用DSSA的情况，包括领域分析、领域设计和领域实现等活动是如何具体实施的，最终实际效果如何。

查看答案 开始考试

正确答案：

本题解析：

一、简要叙述所参与管理和开发的软件项目，需要明确指出在其中承担的主要任务和开展的主要工作。

二、应结合自己所熟悉的领域，定义领域范围，确定领域应用需要满足的用户需求；定义领域特定的元素、领域字典和领域术语；定义领域特定的设计和实现需求约束；在此基础上，定义领域模型，产生该领域的参考架构，并说明构件的语法和语义；最后，产生、搜集可重用的产品单元，为DSSA增加构件．为问题域实现新应用提供支持。这个DSSA的建立过程是并发、递归和反复进行的。

所给出的DSSA应该具备以下4个方面的特征：

（1）一个严格定义的问题域和／或解决域：

（2）具有普遍性，使其可以用于领域中某个特定应用的开发；

（3）对整个领域能有合适程度的抽象；

（4）具备该领域固定的、典型的在开发过程中的可重用元素。

三、需要结合项目实际，指出在架构设计时使用DSSA的情况，包括领域分析、领域设计和领域实现等活动是如何具体实施的，要给出实际的效果并进行分析。

9 问答题 1分

论软件的静态演化和动态演化及其应用

软件演化（Software Evolution）是指软件在其生命周期内的更新行为和过程。演化是一系列贯穿软件生命周期始终的活动，系统需求改变、功能实现增强、新功能加入、软件架构改变、软件缺陷修复、运行环境改变均要求软件系统能够快速适应变化，具有较强的演化能力。软件静态演化（Static Evolution）和动态演化（Dynamic Evolution）是目前软件演化的两种重要类型。

请围绕“软件的静态演化和动态演化及其应用”论题，依次从以下三个方面进行论述。

1. 概要叙述你参与管理和开发的软件项目以及你在其中所担任的主要工作。

2. 请分别对软件静态演化和动态演化的特点进行论述，说明两种软件演化类型各自的优缺点及其应用场合，并举例说明各自的常见演化技术手段。

3. 具体阐述你参与管理和开发的项目中所进行的软件演化活动的特点、演化的类型，以及所采取的对应演化技术手段，说明具体实施过程以及实际应用的效果。

查看答案 开始考试

正确答案：

本题解析：

一、简要叙述所参与管理和开发的软件项目，并明确指出在其中承担的主要任务和开展的主要工作。

二、软件演化可分为静态演化和动态演化两种情形。

1. 静态演化（Static Evolution）。静态演化是指软件在停机状态下的演化。其优点是不用考虑运行状态的迁移，同时也没有活动的进程需要处理。然而停止一个应用程序就意味着中断它提供的服务，造成软件暂时失效。

软件静态演化是指发生在应用程序停止时的软件修改和更新，即一般意义上的软件维护和升级。静态演化的优点是没有状态迁移或活动线程的问题要解决，缺陷是停止应用程序意味着停止它所提供的服务，也就是使软件系统暂时失效。在软件交付之后，静态演化（类似于一般意义上的软件维护）就成为软件变更的一个常规过程。变更可以是一种更正代码错误的简单变更，也可以是更正设计错误的较大范围的变更，还可以是对描述错误进行修正或提供新需求这样的重大改进。有三种不同的软件维护：改正性维护、适应性维护和完善性维护。维护过程一般包括变更分析、版本规划、系统实现和向客户交付系统等活动。

在面向对象技术中，使用子类型方法来扩展程序，它适合于软件静态演化和代码重用。子类型化一个类意味着保留父类中的参数和方法，并尽可能地增加新的参数和方法。另外，使用重载和多态性作为主要的演化机制。实际上，建立类的新版本，最简单的机制是创建它的子类，然后重载需要变更的方法，最后，使用多态性调用新创建的方法。在基于构件的软件技术中，构件采取接口和实现相分离技术，构件之间只能通过接口进行通信，这使得具有兼容接口的不同构件实现可以相互取代，从而成为软件静态演化的一条途径。

2. 动态演化（Dynamic Evolution）。动态演化是指软件在执行期间的软件演化。其优点是软件不会存在暂时的失效，有持续可用性的明显优点。但由于涉及状态迁移等问题，比静态演化从技术上更难处理。

动态演化是最复杂也是最有实际意义的演化形式。动态演化使得软件在运行过程中，可以根据应用需求和环境变化，动态地进行软件的配置、维护和更新，其表现形式包括系统元素数目的可变性、结构关系的可调节性和结构形态的动态可配置性。软件的动态演化特性对于适应未来软件发展的开放性、动态性具有重要意义。

动态演化是指软件在运行期间的演化。在许多重要的应用领域中，例如金融、电力、电信及空中交通管制等，系统的持续可用性是一个关键性的要求，运行时刻的系统演化可减少因关机和重新启动而带来的损失和风险。此外，越来越多的其他类型的应用软件也提出了运行时刻演化的要求，在不必对应用软件进行重新编译和加载的前提下，为最终用户提供系统定制和扩展的能力。

动态演化可分为两种类型：预设的和非预设的。在Web 环境中，软件应用常常需要处理多种类型的信息，因此它们常被设计为可以动态下载并安装插件以处理当前所面临的新类型的信息；而分布式Web 应用也常常需要增减内部处理节点的数目以适应多变的负载。这些动态改变都是软件设计者能够预先设想到的，可实现为系统的固有功能。另有一些必须对系统配置进行修改和调整的情况是直到系统投入运行以后才发现的，这就要求系统能够处理在原始设计中没有完全预料到的新需求。这种情况下一般需要关闭整个系统，重新开发、重新装入并重新启动系统。然而，为了进行局部的修改而关闭整个系统在某些情况下是不允许的（例如，关键运行系统）或者代价太高。精心设计的动态演化技术可以在不关闭整个系统的前提下修改系统的结构配置，并尽量使未受影响的部分继续工作以提高系统的可用度。

为支持软件的动态演化性，已在语言、机制和环境等方面做了大量工作。在程序语言的层次上，引进各种机制以支持软件动态演化，例如动态装载技术允许增加代码到已运行的程序中，延迟绑定是在运行时而不是编译时决定类和对象的绑定。Java hotswap允许在运行时改变方法：当一个方法终止时这个方法的新版本可以有效地替换旧版本，在类层次上代码的二进制兼容被支持。Gilgul语言也允许更换运行时对象。但程序语言层次上的动态演化机制仅局限于函数、类方法和对象等小粒度的替换，只支持预设的有限变更，变更由事件触发。

通过标准化运行级构件的规约，依靠构件运行平台（中间件平台）提供的基础设施，使软件在构件层次上的动态演化成为可能。中间件中具有的如命名服务、反射技术和动态适配等机制，为运行态构件的动态替换和升级提供支撑，从而推动了软件动态演化的发展。命名服务就是给构件实例提供一个名称，以便客户通过这些名称来获取构件实例。对工业标准构件EJB 和CORBA 构件的引用都可以通过中间件平台的命名服务进行。同一构件标识可以被映射到多个构件实例，从而根据具体情境对某一名字的构件引用导向到不同的构件实例。反射技术是系统的一种自描述（self-representation）和自推理的技术，它提供了关于自身行为的表示，这种表示可以被检查和调整，且与它所描述的系统行为是因果相联（causally connected）的。因果相联，意味着对自表示的改动将立即反映在系统的实际状态和行为中，反之亦然。将反射性引入中间件能够以可控的方式开放平台内部的实现，从而提高中间件的定制能力和运行时的适应能力。动态适配机制中比较著名的是CORBA 提供的动态接口服务：动态调用接口DII和动态骨架接口DSI。前者支持动态客户请求调用，而后者支持将请求动态指派（Dispatch）给构件。因此，软件构件化技术使得软件具有良好的构造性，软件演化的粒度更大。中间件技术则为基于构件的软件动态演化提供了坚实的基础设施和方便的操作界面。

三、考生需结合自身参与项目的实际状况，指出其参与管理和开发的项目中所进行的软件演化活动的特点、演化的类型，以及所采取的对应演化技术手段。要给出实施软件演化活动的具体过程、方法以及对实际应用效果的分析。

10 问答题 1分

论基于REST服务的Web应用系统设计

REST（REpresentational State Transfer）是指从几种基于网络的架构风格衍生出来的一种混合架构风格，它是目前互联网的核心架构风格。基于REST服务（RESTful Service）的Web应用系统设计任务主要包括：识别并设计REST风格的服务，采用面向服务的思想进行REST服务集成。采用这种方法设计的Web应用系统能够结合REST风格和面向服务思想的优点，近年来受到了广泛的关注。

请围绕“基于REST服务的Web应用系统设计”论题，依次从以下三个方面进行论述。

1.概要叙述你参与实施的Web应用系统开发项目以及你所承担的主要工作。

2.简要叙述与传统的Web服务相比，采用REST服务构建的Web应用具有哪些优势和不足。

3.阐述你在设计基于REST服务的Web应用系统时遇到了哪些问题，如何解决。

查看答案 开始考试

正确答案：

本题解析：

一、论文中要具体介绍项目的总体需求（特别是质量属性需求）、Web应用系统的逻辑与物理拓扑结构、采用的技术等内容和承担的实际工作。

二、REST（REpresentational State Transfer）是指从几种基于网络的架构风格衍生出来的一种混合架构风格，目前Web的体系结构正是基于REST风格的。REST风格中的特点是客户端／服务器、无状态、缓存、统一接口、分层系统和按需代码。REST组件通过以一种数据格式转移资源的表述进行通信，可以基于接收者的能力和期待的内容，以及资源的性质动态地选择不同的表述。

与传统的Web服务相比，REST服务主要有以下优势：

（1）REST服务基于W3C/IETF的标准与规范（包括HTTP、XML、URI和MIME等），其实现技术简单、成熟。

（2）REST服务基于URI和超链接技术，不需要通过集中式的服务信息仓库即可发现服务资源。

（3）REST服务支持缓存，具有无状态的特性，这些使得REST服务能够支持大量客户端，构建的应用系统具有较强的伸缩性。

（4）REST服务基于轻量级的Web框架，仅仅需要基本的开发工具支持，构建过程简单且成本较低。

（5）REST服务的测试相对简单，采用浏览器即可完成服务功能测试。

与传统的Web服务相比，REST服务主要存在如下不足：

（1）REST服务倡导的REST风格与实际实现尚存在一定差距。例如高层REST服务倡导使用GET、PUT、POST和DELETE所有4个统一接口，在REST实现部分通常只能采用GET和POST接口，因为大多数的代理和防火墙会屏蔽其他接口；并且XHTML表单中只能使用GET和POST接口。

（2） REST服务要求所有的输入参数都必须在URI中传递，这样会产生对参数容量大小的限制（目前的大小是4KB）。如果超出该数量，会导致HTTP协议错误（错误代码414：Request-URI too long）。

（3）在URI中表达复杂类型的参数比较困难，且目前对URI中的参数不存在一种公认的编组（marshalling）和解编（un-marshalling）方法。

三、进行基于REST服务的Web应用系统的设计时可能遇到的问题包括：如何识别并设计REST风格服务；构建REST服务的运行环境，包括HTTP服务器与应用服务器选型等；富客户端表现方式及编程语言的选择；系统逻辑与物理拓扑结构的分析与设计等。