Block definition diagram


Block Definition Diagrams are a structural representation of blocks, interfaces, and relationships. The BDD represents the structure of the System of Interest at a Black box level. The SysML BDD is based on the UML Class Diagram.

Overview

Block Definition Diagrams are SysML's primary static-structure diagrams. They depict blocks – the basic modeling unit in SysML – and their contents and relationships.
A BDD often shows multiple levels of the system hierarchy. For example, a system block may be "nested" by alternating BDDs and IBDs: on one BDD you define the next layer of parts, and on the corresponding IBD you show their interconnections.

Elements

Blocks

Source:
The primary elements in a BDD are blocks, drawn as rectangles. Blocks represent any system element, or other element of interest. Blocks may represent hardware, software, personnel, facilities, or any element relevant to modeling the system, its components, or its context. A block encapsulates information describing the structural properties and the dynamic behavior of the element.

Block Properties

Blocks have properties that define their parts, references, values, and flows. Notable property kinds are:
  • Part Properties: These are owned sub-components. In a BDD, part properties appear as attributes. In the diagram they are modeled with filled-diamond composition relationships, as shown in the example with the relationship between the Specific Subsystem and the System of Interest. This indicates that the block owns those parts.
  • Reference Properties: These are weaker associations. In the diagram they are modeled with a hollow-diamond, as shown in the example with the relationship between the Generic Subsystem and the System of Interest. This indicates that a block refers to another element without owning it.
  • Value Properties: Attributes typed by a ValueType that hold data values.
  • Flow Properties: Special properties representing flow of material or information through a block. They have a direction and a type. In BDDs, flow properties can be shown in block compartments or on ports to indicate rates or currents
  • Constraint Properties: If a block has a ConstraintBlock attached, that is shown as a property of the block. Constraint blocks define parametric equations that constrain values.
  • Ports and Interfaces: Blocks have ports, depicted as small squares on the block boundary, which define explicit interaction points. SysML supports two port types: Full Ports and Proxy Ports.

Constraint Blocks

SysML defines a special block stereotype «constraintBlock» used for parametric modeling. A Constraint Block packages one or more mathematical constraints. When used in a BDD, a constraint block appears as a block and its usage appears as a constraint property

Relationships

Source:
BDDs include various connections between elements:
  • Generalization : Blocks can specialize other blocks.
  • Associations: Standard UML associations between blocks, possibly with name and multiplicity.
  • Composite/Aggregation : Shown as filled/hollow diamonds, representing part-whole. A filled diamond at the owning block end indicates composition. This is how parts are shown.
  • Dependencies: Directed dashed arrows, used for various semantics like «use», «implement», «refine», or «allocate». For example, a block may «use» an interface block, or «allocate» a function or state machine to a block, or <> a requirement.
  • Binding Connectors: In Parametric/Constraint diagrams, binding connectors link value properties to constraint parameters.
Together, these elements allow a BDD to represent the full structure of a system: its components, their features, and how they fit together. The No Magic documentation summarizes this view:

When to use

In systems engineering, BDDs serve as the skeleton of the system model. They capture system architecture, component definitions, and the high-level static decomposition. In addition, BDDs model any hierarchy relevant to the development process. In MBSE workflows, BDDs link to many other elements: each block might be traced to requirements, decomposed into internal structures, or allocated to lower-level functions. For instance, a block on a BDD can be connected via «satisfy» to requirements, or via «allocate» to activities that implement its behavior. BDDs also set up for parametric analysis: blocks can include constraint properties that later become constraint diagrams for simulations.
Additionally, BDDs help produce system dictionaries or glossaries: a complete BDD could serve as a registry of all system elements, their definitions, and interfaces. They are used across system design phases and viewpoints. For example, the top-level BDD might represent a logical architecture while a lower-level BDD shows physical modules. BDDs support traceability and rigor: because they are part of an integrated model, every block can be linked back to stakeholder requirements and forward to design specifications. The synergies between BDDs and behavioral diagrams or parametric diagrams enable a simulation-ready model.