Direct Answer
The Block Definition Diagram (BDD) is the SysML equivalent of a UML Class diagram, but with critical differences: a Block represents a system component with both structural and behavioural features, and it owns value properties (typed by Value Types) rather than just attributes. The BDD defines the vocabulary of the system model — every block you create in a BDD is a definition that can be instantiated elsewhere. Get the BDD wrong — treating Blocks like Classes, ignoring value properties, missing composition relationships — and every Internal Block Diagram, Parametric Diagram, and requirements traceability relationship built on top of it is structurally flawed. In Sparx EA, the SysML MDG provides the Block stereotype, value type library, and BDD diagram type. The package structure, tagged value conventions, and naming standards you establish in the BDD are the foundation of a maintainable MBSE repository.
Block vs UML Class: The Critical Difference
Most engineers encountering SysML for the first time treat Blocks as Classes. This is wrong in ways that propagate through the entire model.
What a UML Class represents: a type of object in a software system. Attributes are data fields. Operations are methods. Relationships are inheritance, association, and dependency.
What a SysML Block represents: a modular system component — hardware, software, or both — with physical, functional, and behavioural characteristics. A Block is not just a data container; it represents something that exists in the physical or logical world.
The key differences:
Value Properties. A Block has value properties typed by SysML Value Types or standard data types. A value property represents a quantitative or qualitative characteristic of the block — mass, voltage, temperature, reliability, throughput. UML attributes are typed by classes or primitives. SysML value properties are typed by value types that carry units of measure.
Parts vs References. In SysML, the distinction between a Part Property (owned part — composition) and a Reference Property (referenced part — association without ownership) is architecturally significant. A Block that owns a part is responsible for creating and destroying it. A Block that references a part does not own it.
Ports. Blocks have ports — flow ports, proxy ports, and full ports in SysML 1.x — that define the interfaces through which the block interacts with its environment. Classes have no equivalent concept.
Constraints. Blocks can own Constraint Properties — instances of Constraint Blocks that define mathematical or logical relationships between the block’s value properties. These are the foundation of Parametric Diagrams.
BDD Package Structure in Sparx EA
Before creating any diagrams, establish the package structure. This is the most consequential decision in MBSE repository setup.
Recommended BDD package structure:
“ [System Name] MBSE Repository ├── System Context │ └── System Context BDD ├── System Block Hierarchy │ ├── System Level BDD │ ├── Subsystem A BDD │ ├── Subsystem B BDD │ └── ... ├── Interfaces │ ├── Interface Blocks BDD │ └── Item Flow Types BDD ├── Value Types and Units │ └── Value Type Library BDD ├── Constraint Blocks │ └── Constraint Block Library BDD └── Supporting Structures ├── Enumerations └── Signal Types “
Keep block definitions in dedicated BDD diagrams — one diagram per subsystem level. Do not mix block definitions with instance-level content (Internal Block Diagrams). The BDD is a definition space; the IBD is an instance space. Mixing them creates confusion that grows exponentially as the model scales.
The Block Stereotype in Sparx EA
With the SysML MDG active in Sparx EA, the Block stereotype is available in the SysML toolbox. Key configuration steps:
Creating a Block:
- Open a BDD diagram
- From the SysML toolbox, drag a Block element onto the diagram
- Name the block with a noun phrase representing the component (e.g., “Hydraulic Actuator”, “Navigation Subsystem”, “Power Supply Unit”)
- Open the Block’s property compartment
Block compartments in Sparx EA: Sparx EA renders SysML compartments for each property type. Enable the compartments you need:
values— value properties (quantitative characteristics)parts— part properties (composition-owned sub-components)references— reference properties (association to non-owned components)operations— operations (functions/behaviours)constraints— constraint propertiesports— ports (flow ports, proxy ports)
Right-click a block in a diagram → Compartment Visibility to control which compartments are displayed.
Standard tagged values for blocks: Add these to every block in your model using a custom MDG Technology profile:
block_id— unique identifier for traceability (e.g., BLK-PROP-001)verification_method— Analysis / Test / Demonstration / Inspectionallocationtosubsystem— which physical or logical subsystem this block belongs tomaturity_level— concept / preliminary / detailed / qualifiedresponsible_engineer— owner of this block definition
Value Types and Enumerations
Value types are the SysML mechanism for typed, unit-carrying properties. Do not use primitive types (Integer, Real, String) for engineering quantities — use SysML Value Types with units.
Creating a Value Type library in Sparx EA:
Create a Value Type Library BDD diagram in your Supporting Structures package. Populate it with Value Type elements for each engineering quantity used in your model:
Mass(unit: kg, g, lb)Voltage(unit: V, mV, kV)Temperature(unit: degC, K, degF)Frequency(unit: Hz, kHz, MHz, GHz)DataRate(unit: bps, Mbps, Gbps)Power(unit: W, mW, kW)
Use SysML Unit and QuantityKind elements to define the unit system. Link Value Types to QuantityKinds using «quantityKind» relationships.
Enumerations. Use SysML Enumeration elements for discrete property values: OperationalState (Operating / Standby / Fault / Off), OperatingMode (Nominal / Degraded / Emergency), InterfaceType (Ethernet / CAN / MIL-STD-1553 / SpaceWire).
Why this matters: when value properties are typed by proper Value Types with units, Parametric Diagrams can bind them to Constraint Blocks and perform margin analysis. If you use raw Real values without unit types, parametric analysis is impossible and the model cannot support the performance budgeting use case.
Associations: Composition and Reference
The relationships between blocks in a BDD carry architectural meaning. Use the right one.
Composition (Part Property). The child block is owned by the parent. If the parent is destroyed, the child is destroyed. The child cannot be shared between multiple parents. Use composition for physical containment (a power supply is part of a chassis — it cannot be in two chassis simultaneously).
In Sparx EA: draw a Composition relationship (solid diamond at the parent end). Sparx EA creates a Part Property in the parent block’s parts compartment automatically.
Association (Reference Property). The child block is referenced by the parent but not owned. The child can be shared. Use association for logical connections (a controller references a sensor — the sensor exists independently and might be referenced by multiple controllers).
In Sparx EA: draw an Association relationship. A Reference Property appears in the parent block’s references compartment.
Generalisation. One block is a specialisation of another. The child inherits all properties, ports, and constraints of the parent. Use generalisation sparingly in systems engineering — system components are usually distinct rather than typed hierarchies.
Connecting BDD to IBD
The BDD is a definition. The IBD is an instantiation.
For every block defined in a BDD that has internal structure (sub-blocks, ports, connectors), you can create one or more IBDs showing instances of that block in context.
In Sparx EA:
- Right-click the Block element in a BDD
- Select Add Diagram → SysML 1.x → Internal Block Diagram
- The IBD is automatically scoped to the selected block
- Drag part properties from the block’s property compartment onto the IBD as part instances
- Connect ports with connectors and add item flows
The structural discipline is: every part that appears in an IBD must be defined as a Part Property (owned by the parent block’s composition) in a BDD. You cannot instantiate parts in an IBD that are not defined in the corresponding BDD. Sparx EA enforces this if you use the formal SysML toolbox rather than dragging arbitrary elements.
Common BDD Mistakes
Mistake 1: Treating Blocks like Classes. Adding string and integer attributes instead of typed value properties. Missing ports. No unit types. The model looks like a class diagram with a different icon.
Mistake 2: Forgetting value properties. An aerospace subsystem without mass, power consumption, and thermal dissipation value properties cannot support mass budget or power budget analysis. Every physical block must have its engineering parameters captured as value properties.
Mistake 3: Overusing generalisation. Systems engineers trained in object-oriented software development reach for inheritance. In systems engineering, most blocks are distinct components, not specialisations. Use generalisation only when blocks genuinely share a formal interface or structural pattern.
Mistake 4: No naming convention. Blocks named “System”, “Component”, “Unit” — without a systematic naming convention — make the model unusable at scale. Establish a naming convention before the first block is created: [Subsystem]-[Function]-[Number] (e.g., “PROP-ValveAssembly-001”).
Mistake 5: Not maintaining the Value Type library. Engineers add raw Real attributes instead of adding to the Value Type library. The library grows inconsistent. Parametric analysis becomes impossible. Enforce Value Type usage through the MDG Technology profile by restricting which types can be used for value properties.
Frequently Asked Questions
Q: What is the difference between SysML 1.x and SysML v2 for BDDs? A: SysML v2 renames the BDD to Definition Diagram and introduces significant structural changes — Blocks become Part Definitions, port types change substantially, and the language moves to a textual syntax. Sparx EA supports SysML 1.x natively; SysML v2 support is in development. For current MBSE programmes, SysML 1.x in Sparx EA is production-ready. For new programmes starting in 2026, evaluate whether your domain requires SysML v2 compliance before committing to a toolset.
Q: How many blocks should a BDD have? A: As many as the system needs — but each diagram should be digestible. A BDD diagram with more than 15 blocks is usually too complex to read. Use hierarchical decomposition: one top-level BDD showing the system and its major subsystems, then separate BDD diagrams for each subsystem’s internal block decomposition.
Q: Can we use Sparx EA’s BDD for software architecture as well as hardware? A: Yes. SysML BDD is explicitly designed for mixed hardware-software systems. Software components are Blocks with appropriate tagged values and interfaces. The integration of hardware and software in a single BDD is one of SysML’s key advantages over domain-specific notations.
Q: How do we handle block libraries (reusable component definitions)? A: Create a Block Library package in your repository. Model common reusable components — standard connectors, commercial off-the-shelf hardware items, standard software components — as blocks in this library. When a project needs one of these components, reference the library block (do not copy it). This ensures that changes to the library propagate to all projects that reference it.
Q: What is the relationship between BDD blocks and TOGAF building blocks? A: SysML BDD blocks are the MBSE equivalent of TOGAF Solution Building Blocks. Both represent specific implementations of a capability. The governance parallel is direct: just as TOGAF governs which SBBs are approved for enterprise use, MBSE governance controls which block definitions are approved for use in system designs. A mature organisation maintains a formal relationship between its TOGAF SBB library and its SysML block library for cross-domain traceability.
Q: How does Sparx EA handle constraint properties in the BDD? A: Sparx EA supports Constraint Properties in the BDD through the SysML MDG. A Constraint Property is an instance of a Constraint Block — defined in a separate Constraint Block BDD — placed within a block. The Constraint Property binds the constraint’s parameters to the host block’s value properties. This is the structural foundation for Parametric Diagrams. The Sparx EA parametric diagram tool then visualises these bindings as binding connectors.
Q: Is Platform Support the right engagement for BDD help? A: Yes. MBSE teams building BDD structures typically need ongoing expert support — questions arise during modeling that require immediate practitioner-level answers. Platform Support provides a retained access arrangement with our MBSE architects: query response, model review, and tooling configuration support without the overhead of a project engagement. Contact us to discuss a Platform Support arrangement for your MBSE team.
Q: What is the correct way to model an interface between blocks in a BDD? A: Use Block associations to show that blocks interact. For typed interfaces, use Interface Block (IBF) elements — a special kind of block that defines the properties and operations of an interface. Ports on blocks are typed by Interface Blocks. This is the SysML 1.x mechanism for precise interface specification. Model Interface Blocks in a dedicated Interface Blocks BDD diagram, not mixed into the block hierarchy diagrams.
Next Step
MBSE teams doing serious SysML work in Sparx EA benefit from ongoing practitioner support — someone who can answer the modeling question on Tuesday afternoon rather than waiting for the next project engagement. Platform Support is a retained arrangement that gives your MBSE team direct access to our SysML architects for query response, model review, and tooling guidance.
