ISO 26262 Indicator of SWAD Complexity
上一篇，我们聊了聊功能安全对软件设计都有哪些要求，本篇我们继续来聊一聊软件架构设计的复杂性指标相关内容。
复杂性的话题很难去界定或者去衡量；它开启了系列不同的解释。然而， ISO 26262尝试列举8个指标来理解软件架构中的复杂性方面。
通常形容高复杂性的8个指标如下所示：
1- High Branched Control or Data Flow 高分支的控制流或者数据流数据流
数据流：从源头到目的地和它们根据要求的转化；在从源头到目标的每一步中，它都可以有一定的形式。数据流任务是处理数据。它定义了它的运动和转化。所以我们不需要高度分支的数据流，因此数据流可以很容易地被追溯和测试。
控制流：我们想要去测试分支的所有正确和错误的结果，但是如果它非常复杂，使得测试所有场景都很困难，那么我们最终会得到复杂的架构；它可以用圈复杂度（Cyclometric Complexity Metric）来衡量。
2- Excessive number of requirements allocated to the single design elements 给单一设计要素分配过多的需求
因此，这个软件组件将是高度复杂的，因为它要处理高容量的功能需求。因此，它将是我们软件架构中的一个复杂性来源。
3- Excessive number of interfaces of one design element or interactions between elements 给一个设计要素分配过多的接口或者要素之间的交互过多
因此，这意味着我们的软件组件不会抽象内部处理，并且将许多当面暴露给另一个软件组件，这需要软件组件之间的更多的通讯；换句话说，高耦合问题。因为我们希望减少耦合，来使每个软件组件都具备良好的自独立性。
4- Complex types or excessive number of parameters 复杂类型或者过多的参数
复杂的数据类型是用户定义的数据类型，它包含过多的初始数据类型。
5- Excessive number of global variables过多的全局变量
全局变量将从每个软件组件中的多个函数中被修改，如果全局变量由于代码重构而中断，就需要更改调用它们的所有模块。
6- Diffculty in providing evidence for suitability and completeness of error detection and handling 很难为错误检测和处理的适合性和完整性提供证据
所以我们需要去找出与软件架构设计相关的错误，并且对每个错误进行明确的处理。如果我们很难找到这一点，意味着我们的软件是复杂的。
7- Difficulty in achieving the required test coverage 很难达到要求的覆盖度
如果我们应用降低软件架构复杂性的原则，达到要求的覆盖度就会更容易。
8- Comprehensibility only to a few experts or only to project participants 只有少数专家和项目的参与者才能理解
这意味着如果相关的工程师不清楚，那么评审的过程将是困难的，评审参与者很难提出意见。
上面提到的8个指标可以列在一个检查表中，以根据复杂性来审查软件架构设计。这样我们就可以利用前面表3中的原则来设计一个折中的方案，同时使我们的架构不那么复杂。
- 用户评论