东南大学 软件系统设计与体系结构 复习

东南大学软件系统设计与体系结构复习第一章：概述1、软件危机2、软件架构的作用：软件架构在高级层次上对软件进行描述，便于软件开发过程中各个视角的统一，能够及早发现开发中的问题并支持各种解决方案的评估和预测3、什么是软件架构？软件架构是一个软件系统的设计图，并不仅限于软件系统的总体结构，还包含一些质量属性以及功能和结构之间的映射关系，即设计决策。4、软件架构的两个主要焦点：系统的总体结构、需求和实现之间的对应。5、*软件架构的主要思想：将注意力集中在系统总体结构的组织上。6、软件架构的实现的手段：运用抽象方法屏蔽错综复杂的模块间连接，使人们的认知提升并保持在整体结构的部件“交互”层次；进一步将交互从计算中分离出来，建立“组件+连接件+配置”的软件系统高层结构组织方式。7、*软件架构的特征：特征实现方式柞用桂蛍可萤用性组件麼架梢级莹用提高软件质量利益相关者较多满足各刑益相关者需求平衡需求关注点分离分而治之、模块化简化复杂性质屋驱动使用软件架构乘■处理质量屈性需求、控制超杂性由功能、数据嶽駆动何质tft驱动转变概念完整性强调设计決策杲一个持续的过程毎个决建都翌在其前面设计决壊的基础上进疔循坏风格架构凤洛、架构模武用标准方法来处理反复出现的问题（1）注重可重用性——组件及架构级重用（2）利益相关者较多——平衡需求（3）关注点分离——模块化、分而治之（4）质量驱动——关注非功能属性（5）提倡概念完整性——强调设计决策是一个持续的过程（6）循环风格——用标准方法来处理反复出现的问题8、软件架构的发展阶段（1）基础研究阶段（1968-1994）：提出“软件架构”，开始尝试模块化的实践（2）概念体系和核心技术形成阶段（1991-2000）：软件架构作为一个独立的领域出现；软件架构核心技术的发展；软件组件技术（3）理论体系丰富发展阶段（1996-1999）（4）理论完善和普及应用阶段（1999至今）第二章：软件架构定义1、*组成派定义依据：软件架构主要反映系统是由哪些部分组成的，以及这些部分是如何组成的，强调软件系统的整体结构和配置。软件架构二｛元素，组成，原理｝架构元素：具有一定形式的结构化元素，包括处理元素、数据元素和连接元素架构组成：由加权的属性和关系构成。属性用来约束架构元素的选择，关系用来约束架构元素的放置。架构原理：捕获在选择架构风格、架构元素和架构形式的选择动机软件架构包括组件、连接件和约束三大要素。组件：可以是一组代码，也可以是独立的程序连接件：过程调用、管道和消息等，用于表示组件之间的相互关系约束：一般为组件连接时的条件软件架构是某一系统的基本组织结构，其内容包括软件组件、组件间的联系、组件与其环境间的联系，以及指导上述内容设计和演化的原理。2、*决策派定义依据：软件架构设计是软件设计的一部分，软件设计实际上是开发人员意志和决策在软件开发过程中的体现，软件架构更是高层领导和架构师意志和决策的体现，强调设计决策，更加注重架构风格和模式的选择。软件架构是一系列重要决策的集合,这些决策关于：软件系统的组织；组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；如何组合这些元素，使它们逐渐合成为更大的子系统；架构风格；这些元素以及它们的接口、协作和组合。软件架构是架构层次上所有设计决策的集合体,这些设计决策与以下内容有关：架构改造的影响、原理、设计准则、设计约束以及附加需求。软件架构是“设计决策+设计”，这里的设计是指设计决策的推理过程。3、组成拍和决策派的区别：组成派关注于软件本身，将软件架构看作组件和交互的集合；决策派关注于软件架构中的实体（人），将软件架构视为一系列重要设计决策的集合。（可以再把两者的定义依据答一下）4、*参考定义框架（一般性定义）：软件架构由：组件、连接件、配置、端口和角色五种元素组成。组件：具有某种功能的可重用的软件模块单元，表示了系统中主要的计算单元和数据存储。组件有两种：复合组件和原子组件。复合组件由其他复合组件和原子组件通过连接而成。连接件：表示了组件之间的交互。配置：表示了组件和连接件的拓扑逻辑和约束。端口：组件作为一个封装的实体，只能通过其接口与外部交互，组件的接口由一组端口组成，每个端口表示了组件和外部环境的交汇点。角色：连接件作为建模软件体系结构的主要是提，同样也有接口，连接件的接口由一组角色组成，连接件的每个角色定义了该连接件表示的交互的参与者。第三章：软件架构模型1、软件架构模型：对架构设计决策的具象化和文档化。2、软件架构模型的意义（为什么要有软件架构模型？）：软件架构模型能够将软件架构某些关键或关注的方面剥离出来，使用统一的图形、文档和数据进行描述，达到直观、便捷地理解、分析和交流。3、*软件架构建模的五类方法：基于非规范的图形表示的建模方法基于UML的建模方法各个图分别对系统的哪些方面进行了建模？用例图从概念上描述了系统的逻辑功能；类图反映了架构中的静态关系；顺序图反映了系统的同步和并行逻辑；活动图表现了一定的并发行为；组件图反映了系统的逻辑结构；部署图描述了物理资源的分布情况。4+1view：逻辑视图：关注功能，可以采用UML用例图来实现开发视图：关注软件的静态组织结构，使用UML的类图、对象图和组件图来表示模块，用包来表示子系统，利用连接表示模块和子系统之间的关联。过程视图：关注软件的流程特征，可以采用UML的状态图、顺序图和活动图来实现。物理视图：关注功能单元的分布状况，可以使用UML的配置图来实现场景试图：关注用户需求，可以使用用例或场景来描述。基于形式化的建模方法基本思想：利用一些已知特性的数学抽象来为目标软件系统的状态特征和行为特征构造模型。基于UML形式化的建模方法基本思想：利用形式化与UML结合的建模方法研究成果，对UML图形赋予形式化语义，然后就可以利用已有的形式化语言和工具对UML模型进行推理验证。其他建模方法：文本语言建模方法、模型驱动的架构建模方法4、*软件架构建模方法的发展趋势：第一层次：文本模型从原始的自然语言文档化到以XML为代表的由固定规范、结构的文档化。第二层次：图形可视化模型（什么是可视化？）将软件架构按照图形的方式进行表达，需要便于涉众阅读、理解和交流，使之不会因图形过于复杂而难以把握软件架构的概况。第三层次：UML模型使用单一的集成的表示法来对系统的多个方面进行建模，模型范畴包括从系统的静态结构到动态行为特征、从系统的逻辑功能到物理部署。第四层次：形式化模型（什么是形式化？）面向模型的方法，利用一些已知特性的数学抽象来为目标软件系统的状态特征和行为特征构造模型。代数方法，它为目标软件系统的规格说明提供了一种特殊的机制，包括描述抽象概念并进行进程联接和推理的方法。第五层次：未来模型只是一种设想，需要前四层技术都发展到相当成熟的阶段。只有将各个层次的先进技术结合在一起，才能建立完备、精确的模型，才能利用模型直接生成全部代码。第四章：软件架构风格1、什么是软件架构风格？软件架构风格又称软件架构惯用模式，是描述某一特定应用领域中系统组织方式的惯用模式，作为“可复用的组织模式和习语”，为设计人员的交流提供了公共的术语空间，促进了设计复用与代码复用。2、使用架构风格的好处：可以极大地促进设计的重用性和代码的重用性，并且使得系统的组织结构易被理解。使用标准的架构风格可较好地支持系统内的互操作性以及针对特定风格的分析。***********经典的软件架构风格**********1、管道过滤器风格（1）特点：在管道过滤器风格下，每个功能模块都有一组输入和输出。功能模块称作过滤器；功能模块间的连接可以看作输入、输出数据流之间的通路，称作管道。管道-过滤器风格的特性之一在于过滤器的相对独立性，即过滤器独立完成自身功能，相互之间无需状态交互。从解耦的角度：每个过滤器之间都是解耦的，每个过滤器都专注于自己的职责。过滤器是独立运行的组件；过滤器对其处理上下连接的过滤器“无知”；结果的正确性不依赖于各个过滤器运行的先后次序。（解耦的好处）解耦能够保持组件之间的自主和独立。它的直接结果就是改动成本低，维护成本低，可读性高。（2）优点：由于每个组件行为不受其他组件的影响，整个系统的行为易于理解。管道-过滤器风格支持功能模块的复用。（任何两个过滤器，只要它们之间传送的数据遵守相同的规约，就可以相连接。）基于管道-过滤器风格的系统具有较强的可维护性和可扩展性。支持一些特定的分析，如吞吐量计算和死锁检测等。（3）缺点：管道-过滤器风格往往导致系统处理过程的成批操作。根据实际设计的需要，设计者需要对数据传输进行特定的处理（如加密），导致过滤器必须对输入、输出管道中的数据流进行解析和反解析，增加了过滤器具体实现的复杂性。交互式处理能力弱。（4）实例：传统的编译器，一个阶段的输入是另一个阶段的输出。Unix和DOS中的管道操作符‘|':将符号‘|'之前的命令的输出作为‘|’之后命令的输入。2、事件驱动风格（1）基本思想：不直接调用一个过程，而是发布或广播一个或多个事件。系统中的其它组件通过注册与一个事件关联起来的过程，来表示对某一个事件感兴趣。当这个事件发生时，系统本身会调用所有注册了这个事件的过程。这样一个事件的激发会导致其它模块中过程的隐式调用。（2）从解耦的角度：系统组件松耦合。在系统执行的过程中，可以并行处理不可预期的事件发生。观察者模式：让多个观察者对象同时监听某一主题对象，当该对象状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。特点：事件发布者不知道哪些组件会受到事件的影响；组件不能对事件的处理顺序，或者事件发生后的处理结果做任何假设。从架构上来说，事件驱动系统的组件提供了一个过程集合和一组事件。过程可以使用显示的方法进行调用，也可以由组件在系统事件中注册。当触发事件时,会自动引发这些过程的调用。连接件既可以是显示过程调用，也可以是一种绑定事件声明和过程调用的手段。优点：事件声明者不需要知道哪些组件会影响事件，组件之间关联较弱。提高软件复用能力。只要在系统事件中注册组件的过程，就可以将该组件集成到系统中。系统便于升级。只要组件名和事件中所注册的过程名保持不变，原有组件就可以被新组件替代。缺点：组件放弃了对计算的控制权，完全由系统来决定。存在数据交换问题。该风格中，正确性验证成为一个问题。3、黑板风格特点：黑板系统是传统上被用于信号处理方面进行复杂解释的应用程序，以及松散耦合的组件访问共享数据的应用程序。黑板架构实现的基本出发点是已经存在一个对公共数据结构进行协同操作的独立程序集合。黑板系统的命于它反映的是一种信息共享系统——如同教室的黑板一样，有多个人读,也有多个人写。数据驱动或状态驱动的控制机制。系统在运行时，每当有新输入、新结果和新状态写入黑板时，中心控制组件就对黑板上的信息进行评价，并据此协调各专门程序进行工作。组成部分：知识源、黑板数据结构、控制器。优点：便于多客户共享大量数据，他们不关心数据何时有的、谁提供的、怎样提供的。既便于添加新的作为知识源代理的应用程序，也便于扩展共享的黑板数据结构。知识源可重用。支持容错性和健壮性。缺点：不同的知识源代理对于共享数据结构要达成一致，而且，这也造成对黑板数据结构的修改较为困难——要考虑到各个代理的调用。需要一定的同步/加锁机制保证数据结构的完整性和一致性，增大了系统复杂度。4、C2风格特点：是一种层次体系架构风格。C2架构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行组件网络。该规则规定了所有组件之间的交互必须通过异步消息机制来实现C2是一种基于组件和消息的架构风格，适用于GUI软件开发，构建灵活和可扩展的应用系统。(如游戏)C2架构的内部，通信和处理是分开完成的。优点：可使用任何编程语言开发组件，组件重用和替换易实现；由于组件之间相对独立，依赖较小，因而该风格具有一定扩展能力，可支持不同粒度的组件；组件不需共享地址空间；可实现多个用户和多个系统之间的交互；可使用多个工具集和多种媒体类型，动态更新系统框架结构。缺点：不太适合大规模流式风格系统，以及对数据库使用比较频繁的使用。5、客户机/服务器风格特点：主要针对资源不对等问题而提出的一种共享策略。客户机和服务器是两个相互独立的逻辑系统，为了完成特定的任务而形成一种协作关系。一般的，客户机为完成特定的工作向服务器发出请求；服务器处理客户机的请求并返回结果。客户机程序和服务器程序配置在同一台计算机上时：采用消息、共享存储区和信号量等方法实现通信连接。客户机程序和服务器程序配置在分布式环境中时：通过远程调用(RemoteProduceCall，RPC)协议来进行通信。两层C/S架构：组成：客户机、数据库服务器优点：客户机组件和服务器组件分别运行在不同的计算机上，有利于分布式数据的组织和处理。组件之间的位置是相互透明的客户机程序和服务器程序可运行在不同的操作系统上，便于实现异构环境和多种不同开发技术的融合。软件环境和硬件环境的配置具有极大的灵活性，易于系统功能的扩展。将大规模的业务逻辑分布到多个通过网络连接的低成本的计算机上，降低了系统的整体开销。缺点：开发成本较高(客户机的软硬件要求高)。客户机程序的设计复杂度大，客户机负荷重。信息内容和形式单一。C/S架构升级需要开发人员到现场更新客户机程序，对运行环境进行重新配置，增加了维护费用。两层C/S结构采用了单一的服务器，同时以局域网为中心，难以扩展到Internet。数据安全性不高。(3)三层C/S架构组成：客户机、应用服务器、数据库服务器相比于两层C/S架构的优点：合理地划分三层结构的功能，可以使系统的逻辑结构更加清晰，提高软件的可维护性和可扩充性。在实现三层C/S架构时，可以更有效地选择运行平台和硬件环境，从而使每一层都具有清晰的逻辑结构、良好的负荷处理能力和较好的开放性。在C/S架构中，可以分别选择合适的编程语言并行开发。系统具有较高的安全性。使用时需要注意的问题：如果各层之间的通信效率不高，即使每一层的硬件配置都很高，系统的整体性能也不会太高。必须慎重考虑三层之间的通信方法、通信频率和传输数据量，这和提高各层的独立性一样也是实现三层C/S架构的关键性问题。6、浏览器/服务器风格特点：组成：浏览器，Web服务器、数据库服务器与三层C/S结构的解决方案相比，/S架构在客户机上采用了WWW浏览器，将Web服务器作为应用服务器。B/S架构核心是Web服务器，数据请求、网页生成、数据库访问和应用程序执行全部由Web服务器来完成。在B/S架构中，系统安装、修改和维护全在服务器端解决，客户端无任何业务逻辑。优点客户端只需要安装浏览器，操作简单，能够发布动态信息和静态信息。运用HTTP标准协议和统一客户端软件，能够实现跨平台通信。开发成本比较低，只需要维护Web服务器程序和中心数据库。客户端升级可以通过升级浏览器来实现。缺点个性化程度比较低，所有客户端程序的功能都是一样的。客户端数据处理能力比较差，加重了Web服务器的工作负担，影响系统的整体性能。在B/S架构中，数据提交一般以页面为单位，动态交互性不强，不利于在线事物处理。B/S架构的可扩展性比较差，系统安全性难以保障。B/S架构的应用系统查询中心数据库，其速度要远低于C/S架构。7、面向服务架构风格SOA（1）特点：SOA是一个组件模型，它将应用程序的不同功能单元（服务）通过这些服务之间定义良好的接口和契约联系起来。基本过程：发布（发布到服务注册中心）-＞发现-＞绑定和调用面向服务软件架构风格在于具有基于标准、松散耦合、共享服务和粗粒度等优势，表现为易于集成现有系统、具有标准化的架构、提升开发效率、降低开发维护复杂度等。通过采用SOA架构，在进行一次开发成本急剧减少的同时，由于系统具有松散耦合的特征使得维护成本也大大减少。（2）优点：灵活性，根据需求变化，重新编排服务。对IT资产的复用。使企业的信息化建设真正以业务为核心。业务人员根据需求编排服务，而不必考虑技术细节。（3）缺点：服务的划分很困难。服务的编排是否得当。如果选择的接口标准有问题，如主流的Webservice之类，会带来系统的额外开销和不稳定性。对IT硬件资产还谈不上复用。目前主流实现方式接口很多，很难统一。目前主流实现方式只局限于不带界面的服务的共享。8、模型-视图-控制器风格（MVC）（1）特点：主要是针对编程语言Smalltalk80所提出的一种软件设计模式。MVC被广泛的应用于用户交互程序的设计中。MVC结构主要包括模型、视图和控制器三部分。模型（Model,M）:模型是应用程序的核心，它封装了问题的核心数据、逻辑关系和计算功能，提供了处理问题的操作过程。视图（View,V）:视图是模型的表示，提供了交互界面，为用户显示模型信息。控制器（Controller,C）：控制器负责处理用户与系统之间的交互，为用户提供操作接口。（2）优点:多个视图与一个模型相对应。变化——传播机制确保了所有相关视图都能够及时地获取模型变化信息，从而使所有视图和控制器同步，便于维护。具有良好的移植性。由于模型独立于视图，因此可以方便的实现不同部分的移植。系统被分割为三个独立的部分，当功能发生变化时，改变其中的一个部分就能满足要求。（3）缺点:增加了系统设计和运行复杂性。视图与控制器连接过于紧密，妨碍了二者的独立重用。视图访问模型的效率比较低。由于模型具有不同的操作接口，因此视图需要多次访问模型才能获得足够的数据。频繁访问未变化的数据，也将降低系统的性能。第六章：软件架构与敏捷开发1、*敏捷开发的基本理念：强调个体和互动比强调过程和工具更好强调获得可运行的软件比强调完成详尽的文档好强调与客户合作比强调进行详细的合同谈判好强调响应变化比强调遵循既定的计划好2、*敏捷开发与架构设计的关系软件架构与敏捷开发的出发点是一致的。都是一个权衡的过程目的都是为了提高软件开发效率、提高软件质量、降低软件成本，将开发团队的价值最大化。敏捷开发也需要重视软件架构。两者在软件开发实践中能够共同存在,且互相促进。敏捷开发改变了软件架构的设计方式。重视软件的架构设计，但是轻架构的详细设计。将传统的架构设计分成：种子架构设计+详细架构设计。3、*敏捷开发中如何改变了软件架构的设计方式？敏捷开发重视软件的架构设计，但是轻架构的详细设计。将传统的架构设计分成：种子架构设计+详细架构设计。种子架构设计关注软件系统的骨架或轮廓的设计。把传统软件开发前期的详细架构设计分散到了整个敏捷开发软件过程中，以达到提高效率、减少风险的目的。敏捷开发中详细设计的原则：重要、关键的设计决策必须在软件开发前确定，对于其他详细的设计决策，则需要时再做。开发过程中，所有的利益相关者都必须全程在一起，便于充分的交流和权衡。将需求文档化，重视需求，明确表示出不同需求之间的权衡过程。开发人员要及时的验证架构。如果必须要进行修改，改动越早越好。不要突发奇想的修改架构，修改架构需要大家一起深思熟虑。4、敏捷开发在实践中表现为一种迭代、增量和持续集成的开发方法。◦迭代反映了项目的开发节奏，是一个多周期的开发过程。◦增量说明了项目的实际进展，整个项目就是由很多增量构成的。◦持续集成反映了集成增量的过程是持续进行的。5、敏捷开发的设计理念：团体设计（群体决策，全部人员参与）、简单设计（表达形式的简单化和现实抽象的简单化）6、优秀的敏捷软件架构的设计过程一般同时包含规划式设计和演进式设计，具体体现为初始阶段设计和迭代过程中的设计。第七章：架构驱动的软件开发1、*架构驱动的软件开发步骤和开发流程架构需求获取架构的需求源于：系统的质量目标、系统的业务目标、软件的利益相关者。架构设计、文档化和评估是一个迭代过程也是架构驱动的软件开发的核心所在。基本架构设计通过获得的架构需求信息，架构师对架构进行设计并通过文档进行记录。架构记录文档化软件系统架构结构的唯一体现方式。旨在方便程序员和分析师的工作。它可以加强软件系统的利益相关者之间的联系，从而确定出满足需求的软件架构。架构评估评估的目的是分析架构以识别潜在风险并验证设计中已经满足的质量需求。架构实现架构维护2、*质量场景抽象场景：根据软件的使用进行一定层面的分类（如：软件流水线方式、三层结构等），这些分类就会对相应软件提出一定的需求，此类需求即为架构需求的抽象场景。对于架构师和领域专家来说，需要做的是从抽象场景描述中获得特定的质量属性场景。组成：源、触发、环境、制品、响应、响应测试、完整的质量场景描述的对象：架构需求应用：①在架构需求获取步骤中用来描述架构需求作为基本架构设计的依据和目标在架构评估时根据质量场景来验证架构是否满足质量需求第八章：软件架构设计和实现1、*成功的软件架构应具有的品质：（1）良好的模块化（2）适应功能需求的变化，适应技术的变化（3）对系统的动态运行有良好的规划（4）对数据的良好规划（5）明确、灵活的部署规划2、*架构设计原则：软件架构设计原则有一般设计原则和关键设计原则两类。一般原则：包含商业原则、数据原则、应用程序原则、技术原则等；关键设计原则：关注分离点、单一职责原则、最少知识原则等。3、*将软件架构的概念和原则引入软件需求阶段有什么好处？不引入可能会引起什么问题？用传统的方法产生需求规约，不考虑软件架构概念和原则，则在软件架构设计阶段建立需规约与架构的映射将相对困难。若把架构概念引入需求分析阶段，有助于保证需求规约、系统设计之间的可追踪性和一致性，有效保持软件质量。将软件架构概念和原则引入需求分析,也可以让我们获得更有结构性和可重用的需求规约。4、*软件架构和软件需求是如何共同演化的？软件需求和软件架构两者是相辅相成的关系，一方面软件需求影响软件架构设计，另一方面软件架构帮助需求分析的明确和细化。需求与架构的互相影响可以看成一个螺旋的过程，也是一个双峰的过程。5、*将软件架构映射到详细设计经常遇到什么问题？如何解决？（1）缺失重要架构视图，片面强调功能需求。（针对遗漏的架构视图进行设计。）（2）不够深入，架构设计方案过于笼统，基本还停留在概念性架构的层面，没有提供明确的技术蓝图。（将设计决策细化到和技术相关的层面。）（3）名不副实的分层架构，缺失层次之间的交互接口和交互机制，只进行职责划分。（步步深入，明确各层之间的交互接口和交互机制。）（4）在某些方面过度设计。（虽然我们必须考虑到系统的扩展性，可维护性等，但切忌过度设计。）6、*MDA的基本思想：将软件系统分成模型和实现两部分：模型是对系统的描述，实现是利用特定技术在特定平台或环境中对模型的解释。模型仅仅负责对系统的描述，与实现技术无关。这是模型的实现技术无关性。*应用MDA的好处？将模型与实现分离后，能够很好的适应技术易变性。由于实现往往高度依赖特定技术和特定平台，当技术发生迁移时，只需针对这种技术作相应的实现，编写相应的运行平台或变换工具。所以，能够比较好的应对实现技术发展带来的挑战。第十五章：软件体系结构评估1、软件架构评估的必要性：体系结构评估可以减少后期的测试和纠错的开销评估是挖掘隐性需求并将其补充到设计的最后机会体系结构是开发过程的中心，不良的体系结构会带来一蹋糊涂的效果。2、软件架构评估的方式分类：基于调查问卷或检查表的评估方式基于场景的评估方式◦基于度量的评估方式3、*质量属性：1）可修改性：度量软件系统变化的成本。变化包括功能扩展、容量扩展、结构更新等。2）可用性：是指软件能够正常运行的时间比例。可用性二平均工作时间/（平均工作时间+平均修复时间）3）性能：性能表征软件系统的响应速度或者由响应速度决定的其它度量。4）可测试性：可测试性表明软件系统在多大程度上容易被测试检查出缺陷。5）易用性：易用性表明软件系统完成后用户的体验和效率。6）安全性：安全性代表软件对未授权和非法操作的防卫能力。4、*体系结构权衡分析方法（ATAM）（1）相关概念①敏感点和权衡点：敏感点：敏感点是一个或多个构件的特征。敏感点可以使设计师搞清楚实现质量目标时应该注意什么。权衡点：权衡点是影响多个质量属性的特征。是多个质量属性的敏感点。权衡点需要进行权衡。敏感点影响一个质量属性；权衡点影响多个质量属性。敏感点是实现一个特定质量属性的关键特征，该特征为一个或多个软件构件所共有。“改变加密的级别可能会对安全性和性能都产生显著的影响”，这是一个对系统权衡点的描述。风险承担者、涉众、涉及到的人：体系结构设计师开发人员维护人员集成人员测试人员标准专家性能工程师质量场景：概念：在进行体系结构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。我们把为得出这些目标而采用的机制叫做场景。场景是从风险承担者的角度对与系统的交互的简短描述。•组成：一般采用刺激、环境和响应三方面来对场景进行描述。刺激是场景中解释或描述风险承担者怎样引发与系统的交互部分。环境描述的是刺激发生时的情况。响应是指系统是如何通过体系结构对刺激作出反应的。•描述的对象：架构需求•应用：①在架构需求获取步骤中用来描述架构需求作为基本架构设计的依据和目标在架构评估时根据质量场景来验证架构是否满足质量需求（2）评估过程：一个完整的ATAM通常会花费三个整天，其中每天都要进行如下三个过程：场景提出、架构提出和将场景映射到架构上，分析。ATAM主要部分包括4组，共9个步骤：1）陈述，包括通过它进行的信息交流ATAM方法的陈述：评估负责人商业动机的陈述：项目经理或系统客户SA的陈述：系统设计人员2）调查与分析，