Block definition diagram

This article needs additional or more specific categories. Please help out by adding categories to it so that it can be listed with similar articles. (May 2025)

Block Definition Diagrams (BDD)^[1] are a structural representation of blocks, interfaces, and relationships.^[2] The BDD represents the structure of the System of Interest^{[Note 1]} at a Black box level. The SysML BDD is based on the UML Class Diagram.

Block Definition Diagrams (BDDs) 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 (with types), and on the corresponding IBD you show their interconnections.^[2]

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.^[2] A block encapsulates information describing the structural properties and the dynamic behavior of the element.

Blocks have properties (attributes) 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.^[3]
• 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 (typically primitives like Integer, String, or user-defined types) that hold data values.
• Flow Properties: Special properties representing flow of material or information through a block. They have a direction (in/out) 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 (always with composite aggregation). 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 (which own their own features) and Proxy Ports (which expose features of the block or its parts).

SysML defines a special block stereotype «constraintBlock» used for parametric modeling. A Constraint Block packages one or more mathematical constraints (parameters and equations). When used in a BDD, a constraint block appears as a block and its usage appears as a constraint property (a composite relationship)^[4]

BDDs include various connections between elements:

• Generalization (Inheritance): Blocks can specialize other blocks (solid line with white triangle).
• Associations: Standard UML associations between blocks, possibly with name and multiplicity.
• Composite/Aggregation (Composition): Shown as filled/hollow diamonds, representing part-whole. A filled diamond at the owning block end indicates composition (the part's lifecycle is bound to the whole). This is how parts (strongly owned components) 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 <<satisfy>> a requirement.
• Binding Connectors: In Parametric/Constraint diagrams (or on BDDs), 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:

BDD defines the features of a block and any relationships between blocks such as associations, generalizations, and dependencies^[3]

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.^[5]

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 (conceptual to detailed design) and viewpoints (logical vs physical). For example, the top-level BDD might represent a logical architecture (function blocks) 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 (activities, sequence, state machines) or parametric diagrams enable a simulation-ready model.^[2]

• The Systems Engineering Body of Knowledge (SeBoK)