# Measuring the Complexity of SysML Models

Anoushka Bhatnager, Lakshmi Bhargav Gullapalli, Pierre de Saqui-Sannes, Rob A. Vingerhoeds

<figure><img src="image_1.png" /></figure>

## To cite this version:

Anoushka Bhatnager, Lakshmi Bhargav Gullapalli, Pierre de Saqui-Sannes, Rob A. Vingerhoeds. Measuring the Complexity of SysML Models. Systems, 2025, 13 (12). hal-05514297

HAL Id: hal-05514297

https://hal.science/hal-05514297v1

Submitted on 17 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
Article

# Measuring the Complexity of SysML Models †

Anoushka Bhatnager ID, Lakshmi Bhargav Gullapalli ID, Pierre de Saqui-Sannes *ID and Rob A. Vingerhoeds ID

Fédération ONERA ISAE-SUPAERO ENAC, Université de Toulouse, 31400 Toulouse, France; lakshmibhargav@outlook.com (L.B.G.)

* Correspondence: pdss@isae-supaero.fr

† This paper is an extended version of our published paper "Quantitative Assessment of Complexity in SysML Models", which was presented at the 38th annual European Simulation and Modelling Conference (ESM2024), International conference proceedings, held in San Sebastian, Spain, 23-25 October 2024.

## Abstract

Model-Based Systems Engineering (MBSE) is employing systems analysis, design, and development on models of these systems, bringing together different viewpoints, with a step-by-step increase of detail. As such, it replaces traditional document-centric approaches with a methodology that uses structured domain models for information exchange and system representation throughout the engineering lifecycle. MBSE comprises different languages, each with distinct features and approaches. SysML is a widely used language in MBSE, and many tools exist for it. This paper is interested in the complexity of SysML models, as it may yield useful quantitative indicators to assess and predict the complexity of systems modeled in SysML, and, by extension, the complexity of their subsequent development. Two avenues are explored: objective structural metrics applied to the SysML model and assessment of the team experience. The proposed approach is implemented as a Java prototype. Although simpler models are easier to comprehend and modify, they may fail to capture the full scope of system functionality. Conversely, more complex models, though richer in detail, require greater development effort and pose challenges for maintenance and stakeholder communication. Technical and environmental factors are integrated into the complexity assessment to reflect real-world project conditions. A drone-based image acquisition system serves as a case study.

**Keywords:** MBSE; model complexity; SysML

<figure><img src="image_3.png" /></figure>

check for
updates

Academic Editor: James Cale

Received: 25 September 2025

Revised: 2 December 2025

Accepted: 10 December 2025

Published: 17 December 2025

**Citation:** Bhatnager, A.; Gullapalli, L.B.; de Saqui-Sannes, P.; Vingerhoeds, R.A. Measuring the Complexity of SysML Models. Systems **2025**, 13, 1128. https://doi.org/10.3390/systems13121128

**Copyright:** © 2025 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).

## 1. Introduction

The Systems Modeling Language (SysML) is an international standard in OMG [1] and allows systems engineers to model requirements, structure, and behavior of a system. SysML is widely used in industry and academia for modeling complex systems [2–4]. Although it provides a powerful representation for, among other features of the system architecture, its flexibility can lead to an increase in the complexity of the system models themselves, making them difficult to manage, understand, and maintain over time.

The increasing complexity of system models, characterized by intricate components, behaviors, interdependencies, and subsystem interactions, has made system engineering more critical than ever. Model-Based Systems Engineering (MBSE) has emerged as a key approach to address system complexity, with SysML being one of the major systems modeling languages [5]. SysML models enable system engineers to capture design, behavior, structure, and performance details in a comprehensive manner. However, the sheer complexity of these models can hinder their visualization, understanding, and practical application [6]. Some challenges include:
1. Challenge of Visualizing Structural Complexity: As systems grow in scale and incorporate numerous interdependent components, subsystems, and interfaces, visualizing their structural complexity within SysML models becomes a significant challenge [7].

2. Impact on System Development Procedures: The complexity embedded within SysML models influences system development procedures and outcomes. Excessive model complexity can lead to inefficiencies in the design process, slowing development cycles, and increasing the likelihood of errors. Balancing the level of complexity while maintaining a comprehensive representation of the system becomes a key consideration to optimize procedural efficiency [8].

3. Quality, Accuracy, and Reliability: The inherent complexity of SysML models directly influences the quality, precision, and reliability of the system they represent [9]. Poorly managed complexity can result in inconsistencies, inaccuracies, and reduced model reliability. Developing methodologies to measure and manage complexity is essential to ensure the robustness of system designs and to improve overall system outcomes.

4. Development Cost: The complexity of SysML models has a direct impact on the cost of system development. Highly complex models can require significant resources, including time, expertise, and computational tools, to develop, maintain, and validate the systems. As the complexity of systems and their models increases, the likelihood of rework, delays, and the need for specialized skills also increases, contributing to higher development costs. In addition, such complexity can result in overlooked issues or errors, leading to expensive downstream fixes [10]. Effective strategies for managing and reducing complexity are therefore crucial not only for technical optimization but also for controlling development budgets and ensuring cost-effective engineering practices [11].

A broader theoretical foundation for understanding model complexity is provided by the work of Efatmaneshnik and Ryan [12], who distinguish between objective and subjective complexity in model-based representations. Objective complexity concerns the inherent structure of a model—its components, interactions, and topological arrangement—while subjective complexity reflects the cognitive effort required by engineers and stakeholders to comprehend, modify, or reason about the model. Their work demonstrates that a usable notion of model complexity must address not only measurable structural properties but also the experiential factors that influence model interpretation and engineering decision-making.

This dual perspective aligns strongly with the motivation of the present work. SysML models simultaneously exhibit structural intricacy (e.g., numerous blocks, states, and interconnections) and cognitive or experiential challenges during design, verification, and communication activities. As models evolve, structural growth often increases subjective difficulty, impacting development speed, error likelihood, and stakeholder engagement. Building on the distinction introduced in [12], this paper proposes a unified assessment framework that integrates both objective structural metrics and team-experience-based indicators. The goal is to operationalize the dual-complexity viewpoint within the context of SysML and Model-Based Systems Engineering, providing system designers with quantitative measures that reflect both the topology of the model and the practical effort required to develop and maintain it.

The aim of this paper is to consider system model complexity (in particular, for SysML models), its importance, and to appreciate how understanding such complexity can be used as an advantage. The idea is to explicitly quantify complexity and understand it, so that design engineers can use this understanding to better master complexity. To this end, complexity metrics are proposed for four SysML diagrams (Requirements diagram, Use Case diagram, Block diagram, and State Machine diagram). Basically, two complementary groups of metrics can be identified: objective structural metrics on the models
and more team-experience assessments, such as effort-based measures that account for
team experience. The combination of the two groups allows one to better appreciate the
development at hand and to guide developers' design choices, thereby enhancing both
technical outcomes and economic efficiency. This paper proposes a framework to assess
the complexity of SysML models, comprising:

* Defining SysML model complexity in terms of metrics (combining both objective metrics and team-experience metrics, taking into account the experience of a development team);

* Analyzing SysML models using these metrics (and a Java-based complexity evaluation tool).

The framework is illustrated with a case study, modeled using TTool¹, an open source SysML toolkit for system design that supports SysML modeling and formal verification, allowing early validation of system properties. Java was retained for the development of the evaluation tool itself because of its platform independence, object-oriented nature, and extensive libraries that facilitate rapid development and testing.

The paper is an extended version of [13] and is organized as follows. Section 2 surveys related work on model complexity for several modeling techniques, but not SysML. Section 2.3 then goes more into detail with respect to the complexity of SysML models. Section 3 presents the proposed approach and a SysML Model complexity assessment tool. Section 4 discusses a case study of a drone system model with two variants. Section 5 discusses different complexities of different models and limitations of the complexity metrics. A tool supporting the approach was developed and is presented in Section 6. Section 7 concludes the paper and outlines possible future work.

## 2. Related Work

Complex systems typically display unexpected, emerging, and/or unpredictable
behavior. Characteristics of a complex system typically include [14,15]:

* A large scale of application;

* Many parts, and many dependencies between parts and with the environment;

* The involvement of many stakeholders with different, sometimes conflicting, interests and goals, requiring extensive cooperation and coordination throughout the system's life-cycle;

* Decision-making by stakeholders on the basis of uncertain, incomplete, inconsistent, or ambiguous information;

* In the case of a networked system: autonomous sub-systems with different norms and values, rules of engagement and agreement, communication architectures, and requirements for trust;

* Continuous change that may span many years;

* No single unique objective measure to determine the quality of a design.

From these characteristics, when turning our attention to model-based systems engineering, the following catch our attention:

* Many parts and many dependencies;

* Sub-systems with different norms and values, and communication architectures;

* No single unique objective measure to determine the quality.

Modeling languages existed years before the advent of UML and SysML and the
coining of the MBSE term. This is why the current 'Related Work' section is divided into
three subsections: Section 2.1 presents works on modeling languages other than UML and
SysML, Section 2.2 presents works on UML, and Section 2.3 presents works on SysML,
allowing us to present in detail the starting point for the current work.
## 2.1. Measuring Complexity for Modeling Languages Other than UML and SysML

In [16], Kokol et al. discussed the complexity of formal specifications relying on a so-called 'alpha-metrics' and adapted it to two formal methods: Lustre and B. Software complexity is based on long-range correlation. The work of Kokol primarily addressed the complexity of software, while the current paper discusses the complexity of models.

