Simulink模型指标分析与模型重构的最佳实践

在此处可以看到，示例的子系统由一些输入端口和输出端口和另外两个子系统组成。在当前结构层，我们只关注两个子系统模块，而忽略关注子系统中包含的内容。即当前子系统具有输入端口和输出端口以及两个模块。这里要理解结构层次的概念，主要是因为在结构层面，我们需要了解信号流的来源、走向和信号的目标，以及它们之间是如何相互连接的，也就是我们在这里看到的当前层的结构布局。因此，为了从结构上理解这种局部复杂度，我们不需要知道设计中做了怎样的计算，我们暂忽略里面的内容，只考虑这些典型的模块。在当前模型层级评估这个系统的局部复杂度，可以计算得出一个具体数字，考虑可见的所有这些元素在内，我们得出好比这里给出的33的一个数字，以此来表征子系统的局部复杂度。

那么为什么要计算局部复杂度呢？事实上我们希望确保在特定的模型层只关注某些模型相关的重要特征信息，应用适当的层次结构，使模型表示的内容更容易阅读和理解，即增强模型的可读性。同时关于模型表达的所有其他信息，我们在当前层级省略并把它放在模型结构的不同层级。合理的复杂度的子系统布局可提升结构质量，提高模型软件的简单性、可读性，减少审查和维护方面的工作。现在，如果这个数字表示不能告诉我们关于复杂度的更多的信息，不用担心，让我们来看下面的示例如图3。

如图3左侧部分，像这样的一个小规模的子系统，基本上只包含简单的几步计算，如果我们应用相同的局部复杂度计算方法计算得到一个数字，显示其复杂度数值为60。相比之下，对于图3右侧一个更大的子系统，我们看到它具有更多的计算。因此，我们第一印象右侧这个子系统更复杂。现在的问题是，它究竟有多复杂？能否给出某种数字来比较它比这个数字大多少或复杂多少？因此，应用局部复杂度的运算，我们得到其复杂度数值为600。好的，那我们说这个右侧大的子系统大约比这里的这个小的子系统复杂十倍。

那么接下来我们研究一下这个具有相当高复杂度的大型子系统（参看图3右和图4），一般来说600显示其复杂度不是很高，但也是中高范围。对于这样的一个子系统，如何提高可读性？整体看，我们会发现这里包含某种并行计算，有些信号流不是很明确。我们可以尝试将局部复杂度限制在某阈值内，600已经有点过大了。于是我们查看此处的子系统并进行模型重构。

容易看到模型基本上分为了上下两个部分。我们在本层结构中上下部分分别创建一个子系统使部分计算包含在下面的模型层，重构后的局部（参看图5）复杂度显著减小为40，更重要的是重新布局的子系统，对于理解信号流、数据流和计算更为清晰简单，增强了可理解性和可维护性。

通过计算局部复杂度，我们可以查看模型组件的大小，或者子系统的复杂程度。从子系统重新开始，现在我们扩展到更大范围研究模型系统或子系统的全局复杂度，以了解模型系统的实现规模。因此，对于同样的模型系统或子系统如图6, 子系统由输入端口, 输出端口和两个子系统模块。但现在我们考虑子系统中的所有内容，子系统内部所有实现，如一些计算或更深层级的子系统中包含的内容，如图6在模型浏览器中我们所看到的那样。现在对模型子系统中包括的所有内容计算所有子系统的复杂度并加和，得到系统的全局复杂度为352。这个模型复杂度的计算考虑了我们在这里看到的所有内容。因此，我们看到当前结构层的全局复杂度不仅包括局部复杂度33，还包括其下各子系统层贡献的局部复杂度。

那么为什么要统计全局复杂度呢？原因在于通过全局复杂度的指标度量确保我们的单元或组件的不至于变得过于复杂。即确保单元和组件的可读性。同时我们还希望保持单元组件可度量，特别是对于审查和测试工作。因此，我们实际上可以将这个数字与审查和测试的工作量联系起来，这意味着数字越大，需要审查和测试的工作量就越大。

因此，全局复杂度大小等同于工作量多少，这正体现了对结构质量的影响。保持单元的小规模的同时提高可读性，模块化和可测试性，提升实施效率。如果对于某项功能需求，我们可以两种不同的方式实现它们，并且在功能上它们都可以完全正常地工作。但是你计算它们的总实现的全局复杂度大小，发现它们之间有很大的差异，然后你就知道全局复杂度较小的一个实际上是更高效的实现。因此全局复杂度不一定对功能质量产生影响，但它会对结构质量产生影响，展现我们的建模效率如何。

