Model Maintainability Metrics

The Model Maintainability Dashboard is a model design dashboard that collects metric data from the model design artifacts in a project, such as MATLAB^® code, Simulink^® models, and Stateflow^® charts. Use the metric data to assess the maintainability and complexity of the units and components in your design across the model development lifecycle. Each metric in the dashboard measures a different aspect of the maintainability of your design. Use the widgets in the Model Maintainability Dashboard to see high-level metric results and to gauge the complexity of the units and components in your design.

Alternatively, you can use the API functions to collect metric results programmatically. When using the API, use the metric identifiers (metric IDs) to refer to each metric. You can use the function getAvailableMetricIds to return a list of available metric identifiers.

Overall Design Cyclomatic Complexity

Metric ID: slcomp.OverallCyclomaticComplexity

Determine the overall design cyclomatic complexity for a unit or component.

Description

Use this metric to determine the overall design cyclomatic complexity for a unit or component.

The design cyclomatic complexity is the number of possible execution paths through a design. In general, the more paths there are through a design, the more complex the design is. When you keep the design cyclomatic complexity low, the design typically is easier to read, maintain, and test. The design cyclomatic complexity is calculated as the number of decision paths plus one. The metric adds one to account for the execution path represented by the default path. The design cyclomatic complexity includes the default path because the metric identifies each possible outcome from an execution path, including the default outcome.

For example, the design cyclomatic complexity of an if-else statement is two because the if statement represents one decision and the else statement represents the default path. The default path is not included in the number of decisions because no decision is made to reach a default state.

function y = fcn(u)
    if u < 0 % one decision
        y = -1*u;
    else % default path, zero decisions
        y = u;
    end
end

The overall design cyclomatic complexity metric counts the total number of execution paths in a unit or component. The default path is only counted once per unit or component.

The overall design cyclomatic complexity is equal to the sum of the:

• Simulink Decision Count

• Stateflow Decision Count

• MATLAB Decision Count

• plus one (for the default path)

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.OverallCyclomaticComplexity.

Results

For this metric, instances of metric.Result return Value as the integer value for the overall design cyclomatic complexity for a unit or component.

Examples

Suppose your unit contains four Simulink decisions, five Stateflow decisions, and six MATLAB decisions. The overall design cyclomatic complexity for your unit is 16 because the sum of four Simulink decisions, plus five Stateflow decisions, plus six MATLAB decisions, plus one default outcome equals 16.

Capabilities and Limitations

The metric has a minimum value of 1 because every design has at least one default execution path, even if no decisions are made within the design.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

Layer Depth

Metric ID: slcomp.LayerDepth

Determine how many layers deep a model component is in the model hierarchy.

Description

Use this metric to count how many layers deep a model component is in the model hierarchy for a unit or component. A layer is a parent or child model component in the model hierarchy.

This metric analyzes these model components:

• Simulink Subsystems

• Stateflow states

• MATLAB Function blocks

• External MATLAB functions and classes

• MATLAB methods

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, in the Component Structure section, point to the Depth widget and click the Run metrics for widget icon . The Depth widget shows the maximum depth found in the current unit or component. If you click on the Depth widget, you can view a table that shows the depth for each model component.

• Use getMetrics with the metric identifier slcomp.LayerDepth.

Results

For this metric, instances of metric.Result return Value as the integer value for the depth of the model component in the model hierarchy of a unit or component.

Examples

Suppose you have a unit, u1, that contains a subsystem, s1, and subsystem s1 contains subsystem s2. u1 is at layer depth 1, s1 is at layer depth 2, and s2 is at layer depth 3.

Capabilities and Limitations

The metric:

• Does not count relationships to data dictionaries.

• Does not count relationships to other units. For example, if you have a component with a required relationship to another model that is a unit, that relationship is not included in the metric count. The metric only counts the relationship if the other model is not a unit.

See Also

For information on finding the maximum layer depth for a unit or component, see Maximum Layer Depth.

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

Maximum Layer Depth

Metric ID: slcomp.MaxLayerDepth

Determine the maximum number of layers in the model hierarchy of a unit or component.

Description

Use this metric to determine the maximum number of layers in the model hierarchy of a unit or component. A layer is a parent or child model component in the model hierarchy.

This metric analyzes these model components:

• Simulink Subsystems

• Stateflow States

• MATLAB Functions

• MATLAB Methods

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, in the Component Structure section, point to the Depth widget and click the Run metrics for widget icon . The Depth widget shows the maximum depth found in the current unit or component. If you click on the Depth widget, you can view a table that shows the depth for each model component.

• Use getMetrics with the metric identifier slcomp.MaxLayerDepth.

Results

For this metric, instances of metric.Result return Value as the integer value for the maximum number of layers deep a model component is in the model hierarchy for a unit or component.

Examples

Suppose you have a unit, u1, that contains only a subsystem, s1, and subsystem s1 contains only subsystem s2. u1 is at layer depth 1, s1 is at layer depth 2, and s2 is at layer depth 3. The maximum layer depth is 3 because 3 is the maximum of the layer depth values associated with the unit. You can view the layer depth associated with each child model component in the Metric Details table by clicking on the Depth widget.

Capabilities and Limitations

The metric:

• Does not count model references or subsystem references.

• Does not count relationships to data dictionaries.

• Does not count relationships to other units. For example, if you have a component with a required relationship to another model that is a unit, that relationship is not included in the metric count. The metric only analyzes the relationship if the other model is not a unit.

See Also

For information on finding the layer depth for each layer of a unit or component, see Layer Depth.

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

Layer Breadth

Metric ID: slcomp.LayerBreadth

Determine the number of child model components that each artifact contains.

Description

Use this metric to count the number of child model components that each artifact contains. A layer is a parent or child model component in the model hierarchy.

This metric counts the following model components:

• Simulink Subsystems

• Stateflow states

• MATLAB Function blocks

• External MATLAB functions and classes

• MATLAB methods

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, in the Component Structure section, point to the Breadth widget and click the Run metrics for widget icon . The Breadth widget shows the maximum breadth found in the current unit or component. If you click on the Breadth widget, you can view a table that shows the breadth for each artifact.

• Use getMetrics with the metric identifier slcomp.LayerBreadth.

Results

For this metric, instances of metric.Result return Value as the integer value for the number of child model components that each artifact contains.

Examples

Suppose you have a unit, u2, that contains two subsystems: c1 and c2. The layer breadth for the unit u2 is 2 because there are 2 child model components directly associated with the unit.

Capabilities and Limitations

The metric:

• Includes model references as child model components.

• Does not count relationships to data dictionaries. For example, suppose that you have a block diagram that contains a subsystem and requires a Simulink Data Dictionary (SLDD) file. The metric returns a layer breadth of one, not two.

