复杂性

复杂性具有不同的种类和形态，一种简明的度量是类之间通信路径的数量，通信路径是类之间存在的持久或暂时连接。

复杂性存在四种维度的解释：

• 问题复杂性：问题问题域本身的复杂性，也称为计算复杂性。
• 算法复杂性：目标是度量软件算法的效率。具有降低相关性应归于从算法到交互计算模式的转变。
• 结构复杂性：目标是建立软件结构之间的关系及易于维护和易于演化。对郎被应用到软件对象之间的依赖。
• 认知复杂性：度量理解软件所需要的努力，即捕获程序的逻辑流，并度量逻辑流的各种特性。

从适应能力的角度，认知复杂性度量可以增强可理解性质量，结构复杂性可以增强可维护性和可伸缩性质量。这两种度量是有关系的，对于低结构复杂性，认知复杂性的较小值虽然是必要不充分条件，这与修改代码的需求是一致的，在修改之前首先要理解它。

空间认知复杂性

计算机现代程序的可认知复杂性的最合适的度量就是空间复杂性度量，其目标是度量软件工程师为了构造软件的智力模型而必须在代码中移动的距离，空间复杂性的度量体现出不同的特点。

空间复杂性的度量有面向过程的理论和面向对象的理论，面向对象的理论基础很差且常常是错误的，而函数程序设计的空间复杂性公式则是存在的。

导出复杂性的值应该这么做：

计算程序中每个函数的复杂性：$FC=\sum _{i=1}^{total\_calls}dis{t}_i$

将这些值累加得到整个程序的复杂性：$PC=\sum _{i=1}^{total\_functions}F{C}_i$

上述公式的主要弱点是以代码行计算距离。对于更现代的程序设计方法，代码行缺少相关性，当进行分析时也缺少将程序代码可视化的方法。另外，在这种情况下，代码行曲解了空间的含义。

结构复杂性

认知复杂性关注逻辑流，结构复杂性关注程序对象间的依赖。

一个依赖在模型元素之间定义了一种供应者/客户关系，对供应者的修改可能会影响客户模型的元素、依赖意味着没有供应者，客户的语义是不完整的。

如果更改提供服务的对象，则有必要修改此服务的客户对象，那么这两个系统对象之间就存在依赖。

如果系统中的所有依赖都被标识和理解，则说系统有适应性，即具有可理解性、可维护性、可伸缩性。适应性的一个必要条件是依赖可追踪，软件工程师的任务是减少依赖。

在软件系统中，可以根据不同粒度的对象（构件、包、类、方法）来识别依赖。位于低层次粒度上的较特殊对象的依赖会向上传递，在高层次粒度上产生依赖。依赖管理有必要更详细地研究代码，识别数据结构之间的所有关系以及软件对象之间的代码调用。

网络的结构复杂性

网络的每条通信路径一般都允许类之间进行双向交互，其复杂性可以表示为${}_{net}CCD=n(n-1)$。

我们以类的数量而不是以对象的数量来测量复杂性。程序中，是对象而不是类发送消息给相同类或不同类的其他对象，这对于负责移交应用程序逻辑和管理程序变量和其他数据结构的程序员来说又引入了另外的困难。然而，这种困难在这种情况下不重要，可以忽略。

只有两个对象之间存在持久或瞬态连接，一个对象才可以向另一个对象发送消息。瞬态连接是在单个程序调用中解决的，在程序结构中直接可见，也可以不直接可见。只有在类模型中定义了连接，持久连接才存在。

层次的结构复杂性

复杂性控制结构的解决方案是通过将类组织成类的合并结构来减少网络结构。用这种方法，类可以很自然地形成层，强调类之间的层次体系分解，而层的内部允许类似网络的交互。

分等级的层次组织通过限制类之间潜在交互路径的数量而降低复杂性，方法是：将类分到层中，只有同一层的内部及一层与层次体系中下面的相邻层之间才允许直接的类交互。

令$size(l_i)$表示第$l_i$层的对象数，$l_i$为第$l_i$层的双亲数，$p_j(l_i)$为第$l_i$层的第$j$个双亲。

${}_{holarchy}CCD=\sum _{i=1}^n\frac{size(l_i)\times (size(l_i)-1)}{2}+\sum _{i=1}^n\sum _{j=1}^{l_i}(size(l_i)\times size(p_j(l_i)))$

总结

以上是生活随笔为你收集整理的【软件体系结构】软件体系结构复杂性的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。