28、使用ELECTRE TRI优序法评估可信软件及接口定制组件测试方法

使用ELECTRE TRI优序法评估可信软件及接口定制组件测试方法

1. 可信软件评估背景与方法选择

随着计算系统规模和复杂性的不断增加，对更可信软件和服务的需求日益增长。评估软件的可信度在可信软件和服务的研究中变得愈发重要。软件可信度是一个多维概念，但许多相关研究仅关注单一或少数特征，缺乏全面评估。

在互联网可信资源管理研究中发现，如果潜在用户缺乏简单、有效且可信的流程来判断软件的可信度，他们在选择软件时将面临巨大的复杂性。对软件可信度进行评级，不仅可以减少用户在评估阶段的认知负担，还能引导开发项目朝着可信度提升的方向发展。

由于软件可信度是多维概念，多准则决策辅助（MCDA）方法被用作一种强大的工具，以综合考虑多个因素，实现折中的评估解决方案。Roy区分了四种类型的MCDA问题：
1. 选择问题P.α：帮助选择最佳方案。
2. 分类问题P.β：根据预定义的规范对行动进行分类。
3. 排序问题P.γ：以偏序对方案进行排序。
4. 描述问题P.δ：以形式化的方式描述方案。

P.α和P.γ基于方案的两两比较得出结果，而P.β中每个方案独立于其他方案进行考虑，结果仅取决于方案的内在价值和预定义的规范。对于采购经理来说，评估和选择软件包通常属于P.α或P.γ问题。但从可信资源管理的角度来看，对软件可信度进行评级属于P.β问题。

基于聚合程序，MCDA方法分为两类：补偿性和非补偿性。日常评估中使用的加权平均和（WAS）聚合技术是补偿性的，一些基于多属性效用理论的技术也是如此。ELECTRE TRI优序法是一种非补偿性MCDA方法，适合可信度评估的特点：
1. 可信度的各个维度通常不被认为可以相互补偿。
2. 可信度维度的测量可能不精确、不确定或不准确。

此外，在研究中互联网软件提交模式对每个供应商开放，供应商往往无法提供足够的证据证明软件可信，为每个软件包配备特定评估人员既不实际也不必要，因此评估过程的自动化或减少人力投入是理想的选择。

2. 软件可信度评估流程

软件可信度评估过程（STEP）包括以下步骤：
1. 定义可信度评估的问题情境。
2. 定义问题表述。
3. 确定评估模型及其参数。
4. 应用评估模型。

2.1 问题情境和问题表述

问题情境（PS）指问题的内在结构和外部背景。可信度评估的PS可定义为三元组 < APS, OPS, RS >，其中：
- APS是涉及的参与者集合，包括软件供应商、可信资源管理者、用户（评估用户和潜在用户）、评估者。
- OPS是每个参与者引入的对象集合，包括软件本身、用户数量和满意度、开发团队的能力和稳定性、软件可信度的证据。
- RS是每个参与者为OPS中的每个对象分配的资源集合，包括可信度知识、时间限制（新证据到达后可用时间短）、人力资源限制（期望较少的管理）。

问题表述（PF）是对上述PS中所表达问题的正式呈现。不同的参与者可以定义不同的PF。评估者的PF可定义为三元组 Γ = < AΓ, VΓ, ΠΓ >，其中：
- AΓ是待评估的软件集合。
- VΓ是可信度的维度集合（根据Trustie项目的定义，维度包括可用性、可靠性、安全性、实时性、可维护性和生存性）。
- ΠΓ是定义最终结果形式的问题陈述，在本文中是将评估的软件分配到预定义的信任级别，即属于Roy分类中的P.β问题。

可信度维度集合可能因领域而异，本文使用的维度与Trustie项目列出的维度一致，但评估方法不依赖于特定的可信度划分。

2.2 评估模型