• Does not count relationships to other units. For example, if you have a component with a required relationship to another model that is a unit, that relationship is not included in the metric count. The metric only counts the relationship if the other model is not a unit.

See Also

For information on finding the maximum layer breadth for a unit or component, see Maximum Layer Breadth.

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

Maximum Layer Breadth

Metric ID: slcomp.MaxLayerBreadth

Determine the maximum number of child model components that a single model layer in the unit or component contains.

Description

Use this metric to determine the maximum number of child model components that a single model layer in the unit or component contains.

This metric analyzes these model components:

• Simulink Block Diagrams

• Simulink Subsystems

• Stateflow Charts

• MATLAB Functions

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, in the Component Structure section, point to the Breadth widget and click the Run metrics for widget icon . The Breadth widget shows the maximum breadth found in the current unit or component. If you click on the Breadth widget, you can view a table that shows the breadth for each artifact.

• Use getMetrics with the metric identifier slcomp.MaxLayerBreadth.

Results

For this metric, instances of metric.Result return Value as the integer value for the maximum number of child model components for a unit or component.

Examples

Suppose you have a unit, u3, that contains three subsystems: e1, e2, and e3. e1 has a layer breadth of 2, e2 has a layer breadth of three, and e3 has a layer breadth of four. The maximum layer breadth for the unit is four because that is the maximum of the layer breadth values associated with the child model components for the unit. You can view the layer breadth associated with each child model component in the Metric Details table by clicking on the Breadth widget.

Capabilities and Limitations

The metric:

• Includes model references as child model components.

• Does not count relationships to data dictionaries. For example, suppose that you have a block diagram that contains a subsystem and requires a Simulink Data Dictionary (SLDD) file. The layer breadth for the model component is one, not two.

• Does not count relationships to other units. For example, if you have a component with a required relationship to another model that is a unit, that relationship is not included in the metric count. The metric only analyzes the relationship if the other model is not a unit.

See Also

For information on finding the layer breadth for each layer of a unit or component, see Layer Breadth.

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

Input and Output Component Interface Ports

Metric ID: slcomp.InterfacePorts

Determine the number of input ports and output ports to the component interface.

Description

Use this metric to count the number of input ports and output ports to the component interface.

This metric counts:

• Simulink Inport blocks

• Simulink Outport blocks

• Input ports for Stateflow charts

• Output ports for Stateflow charts

• Inputs and outputs to MATLAB code

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, in the Component Interface section, point to the Input Ports or Output Ports widgets and click the Run metrics for widget icon .

• Use getMetrics with the metric identifier slcomp.InterfacePorts.

Results

For this metric, instances of metric.Result return the Value as an integer vector that contains these elements:

• Value(1) — The number of input component interface ports. This corresponds to the Input Ports widget in the Component Interface section.

• Value(2) — The number of output component interface ports. This corresponds to the Output Ports widget in the Component Interface section.

The results of this metric correspond to the Input Ports and Output Ports widgets in the Component Interface section.

Examples

Suppose your component is a model that has eleven Inport blocks and five Outport blocks, this metric returns a Result array with a Value property of [11, 5].

Capabilities and Limitations

The metric returns the number of component interfaces.

See Also

For information on finding the number of interface signals for a unit or component, see Input and Output Component Interface Signals.

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

Input and Output Component Interface Signals

Metric ID: slcomp.ComponentInterfaceSignals

Determine the number of input signals and output signals that connect to the component interface.

Description

Use this metric to count the number of root-level, input signals and output signals that connect to the component interface.

This metric counts signals to or from:

• Simulink Inport blocks

• Simulink Outport blocks

• Input ports for Stateflow charts

• Output ports for Stateflow charts

• Inputs and outputs to MATLAB code

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, in the Component Interface section, point to the Input Signals or Output Signals widgets and click the Run metrics for widget icon .

• Use getMetrics with the metric identifier slcomp.ComponentInterfaceSignals.

Results

For this metric, instances of metric.Result return the Value as an integer vector that contains these elements:

• Value(1) — The number of input component interface signals. This corresponds to the Input Signals widget in the Component Interface section.

• Value(2) — The number of output component interface signals. This corresponds to the Output Signals widget in the Component Interface section.

The results of this metric correspond to the Input Signals and Output Signals widgets in the Component Interface section.

Examples

Suppose your unit is a model that has six Inport blocks and two Outport blocks that connect to your component, this metric returns a Result array with a Value property of [6, 2].

Capabilities and Limitations

The metric:

• Returns the number of component interface signals. If the data type of an input or output is Bus, the metric counts the individual elements in the bus.

• Displays a warning if the data type of an input or output is set to 'Inherit: auto'. The metric is unable to resolve inherited data types. Specify valid data types, other than 'Inherit: auto', for root outports and inports.

• Displays a warning if the 'HasAccessToBaseWorkspace' property for a model is set to true. Data type definitions accessed from the base workspace are not considered by traceability analysis. Changes to base workspace variables will not cause the metric to be recollected.

See Also

For information on finding the number of component interfaces, see Input and Output Component Interface Ports.

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

Design Cyclomatic Complexity Breakdown

The design cyclomatic complexity is the number of possible execution paths through a design. In general, the more paths there are through a design, the more complex the design is. When you keep the design cyclomatic complexity low, the design typically is easier to read, maintain, and test. The design cyclomatic complexity is calculated as the number of decision paths plus one. The metric adds one to account for the execution path represented by the default path. The design cyclomatic complexity includes the default path because the metric identifies each possible outcome from an execution path, including the default outcome.

For example, the design cyclomatic complexity of an if-else statement is two because the if statement represents one decision and the else statement represents the default path. The default path is not included in the number of decisions because no decision is made to reach a default state.

function y = fcn(u)
    if u < 0 % one decision
        y = -1*u;
    else % default path, zero decisions
        y = u;
    end
end

The Design Cyclomatic Complexity Breakdown section of the dashboard shows the sources of design cyclomatic complexity for a component or unit in your design.

In the Design Cyclomatic Complexity Breakdown section of the dashboard:

• The Complexity column shows:

  • Simulink Design Cyclomatic Complexity

  • Stateflow Design Cyclomatic Complexity

  • MATLAB Design Cyclomatic Complexity

• The Distribution column shows:

  • Simulink Decision Distribution

  • Stateflow Decision Distribution

  • MATLAB Decision Distribution

When you drill in to a widget in the Design Cyclomatic Complexity Breakdown section of the dashboard, you can view the Metric Details associated with the metrics for:

• Simulink Decision Count

• Stateflow Decision Count

