免费智能真题库 > 历年试卷 > 系统架构设计师 > 2010年下半年 系统架构设计师 上午试卷 综合知识
  第45题      
  知识点:   架构设计与演化   软件架构   架构设计   评审   软件架构设计   设计评审
  关键词:   软件架构   设计评审   评审        章/节:   软件架构基础知识       

 
软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动,是一个迭代的过程。以下关于软件架构设计活动的描述,错误的是(45)。
 
 
  A.  在建立软件架构的初期,一般需要选择一个合适的架构风格
 
  B.  将架构分析阶段已标识的构件映射到架构中,并分析这些构件之间的关系
 
  C.  软件架构设计活动将已标识构件集成到软件架构中,设计并实现这些构件
 
  D.  一旦得到了详细的软件架构设计,需要邀请独立于系统开发的外部人员对系统进行评审
 
 
 

 
  第63题    2013年下半年  
   31%
架构权衡分析方法(Architecture Tradeoff Analysis Method,ATAM)是一种系统架构评估方法,主要在系统开发之前,针对性能、(57)、..
  第44题    2011年下半年  
   32%
(44) 描述了一类软件架构的特征,它独立于实际问题,强调软件系统中通用的组织结构选择。垃圾回收机制是Java语言管理内存资源时常..
  第53题    2017年下半年  
   44%
