How to Properly Decompose a System into Subsystems in SysML (Road Bike Example)

One of the most important steps in Model-Based Systems Engineering (MBSE) is properly decomposing a system into subsystems. Good decomposition makes a model easier to understand, scale, and maintain. Poor decomposition, on the other hand, can create confusing models that are difficult to refine as the system evolves.

In this tutorial, we explore how to properly decompose a system in SysML using a simple and intuitive example: a road bike.

By examining examples of both poor and good modeling practices, we can better understand how to structure system architectures effectively.

Watch the full walkthrough here:

https://www.youtube.com/watch?v=6-BrWoaRc8k

---

What is System Decomposition in SysML?

System decomposition is the process of breaking a system down into smaller subsystems and components.

In SysML, this is typically represented using:

• Blocks

• Part properties

• Containment hierarchies

• Internal Block Diagrams (IBDs)

The goal is to create an architecture that clearly communicates how the system is structured and how its parts relate to one another.

In our example, the system of interest is a road bike, and we will decompose it into logical subsystems.

---

Starting Point: Identifying System Components

Before decomposing the bike, we first identify the major physical components:

• frame

• wheels

• drivetrain

• seat

• handlebars

• pedals

• fork

Each component can be represented as a SysML block.

However, simply listing all components directly under the bike system is not ideal architecture.

This leads us to the first example of poor decomposition.

---

Example of Poor System Decomposition (Too Flat)

In the first bad example, every component is placed directly beneath the bike system.

This creates a flat architecture where dozens of parts sit at the same level in the containment tree.

Problems with flat decomposition include:

• the model becomes difficult to read

• subsystem relationships are unclear

• scaling the architecture becomes difficult

• large models become cluttered

As systems grow in complexity, flat structures quickly become unmanageable.

Instead, components should be grouped into logical subassemblies.

---

Example of Poor Decomposition (Too Many Levels)

The second bad example shows the opposite problem.

Instead of being too flat, the model has too many decomposition levels.

For example:

• frame

• not frame

• interfaces for rider

• interfaces for road

• tube vs not tube

This structure introduces several modeling problems:

Misuse of “Not” Terminology

Using categories such as “not frame” or “not tube” creates ambiguous architectural structures and should generally be avoided.

Breaking the System by Interfaces

Decomposition should not be driven purely by what the system interfaces with. Instead, it should reflect physical or logical assemblies.

Single-Component Assemblies

Some subsystems in the example contain only one component, which is usually unnecessary.

If an assembly only contains one element, the hierarchy can often be simplified.

---

Decomposition vs Classification (Taxonomy)

Another common modeling mistake is confusing decomposition relationships with generalization relationships.

These represent two very different concepts.

Decomposition (Composition)

Decomposition describes how a system is built from parts.

Example:

Bike
→ Wheel Assembly
→ Frame Assembly
→ Drivetrain Assembly

This describes structure.

Generalization (Taxonomy)

Generalization describes types of elements that share common properties.

Example:

Tubular Structure
→ Top Tube
→ Down Tube
→ Seat Tube

In this case, all elements inherit properties like:

• inner diameter

• outer diameter

• material

• length

This is classification, not decomposition.

Understanding the difference between these two modeling concepts is critical for building clear SysML architectures.

---

Example of Good System Decomposition (The Goldilocks Approach)

A good decomposition structure avoids both extremes.

The architecture should be neither too flat nor too deep.

In the road bike example, the system is decomposed into five major subassemblies:

• Wheel Assembly

• Seat Assembly

• Frame Assembly

• Control System

• Propulsion Assembly

This structure is significantly easier to understand than the previous examples.

Each subsystem groups related components together and provides a clear architectural hierarchy.

---

The “5 ± 2” Rule for Subsystems

A useful rule of thumb in system architecture is the “five plus or minus two” rule.

A system should generally contain between three and seven subsystems.

If there are too few subsystems:

• the model becomes too tall

• decomposition levels increase unnecessarily

If there are too many subsystems:

• the model becomes difficult to comprehend

• relationships become harder to track

The Goldilocks architecture works well because it stays within this range.

---

How Good Architecture Reveals Missing Components

One of the biggest advantages of proper decomposition is that it helps identify missing parts of the system.

In the road bike example, once the architecture was properly organized, something became obvious:

The seat itself was missing.

The model originally contained a seat post, but not the actual seat block.

Because the architecture was clearly structured, this omission was immediately visible and easy to fix.

This is one of the major benefits of good MBSE architecture.

---

Scaling the Model as Complexity Grows

Real engineering systems rarely stay simple.

As the model evolves, engineers may discover that the bike contains dozens of additional components.

For example:

• bearings

• cables

• brake calipers

• chainrings

• sprockets

• spokes

A well-structured architecture allows these additional components to be mapped cleanly into existing subsystems.

For example:

Wheel Assembly
→ spokes
→ rim
→ hub

Propulsion Assembly
→ chain
→ crankset
→ cassette

When architecture is designed well, expanding the model becomes much easier.

---

Key Takeaways for SysML System Decomposition

When decomposing systems in SysML, remember these principles:

Avoid flat architectures

Too many components at one level create confusion.

Avoid overly deep hierarchies

Too many decomposition levels make models difficult to follow.

Use logical assemblies

Subsystems should represent meaningful engineering groupings.

Do not confuse decomposition with classification

Generalization represents taxonomy, not system structure.

Follow the 5 ± 2 rule

Keeping subsystem counts manageable improves clarity.

Good architecture exposes modeling gaps

A clear structure helps reveal missing components and inconsistencies.

---

Learn More SysML Architecture Techniques

If you are learning SysML system architecture, understanding proper decomposition is one of the most important modeling skills.

Watch the full tutorial here:

https://www.youtube.com/watch?v=6-BrWoaRc8k

The video walks through the road bike example step-by-step and demonstrates how to structure subsystem architectures effectively.

---

Final Thoughts

System decomposition is the foundation of good MBSE architecture.

When done correctly, it allows engineers to:

• understand complex systems quickly

• scale models as complexity increases

• organize components logically

• maintain clear architectural structure

The road bike example provides a simple but powerful demonstration of how good system decomposition leads to better SysML models.