• MATLAB Decision Count

Simulink Design Cyclomatic Complexity

Metric ID: slcomp.SLCyclomaticComplexity

Determine the design cyclomatic complexity of the Simulink model components in your design.

Description

The design cyclomatic complexity is the number of possible execution paths through a design. In general, the more paths there are through a design, the more complex the design is. When you keep the design cyclomatic complexity low, the design typically is easier to read, maintain, and test. The design cyclomatic complexity is calculated as the number of decision paths plus one. The metric adds one to account for the execution path represented by the default path. The design cyclomatic complexity includes the default path because the metric identifies each possible outcome from an execution path, including the default outcome.

Use the Simulink design cyclomatic complexity metric to determine the design cyclomatic complexity of the Simulink model components in your design.

This metric counts the total number of Simulink-based execution paths through a unit or component. The number of execution paths is calculated as the number of Simulink decisions, Simulink Decision Count, plus one for the default path. The default path is only counted once per unit or component.

To see the number of Simulink decisions associated with different block types, see Decision Counts for Common Block Types.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.SLCyclomaticComplexity.

Results

For this metric, instances of metric.Result return Value as the integer value for the Simulink design cyclomatic complexity of a unit or component.

Examples

Suppose you have a unit that contains only an Abs block with an input u.

The Abs block can be treated as an if-else statement:

• If the input to the Abs block is less than zero, the output of the Abs block is the input multiplied by negative one.

• Otherwise, by default, the output of the Abs block is equal to the input of the Abs block.

if (input < 0) % one decision
  output = -1*input;
else % default path, zero decisions
  output = input;
end

For an if-else statement, the number of decisions is one because the if statement represents one decision and the else statement represents the default behavior. The execution path follows the default path if no decisions are made.

In this example, the number of Simulink decisions is 1 and therefore the Simulink design cyclomatic complexity of the unit is 2.

The value of the Simulink design cyclomatic complexity represents the two possible execution paths through the unit, either:

• u < 0 and the output of the Abs block is the input multiplied by negative 1

• u ≥ 0 and the output of the Abs block is equal to the input of the Abs block

Capabilities and Limitations

The metric does not exclude decisions associated with short-circuiting logical operations because Simulink runs a block regardless of whether or not a previous input alone determined the block output.

For example, in Simulink an AND block with repeating inputs runs regardless of whether or not the previous input alone determined the block output.

See Also

For information on how the metric calculates the number of Simulink decisions, see Simulink Decision Count.

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

Simulink Decision Count

Metric ID: slcomp.SimulinkDecisions

Determine the number of Simulink decisions in each layer of a unit or component.

Description

Use this metric to count the number of Simulink decisions in the Simulink blocks in each layer of a unit or component.

Decision Counts for Common Block Types

The following table shows how the metric calculates the decision count for common Simulink blocks.

 Decision Counts Table

Block	Decision Count	Description
Abs	1	For the decision count, the Abs block can be treated as an if-else statement: If the input to the Abs block is less than zero, the output of the Abs block is the input multiplied by negative 1. Otherwise, by default, the output of the Abs block is equal to the input of the Abs block. if (input < 0) % one decision output = -1*input; else % default path, zero decisions output = input; end An if-else statement has a decision count of 1 because the if statement represents one decision and the else statement represents the default behavior (no decisions made).
Cominatorial Logic	Is equal to the number of rows in the Truth table parameter) minus 1	The decision count depends on the number of rows in the truth table. If a truth table contains five rows, the decision count is 4. One row in the truth table contains the default output and the other four rows contain potential outputs that depend on a decision being made.
Dead Zone	2	The output of the Dead Zone block depends on the block input (U) and the values of the Start of dead zone(lower limit, LL) and End of dead zone (upper limit, UL) parameters. For the decision count, the Dead Zone block can be treated as an if-elseif-else statement: If U >= LL and U <= UL, the output is 0. If U > UL, the output is U - UL. Otherwise, the output is U - LL. if ((U >= LL) & (U <= UL)) % one decision output = 0; elseif (U > UL) % one decision output = U - UL; else % default path, zero decisions output = U - LL; end An if-elseif-else statement has a decision count of 2 because the if statement represents one decision, the elseif statement represents one decision, and the else statement represents the default behavior (no decisions made).
Discrete-Time Integrator	Is equal to either 0, 2, 3, or 5	The decision count depends on the External reset parameter and the Limit output parameter. If External reset is set to none and the Limit output check box is unselected, the decision count is 0. This is the default behavior for the Discrete-Time Integrator block. If External reset is set to a value other than none and the Limit output check box is unselected, the decision count is 2. If External reset is set to none and the Limit output check box is selected, the decision count is 3. If External reset is set to a value other than none and the Limit output check box is selected, the decision count is 5.
Enabled Subsystem	1	For the decision count, the Enabled Subsystem block can be treated as an if-else statement: If the subsystem is enabled, the subsystem executes. Otherwise, by default, the subsystem does not execute. An if-else statement has a decision count of 1 because the if statement represents one decision and the else statement represents the default behavior (no decisions made).
Enabled and Triggered Subsystem	1	For the decision count, the Enabled and Triggered Subsystem block can be treated as an if-else statement: If the subsystem is enabled and triggered, the subsystem executes. Otherwise, by default, the subsystem does not execute. An if-else statement has a decision count of 1 because the if statement represents one decision and the else statement represents the default behavior (no decisions made).
For Iterator Subsystem	1	For the decision count, the For Iterator block can be treated as an if-else statement: If the iteration value is less than or equal to the iteration limit, iterate over blocks in the For Iterator Subsystem block. Otherwise, the subsystem does not execute. An if-else statement has a decision count of 1 because the if statement represents one decision and the else statement represents the default behavior (no decisions made).
If	Is equal to the number of if and elseif expressions	Each if statement represents a decision and each elseif statement represents a decision. The decision count is equal to the number of if and elseif statements. For example, the following code contains one if statement and one elseif statement and therefore has a decision count of 2: if (u > 0) % one decision y = 1; elseif (u < 0) % one decision y = 2; else % default path, zero decisions y = 0; end
Index Vector	1	The Index Vector block is associated with a decision count of 1. The Index Vector block is a special configuration of the Multiport Switch block in which you specify one data input and the control input is zero-based. For example, if the input vector is [18 15 17 10] and the control input is 3 (zero-based index), the output is 10. Using the control input to index into the input vector is considered a single decision.
Multiport Switch	Is equal to the number of data ports minus 1	The decision count for the Multiport Switch block depends on the number of data ports that are inputs to the block. The number of data ports represents the number of possible outcomes. The decision count equals the number of data ports minus 1 because one of the possible outcomes is the default path. For the default path, no decision was made. For example, if the number of data inputs is 3, then the decision count is 2. If there is only one data port, the Multiport Switch block acts as an Index Vector block and has a decision count of 1.
Rate Limiter	2	The output of the Rate Limiter block is determined by comparing rate to the Rising slew rate (R) and Falling slew rate (F) parameters. For the decision count, the Rate Limiter block can be treated as an if-elseif-else statement: If rate is greater than R, the output is calculated using the rising slew rate. If rate is less than F, the output is calculated using the falling slew rate. Otherwise, the rate is between the bounds of R and F and the change in output is equal to the change in input. An if-elseif-else statement has a decision count of 2 because the if statement represents one decision, the elseif statement represents one decision, and the else statement represents the default behavior (no decisions made).
Relay	2	The output of the Relay block is determined by the Switch off point and the Switch on point parameters. For the decision count, the Relay block can be treated as an if-elseif-else statement: If the relay is on, the output remains on until the input drops below the value of the Switch off point parameter. If the relay is off, the output remains off until the input exceeds the value of the Switch on point parameter. Otherwise, the input falls between the Switch off point and the Switch on point and the output is unchanged. An if-elseif-else statement has a decision count of 2 because the if statement represents one decision, the elseif statement represents one decision, and the else statement represents the default behavior (no decisions made).
Saturation	2	The output of the Saturation block is determined by comparing the input to the Upper limit and Lower limit parameters. For the decision count, the Saturation block can be treated as an if-elseif-else statement: If the input is less than the Lower limit, the output is equal to the value of the Lower limit. If the input is greater than the Upper limit, the output is equal to the value of the Upper limit. Otherwise, the output is equal to the value of the input. An if-elseif-else statement has a decision count of 2 because the if statement represents one decision, the elseif statement represents one decision, and the else statement represents the default behavior (no decisions made).
Switch	1	The Switch block is associated with a decision count of 1: If input 2 (the control input) satisfies the selected criterion, the output is equal to input 1. Otherwise, the output is equal to input 3. For example, the following code shows a decision count of 1: switch (u2 > 0) case 1 % one decision y = u1; otherwise % default path, zero decisions y = u3; end
Switch Case	Is equal to the number of outports minus 1	The default case represents the default behavior (no decisions made). But each subsequent case represents a decision. The decision count is equal to the number of outports minus 1. For example, the following code represents a Switch Case block with 3 outputs and has a decision count of 2: switch u1 case 1 % one decision y = port1; case 2 % one decision y = port2; otherwise % default path, zero decisions y = port3; end
Triggered Subsystem	1	For the decision count, the Triggered Subsystem block can be treated as an if-else statement: If the subsystem is triggered, the subsystem executes. Otherwise, by default, the subsystem does not execute. An if-else statement has a decision count of 1 because the if statement represents one decision and the else statement represents the default behavior (no decisions made).

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.SimulinkDecisions.

