SysML FAQ: What is SysML? Who created 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.

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

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.

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

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

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.

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.

What is a SysML Package diagram?

Definitions

Package: A Package (notation: "folder" icon) is a general-purpose mechanism for organizing model elements and diagrams into groups. Packages define unique namespaces for model elements defined within their scope.

• namespace = a declarative region that provides scope for the identifiers contained within

Package diagram (pkg): A Package diagram is a static structural diagram that shows the relationships among packages and their contents. Package can be stereotyped (customized) for organizing model elements into models, views, model libraries, and frameworks.

Purpose

The purpose of Package diagram is to support the organization and management of large, complex System Architecture Models (SAMs).

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.