系统中的构件和连接件都有一个顶部和一个底部,构件的顶部应连接到某连接件的底部,构件的底部则应连接到某连接的顶部,构件和构..
   知识点讲解    
   · 架构设计与演化    · 软件架构    · 架构设计    · 评审    · 软件架构设计    · 设计评审
 
       架构设计与演化
        对于软件项目的开发来说,一个清晰的架构是首要的。即使在初始原型阶段,也不例外。然而,在系统开发的初始阶段就设计好系统的最终结构是不可能的,也是不现实的,因为,需求还在不断地发生变化。所以,一个好的软件架构应该可以创建或再创建功能、用户界面和问题域模型,演化原型以满足新的软件需求。也就是说,软件架构本身也是可演化的,这种演化可基于需求的变化、增进了的对问题域的理解、对实现系统的技术方式的进一步理解的基础上。从这种意义上来说,不但软件系统以原型方式演化,架构本身也以原型方式演化。
        一个软件系统开发完毕正式投入使用之后,如果要将该系统移植到另一个环境运行,且新环境的需求也有相应的变化时,软件也要进行修改。通常,这种修改所需的工作量与软件需求变化的多少和变化的范围有直接关系。但是,一个好的软件架构能大大减少修改工作量。
                      设计和演化过程
                      基于架构的软件开发过程可以分为独立的两个阶段,这两个阶段分别是实验原型阶段和演化开发阶段。
                      (1)实验原型阶段。这一阶段考虑的首要问题是要获得对系统支持的问题域的理解。为了达到这个目的,软件开发组织需要构建一系列原型,与实际的最终用户一起进行讨论和评审,这些原型应该演示和支持全局改进的实现。但是,来自用户的最终需求是很模糊的,因此,整个第一个阶段的作用是使最终系统更加精确化,有助于决定实际开发的可行性。
                      (2)演化开发阶段。实验原型阶段的结果可以决定是否开始实现最终系统,如果可以,开发将进入第二个阶段。与实验原型阶段相比,演化开发阶段的重点放在最终产品的开发上。这时,原型即被当作系统的规格说明,又可当作系统的演示版本。这意味着演化开发阶段的重点将转移到构件的精确化。
                      虽然实验原型阶段的结果可以决定是否开始实现最终系统,但在实验原型阶段之后,还会有些功能需求不能足够准确地得到表达。然而,系统有哪些组成部分和这些部分该如何相互作用应该是明确的了。
                      在每个阶段中,都必须以一系列的开发周期为单位安排和组织工作,一个开发周期的时间长短可根据软件项目的性质、功能复杂性、开发阶段等因素决定。每一个开发周期都要有不同的着重点,要有一个分析、设计和实现的过程,这个过程取决于当前对系统的理解和前一个开发周期的结果。为了控制开发进度,在每一个开发周期结束时,都必须对当前产品安排一次技术评审,评审组成员由最终用户代表和开发组织的管理人员组成。技术评审的目的是指出当前产品中可能存在的问题,制订下一个开发周期的工作计划。
                      实验原型阶段
                      一般地,实验原型阶段的第一个开发周期没有具体的、明确的目标。此时,为了提高开发效率,缩短开发周期,所有开发人员可以分成了两个小组,一个小组创建图形用户界面,另一个小组创建一个问题域模型。两个小组要并行地工作,尽量不发生相互牵制的现象。
                      在第一个周期结束时,形成了两个版本,一个是图形用户界面的初始设计,主要包括一些屏幕元素,例如窗口、菜单等;另一个是问题域模型,该模型覆盖了问题域的子集。用户界面设计由水平原型表示,也就是说,运行的程序只是实现一些用户界面控制,没有实现真正的系统功能。问题域模型可由一个统一建模语言类图表示,该类图并不是运行的原型的一部分。然而,它并不只是一个简单的类图,可由一个CASE工具(如IBM Rational Rose)自动产生代码,而且,当一个新的元素增加到模型中时,这些代码会自动进行增量更新。
                      第二个开发周期的任务是设计和建立一个软件架构,该架构应该具有以下特征:
                      (1)必须足够灵活,不但能包含现有的元素,而且能包含新增的功能。
                      (2)必须提供一个相当稳定的结构,在这个结构中,原型能在实验原型阶段进行演化。
                      (3)必须支持一个高效的开发组织,允许所有开发人员并行地在原型的基础上进行开发。
                      整个第二个开发周期又可细分为以下5个小阶段:
                      (1)标识构件。为系统生成初始逻辑结构,包含大致的构件。这一阶段又可分为3个小步骤:生成类图、对类进行分组、把类打包成构件。
                      (2)提出软件架构模型。在建立架构的初期,选择一个合适的架构风格是首要的。在这个风格基础上,开发人员通过架构模型,可以获得关于架构属性(如程序逻辑结构、开发平台等)的理解。此时,虽然这个模型是理想化的(其中的某些部分可能错误地表示了应用的特征),但是,该模型为将来的调整和演化过程建立了目标。
                      (3)把已标识的构件映射到软件架构中。把在第(1)阶段已标识的构件映射到架构中,将产生一个中间结构,这个中间结构只包含那些能明确适合架构模型的构件。
                      (4)分析构件之间的相互作用。为了把所有已标识的构件集成到架构中,必须认真分析这些构件的相互作用和关系。
                      (5)产生软件架构。一旦决定了关键的构件之间的关系和相互作用,就可以在第(3)阶段得到的中间结构的基础上进行细化。可以利用顺序图标识中间结构中的构件和剩下的构件之间的依赖关系,分析第(2)阶段模型的不一致性(如丢失连接等)。
                      演化开发阶段
                      一旦软件的架构得以确定,就可以开始正式的构件开发工作。在构件开发过程中,最终用户的需求可能还有变动。在软件开发完毕,正常运行后,由一个单位移植到另一个单位,需求也会发生变化。在这两种情况下,就必须使用系统演化步骤去修改应用,以满足新的需求。主要包括以下8个步骤:
                      (1)需求变动归类。首先必须对用户需求的变化进行归类,使变化的需求与已有构件和线索对应。对找不到对应构件和线索的变动,也要作好标记,在后续工作中,将创建新的构件或线索,以对应这部分变化的需求。
                      (2)制订架构演化计划。在改变原有结构之前,开发组织必须制订一个周密的架构演化计划,作为后续演化开发工作的指南。
                      (3)修改、增加或删除构件。在演化计划的基础上,开发人员可根据在第(1)步得到的需求变动的归类情况,决定是否修改或删除存在的构件、增加新构件。
                      (4)更新构件的相互作用。随着构件的增加、删除和修改,构件之间的控制流必须得到更新。
                      (5)产生演化后的架构。在原来系统上所作的所有修改必须集成到原来的架构中。这个架构将作为改变的详细设计和实现的基础。
                      (6)迭代。如果在第(5)步得到的架构还不够详细,不能实现改变的需求,可以把第(3)~(5)步再迭代一次。
                      (7)对以上步骤进行确认,进行阶段性技术评审。
                      (8)对所做的标记进行处理。重新开发新线索中的所有构件,对已有构件按照标记的要求进行修改、删除或更换。完成一次演化过程。
 
       软件架构
        随着嵌入式技术的发展,特别是在后PC时代,嵌入式软件系统得到了极大的丰富和发展,形成了一个完整的软件体系,如下图所示。这个体系自底向上由3部分组成,分别是嵌入式操作系统、支撑软件和应用软件。
        
        嵌入式系统的软件架构
        嵌入式操作系统(Embedded Operating System,EOS)由操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务,其他大部分的功能则由支撑软件完成。
        嵌入式系统中的支撑软件由窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。对于嵌入式系统来讲,软件的开发环境大部分在通用台式计算机和工作站上运行,但从逻辑上讲,它仍然被认为是嵌入式系统支撑软件的一部分。支撑软件一般用于一些浅度嵌入的系统中,如智能手机、个人数字助理等。
        嵌入式系统中的应用软件是系统整体功能的集中体现。系统的能力总是通过应用软件表现出来的。
 
       架构设计
        WebApp描述了使WebApp达到其业务目标的基础结构,典型使用多层架构来构造,包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器,以及可以包含WebApp的业务规则的内容层或模型层,描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容。模型-视图-控制器(Model-View-Controller,MVC)结构是WebApp基础结构模型之一,它将WebApp功能及信息内容分离。
 
       评审
        对设计部分是否完整地实现了需求中规定的功能、性能等要求,设计方法的可行性,关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行评审。
 
       软件架构设计
        软件架构也称为软件体系结构,需要考虑如何对系统进行分解,对分解后的组件及其之间的关系进行设计,满足系统的功能和非功能需求。软件架构形成过程如下图所示。
        
        架构的形成过程概要
        软件架构设计需要从用户业务需求、未来应用环境、需求分析、硬件基础、接口输入、数据处理、运算或控制规律、用户使用等方面进行综合、权衡和分析基础上产生。面向某种问题的架构一旦确定就很难改变,随后的架构设计需要通过一系列的迭代开发完善,使得软件架构日趋成熟、稳定。
        软件架构的重要作用也在于控制一个软件系统的使用、成本和风险。好的架构要求是和谐的软件架构,包括与上一级系统架构相互和谐、与系统中同一级的其他组件架构互相和谐,确保系统满足性能、可靠性、安全性、信息安全性和互操作性等方面的关键要求,也具有可扩展、可移植性,从而为一个软件带来长久的生命力。
        在大量开发实践中,有很多广泛使用并被普遍接受的软件架构设计原则,这些原则独立于具体的软件开发方法,主要包括抽象、信息隐藏、强内聚和松耦合、关注点分离等。
        (1)抽象:这是软件架构的核心原则,也是人们认识复杂客观世界的基本方法。抽象的实质是提取主要特征和属性,从具体的事务中通过封装来忽略细节,并且运用这些特征和属性,描述一个具有普遍意义的客观世界。软件架构设计中需要对流程、数据、行为等进行抽象。复杂系统含有多层抽象,从而有多个不同层次架构。
        (2)信息隐藏:包括局部化设计和封装设计。局部化设计就是将一个处理所涉及到的信息和操作尽可能地限制在局部的一个组件中,减少与其他组件的接口。而封装设计是将组件的外部访问形式尽可能简单、统一。
        (3)强内聚和松耦合:强内聚是指软件组件内的特性,即组件内所有处理都高度相关,所有处理组合在一起才能组成一个相对完整的功能。而松耦合是指软件组件之间的特性,软件组件之间应尽量做到没有或极少的直接关系,使其保持相对独立,这样使得未来的修改、复用简单,修改之后带来的影响最小。
        (4)关注点分离:所谓关注点是软件系统中可能会遇到的多变的部分。如为适应不同运行接口条件,需要进行适应性的参数调整和驱动配置。关注点分离设计是将这部分组件设计成为相对独立的部分,使未来的系统容易配置和修改。而核心的部分可以保持一个相对独立的稳定状态。如果功能分配使得单独的关注点组件足够简单,那么就更容易理解和实现。但“展示某些关注点得到满足时,可能会影响到其他方面的关注点,但架构师必须能够说明所有关注点都已得到满足”。
        以上的原则中,删除需求细节或对细节进行抽象是最重要的工作,为用户的需求创建抽象模型,通过抽象将特殊问题映射为更普遍的问题类别,并识别各种模式。
        软件架构设计使用纵向分解和横向分解两种方式。纵向分解就是分层,横向分解就是将每一个层面分成相对独立的部分。经过分解之后,可以将一个完整的问题分解成多个模块来解决。模块是其中可分解、可组装,功能独立、功能高度内聚、之间低耦合的一个组件。
        类似于建筑架构,软件架构也决定了软件产品的好用、易用、可靠、信息安全、可扩展、可重用等特性,好的软件架构也给人完整、明确、清晰等赏心悦目的感觉,具有较长的生命力。
        架构设计是围绕业务需求带来的问题空间到系统解决空间第一个顶层设计方案。按照抽象原则,在这个阶段进行的架构设计关注软件设计环节抽象出来的重要元素,而不是所有的设计元素。在架构设计时将软件这些要素看作是黑盒,架构设计需要满足黑盒的外部功能和非功能需求的目标。一个软件的架构设计首先为软件产品的后续开发过程提供基础,在此基础上可将一个大规模的软件分解为若干子问题和公共子问题。而一般意义的软件设计是软件的底层设计,开发人员需要关注各子问题或要素的进一步分解和实现,是根据架构设计所定义的每个要素的功能、接口,进一步实现要素组件内部的配置、处理和结构。在遵守组件外部属性前提下,考虑实现组件内部的细节及其实现方法。对于其中的公共子问题,形成公共类和工具类,从而可以达到重用的目的。
        一般的软件构架是根据需求自上而下方式来设计,即首先掌握和研究利益相关方的关键需求,基本思路是首先进行系统级的软件架构设计,需要将软件组件与其外部环境属性绑定在一起,关注软件系统与外部环境的交联设计;其次将一个大的系统划分成各组成部分,这些部分可以按照架构设计的不同方法,分为层次或成为模块;之后再开始研究所涉及到的要素,再实现这些要素以及定义这些要素之间的关系。
        在实际工作中,软件构架也可采用自底向上的方法,前提是已经建立了一个成熟稳定的软件架构,也可以称之为“模式”。模式是组织一级设计某一类具体问题的顶层思路,是为了解决共有问题解的方案模板,但并不是一个问题的设计或设计算法。
        模式常常整合在一起使用,提供解决更大、更复杂问题的解决方案,而组成一个解决问题的通用框架。框架往往提供统一平台和开发工具,而且已经高效地利用了已经经过验证的模式、技术和组件。在新软件系统的设计中指定沿用或重用这种架构框架,这时其他重要元素可以在这个架构基础上针对新的需求进行扩展,有时是针对性地进行参数化设计。所以在架构设计中可以借用模式的概念进行设计,采用成熟的先进的设计框架和工具提高开发的效率,保证设计正确性。
        下图所示是针对架构设计中非功能需求的多维度分析,从中可知任何一个因素的变化都会带来对其他因素的影响。实际上软件架构设计属于软件设计过程的一部分,但超越了系统内部的算法和数据结构的详细设计。
        
        架构的多维度分析
        在架构设计阶段,需要定义边界条件、描述系统组织结构、对系统的定量属性进行约束、帮助对模型进行描述并基本构造早期的原型、更准确地描述费用和时间的评估。
 
       设计评审
        对于按照以上规范提出的网络逻辑设计方案,必须得到批准后才能够实施。先交由单位组建的网络评审委员会讨论,审查该方案是否满足本单位对新网络的各种类型的需求,网络规划是否合理,使用的技术是否先进,选择的设备厂商是否信誉良好,网络的实施成本是否在单位的预算之内等,不同的单位可能有不同的审查准则。在所有条件均满足之后,网络设计方案才能得到批准。
        批准时,需要由单位的管理部门、MIS(管理信息系统)职员和咨询公司代表签字。
   题号导航      2010年下半年 系统架构设计师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第45题    在手机中做本题