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

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.

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

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

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

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

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

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

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

### Stateflow Design Cyclomatic Complexity

**Metric ID**:
`slcomp.SFCyclomaticComplexity`

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

#### Description

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

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

#### See Also

For related metrics, see:

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

### MATLAB Design Cyclomatic Complexity

**Metric ID**:
`slcomp.MatlabCyclomaticComplexity`

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

#### Description

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

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

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

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

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

#### See Also

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

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

`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

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

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

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

`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

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

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

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

`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

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

#### See Also

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

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

`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

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

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

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

`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

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

**Distribution**column shows:

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.

#### See Also

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

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

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

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