In [17], Cheung et al. evaluated the complexity of distributed systems specified using the formal description technique LOTOS. In terms of language type, LOTOS falls in the category of process algebra. In comparison with SysML, LOTOS uses processes, whereas SysML uses blocks to model an architecture and state machines to describe behavior. The paper [17] describes a tool that computes cyclomatic values for a distributed system modeled in LOTOS.

In [18], Huang and Lai discussed the complexity of the Estelle specifications. Like LOTOS, Estelle is a formal description technique for distributed systems. By its architecture and composition of state machines, Estelle may be compared to the block and state machine diagrams of SysML. The structure of the Estelle specification is analyzed in terms of blocks, communicating channels, and state machines, just to mention a few. The results of applying complexity metrics enable the development of a management decision support system.

## 2.2. Complexity of UML Models

In [19] Masmali and Badreddin outlined the metrics for two main software design notations; UML Class Diagrams and UML State Machines. The approach is based on the analysis of the design elements and their mutual interactions. The approach is not based on the experience and skills of the UML model developer. The measurement approach in [19] is based on evaluating each element in any class diagram and the state machine diagram by assigning a complexity rate (primitive, simple, or complex). The complexity of a system can be calculated by summing the complexities of all elements in the software design.

In [20] Criz-Lemus et al. link structural complexity with the understandability of UML Statechart diagrams. The authors of [20] identified three dimensions of structural complexity that affect understandability: (i) the size and control flow complexity of the Statechart in terms of features such as the number of states, events, guards, and state transitions; (ii) the actions that are performed when entering or leaving a state; (iii) the sequence of actions that are performed while staying within a state. Based on these structural complexity dimensions, the authors of [20] have developed an understandability prediction model using regression that is specifically recommended for data obtained from repeated-measures designs.

## 2.3. Complexity of SysML Models

In this section, a parallel is drawn to activities developed in software engineering. The approaches presented can be divided into two categories:

* Experiential (team-experience) indicators, taking into account specific skills of the development team.

* Structural (objective) indicators, building on the models themselves.

Both make important contributions and can jointly help development leaders see more clearly. In the following, both indicators will be briefly presented.

Efatmaneshnik and Ryan [12] propose a conceptual model of complexity that is highly relevant for SysML-based system design. Their framework distinguishes objective complexity, arising from measurable structural or architectural features of a model, from subjective complexity, which reflects the cognitive effort required to understand, manipulate, or reason about the model. Objective complexity is tied to quantifiable characteristics such as the number of entities, interconnections, structural dependencies, and topological patterns,
whereas subjective complexity is influenced by stakeholder expertise, familiarity with modeling constructs, and the interpretability of diagrams.

This distinction complements the two categories of SysML complexity indicators typically discussed in the literature—structural (objective) indicators and experiential (team-based) indicators—as summarized in Section 3. Existing SysML complexity measures, including block adjacency analysis, state-machine cyclomatic complexity, and use-case metrics, largely address the objective dimension. Conversely, factors such as Technical Complexity Factors (TCF), Environmental Complexity Factors (ECF), and experience-based classifications of use cases and actors capture aspects of subjective complexity, as noted in the proposed methodology of this paper.

The conceptual alignment between [12] and existing SysML approaches underscores an important gap in current literature: while many works treat structural and experiential metrics separately, few provide an integrated model of SysML complexity that reflects both dimensions simultaneously. The contribution of the present paper directly addresses this gap by operationalizing the objective/subjective distinction through a unified, computable set of metrics and combining them within a single SysML complexity evaluation framework.

### 2.3.1. Comparison with a General Framework

Efatmaneshnik and Ryan [12] propose a rigorous, domain-agnostic framework that separates objective complexity (size, structure, connectivity, information content) from subjective complexity (distance from a chosen reference simplicity). By expressing complexity as a monotonic function of these two components, their work provides a strong theoretical basis and unifies a wide range of existing graph- and entropy-based measures under a single conceptual template. They also highlight the context dependence of complexity and the importance of selecting an appropriate reference model.

The present work builds on this foundation and applies it to MBSE and SysML. It instantiates concrete, diagram-level metrics for the most common SysML artefacts (requirements, use-case, block, and state-machine diagrams), using adjacency-matrix measures, block/interface counts, and cyclomatic complexity, and complements them with Use Case Points adjusted by Technical and Environmental Complexity Factors (TCF/ECF) to capture experiential aspects. This transforms a general theory into a SysML-aware, engineer-interpretable measurement framework.

A key advantage of this approach is its tool support and empirical validation. A Java prototype extracts metrics directly from SysML XML (TTool), enabling automated, repeatable analysis and model-to-model comparison. The case study on successive drone model versions demonstrates how complexity evolves as new functions and architectural decisions are added, making the results actionable for modularization, effort estimation, and test prioritization. In this way, while Efatmaneshnik and Ryan provide the theoretical lens, the present method delivers a practical, SysML-specific, and deployable solution for complexity management in real MBSE projects.

### 2.3.2. Experiential Indicators

This section presents indicators that allow us to identify complexity as a result of team experience. A first step in any development is to capture the requirements. In the literature, various methods for assessing the complexity of natural language requirements have been explored, associating a complexity value with each requirement to indicate the difficulty to make a project successful [21]. Higher complexity values suggest greater challenges in implementation, necessitating careful project management and often leading to a situation of needing more resources and more time to realize such requirements. Understanding
these complexity measures is essential for evaluating requirements in SysML. This section reviews related work on Requirement Diagrams and analyzes their complexity.

**Time spent on analysis and modeling of the project requirements:** This first indicator accounts for the total time spent on the model to write its requirements, considering employee skills, available resources, and the difficulty of the task. Project deadlines require time estimates, and experienced project managers often rely on past projects to make informed predictions. However, since every project is unique, previous estimates may not always be accurate. To address this, information on the number of hours worked is collected, and a complexity index ranging from zero to five is assigned based on the reported data [22].

**Skills of the project team members:** This second criterion evaluates the general level of skill of individual project team members assigned to work on the project. Wrigley and Dexter (1987) [23] emphasize that expert judgment remains the most common estimation method; successful managers rely on both business acumen and experience to adapt to changing market demands. However, skill levels within project teams often vary across individuals, from recent graduates to experienced professionals, creating a diverse mix of expertise that influences the complexity and precision of project execution estimates. Based on the skill level assessed, a value is assigned; for software engineering projects [22] proposes this approach.

### 2.3.3. Structural Indicators

This section presents indicators that can be used to obtain an accurate estimate of software development implementation. In software engineering, the concept of Use Case Points (UCP) can be applied [24], originally developed by Gustav Karner in 1993. Use cases, a subset of UML modeling methodologies, are used to specify the system requirements that form the basis of the UCP idea. The use cases are then used to determine the software size, which is then factored to take into account technical and environmental factors. The expected effort for the realization of a software project can then be determined on the basis of this UCP. The size estimate can be determined by looking at the Unadjusted Use Case Weight (UUCW), the Unadjusted Actor Weight (UAW), the Technical Complexity Factor (TCF), and the Environmental Complexity Factor (ECF).

**Unadjusted Use Case Weight (UUCW):** This criterion accounts for the number and complexity of use cases. Each use case for a system is recognized and categorized as Simple, Average, or Complex, depending on how many transactions it contains. Each categorization is assigned a weight, derived from Gustav Karner's original Use Case Point (UCP) method, intended to reflect the complexity of the functional behavior modeled. The categorization into simple, average, or complex depends on the number of interactions (transactions) between the system and its actors that must be represented in the model. Such a scaled weighting approach ensures that functions that require more modeling effort are appropriately emphasized when estimating the complexity of the system. UUCW is then calculated as follows [25]:

$$ UUCW = (\text{Total No. of Simple Use Cases} \times \text{assigned weight}) + (\text{Total number of average use cases} \times \text{assigned weight}) + (\text{Total number of complex use cases} \times \text{assigned weight}) \quad (1) $$

**Unadjusted Actor Weight (UAW):** This criterion accounts for the number and complexity of actors. Every actor needs to be recognized and categorized as Simple, Average, or Complex, depending on the kind of actor, just like when determining the UUCW. The weights used in UAW reflect the complexity of the external entities that interact with the system. In SysML, actors can be human users, external systems, subsystems, or physical components that participate in operational scenarios. The assigned weights capture the
increasing effort required to model and analyze these interactions within the SysML use case and interaction diagrams. The UAW should be calculated as follows [25]:

$$UAW = (\text{Total number of simple actors} \times \text{assigned weight}) + (\text{Total number of average actors} \times \text{assigned weight}) + (\text{Total number of complex actors} \times \text{assigned weight}) \quad (2)$$

**Technical Complexity Factor (TCF):** This criterion takes into account different types of technical considerations [26]. In the calculation, first, a technical factor (TF) is obtained by evaluating each of the technical factors that come into play and assigning a score ranging from 0 (factor irrelevant) to 5 (factor is crucial). The weighted values for each factor are then determined and multiplied by this score. The technical factor (TF) is the sum of all computed values. Then, the actual TCF is calculated using the TF and the following formula [26]:

$$TCF = 0.6 + \frac{TF}{100} \quad (3)$$

