高级系统架构设计师下午试题（Ⅰ）押题密卷2_在线真题试卷与模拟练习_高级系统架构设计师下午试题（Ⅰ）押题密卷2_考试宝

更新时间：试题数量：购买人数：提供作者：

有效期：个月

章节介绍：共有个章节

收藏

我的练习

我的错题
(0道)

我的收藏
(0道)

我的斩题
(0道)

我的笔记
(0道)

专项练习

顺序练习 0 / 0

随机练习 自定义设置练习量

题型乱序 按导入顺序练习

模拟考试 仿真模拟

题型练习 按题型分类练习

易错题 精选高频易错题

学习资料 考试学习相关信息

搜索

题库预览

请围绕“基于Mashup 的Web应用系统设计与应用”论题，依次对以下3个方面进行论述： 1. 概要叙述你参与管理和实施的Web应用系统开发项目及你所承担的主要工作。 2. 简述常见的Mashup 数据接口，详细论述你在所参与建设的Web应用系统项目中是如何应用Mashup 技术，并分析应用这些技术之后对项目产生了哪些效果(或影响)。 3. 论述在你参与建设的Web应用系统项目实施过程中遇到的，与Mashup 技术相关的问题及解决的办法，还有哪些需要进一步改进之处及如何进行改进。

请围绕“基于设计模式的软件架构设计与应用”论题，依次对以下3个方面进行论述： 1. 概要叙述你参与管理和开发的软件工程项目及你在其中所承担的主要工作。 2. 简要介绍设计模式的基本分类，详细说明在你所参与管理和开发的软件工程项目中应用了哪些设计模式、方法，以及选用它们的原因。 3. 分析并讨论使用设计模式的效果，并分析和评价设计模式对软件架构设计的影响。

请分析比较两种集成方案的优点和不足，将应用系统集成方案对比表中的(1)～(6)空缺处的内容填写完整。（应用系统集成方案对比表：考虑因素\集成方案 | 魏工建议的集成方案 | 陈工建议的集成方案拟采取的集成方法 | 涉及不同的集成层次，集成方法复杂多样 | (1) 对企业集成需求的符合程度 | (2) | (3) 集成系统体系结构 | (4) | (3) 集成系统的可扩展性 | 遗产系统集成方法多样，系统耦合度高，可扩展性较差 | (6) ）

企业数据的分布性和异构性是应用系统方便访问企业数据和在企业数据之上提供增值服务的主要障碍。基于SOA的企业集成通过信息服务提供集成数据的能力，针对该企业的集成实际情况，请用300字以内的文字列举3种基于SOA的企业集成中的“数据整合一信息服务”，并给出简要说明。

结合你的系统架构设计经验，请用300字以内的文字简要说明FT公司项目组在对该企业构建SOA架构时，除了注意原有系统架构中的集成需求之外，还需要在服务构建时重点关注哪些问题。

车载终端用户在遇到特殊情况下通过车载电话(或按键)与调度中心保持通信的处理过程顺序图如图3所示。结合你的系统架构经验，以及对GPS终端系统的理解，请将下列A～F标记的处理过程填入到图3中的(1)～(6)空缺处，并给出通过车载电话(或按键)与调度中心保持通信的正确处理顺序(请用A～F表达，例如ABCDEF)。

建立顶层架构是基于UML对该车载GPS终端系统进行建模的步骤之一。顶层架构的主要目的是为后续的分析和设计活动建立一种结构和划分，以便开发人员在不同阶段，以及同一开发阶段的不同开发人员，能够聚集于系统的不同部分。结合你的系统架构经验，请简要说明在该车载GPS终端系统确立顶层架构的过程中需要综合考虑哪些因素？

结合你的系统架构设计经验，请用200字以内的文字简要说明A公司是否适合采用产品线方法，并说明你的理由。

结合你的系统架构设计经验，请用400字以内的文字说明在原有产品的基础上建立软件产品线的方式，并进行简要评价。

结合你的系统架构设计经验，请用250字以内的文字说明成功实施产品线的主要因素。