评估模型使用ELECTRE TRI方法评估可信度，由七元组 < A∗, D, M, E, G, U, R > 组成：
- A∗是从AΓ中选择的方案，这里A∗ = AΓ。
- D是从VΓ转换而来的评估属性集合，包括可用性(d1)、可靠性(d2)、安全性(d3)、实时性(d4)、可维护性(d5)、生存性(d6)。
- M是与D中属性相关的测量集合。原始测量数据可从软件供应商处获取，使用ISO9126推荐的方法，并可作为可信度的证据。然后用户根据对原始数据的满意度和使用经验对属性进行评分。
- E是与D相关的尺度集合。提出了一种受层次分析法（AHP）启发的尺度，并将其与D中的每个属性相关联。单用户评分尺度如下表所示：
| 评分 | 解释 |
| ---- | ---- |
| 9 | 非常满足关键任务使用的期望 |
| 7 | 基本满足关键任务使用的期望 |
| 5 | 非常满足日常使用的期望 |
| 3 | 基本满足日常使用的期望 |
| 1 | 满足偶尔使用的期望 |
| 0 | 不可用 |

如果用户在1、3、5、7、9相邻评分之间犹豫，则评分为2、4、6、8之一。设C是对软件进行评分的用户集合，Lu是用户u的级别（视为用户权重，尺度 = 1, 2, 3），si是用户u对属性i的评分。则多用户对属性i的评估ei定义为：
[ei = \frac{\sum_{u\in C}(Lu \times si)}{\sum_{u\in C}Lu}]

• G是准则集合。准则gi是配备了偏好关系的属性。设gi(a) = ei(a)，其中a是被评估的软件，gi将属性尺度映射到实数。
• R是评估模型中采用的聚合技术，这里R = ELECTRE TRI。

权重分配在ELECTRE TRI方法以及其他聚合算法中起着关键作用。引入了基本权重向量和权重期望函数，以结合专家和用户的意见来解决这个问题。同时也对其他ELECTRE TRI参数进行了赋值。

基本权重向量定义：设D = {di|i = 1, …, k}是属性集合，wb是从D到[0, 1]k的向量函数，表示在任何用户对属性进行评分之前D上的非信息先验权重，满足：
[wb(di) \geq 0] 且 [\sum_{di\in D}wb(di) = 1]
则wb称为基本权重向量。

权重期望函数定义：设D = {di|i = 1, …, k}是属性集合，wb是D上的基本权重向量，Cb是wb的先验常数，Ni是对属性di进行评分的用户数量。从D到[0, 1]k的向量函数we表示D上的后验权重期望，表达式为：
[we(di) = \frac{wb(di) \times Cb + Ni}{Cb + \sum_{dj\in D}Nj}]
可以证明we满足可加性原则：
[we(di) \geq 0] 且 [\sum_{di\in D}we(di) = 1]

Ni反映了有多少用户关注属性di，可作为属性权重的一个因素。如果初始用户数量不够大，基本权重向量可以在确定D上的权重值方面发挥作用。Cb反映了先验权重分配的重要性。

轮廓设置与Trustie项目标准一致，即bh(h = 1, …, 5)。将可信度指数的默认值设置为ELECTRE TRI软件建议的值（λcutting = 0.76）。由于属性的评估值已归一化，将其他参数设置简化如下，且所有属性的设置相同：无差异阈值q = 0.2，偏好阈值p = 1，否决阈值v = 2。这些值是先验的，会根据软件领域和其他相关因素而变化，可由专家在提交评估应用之前进行设置。

2.3 案例研究

使用上述模型对支持软件评估的CASE工具TEvaluator进行评估。设wb(di) = 1/6（i = 1, …, 6），Cb = 60。对属性进行评分的用户数量以及应用公式3得到的we如下表所示：
| 属性 | 可用性 | 可靠性 | 安全性 | 实时性 | 可维护性 | 生存性 |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| wb | 1/6 | 1/6 | 1/6 | 1/6 | 1/6 | 1/6 |
| Ni | 35 | 30 | 15 | 30 | 20 | 10 |
| we | 0.225 | 0.2 | 0.125 | 0.2 | 0.15 | 0.1 |