Results

For this metric, instances of metric.Result return Value as the integer value for the number of Simulink decisions in the Simulink blocks in each layer of a unit or component.

Examples

To see the number of Simulink decisions associated with different block types, see Decision Counts for Common Block Types.

Capabilities and Limitations

The metric does not exclude decisions associated with short-circuiting logical operations because Simulink runs a block regardless of whether or not a previous input alone determined the block output.

For example, in Simulink an AND block with repeating inputs runs regardless of whether or not the previous input alone determined the block output.

See Also

For related metrics, see:

• Simulink Design Cyclomatic Complexity

• Simulink Decision Distribution

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

Simulink Decision Distribution

Metric ID: slcomp.SimulinkDecisionDistribution

Determine the distribution of the number of Simulink decisions in a unit or component.

Description

Use this metric to determine the distribution of the number of Simulink decisions in a unit or component. For information on how the metric calculates the number of Simulink decisions, see Simulink Decision Count.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.SimulinkDecisionDistribution.

Results

For this metric, instances of metric.Result return Value as a distribution structure that contains these fields:

• BinCounts — The number of artifacts in each bin, returned as an integer vector.

• BinEdges — Bin edges for the number of Simulink decisions, returned as an integer vector. BinEdges(1) is the left edge of the first bin and BinEdges(end) is the right edge of the last bin. The length of BinEdges is one more than the length of BinCounts.

The bins in this metric result correspond to the bins in the Simulink row and Distribution column in the Design Cyclomatic Complexity Breakdown section.

Examples

Suppose your unit has:

• 16 model layers that each make between zero and nine Simulink decisions

• 41 model layers that each make between 10 and 19 Simulink decisions

• 100 model layers that each make between 20 and 29 Simulink decisions

The Value structure contains:

ans = 

  struct with fields:

    BinCounts: [16 41 100 0 0 0 0 0 0 0]
     BinEdges: [0 10 20 30 40 50 60 70 80 90 18446744073709551615]

There are 10 bins in the Simulink decision distribution. BinCounts shows the number of model layers in each bin and BinEdges shows the edges of each bin. The last bin edge is 18446744073709551615, which is the upper limit of the decision count.

For this example, there are 16 model layers in the first bin, 41 model layers in the second bin, and 100 model layers in the third bin, and no model layers in the other seven bins.

You can view the distribution bins in the Model Maintainability Dashboard. Point to a distribution bin to see tooltip information on the number of model layers and decisions associated with the bin.

See Also

For information on how the metric calculates the number of Simulink decisions, see Simulink Decision Count.

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

Stateflow Design Cyclomatic Complexity

Metric ID: slcomp.SFCyclomaticComplexity

Determine the design cyclomatic complexity of the Stateflow components in your design.

Description

The design cyclomatic complexity is the number of possible execution paths through a design. In general, the more paths there are through a design, the more complex the design is. When you keep the design cyclomatic complexity low, the design typically is easier to read, maintain, and test. The design cyclomatic complexity is calculated as the number of decision paths plus one. The metric adds one to account for the execution path represented by the default path. The design cyclomatic complexity includes the default path because the metric identifies each possible outcome from an execution path, including the default outcome.

Use the Stateflow design cyclomatic complexity metric to determine the design cyclomatic complexity for the Stateflow components in your design.

This metric counts the total number of Stateflow-based execution paths through a unit or component. The total number of execution paths is calculated as the number of Stateflow decisions, Stateflow Decision Count, plus one for the default path. The default path is only counted once per unit or component.

To see the number of Stateflow decisions associated with different Stateflow components, see Decision Counts for Common Stateflow Components.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.SFCyclomaticComplexity.

Results

For this metric, instances of metric.Result return Value as the integer value for the Stateflow design cyclomatic complexity of a unit or component.

