SysML Block Definition Diagram (BDD) in Sparx EA: Complete Practitioner Guide

The Block Definition Diagram is the foundation of every SysML model, and the place where most newcomers go wrong. It looks like a UML Class diagram, so engineers treat Blocks like Classes — and that single mistake propagates through every Internal Block Diagram, Parametric Diagram, and traceability relationship built on top of it. This guide covers what a Block actually is, how to structure a BDD in Sparx EA, and the conventions that keep a model maintainable as it scales.

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 compound through the entire model.

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.

A SysML Block represents a modular system component — hardware, software, or both — with physical, functional, and behavioral characteristics. It is not just a data container; it represents something that exists in the physical or logical world.

The differences that matter:

• Value properties. A Block has value properties typed by SysML Value Types — mass, voltage, temperature, reliability, throughput — that carry units of measure. UML attributes are typed by classes or primitives and carry no units.
• Parts vs references. The distinction between a Part Property (owned — composition) and a Reference Property (referenced — 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 is not.
• Ports. Blocks have ports — flow ports, proxy ports, and full ports in SysML 1.x — defining the interfaces through which the block interacts with its environment. Classes have no equivalent.
• Constraints. Blocks can own Constraint Properties — instances of Constraint Blocks that define mathematical or logical relationships between value properties. These are the foundation of Parametric Diagrams.

Definition vs instance: the one rule that governs everything

The single discipline that keeps a SysML model coherent is separating definitions from instances. The BDD is the definition space; the Internal Block Diagram (IBD) is the instance space. Every block you define in a BDD can be instantiated as a part in an IBD — but you cannot instantiate a part in an IBD that was never defined in the corresponding BDD.

The BDD declares which parts a block may own; the IBD wires up instances of those parts. Mix the two and the model becomes unreadable at scale.

BDD package structure in Sparx EA

Before creating any diagrams, establish the package structure — the most consequential decision in repository setup. A practical structure separates definitions, interfaces, value types, and constraints:

• System Context — the system context BDD.
• System Block Hierarchy — system-level BDD plus one BDD per subsystem.
• Interfaces — Interface Blocks BDD and Item Flow Types BDD.
• Value Types and Units — the Value Type Library BDD.
• Constraint Blocks — the Constraint Block Library BDD.
• Supporting Structures — enumerations and signal types.

Keep block definitions in dedicated BDDs — one per subsystem level — and do not mix them with instance-level IBD content. The confusion of blending the two grows exponentially as the model scales.

The Block stereotype in Sparx EA

With the SysML MDG Technology active, the Block stereotype is available in the SysML toolbox. To create one: open a BDD, drag a Block element onto it, name it with a noun phrase ("Hydraulic Actuator," "Navigation Subsystem," "Power Supply Unit"), then open its property compartment.

Block compartments. Sparx EA renders a compartment for each property type — values, parts, references, operations, constraints, and ports. Right-click a block → Compartment Visibility to control which are displayed.

Standard tagged values. Add these to every block via a custom MDG profile so traceability and governance have something to query:

• block_id — unique identifier (e.g., BLK-PROP-001).
• verification_method — Analysis / Test / Demonstration / Inspection.
• allocation_to_subsystem — the physical or logical subsystem this block belongs to.
• maturity_level — concept / preliminary / detailed / qualified.
• responsible_engineer — owner of the 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 Value Types with units.

Create a Value Type Library BDD in your Supporting Structures package and populate it with a Value Type for each engineering quantity: Mass (kg, g, lb), Voltage (V, mV, kV), Temperature (degC, K, degF), Frequency (Hz, kHz, MHz), DataRate (bps, Mbps, Gbps), Power (W, mW, kW). Use SysML Unit and QuantityKind elements to define the unit system, linking Value Types to QuantityKinds via «quantityKind» relationships.

Enumerations. Use SysML Enumeration elements for discrete 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 for margin analysis. Raw Real values without unit types make parametric analysis impossible and break 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 — destroy the parent and the child goes with it, and the child cannot be shared. Use composition for physical containment (a power supply is part of a chassis; it cannot be in two chassis at once). In Sparx EA, draw a Composition relationship (solid diamond at the parent end) and Sparx EA creates a Part Property in the parent's parts compartment automatically.

Association (Reference Property). The child block is referenced but not owned, and can be shared. Use association for logical connections (a controller references a sensor that exists independently and may be referenced by several controllers). In Sparx EA, draw an Association and a Reference Property appears in the parent's references compartment.

Generalization. One block specializes another, inheriting its properties, ports, and constraints. Use it 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 with internal structure, you can create one or more IBDs showing instances of that block in context.

In Sparx EA: right-click the Block in a BDD → 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, then connect ports with connectors and add item flows.

The structural discipline: every part that appears in an IBD must be defined as a Part Property in the corresponding BDD. Sparx EA enforces this when 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 ends up 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 needs its engineering parameters captured as value properties.

Mistake 3: overusing generalization. Engineers from object-oriented backgrounds reach for inheritance. In systems engineering most blocks are distinct components, not specializations. Use generalization only when blocks genuinely share a formal interface or structural pattern.

Mistake 4: no naming convention. Blocks named "System," "Component," "Unit" make the model unusable at scale. Establish a convention before the first block is created — for example, [Subsystem]-[Function]-[Number] ("PROP-ValveAssembly-001").

Mistake 5: not maintaining the Value Type library. Engineers add raw Real attributes instead of extending the library, and it grows inconsistent until parametric analysis becomes impossible. Enforce Value Type usage through the MDG profile by restricting which types can be used for value properties.

Frequently asked questions

Where this fits in a larger MBSE practice

The BDD is the foundation, but a production SysML model spans requirements, internal structure, behavior, and performance. Once your block hierarchy is sound, the next steps are the Internal Block Diagram for connections and flows, the Parametric Diagram for constraints and margins, and repository governance once the model grows. For teams doing serious SysML work, Sparx Services provides ongoing practitioner support — model review, modeling guidance, and tooling configuration. See our MBSE discipline for how that support is structured.