## 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:

#### 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.

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:

• 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 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.

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:

• 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 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.

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.

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:

• 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 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.

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.

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:

• 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 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.

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:

• 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 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.

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:

• 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 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.

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:

• The Distribution column shows:

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:

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.

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.

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.

#### 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.

For related metrics, see:

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

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

• 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 . Point to a distribution bin to see tooltip information on the number of model layers and decisions associated with the bin.

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.

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.

#### 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.

For related metrics, see:

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.

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.

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.

#### Collection

To collect data for this metric:

• In the Model Maintainability Dashboard, in the Design Cyclomatic Complexity Breakdown section, click the 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.

For related metrics, see:

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 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.

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.

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:

• The Distribution column shows:

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:

### 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.

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

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 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.

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

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 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.

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

### 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.

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

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.

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

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.

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

### 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.

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

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 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.

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

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 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.

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

### 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:

• The Distribution column shows:

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:

### 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.

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

### 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.

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

### 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.

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

### 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.

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

### 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.

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

### 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.

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

### 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:

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:

### 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.

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 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.

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

### 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 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.