Examples

Suppose you have a unit that contains only a Truth Table block from the Stateflow library. By default, the Truth Table block contains a Condition Table with two condition rows and three decision columns and an Action Table with two actions.

To see the number of Stateflow decisions associated with different Stateflow components, see Decision Counts for Common Stateflow Components.

For the Truth Table block, the number of graphical decisions is calculated as the number of conditions (rows) multiplied by the number of decisions (columns) in the Condition Table. In this example, the number of graphical decisions is equal to 2 multiplied by 3.

For the Truth Table block, the number of MATLAB code decisions is calculated as the number of decisions in the Action Table. In this example, there are no decisions made in the code of the Action Table.

The Stateflow design cyclomatic complexity is equal to the sum of the number of graphical Stateflow decisions, plus the number of MATLAB code decisions in the Stateflow component, plus one (for the default path). In this case, the Stateflow design cyclomatic complexity is calculated as 6 + 0 + 1 which equals seven.

Capabilities and Limitations

The metric:

• Only supports Stateflow objects that use MATLAB as the action language.

• Analyzes Stateflow charts that use C as the action language, but does not represent decisions from short-circuiting in logical operations.

See Also

For information on how the number of Stateflow decisions is calculated, see Stateflow Decision Count.

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

Stateflow Decision Count

Metric ID: slcomp.StateflowDecisions

Determine the number of Stateflow decisions in each layer of a unit or component.

Description

Use this metric to count the number of Stateflow decisions in the Stateflow model components in each layer of a unit or component.

Decision Counts for Common Stateflow Components

The metric returns both graphical decisions and MATLAB code decisions. Graphical decisions are decisions based on the connections drawn graphically in a Stateflow chart. MATLAB code decisions are decisions based on code written in the MATLAB action language used in a Stateflow chart.

The following table shows how the metric calculates the decision count for common Stateflow components.

 Decision Counts Table

Component	Graphical Decision Count	MATLAB Code Decision Count
Transitions	Is equal to the number of transitions with conditions	Is equal to the number of short-circuit operations (&& and ||) in conditions
States	Is equal to the number of states minus the default state	Is equal to the number of transitions with conditions plus the number of states minus 1 (This includes decisions in Entry, During, and Exit Actions.)
Truth Tables	Is equal to the number of conditions multiplied by the number of decisions in the Condition Table	Is equal to the number of code decisions in the Action Table

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.StateflowDecisions.

Results

For this metric, instances of metric.Result return Value as the integer value for the number of Stateflow decisions in each layer of a unit or component.

Examples

To see the number of Stateflow decisions associated with different Stateflow components, see Decision Counts for Common Stateflow Components.

See Also

For related metrics, see:

• Stateflow Design Cyclomatic Complexity

• Stateflow Decision Distribution

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

Stateflow Decision Distribution

Metric ID: slcomp.StateflowDecisionsDistribution

Determine the distribution of the number of Stateflow decisions in each layer of a unit or component.

Description

Use this metric to determine the distribution of the number of Stateflow decisions in the Stateflow model components in each layer of a unit or component. For information on how the number of Stateflow decisions is calculated, see Stateflow Decision Count.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.StateflowDecisionsDistribution.

Results

For this metric, instances of metric.Result return Value as a distribution structure that contains these fields:

• BinCounts — The number of artifacts in each bin, returned as an integer vector.

• BinEdges — Bin edges for the number of Stateflow decisions, returned as an integer vector. BinEdges(1) is the left edge of the first bin and BinEdges(end) is the right edge of the last bin. The length of BinEdges is one more than the length of BinCounts.

The bins in this metric result correspond to the bins in the Stateflow row and Distribution column in the Design Cyclomatic Complexity Breakdown section.

See Also

For information on how the number of Stateflow decisions is calculated, see Stateflow Decision Count.

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

MATLAB Design Cyclomatic Complexity

Metric ID: slcomp.MatlabCyclomaticComplexity

Determine the design cyclomatic complexity of the MATLAB code in your design.

Description

The design cyclomatic complexity is the number of possible execution paths through a design. In general, the more paths there are through a design, the more complex the design is. When you keep the design cyclomatic complexity low, the design typically is easier to read, maintain, and test. The design cyclomatic complexity is calculated as the number of decision paths plus one. The metric adds one to account for the execution path represented by the default path. The design cyclomatic complexity includes the default path because the metric identifies each possible outcome from an execution path, including the default outcome.

Use this metric to determine the design cyclomatic complexity of the MATLAB code in your design.

The MATLAB design cyclomatic complexity is the total number of execution paths through the MATLAB code in a unit or component. The number of execution paths is calculated as the number of MATLAB decisions, MATLAB Decision Count, plus one for the default path. The default path is only counted once per unit or component.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.MatlabCyclomaticComplexity.

Results

For this metric, instances of metric.Result return Value as the integer value for the MATLAB design cyclomatic complexity of a unit or component.

Examples

Suppose you have a unit that contains only a MATLAB Function block with this code:

function y = fcn(u)
    if u < 0 % one decision
        y = -1*u;
    else % default path, zero decisions
        y = u;
    end
end

For an if-else statement, the number of decisions is one because the if statement represents one decision and the else statement represents the default behavior. The execution path follows the default path if no decisions are made.

• If the input to the MATLAB Function block is less than zero, the output of the MATLAB Function block is the input multiplied by negative one.

• Otherwise, by default, the output of the MATLAB Function block is equal to the input of the MATLAB Function block.

In this example, the number of MATLAB decisions is one and therefore the MATLAB design cyclomatic complexity of the unit is two. The default path is not included in the number of decisions because no decision is made to reach a default state, but the default path is included in the design cyclomatic complexity.

The value of the MATLAB design cyclomatic complexity represents the two possible execution paths through the unit, either:

• u < 0 and the output of the MATLAB Function block is the input multiplied by negative one

• u ≥ 0 and the output of the MATLAB Function block is equal to the input of the MATLAB Function block

Capabilities and Limitations

The metric includes the decisions associated with logical operations that might be short-circuited during code execution.

See Also

For information on how the number of MATLAB decisions is calculated, see MATLAB Decision Count.

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

MATLAB Decision Count

Metric ID: slcomp.MATLABDecisions

Determine the number of decisions in MATLAB code associated with a unit or component.

Description

Use this metric to count the number of decisions in MATLAB code associated with a unit or component.

This metric analyzes:

• MATLAB functions in Simulink, including MATLAB Function blocks and Interpreted MATLAB Function blocks

• MATLAB functions in Stateflow objects

• Functions and methods in MATLAB files

Decision Counts for Common MATLAB Keywords