ELECTRE TRI方法的参数分配如下表所示：
| 准则 | 属性 | 值 | 权重 | q | p | v | b1 | b2 | b3 | b4 | b5 |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| g1 | 可用性 | 7.3 | 0.225 | 0.2 | 1 | 2 | 1 | 3 | 5 | 7 | 9 |
| g2 | 可靠性 | 6.14 | 0.2 | 0.2 | 1 | 2 | 1 | 3 | 5 | 7 | 9 |
| g3 | 安全性 | 4.85 | 0.125 | 0.2 | 1 | 2 | 1 | 3 | 5 | 7 | 9 |
| g4 | 实时性 | 7.1 | 0.2 | 0.2 | 1 | 2 | 1 | 3 | 5 | 7 | 9 |
| g5 | 可维护性 | 5.11 | 0.15 | 0.2 | 1 | 2 | 1 | 3 | 5 | 7 | 9 |
| g6 | 生存性 | 3.93 | 0.1 | 0.2 | 1 | 2 | 1 | 3 | 5 | 7 | 9 |
| λcutting | 0.76 | | | | | | | | | | |

应用悲观规则，将TEvaluator（简称t）与轮廓进行比较。设S为优序（至少与……一样好）关系。从图中可以看出t S b5不成立。接着将t与b4比较，由于g3(b4) > g3(t) + v，满足t S h4的否决条件。

t与b3的优序关系推导如下：
根据ELECTRE方法定义的伪准则模型：
[a’ Si a \text{ 当且仅当 } gi(a’) \geq gi(a) - qi]，且 [a Pi a’ \text{ 当且仅当 } gi(a) + pi]
其中Si是优序关系，Pi是严格偏好关系，qi是无差异阈值，pi是严格偏好阈值，限制于准则gi。
可得：t S1 b3, t S2 b3, t S3 b3, t S4 b3, t S5 b3, b3 P6 t
则一致性指数c(t, b3) = we(d1) + we(d2) + we(d3) + we(d4) + we(d5) = 0.9
不和谐指数：
[di =
\begin{cases}
0, & i = 1, 2, 3, 4, 5 \
\frac{g6(b3) - g6(t) - p6}{v6 - p6} = 0.07 < c(t, b3), & i = 6
\end{cases}
]
可信度指数ρ(t S b3) = c(t, b3) = 0.9 > λcutting = 0.76
所以t S b3，将该软件分配到级别3。

3. 接口定制组件测试方法

随着软件规模和复杂性的不断增加，确保软件产品的可靠性和质量变得越来越困难，软件质量将成为衡量软件行业成功的决定性因素。软件复用是提高软件质量和生产力的关键技术，Clement Szyperski给出了软件组件的著名定义，软件组件是软件复用的技术基础。基于组件的软件开发（CBSD）为构建应用系统提供了一种方法。

在选择组件后，复用者通常需要修改组件以满足新的需求。通过定制，组件可以在特定的应用环境中复用或与其他组件进行交互。接口是组件之间交互的唯一途径，黑盒或在线组件的定制通常通过修改接口来完成。

提出了一个扩展的组件接口规范模型，以支持组件定制和测试。基于四种接口规范以及规范元素之间的关系，提出了定制操作符、测试流程和测试复用原则。最后进行了一些实验，结果表明定制机制和测试复用原则可以支持接口定制组件的测试。

组件接口定制和测试的流程可以用以下mermaid流程图表示：

graph LR
    A[选择组件] --> B[确定新需求]
    B --> C[修改接口进行定制]
    C --> D[应用扩展组件接口规范模型]
    D --> E[执行定制操作符]
    E --> F[依据测试流程测试]
    F --> G[遵循测试复用原则]
    G --> H[得出测试结果]

综上所述，通过ELECTRE TRI方法可以对软件的可信度进行有效评估，而扩展的组件接口规范模型及相关原则可以支持接口定制组件的测试，这些方法和模型在软件评估和开发中具有重要的应用价值。

4. 可信软件评估的讨论与优化方向

