在本文中，对软件体系结构评估的最新技术进行了小规模的研究，目的是提供有关该主题的一般全景。它涵盖以下主题：什么是评估？评估架构的目标是什么？为什么要评估架构？什么时候评估架构？它们有什么特点？谁参与体系结构评估？以及评估体系结构时使用的技术，对一些现有评估方法的简要分析和LISI（系统研究实验室）的评估建议西蒙·玻利瓦尔大学）。
介绍
软件体系结构是一种年轻的实践，仅需几年的不懈努力。它起源于1960年代，但直到1990年代，Dewayne Perry和Alexander Wolf才以今天所知的意义揭露它。正如Perry和Wolf所预言的那样，这十年被视为软件体系结构的十年。从这一刻起，软件架构在学术界和工业界都开始令人眼花developing乱，发展了建筑风格的ADL（建筑描述豆类），尽管在今天这仍然有些处女，其中。所有这些都破坏了不同类型架构的创建，例如基于组件的架构。
要构建的软件系统的软件体系结构成为实现高质量水平的重要因素。请记住，拥有一个良好的软件体系结构至关重要，因为这是任何计算机系统的核心，它决定了与系统相关的质量等级（1）。
在不满足客户端非功能性要求中指定的质量属性的系统中，没有任何用处。因此，设计正确的体系结构将决定软件系统的成败与否，只要达到或不满足其目标（4）。因此，“为减少此类风险，并作为良好的工程实践，建议进行建筑评估”（4）。
本文介绍了对软件体系结构进行概念验证（评估体系结构）的过程，着重强调了为什么需要这样做，它提供了哪些好处，并着重介绍了一些现有的评估方法以及其中哪些是评估方法。提出。在这种情况下，MECABIC（基于组件集成的体系结构质量评估方法）的主要目标是评估和分析此类软件体系结构的质量。该方法是由西蒙·玻利瓦尔大学的AleksanderGonzález，MarizéMijares，Luis E.Mendoza，AnnaGrimán，MaríaPérez，LISI（信息系统研究实验室）提出的。
本文准备工作所追求的总体目标是提出一种评估面向服务的软件体系结构的过程。
在ERP体系结构中实现它。
本文追求的具体目标是：
- 进行软件体系结构评估最新技术的研究分析并确定现有的用于评估软件体系结构的不同方法或过程的潜力。系统的非功能性需求。
本文分为两章：
在第一章中，对概念证明的最新技术进行了研究，概述了与该主题有关的理论方面。还详细介绍了一些方法或过程，它们的特点是它们之间的简要比较。
在第2章中，提出了一种建议的评估方法，该评估方法强调了架构方面，例如评估工具和技术，参与者以及开发该评估工具的每个阶段的步骤。
本文档的范围是介绍体系结构评估的一般概述，并建议将提出的方法应用于公司正在开发的资源计划系统ERP（企业资源计划）的模块的体系结构。第三系与信息科学大学的其他系一起。
概念框架
软件体系结构：根据IEEE标准（电气与电子工程师协会）：“软件体系结构是系统的基本组织，该系统体现在其组件，组件与环境之间的关系以及指导其设计和发展的原则上。 “（一个）。
软件质量：软件质量是“与明确记录的开发标准所建立的功能和性能要求以及所有专业开发的软件所期望的隐含特性相一致”（1）。
组件： “它是一个清晰可识别的软件体系结构的一部分，与使用它的应用程序和其他组件（部分）无关，后者在体系结构的上下文中描述并执行特定而清晰的功能，可以在修改过程中对其进行修改该设计具有清晰的文档，可以了解其特性，属性和行为，可重用性以及与其他组件（部件）的互操作性，而不会降低体系结构的效率”（1）。
场景：场景包括三个部分：激励，上下文和响应。刺激是场景的一部分，它解释或描述了开发人员参与与系统交互的行为。它可以包括任务执行，系统更改，测试执行，配置等。上下文描述了刺激时刻系统中发生的情况。响应通过体系结构描述了系统应如何响应刺激。最后一个元素是允许确定哪个元素是关联的质量属性（2）。 “这些场景描述了系统的预期使用或期望使用，通常用一句话表示”（3）。 “它们代表了系统最重要需求的抽象”（3）。
利益相关者：以某种方式与系统相关的人员，无论是开发人员，用户还是经理等。
第1章。研究现状
介绍
在本章中，将对软件体系结构评估中的最新技术进行研究。对此主题进行介绍时，将处理诸如体系结构在项目中引起的主要问题之类的方面，并且还定义了它是对体系结构，其特征和所追求的目标的评估。还分析了何时以及为什么应该评估某种体系结构及其带来的好处。
目标
- 提供有关体系结构评估的重要性和含义的信息，分析并确定评估软件体系结构的各种方法或过程的潜力。
我们如何确定它是体系结构的一部分？
它必须是组件（元素），组件之间的关系或需要在外部可见的属性，以便推断系统满足其质量要求的能力，或支持将系统分解为可独立实施的部分（二）。
由体系结构引起的项目中的主要问题（5）：
- 它不能满足必要的质量，不能尝试支持业务需求，用户对项目完成的承诺不足（通信问题）。
- 落后的项目中有50％的建筑存在问题，超过建造成本的项目中有35％的建筑存在问题。
什么是评估？
- 这是一项可行性研究，旨在发现可能的风险并寻求控制建议的风险（5）评估与验证之间的区别在于，评估是在解决方案实施之前进行的。验证已使用已构建的产品（5）。
评估架构的目标
评估架构的目的是要知道架构是否可以满足需求，质量属性和限制，以确保要构建的系统满足涉众的需求（5）。
评估软件体系结构是一项艰巨的任务，因为它旨在基于抽象规范（例如体系结构设计）来测量系统属性。因此，目的是评估为实现所需质量属性而设计的体系结构的潜力。根据架构师发现自己的情况以及他使用的技术的适用性，对软件体系结构进行的测量可以具有不同的目标。其中一些目标是：定性，定量和理论上的最大值和最小值（2）。
- 的定性测定被应用于候选体系结构之间的比较并且与知道选项最适合特定质量属性的意图。这种类型的测量提供了肯定或否定的答案，detalle.La更高的水平定量测量寻求获得允许对软件架构的质量属性进行决策的价值。通用方案是与已建立的边距进行比较（如性能要求的情况），以建立对候选体系结构的遵从程度或做出决策。这种方法可以进行比较，但是在最大理论值和已知的最小测量值之间都是比较有限的。La 测量最大和最小理论值为了将测量与指定的质量属性进行比较，它考虑了理论值。知道最大或最小值可以清楚地确定质量属性的实现程度。
通常，以前的方法提出了用于测量质量属性的目标。但是，有时，对软件体系结构的评估不会产生允许直接决策的数值。考虑到可以在设计过程的任何级别进行评估的可能性，可以使用不同级别的规范，Kazman提出了一种针对架构的质量属性进行评估的通用方案。从这个意义上讲，Kazman和他的同事们肯定，对体系结构的评估不会获得“是-否”，“好-坏”或“ 6.75 / 10分”类型的答案，而是要说明哪些是风险的风险点。评估设计（2）。
Bosch和Kazman方法之间的主要区别之一是它们用于评估目的的方法。博世提出的建筑设计方法的主要特征是在设计过程中对建筑质量属性的明确评估。从这个意义上说，博世提出了评估技术：基于场景，基于模拟，基于数学模型和基于经验。就Kazman而言，他建议，在设计过程的早期阶段，对质量属性的表征或测量几乎没有兴趣。它的方法以降低风险为导向，定位感兴趣的质量属性受体系结构决策影响的位置（2）。
博世（Bosch）和卡兹曼（Kazman）均指出，全面定义质量属性作为评估软件体系结构基础的重要性。重点是根据您的目标和环境定义质量属性，而不是绝对数量（2）。
体系结构评估的特征
- 它是项目中的主要评估点之一，因为其中的错误会导致项目失败（5）。它可以由项目内部或外部的人员执行，尽管最有趣的是它是由外部人员执行的（导师或区域建筑师）（5）。
如何确定我的体系结构选择对我的软件是正确的？
如果架构决策确定了系统的质量属性，则可以评估架构决策对这些属性的影响（2）。
为什么要评估架构？
“评估架构的目的是分析和识别架构和属性中的潜在风险，这些风险可能会影响最终的软件系统，验证架构中是否存在非功能性要求，并确定学位质量属性得到满足。应该注意的是，非功能性需求也被称为质量属性（4）。
质量属性是影响项目的质量特征。术语“特征”是指非功能性方面，术语“元素”是指组件（4）。
- 在软件项目中发现问题越早越好（5）进行体系结构评估是避免灾难的最经济方法（5）分析和评估用户所需的质量（5）。设计（5）或实施限制。
- 建立系统的开发，构建和执行的组织结构，达到质量属性。o允许原型制作，可以进行更准确的估算。
什么时候可以评估架构？
根据Kazman的说法，可以随时执行此操作，但他提出了两种将两个不同阶段组合在一起的变体：早期和晚期（2）。
- 早期。无需完全指定体系结构即可执行评估，并且从早期设计阶段一直延伸到开发。下午。建立并实现完成后。这是购买已开发系统时发生的一般情况。
确定何时进行评估的黄金法则（4）：
- 当开发团队开始做出直接影响体系结构的决策时，请执行评估；…不做出这些决策的代价可能要比进行评估的代价大。
谁参加评估？
通常，架构评估是由开发团队，架构师，设计师等成员进行的。但是，也可能有现场专家介入的情况。另一个对评估结果也感兴趣的客户是客户，因为根据结果，他们可以决定是否继续该项目（4）。
评估技术
有一组评估技术，分为定性和定量
（5）：
- 质疑或定性技巧。他们使用定性问题来询问架构或开放性。早期或清单。特定于应用程序的领域。
- 系统特定。先进的架构。
- 使用架构指标，例如耦合，模块内聚，继承深度，可修改性，模拟，原型和实验
图#1：评估技术的分类（4）
通常，当架构正在构建时使用定性评估技术，而当架构已经实现时使用定量评估技术（4）。
规划或不规划架构
评估可以是（4）：
- 计划的：这些是针对开发生命周期进行计划的，因此它是项目活动的一部分。计划外的：当架构包含在开发的后期阶段已发现的几个缺陷时，就会发生这种情况，因此，进行计划外的评估会延迟交付时间，并增加项目成本。因此，建议项目考虑对架构进行一次或多次评估。
可以评估什么素质的体系结构？
大致而言，Bass将质量属性分为两类（2）：
- 通过执行可观察：这些属性是根据执行时系统的行为确定的。表1中提供了其中一些属性的描述。通过执行无法观察到：在系统开发过程中建立的那些属性。表2给出了其中一些属性的描述。
表格1。通过执行可观察到的质量属性的描述（2）
| 质量属性 | 描述 |
| 可用性 | 它是系统使用可用性的量度（Barbacci等，1995）。 |
| 保密 | 缺乏未经授权的信息访问（Barbacci等，1995）。 |
| 功能性 | 系统执行其构想的工作的能力（Kazman等，2001）。 |
| 性能 | 它是系统或组件在某些给定的约束（例如速度，准确性或内存使用率）内执行其指定功能的程度。（IEEE 610.12）。 |
| 可靠性 | 它衡量系统在整个过程中保持运行的能力 |
时间（Barbacci等，1995）。
| 外部安全 | 在环境中没有灾难性后果。它是衡量没有错误而导致信息丢失的方法（Barbacci等，1995）。 |
| 内部安全 | 它是系统在为合法用户提供服务时抵抗未经授权的使用尝试和拒绝服务的能力的度量（Kazman等，2001）。 |
表#2。通过执行无法观察到的质量属性的描述（2）
| 质量属性 | 描述 |
| 可配置性 | 赋予专家用户对系统进行某些更改的可能性（Bosch等，1999）。 |
| 可整合性 | 这是单独开发的要集成的系统组件可以正常工作的程度。（巴斯等人1998） |
| 廉正 | 缺乏不适当的信息变更（Barbacci等，1995）。 |
| 互通性 | 它是系统一组部分与另一个系统一起工作的能力的度量。这是一种特殊的可集成性（Bass等，1998）。 |
| 可修改性 | 它是将来对系统进行更改的能力。（Bosch等人，1999）。 |
| 可维护性 | 它是使系统受到修复和发展的能力
（Barbacci等，1995）。快速，低成本地修改系统的能力（Bosch等，1999）。 |
| 可移植性 | 这是系统在不同计算环境中执行的能力。这些环境可以是硬件，软件，也可以是两者的组合（Kazman等，2001）。 |
| 可重用性 | 能够以这样一种方式设计系统，使其结构或部分组件可以在将来的应用程序中重用（Bass等，1998）。 |
| 可扩展性 | 它是建筑，数据或程序设计可以扩展的程度（Pressman，2002）。 |
| 容量
测试 |
这是对软件进行一系列测试时可以证明其缺陷的难易程度的度量。假设您至少有一个故障，则该软件有可能在下一次测试运行时失败（Bass等，1998）。 |
进行架构评估有什么好处？（5）
- 财务将利益相关者召集到一起阐明特定的质量目标迫使对体系结构的文档进行改进改进体系结构尽早发现问题有效需求并优先考虑它们收集基础知识和体系结构决策。
评估体系结构会产生什么结果？
评估完成后，必须准备报告。必须将其作为初步文件提出，以便由参与评估的人员进行更正。报告的内容回答了两种类型的问题（4）：
- 是否为系统设计了最合适的体系结构？哪种提议的体系结构最适合要构建的系统？除了回答这些问题之外，该报告还指出了满足质量属性的程度。
建筑评估的输出是什么？（6）
- 评估架构所需的质量属性的优先列表风险和非风险。
评估的基本步骤（5）
- 准备工作。oo评估者。o范围。
- 建筑的表现形式。
- 提出要解决的业务问题和建议的体系结构。o评估成本，功能，质量属性。o他们审核需求和可能的更改，并讨论问题和观察结果。
建筑评估方法
- ATAM（体系结构权衡分析方法）：它受三个不同领域的启发：体系结构样式，质量属性分析和SAAM（软件体系结构分析方法）评估方法。ATAM方法的名称源于以下事实：它揭示了特定体系结构满足某些质量属性的方式，并提供了有关质量属性如何与其他属性交互的见解。
该方法集中于识别所使用的建筑风格或建筑方法。这些元素代表架构用来实现质量属性的手段，并描述系统的成长，响应变化以及与其他系统集成的方式（其中包括其他）（2）。
图#2。ATAM方法的概念流程（7）
ATAM评估方法包括九个步骤，分为四个阶段（演示，调查和分析，测试和报告）。
- 博世（2000）。该声明指出：“评估过程应视为迭代活动，这是设计过程的一部分，也是迭代的。对体系结构进行评估后，假设它不满足所有要求，它将经历一个转换阶段。然后，再次评估转换后的体系结构”（2）。此方法包括5个步骤，分为两个阶段。ADR（主动设计审查）。 “ ADR用于评估软件单元（例如组件或模块）的详细设计。问题围绕文档的质量和完整性以及所提出的设计提供的服务的充分性，调整性和便利性”（2）。干旱（对中级设计的积极评论）。 ARID是一种低成本，高收益的方法，在开发的早期阶段进行局部设计的评估很方便（2）。 ARID是ADR和ATAM（8）之间的混合体。它基于组装利益相关者设计以阐明重要或重要的使用场景，并测试设计以查看其是否满足场景。由于应用了此程序，因此获得了高保真设计，同时对涉众的设计也有了高度的了解。该方法包括9个步骤，分为两个阶段（先前的活动和评估）（9）。洛萨维（2003）：它是一种评估和比较候选软件体系结构的方法，它利用了从ISO / IEC 9126模型改编的质量和属性规范模型，使用基于国际标准的模型对质量属性进行规范提供了一种观点面向用户和系统架构师的全面和全局质量属性，以进行评估（2）。该方法包括七个活动。
| 阿塔姆 | 萨姆 | 干旱 | 博世（2000） | 洛萨维（2003） | |
| 预期的质量属性 | 可修改性
安全 可靠性 性能 |
可修改性
功能性 |
评估设计的适用性 | 由架构师根据系统的重要性选择 | 功能性
可靠性 易用性 效率 保养 可移植性 |
|
对象 分析 |
建筑风格，文档，数据流和建筑视图 |
文档和架构视图 | 组件规格 | 建筑风格，建筑景观，建筑图案，设计图案和语言图案 |
质量属性规范 |
| 应用项目的阶段 | 建立架构设计之后 | 在架构具有位于模块中的功能之后 | 整个架构设计 | 建立架构设计之后 | 建立架构设计之后 |
| 方法
用过的 |
效用树和集思广益，以阐明质量要求。可检测敏感点，平衡点和风险的体系结构分析。 | 针对场景进行头脑风暴并阐明质量要求。分析方案以验证功能或估计变更成本。 | 设计审查，集思广益。 | 资料分析（资料） | 分析和比较候选架构的结果 |
- 表3。评估方法之间的比较（2）。
还有其他评估特定质量属性的体系结构评估方法：
- ALMA（架构级别可修改性分析）。该方法是Brengtsson和Lassing的研究工作的结果，该方法分析的质量属性是易于修改。这是指由于需求或环境的变化以及新功能的添加而对系统进行调整的能力（9）。
ALMA是一种面向目标的评估方法，该方法依赖于变更方案的使用，该方案记录了可能导致系统变更的事件以及如何进行变更。它由五个步骤组成，如下图（9）所示。
图#3。ALMA方法（9）
- PASA（软件体系结构的性能评估）。该方法分析的质量属性是性能。有兴趣了解一个或多个事件发生时软件系统响应需要多长时间，以及确定在给定时间间隔内处理的事件数。PASA是Williams和Smith的工作的结果，它使用了各种评估技术，例如建筑风格，反模式，设计指南和模型的应用（9）。
此方法也是基于方案的，可以早或晚应用。用这种方法生成的场景是构建绩效模型的起点（9）。
它提出的要求或前提条件之一是，必须事先对体系结构进行记录，如果体系结构不完整，则必须从团队成员中提取其余信息（9）。
图#4。通过方法（9）
评估过程中涉及的人员是：架构师，开发团队，有时还包括项目经理。如果密集锁定，使用此过程进行的评估最多可能需要一周的时间。由于它已在各种应用程序领域（如Web系统，金融应用程序和实时系统）中进行了测试，因此被认为是一种成熟的评估方法（9）。
- SALUTA（基于场景的体系结构级别可用性分析）。这是第一个从系统易用性的角度评估体系结构的方法，这是Folmer和Gurp（9）研究的结果。
该方法利用了表示易用性和软件体系结构之间存在的关系的参考框架。这些参考框架包括一组集成的设计解决方案，例如设计模式或属性，它们对软件系统的易用性产生积极影响（9）。
SALUTA分析了与软件系统的易用性直接相关的四个属性：易学性，使用效率，可靠性和满意度。像之前分析过的两种方法一样，它基于场景，在这种情况下，是将一个或多个使用配置文件分组的使用场景，而不考虑冗余，其中每个都代表系统所需的易用性（9 ）。
建议在指定体系结构之后但在实现之前使用它（9）。同一帐户包含四个步骤，如下所示：
图#5。SALUTA方法（9）。
评估过程中涉及的人员是：软件架构师，需求工程师或负责易用性的工程师（9）。
- SNA（可生存网络分析）。它是由CERT（计算机紧急响应小组）开发的一种方法，该小组是SEI（软件工程学院）的一部分。
这种方法有助于识别系统中的生存能力，
它的架构。生存能力是系统在存在攻击，故障或事故的情况下按时完成其任务的能力。为了评估这种生存，SNA使用三个关键属性：抵抗力，识别力和恢复力（9）。
此过程可以在体系结构规范之后，其实现期间或之后执行。SNA基于使用场景的技术，并识别两种类型的场景（9）：
- 普通方案由一系列步骤组成，用户调用服务并获得对资产（如数据库）的访问权限；入侵方案，表示对系统的不同类型的攻击。
该方法的实现过程中涉及的人员是：软件架构师，主要设计师，系统所有者和相同用户。评估的结果是，获得了以下内容：一份文档，其中包括对架构的所有建议修改，以及生存地图（9）。
图#6。SNA方法（9）。
下表总结了这些先前分析的方法之间的比较表：
表#4。ALMA，PASA，SALUTA和SNA方法之间的比较（9）。
部分结论
- ATAM方法相对于其他方法，更深入地评估与体系结构相关的问题，例如：质量属性。迄今为止，已经提出了几种体系结构评估方法，其中一些方法比其他方法更完善，但是无论如何它们都有一个共同点，那就是它们使用场景技术来验证体系结构在多大程度上响应系统所需的质量属性。
第2章结果与讨论
介绍
在本章中，提出了一种评估基于组件的软件架构（ASBC）的程序，其目的是在架构中应用
面向服务（SOA）。从某种角度进行分析，即在某些情况下或某些条件下，服务可以被视为组件。
目标
本章的目的是逐步描述和分析所提出的方法如何工作，谁参与以及用于验证与系统质量属性的符合程度的工具和评估技术。
程序建议
作为对不同方法比较的分析结果，可以观察到架构权衡分析方法（ATAM）具有一组步骤，一个评估团队和一组定义更好的输出，并且对特性没有任何限制。质量评估。 MECABIC受到ATAM的启发，尽管为了促进其在ASBC上的应用，其某些步骤中还包括一种集成设计元素的方法，该方法受到了基于建筑的设计（ABD）采用的建筑零件的启发。另外，提出了一种基于ISO-9126质量模型的初始效用树，该模型针对Losavio提出的软件体系结构实例化。MECABIC对该模型的采用允许专注于完全依赖于体系结构的特性，并且作为标准，它有助于与研究方法所考虑的质量特性相对应。该树中包含的方案特定于基于组件的应用程序（1）。
评估小组
三个工作组参加了MECABIC方法
表#5 参加MECABIC方法的小组（1）。
| 设备 | 定义 | 他们参与的阶段 |
| 建筑师 | 负责为所研究的系统生成和记录软件体系结构。 | 所有 |
| 评估者 | 由质量问题专家组成，他们将指导体系结构评估过程 | 所有 |
相关的他们是与系统相关的人员：阶段1、3和4。程序员，用户，管理者等等。
评估工具和技术
为了指定质量，使用了一个实用程序树，它的根节点是系统的“良善”或“实用程序”。在树的第二层是质量属性。实用程序树的叶子是方案，它们代表了各种机制，通过这些机制，可以使特定的（质量不明确的）质量声明变得具体并可以进行评估。质量树的生成包括一个允许您确定优先级的步骤。对于架构分析，使用场景技术并在调查表的支持下确定参与者的需求（1）。
方法的阶段
- 在演示的第一阶段，该方法在所有小组，系统及其组织中广为人知，最后提出了必须评估的体系结构（1）第二阶段是研究和分析，它确定了如何研究体系结构，要求利益相关者精确表达所需的质量方案，并分析了体系结构是否合适或是否需要对其进行修改。在此阶段中，只有评估组和建筑师组参与（1）。第三阶段是测试，它包括对第二阶段的审查，所有团队都参与其中（1）。结果展示。所有小组都参与此阶段（1）。
每个阶段及其各自的步骤将在下面说明。
- 演示阶段（1）
在此阶段，将介绍MECABIC方法，以便参与者始终了解他们在该方法的应用中所处的位置。还公开了要评估的初始体系结构以及有望实现的质量特性。
- 方法介绍。
第一步，评估经理将方法介绍给项目的参与者。在会议期间，将解释每个项目参与者要遵循的过程，回答问题，并就剩余的活动或任务建立期望和上下文。此步骤的目的是让所有利益相关者了解要遵循的步骤顺序，每个步骤中使用的工具以及方法的输出。利益相关者被要求对他们的期望发表评论或对他们对应用该方法的期望提出特定疑问。
- 介绍业务准则。
负责评估的每个人（项目代表，团队成员等），都需要了解系统的上下文以及促使其发展的业务上下文的主要方面。在此步骤中，将向涉众解释系统的上下文以及系统将在其中运行的业务需求。此演示文稿应包含的一些主题是：系统最重要的功能，与项目相关的业务目标和上下文，利益相关者领导小组，架构准则（架构要满足的质量要求），技术，管理，经济和政治限制以及评估和系统限制的开放性。
- 架构介绍。
在这一步骤中，架构师或一组代表必须向利益相关者解释所评估的架构是什么。它应包含清晰的结构差异，应清楚地显示体系结构组件与所涉及的不同粒度之间的关系。在此演示文稿中，架构师介绍了技术约束（操作系统，硬件，系统必须与之交互的其他系统等）以及用于满足要求的体系结构范围。架构师必须传达基本信息，并以此方式简化团队所需的架构信息。
- 研究与分析阶段（1）
在此阶段，确定设计元素以帮助分析体系结构，指定步骤2中提出的要求，并分析所考虑的设计元素如何响应要求。
- 确定设计元素。
在此步骤中，将考虑架构设计替代方案，稍后将对其进行分析，以了解它们如何响应所提出的质量要求。必须从系统中对其体系结构进行全面评估，其组件具有最高的粒度，直至达到与组件相对应的最低粒度。在这种方法中，建议将基于组件的体系结构中的设计元素标识为组件以及与之交互的组件集，对某些特定质量特征感兴趣的一组关联或具有影响力的决策集远远超过其他设计元素。为了识别设计元素，有必要考虑可用组件提供的服务以及不同的选项，以定义为系统开发的组件的服务。记录设计元素的方式取决于它们在评估中可能具有的重要性，需要做出的一系列决策或调整以及评估中存在的利益相关者的知识。
- 实用程序树的生成。
MECABIC为ASBC提供了一个特定的初始效用树，他们从中选择了感兴趣的场景集（请参阅表#6），该场景基于Losavio提出的用于软件体系结构的ISO 9126-1质量模型。假定当应用该方法时，系统中存在的功能是用户所需的功能，因此，不包括适用性场景（功能子特性）。随后，考虑初始效用树中未考虑的方案。
表#6。方法（1）提出的初始效用树的子集
| 特性 | 子特征 | 阶段 |
| 功能性 | 互通性 | 该系统具有能够从其他系统读取数据的组件。
该系统具有能够为另一个系统生成数据的组件。 |
| 精确 | 系统组件提供的结果是准确的。组件之间的通信不会改变数据的准确性 | |
| 安全 | 该系统检测到入侵者的行为并阻止访问处理敏感信息的组件
系统确保组件不会因攻击而丢失数据（内部或外部）。 |
|
| 服从
（合规） |
这些组件遵守可靠性标准。
组件之间的通信不违反可靠性标准。 |
|
| 可靠性 | 到期 | 系统组件处理错误的数据输入。 |
| 容错能力 | 在不利条件下，组件正确执行的所有操作。 | |
| 恢复或恢复能力 | 系统组件在某些指定条件下不会发生故障。
面对环境问题，某些组件子集可以继续提供其服务。 |
|
| 效率 | 行为时间 | 系统必须在指定时间内接收其组件的服务。 |
| 使用资源 | 组件可以适当地共享资源。系统控制没有组件在需要时会耗尽资源。 | |
| 可维护性 | 变化能力，稳定性，证明 | 您可以检查系统组件的状态。
该系统使装配零件变得容易。 |
该系统应有助于组件的更换/适配。
| 可移植性 | 适应性 | 即使环境提供的组件服务有所不同，系统也必须继续正常运行。 |
| 容量
安装 |
这些组件可以轻松安装在必须运行的所有环境中。 | |
| 共存 | 这些组件足以处理共享的系统资源。 |
下面介绍了获取实用程序树的步骤。
5.1。选择要考虑的初始方案。
在此步骤中，评估小组向其余的参与者提出要考虑的不同方案，并确定将在实用程序树中包括哪些方案。
5.2。没有设想方案的提议。
此步骤旨在使利益相关者有可能验证是否有必要在实用程序树中包括其他方案。如果确定了质量方案，并获得了参与者的高度认同，则应将其直接包含在实用程序树中。其余方案的选择可以通过投票完成，如ATAM最初建议的那样。然后，通过质量特征来组织在初始效用树的生成表中未考虑的引入的质量方案。因为要评估一组感兴趣的特征，所以不应针对所有已知的质量特征呈现质量方案。一旦获得了包含实用程序树的方案，便对其进行优先级排序。
5.3。优先考虑质量方案。
在这一步中，目标应该是对场景进行排序，因为通过这种方式，架构师可以获得更多指导来做出架构决策，并且利益相关者可以更加了解他们对系统的期望，并了解其将在多大程度上实现目标。满意。一旦决定在实用程序树中包括最重要的方案，我们便使用两个标准为系统的质量方案分配一个顺序，即：
- 评估不考虑方案的风险。必须回答以下问题：如果不满足此方案会发生什么？受影响的人数是多少？是否可以弥补对此方案的不响应？评估实现该方案所需的工作量。在这种情况下，确定必须对新组件进行更改或集成才能满足该方案。最困难的情况是应消耗更多的分析时间，而其余的应作为注册表的一部分保存。
最后，使用上一步的输出构建实用程序树。方案的优先级在此方法中定义为对（X，Y），其中X定义满足方案的工作量，而Y表示通过将它们从利润树中排除而产生的风险。X和Y的可能值为A（高），B（低）和M（中）。所生成的利润树被用作该方法执行的其余评估的计划。它还告诉评估团队在哪里花费时间以及在哪里测试体系结构方法和风险。
- 分析ASBC的设计元素。
在此步骤中，分析步骤4中标识的设计元素或可以标识的新设计元素，以确定它们如何影响步骤5中生成的实用程序树中存在的质量方案的性能。
- 分析步骤4中研究的设计元素。
根据设计元素的类型，评估会有所不同。组件提供了一组端口，必须扩展这些端口才能提供新服务，而这些端口又可以提供给其他组件进行扩展。必须根据一些质量标准评估一组选项，这些选项指示一种定义端口之间的关系的方法（在步骤4中提出，可以在此步骤中进行扩展，考虑到生成的实用程序树）。质量方案必须应用于已生成的体系结构。评估团队以该方法提出的分析问题为指导，以确定有关架构的决策。应该询问所做出的决定是否允许达到所提出的质量方案。如果答案是否定的，则应重新考虑已做出的任何决定。该方法分析设计元素所带来的一些问题如下所示。
表#7。分析确定的设计元素的一些问题（1）
| 特性 | 子特征 | 分析问题 |
| 功能性 | 精确 | 组件之间的通信是否会导致组件提供的服务不准确？ |
| 互通性 | 允许系统与其他系统交互的组件在哪里？ | |
| 可靠性 | 到期 | 是否有决策来最大程度地减少组件之间通信中的数据错误处理？ |
| 容错能力 | 您如何检测组件故障？ | |
| 效率 | 行为时间 | 体系结构不同部分的组件数量之间的关系如何？ |
| 可维护性 | 变化能力，稳定性，证明 | 如何验证组件的正确操作？
您如何检查组件之间的通信状态？ 如何轻松更换组件？ |
| 可移植性 | 容量
安装 |
是否存在确定所有系统组件是否正确安装的机制？ |
| 共存 | 有没有办法确定与体系结构外部的系统组件进行交互的规则？ |
- 交易点，平衡点，风险，非风险和未解决问题的文档。
步骤6.1中确定的决策可能与某些设计元素有关。应该研究特定决策带来的风险，或者它是否对已经确定的任何风险有所影响。还可以记录未采取的决策或未解决的问题，在评估团队的判断中，将来可以通过研究更详细的设计元素来解决。
- 测试阶段（1）
作为阶段1和阶段2的应用的结果，考虑到生成的实用程序树，做出了一组记录的体系结构决策。在这个阶段，我们将面对到目前为止所做出的决策，我们将与系统中所有相关人员一起努力，以产生最终的体系结构。
- 审查实用程序树。
MECABIC建议使用质量方案来代表所有评估组的利益，并确认已经评估了所需的质量要求。评估团队可以通过使用步骤6中建议的一组步骤来促进场景的拟定。利益相关者将未考虑的效用树的场景放置在集思广益包中，让您有机会查看服务不足的情况。将生成的方案与实用程序树中最初考虑的列表进行比较。如果考虑和优先级重合，则可以说评估的场景适合于系统中的利益相关者组。如果不匹配，必须重新考虑新方案和/或其优先级。如果两组利益相关者之间未达成协议，则可能没有充分体现涉众的利益。利益相关者还应该分析已经评估过的方案，以验证他们是否已经收到适当的重视。一旦考虑了新方案，就可以提出三种情况：
- 该方案复制了在实用程序树中已经考虑过的方案，该方案成为现有分支的叶子，该方案没有分支，因为以前没有考虑过。
前两个案例表明该软件体系结构是根据利益相关者的期望创建的，而在第三个案例中，它没有考虑一些重要的质量方面，可能存在文档风险。
- 审查已定义的设计元素。
评估团队必须研究步骤6中分析的设计元素如何促进新的利益相关者小组提出的方案。如果它们不能促进所需的质量特性，则应重新考虑。
- 最终架构和报告的生成阶段（1）
目前，已经对到目前为止已经做出的所有决策进行了分析。如果没有冲突，并且可以得出结论，评估所涉及的利益相关者的质量要求有适当的架构，则可以直接进行步骤10。相反，如果在某些设计元素中存在有利于某项要求的决策，那么利益相关者就是那些必须确定或同意要满足哪些要求的决策者。
- 生成协议。
在此步骤中，确定将采用该系统的体系结构。为此，如果尚未找到更好的选择，则必须就现有选择达成共识。如果存在尚未达到的质量要求，则必须为利益相关者提供可能性，以同意重新考虑尚未达到的质量要求，以利用体系结构的可能优势。到了这个时候，利益相关者对通过研究的替代方案可以获得什么好处的想法有所了解。这是一项至关重要的协商，因为如果失败，则意味着需要重新考虑体系结构；如果成功，则必须注意未解决的质量要求是等效的，使利益相关者对该系统感到满意。最后，记录所有无法找到解决方案的质量要求，并说明原因。
- 结果介绍。
为了最终确定该方法的应用，以口头和/或书面形式给出了该方法的应用摘要。然后必须包括以下文件，从该文件开始评估：
- 业务上下文质量要求生成的体系结构确定的设计元素的分析协商的方案集属性评估的问题集利润树无风险的记录敏感点和协商点
部分结论
有必要将建议的过程应用于SOA架构样式，以了解它在此类架构中的有效性，并以此方式能够分析可以在其中调整或修改哪些方面，以便获得更大的深度。应用此方法时。
结论
- 尽管基于组件的软件工程有望大大提高系统的质量水平，但是对软件体系结构的评估仍然很重要。然而，为了应用传统的建筑评估方法，有必要使其适应组件的性质以应用MECABIC方法，无论是在分析的方法还是在拟议的方法中，评估建筑的“场景技术”最多。用来验证某个质量属性是否符合系统要求的程度。值得强调的是，一种评估方法并不比另一种更好，而是在一定条件下针对给定的质量属性进行了更好的评估。根据条件和您要评估的内容，将是所使用的评估方法（不必只是一种）。
推荐建议
建议将建议的方法应用于其他体系结构样式，例如SOA（面向服务的体系结构），以了解其对其他类型的体系结构的有效性，并以此方式分析其中可以调整或修改的方面，因此，使用此方法时可获得更大的深度。
- 参考书目基于组件的软件架构评估方法（MECABIC）。亚历山大·冈萨雷斯（AleksanderGonzález），玛丽亚·米哈雷斯（MarizéMijares），路易斯·门多萨（Luis E.Mendoza），安娜·格里曼（AnnaGrimán），玛丽亚·佩雷斯（MaríaPérez）。墨西哥，科利米亚：锡，2005年，第1卷。埃里卡·卡马乔（Erika Camacho），法比奥·卡德索（Fabio Cardeso），加布里埃尔·努涅斯（GabrielNuñez）。软件体系结构。Reinoso，Carlos MSDN。 MSDN。 2006年6月26日。http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.mspx。评估软件架构。第1部分。概述。戈麦斯，奥马尔·萨尔瓦多·戈麦斯。 01，墨西哥：Brainworx SA，2007年。1870-0888。古斯塔沃·安德烈斯·布雷（GustavoAndrésBrey），加斯托·埃斯科巴尔（GastónEscobar），尼古拉斯·帕塞里尼（Nicolas Passerini）和胡安·阿里亚斯（Juan Arias）。IT项目架构。建筑评估。布宜诺斯艾利斯：国立技术大学。布宜诺斯艾利斯地区学院-系统系，2005年。豪尔赫·特里亚纳斯，玛丽亚·德拉斯·尼维斯·弗雷拉。软件管理。软件管理。 2006。http：//www.fing.edu.uy/inco/cursos/gestsoft/。克莱恩，马克。 SEI（软件工程学院）。 SEI（软件工程学院）。卡内基梅隆大学，2007年。http：//www.sei.cmu.edu/architecture/ata_method.html。克莱门特，保罗。 SEI（软件工程师协会）。 SEI（软件工程师协会）。 2000年8月。http：//www.sei.cmu.edu/publications/documents/00.reports/00tn009.html。标准Z39-18298-102。评估软件架构。第2部分。评估方法。戈麦斯，奥马尔·萨尔瓦多·戈麦斯。02，墨西哥：Brainworx SA，2007年。1870-0888.SEI（软件工程学院）。SEI（软件工程学院）。卡内基·梅隆大学。www.sei.cmu.edu/architecture/arid.html。
