SysML FAQ: What is an Internal Block Diagram (IBD) and how is it used?
What is a SysML Internal Block Diagram?
Definitions
Block: A Block (notation: rectangle with keyword = «block») represents a system component, a modular structural unit that encapsulates its contents (Properties, Behaviors, Constraints) and supports first-class (i.e., can be drawn and directly manipulated in the model repository) Interfaces. Behaviors encapsulated by Blocks include: Operations, Signals, and State Machines. The unique interaction points for attaching and connecting ("wiring") Block Interfaces are called Ports.
- Blocks can specify software, hardware, mechanical, and wetware (persons, organizations, facilities) components.
- Blocks support both Provided (implemented or realized) and Required (used) Interfaces for both information and physical flows.
- Blocks can be recursively decomposed into Parts, where each Part must also be defined by a Block. (See Usage Notes below.)
Internal Block Diagram (ibd): An Internal Block Diagram is a static structural diagram owned by a particular Block that shows its encapsulated structural contents: Parts, Properties, Connectors, Ports, and Interfaces. Stated otherwise, an IBD is a "white-box" perspective of an encapsuated ("black-box") Block.
- Blocks can be recursively decomposed ("nested") into Parts by alternating between Block Definition Diagram (BDD) definitions and Internal Block Diagram (IBD) usages (See Usage Notes below.)
- Behaviors can either be encapsulated by Blocks (e.g., Operations, Signals, and State Machines) or Allocated (via «allocate» Dependency) to Blocks (e.g., Activities/Actions) directly or indirectly (via Interfaces).
- Blocks can be mathematically constrained via Constraint Blocks to produce mathematically simulatable Parametric diagrams.
- compare and contrast: UML 2 Class and Component diagrams; SA/SD System Context & Structure Chart diagrams; IDEF IDEF1X diagrams.
Purpose
The purpose of Internal Block Diagrams (IBDs) is to show the encapsulated structural contents (Parts, Properties, Connectors, Ports, Interfaces) of Blocks so that they can be recursively decomposed and "wired" using Interface Based Design techniques. When used correctly BDDs + IBDs are recursively scalable and mathematically (parametrically) simulatable (See Executable Semantics below.)
Diagram Properties
| Diagram Name | Diagram Type | UML 2 Analog | SDLC Usage | Essential AGILE SYSML? |
Dynamic Sim † |
Math Sim ‡ |
Auto Code Gen |
Rigor | Semi | Informal |
|---|---|---|---|---|---|---|---|---|---|---|
| Internal Block Diagram (ibd) | Static Structure [White Box Usage] |
Composite Structure [moderate mods] |
System Analysis, System Design |
|||||||
Usage Notes
BDD Block Definition vs. IBD Block Usage Dichotomy
BDDs and IBDs complement each other (cf. black-box vs. white-box) and support recursive structural decomposition techniques during System Analysis & Design.
- A BDD defines a Block’s Properties, including its Part Properties (strongly owned Parts) and Reference Properties (shared Parts)
- IBD specifies Part Properties and Reference Properties usages or roles in the structural context of the Block that encapsulates them. Stated otherwise, Part Properties and Reference Properties in an IBD can have a different usages or roles depending upon how they are realized ("wired") in the IBD.
- Compare and contrast UML Specification-Realization and Type-Instance dichotomies
| BEST PRACTICE PATTERNS |
ANTI-PATTERNS |
|---|---|
| * Aggressively apply Object Triad Pattern triage techniques to Blocks in order to separate Control Objects, Interface Objects, and Data Objects. | * Conflate Control Object, Interface Object, and Data Object Blocks. |
| * Recursively decompose ("nest") Block hierarchies by alternating between BDD definitions and IBD usages. | * SA/SD DFD Anti-Pattern (a.k.a., "Back to the Future circa 1980" Anti-Pattern) = Define Activity diagrams as Functional Flow diagrams without Parttions that represent Control Objects. |
| * Allocate all Activities to Partitions that represent Control Object Blocks. | * Bloctivity Anti-Pattern = Conflate Block and Activity syntax and semantics. |
TOGAF and ARCHIMATE are trademarks of The Open Group.
ENTERPRISE ARCHITECT is a trademark of Sparx Systems Pty Ltd. MAGICDRAW and CAMEO are trademarks of No Magic, Inc. RATIONAL RHAPSODY is a trademark of IBM.
All other trademarks are the property of their respective owners.