那么，全局复杂度在建模实践中怎样帮助我们改善和提高建模效率呢？我们以Matlab/Simulink中的一个典型示例模型为例加以说明。首先根据全局复杂度的指标，可以衡量并限制模型组件的整体大小，降低模型组件的复杂程度。其次，提供可测试性指标。例如通过采用库或模型引用（图7）的方式，将文件分拆成单独的模型组件，提高组件的模块化和可测试性。最后，提供模块化指标。合理划分模块，达到模块复用或者单独测试的目的。模块化的设计与您的软件架构设计保持一致，关联重点需求和测试。模块化带来灵活地加载和编译，在不同的工程模型中重用，而不必在全局范围内重复的评审和测试某种结构类型的组件。

前面我们已经讨论复杂度的概念，如何了解组件的大小和复杂度。现在，我们进一步了解此组件本身的协同工作情况，如计算或计算之间是否彼此关联。为此，我们研究组件内不同组成部分的关联程度，Matlab/Simulink/Stateflow中我们使用内聚度^【1】和非相干度来表示。中心思想是子系统中的每个模块直接或间接地影响子系统中的其他模块，并且本身直接或间接地受到子系统中其他模块的影响。因此，对于每个模块b，计算受模块b影响或影响模块b的所有模块的数量，包括模块b本身，即通过b的路径上的模块总数（简记为bop）。高内聚的子系统的bop接近子系统的总模块计数；低内聚的子系统的bop（b）与总模块计数相比会很低。例如图8中的模块，我们可以找到模块旁边标注每个模块的 bop 值。

让我们来看一个复杂的例子如图12。我们现在可以使用非相干度来识别具有高复杂度和高度不相干的子系统。如图12子系统的局部复杂度已经大到1104，导致可读性和可测试性方面非常大的困难。根据模型的非相干度指标值约为5，表明大约可划分为4-5个独立的组件。因此，我们对模型进行重构，可将模型重构为4个更大的分离组件。当然根据需要划分为5个也是完全可以的。

像这样重构后，得到类似图13的新结构，形成新的结构层，使整个模型更容易理解。首先，清晰地显示哪些输入信号对应于整个子系统单元的哪部分功能或运算，对相应功能信号的评估很重要。其次我们还可发现，非相干度大致保持不变，但是局部复杂度数值显著降低，提高了该层级模型的可理解性，当前模型层引入了结构层而不是功能和结构的混合。

模型指标非相干度值除了帮助我们进行粗略的分离组件的估计，还能帮助我们避免隐式数据流的设计。我们来看看图14这个例子。子系统由很多单独的图表组成，主要信号数据流被Goto/From模块隐藏，很难理解信号的属性和流向。统计显示子系统具有非常高的局部复杂度，可读性差。但是同时我们又注意到，非相干度数值只有3，意味着Goto/From模块的使用在观感上分隔了功能组件，但实际上它们可以简化为三个主要的功能组。

而重构后的模型图15表明，到结构层的子系统及数据信号流等方面得到更清晰的呈现，同时也显著降低了局部复杂度。

结构和功能元素

如何理解实现结构和功能的分离？如图16的Simulink的子系统为例，我们把输入端口和输出端口称为中性块，因为在大多数情况下都必须存在。在子系统内部，没有任何计算在这里进行，只有两个子系统。我们称这样只包含子结构模块的子系统为结构子系统。

再如图17这样的子系统，除了输入和输出端口，其余的模块都也是数学、逻辑或位运算或函数等功能性运算。我们称这样只包含功能运算模块的子系统为功能子系统。

按照ISO26262架构设计的原则的建议，创建子系统的适当层次结构。但什么是适当的呢？您可以在此处将适当定义为结构和功能层之间的专用差异化设计。将结构和功能元素分开，形成信号处理和结构、功能的层次结构架构设计的一致性，提高可读性，模块化，可测试性和修改的适用性等方面的结构质量。