The following table shows how the metric calculates the decision count for common MATLAB keywords.

 Decision Counts Table

Keyword	Decision Count	Description
case	Is equal to the number of case statements	Each case statement represents a decision in the code.
catch	0	The catch statement represents a default behavior. The default path is not included in the number of decisions because no decision is made to reach a default state.
else	0	The else statement represents a default behavior. The default path is not included in the number of decisions because no decision is made to reach a default state.
elseif	Is equal to the number of elseif statements	Each elseif statement represents a decision in the code.
if	Is equal to the number of if statements	Each if statement represents a decision in the code.
otherwise	0	The otherwise statement represents a default behavior. The default path is not included in the number of decisions because no decision is made to reach a default state.
parfor	Is equal to the number of parfor statements	Each parfor statement represents a decision in the code.
try	Is equal to the number of try statements	Each try statement represents a decision in the code.
while	Is equal to the number of while statements	Each while statement represents a decision in the code.

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, in the Design Cyclomatic Complexity Breakdown section, click the Run metrics for widget icon . The distribution of the decisions appears in the MATLAB row and Distribution column. To view a table that shows the MATLAB decision count for each model component, click one of the bins in the distribution.

• Use getMetrics with the metric identifier slcomp.MATLABDecisions.

Results

For this metric, instances of metric.Result return Value as the integer value for the number of MATLAB decisions in the MATLAB code associated with each layer of a unit or component.

Examples

Suppose you have a unit that contains only a MATLAB Function block with this code:

function y = fcn(u)
    if u < 0 % one decision
        y = -1*u;
    else % default path, zero decisions
        y = u;
    end
end

For an if-else statement, the number of decisions is one because the if statement represents one decision and the else statement represents the default behavior. The execution path follows the default path if no decisions are made.

• If the input to the MATLAB Function block is less than zero, the output of the MATLAB Function block is the input multiplied by negative one.

• Otherwise, by default, the output of the MATLAB Function block is equal to the input of the MATLAB Function block.

In this example, the number of MATLAB decisions is one.

Suppose the code includes elseif statements:

function y = fcn(u)
    if u < 0 % one decision
        y = -1*u;
    elseif u = 1; % one decision
        y = 1;
    elseif u = 2; % one decision
        y = 2;
    else % default path, zero decisions
        y = u;
    end
end

The number of MATLAB decisions increases by one for each additional elseif statement in the code. MATLAB code that contains one if statement, two elseif statements, and one else statement contains three decisions. The else statement does not contribute to the number of decisions because the else statement is part of the default path. The default path is not included in the number of decisions because no decision is made to reach a default state.

Capabilities and Limitations

The metric:

• Calculates the number of decisions in MATLAB code by taking the cyclomatic complexity calculated by the Code Analyzer and subtracting one to exclude the default path. For more information, see checkcode.

• Counts decisions from if, elseif, while, for, parfor, try, and case statements.

• Ignores else, otherwise, and catch statements because they form the default path.

See Also

For related metrics, see:

• MATLAB Design Cyclomatic Complexity

• MATLAB Decision Distribution

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

MATLAB Decision Distribution

Metric ID: slcomp.MATLABDecisionsDistribution

Determine the distribution of the number of decisions in MATLAB code.

Description

Use this metric to determine the distribution of the number of decisions in MATLAB code.

This metric analyzes the MATLAB functions and methods in:

• MATLAB files

• MATLAB Function blocks

For information on how the number of MATLAB decisions is calculated, see MATLAB Decision Count.

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, in the Design Cyclomatic Complexity Breakdown section, click the Run metrics for widget icon . The distribution of decisions appears in the MATLAB row and Distribution column.

• Use getMetrics with the metric identifier slcomp.MATLABDecisionsDistribution.

Results

For this metric, instances of metric.Result return Value as a distribution structure that contains these fields:

• BinCounts — The number of artifacts in each bin, returned as an integer vector.

• BinEdges — Bin edges for the number of MATLAB decisions, returned as an integer vector. BinEdges(1) is the left edge of the first bin and BinEdges(end) is the right edge of the last bin. The length of BinEdges is one more than the length of BinCounts.

The bins in this metric result correspond to the bins in the MATLAB row and Distribution column in the Design Cyclomatic Complexity Breakdown section.

See Also

For information on how the number of MATLAB decisions is calculated, see MATLAB Decision Count.

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

Simulink Architecture

The Simulink Architecture section of the dashboard shows the number of Simulink blocks, signal lines, and Goto blocks in the layers of your unit or component.

In the Simulink Architecture section of the dashboard:

• The Count column shows:

  • Overall Blocks

  • Overall Signal Lines

  • Overall Goto Blocks

• The Distribution column shows:

  • Simulink Blocks Distribution

  • Simulink Signal Lines Distribution

  • Simulink Goto Blocks Distribution

When you drill in to a widget in the Simulink Architecture section of the dashboard, you can view the Metric Details associated with the metrics for:

• Simulink Blocks

• Simulink Signal Lines

• Simulink Goto Blocks

Overall Blocks

Metric ID: slcomp.OverallBlocks

Determine the overall number of blocks in a unit or component.

Description

Use this metric to count the total number of blocks in a unit or component.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.OverallBlocks.

Results

For this metric, instances of metric.Result return Value as the integer value for the number of overall blocks that a unit or component contains.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Simulink Blocks

• Simulink Blocks Distribution

Simulink Blocks

Metric ID: slcomp.SimulinkBlocks

Determine the number of Simulink blocks, excluding Inport, Outport, and Goto blocks, in each layer of a unit or component.

Description

Use this metric to count the of the number of Simulink blocks, excluding Inport, Outport, and Goto blocks, in each layer of the model hierarchy for a unit or component.

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, point to the Simulink Architecture section and click the Run metrics for widget icon . If you click on the widget in the Blocks row and Count column, you can view a table that shows the number of Simulink blocks, excluding Inport, Outport, and Goto blocks, in each layer of a unit or component.

• Use getMetrics with the metric identifier slcomp.SimulinkBlocks.

Results

For this metric, instances of metric.Result return Value as the integer value for the number of Simulink blocks, excluding Inport, Outport, and Goto blocks, in each layer of a unit or component.

Capabilities and Limitations

The metric:

• Does not include Inport, Outport, and Goto blocks in the block count.

• Counts the blocks, excluding Inport, Outport, and Goto blocks, in each variant.

• Does not count blocks that are commented out.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Overall Blocks

• Simulink Blocks Distribution

Simulink Blocks Distribution

Metric ID: slcomp.BlocksDistribution

Determine the distribution of the number of Simulink blocks, excluding Inport, Outport, and Goto blocks, in each layer of a unit or component.