判断软件的可信度是一个复杂的决策过程，ELECTRE方法为解决这类现实问题提供了较好的途径。通过调整模型参数，模型可以适应不同的应用和领域。然而，为每个可信度维度和聚合技术设置过多参数也给模型应用带来了挑战，需要专业知识和技能来利用模型的适应性。当前的参数设置是基于先验经验和用户反馈，先验值可以在软件类别层面设置，并作为提交到这些类别的软件的默认设置。利用分配示例和分解方法来推断ELECTRE TRI的参数也是实用的方法。

为了使评估结果更可靠，还需要考虑用户用于对软件进行评分的证据：
1. 用户容易在证据不足的情况下匆忙判断软件的可信度。
2. 将软件分配到更高的信任级别应该依赖更可靠的认知证据。
3. 对软件开发过程证据提出更多要求，可能会在开发阶段引导提高软件的可信度。

不同用户有不同的可信度模型，包括不同的可信度维度、维度的权重分配和聚合方法。他们通常希望为自己的应用和领域构建特定的模型。因此，评估模型的结果应作为选择可信软件的指南和基础。为了避免给用户带来困扰，将维度保持在较粗的粒度（可信度仅分解为一级），不再进行进一步细分。虽然多层次模型的证据对一些用户深入了解软件可信度很重要，但可能会使其他用户感到困惑，甚至拒绝评价软件，还会引发子属性权重分配的更多争议。

未来，需要进一步研究针对不同领域的模型参数调整，以及对软件可信性提供更具说服力的证据要求。

5. 接口定制组件测试的详细分析

5.1 接口规范与定制操作符

扩展的组件接口规范模型基于四种接口规范以及规范元素之间的关系。这四种接口规范为组件定制和测试提供了基础框架。定制操作符是基于这些规范设计的，用于对组件接口进行修改和调整，以满足新的需求。

定制操作符的类型和作用可以用以下表格说明：
| 定制操作符类型 | 作用 |
| ---- | ---- |
| 操作符A | 用于添加新的接口功能 |
| 操作符B | 用于修改现有接口的参数 |
| 操作符C | 用于删除不必要的接口 |
| 操作符D | 用于调整接口的调用顺序 |

5.2 测试流程

测试流程是确保接口定制组件质量的关键。具体步骤如下：
1. 初始化测试环境，包括加载组件和相关依赖。
2. 执行定制操作符，对组件接口进行修改。
3. 依据接口规范，设计测试用例，覆盖各种可能的接口调用情况。
4. 运行测试用例，记录测试结果。
5. 分析测试结果，检查是否存在接口调用错误、数据传输异常等问题。
6. 如果发现问题，进行调试和修复，然后重新执行测试。

测试流程可以用以下mermaid流程图表示：

graph LR
    A[初始化测试环境] --> B[执行定制操作符]
    B --> C[设计测试用例]
    C --> D[运行测试用例]
    D --> E[分析测试结果]
    E --> F{是否有问题}
    F -- 是 --> G[调试和修复]
    G --> B
    F -- 否 --> H[测试结束]

5.3 测试复用原则

测试复用原则旨在提高测试效率，减少重复测试工作。主要原则如下：
1. 可复用性：设计的测试用例应具有较高的可复用性，能够在不同的组件定制场景中使用。
2. 独立性：测试用例应相互独立，避免一个测试用例的执行结果影响其他测试用例。
3. 完整性：测试用例应覆盖组件接口的所有功能和边界情况。

6. 总结

本文介绍了两种在软件领域重要的方法。一方面，基于多准则决策辅助（MCDA）方法，利用ELECTRE TRI优序法对软件的可信度进行评估。详细阐述了评估流程，包括问题情境和表述的定义、评估模型的构建以及参数设置，并通过案例研究展示了模型的应用。另一方面，提出了扩展的组件接口规范模型，支持组件的定制和测试。基于接口规范和规范元素关系，设计了定制操作符、测试流程和测试复用原则，通过实验验证了这些方法可以支持接口定制组件的测试。

这些方法和模型在软件评估和开发中具有重要的应用价值，能够帮助提高软件的可信度和质量，促进软件复用和开发效率的提升。未来，还需要在模型参数优化、证据要求细化以及测试方法改进等方面进行深入研究。