这里我们给出推荐的模型架构设计的最佳实践。在软件开发过程的软件架构部分粗略地定义模型软件架构，同时根据以上我们谈到的相应的模型指标进行模型系统的设计和重构来确保模型系统或子系统符合行业最佳实践和初始的软件架构设计。在详细设计阶段，我们仍然需要注意避免在同一子系统中混合结构和功能模块元素，确保最终得到简易美观分层合理的模型结构。如形成类似图18所示的适当分层的模型结构，由SimuLink根层作为顶层的系统结构布局，其下层如图中模型层1通过各级子系统实现信号分配和软件架构层，然后其下层模型层K的子系统作为软件架构设计的结构实现。然后，从某层如模型层m开始，作为软件架构的结构层，或者实际功能计算的实现层，直到功能计算的最后一层。即在分层结构中，将结构子系统层保持到最后一层。建模过程中通过合理使用库链接或模型引用简化系统复杂度，最终形成简单易读、易测试、易维护的模型架构。

无效接口与接口大小

现在，在谈论子系统的层和结构以及模型分层架构时，我们当然还需要了解子系统之间和进入子系统的信号流和子系统的接口。

按照ISO 26262关于软件设计的原则建议，接口大小应限制在合理范围，防止接口过大而导致系统变得难以理解。考虑接口大小限制时，一方面考虑子系统接口总数的限制和信号的总线化处理，另一方面我们需要更加注重的是接口信号的有效供给。也就是说，输入子系统的信号务必与子系统中的功能需求相关的有效输入，防止实质上无用信号的输入。为了更好的理解，让我们看下面图19的例子。五个基本输入信号进入包含多级子系统和模型引用的子系统中。值得注意的是五个基本信号实际上只使用了两个，即信号a和信号b用于点积运算，而其他信号c、d、signal1是不必要的输入，因为它们事实上没有被后续用于功能或运算。

但在某些情况下，如果我们不了解实际的信号流，如我们难以查看子系统的模型或了解所有模型引用的细节，则很难理解这些信号是否被实际使用。此外，典型的用例如图20中，我们常常把整个总线馈送到子系统中，但是子系统中本身的功能实现只需求其中部分数量的信号，旁路信号实际上并未被子系统所使用。所以我们希望限制接口的大小，确保单元和组件是可重用性的同时，还要避免出现虚拟耦合。为此我们通常采用强制实施显式信号流，以此提高模型的可读性、模块化、可测试性、可维护性和修改的适用性。

对于接口大小方面的限制和信号的处理，有什么最佳实践操作呢？首先我们要注意单纯的限定输入输出端口为具体的数值是不合理的。另外，作为接口操作的最佳实践如图21，我们可以将需求的信号按功能需求分类分组到总线中，最好明确为子系统所需有效信号的基础上，使这些信号流显式表示，如图18中的信号分组与提取过程。因此，我们在子系统外部提取或修改必要的总线信号，在信号选择器上选择我们实际要使用的信号，并且在结构层上明确显示子系统必需的信号流。

克隆组件

现在假设我们已经有了一个很好的模型设计，结构质量各指标都已得到充分优化，我想把某个功能或算法复用到其他地方，这时我们的操作可能是对模块、组件或子系统复制粘贴。当系统中多处形成类似结构，如包含相同属性的子系统部件组，我们也称其为克隆组。关于子系统克隆与克隆组的操作，假设模型中存在一个小子系统，包含一系列运算模块，一些常量，呈现一定布局。作为复用组件，我们复制粘贴它到模型另外一个地方，并进行了一些布局和参数的修改，如图22所示。可以预见，如果我们重复进行类似操作，模型的复杂度会快速增长，相应也会带来测试和审查的工作量。因此，为了简化设计，降低模型系统的复杂度，可以把具有克隆组的模型作为单独的模型引用。如果某些子系统需要频繁多次在模型中使用，我们可以将其转换为库文件。转换为模型引用或模型库的方式，有助于减少模型的复杂度，减少模型测试和维护的工作量，最终也会减少代码量。

因此，找到大量克隆和克隆组，并用库引用替换它们，是针对克隆组件的最佳实践。以便显着降低全局复杂度，这意味着大小和工作量。对一个不同类型大量模块构成的复杂模型系统，通常各模型模块分组分散开发，容易出现模型的复制粘贴和克隆组的情况，模型系统呈现相对较高的全局复杂度。以某项目在克隆组及复杂度方面的研究统计结果^【2】为例（图23），系统中包含了大量的克隆组件和重复的子系统。对克隆组及克隆子系统的优化，可实现10%左右的复杂度缩减。一般来讲，对于大型工程，10%的复杂度降低意味着10%的评审测试工作的减少，意味着大量的人工和成本的节省。