Description

Use this metric to determine the distribution of the number of Simulink blocks, excluding Inport, Outport, and Goto blocks, in each layer of the model hierarchy for a unit or component.

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, point to the Simulink Architecture section and click the Run metrics for widget icon . See the results in the Blocks row and Distribution column.

• Use getMetrics with the metric identifier slcomp.BlocksDistribution.

Results

For this metric, instances of metric.Result return Value as a distribution structure that contains these fields:

• BinCounts — The number of artifacts in each bin, returned as an integer vector.

• BinEdges — Bin edges for the number of blocks, excluding Inport, Outport, and Goto blocks, in each layer of a unit or component, returned as an integer vector. BinEdges(1) is the left edge of the first bin and BinEdges(end) is the right edge of the last bin. The length of BinEdges is one more than the length of BinCounts.

The bins in this metric result correspond to the bins in the Blocks row and Distribution column in the Simulink Architecture section.

Capabilities and Limitations

The metric:

• Does not include Inport, Outport, and Goto blocks in the block count.

• Counts the blocks, excluding Inport, Outport, and Goto blocks, in each variant.

• Does not count blocks that are commented out.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Overall Blocks

• Simulink Blocks

Overall Signal Lines

Metric ID: slcomp.OverallSignalLines

Determine the overall number of signal lines in a unit or component.

Description

Use this metric to count the total number of signal lines in a unit or component.

The metric uses find_system to find the signal lines.

The metric includes:

• Simulink signal lines that the model uses

• Commented lines

• Each individual branch line

• Unterminated lines

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.OverallSignalLines.

Results

For this metric, instances of metric.Result return Value as the integer value for the overall number of signal lines in a unit or component.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Simulink Signal Lines

• Simulink Signal Lines Distribution

Simulink Signal Lines

Metric ID: slcomp.SimulinkSignalLines

Determine the number of signal lines in each layer of a unit or component.

Description

Use this metric to count the number of signal lines in each layer of a unit or component.

The metric uses find_system to find the signal lines.

The metric includes:

• Simulink signal lines that the model uses

• Commented lines

• Each individual branch line

• Unterminated lines

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.SimulinkSignalLines.

Results

For this metric, instances of metric.Result return Value as the integer value for the number of signal lines in each layer of a unit or component.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Overall Signal Lines

• Simulink Signal Lines Distribution

Simulink Signal Lines Distribution

Metric ID: slcomp.SignalLinesDistribution

Determine the distribution of the number of signal lines in a unit or component.

Description

Use this metric to determine the distribution of the number of signal lines in a unit or component.

The metric uses find_system to find the signal lines.

The metric includes:

• Simulink signal lines that the model uses

• Commented lines

• Each individual branch line

• Unterminated lines

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.SignalLinesDistribution.

Results

For this metric, instances of metric.Result return Value as a distribution structure that contains these fields:

• BinCounts — The number of artifacts in each bin, returned as an integer vector.

• BinEdges — Bin edges for the number of signal lines, returned as an integer vector. BinEdges(1) is the left edge of the first bin and BinEdges(end) is the right edge of the last bin. The length of BinEdges is one more than the length of BinCounts.

The bins in this metric result correspond to the bins in the Signal Lines row and Distribution column in the Simulink Architecture section.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Overall Signal Lines

• Simulink Signal Lines

Overall Goto Blocks

Metric ID: slcomp.OverallGotos

Determine the overall number of Goto blocks in a unit or component.

Description

Use this metric to count the total number of Goto blocks in a unit or component.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.OverallGotos.

Results

For this metric, instances of metric.Result return Value as the integer value for the overall number of Goto blocks in a unit or component.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Simulink Goto Blocks

• Simulink Goto Blocks Distribution

Simulink Goto Blocks

Metric ID: slcomp.SimulinkGotos

Determine the number of Simulink Goto blocks in each layer of a unit or component.

Description

Use this metric to count the number of Simulink Goto blocks in each layer of a unit or component.

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, point to the Simulink Architecture section and click the Run metrics for widget icon . If you click on the widget in the Gotos row and Count column, you can view a table that shows the number of Goto blocks in each layer of a unit or component.

• Use getMetrics with the metric identifier slcomp.SimulinkGotos.

Results

For this metric, instances of metric.Result return Value as the integer value for the number of Goto blocks in each layer of a unit or component.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Overall Goto Blocks

• Simulink Goto Blocks Distribution

Simulink Goto Blocks Distribution

Metric ID: slcomp.GotosDistribution

Determine the distribution of the number of Simulink Goto blocks in each layer of a unit or component.

Description

Use this metric to determine the distribution of the number of Simulink Goto blocks in each layer of a unit or component.

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, point to the Simulink Architecture section and click the Run metrics for widget icon .

• Use getMetrics with the metric identifier slcomp.GotosDistribution.

Results

For this metric, instances of metric.Result return Value as a distribution structure that contains these fields:

• BinCounts — The number of artifacts in each bin, returned as an integer vector.

• BinEdges — Bin edges for the number of Goto blocks in each layer of a unit or component, returned as an integer vector. BinEdges(1) is the left edge of the first bin and BinEdges(end) is the right edge of the last bin. The length of BinEdges is one more than the length of BinCounts.

The bins in this metric result correspond to the bins in the Gotos row and Distribution column in the Simulink Architecture section.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Overall Goto Blocks

• Simulink Goto Blocks

Stateflow Architecture

The Stateflow Architecture section of the dashboard shows the number of Stateflow transitions and states in the layers of your unit or component.

In the Stateflow Architecture section of the dashboard:

• The Count column shows:

  • Overall Transitions

  • Overall States

• The Distribution column shows:

  • Stateflow Transitions Distribution

  • Stateflow States Distribution

When you drill in to a widget in the Stateflow Architecture section of the dashboard, you can view the Metric Details associated with the metrics for:

• Stateflow Transitions

• Stateflow States

Overall Transitions

Metric ID: slcomp.OverallTransitions

Determine the overall number of transitions in a unit or component.

Description

Use this metric to count the total number of transitions in a unit or component.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.OverallTransitions.

Results

For this metric, instances of metric.Result return Value as the integer value for the overall number of transitions in a unit or component.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Stateflow Transitions

• Stateflow Transitions Distribution

Stateflow Transitions

Metric ID: slcomp.StateflowTransitions

Determine the number of Stateflow transitions in each layer of a unit or component.

Description

Use this metric to count the number of Stateflow transitions in the Stateflow model components in each layer of a unit or component.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.StateflowTransitions.

Results

For this metric, instances of metric.Result return Value as the integer value for the number of Stateflow transitions in each layer of a unit or component.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Overall Transitions