The constant 0.6 in the formula for the Technical Complexity Factor (TCF) originates from Gustav Karner's original Use Case Point (UCP) method (1993). Karner introduced this baseline value to ensure that the TCF remains greater than zero, even if all technical factors are considered irrelevant (i.e., TF = 0). Without this constant, TCF could be evaluated to 0, which would eliminate the entire effort estimation. By setting the minimum TCF at 0.6, Karner established a lower bound that reflects the fact that any nontrivial system development requires at least a baseline level of technical effort, even when technical factors are minimal. As technical factors increase (TF grows larger), the second term, TF/100, gradually increases the TCF, scaling it up from this baseline. As such, Formula (3) ensures that the technical adjustment of complexity always starts from a meaningful minimum (0.6) and then increases proportionally based on the evaluated technical factors.

**Environmental Complexity Factor (ECF):** In the same way, an environmental complexity factor [26] is used to adjust estimates, based on environmental considerations, which basically includes the overall experiences of the team. It is obtained by assigning a score from 0 (no experience) to 5 (experience) to each environmental factor. The score is multiplied by a specified weighted value for each factor. The sum of all the values calculated is the environmental factor (EF). The EF is then used to calculate ECF using the following formula [26]:

$$ECF = 1.4 + (-0.03 \times EF) \quad (4)$$

In this equation, the values 1.4 and -0.03 were empirically derived from the foundational UCP model developed by Gustav Karner. The inclusion of these specific constants reflects a deliberate calibration of the model to align with historical project data. The constant -0.03 serves as a weighting factor for the Environmental Factor (EF) score. As the EF score increases, indicating a more favorable and experienced team environment, this negative multiplier ensures that the overall value of the ECF decreases, thus logically reducing the total estimated project effort. The constant 1.4 acts as a baseline, ensuring that the ECF value remains within a validated range (typically between 0.7 and 1.3) consistent with complexity adjustments in similar software estimation models. Thus, these values are not the result of a direct calculation for a specific project, but are fundamental, predefined components of the standardized UCP framework.

Finally, the UCP can be calculated as the unadjusted project size (UUCW and UAW), technical factor (TCF), and environmental factor (ECF) have been determined. The UCP can be calculated using the following formula [26]:

$$UCP = (UUCW + UAW) \times TCF \times ECF \quad (5)$$
After calculating the Use Case Points, the complexity and the associated estimated effort for the project depending on approximate hours per Use Case Point can be computed, allowing to substantiate estimates on how many man hours can be expected to go into the making of the software.

### 2.3.4. Other Approaches Related to System Development

When turning attention to system development, key challenges while modeling using SysML include visualizing structural complexity, ensuring stakeholder comprehension, and balancing complexity to optimize system development and tool utilization. Recent research focuses on addressing these challenges to enhance the quality, accuracy, and reliability of SysML-based systems. A complexity metric from [27] is defined as follows:

$$C(n, m, A) = \sum_{i=1}^{n} \alpha_i + \left( \sum_{i=1}^{n} \sum_{j=1}^{n} \beta_{ij} A_{ij} \right) \frac{E(A)}{n} \quad (6)$$

where

* C is the complexity of the system;

* $\alpha_i$ is the complexity of the individual elements in the system. It is additive across all elements to contribute to the total structural complexity;

* $\beta_{ij}$ is the complexity associated with interactions between pairs of elements. It is summed over all pairs of connected elements, factoring in the connectivity of the system as defined by the adjacency matrix;

* $A_{ij}$ is the adjacency matrix;

* n is the number of subcomponents;

* $E(A)$ is its graph energy.

$E(A)$ serves as a quantitative measure of the complexity arising from the way elements in a system are connected to each other, reflecting the overall complexity of the system's topology.

This metric depends on $E(A)$, which presents two issues [28]:

1. It limits the application to the system's highest level or neglects external interactions;

2. It complicates analysis when component information varies across levels (e.g., COTS vs. in-house components).

As an alternative, Ref. [29] suggests the use of cyclomatic complexity:

$$v = e - n + 2p \quad (7)$$

where

* $v$ is cyclomatic complexity;

* $e$ is the number of relations;

* $n$ is the number of sub-components;

* $p$ is the number of connected internal components.

By substituting the $E(A)$ with the cyclomatic complexity $v$, Equation (6) transforms into Equation (8) as follows:

$$C = \sum_{i=1}^{n} \alpha_i + \left( \sum_{i=1}^{n} \sum_{j=1}^{n} \beta_{ij} + \sum_{i=1}^{n} \sum_{m=1}^{n} \gamma_{im} \right) \frac{v}{n} \quad (8)$$

Here,

* C represents the complexity of component k;

* $\alpha_i$ is the complexity of the i-th sub-component;
* $\beta_{ij}$ is the interaction complexity between the i-th and j-th sub-components;

* $\gamma_{im}$ is the interaction complexity between the i-th sub-component and the m-th external sub-component;

* v is the cyclomatic complexity;

* n is the number of sub-components.

Victor Lopez and Dale Thomas highlighted the importance of complexity management as a way to enhance system engineering procedures. Model simplification, modularization, and the use of abstraction techniques were all suggested as complexity reduction techniques. These techniques attempt to improve the modifiability, maintainability, and understanding of the model [28].

Dalvi and El-Mounayri [30] presented a methodology to assess complexity. This methodology enables systems engineers to assess the complexity of the system architecture at several levels, which are structural, behavioral, and interconnection complexities. Quantitative metrics that address these structural, behavioral, and interconnection complexities, using metrics such as I (number of interfaces), S (number of components), U (number of use cases), and P (functions per use case) are as follows:

1. Relation between complexity index and complexity number:

$$ \hat{C} = F(C) \qquad (9) $$

2. Relation between overall system architecture complexity, that is, the sum of Structural Complexity and Behavioral Complexity:

$$ \hat{C} = \hat{C}_s + \hat{C}_b \qquad (10) $$

3. System Complexity Index at the black box level:

$$ \hat{C} = \ln(\sum_{s=1}^{s} I^{S}) + \ln(\sum_{u=1}^{u} P^{U}) \qquad (11) $$

4. System Complexity Index at the white box level:

$$ \hat{C} = \ln(\sum_{s=1}^{s} I^{S}) + \ln(\sum_{p=1}^{p} P_{d}^{P}) \qquad (12) $$

The above formulae, as proposed in [30], focus on Block diagrams and State Machine diagrams for software engineering. Taking the work forward towards systems engineering in general and the use of SysML in particular, this paper takes into account Requirement Diagrams, Use Case Diagrams, along with Block Diagrams, and State Machine Diagrams. The concept of Use Case Points (UCPs) is used for Use Case Diagrams. This will provide an overall understanding of the model's complexity.

## 3. Methodology

This paper builds on the above-mentioned approaches and extends them to Model-Based Systems Engineering. It combines existing complexity metrics and estimation techniques, such as Use Case Points (UCPs), structural complexity measures, and interaction-based complexity measures, to develop a comprehensive framework for assessing system model complexity. This approach is designed to address the challenges of modeling system complexity, ensuring accurate estimation and efficient project management.
### 3.1. The Proposed Methodology

This methodology incorporates both objective and team-experience elements in assessing the complexity of the SysML model. Structural complexity analysis is objective, as it relies on measurable system topology metrics such as adjacency matrices and cyclomatic complexity. In contrast, the Technical Complexity Factor (TCF) and the Environmental Complexity Factor (ECF) involve team experience assessments based on expert judgment and contextual considerations. Similarly, Unadjusted Use Case Weight (UUCW) and Unadjusted Actor Weight (UAW) depend on team-experience classification of use cases and actors into predefined complexity categories. Recognizing this mix of objectivity and subjectivity is essential for interpreting complexity estimates and ensuring balanced decision-making in project management. The approach or the methodology can be seen in Figure 1.

<figure><img src="image_4.png" /><figcaption>**Figure 1.** Proposed methodology.</figcaption></figure>

**Step 1: Requirements Capture and Use Case Categorization.** To initiate the complexity assessment, begin by capturing system requirements thoroughly using Use Case Modeling. This involves the following:

1. The process begins by thoroughly gathering the system's requirements through Use Case modeling. This involves eliciting the functional behaviors of the system and documenting them in a structured manner.

2. Use Case Classification:

*   **Identification:** Each use case is identified from the requirements.

*   **Categorization:** Use cases are classified into three levels, Simple, Average, and Complex, based on criteria such as the number of transactions or the intrinsic difficulty of the task.

*   **Weighting:** A predetermined weight is assigned to each category. For example, a simple use case may receive a lower weight than a complex one.

3. Actor Classification:

*   **Identification:** Actors (i.e., the external entities interacting with the system) are identified.

*   **Categorization:** Actors are similarly classified as Simple, Average, or Complex, based on the nature and extent of their interactions with the system.

*   **Weighting:** Predefined weights are also assigned to these categories.
### 4. Computation of Functional Size:

Unadjusted Use Case Weight (UUCW): Calculated as the sum of (number of use cases × corresponding weight) across all categories.

Unadjusted Actor Weight (UAW). Similarly, computed by summing the products of actor counts and their assigned weights.

Please note that for the weights for the UUCW calculation, the following definitions were taken from the original work:

* Simple use case (Weight = 5): Involves one to three transactions. These are straightforward functions with limited interaction steps. For example, "system starts up" or "system performs self-check."

* Average use case (Weight = 10): Involves four to seven transactions. These require moderate modeling effort, often involving branching behavior or multiple interaction steps. For example, "system processes operator command and generates a status report."

* Complex use case (Weight = 15): Involves eight or more transactions. These represent elaborate operational scenarios, often with multiple interactions, conditions, and alternative flows. For example, "the system executes a mission sequence involving multiple subsystems and external entities."

Similarly, for the AUW calculation, the following weights were defined as follows:

* Simple actor (Weight = 1): An external component or subsystem with a single, well-defined mode of interaction. For example, a sensor providing a fixed data feed.

* Average actor (Weight = 2): An external system or subsystem that interacts in multiple structured ways, such as exchanging commands and status information. For example, a ground station that exchanges telemetry and command data with a satellite.

* Complex actor (Weight = 3): Typically a human operator or a system with rich and variable interactions that requires detailed modeling of roles, goals, and interactions. For example, a pilot interacting with an aircraft system or a mission controller coordinating across multiple subsystems.

Together, UUCW and UAW provide an initial unadjusted estimate of the functional size of the system.

**Step 2: Technical and Environmental Adjustments.** The raw functional size must be refined to account for the challenges of real-world development. Two sets of adjustment factors are introduced:

#### 1. Technical Complexity Factor (TCF):

**Assessment:** Thirteen technical attributes are evaluated, such as system distribution, performance objectives, ease of use, and maintenance (see Table 1). Each factor is rated on a scale (typically 0 to 5) based on its relevance and impact.

**Aggregation:** The scores are multiplied by their corresponding weights and summed to yield a total technical factor (TF).

**Adjustment Formula:** The TCF is then computed using the formula:

$$TCF = 0.6 + \frac{TF}{100}$$

This multiplier adjusts the functional size to account for technical challenges that may affect the development effort.
<table><caption>**Table 1.** Technical complexity factors [26].</caption><thead><tr><td>Factor</td><td>Description</td><td>Weight</td></tr></thead><tbody><tr><td>T1</td><td>Distributed system</td><td>2.0</td></tr><tr><td>T2</td><td>Response time / performance objectives</td><td>1.0</td></tr><tr><td>T3</td><td>End-user efficiency</td><td>1.0</td></tr><tr><td>T4</td><td>Internal processing complexity</td><td>1.0</td></tr><tr><td>T5</td><td>Code reusability</td><td>1.0</td></tr><tr><td>T6</td><td>Easy to install</td><td>0.5</td></tr><tr><td>T7</td><td>Easy to use</td><td>0.5</td></tr><tr><td>T8</td><td>Portability to other platforms</td><td>2.0</td></tr><tr><td>T9</td><td>System maintenance</td><td>1.0</td></tr><tr><td>T10</td><td>Concurrent / parallel processing</td><td>1.0</td></tr><tr><td>T11</td><td>Security features</td><td>1.0</td></tr><tr><td>T12</td><td>Access for third parties</td><td>1.0</td></tr><tr><td>T13</td><td>End user training</td><td>1.0</td></tr></tbody></table>

## 2. Environmental Complexity Factor (ECF):

**Assessment:** Eight environmental factors, such as team experience, familiarity with the development process, stability of requirements, and other contextual conditions, are similarly evaluated (see Table 2).

**Aggregation:** Each environmental factor is rated and weighted, and the aggregate forms the environmental factor (EF). The ECF is computed as follows:

$$ECF = 1.4 + (-0.03 \times EF)$$

This factor reflects the external conditions under which the system is developed and may mitigate or exacerbate the effective complexity.

**Step 3: Calculation of Use Case Points (UCPs).** The UCP is calculated by combining UUCW, UAW, TCF, and ECF:

$$UCP = (UUCW + UAW) \times TCF \times ECF$$

This provides an adjusted estimation of the system's size and the effort required.

**Step 4: Effort Estimation.** Finally, the estimated development effort is calculated based on UCP and approximate hours per Use Case Point, aiming at providing a better insight through balancing structural and environmental complexities. At this point, the time spent on analyzing and modeling the project requirements and the project team members' skills will be assessed, yielding more subjective assessments that will impact development estimates. To address the time spent on the analysis and modeling of the requirements of the project, information on the number of hours worked is collected, and a complexity index ranging from zero to five is assigned based on the reported data (Table 3), see also [22].

To address the skills of the project team members, skill level assessments are performed and a value is assigned (Table 4); see also [22] for software engineering projects.
<table><caption>**Table 2.** Environmental complexity factors [26].</caption><thead><tr><td>Factor</td><td>Description</td><td>Weight</td></tr></thead><tbody><tr><td>E1</td><td>Familiarity with development process used</td><td>1.5</td></tr><tr><td>E2</td><td>Application experience</td><td>0.5</td></tr><tr><td>E3</td><td>Object-oriented experience of team</td><td>1.0</td></tr><tr><td>E4</td><td>Lead analyst capability</td><td>0.5</td></tr><tr><td>E5</td><td>Motivation of the team</td><td>1.0</td></tr><tr><td>E6</td><td>Stability of requirements</td><td>2.0</td></tr><tr><td>E7</td><td>Part-time staff</td><td>-1.0</td></tr><tr><td>E8</td><td>Difficult programming language</td><td>-1.0</td></tr></tbody></table>

<table><caption>**Table 3.** Complexity metric based on hours required [22].</caption><tr><td>Hours Required</td><td>1–8</td><td>9–40</td><td>41–160</td><td>161–320</td><td>above 320</td></tr><tr><td>Complexity Metric</td><td>1</td><td>2</td><td>3</td><td>4</td><td>5</td></tr></table>

<table><caption>**Table 4.** Skill of project members [22].</caption><thead><tr><td>Skill Level</td><td>Value</td></tr></thead><tbody><tr><td>Highly competent</td><td>1</td></tr><tr><td>Competent</td><td>2</td></tr><tr><td>Short tenure</td><td>3</td></tr><tr><td>Experienced but new</td><td>4</td></tr><tr><td>No experience</td><td>5</td></tr></tbody></table>

**Step 5: Structural Complexity Analysis.** Beyond effort estimation, the methodology rigorously examines the intrinsic structural complexity of the SysML model:

1. Adjacency Matrix-Based Complexity:

Representation: The model components are represented as nodes, with their interactions captured in an adjacency matrix.

Calculation: A complexity score is computed by summing the individual complexities of the components $\alpha_i$ and the complexities of their pairwise interactions $\beta_{ij}$, weighted by the entries in the adjacency matrix. The graph energy, $E(A)$, of the system further modulates this sum to reflect the overall inter-connectivity.

$$C(n, m, A) = \sum_{i=1}^{n} \alpha_i + \left( \sum_{i=1}^{n} \sum_{j=1}^{n} \beta_{ij} A_{ij} \right) \frac{E(A)}{n}$$

where $E(A)$ reflects the graph energy of the system.

2. Cyclomatic Complexity:

Metric Origin: Borrowed from software engineering, cyclomatic complexity measures the number of independent paths through the control flow of the system.

Formula: $v = e - n + 2p$ where e is the number of relations (edges), n is the number of components (nodes), and p is the number of connected internal components (or exit points).

Implications: A higher cyclomatic complexity indicates more potential paths and a
more intricate structure, which can impact the maintainability and testability.

$$v = e - n + 2p$$

where (e) is the number of relations, (n) is the number of sub-components, and (p) is the number of connected internal components.

### 3. Composite Complexity Metric:

Integration: To provide a holistic view, a composite metric combines effort-based (UCP-derived) and structural measures.

$$C = \sum_{i=1}^{n} \alpha_i + \left( \sum_{i=1}^{n} \sum_{j=1}^{n} \beta_{ij} + \sum_{i=1}^{n} \sum_{m=1}^{n} \gamma_{im} \right) \frac{v}{n}$$

Interpretation: This composite metric reflects both the internal structural intricacies and the external interactions, offering a comprehensive measure of model complexity.

By systematically capturing functional requirements, adjusting for technical and environmental conditions, and rigorously analyzing structural attributes, this methodology provides a detailed and nuanced evaluation of the complexity of the SysML model. Integration of team-experience judgment with objective measurements ensures that the model's size, inter-connectivity, and inherent structural challenges are all accounted for, thereby supporting better system design, improved maintainability, and more accurate effort estimation.

As shown in Figure 1, the first step is to capture the requirements and categorize the Use Cases (and Actors) into simple, average, or complex. Then, along with Unadjusted Use Case Weight and Unadjusted Actor Weight, calculate the Technical and Environmental Factors to compute the Use Case Points (UCPs). Once the UCP is found, the estimated effort to build the system model can be determined. Furthermore, the complexities of Block and State Machine Diagrams are to be computed.

This section outlined a structured methodology for assessing the complexity of SysML models by integrating Use Case Points, structural complexity metrics, and interaction-based complexity metrics. Although this approach provides a comprehensive framework for evaluating system complexity and effort estimation, manual execution of these steps can be time-consuming and prone to inconsistencies. To improve efficiency and accuracy, the following section explores the automation of this methodology, leveraging computational techniques to streamline complexity assessment and improve project management outcomes.

### 3.2. Prototyping a SysML Model Complexity Evaluation Tool

The presented methodology offers a robust framework for complexity assessment. For small systems with few models, this approach can easily be applied and can give valuable insight into the complexity of the models. However, with the growing complexity of the systems themselves, manual execution of such calculations can be time-consuming and is prone to human error. Therefore, in order to ensure efficiency and consistency, an automated complexity computation tool was developed that supports the presented methodology. The tool was designed to parse SysML models from the open-source MBSE tool TTool and assess the complexity based on the metrics defined in the previous section. The developed tool extracts all the data from the source file of the MBSE tool. In the case of TTOOL, the models are saved in the XML file format. A Java application was created that takes an XML file of a model as input and performs all the necessary evaluations as explained before. As the XML file contains all the information of the models, the user will only be asked to give the necessary inputs whenever required, according to the evaluation metrics.
In the first step, robust extraction and parsing of SysML model data from XML files are performed. The XML file contains distinct sections corresponding to various SysML diagrams (Requirements, Use Case, Block, and State Machine diagrams), and dedicated Java classes were developed to manage the extraction process, tailored to a specific diagram type. The following outputs were defined for the three mentioned SysML diagrams:

* For State Machine Diagrams, the output consists of the diagram name, the number of states and connectors, and any time delay statistics, which are later integrated into the overall complexity metrics.

* For the Block Diagrams, the collected information includes the block name and the quantitative measures (e.g., the number of signals) that contribute to the calculation of structural complexity.

* For the Use Case Diagrams, the results comprise the computation of the Unadjusted Use Case Weight (UUCW) and the Unadjusted Actor Weight (UAW), which are critical inputs for estimating effort and overall model complexity.

Then, a central integration point was developed where all parsed data converge. This specific Java class:

1. Aggregates Data—it collates outputs from the State Machine Diagrams, Block Diagrams, and Use Case classes.

2. User Input Integration—in addition to the parsed structural data, the class prompts the user for supplementary inputs—such as time spent on requirements and team skill level—which affect requirement complexity.

3. Computational Processing—using predefined formulas (e.g., those incorporating cyclomatic complexity, adjacency matrix-based metrics, and use case points), the Complexity class computes a comprehensive complexity score for the model.

4. Result Presentation—finally, the computed metrics are displayed to the user via a graphical interface, allowing for further analysis or model comparison.

And some error handling mechanisms were put in place so as to cover for the following:

* Missing Data—handling cases where expected elements are absent, therefore aiming to maintain overall analysis integrity.

* User Guidance—prompting users and proposing fallback options to ensure that users can resolve issues without disrupting the workflow.

The output of a complexity analysis provides insight into different components. Once all factors presented in the previous sections have been collated, an overall complexity is determined by summing the cyclomatic and temporal complexity terms.

## 4. Case Study

Modern systems, such as drones, require meticulous design and evaluation to balance functionality, reliability, and usability. SysML provides a structured framework for modeling these complex systems, enabling efficient communication, visualization, and decision-making throughout the development lifecycle. A drone in charge of taking pictures serves as a case study for this research. The drone's mission is to enable its users to capture aerial images of locations specified by their coordinates, without requiring user intervention during flight.

The case study models a small autonomous drone whose mission is to fly to GPS coordinates supplied by a ground operator, take aerial photos, store them locally, and (optionally) transmit them back—all without human intervention during flight. The paper builds three incremental SysML models (M1 → M2 → M3), each adding features and therefore increasing modeling and development complexity.
The study applies both team-experience metrics (Use Case Points, TCF, ECF) and structural metrics (adjacency/cyclomatic-like measures applied to Block and State Machine diagrams) and shows how those produce consistent complexity and effort estimates as the system grows. The following sections present the description of various picture-taking drone models:

## 4.1. First, Basic Model (M1)

The first model (M1) models a drone whose coordinates are obtained via a GNSS device. The autopilot instructs the drone to a location, the camera driver takes the picture, and the picture processing manager sends a signal to the compact flash driver to save it.

### 4.1.1. Requirement Diagram

The requirement diagram for the M1 model is shown in Figure 2.

<figure><img src="image_5.png" /><figcaption>**Figure 2.** Requirement diagram for M1.</figcaption></figure>

The complexity of the requirement diagram in Figure 2 depends on the time spent on the project and the skill level of the team that works on the model.

(i) **Number of Hours Spent on the Model:** As stated in the previous sections, the number of hours spent on the model has to be specified by the user. Then according to Table 3, the response is given a complexity index. The number of hours spent on the requirements of this model is between 0 and 8 h. It corresponds to complexity index 1.

(ii) **Skill of the Project Members:** The users are then asked to rate their skill level based on the options given in Table 4, and a specific complexity index is assigned accordingly.

The skill level of the professionals working on the requirements is an employee who has been with the company a short period of time, has experience in 1–2 similar projects. It corresponds to the complexity index of 3.

The complexity is the product of both indices assigned earlier. It may seem lower compared to the complexity numbers of other sections of the model, but it is imperative to understand that it applies only to requirements and ranges between 1 and 25, with 1 representing less time-consuming tasks handled by highly skilled professionals and 25 representing highly time-consuming tasks managed by less skilled professionals.

In total, the complexity of the requirements of the M1 Model becomes 1 × 3 = 3.
### 4.1.2. Use Case Diagram

For each of the Use Case diagrams, the concept of Use Case Points [24] has been applied. Further, with the Use Case Points, the estimated effort for a project can be calculated, which helps determine the total number of hours expected on the project. This would help inform decision-making and enable efficient project management. The classification of Unadjusted Use Case Weight (UUCW) and Unadjusted Actor Weight (UAW) introduces subjectivity into the complexity assessment process. The complexity metrics are not inherently subjective; rather, they are a quantitative representation of a subjective classification. The Use Case Point (UCP) method turns a qualitative judgment into a quantifiable data point. Although the weights for each complexity category—Simple (5), Average (10), and Complex (15)—are fixed and objective, the initial decision to place a use case into one of these categories is a human-based evaluation. This judgment is influenced by the evaluator's interpretation of factors like the number of transactions and the perceived intricacy of the underlying system logic, introducing an element of subjectivity at the input stage. Therefore, the metrics themselves are objective, but they are derived from a process rooted in subjective professional opinion.

The Use Case diagram of the model is shown in Figure 3.

<figure><img src="image_6.png" /><figcaption>Figure 3. Use case diagram of the M1 Model.</figcaption></figure>

(i) **Unadjusted Use Case Weight (UUCW):** As stated above in the Related Work section, the user is required to identify the use cases as simple, average, and/or complex use cases depending on how many transactions each use case has. There is a universally set assigned value given to each of these categories as shown in Table 5:

<table><caption>Table 5. Use Case classification—M1 Model.</caption><thead><tr><td>Use Case Classification</td><td>No. of Transactions</td><td>Assigned Value</td></tr></thead><tbody><tr><td>Simple</td><td>1 to 3</td><td>5</td></tr><tr><td>Average</td><td>4 to 7</td><td>10</td></tr><tr><td>Complex</td><td>8 or more</td><td>15</td></tr></tbody></table>

Since all use cases have at most two transactions, they can be classified as Simple. However, one may classify use cases on the basis of how complex they really are, regardless of the number of transactions. The computation for this Use Case diagram can be conducted as follows (Table 6):
<table><caption>**Table 6.** Use Case classification.</caption><thead><tr><th>Use Case Classification</th><th>Use Cases</th><th>Reason</th></tr></thead><tbody><tr><td>Simple</td><td>Take Picture, Send Picture, Save Picture</td><td>Simple tasks</td></tr><tr><td>Average</td><td>Manage Picture</td><td>Integration of one or more tasks</td></tr><tr><td>Complex</td><td>nil</td><td>nil</td></tr></tbody></table>

$$ \text{UUCW} = (\text{Total No. of Simple Use Case} \times 5) + (\text{Total No. Average Use Cases} \times 10) + (\text{Total No. Complex Use Cases} \times 15) $$

$$ \text{UUCW} = (3 \times 5) + (1 \times 10) + (0 \times 15) = 15 + 10 = 25 $$

(ii) **Unadjusted Actor Weight (UAW):** The user is required to identify the actors as simple, average, and/or complex actors. There is a universally assigned value given to each of these categories. Simple is assigned 1; Average is assigned 2; and Complex is assigned 3.

For the M1 Model, the actors have been classified as shown in the table. The computation for this Use Case diagram can be done as follows (Table 7):

<table><caption>**Table 7.** Actor Classification—M1 Model.</caption><thead><tr><th>Actor Classification</th><th>Actors</th><th>Assigned Value</th></tr></thead><tbody><tr><td>Simple</td><td>Autopilot</td><td>1</td></tr><tr><td>Average</td><td>Camera Driver, Compact Flash Driver</td><td>2</td></tr><tr><td>Complex</td><td>Transmission Devices, GNSS Device</td><td>3</td></tr></tbody></table>

$$ \text{UAW} = (\text{Total No. of Simple actors} \times 1) + (\text{Total No. Average actors} \times 2) + (\text{Total No. Complex actors} \times 3) $$

$$ \text{UAW} = (1 \times 1) + (2 \times 2) + (2 \times 3) = 1 + 4 + 6 = 11 $$

(iii) **Technical Complexity Factor (TCF):** TCF is a factor which is needed to estimate the size of the system by taking into considerations the technical factors (TF). To calculate TF, a value is assigned to each of the technical factors based on how essential the technical aspect is to the system being developed (see Table 8). Then, the weighted and assigned values are multiplied, and the total TF is determined. Now, the TCF is calculated using the TF, and the formula is as follows:

$$ \begin{aligned} \text{TCF} &= 0.6 + \left( \frac{\text{TF}}{100} \right) \\ &= 0.6 + \left( \frac{39}{100} \right) \\ &= 0.99 \end{aligned} \qquad (13) $$