简要介绍你参与规划、设计和实施的大中型信息系统软件工程项目，简要说明自己在该项目中的角色、所承担的主要任务及开展的主要工作。论文叙述自己参与设计和实施的软件工程项目应有一定的规模，自己在该项目中担任的主要工作应有一定的分量。设计模式描述了在特定场景下解决一般设计问题的类和相互通信的对象。设计模式的核心在于提供了相关问题的解决方案。设计模式的基本组成元素有模式名称、问题或意图、情景、动机、解决方案、示例、结果情景、基本原理、相关模式和已知应用等。设计模式主要用于得到简洁灵活的系统设计，GoF的书中共有23个设计模式，这些模式可以按两个准则来分类：一是按设计模式的目的划分，可分为创建型、结构型和行为型3种模式；二是按设计模式的范围划分，即根据设计模式是作用于类还是作用于对象来划分，可分为类设计模式和对象设计模式，如表所示。【缺少答案，请补充】（含图）

应用集成是指两个或多个应用系统根据业务逻辑的需要而进行的功能之间的相互调用和互操作。应用集成需要在数据集成的基础上完成。应用集成在底层的网络集成和数据集成的基础上实现异构应用系统之间语用层次上的互操作。它们共同构成了实现企业集成化运行最顶层会集成代所需要的，技术层次之间的基础支持。应用集成模式包括集成适配器、集成信使、集成面板和集成代理4种，每种应用集成模式都是对具有业务功能依赖关系的多个应用之间互操作实现方法的总结。在具体应用中，集成模式可能以某种变形(这是一种扩展集成模式的主要方式)的形式出现，这些变形可能不仅仅只是一种模式的实例化，也可能是一种具有广泛适用性的集成方式。通常，应用集成主要采用点对点的紧耦合方式。这种集成方式虽然不需要对应用系统做较大的改动，但用这种方式集成的系统缺乏必要的柔性，不能适应业务系统快速重构的需求。随着应用软件系统设计和实现过程中标准化程度的不断提高，系统的开放性(可配置性、可扩展性)越来越好，组件化的系统实现及松散耦合的应用集成方式逐渐成为构建企业业务处理系统的主流。其中，松散耦合是实现系统柔性的基础。在陈工建议的集成方案中，Web Service是一种可以接收从Internet 或Intranet 上传送的请求、轻量级的独立的通信技术，它允许网络上的所有系统相互间进行交互。Web Service的3个基本技术分别是UDDI, WSDL和SOAP，它们都是以XML为基础定义的。在Web服务体系中，使用WSDL来描述服务，UDDI来发布和查找服务，而SOAP用来执行服务调用。面向服务架构体系结构(SOA) 的几个关键特性是，它是一种粗粒度、松耦合的服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。SOA可以根据需求通过网络对松耦合、粗粒度的应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中软件代理交互的人为依赖性。 SOA技术将应用程序的不同功能单元通过一些良好定义的接口联系起来，并且接口采用中立的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言。这样可以使得构建的服务以一种【缺少答案，请补充】

图2为车载终端用户通过车载电话(或按键)与调度中心保持通信的处理过程顺序图。其表达的处理过程如下：用户通过按下按钮或语音对话试图连接调度中心，主控器模块接收到连接请求后(或连接建立后),就发送相应的信息给通信模块；通信模块负责处理并通过GSM发送消息，调度中心接收消息成功后要求监听信息，并把该要求返回给车载系统的GSM通信模块； GSM通信模块把该请求信息(即调度中心的要求监听信息)递交给主模块，主模块把监听命令递交给GSM通信模块，然后可由GSM通信模块递交给调度中心。【缺少答案，请补充】（含图）

