What is the measure of a model?

In past posts, I have written about writing understandable models (Simulink and Stateflow.)  With this post, I want to address measures of clarity (or it’s inverse complexity.)  Note: in this post, I will be focusing specifically on Simulink metrics as contrasted with C based metrics.

Measurements in the C world

So what should be Baby angel sharks with ruler at Deep Sea World_900x583px.jpgmeasured and how do you evaluate the measurements?  In traditional C based development there multiple metrics such as…

  1. Lines of code (LOC):  A simple measure of overall project “size”.
    Note: A sub-metric is lines of code per function (LOC/Func)
  2. Coding standard compliance: A set of guidelines for how code should be formatted and structured (e.g. MISRA)
  3. Cyclomatic complexity: A measure of the number of logical paths through the program
  4. Depth of inheritance: A C++ measure of how deep the class definition extends to the “root” class.  Can be applied to function call depth as well.
  5. Reuse: The degree to which code is reused in the project.
    Note: a better measure is the degree of reuse across projects but this is more difficult to capture with automated tools.
  6. Coupling/Cohesion: Measures of the direct dependencies of modules on other modules.  Lose coupling supports modular programming
  7. Much more… : A list of some additional code metrics can be found here:  Software Metrics : Wikipedia

cyclomatic_complexity.png

Model-Based Design metrics

Within the Model-Based Design world, there are both direct and analogous metrics of the C-based versions.

  1. Total block count (TBC): The total block count maps onto the LOC metric.  Likewise, a Blocks per Atomic Subsystem can be compared to the LOC/Function metric.
  2. Guideline compliance: Modeling guidelines, such as the MAAB, map on to C based guidelines.
  3. Model complexity: Maps onto cyclomatic complexity.  It should be noted that the model complexity and cyclomatic complexity of the generated code will be close but not exact.
  4. Subsystem/reference depth: A measure of how many layers of hierarchy exist in the model
  5. Reuse: The use of libraries and referenced models that can directly
  6. Coupling: Simulink models do not have an analogous metric for coupling.  By their nature, they are atomic units without coupling.
  7. Much more….

Evaluating measurements

There is no such thing as a perfect model or perfect bit of C code.  In the end, all of the metrics above are measured against pass/fail thresholds.  For example, common thresholds for the Model Metrics include

  1. Blocks per atomic subsystem < 50
  2. Guideline compliance > 90%
    Note: with some guidelines that must be passed regardless of percentage

 

Measuring the model

With Models, as with text-based development environments, there are a variety of tools for collecting metrics.  Within the Simulink environment, it is possible to write stand-alone scripts to automate this process or use the Model Metrics tool to automatically collect this information.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.