(iv) **Environmental Complexity Factor (ECF):** The size of the system should also be estimated, taking into account the environmental factors as well. Based on the level of team experience, the values are assigned to the Environmental Factors whose weights have already been established (see Table 9).
<table><caption>**Table 8.** Technical complexity factor.</caption><thead><tr><th>Factor</th><th>Description</th><th>Weight</th><th>Assigned Value</th><th>Weight × Assigned Value</th></tr></thead><tbody><tr><td>T1</td><td>Distributed system</td><td>2.0</td><td>5</td><td>10</td></tr><tr><td>T2</td><td>Response time/performance objectives</td><td>1.0</td><td>5</td><td>5</td></tr><tr><td>T3</td><td>End-user efficiency</td><td>1.0</td><td>4</td><td>4</td></tr><tr><td>T4</td><td>Internal processing complexity</td><td>1.0</td><td>2</td><td>2</td></tr><tr><td>T5</td><td>Code resuability</td><td>1.0</td><td>2</td><td>2</td></tr><tr><td>T6</td><td>Easy to install</td><td>0.5</td><td>1</td><td>0.5</td></tr><tr><td>T7</td><td>Easy to use</td><td>0.5</td><td>5</td><td>2.5</td></tr><tr><td>T8</td><td>Portability to other platforms</td><td>2.0</td><td>1</td><td>2</td></tr><tr><td>T9</td><td>System maintenance</td><td>1.0</td><td>3</td><td>3</td></tr><tr><td>T10</td><td>Concurrent/parallel processing</td><td>1.0</td><td>2</td><td>2</td></tr><tr><td>T11</td><td>Security features</td><td>1.0</td><td>4</td><td>4</td></tr><tr><td>T12</td><td>Access for third parties</td><td>1.0</td><td>1</td><td>1</td></tr><tr><td>T13</td><td>End user training</td><td>1.0</td><td>1</td><td>1</td></tr><tr><td colspan="4">Total (TF):</td><td>39</td></tr></tbody></table>

<table><caption>**Table 9.** Environmental complexity factor.</caption><thead><tr><th>Factor</th><th>Description</th><th>Weight</th><th>Assigned Value</th><th>Weight × Assigned Value</th></tr></thead><tbody><tr><td>E1</td><td>Familiarity with development process used</td><td>1.5</td><td>4</td><td>6</td></tr><tr><td>E2</td><td>Application experience</td><td>0.5</td><td>4</td><td>2</td></tr><tr><td>E3</td><td>Object-oriented experience of team</td><td>1.0</td><td>3</td><td>3</td></tr><tr><td>E4</td><td>Lead analyst capability</td><td>0.5</td><td>5</td><td>2.5</td></tr><tr><td>E5</td><td>Motivation of the team</td><td>1.0</td><td>3</td><td>3</td></tr><tr><td>E6</td><td>Stability of requirements</td><td>2.0</td><td>1</td><td>2</td></tr><tr><td>E7</td><td>Part-time staff</td><td>-1.0</td><td>0</td><td>0</td></tr><tr><td>E8</td><td>Difficult programming language</td><td>-1.0</td><td>3</td><td>-3</td></tr><tr><td colspan="4">Total (EF):</td><td>15.5</td></tr></tbody></table>

Now, the ECF is calculated using the EF and the following formula:

$$ 
\begin{aligned}
ECF &= 1.4 + (-0.03*EF) \\
&= 1.4 + (-0.03*15.5) \\
&= 0.935
\end{aligned} 
\quad (14) $$

Now, **Use Case Points (UCPs)** can be calculated by substituting the values of UUCW, UAW, TCF, and ECF as follows:

$$ 
\begin{aligned}
UCP &= (UUCW + UAW) \times TCF \times ECF \\
&= 33.3234
\end{aligned} 
\quad (15) $$

**Estimated Effort:** Assuming that each Use Case Point takes up 20 man hours, the total effort for the project can be estimated as follows: Estimated Effort = Use Case Point × Man hours/Use Case Point = 666.468 h (666 h, 7 min, and 48 s).
### 4.1.3. Block and State Machine Diagrams

In system modeling, Block and State Machine diagrams play complementary roles, specifically in TTool. Block diagrams capture the structural organization of system components, including their attributes, operations, and communication interfaces. On the other hand, State Machine diagrams model the dynamic behavior of system components by defining their states and transitions. Together, they provide a comprehensive view of both the static architecture and the dynamic operation of the system.

The complexity computation for the M1 model is objective, as it is based on measurable system components and defined structural relationships. The model represents a functional breakdown of the drone, where each component and its interactions are clearly specified. The application of complexity metrics to block and state machine diagrams follows a systematic and quantifiable approach, ensuring consistency in the assessment. Since the computation relies on predefined formulas and measurable system attributes rather than interpretation by team experience, the resulting complexity values provide an objective representation of the structural intricacies of the model.

When applying the complexity metrics, the complexity of the block and state machine diagrams was successfully computed and can be seen in Table 10. The formula used is the following: $C = \sum_{i=1}^{n} \alpha_i + (\sum_{i=1}^{n} \sum_{j=1}^{n} \beta_{ij} + \sum_{i=1}^{n} \sum_{m=1}^{n} \gamma_{im}) \frac{v}{n}$.

<table><caption>**Table 10.** Complexity of the M1 Model.</caption><thead><tr><th>M1 Model</th><th>α</th><th>β</th><th>γ</th><th>n</th><th>e</th><th>Total</th></tr></thead><tbody><tr><td>Transmission Devices</td><td>1</td><td>4</td><td>0</td><td>1</td><td>6</td><td>29</td></tr><tr><td>GNSS Device</td><td>1</td><td>2</td><td>0</td><td>2</td><td>6</td><td>7</td></tr><tr><td>Compact Flash Driver</td><td>2</td><td>2</td><td>1</td><td>1</td><td>4</td><td>13</td></tr><tr><td>Autopilot</td><td>1</td><td>1</td><td>0</td><td>1</td><td>3</td><td>5</td></tr><tr><td>Camera Driver</td><td>0</td><td>2</td><td>0</td><td>1</td><td>4</td><td>10</td></tr><tr><td>Picture Processing Manager</td><td>1</td><td>11</td><td>0</td><td>2</td><td>15</td><td>83.5</td></tr><tr><td colspan="6">Total Complexity</td><td>147.5</td></tr></tbody></table>

### 4.2. Extended Model (M2)

The previous section discussed the modeling and analysis of the elementary model M1 (see Figure 4). The current section applies the same approach to the Extended Model M2 and presents the specifics of M2 without reaching the level of detail used for M1 in the previous section. This Extended Model M2 adds an Obstacle Avoidance System to the M1 Model. This system integrates sensors to detect obstacles during flight and sends signals to the autopilot to initiate maneuvering when necessary. Figure 5 depicts the requirements for M2.

(i) **Time Spent on Project:** the TSP for M2 is lower than the TSP for M1. Since the Extended Model was modeled from scratch, the time spent on requirements of this model is between 8–40 h. It corresponds to the complexity index 2.

(ii) **Skill of the Project Members:** From Table 4, the user rates their skill level and assigns a specific complexity index accordingly.

The skill level of the professionals working on the requirements is 'Employee who has been with the company for a short length of time, has experience in 1–2 similar projects.' It is the same as the previous model, assuming that the same professionals are working on it. It corresponds to the complexity index of 3.

Therefore, the complexity of the requirements of the Extended Model = 2 × 3 = 6.
<figure><img src="image_7.png" /><figcaption>Figure 4. Block diagram of the M1 Model.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Figure 5. Extended model requirements.</figcaption></figure>

4.3. Advanced Model (M3)

Compared to the M2 model, this final model incorporates a battery management system that monitors the camera's battery status. If the battery level falls below a threshold, a signal is sent to the picture processing manager, and the battery must be charged. This extra component gives the model a little more modeling complexity while giving it new advanced features.
## Requirement Diagram

Requirement complexity is team experience, as it depends on the judgment of the user about the time spent and the skill level, leading to variations in the assessment. The requirements for the Advanced Model are as follows (Figure 6).

<figure><img src="image_9.png" /><figcaption>Figure 6. Advanced model requirements.</figcaption></figure>

The approach applied to M1 and M2 is now applied to M3.

* Time Spent on Project: between 8–40 h (complexity index 2).

* Skill of the Project Members = 6 (complexity index of 3) = 66.6468.

# 5. Discussion

The basic model (M1) exhibits the lowest measured complexity with a structural-behavioral score of 147.50 and a Use Case Point-derived effort estimate of approximately 666.47 person-hours. Structurally, M1 is characterized by a smaller number of blocks and a lower number of inter-block interfaces; behaviorally, it contains fewer state machines, fewer states per machine, and a lower sum of transitions, which produces a smaller summed cyclomatic value. These objective properties translate into a reduced number of independent execution paths to verify, fewer interaction points at which integration faults can occur, and, correspondingly, lower cognitive load for reviewers and integrators. In practical engineering terms, M1’s low interface multiplicity and limited state branching make it more tractable for unit-level verification, simpler to instrument for test coverage, and less prone to subtle cross-component integration defects—but it also represents a narrower functional envelope and therefore provides less coverage of real operational scenarios.