在初步的业务需求描述已经形成的前提下，基于UML的需求分析大致可分为以下几个步骤。 • 利用用例及用例图表示需求。从业务需求描述出发获取执行者和场景；对场景进行汇总、分类和抽象；形成用例；确定执行者与用例，用例与用例图之间的关系，生成用例图。 • 利用包图及类图表示目标软件系统的总体框架结构。根据领域知识、业务需求描述和既往经验设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”,形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的关系，生成类图。上述两个步骤并没有时序关系，它们可以并行展开。其中，顶层架构的主要目的是为后续的分析和设计活动建立一种结构和划分，以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分。顶层架构是分析和设计的阶段成果的承载体。随着开发过程的推进，框架中的内容不断丰富和翔实，最终演进为完整的面向对象的软件结构。UML包图是表示顶层架构的适当机制。建立软件系统顶层架构的基本方法是，结合实际需求，从既往的架构设计经验模型中选取适当者，再进行微调或局部改造。目前有以下几种主要的架构模式。 (1)流程处理模式。流程处理系统以算法和数据结构为中心，其系统功能由一系列的处理步骤构成，相邻的处理步骤之间以数据流通管道相互连接。该模式仅适合于采用批处理方式的软件系统，不适合于交互式系统。 (2)客户/服务器模式。客户端负责用户输入和处理结果的呈现，服务器端则负责后台的业务逻辑处理。 (3)模型一视图一控制器(MVC)模式。该模式将整个软件系统划分为模型、视图和控制器3个部分。模型负责维护并保存具有持久性的业务数据，实现业务处理功能，并将业务数据的变化情况及时通知视图；视图负责呈现模型的业务数据，响应模型变化通知，更新呈现形式，并向控制器传递用户的界面动作；控制器负责将用户的界面动作映射为模型中业务处理功能并实际调用之，然后根据模型返回的业务处理结果选择新的视图。MVC模式特别适合于分布式应用软件，尤其是Web应用系统。 (4)分层模式。该模式将整个软件系统分为若干层次，最顶层直接面向用户提供软件系统的操作界面，其余各层为紧邻其的层次提供服务。层次划分的主要原则是，较易变化的软件部分(例如用户界面和与业务逻辑紧密相关的部件)置于较高层次，较稳定的软件部分(例如公共的技术服务部件)则位于较低层次；每一层次尽量只访问其紧邻下层提供的服务，避免越级访问，尤其要避免逆向访问(上层模块为下层模块提供服务);在许多情况下，可以将目标软件系统的外部接口置入较低层次，目标软件系统其余部分对外部系统的访问或操作均通过这些外部接口所提供的公共服务来完成。分层模式可以有效地降低软件系统的耦合度，因此其应用十分普遍。在全面了解软件架构样式的前提下，对于具体的应用需求而言，影响顶层架构选取的主要因素在于系统架构师的经验及他们对每种架构样式与当前软件项目之间匹配程度的判断。事实上，大型软件的顶层架构往往需要复合使用多种架构样式。例如，整个目标软件系统采用分层结构，在系统的不同层次内再分别使用适宜的其他种类的架构模式。在确立顶层架构的过程中，需要综合考虑以下因素。 (1)架构中包的数量。原则上，如果每个包中包含的软件元素(例如类)的数量过多，应考虑将其进一步细分；如果过少，则说明架构过早地陷入了细节，架构划分返工的可能性较大，同时也不合理地限制了后续分析和设计活动的自由空间。 (2)架构中包之间的耦合度。包之间的依赖关系和连接关系应尽量简单、稀疏，例如，在分层结构中，通常要求某一层中的软件元素只与同层及相邻下一层的元素之间存在依赖关系。 (3)软件元素的稳定性。要尽量抽取不稳定的软件元素之中相对稳定的部分，将不稳定的软件元素分类聚集于少数几个包中，以提高软件系统的可维护性。 (4)软件元素的必然性。可以将可选功能和必须实现的功能分置于架构中不同的包或子包之中。 (5)作为软件系统运行环境的物理网络拓扑。根据软件元素在分布环境的部署情况，区分顶层架构中的包，可以使包之间的消息传递与物理节点之间的通信相吻合，使后续的分析和设计活动受益于顶层架构中明确定义的通信关系。 (6)软件元素的安全和保密级别。根据安全访问的权限划分顶层架构中的包或者子包。 (7)开发团队的技术专长。根据开发人员在问题领域和软件技术领域不同的专长划分顶层架构中的包，使每个包都能分配给最适合的开发人员进行后续的分析、设计、编码和测试等，从而有利于并行开发。【缺少答案，请补充】

这是一道要求读者根据具体应用环境，分析软件产品线(Software Product Line)的适用性的综合理解题。本试题的解答思路如下。

指出基于现有产品集出发的“软件产品线”构建方法，并指出它们的区别与实施要点

说明成功实施产品线的主要因素

1

更多题库