免费智能真题库 > 历年试卷 > 系统架构设计师 > 2014年下半年 系统架构设计师 上午试卷 综合知识
  第40题      
  知识点:   软件架构   软件架构概述   架构设计   软件架构设计   重要性
  关键词:   软件架构        章/节:   软件架构的概念       

 
以下关于软件架构设计重要性的描述,(40)是错误的。
 
 
  A.  软件架构设计能够满足系统的性能、安全性、可维护性等品质
 
  B.  软件架构设计能够帮助项目干系人(Stakeholder)更好地理解软件结构
 
  C.  软件架构设计能够帮助架构师更好地捕获和细化系统需求
 
  D.  软件架构设计能够有效地管理系统的复杂性,并降低系统维护费用
 
 
 

 
  第42题    2015年下半年  
   33%
软件架构是降低成本、改进质量、按时和按需交付产品的关键因素。软件架构设计需满足系统的( ),如性能、安全性和可修改性等,并..
  第45题    2011年下半年  
   54%
(44) 描述了一类软件架构的特征,它独立于实际问题,强调软件系统中通用的组织结构选择。垃圾回收机制是Java语言管理内存资源时常..
  第42题    2013年下半年  
   44%
软件系统架构是关于软件系统的结构、(40)和属性的高级抽象。在描述阶段,主要描述直接构成系统的抽象组件以及各个组件之间的连接..
   知识点讲解    
   · 软件架构    · 软件架构概述    · 架构设计    · 软件架构设计    · 重要性
 
       软件架构
        随着嵌入式技术的发展,特别是在后PC时代,嵌入式软件系统得到了极大的丰富和发展,形成了一个完整的软件体系,如下图所示。这个体系自底向上由3部分组成,分别是嵌入式操作系统、支撑软件和应用软件。
        
        嵌入式系统的软件架构
        嵌入式操作系统(Embedded Operating System,EOS)由操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务,其他大部分的功能则由支撑软件完成。
        嵌入式系统中的支撑软件由窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。对于嵌入式系统来讲,软件的开发环境大部分在通用台式计算机和工作站上运行,但从逻辑上讲,它仍然被认为是嵌入式系统支撑软件的一部分。支撑软件一般用于一些浅度嵌入的系统中,如智能手机、个人数字助理等。
        嵌入式系统中的应用软件是系统整体功能的集中体现。系统的能力总是通过应用软件表现出来的。
 
       软件架构概述
        软件架构是具有一定形式的结构化元素,即构件的集合,包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工,数据构件是被加工的信息,连接构件把架构的不同部分组合连接起来。软件架构是软件设计过程中的一个层次,这一层次超越计算过程中的算法设计和数据结构设计。架构问题包括总体组织和全局控制、通信协议、同步、数据存取,给设计元素分配特定功能,设计元素的组织,规模和性能,在各设计方案间进行选择等。软件架构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题,如全局组织和全局控制结构、关于通信、同步与数据存取的协议,设计构件功能定义,物理分布与合成,设计方案的选择、评估与实现等。
        软件架构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。其中,“软件外部的可见特性”是指软件构件提供的服务、性能、特性、错误处理、共享资源使用等。对于复杂系统和大型系统的开发而言,设计好软件架构是保证软件质量的根本措施。具体来说,软件架构具有以下作用:
        (1)软件架构是项目干系人进行交流的手段。架构代表了系统的公共的高层次的抽象。这样,系统的大部分有关人员(即使不是全部)能把它作为建立一个互相理解的基础,形成统一认识,互相交流。
        (2)软件架构是早期设计决策的体现。架构体现了系统的最早的一组设计决策,这些早期的约束比起以后的开发、设计、编码或运行服务及维护阶段的工作重要得多,对系统生命周期的影响也大得多。早期决策的正确性最难以保证,而且这些决策也最难以改变,影响范围也最大。软件架构明确了对系统实现的约束条件,决定了开发和维护组织的组织结构;架构制约着系统的质量属性,通过研究软件架构可能预测软件的质量;架构使推理和控制更改更简单,有助于循序渐进的原型设计;架构可以作为培训的基础。
        (3)软件架构是可传递和可重用的模型。架构体现了一个相对来说比较小又可理解的模型。架构级的重用意味着架构的决策能在具有相似需求的多个系统中发生影响,这比代码级的重用要有更大的好处。
 
       架构设计
        WebApp描述了使WebApp达到其业务目标的基础结构,典型使用多层架构来构造,包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器,以及可以包含WebApp的业务规则的内容层或模型层,描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容。模型-视图-控制器(Model-View-Controller,MVC)结构是WebApp基础结构模型之一,它将WebApp功能及信息内容分离。
 
       软件架构设计
        软件架构也称为软件体系结构,需要考虑如何对系统进行分解,对分解后的组件及其之间的关系进行设计,满足系统的功能和非功能需求。软件架构形成过程如下图所示。
        
        架构的形成过程概要
        软件架构设计需要从用户业务需求、未来应用环境、需求分析、硬件基础、接口输入、数据处理、运算或控制规律、用户使用等方面进行综合、权衡和分析基础上产生。面向某种问题的架构一旦确定就很难改变,随后的架构设计需要通过一系列的迭代开发完善,使得软件架构日趋成熟、稳定。
        软件架构的重要作用也在于控制一个软件系统的使用、成本和风险。好的架构要求是和谐的软件架构,包括与上一级系统架构相互和谐、与系统中同一级的其他组件架构互相和谐,确保系统满足性能、可靠性、安全性、信息安全性和互操作性等方面的关键要求,也具有可扩展、可移植性,从而为一个软件带来长久的生命力。
        在大量开发实践中,有很多广泛使用并被普遍接受的软件架构设计原则,这些原则独立于具体的软件开发方法,主要包括抽象、信息隐藏、强内聚和松耦合、关注点分离等。
        (1)抽象:这是软件架构的核心原则,也是人们认识复杂客观世界的基本方法。抽象的实质是提取主要特征和属性,从具体的事务中通过封装来忽略细节,并且运用这些特征和属性,描述一个具有普遍意义的客观世界。软件架构设计中需要对流程、数据、行为等进行抽象。复杂系统含有多层抽象,从而有多个不同层次架构。
        (2)信息隐藏:包括局部化设计和封装设计。局部化设计就是将一个处理所涉及到的信息和操作尽可能地限制在局部的一个组件中,减少与其他组件的接口。而封装设计是将组件的外部访问形式尽可能简单、统一。
        (3)强内聚和松耦合:强内聚是指软件组件内的特性,即组件内所有处理都高度相关,所有处理组合在一起才能组成一个相对完整的功能。而松耦合是指软件组件之间的特性,软件组件之间应尽量做到没有或极少的直接关系,使其保持相对独立,这样使得未来的修改、复用简单,修改之后带来的影响最小。
        (4)关注点分离:所谓关注点是软件系统中可能会遇到的多变的部分。如为适应不同运行接口条件,需要进行适应性的参数调整和驱动配置。关注点分离设计是将这部分组件设计成为相对独立的部分,使未来的系统容易配置和修改。而核心的部分可以保持一个相对独立的稳定状态。如果功能分配使得单独的关注点组件足够简单,那么就更容易理解和实现。但“展示某些关注点得到满足时,可能会影响到其他方面的关注点,但架构师必须能够说明所有关注点都已得到满足”。
        以上的原则中,删除需求细节或对细节进行抽象是最重要的工作,为用户的需求创建抽象模型,通过抽象将特殊问题映射为更普遍的问题类别,并识别各种模式。
        软件架构设计使用纵向分解和横向分解两种方式。纵向分解就是分层,横向分解就是将每一个层面分成相对独立的部分。经过分解之后,可以将一个完整的问题分解成多个模块来解决。模块是其中可分解、可组装,功能独立、功能高度内聚、之间低耦合的一个组件。
        类似于建筑架构,软件架构也决定了软件产品的好用、易用、可靠、信息安全、可扩展、可重用等特性,好的软件架构也给人完整、明确、清晰等赏心悦目的感觉,具有较长的生命力。
        架构设计是围绕业务需求带来的问题空间到系统解决空间第一个顶层设计方案。按照抽象原则,在这个阶段进行的架构设计关注软件设计环节抽象出来的重要元素,而不是所有的设计元素。在架构设计时将软件这些要素看作是黑盒,架构设计需要满足黑盒的外部功能和非功能需求的目标。一个软件的架构设计首先为软件产品的后续开发过程提供基础,在此基础上可将一个大规模的软件分解为若干子问题和公共子问题。而一般意义的软件设计是软件的底层设计,开发人员需要关注各子问题或要素的进一步分解和实现,是根据架构设计所定义的每个要素的功能、接口,进一步实现要素组件内部的配置、处理和结构。在遵守组件外部属性前提下,考虑实现组件内部的细节及其实现方法。对于其中的公共子问题,形成公共类和工具类,从而可以达到重用的目的。
        一般的软件构架是根据需求自上而下方式来设计,即首先掌握和研究利益相关方的关键需求,基本思路是首先进行系统级的软件架构设计,需要将软件组件与其外部环境属性绑定在一起,关注软件系统与外部环境的交联设计;其次将一个大的系统划分成各组成部分,这些部分可以按照架构设计的不同方法,分为层次或成为模块;之后再开始研究所涉及到的要素,再实现这些要素以及定义这些要素之间的关系。
        在实际工作中,软件构架也可采用自底向上的方法,前提是已经建立了一个成熟稳定的软件架构,也可以称之为“模式”。模式是组织一级设计某一类具体问题的顶层思路,是为了解决共有问题解的方案模板,但并不是一个问题的设计或设计算法。
        模式常常整合在一起使用,提供解决更大、更复杂问题的解决方案,而组成一个解决问题的通用框架。框架往往提供统一平台和开发工具,而且已经高效地利用了已经经过验证的模式、技术和组件。在新软件系统的设计中指定沿用或重用这种架构框架,这时其他重要元素可以在这个架构基础上针对新的需求进行扩展,有时是针对性地进行参数化设计。所以在架构设计中可以借用模式的概念进行设计,采用成熟的先进的设计框架和工具提高开发的效率,保证设计正确性。
        下图所示是针对架构设计中非功能需求的多维度分析,从中可知任何一个因素的变化都会带来对其他因素的影响。实际上软件架构设计属于软件设计过程的一部分,但超越了系统内部的算法和数据结构的详细设计。
        
        架构的多维度分析
        在架构设计阶段,需要定义边界条件、描述系统组织结构、对系统的定量属性进行约束、帮助对模型进行描述并基本构造早期的原型、更准确地描述费用和时间的评估。
 
       重要性
        IT系统的运营管理要考察系统的运营状况,根据需要调整和改善系统软硬件和环境条件,以提高系统的业务支持能力;或者调整IT资产结构,在保障系统有效运转的前提下降低IT系统总体成本。IT系统运营管理的根本目的是以尽可能低的花费为组织的业务提供足够的和可靠的IT服务支持。
        为了保障对业务提供持续可靠并且经济的IT支持,需要对系统性能进行科学而有效的管理。性能评价技术是在必要的时候(例如,新硬件设备采购的评测、定期系统能力评价、业务需求变更之时的能力评测和规划)作为性能管理的支撑技术出现的。
   题号导航      2014年下半年 系统架构设计师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第40题    在手机中做本题