软考高级之系统架构师系列之软件架构设计

注本文汇总整理软考高级系统架构设计师试题和分析。纯理论、纯概念、非原创。概述软件系统架构是关于软件系统的结构、行为和属性的高级抽象描述阶段主要描述直接构成系统的抽象组件以及各个组件之间的连接规则特别是相对细致地描述组件的交互关系实现阶段这些抽象组件被细化为实际的组件如具体类或对象。软件系统架构不仅指定软件系统的组织和拓扑结构而且显示系统需求和组件之间的对应关系包括设计决策的基本方法和基本原理。软件架构能够在设计变更相对容易的阶段考虑系统结构的可选方案便于技术人员与非技术人员就软件设计进行交互能够展现软件的结构、属性与内部交互关系。但是软件架构与用户对系统的功能性需求没有直接的对应关系。软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动是一个迭代的过程。架构设计主要关注软件组件的结构、属性和交互作用并通过多种视图全面描述特定系统的架构。软件架构设计与系统需求是直交的两者并无必然联系。层次有3个由大到小的层次架构模式软件设计中的高层决策C/S结构就属于架构模式架构模式反映开发软件系统过程中所作的基本设计决策设计模式主要关注软件系统的设计与具体的实现语言无关垃圾回收机制是Java语言管理内存资源时常用的一种设计模式。惯用法最低层的模式关注软件系统的设计与实现描述如何实现构件及构件之间的关系实现时通过某种特定的程序设计语言来描述构件与构件之间的关系例如引用-计数就是C语言中的一种惯用法。优点软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素能够满足系统的性能、安全性、可维护性等品质能够帮助项目干系人Stakeholder更好地理解软件结构能够有效地管理系统的复杂性并降低系统维护费用对系统开发具有指导性为系统复用奠定的基础能够支持冲突分析。ADL架构描述语言Architecture Description LanguageADL是一种为明确说明软件系统的概念架构和对这些概念架构建模提供功能的语言。主要包括以下组成部分组件、组件接口、连接件和架构配置。对连接件的重视成为和其他建模语言区分的重要特征之一。复用软件架构设计的一个核心问题是能否使用重复的架构模式即能否达到架构级的软件重用。即能否在不同的软件系统中使用同一架构。基于这个目的学者们开始研究和实践软件架构的风格和类型问题。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映领域中众多系统所共有的结构和语义特性并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解软件架构风格定义用于描述系统的术语表和一组指导构件系统的规则。软件架构复用是指在不改变软件功能的情况下将已有的软件架构直接或进行微调后复用到新的软件或系统中从而加快软件开发进程提高软件生产效率。软件架构复用包括软件产品复用和软件过程复用两部分的内容。其中软件产品复用是指将已有的软件组件如函数、模块、组件等直接或进行适应性修改后复用到新的软件或系统中软件过程复用是指将已有的软件生产过程中的各种劳动成果如设计文档、测试案例、源代码等直接或进行适应性修改后复用到新的软件或系统中。复用开发过程中只要发现有可复用的资产就对其进行复用计划复用开发之前就要进行规划以决定哪些需要复用软件架构复用可分为以下几种类型代码级通过编写公共类和公共函数等供开发人员直接使用组件级将功能的组件化封装对外提供API接口模块级在开发的项目或产品中如果发现大量重复的功能模块可以在这些模块设计时注重扩展性使其能应用到其他类似功能的项目中构架级在设计概念上最为高级的一种。它相当于一个平台或思想在这个平台上可开发出根据此平台思想稳定而又高效的软件产品软件架构复用的实现方式主要包括以下几种白盒复用源代码可见可修改和扩展黑盒复用源代码不可见不能修改模块层次复用接口/类包括继承和委托等软件复用过程包括三个主要阶段构造/获取可复用的软件资产Create/Acquire管理可复用资产Manage使用可复用资产Use。这是标准的复用生命周期模型。预期复用Planned Reuse是在系统开发前预先规划哪些构件需要复用是一种有计划的复用策略机会复用Opportunistic Reuse是在开发过程中碰到合适的复用资产就复用是临时的、被动的。需求软件架构需求是指用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。需求过程主要是获取用户需求标识系统中所要用到的构件并进行架构需求评审。其中标识构件又详细分为生成类图、对类图进行分组和将类打包成构件三步。软件架构需求并不应该包括设计构件的过程。架构师架构师的主要职责包括确认需求。在项目开发过程中架构师是在需求规格说明书完成后介入的需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流以保证完整并准确地理解用户需求。系统分解。依据用户需求架构师将系统整体分解为更小的子系统和组件从而形成不同的逻辑层或服务。随后架构师会确定各层的接口层与层相互之间的关系。架构师不仅要对整个系统分层进行纵向分解还要对同一逻辑层分块进行横向分解。技术选型。架构师通过对系统的一系列的分解最终形成了软件的整体架构。技术选择主要取决于软件架构。架构师对产品和技术的选型只限于评估没有决定权最终的决定权归项目经理。架构师提出的技术方案为项目经理提供重要的参考信息项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡最终进行确认。制定技术规格说明。架构师在项目开发过程中是技术权威。需要协调所有的开发人员与开发人员一直保持沟通始终保证开发者依照他的架构意图去实现各项功能。架构师通过他制定的技术规格说明书UML视图、Word文档、Visio文件与开发者沟通保证开发者可从不同角度去观察、理解各自承担的子系统或者模块。架构师还需要与项目经理、需求分析员甚至与最终用户保持沟通。建模应用架构建模中要绘制的第一个物理数据流图PDFD是网络架构DFD它们不显示单位时间的数据流量需要显示的信息包括服务器及其物理位置客户端及其物理位置处理器说明传输协议。生命周期软件架构贯穿于软件的整个生命周期但在不同的阶段对软件架构的关注力度并不相同。其中需求分析阶段主要关注问题域设计阶段主要将需求转换为软件架构模型软件实现阶段主要关注将架构设计转换为实际的代码软件部署阶段主要通过组装软件组件提高系统的实现效率。其中设计与实现阶段在软件架构上的工作最多也最重要因此关注力度最大。概念Software Architecture正式定义最早由Dewayne E. Perry和Alexander L. Wolf在1997年发表的经典论文Foundations for the Study of Software Architecture中提出该论文定义软件架构为组件components、连接件connectors和约束constraints的集合。Nx冗余模式N正常运行的节点数x允许同时故障的额外节点数N2冗余表示配置N个主节点额外配置2个备用节点允许任意2个节点故障仍能提供服务。常见于金融、电信等高可用系统。N1冗余允许1个故障2N冗余允许N个故障。风格软件架构风格是描述某一特定应用领域中的系统组织方式和惯用模式反映领域中众多系统所共有的结构和语义两个方面的特征主要包括架构定义、架构词汇表和架构约束并指导如何将各个模块和子系统有效地组织成一个完整的系统。架构风格定义一个系统家族即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格描述一类软件架构的特征它独立于实际问题强调软件系统中通用的组织结构选择。分类Garlan和Shaw对通用软件架构风格进行分类数据流风格包括批处理序列和管道-过滤器两种风格调用/返回风格包括主程序/子程序、数据抽象、面向对象、层次结构独立构件风格包括进程通信、事件驱动、发布-订阅风格的系统虚拟机风格包括解释器和基于规则的系统仓库风格包括数据库系统、黑板系统和超文本系统过程控制风格包括有开环、闭环等其他包括C2、异构风格、混合风格架构风格大类架构小类构件连接件数据流风格批处理序列管理过滤器计算单元过滤器数据流传输的管道调用/返回风格主/子程序面向对象层次结构主子程序对象每一层过程调用对象间的交付方式层间的交付方式独立构件进程通信事件驱动独立进程模块消息传递隐式调用仓库风格黑板系统知识源黑板或数据库系统数据流风格批处理序列定义构建为一序列固定顺序的计算单元构建之间只通过数据传递进行交付每个处理步骤是一个独立的程序每一步必须在其前一步结束后才能开始数据必须是完整的以整体的方式进行传递。特点强调整体性无交互管理过滤器定义每个构建都有一组输入、输出构建读输入的数据流经过内部处理然后产生输出数据流这个过程通常是通过对输入数据流的变换或计算来完成的包括通过计算和增加信息以丰富数据通过浓缩和删除以精简数据通过改变记录方式以转化数据和递增的转化数据构建为过滤器连接件是数据流传输的管道特点不适合处理交互式应用调用/返回风格主程序/子程序定义所有的计算构件作为子程序协作工作并由一个主程序顺序地调用这些子程序构件通过共享存储区交换数据。调用关系具有层次性其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性构件为主程序和子程序连接件是过程调用面向对象定义建立在数据抽象和面向对象的基础上数据的表示和它们的相应操作被封装起来。构件是对象对象是抽象数据类型的实例对象之间通过消息机制进行通信连接件是对象间的交付方式。层次结构定义每层为上层提供服务并使用下层提供的服务一般中间层只对相邻层可见。构件组成一个层次结构连接件通过层间交互的协议来定义。物联网属于层次型架构感知层负责信息采集和物物之间的信息传输实现对物理世界的智能感知识别、信息采集处理和自动控制包括传感器、执行器、RFID、二维码和智能装置网络层利用无线和有线网络对采集的数据进行编码、认证和传输利用无线和有线网络对采集的数据进行编码、认证和传输广泛覆盖的移动通信网络是实施物联网的基础设施应用层实现应用。提供丰富的基于物联网的应用物联网发展的根本目标将物联网技术与行业信息化需求相结合。独立构件风格进程通信定义构件通常是命名过程消息传递可以是点对点、异步或同步方式、以及远程过程调用等。构件是独立的进程连接件是消息传递事件驱动系统隐式调用定义构件不直接调用一个过程而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册当某个事件被触发系统自动调用在这个事件上注册的所有过程。构件是一些模块这些模块可以是过程或事件。连接件以过程之间的隐式调用来实现。优点增加架构灵活性缺点构件放弃对系统计算的控制共享数据问题C2Components and ConnectorsC2。C2体系结构风格可概括为通过连接件绑定在一起的按照一组规则运作的并行构件网络。主要用于网络化的软件应用中特别是那些需要清晰分层和松耦合的系统。两个基本元素Components构件代表系统中的一个模块或功能单元有自己的界面和内部状态可独立于其他构建件运行。Connectors连接件负责在构建件之间传递消息、数据或控制流定义构建件如何交互。系统组织规则系统中的构件和连接件都有一个顶部和一个底部构件的顶部应连接到某连接件的底部构件的底部则应连接到某连接件的顶部而构件与构件之间的直接连接是不允许的一个连接件可与任意数目的其他构件和连接件连接当两个连接件进行直接连接时必须由其中一个的底部到另一个的顶部。优点松耦合上层构件对下层构件不感知方便更新或替换下层构件高内聚构件之间通过消息交互相对独立可封装任意复杂度的构件至系统中易扩展构件只与上下层构件交互功能的修改最多只影响上下层不扩散影响可重用只要符合请求及响应标准即可重用构件支持异构系统集成松耦合适合集成异构系统和组件易于理解和实施清晰的分层和组件化设计使得系统易于理解和实施。缺点性能开销若业务处理涉及多个构件层次在系统执行过程中将存在性能损耗层次不清难以划分出合适且正确的层次结构有时由于需求需要跨层交互增加复杂性。分布式客户机/服务器系统开发时可采用不同的分布式计算架构分布式表示架构将表示层和表示逻辑层迁移到客户机应用逻辑层、数据处理层和数据层仍保留在服务器上分布式数据架构将数据层和数据处理层放置于服务器应用逻辑层、表示逻辑层和表示层放置于客户机分布式数据和应用架构将数据层和数据处理层放置在数据服务器上应用逻辑层放置在应用服务器上表示逻辑层和表示层放置在客户机上。实战黑板对于信号处理、语音识别、语音搜索、模式识别、知识推理等问题复杂、解空间很大、求解过程不确定的这一类软件系统通常会采用黑板架构风格以知识为中心进行分析与推理。黑板体系结构风格主要由三部分组成知识源知识源中包含独立的、与应用程序相关的知识知识源之间不直接进行通信它们之间的交互只通过黑板来完成黑板数据结构黑板数据是按照与应用程序相关的层次来组织的解决问题的数据知识源通过不断地改变黑板数据来解决问题控制控制完全由黑板的状态驱动黑板状态的改变决定使用的特定知识。管道-过滤器对于因数据而驱动数据到达某个构件经过内部处理产生数据输出的系统通常采用管道-过滤器体系结构风格。某公司拟为某种新型可编程机器人开发相应的编译器。编译过程包括词法分析、语法分析、语义分析和代码生成四个阶段每个阶段产生的结果作为下一个阶段的输入而且需要独立存储。采用管道-过滤器体系结构风格最为合适。解析在管道和过滤器软件体系结构中每个模块都有一组输入和一组输出。每个模块从它的输入端接收输入数据流在其内部经过处理后按照标准的顺序将结果数据流送到输出端以达到传递一组完整的计算结果实例的目的。最典型的应用是在编译系统。某软件开发公司负责开发一个Web服务器服务端处理软件其核心部分是对客户端请求消息的解析与处理包括HTTP报头分离、SOAP报文解析等功能。该公司的架构师决定采用成熟的架构风格指导整个软件的设计以下架构风格最适合该服务端处理软件。解析Web服务器服务端的核心功能是数据处理Web服务在数据传输方面具有协议分层的特征即底层协议会包装上层协议HTTP协议体中包含整个SOAP消息内容因此需要数据内容的逐步分解与分阶段处理。由于管道-过滤器的架构风格支持分阶段数据处理因此特别适合该服务端处理软件的要求。过程控制调温器需要实时获取外界的温度信息与用户定义的温度进行比较并做出动作。根据该系统的应用领域和实际需求是典型的过程控制架构风格的应用场景。某公司拟开发一个轿车巡航定速系统系统需要持续测量车辆当前的实时速度并根据设定的期望速度启动控制轿车的油门和刹车。采用过程控制架构风格最为合适。过程控制系统的特点是不断采集系统当前状态与系统中的设定状态进行对比并通过将当前状态与设定状态进行对比从而进行控制。事件驱动用户会注册自己的兴趣系统也会把新闻按兴趣分类如果某个新闻事件发生可通过事件来触发推送动作将新闻推送给对其感兴趣的用户。事件驱动系统应用场景。Windows操作系统在图形用户界面处理方面采用的是典型的事件驱动架构风格首先注册事件处理的是回调函数当某个界面事件发生时系统会查找并选择合适的回调函数处理该事件。隐式调用某公司欲开发一个基于图形用户界面的集成调试器该调试器的编辑器和变量监视器可以设置调试断点。当调试器在断点处暂停运行时编辑程序可以自动卷屏到断点变量监视器刷新变量数值。采用隐式调用的架构风格最为合适。回调机制。某公司欲开发一个漫步者机器人用来完成火星探测任务。机器人的控制者首先定义探测任务和任务之间的时序依赖性机器人接受任务后需要根据自身状态和外界环境进行动态调整最终自动完成任务。针对这些需求该机器人应该采用隐式调用架构风格最为合适。解析漫步者机器人需要根据自身状态和外界环境进行自动调整这是一个典型的根据外部事件进行响应的场景。解释器某企业内部现有的主要业务功能已封装成Web服务。为拓展业务范围需要将现有的业务功能进行多种组合形成新的业务功能。针对业务灵活组合这一要求采用解释器架构风格最为合适。公司欲开发一个大型多人即时战略游戏游戏设计的目标之一是能够支持玩家自行创建战役地图定义游戏对象的行为和对象之间的关系。针对该需求公司应该采用解释器架构风格最为合适。解析题目中提及支持玩家自行创建战役地图这说明系统要能应对自定义内容的解析这需要用到解释器风格。解释器是一个用来执行其他程序的程序解释器可针对不同的硬件平台实现一个虚拟机将高抽象层次的程序翻译为低抽象层次所能理解的指令以消除在程序语言与硬件之间存在的语义差异。作为一种体系结构风格解释器已经被广泛应用在从系统软件到应用软件的各个层面包括各类语言环境、Internet浏览器、数据分析与转换等LISPProlog、JavaScript、VBScript、HTML、Matlab、数据库系统SQL解释器、各种通信协议等。虚拟机Java是一种解释型语言在JVM上运行从架构风格上看是典型的虚拟机风格即通过虚拟机架构屏蔽不同的硬件环境。规则系统规则系统体系结构风格是一个使用模式匹配搜索来寻找规则并在正确的时候应用正确的逻辑知识的虚拟机其支持把频繁变化的业务逻辑抽取出来形成独立的规则库。这些规则可独立于软件系统而存在可被随时地更新。它提供一种将专家解决问题的知识与技巧进行编码的手段将知识表示为条件-行为规则当满足条件时触发相应的行为而不是将这些规则直接写在程序源代码中规则一般用类似于自然语言的形式书写无法被系统直接执行故而需要提供解释规则执行的解释器。如扫地机器人。基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存一般用在人工智能领域和DSSDecision Support Systems决策支持系统中。数据共享现代编译器主要关注编译过程和程序的中间表示围绕程序的各种形态进行转化与处理。这种情况下可以针对程序的各种形态构建数据库通过中心数据库进行转换与处理数据共享风格最符合要求。某公司为其研发的硬件产品设计实现一种特定的编程语言为了方便开发者进行软件开发公司拟开发一套针对该编程语言的集成开发环境包括代码编辑、语法高亮、代码编译、运行调试等功能。针对上述描述该集成开发环境应采用架构风格最为合适。答案数据仓储数据共享。解析现代编译器的集成开发环境一般采用数据仓储即以数据为中心的架构风格架构风格进行开发其中心数据就是程序的语法树。编译器早期的编译器采用管道-过滤器架构风格以文本形式输入的代码被逐步转化为各种形式最终生成可执行代码。大多数编译器在词法分析时创造独立的符号表在其后的阶段会不断修改符号表因此符号表并不是程序数据的一部分现代的编译器采用以数据共享为中心的架构风格主要关心编译过程中程序的中间表示分析树是在语法分析阶段结束后才产生作为语义分析的输入分析树是数据中心中重要的共享数据为后续的语义分析提供帮助。DSSA特定领域软件架构Domain Specific Software Architecture以一个特定问题领域为对象形成由领域参考模型、参考需求、参考架构等组成的开发基础架构其目标是支持一个特定领域中多个应用的生成。在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构。特定领域的架构可分为垂直域定义一个特定的系统族包含整个系统族内的多个系统结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构水平域定义在多个系统和多个系统族中功能区城的共有部分。在子系统级上涵盖多个系统族的特定部分功能。DSSA通常是一个具有三个层次的系统模型领域开发环境、领域特定应用开发环境和应用执行环境其中应用工程师主要在领域特定应用开发环境中工作。基本活动包括领域分析主要目的是获得领域模型。领域模型描述领域中系统之间共同的需求即领域需求领域设计主要目标是获得DSSADSSA描述领域模型中表示需求的解决方案领域实现主要目标是依据领域模型和DSSA开发和组织可重用信息并对基础软件架构进行实现。参与DSSA的人员可划分为4种角色领域专家提供关于领域中系统的需求规约和实现的知识领域分析者控制整个领域分析过程进行知识获取将获取的知识组织到领域模型中领域设计人员根据领域模型和现有系统开发出DSSA并对DSSA的准确性和一致性进行验证领域实现人员ABSD基于架构的软件开发Architecture Based Software Development强调由商业、质量和功能需求的组合驱动软件架构设计视角和视图来描述软件架构用例和质量属性场景Quality Attribute Scenario来描述需求。用例描述的是功能需求质量属性场景描述的是质量需求或侧重于非功能需求。ABSD方法有三个基础功能分解使用已有的基于模块的内聚和耦合技术通过选择体系架构风格来实现质量属性和商业需求采用软件模板设计软件结构ABSD方法主要包括6个主要活动架构需求架构设计架构文档化应该从使用者的角度进行书写针对不同背景的人员采用不同的书写方式并将文档分发给相关人员。架构文档要保持较新但不要随时保证文档最新要保持文档的稳定性。架构文档化的主要输出结果是架构规格说明书和架构质量说明书。架构复审目标是标识潜在的风险及早发现架构设计中的缺陷和错误架构实现架构演化针对用户的需求变化修改应用架构满足新的需求使用ABSD方法设计活动可以从项目总体功能框架明确就开始并且设计活动的开始并不意味着需求抽取和分析活动可以终止而是应该与设计活动并行。ABSD方法是一个自顶向下递归细化的过程软件系统的架构通过该方法得到细化直到能产生软件构件和类。架构设计、文档化和复审是一个迭代的过程。在一个主版本的软件架构分析之后要安排一次由外部人员用户代表和领域专家参加的复审。架构复审过程中通常会对一个可运行的最小化系统进行架构评估和测试。质量属性刻画质量属性的手段由六部分组成刺激源、刺激、环境、制品、响应、响应度量最常见的质量属性可用性Availability、可修改性Modifiability、性能Performance、安全性Security、可测试性Testability、易用性Usability。一种分类运行期质量属性开发期质量属性运行期质量属性性能指软件系统及时提供相应服务的能力。速度、吞吐量、持续高速性安全性指软件系统同时兼顾向合法用户提供服务以及阻止非授权使用的能力易用性指软件系统易于被使用的程度可伸缩性指当用户数和数据量增加时软件系统维持高服务质量的能力互操作性与其他系统交换数据和相互调用服务的难易程度可靠性在一定的时间内无故障运行的能力持续可用性指系统长时间无故障运行的能力。与可靠性相关联常将其纳入可靠性中鲁棒性是指软件系统在一些非正常情况如用户进行非法操作、相关的软硬件系统发生故障等下仍能够正常运行的能力。也称健壮性或容错性。开发期质量属性易理解性指设计被开发人员理解的难易程度可扩展性软件因适应需求变化而增加新功能的能力。也称为灵活性可重用性指重用软件系统或某一部分的难易程度可测试性对软件测试以证明其满足需求规范的难易程度可维护性当需要修改缺陷、增加功能、提高质量属性时定位修改点并实施修改的难易程度可移植性将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度可伸缩性和可扩展性可伸缩性Scalability指系统在保持性能稳定的前提下能通过增加资源计算或存储应对增长的需求应对高负载。例如水平扩展添加更多服务器或垂直扩展提高单个服务器的性能以处理更多的请求可扩展性Extensibility指系统在不影响现有系统结构和功能的前提下能较方便地添加新功能或模块应对业务需求。关注的是系统在未来变更需求下的灵活性。另一种分类软件质量特性包括6个方面每个方面都包含若干个子特性功能性适合性、准确性、互操作性、依从性、安全性可靠性成熟性、容错性、易恢复性易用性易理解性、易学性、易操作性效率时间特性、资源特性可维护性易分析性、易改变性、稳定性、易测试性可移植性适应性、易安装性、遵循性、易替换性软件质量属性通常需要采用特定的设计策略实现设计策略会对其他质量属性产生影响。改善提高软件质量属性的常见策略可用性可靠性错误检测命令/响应、心跳机制、Ping/Echo、异常监控错误恢复表决裁决表、主动冗余、被动冗余、备件备份、状态再同步、检查点/回滚、选举错误预防从服务中删除异常失效/失联节点、事务要么全成功要么全失败、定期重置、进程监视器安全性抵抗攻击对用户进行身份验证、对用户进行授权、维护数据的机密性、维护完整性、限制暴露的信息信息隐藏、限制访问检测攻击部署入侵检测系统、追踪审计被攻击后恢复恢复、识别攻击者可修改性局部化修改维持语义一致性、预期期望变更、泛化该模块、限制可能的选择、接口-实现分离防止连锁反应信息隐藏高内聚低耦合、维持现有的接口、限制通信路径、使用仲裁者推迟绑定时间运行时注册、配置文件、多态、构件更换性能资源需求减少处理时间所需的资源、减少所处理事件的数量、控制资源使用改善资源需求、限制执行时间、降低计算复杂度减少计算开销资源管理引入并发、维持数据或计算的多个副本、增加可用计算资源资源仲裁先进/先出、固定优先级、动态优先级调度、静态调度可测试性输入/输出记录/回放、将接口—实现分离、优化访问线路/接口内部监控当监视器处于激活状态时、记录事件SAAM基于场景的架构分析方法Scenarios-based Architecture Analysis Method。卡耐基梅隆大学软件工程研究所的Kazman等人于1983年提出的一种非功能质量属性的架构分析方法是最早形成文档并得到广泛应用的软件架构分析方法。其分析过程主要包括场景开发、体系结构架构描述、单个场景评估、场景交互和总体评估。场景在进行体系结构架构评估时一般首先要精确地得出具体的质量目标并以之作为判定该体系结构优劣的标准。为得出这些目标而采用的机制做场景。场景是从风险承担者的角度对与系统的交互的简短描述。在体系结构评估中一般从三方面来对场景进行描述stimulus刺激场景中解释或描述风险承担者怎样引发与系统的交互部分。如用户可能会激发某个功能维护可能会做某个更改测试人员可能会执行某种测试environment环境描述的是刺激发生时的情况。如当前系统处于什么状态有什么特殊约束条件系统负载是否很大某个网络通道是否出现阻塞等response响应指系统是如何通过体系结构对刺激作出反应的例如用户所要求的功能是否得到满足维护人员的修改是否成功测试人员的测试是否成功等SAAM的主要输入问题描述、需求说明和架构描述架构描述ANSI/IEEE 1471-2000是对软件密集系统的架构进行描述的标准。系统是为了达成利益相关人Stakeholder的某些使命Mission在特定环境Enviroment中构建的。每一个系统都有一个架构Architecture。架构是对所有利益相关人的关注点Concern的响应和回答通过架构描述Architecture Description来说明。每一个利益相关人都有各自的关注点。这些关注点是指对其重要的与系统的开发、运营或其他方面相关的利益。架构描述本质上是多视图的。每一个视图View是从一个特定的视角View Point来表述架构的某一个独立的方面。试图用一个单一的视图来覆盖所有的关注点当然是最好的但实际上这种表述方式将很难理解。视角的选择基于要解决哪些利益相关人的哪些关注点。它决定用来创建视图的语言、符号和模型等以及任何与创建视图相关的建模方法或分析技术。一个视图包括一个或多个架构模型Model一个模型也可能参与多个视图。模型较文本表述的好处在于可以更容易的可视化、检查、分析、管理和集成。视图主要用于描述软件架构模型ATAM架构权衡分析方法Architecture Tradeoff Analysis Method。主要关注系统的需求说明。该方法强调对软件的质量属性进行分析、分类和优先级排序等工作在此基础上构建质量属性效用树对质量属性描述进行刻画和排序并对风险点、非风险点、敏感点和权衡点进行识别和分析。ATAM要求在系统开发之前首先针对性能、可用性、安全性和可修改性等质量属性进行评价和折中。在SAAM基础之上发展起来的一种系统架构评估方法主要对软件体系结构的设计结果进行评估。评估是软件系统详细设计、实现和测试之前的阶段工作因此评估不涉及系统的实现代码和测试因为评估是考査软件体系结构是否能够合适地解决软件系统的需求并不对软件需求自身是否准确进行核实而软件需求是否准确是需求评审阶段的工作。不是一种精确的评估方法主要形式是评审会议。整个评估过程强调以属性作为架构评估的核心概念。主要包括场景和需求收集、架构视图和场景实现、属性模型构造和分析、属性模型架构决策与折中等4个阶段。效用树从根部到叶子节点依次是树根、质量属性、属性分类、质量属性场景。特定目标是在考虑多个相互影响的质量属性的情况下从原则上提供一种理解软件体系结构的能力的方法。对于特定的软件体系结构在系统开发之前可使用ATAM确定在多个质量属性之间折中的必要性质量属性ATAM分析多个相互竞争的质量属性。考虑系统的可修改性、安全性、性能和可用性风险承担者在场景、需求收集有关的活动中ATAM需要所有系统相关人员的参与体系结构描述体系结构空间受到历史遗留系统、互操作性和以前失败的项目约束。在五个基本结构的基础上进行体系结构描述这五个结构是从Kruchten的41视图派生而来的。其中逻辑视图被分为功能结构和代码结构。这些结构加上它们之间适当的映射可以完整地描述─个体系结构。4点识别风险、非风险、敏感点和权衡点是进行软件架构评估的重要过程风险点是某个存在问题的架构设计决策可能会导致问题。非风险与风险相对是良好的架构设计决策。风险点与非风险点不是以标准专业术语形式出现的只是一个常规概念即可能引起风险的因素可称为风险点。敏感点是一个或多个构件和/或构件之间的关系的特性。研究敏感点可使设计入员或分析员明确在搞清楚如何实现质量目标时应注意什么。敏感点是实现一个特定质量属性的关键特征该特征为一个或多个软件构件所共有。权衡点是影响多个质量属性的特性是多个质量属性的敏感点。权衡点是影响一个或多个质量属性的特性是多个质量属性的敏感点。例如改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性但可能要耗费更多的处理时间影响系统性能。如果某个机密消息的处理有严格的时间延迟要求则加密级别可能就会成为一个权衡点。【改变业务数据编码方式会对系统的性能和安全性产生影响】是对权衡点的描述【改变加密的级别可能会对安全性和性能都产生显著的影响】是对系统权衡点的描述【假设用户请求的频率为每秒1个业务处理时间小于30毫秒则将请求响应时间设定为1秒钟是可以接受的】是对非风险的描述【系统需要支持的最大并发用户数量直接影响传输协议和数据格式】描述敏感点参考软考高级试题及解析