• Stateflow Transitions Distribution

Stateflow Transitions Distribution

Metric ID: slcomp.TransitionsDistribution

Determine the distribution of the number of Stateflow transitions in each layer of a unit or component.

Description

Use this metric to determine the distribution of the number of Stateflow transitions in the Stateflow model components in each layer of a unit or component.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.TransitionsDistribution.

Results

For this metric, instances of metric.Result return Value as a distribution structure that contains these fields:

• BinCounts — The number of artifacts in each bin, returned as an integer vector.

• BinEdges — Bin edges for the number of Stateflow transitions, returned as an integer vector. BinEdges(1) is the left edge of the first bin and BinEdges(end) is the right edge of the last bin. The length of BinEdges is one more than the length of BinCounts.

The bins in this metric result correspond to the bins in the Transitions row and Distribution column in the Stateflow Architecture section.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Overall Transitions

• Stateflow Transitions

Overall States

Metric ID: slcomp.OverallStates

Determine the overall number of states in a unit or component.

Description

Use this metric to count the total number of states in a unit or component.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.OverallStates.

Results

For this metric, instances of metric.Result return Value as the integer value for the overall number of states in a unit or component.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Stateflow States

• Stateflow States Distribution

Stateflow States

Metric ID: slcomp.StateflowStates

Determine the number of Stateflow states in each layer of a unit or component.

Description

Use this metric to count the number of Stateflow states in the Stateflow model components in each layer of a unit or component.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.StateflowStates.

Results

For this metric, instances of metric.Result return Value as the integer value for the number of Stateflow states in each layer of a unit or component.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Overall States

• Stateflow States Distribution

Stateflow States Distribution

Metric ID: slcomp.StatesDistribution

Determine the distribution of the number of Stateflow states in each layer of a unit or component.

Description

Use this metric to determine the distribution of the number of Stateflow states in the Stateflow model components in each layer of a unit or component.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.StatesDistribution.

Results

For this metric, instances of metric.Result return Value as a distribution structure that contains these fields:

• BinCounts — The number of artifacts in each bin, returned as an integer vector.

• BinEdges — Bin edges for the number of Stateflow states, returned as an integer vector. BinEdges(1) is the left edge of the first bin and BinEdges(end) is the right edge of the last bin. The length of BinEdges is one more than the length of BinCounts.

The bins in this metric result correspond to the bins in the States row and Distribution column in the Stateflow Architecture section.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Overall States

• Stateflow States

MATLAB Architecture

The MATLAB Architecture section of the dashboard shows the number of effective lines of MATLAB code in your unit or component.

In the MATLAB Architecture section of the dashboard:

• The Count column shows:

  • Overall MATLAB Executable Lines of Code (eLOC)

• The Distribution column shows:

  • MATLAB Effective Lines of Code (eLOC) Distribution

When you drill in to a widget in the MATLAB Architecture section of the dashboard, you can view the Metric Details associated with the metric for:

• MATLAB Effective Lines of Code (eLOC)

Overall MATLAB Executable Lines of Code (eLOC)

Metric ID: slcomp.OverallMATLABeLOC

Determine the overall number of executable lines of MATLAB code in a unit or component.

Description

Use this metric to count the total number of executable lines of MATLAB code in a unit or component. Effective lines of MATLAB code are lines of executable code.

The metric does not consider the following to be effective lines of code:

• empty lines

• lines that contain only comments

• lines that contain only white spaces

• lines that contain only an end statement

For example, suppose a unit contains only two MATLAB Function blocks: f1 and f2. If f1 contains 100 effective lines of code and f2 contains 50 effective lines of code, the overall number of executable lines of MATLAB code in the unit is 150.

Collection

To collect data for this metric, use getMetrics with the metric identifier slcomp.OverallMATLABeLOC.

Results

For this metric, instances of metric.Result return Value as the integer value for the overall number of executable lines of MATLAB code in a unit or component.

See Also

To view the number of lines of MATLAB code associated with each model component, see MATLAB Effective Lines of Code (eLOC).

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

MATLAB Effective Lines of Code (eLOC)

Metric ID: slcomp.MATLABeLOC

Determine the number of effective lines of MATLAB code.

Description

Use this metric to count the number of effective lines of MATLAB code. Effective lines of MATLAB code are lines of executable code.

The metric does not consider the following to be effective lines of code:

• empty lines

• lines that only contain comments

• lines that only contain white spaces

• lines that only contain an end statement

To view the total number of lines of MATLAB code associated with a unit or component, see Overall MATLAB Executable Lines of Code (eLOC).

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, in the MATLAB Architecture section, click the Run metrics for widget icon . The distribution of the effective lines of MATLAB code appears in the Lines of Code row and Distribution column. To view a table that shows the effective lines of MATLAB-based code for each model component, click one of the bins in the distribution.

• Use getMetrics with the metric identifier slcomp.MATLABeLOC.

Results

For this metric, instances of metric.Result return Value as the integer value for the number of lines of effective MATLAB code in a unit or component.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Overall MATLAB Executable Lines of Code (eLOC)

• MATLAB Effective Lines of Code (eLOC) Distribution

MATLAB Effective Lines of Code (eLOC) Distribution

Metric ID: slcomp.MATLABeLOCDistribution

Determine the distribution of the number of effective lines of MATLAB code.

Description

Use this metric to determine the distribution of the number of effective lines of MATLAB code. Effective lines of MATLAB code are lines of executable code.

The metric does not consider the following to be effective lines of code:

• empty lines

• lines that only contain comments

• lines that only contain white spaces

• lines that only contain an end statement

To view the number of lines of MATLAB code associated with each model component, see MATLAB Effective Lines of Code (eLOC).

Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, in the MATLAB Architecture section, click the Run metrics for widget icon . The distribution of effective lines of code appears in the Lines of Code row and Distribution column.

• Use getMetrics with the metric identifier slcomp.MATLABeLOCDistribution.

Results

For this metric, instances of metric.Result return Value as a distribution structure that contains these fields:

• BinCounts — The number of artifacts in each bin, returned as an integer vector.

• BinEdges — Bin edges for the number of effective lines of MATLAB code, returned as an integer vector. BinEdges(1) is the left edge of the first bin and BinEdges(end) is the right edge of the last bin. The length of BinEdges is one more than the length of BinCounts.

The bins in this metric result correspond to the bins in the Lines of Code row and Distribution column in the MATLAB Architecture section.

See Also

For an example of collecting metrics programmatically, see Collect Model Maintainability Metrics Programmatically.

• Overall MATLAB Executable Lines of Code (eLOC)

• MATLAB Effective Lines of Code (eLOC)