The intermediate model (M2) adds an Obstacle Avoidance subsystem and its associated sensing and signaling interfaces. Measured complexity for M2 rises to 196.50, and the UCP effort estimate increases to about 999.70 person-hours. Objectively, M2 increases both interface density and behavioral branching: new sensor-to-processor and sensor-to-autopilot connectors increase adjacency matrix non-zeros, while the reactive control logic adds states and transitions that substantially raise per-machine cyclomatic sums. Numerically, the structural score increases by 49.00 points from M1 to M2, a relative increase of ≈33.22 percent, and the estimated effort increases by 333.23 h (≈49.99 percent increase). This relatively large jump reflects the fact that reactive obstacle handling tends to multiply interaction paths (sensing → detection → decision → maneuver → resume) and introduces real-time and safety constraints that require additional validation scenarios. From a design perspective, M2 therefore represents an important capability gain at the cost of a significant rise in both verification surface and integration complexity; it is the point at which modeling effort shifts from primarily static decomposition to an emphasis on dynamic, safety-critical behavior.
The advanced model (M3) further augments M2 with a Battery Management System that coordinates charging/charging-complete states with the camera and other subsystems. M3's complexity reaches 227.83 (see Figure 7), and its effort estimate is approximately 1332.94 person-hours. Structurally, the addition increases coupling and adds some new interfaces, and behaviorally, the model acquires lifecycle coordination states that span components (e.g., CameraDriver—BMS coordination). Compared to M2, the structural score increases by 31.33 points (≈15.94 percent relative increase) and the estimated effort increases by 333.236 h (≈33.33 percent relative increase). The smaller relative structural increment (M2 to M3) compared to the initial increment (M1 to M2) suggests that while BMS introduces cross-component coordination, it does not produce as many distinct new interaction paths as obstacle avoidance did; nevertheless, the absolute additional effort remains substantial because lifecycle coordination often demands end-to-end scenario validation, new fault modes, and integration testing with power management constraints.

<figure><img src="image_10.png" /><figcaption>Figure 7. Complexity of M3 computed using the prototype.</figcaption></figure>

These empirical patterns inform concrete engineering practices. First, complexity measures should be used to identify high-impact subsystems (those that contribute disproportionately to summed cyclomatic value). For such hotspots, teams should apply modularization strategies and well-defined interface contracts to reduce coupling and to permit isolated verification. Second, per-state-machine cyclomatic contributions should drive test-case prioritization: machines with the largest contribution to the summed cyclomatic metric should receive early, focused test generation and path-coverage analysis because they represent the greatest combinatorial verification risk. Third, incremental integration and hardware-in-the-loop simulation are especially valuable when adding reactive capabilities (M2-type changes): early, automated integration tests that exercise sensing→decision→actuation chains will reveal cross-component timing or protocol faults before full system integration. Fourth, for lifecycle-coordination features (M3-type changes), regression suites that include resource-state scenarios (e.g., low power, charging interrupt, graceful resume) are required to validate recovery and interlock behavior.

Finally, the prototype extractor and analyzer tool developed for this work (the standalone Java tool that imports SysML XML files) makes these recommendations operational: by producing per-component adjacency measures, per-state-machine cyclomatic values, and composite complexity indices, it enables targeted refinement of the model and empir-
ically driven calibration of prediction weights. In practice, teams can use the tool to run sensitivity analyses (e.g., removing or isolating a subsystem in the model and measuring the change in adjacency and cyclical sums) to quantify the marginal complexity cost of candidate features. Normalizing sub-scores and calibrating aggregation weights against historical projects will improve the predictive power of the tool, which suggests different remediation strategies for different kinds of models.

In general, complexity analysis provides a team experience and an objective assessment of the modeled systems. This would ultimately give system designers and system engineers a much better understanding of the system, enabling better usage of the MBSE approach. It helps in identifying potential areas of concern for system designers in terms of modeling and scalability based on the complexity number, and helps them make informed decisions regarding the system design, optimization, and verification as intended.

The results of the case study further illustrate the relevance of the dual-complexity viewpoint introduced by Efatmaneshnik and Ryan [12]. Increases in structural complexity—visible through growth in adjacency metrics, cyclical values, and block interactions—correspond closely to increases in experiential or perceived complexity reported by the development team. This relationship reflects the interplay between objective and subjective dimensions of complexity, wherein richer models provide deeper behavioral and architectural fidelity but also impose higher cognitive demands on stakeholders responsible for model comprehension and refinement. By combining structural complexity metrics with team-experience factors (TCF, ECF, UUCW, UAW), the methodology proposed in this paper provides a practical operationalization of this dual perspective. Structural indicators quantify the inherent complexity of the model, whereas experiential indicators approximate the subjective difficulty of model development. This integration allows system designers to not only assess how complex a model is but also anticipate how difficult it will be to work with that model throughout the engineering lifecycle.

The increasing complexity of modern systems presents significant challenges in their visualization, communication, and development when using SysML. Addressing these challenges requires a multifaceted approach—balancing model complexity, improving stakeholder engagement, optimizing SysML tool utilization, and ensuring model quality and reliability.

## 6. Development of a Tool Supporting This Approach

An automated complexity analysis prototype tool was implemented as a standalone Java application that imports SysML model XML files, specifically those produced by TTool, rather than as a tightly coupled plugin. The prototype performs two primary workflow analyses of a single model and pairwise comparison of two models, and is driven by a lightweight graphical front-end that prompts the user to select XML input files and answer a small set of questions about requirements and use-case characteristics. The tool reads the canonical XML representation of the model and extracts the information needed to compute both structural and experience-based metrics, enabling automated repeatable measurement runs without modifying the modeling environment.

The software's XML parsing uses standard Java APIs (DocumentBuilder/Document) and the extraction logic is encapsulated in three purpose-built extractor classes. The Block-Diagram extractor iterates over <COMPONENT> elements to collect block names, attribute and method counts, and associated signal lists, storing results in a Map <String, BlockInfo> for downstream analysis. The SMD extractor scans <StateMachineDiagramPanel> elements to identify state-machine panels, count states (detected by name prefixes such as "state0" or "state") and connectors, and build a StateMachineInfo map representing each state machine's topology. The UseCase extractor processes <UseCaseDiagramPanel> entries
to recover actors, use cases, and connector metadata. All extractor routines are imple-
mented as public static methods so that they can be invoked programmatically from other
applications or integrated into larger toolchains.

A central Complexity class coordinates the user workflow, presenting a simple Swing UI (a JFrame and a JFile Chooser) to select modes and input files, invokes the extractor methods, and aggregates the extracted metrics. The compute pipeline calculates cyclomatic-derived measures for each state machine and sums these to produce a structural baseline; it also collects block-level statistics (attributes, operations, signals, connectors) and uses interactive inputs to produce requirement-driven estimates (requirementComplexity and estimatedComplexity). The results are displayed to the user in dialog windows, while intermediate outputs—block and state machine maps and console logs—are retained for traceability and programmatic reuse. When run in comparison mode, the same pipeline is executed for two XML files, and the tool presents a side-by-side comparison of complexity indicators and effort estimates.

Because the prototype imports XML rather than depending on an internal TTool API,
it functions as a connector that could be readily applicable to models produced by other
SysML tools that support comparable exchange formats. This external adapter-based
architecture reduces adoption friction, facilitates continuous integration or batch analysis
workflows, and simplifies the development of additional adapters or wrappers to integrate
the analyzer into diverse toolchains. Returned maps and public extractor methods make it
easy to embed the parser and computation engine within automated pipelines or to expose
its output to downstream analysis, visualization, or calibration routines.

In operation, the prototype thus bridges diagram-level model artifacts and composite
complexity assessment: cyclomatic metrics computed per state machine are combined with
block-adjacency and use-case/requirement indicators to produce an overall complexity and
effort estimate. The implementation approach—standalone, XML-driven, and program-
matically accessible—enables broad, multitool usage and provides a practical foundation
for empirical calibration, weight tuning, and extension to additional structural patterns (for
example, concurrency or hierarchical states) in future work.

7. Conclusions

The challenges outlined above demonstrate the delicate balance required when manag-
ing SysML model complexity. Overly simplistic models risk omitting critical details, while
excessively complex models hinder visualization and stakeholder engagement. Strategies
such as hierarchical decomposition, modularity, and abstraction are essential to balance
these competing needs. In addition, providing training and resources to improve stake-
holder familiarity with SysML tools and practices can significantly enhance comprehension
and application.

To improve quality and reliability, quantitative metrics can be developed to mea-
sure complexity. Such measures could help system engineers identify and address cases
where models become overly intricate or ambiguous, thereby ensuring greater consistency
and accuracy.

The purpose of this paper was to conduct a thorough study on the complexity of
a system and understand how having the knowledge of complexity can be used as an
advantage in the field of systems engineering. The complexity of a system was to be
quantified so that it could be understood by design engineers and used as a means to build
system models. Complexity metrics were defined for four SysML diagrams and applied
to SysML models developed in TTool. The study was illustrated by analyzing a drone
case study.
Future research on SysML model complexity could explore integrating dynamic complexity analysis with model validation to enhance model reliability and usability. More specifically, this could entail the following:

* Developing standardized methodologies and tools to manage complexity effectively;

* The transition from SysML v1 to SysML v2 opens new opportunities for complexity analysis [31]. SysML v2 introduces a more robust and expressive syntax and semantics, enabling improved modeling precision and interoperability. Future research could explore how these enhancements impact complexity management, providing new methods to quantify and analyze the complexity of SysML v2 models. This could include developing tools to assess the impact of modular architecture and the improved APIs introduced in SysML v2 on system design and complexity [32].

* The dynamic aspects of SysML models must be incorporated. This could involve studying how model complexity evolves over time, particularly in response to changes in system behavior or environmental conditions. The integration of complexity analysis techniques with model validation and verification processes would help to enhance the reliability and quality of SysML models. This could involve identifying correlations between model complexity metrics and the likelihood of errors or inconsistencies. Furthermore, SysML v2's enhanced features for representing system behaviors and interactions could facilitate more comprehensive dynamic complexity analyses.

