This SysML Diagram Tutorial is a Systems Modeling Language (SysML) primer that provides an overview of the nine (9) SysML diagram types and complementary Allocation Tables that constitute this de facto architecture modeling language standard for Model-Based Systems Engineering (MBSE) applications.
For a SysML primer that shows how SysML can be pragmatically applied to MBSE applications check out the SysML by Example Tutorial: Griffin Space Vehicle Project.
Please contact us with your constructive ideas to correct and improve this section.
You can't teach people everything they need to know. The best you can do is position them where they can find what they need to know when they need to know it. Seymour Papert
The SysML is composed of nine (9) diagram types and Allocation Tables for mapping language elements across diagram types:
The SysML Diagram Taxonomy comparison table below explains the similaries and differences among the various SysML diagram types.
The SysML is composed of nine (9) diagram types and Allocation Tables for mapping language elements across diagram types:
Diagram Name | Diagram Type | UML 2 Analog | SDLC Usage | Essential AGILE SYSML? |
Dynamic Sim † |
Math Sim ‡ |
Auto Code Gen |
Rigor | Semi | Informal |
---|---|---|---|---|---|---|---|---|---|---|
Requirement diagram (req) | Static Structure [Declarative] |
N/A | Requirements Analysis | |||||||
Use Case diagram (uc) | Behavior * [Non-Simulatable] |
Use Case | Requirements Analysis | |||||||
Activity diagram (act) | Dynamic Behavior [Simulatable] |
Activity [minor mods] |
System Analysis, Functional Analysis, System Design |
|||||||
Sequence diagram (sd) | Dynamic Behavior [Simulatable] |
Sequence | System Design | |||||||
State Machine diagram (stm) | Dynamic Behavior [Simulatable] |
State Machine | System Analysis, System Design |
|||||||
Block Definition Diagram (bdd) | Static Structure [Black Box Definition] |
Class [moderate mods] |
System Analysis, System Design |
|||||||
Internal Block Diagram (ibd) | Static Structure [White Box Usage] |
Composite Structure [moderate mods] |
System Analysis, System Design |
|||||||
Parametric Diagram (par) | Static Structure [White Box Usage] |
N/A | System Analysis, System Design |
|||||||
Package diagram (pkg) | Static Structure [Grouping] |
Package [minor mods] |
All SDLC phases | |||||||
Allocation Table | N/A [Relationship Matrix] |
N/A | All SDLC phases |
†: Dynamic Simulation (a.k.a. Dynamic System Simulation) refers to the capability of a computer program to execute the time-varying behavior of a system of interest. In general, with the exception of Use Case diagrams, SysML and UML 2 Behavior diagrams are potentially capable of Dynamic System Simulation.
‡: Mathematical Modeling & Simulation (a.k.a. Mathematical ModSim, Mathematical M&S, Parametric Simulation) refers to the capability of a computer program to execute the a mathematical model of the behavior of a system of interest, where the model is defined as a set of mathematical equations. When properly defined and applied Parametric diagrams are capable of Mathematical ModSim; no other SysML or UML 2 diagrams are capable of this.
*: Although Use Case diagrams are generally classified as Behavior diagrams by both the OMG SysML and UML 2 specifications their Behavioral semantics are ambiguous and incomplete. Whereas Activity, Sequence and State Machine diagrams are Turing Complete, and their dynamic behavior can be simulated or executed, Use Cases diagrams are not Turing Complete and are not simulatable.
The SysML is composed of nine (9) diagram types and Allocation Tables for mapping language elements across diagram types:
Diagram Name | Diagram Type | UML 2 Analog | SDLC Usage | Essential AGILE SYSML? |
Dynamic Sim † |
Math Sim ‡ |
Auto Code Gen |
Rigor | Semi | Informal |
---|---|---|---|---|---|---|---|---|---|---|
Requirement diagram (req) | Static Structure [Declarative] |
N/A | Requirements Analysis | |||||||
Use Case diagram (uc) | Behavior * [Non-Simulatable] |
Use Case | Requirements Analysis | |||||||
Activity diagram (act) | Dynamic Behavior [Simulatable] |
Activity [minor mods] |
System Analysis, Functional Analysis, System Design |
|||||||
Sequence diagram (sd) | Dynamic Behavior [Simulatable] |
Sequence | System Design | |||||||
State Machine diagram (stm) | Dynamic Behavior [Simulatable] |
State Machine | System Analysis, System Design |
|||||||
Block Definition Diagram (bdd) | Static Structure [Black Box Definition] |
Class [moderate mods] |
System Analysis, System Design |
|||||||
Internal Block Diagram (ibd) | Static Structure [White Box Usage] |
Composite Structure [moderate mods] |
System Analysis, System Design |
|||||||
Parametric Diagram (par) | Static Structure [White Box Usage] |
N/A | System Analysis, System Design |
|||||||
Package diagram (pkg) | Static Structure [Grouping] |
Package [minor mods] |
All SDLC phases | |||||||
Allocation Table | N/A [Relationship Matrix] |
N/A | All SDLC phases |
†: Dynamic Simulation (a.k.a. Dynamic System Simulation) refers to the capability of a computer program to execute the time-varying behavior of a system of interest. In general, with the exception of Use Case diagrams, SysML and UML 2 Behavior diagrams are potentially capable of Dynamic System Simulation.
‡: Mathematical Modeling & Simulation (a.k.a. Mathematical ModSim, Mathematical M&S, Parametric Simulation) refers to the capability of a computer program to execute the a mathematical model of the behavior of a system of interest, where the model is defined as a set of mathematical equations. When properly defined and applied Parametric diagrams are capable of Mathematical ModSim; no other SysML or UML 2 diagrams are capable of this.
*: Although Use Case diagrams are generally classified as Behavior diagrams by both the OMG SysML and UML 2 specifications their Behavioral semantics are ambiguous and incomplete. Whereas Activity, Sequence and State Machine diagrams are Turing Complete, and their dynamic behavior can be simulated or executed, Use Cases diagrams are not Turing Complete and are not simulatable.
Requirement: A Requirement (notation: rectangle with «requirement» keyword) is a capability or condition that a system must ("shall") satisfy. A Functional Requirement (functionalRequirement» keyword) specifies a function that a system must perform, whereas a Non-Functional Requirement (NFR) specifies quality criteria that can be used to test the effectiveness of system functions.
SysML predefines the following stereotype specializations of NFRs:
Requirement diagram (req): A SysML Requirement diagram is a static structural diagram that shows the relationships among Requirement («requirement») constructs, model elements that Satisfy («satisfy» Dependency) them, and Test Cases that Verify («verify» Dependency) them.
The purpose of Requirement diagrams is to specify both Functional and Non-Functional Requirements within the model so that they can be traced to other model elements that Satisfy them and Test Cases that Verify them.
Diagram Name | Diagram Type | UML 2 Analog | SDLC Usage | Essential AGILE SYSML? |
Dynamic Sim † |
Math Sim ‡ |
Auto Code Gen |
Rigor | Semi | Informal |
---|---|---|---|---|---|---|---|---|---|---|
Requirement diagram (req) | Static Structure [Declarative] |
N/A | Requirements Analysis |
BEST PRACTICE PATTERNS | ANTI-PATTERNS |
---|---|
* Aggressively apply Requirements Triage techniques to separate «functionalRequirement», «performanceRequirement», and «designConstraint» Requirements. | * Conflate «functionalRequirement», «performanceRequirement», and «designConstraint» Requirements. |
* Satisfy all Functional Requirements with Functional Activities using the «satisfy» Dependency. | * Regurgitate System Design decisions as SysML Requirements text. Compare and contrast bona fide «designConstraint» Requirements (e.g., "... shall use FOSS SW and COTS HW ..."). |
* Apply MBSE + SysML Requirements Cluster Pattern to manage FR-NFR complexity. | |
* Apply MBSE + SysML Requirements Transitive Trace Pattern to scale system Requirements traceability on the "Left-Hand-Side" of the System V-Model. |
Use Case: A Use Case (notation: oval/ellipse) represents a system transaction with an external system user, called an Actor (notation: stick-figure). Use Cases are sometimes considered high-level functional requirements.
Use Case diagram (uc): A Use Case diagram shows communications among system transactions (Use Cases) and external users (Actors) in the context of a system boundary (Subject; notation: rectangle). Actors may represent wetware (persons, organizations, facilities), software systems, or hardware systems. Defining relationships between the system Subject and the system Actors is an effective informal way to define system scope.
The purpose of Use Case diagrams is to provide a high-level view of the subject system and convey the top-level system requirements in non-technical terms for all stakeholders, including customers and project managers as well as architects and engineers. Additional more rigorous SysML diagrams are needed to specify a scalable and simulatable System Architecture Model (SAM).
Diagram Name | Diagram Type | UML 2 Analog | SDLC Usage | Essential AGILE SYSML? |
Dynamic Sim † |
Math Sim ‡ |
Auto Code Gen |
Rigor | Semi | Informal |
---|---|---|---|---|---|---|---|---|---|---|
Use Case diagram (uc) | Behavior * [Non-Simulatable] |
Use Case | Requirements Analysis |
If Use Cases are considered to be high-level system functional requirements they should be traced to «functionalRequirement» Requirements using Refine («refine») Dependencies.
BEST PRACTICE PATTERNS | ANTI-PATTERNS |
---|---|
* Restrict use for brainstorming, ConOps, "Cartoons for Executives & General s", etc. | * Examples of Use Case Modeling Antipatterns [M. El-Attar] |
* Cut-over to high-level Activity diagrams ASAP! |
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.
Block Definition Diagram (bdd): A Block Definition Diagram is a static structural diagram that shows system components, their contents (Properties, Behaviors, Constraints), Interfaces, and relationships.
The purpose of Block Definition Diagrams is to specify system static structures that be used for Control Objects, Data Objects, and Interface Objects. When properly applied (See Usage Notes below) Block diagrams are recursively scalable and mathematically (parametrically) simulatable (See Executable Semantics below.)
Diagram Name | Diagram Type | UML 2 Analog | SDLC Usage | Essential AGILE SYSML? |
Dynamic Sim † |
Math Sim ‡ |
Auto Code Gen |
Rigor | Semi | Informal |
---|---|---|---|---|---|---|---|---|---|---|
Block Definition Diagram (bdd) | Static Structure [Black Box Definition] |
Class [moderate mods] |
System Analysis, System Design |
BDDs and IBDs complement each other (cf. black-box vs. white-box) and support recursive structural decomposition techniques during System Analysis & Design.
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 Conrol Object Blocsk. | * Bloctivity Anti-Pattern = Conflate Block and Activity syntax and semantics. |
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.
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.
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 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 |
BDDs and IBDs complement each other (cf. black-box vs. white-box) and support recursive structural decomposition techniques during System Analysis & Design.
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 Conrol Object Blocsk. | * Bloctivity Anti-Pattern = Conflate Block and Activity syntax and semantics. |
Constraint Block: A Constraint Block (notation: rectangle with keyword = «constraint») defines a mathematical rule (Constraint) and rule Parameters, where the latter are bound to Block Value Properties so that changes to one Block Value Property will be propagated to other Block Value Properties in a manner consistent with the mathematical rule. (See Executable Semantics below.)
Parametric diagram (par): An Parametric diagram is a specialization of an Internal Block Diagram (IBD) that enforces mathematical rules (Constraints) defined by Constraint Blocks across the internal Part Value Properties bound by the Constraint Block Parameters.
The purpose of Parametric diagrams (PARs) is to enforce mathematical rules across Block Value Properties. When used correctly BDDs + IBDs + PARs are recursively scalable and mathematically simulatable. (See Executable Semantics below.)
Diagram Name | Diagram Type | UML 2 Analog | SDLC Usage | Essential AGILE SYSML? |
Dynamic Sim † |
Math Sim ‡ |
Auto Code Gen |
Rigor | Semi | Informal |
---|---|---|---|---|---|---|---|---|---|---|
Parametric Diagram (par) | Static Structure [White Box Usage] |
N/A | System Analysis, System Design |
Compare and contrast: BDD Block Definition vs. IBD Block Usage dichotomy; UML Specification-Realization and Type-Instance dichotomies
BEST PRACTICE PATTERNS |
ANTI-PATTERNS |
---|---|
* Apply Constraint Blocks and PAR diagrams to System Designs after the BDD-IBD system architecture skeletons have stabilized. | * Applying Constraint Blocks and PAR diagrams in isolation (i.e., not integrated with BDD-IBD system architecture skeletons. |
Activity: An Activity (notation: rounded-rectangle or "roundangle") represents a flow of functional behaviors that may include optional Object (data) Flows. Control and Object Flows can be sequential (default) or parallel (indicated by Fork & Join Nodes) depending upon conditions.
Activity diagram (act): An Activity diagram shows system dynamic behavior using a combined Control Flow and Object (data) Flow model.
The purpose of Activity diagrams is to specify dynamic system behaviors that Satisfy («satisfy» Dependency) system Functional Requirements using both Control and Object (data) Flows. When properly applied (See Usage Notes below) Activity diagrams are recursively scalable and simulatable.
Diagram Name | Diagram Type | UML 2 Analog | SDLC Usage | Essential AGILE SYSML? |
Dynamic Sim † |
Math Sim ‡ |
Auto Code Gen |
Rigor | Semi | Informal |
---|---|---|---|---|---|---|---|---|---|---|
Activity diagram (act) | Dynamic Behavior [Simulatable] |
Activity [minor mods] |
System Analysis, Functional Analysis, System Design |
BEST PRACTICE PATTERNS | ANTI-PATTERNS |
---|---|
* Recursively decompose ("nest") Activities by alternating between Activity definitions and Call Behavior usages. | * Bloctivity Anti-Pattern = Conflate Block and Activity syntax and semantics. |
* Allocate all Activities and Actions to a Partition that represents a Control Block. | * SMactivity Anti-Pattern = Conflate State Machine and Activity syntax and semantics. |
* Allocate Data Blocks or Signals to all Activity Parameters and Action Pins. | |
* Ensure that all Activities Satisfy at least one Functional Requirement. |
Message: A Message (notation: arrow) represents communication from one object to another, with the expectation that a useful behavior will ensue. Messages may be synchronous (notation: open arrowhead) or asynchronous (notation: black-triangle arrowhead).
Sequence diagram (sd): A Sequence diagram is a dynamic behavioral diagram that shows interactions (collaborations) among distributed objects or services via sequences of messages exchanged, along with corresponding (optional) events.
The purpose of Sequence diagrams is to specify dynamic system behaviors as message-passing collaborations among prototypical Blocks (Parts). When properly applied (See Usage Notes below) Activity diagrams are recursively scalable and simulatable.
Diagram Name | Diagram Type | UML 2 Analog | SDLC Usage | Essential AGILE SYSML? |
Dynamic Sim † |
Math Sim ‡ |
Auto Code Gen |
Rigor | Semi | Informal |
---|---|---|---|---|---|---|---|---|---|---|
Sequence diagram (seq) | Dynamic Behavior [Simulatable] |
Sequence | System Design |
BEST PRACTICE PATTERNS | ANTI-PATTERNS |
---|---|
* Recursively decompose ("nest") Sequence diagrams by using Combined Fragement References (denoted by ref label). | * Define Messages as strings instead of reusing Block and Interface Operations and Signals. |
State: A State (notation: rounded-rectangle a.k.a. "roundangle") represents a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.
State Machine diagram (smd): An State Machine diagram is a dynamic behavioral diagram that shows the sequences of States that an object or an interaction go through during its lifetime in response to Events (a.k.a. "Triggers"), which may result in side-effects (Actions.
The purpose of State Machine diagrams is to specify dynamic system behaviors for time-critical, mission-critical, safety-critical, or financially-critical objects. When properly applied (See Usage Notes below) State Machine diagrams are recursively scalable and simulatable.
Diagram Name | Diagram Type | UML 2 Analog | SDLC Usage | Essential AGILE SYSML? |
Dynamic Sim † |
Math Sim ‡ |
Auto Code Gen |
Rigor | Semi | Informal |
---|---|---|---|---|---|---|---|---|---|---|
State Machine diagram (stm) | Dynamic Behavior [Simulatable] |
State Machine | System Analysis, System Design |
BEST PRACTICE PATTERNS |
ANTI-PATTERNS |
---|---|
* Use Activity and Sequence diagrams to specify collaborative dynamic behaviors; use State Machines selectively for time/safety/mission/financial critical objects. | * SMactivity Anti-Pattern = Conflate State Machine and Activity syntax and semantics. |
Definitions:
Allocation: An Allocation Dependency arrow (dashed-line with open-arrow notation and keyword = «allocate») associates or maps model elements of different types, or in different hierarchies. Allocate Dependency patterns are generally useful for improving model architecture integrity (a.k.a., well-formedness) and consistency. SysML predefines the following Allocation Dependencies:
Users are encourage to define their own Allocation Dependencies as needed. (See Best Practice Patterns below for examples of user-defined Allocations.)
Allocation Table: An Allocation Table is a tabular (matrix) notation for Allocation relationships, but the SysML standard does not prescribe a particular format for these so they tend to be vendor specific.
The purpose of an Allocation Table is to define relationship matrices within and across diagram types to improve model architectural integrity (well-formedness) and consistency.
Diagram Name | Diagram Type | UML 2 Analog | SDLC Usage | Essential AGILE SYSML? |
Dynamic Sim † |
Math Sim ‡ |
Auto Code Gen |
Rigor | Semi | Informal |
---|---|---|---|---|---|---|---|---|---|---|
Allocation Table | N/A [Relationship Matrix] |
N/A | All SDLC phases |
BEST PRACTICE PATTERNS | ANTI-PATTERNS |
---|---|
* Use Allocation Tables to define system architecture integrity (well-formedness rules) for System Analysis and System Design. | * Rely on the anemic subset of Allcoation Tables defined by the OMG SysML specification and SysML tool vendors. |
* Use Allocation Tables to define system Verification & Validation (V&V) relationships on both sides of the System V-Model. |