SysML Diagram Tutorial

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


What are the SysML diagram types?

Question Variant(s): How do the SysML diagrams compare and contrast?; What are SysML Allocation Tables and what are they used for?

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.

SysML Diagram Taxonomy

The SysML is composed of nine (9) diagram types and Allocation Tables for mapping language elements across diagram types:

DIAGRAM PROPERTIES
EXECUTABLE SEMANTICS
FORMAL SEMANTICS
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.

SysML Diagram Properties Table
SysML Diagram Taxonomy

The SysML is composed of nine (9) diagram types and Allocation Tables for mapping language elements across diagram types:

DIAGRAM PROPERTIES
EXECUTABLE SEMANTICS
FORMAL SEMANTICS
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.



Architecture Modeling Language Evolution
Architecture Modeling Language Evolution: UML 2 & SysML

What is a SysML Requirement diagram?

Definitions

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:

  • «performanceRequirement»
  • «interfaceRequirement»
  • «designConstraint»
  • «physicalRequirement»

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.

Purpose

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.


SysML Requirement Diagram Example
SysML Requirement Diagram:
Top-Level Requirements

SysML Requirement Diagram Example
SysML Requirement Diagram:
Requirements Cluster Pattern

Diagram Properties
DIAGRAM PROPERTIES
EXECUTABLE SEMANTICS
FORMAL SEMANTICS
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
Usage Notes
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.

What is a SysML Use Case diagram?

Definitions

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.

Purpose

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).


SysML Use Case Diagram: Top-Level UCs
SysML Use Case Diagram:
Top-Level Use Cases

SysML Use Case Diagram: UC Decomposition
SysML Use Case Diagram:
Use Case Decomposition

Diagram Properties
DIAGRAM PROPERTIES
EXECUTABLE SEMANTICS
FORMAL SEMANTICS
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
Usage Notes

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!

What is a SysML Block Definition 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.)

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.

  • 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 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.)


SysML Block Definition: Interfaces
SysML Block Definition Diagram (BDD):
System Interfaces
SysML Block Definition: Components
SysML Block Definition Diagram (BDD):
System Components

Diagram Properties
DIAGRAM PROPERTIES
EXECUTABLE SEMANTICS
FORMAL SEMANTICS
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
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 Conrol Object Blocsk. * Bloctivity Anti-Pattern = Conflate Block and Activity syntax and semantics.

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 PROPERTIES
EXECUTABLE SEMANTICS
FORMAL SEMANTICS
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 Conrol Object Blocsk. * Bloctivity Anti-Pattern = Conflate Block and Activity syntax and semantics.

What is a SysML Parametric Diagram?

Definitions

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.

  • Binding Connectors (keyword = «equal») between Constraint Block Parameters and internal Part Value Properties effect constraint satisfaction (propagation)
Purpose

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.)


SysML BDD: Constraint Block Definition

SysML Parametric Diagram Example
SysML Parametric Diagram (PAR):
Constraint Block Usage

Diagram Properties
DIAGRAM PROPERTIES
EXECUTABLE SEMANTICS
FORMAL SEMANTICS
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
Usage Notes
BDD Constraint Block Definition vs. PAR Constraint Block Usage Dichotomy
  • A BDD defines a Constraint Block’s mathematical rule (Constraint) and the rule's Parameters
  • a PAR specifies the Binding Connector usages among Constraint Block Parameters and the Part Value Properties that are restricted by them.

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.

What is a SysML Activity diagram?

Definitions

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.

  • Action = atomic Activity, which is a primitive executable behavior.
  • Control Flow = flow of functional behaviors
  • Object Flow = data flow of object inputs/outputs into/from an Activity or Action.

Activity diagram (act): An Activity diagram shows system dynamic behavior using a combined Control Flow and Object (data) Flow model.

  • Activities (and indirectly Activity diagrams) can be recursively decomposed ("nested") by alternating between Activity definitions and Call Behavior Action usages (See Usage Notes below.)
  • Activities and Actions can be Allocated (via to Partitions that represent Control Blocks (i.e., Blocks that represent the System, Subsystems, Sub-Subsystems, ..., atomic structures);
  • Data Blocks (i.e., Blocks that represent Persistent Data Stores) and Signals that contain Data Blocks can be Allocated to Activity Parameters and Action Pins;
  • compare and contrast: SA/SD DFDs, FFBDs, EFFBDs,IDEF0; BPMN BPDs.
Purpose

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 Properties
DIAGRAM PROPERTIES
EXECUTABLE SEMANTICS
FORMAL SEMANTICS
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
Usage Notes
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.

What is a SysML Sequence diagram?

Definitions

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.

  • collaborating objects or services are Parts depicted as Lifelines (notation: rectangle with a dashed vertical line below)
  • Combined Fragment operators support recursive nesting and Turing Complete semantics (Alternative [alt], Optional [opt], Parallel [par], Loop [loop], etc.)
  • compare and contrast: Message Sequence Charts (MSCs).
Purpose

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.


SysML Sequence Diagram Example
SysML Sequence Diagram:
Top-Level Sequence

SysML Sequence Diagram Example
SysML Sequence Diagram:
Reference Decomposition

Diagram Properties
DIAGRAM PROPERTIES
EXECUTABLE SEMANTICS
FORMAL SEMANTICS
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
Usage Notes
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.

What is a SysML State Machine diagram?

Definitions

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.

Purpose

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.


SysML State Machine Diagram Example
SysML State Machine Diagram:
Top-Level State Machine

SysML State Machine Diagram Example
SysML State Machine Diagram:
Submachine State

Diagram Properties
DIAGRAM PROPERTIES
EXECUTABLE SEMANTICS
FORMAL SEMANTICS
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
Usage Notes
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.

What is a SysML Allocation Table?

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:

  • allocations for Requirement dependencies
  • allocations for Activities to Partitions (swimlanes)

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.

Purpose

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.

SysML Allocation Table Example
SysML Allocation Table Example


Diagram Properties
DIAGRAM PROPERTIES
EXECUTABLE SEMANTICS
FORMAL SEMANTICS
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
Usage Notes
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.


UML, BPMN, OMG SYSML and UPDM are trademarks of the Object Management Group.
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.
© 2003-2024 PivotPoint Technology Corp. | Privacy | Contact Us