* The role of human factors could also be explored, such as cognitive load and decision-making biases, could also be explored in managing complexity within SysML models. SysML v2's improved expressiveness and usability might mitigate some of the challenges associated with human interpretation and cognitive strain, offering fertile ground for research on user-centric complexity metrics and visualizations.

* Furthermore, complexity analysis capabilities can be integrated directly into other existing SysML modeling tools to streamline the complexity management process. This would allow engineers to conduct real-time complexity analysis as they develop and refine their models. For SysML v2, embedding such capabilities into tools that leverage its modern APIs and integration potential could significantly improve efficiency, enabling seamless complexity monitoring and adaptive modeling strategies.

* The evolution of SysML v2 represents a pivotal moment for the field, offering a platform not only to extend existing complexity management approaches but also to develop entirely new methods tailored to its advanced capabilities. By addressing these areas, researchers can help ensure that SysML remains an effective and scalable tool for managing system complexity in increasingly sophisticated engineering environments.

**Author Contributions:** Conceptualization, all authors; methodology, all authors; software, A.B. and L.B.G.; validation, all authors; writing—original draft preparation, all authors; writing—review and editing, all authors; supervision, P.d.S.-S. and R.A.V. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research received no external funding.

**Institutional Review Board Statement:** Not applicable.

**Data Availability Statement:** No new data were created or analyzed in this study. Data sharing is not applicable to this article.

**Conflicts of Interest:** The authors declare no conflicts of interest.
## Abbreviations

The following abbreviations are used in this manuscript:

<table><tr><td>ECF</td><td>Environmental Complexity Factor</td></tr><tr><td>EF</td><td>Environmental Factor</td></tr><tr><td>GPS</td><td>Global Positioning System</td></tr><tr><td>GNSS</td><td>Global Navigation Satellite System</td></tr><tr><td>MBSE</td><td>Model-Based Systems Engineering</td></tr><tr><td>OMG</td><td>Object Modelling Group</td></tr><tr><td>SysML</td><td>System Modelling Language</td></tr><tr><td>TCF</td><td>Technical Complexity Factor</td></tr><tr><td>TF</td><td>Technical Factor</td></tr><tr><td>UAW</td><td>Unadjusted Actor Weight</td></tr><tr><td>UCP</td><td>Use Case Point</td></tr><tr><td>UML</td><td>Unified Modelling Language</td></tr><tr><td>UUCW</td><td>Unadjusted Use Case Weight</td></tr><tr><td>XML</td><td>Extensible Markup Language</td></tr></table>

## Note

¹ https://ttool.telecom-paris.fr/ (accessed on 9 December 2025).

## References

1. OMG. *OMG Systems Modeling Language*; Object Management Group: Milford, MA, USA, 2017. Available online: https://www.omg.org/spec/SysML/1.5 (accessed on 9 December 2025).

2. Wolny, S.; Mazak, A.; Carpella, C.; Geist, V.; Wimmer, M. *Thirteen Years of SysML: A Systematic mapping Study*. *Softw. Syst. Model.* **2020**, *19*, 111–169. [CrossRef]

3. Santos, T.; Soares, M. *A Qualitative Study on SysML Based on Perceived Views from Industry Professionals*. In *Computational Science and Its Applications*; LNCS: Ghaziabad, India, 2021; pp. 299–310. [CrossRef]

4. de Saqui-Sannes, P.; Vingerhoeds, R.A.; Garion, C.; Thirioux, X. *A Taxonomy of MBSE Approaches by Languages, Tools and Methods*. *IEEE Access* **2022**, *10*, 120936–120950. [CrossRef]

5. Friedenthal, S.; Moore, A.; Steiner, R. *A Practical Guide to SysML: The Systems Modeling Language*; Morgan Kaufmann: Burlington, MA, USA, 2014.

6. Umeda, H.; Takatsuki, S.; Kobayashi, T.; Ueda, Y.; Wada, A.; Komatsu, Y.; Ishihama, N.; Iwata, T. *System modeling process with SysML assuming the use of models*. In *Proceedings of the 2022 IEEE International Symposium on Systems Engineering (ISSE)*, Vienna, Austria, 24–26 October 2022; pp. 1–8. [CrossRef]

7. Pasek, Z.; Dufresne, D.; Thalmann, D. *The role of Model-Based Systems Engineering (MBSE) in managing complex systems*. *Int. J. Syst. Syst. Eng.* **2015**, *6*, 284–300.

8. Blanchard, B.S.; Fabrycky, W.J. *System Engineering and Analysis*; Prentice Hall: Englewood Cliffs, NJ, USA, 2011.

9. Eppinger, S.D.; Browning, T.R. *Design Structure Methods and Applications*; MIT Press: Cambridge, MA, USA, 2012. Available online: https://www.researchgate.net/publication/371165639_Proceedings_2017_DSM_Conference (accessed on 9 December 2025).

10. Boehm, B.W. *Software Engineering Economics*; Prentice Hall: Englewood Cliffs, NJ, USA, 1981.

11. Cohn, M. *Agile Estimating and Planning*; Prentice Hall: Englewood Cliffs, NJ, USA, 2005.

12. Efatmaneshnik, M.; Ryan, M.J. *A general framework for measuring system complexity*. *Complexity* **2016**, *21*, 533–546. [CrossRef]

13. Gullapalli, L.B.; Bhatnager, A.; de Saqui-Sannes, P.; Vingerhoeds, R. *Quantitative Assessment of Complexity in SysML Models*. In *Proceedings of the Modelling and Simulation 2024, ESM 2024; San Sebastian, Spain, 23–25 October 2024; EUROSYS: Oostende, Belgium, 2024*; pp. 275–280.

14. Flood, R.L. *Liberating Systems Theory*. In *Contemporary Systems Thinking*; Plenum Press: New York, NY, USA, 1990.

15. Van de Poel, I. *Values in engineering design*. In *Handbook of the Philosophy of Science. Volume 9: Philosophy of Technology and Engineering Sciences*; Elsevier: North-Holland, The Netherlands, 2009; pp. 973–1006.

16. Kokol, P.; Podgorelec, V.; Habrias, H.; Rabia, N. *The Complexity of Formal Specifications—Assessments by alpha-Metric*. *SIGPLAN Not.* **1999**, *34*, 84–88. [CrossRef]

17. yat Cheung, T.; Ren, S.; Mak, W.M. *A tool for assessing the quality of distributed software designs*. In *Proceedings Software Education Conference (SRIG-ET’94)*, Dunedin, New Zealand, 22–25 November 1994; pp. 42–49. [CrossRef]
18. Huang, S.; Lai, R. On measuring the complexity of an estelle specification. *J. Syst. Softw.* **1998**, *40*, 165–181. [CrossRef]

19. Masmali, O.; Badreddin, O. Comprehensive Model-Driven Complexity Metrics for Software Systems. In Proceedings of the 2020 IEEE 20th International Conference on Software Quality, Reliability and Security Companion (QRS-C), Macau, China, 11–14 December 2020; pp. 674–675. [CrossRef]

20. Cruz-Lemus, J.A.; Maes, A.; Genero, M.; Poels, G.; Piattini, M. The impact of structural complexity on the understandability of UML statechart diagrams. *Inf. Sci.* **2010**, *180*, 2209–2220. [CrossRef]

21. Davis, A. *Software Engineering and Analysis*; Pearson: London, UK, 1993.

22. Parsons-Hann, H.; Liu, K. Measuring Requirements Complexity to Increase the Probability of Project Success. In Proceedings of the Seventh International Conference on Enterprise Information Systems—Volume 3: ICEIS, Miami, FL, USA, 25–28 May 2005.

23. Wrigley, R.; Dexter, A. Estimating Project Effort Based on Skill Levels. *J. Proj. Manag.* **1987**, *8*, 100–110.

24. Kirmani, M.M.; Wahid, A. Impact of Modification Made in Re-UCP on Software Effort Estimation. *J. Softw. Eng. Appl.* **2015**, *8*, 276. [CrossRef]

25. Kusumoto, S.; Matukawa, F.; Inoue, K.; Hanabusa, S.; Maegawa, Y. Estimating effort by use case points: Method, tool and case study. In Proceedings of the 24th International Conference on Software Engineering, Orlando, Fl, USA, 19–25 May 2002; pp. 601–606. [CrossRef]

26. Clemmons, R.K. Project Estimation With Use Case Points. *CrossTalk J. Def. Softw. Eng.* **2006**, *19*, 18–22.

27. Sinha, K.; Suh, E.S. Pareto-optimization of complex system architecture for structural complexity and modularity. *Res. Eng. Des.* **2018**, *29*, 123–141. [CrossRef]

28. Lopez, V.; Thomas, L. Metric for Structural Complexity Assessment of Space Systems Modeled Using the System Modeling Language. *Aerospace* **2022**, *9*, 612. [CrossRef]

29. Lankford, J. Measuring system and software architecture complexity. In Proceedings of the IEEE Aerospace Conference Proceedings (Cat. No.03TH8652), Big Sky, MT, USA, 8–15 March 2003.

30. Dalvi, A.S.; El-Mounayri, H. Integrated System Architecture Development Framework And Complexity Assessment. In Proceedings of the ASME 2021 International Mechanical Engineering Congress and Exposition, Virtual, Online, 1–5 November 2021.

31. Friedenthal, S. *SysML v2 Basics: Transition from SysML v1 to SysML v2*; OMG MBSE Wiki: Torrance, CA, USA, 2024.

32. OMG. *SysML v2 Beta Specifications*; Object Management Group (OMG): Milford, MA, USA, 2023.

**Disclaimer/Publisher's Note:** The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.