文章“Simulink教程：一种数据驱动的模型复杂度降低方法”目前仅提供英文版本。
在基于模型的开发中，经常会出现包含复杂子系统的Simulink模型。这通常是由项目时间紧迫、需求不断增加等原因导致。然而，这类模型会增加后续维护、功能扩展和复用的难度，并从长远来看提高开发成本。
在本篇Simulink教程中，我们将介绍如何通过软件度量指标、合适的工具以及重构，对Simulink模型的复杂度进行分析，并有针对性地加以降低。
Simulink教程：一种数据驱动的模型复杂度降低方法
Have you ever opened up a Simulink model that was built years ago, and were unable to follow the logic?
Well, it happens more often than you would think. In reality, developers often face an uncomfortable truth: they know which subsystems are problematic because those subsystems were built quickly to meet a deadline or they have been extended again and again over years .
While they can sense that these issues need to be addressed, they often cannot easily quantify them.
Without data, it is difficult to justify refactoring, and if a developer leaves, the team may be forced to rebuild the incomprehensible subsystem from scratch.
This Simulink tutorial demonstrates how to transform gut feelings about model quality into actionable data using software metrics with the MES Model Examiner® (MXAM), and how to use MES Model & Refactor® (MoRe) to implement and automate those improvements in practice.
Step 1: Measuring the Problem
Let us look at a real-world, anonymized example of a problematic subsystem. At first glance, you see a high number of blocks and numerous crossing lines. This makes the subsystem really hard to understand. To really comprehend the dependencies between functionalities, you have to closely follow each individual line.
To estimate how complex the subsystem is, you can measure a metric known as Local Complexity of the Halstead metric. This matters, because after all, you cannot improve what you cannot measure.
While Simulink offers the option to count the number of blocks, this is an inaccurate proxy for complexity. A 'Lookup Table' is far more complex than a 'Gain Block', yet a simple count treats them as equal.
Instead, you can use Halstead metric using the MES Model Examiner® (MXAM) to calculate the Halstead Volume metric. This metric evaluates how functionality is distributed and how blocks are interconnected, immediately flagging areas where too much logic has accumulated in one place. In our example, the initial local complexity is at a high value of ~2600.
Without this metric, you will be refactoring blindly, missing the real hotspots, and accumulating technical debt in your models.
Step 2: Revealing Hidden Dependencies
A major contributor to the confusion in this model is the presence of many Goto and From blocks. Although they are often used to avoid 'signal chaos', they hide the graphical data and control flow, which is one of the primary benefits of using Simulink.
To fix this, the first step is to remove all Goto/From blocks and replace them with explicit signal lines. To achieve that you can use MoRe's action 'Transform GoTo/Froms to Lines' and obtain the result after a few easy clicks. At first, this makes the model look even worse and harder to understand. However, this is necessary to reveal the true dependencies.
Remember: clarity can look chaotic before it is well structured, and that is perfectly fine. The visual noise will be addressed in a later step using MoRe.
Step 3: Implementing Visual Improvements with MoRe
In this step of our Simulink tutorial, you can use MoRe to address the visual clutter. By applying the 'Auto Layout' action in MoRe, the tool automatically:
- Arranges blocks to follow a left-to-right data flow and visualize dependencies
- Places blocks vertically and aligns them horizontally for maximum clarity
- Reduces the number of line crossings
- Applies standard layout guidelines and best practices
After these actions, the model clearly showcases the sequence of functionalities, and the Local Complexity is significantly reduced to a value of ~1300.
Now the subsystem is not only readable, but it also serves as a good basis for further refactoring.
Step 4: Analyzing Subsystem Purpose
Next, you need to evaluate whether the subsystem is structured correctly using the Percentage of Functional Blocks metric. According to modeling best practices, subsystems should ideally be:
- Mainly Structural: Containing mainly Inports, Outports, Subsystems and other blocks with structuring purpose
- Mainly Functional: Containing mathematical or logic operation blocks but no further structuring blocks
Our example subsystem currently has a hybrid value, meaning it mixes both types. This is a practice that should be avoided because hybrid subsystems reduce readability, understandability, and testability. A value of 0% would mean the subsystem is 100% structural, while 100% would mean it is purely functional.
Step 5: Using the Incoherence Metric to Decide Whether to Split the Subsystem
To move away from a hybrid structure, you need to know where to split the logic. You can use the Incoherence metric for this. While Cohesion measures how strongly internal elements collaborate on a single task, Incoherence measures the extent to which elements are pursuing multiple, unrelated tasks.
In our subsystem, the Incoherence metric shows multiple independent parts. This data is an indication that there are different functional areas that should be separated into their own subsystems.
Considering this metric helps you to split the subsystem based on real data and not gut feeling.
Step 6: Final Refactoring with MoRe
Guided by the Incoherence data, you can use MoRe to finalize the improvements:
- Implement the 'Create Subsystem' action to group the unrelated tasks into their own distinct components.
- Apply the 'Auto Layout' action again to these new subsystems to ensure they are clean and easy to follow.
This refactoring process is both efficient and fully guided by the data captured in the metrics. As a result, the subsystem’s estimated local complexity was reduced by half, decreasing from approximately 2,600 to 1,300.
From Unreadable to Maintainable: The Benefits of Measuring Complexity
The final result is a clean subsystem where even the Global Complexity has been reduced. Global Complexity is the sum of the individual local complexities of all subsystems in the model. This metric is vital because it reflects the overall maintainability of the entire system.
By bringing this number down, you will have completed this Simulink tutorial and transformed a difficult to read and maintain model into one that can be used for years to come. A metric-driven refactoring approach coupled with tools like MoRe saves resources and time, but it also allows you to focus on functionality.
