SysML FAQ: What is SysML?, What is MBSE?, Who created SysML?

This section features Frequently Asked Questions (FAQs) about the Systems Modeling Language (SysML) and related Model-Based Systems Engineering (MBSE) technologies.

Please contact us with your constructive ideas to correct and improve this section.

Agile MBSE™ + SysML Expert
Training & Certification...

SysML Diagram Taxonomy for Agile MBSE™

General Questions

What is SysML?

What is the Systems Modeling Language (SysML)?

Question Variant(s): What is SysML?; What is OMG SysML?

Definition

Systems Modeling Language (SysML): SysML is a general-purpose architecture modeling language for Systems Engineering applications.

SysML supports the specification, analysis, design, verification, and validation of a broad range of systems and systems-of-systems. These systems may include hardware, software, information, processes, personnel, and facilities.
SysML is a dialect of UML 2, and is defined as a UML 2 Profile. (A UML Profile is a UML dialect that customizes the language via three mechanisms: Stereotypes, Tagged Values, and Constraints.)
SysML is an enabling technology for Model-Based Systems Engineering (MBSE).

The SysML was originally created by the SysML Partners' SysML Open Source Specification Project in 2003. The SysML was adapted and adopted by the Object Management Group (OMG) as OMG SysML in 2006. For more information about the current version of OMG SysML, see the SysML FAQ: What is the current version of SysML?.

SysML Diagram Taxonomy for Agile MBSE™

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.

Agile MBSE™ + SysML Expert
Training & Certification...

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

Why use SysML? (What is SysML used for?)

If you are a Systems Engineer and want to improve the precision and efficiency of your communications with fellow Systems Engineers and other system and business stakeholders (e.g., Clients, Software Engineers, Electrical Engineers, Mechanical Engineers), then you should consider using a system architecture modeling language standard as a lingua franca (common language).

The Systems Modeling Language (SysML) has emerged as the de facto standard system architecture modeling language for Model-Based Systems Engineering (MBSE) applications. SysML is a dialect of UML 2, which extends the Unified Modeling Language (UML) standard for software-intensive applications so that it can be successfully applied to Systems Engineering applications.

SysML Diagram Taxonomy for Agile MBSE™

Here's a list of reasons why Systems Engineers may want to use SysML and a Model-Based Systems Engineering approach for their mission critical work:
• Facilitate communication among various stakeholders across the System Development Life Cycle (SDLC), including both sides of System V-Model;
• Capture and manage corporate Intellectual Property related to system architectures, analyses, designs, and processes;
• Facilitate Trade Studies and compare and contrast “As Is” and “To Be” solutions;
• Provide scalable structure for problem solving;
• Furnish rich abstractions to manage size and complexity;
• Explore multiple solutions or ideas concurrently with minimal risk; and
• Detect errors and omissions early in System Development Life Cycle (SDLC)

Of course, like any technology, SysML can be both properly applied and abused. Compare and contrast the difference between "SysML-as-Pretty-Pictures" and "SysML-as-System-Architecture-Blueprint" usage modes in the SysML FAQ: How should SysML be applied to an MBSE project? How is SysML commonly abused?.

Who created SysML?

The Systems Modeling Language (SysML) was created by the SysML Partners, an informal association of Systems Engineering experts and software modeling tool experts that was organized by Cris Kobryn in 2003 to create a profile (dialect) of the Unified Modeling Language (UML) that could be used for Systems Engineering applications.

Since Kobryn had previously successfully led the UML 1.x and UML 2.0 language design teams, David Oliver and Sanford Friedenthal of INCOSE asked Kobryn to lead their joint effort to respond to the Object Management Group's UML for Systems Engineering RFP issued in March 2003. As Chair of the SysML Partners, Kobryn coined the language name "SysML" (short for "Systems Modeling Language"), designed the original SysML logo, and organized the SysML core language design team as an open source specification project.

For further details about the history of the SysML, see the SysML Partners page on the SysML.org web.

What is Model-Based Systems Engineering (MBSE)?

Model-Based Systems Engineering (MBSE), a.k.a. Model-Based Systems Development (MBSD), is a Systems Engineering process paradigm that emphasizes the application of rigorous architecture modeling principles and best practices to Systems Engineering activities throughout the System Development Life Cycle (SDLC). These Systems Engineering activities include, but are not limited to, requirements analysis, functional analysis, performance analysis, system design, trade studies, system architecture specification, and system Verification & Validation (V&V).

Agile MBSE™ System-of-Systems Architecture Tetrad

Model-Based Systems Engineering principles and best practices continue to evolve. The following are some additional desirable characteristics of MBSE approaches:

• emphasize a precise and complete System Architecture Model "blueprint", typically organized using an Architecture Framework with multiple Views/Viewpoints, as the primary work artifact throughout the System Development Life Cycle (SDLC);
• promote the use of open standards for architectural modeling and tool interoperability (e.g., SysML, UML 2, XMI, AP233), where these open standards are used to specify the System Architecture Model and to serve as a lingua franca among Systems Engineers and other stakeholders (Software Engineers, Electrical Engineers, Mechanical Engineers, Customers, etc.);
• ensure that the System Architecture Model is requirements-driven to the extent that all model elements must be fully traceable to system and user requirements;
• ensure that the System Architecture Model is architecture-centric to the extent that all model elements must maintain structural and functional integrity relationships, and support full derivation traceablity across all system stakeholder Views and Viewpoints;
• combine traditional Systems Engineering best practices with architecture modeling best practices.

The term Model-Based Systems Engineering and its acronym MBSE are popular among Systems Engineers who advocate the use of SysML as a standard architecture modeling language for Systems Engineering applications, and who want to distinguish their approach from Model-Driven Development and its variants, which tend to be software-centric.

For more information about Model-Based Systems Engineering, check out the MBSEworks.com web.

What is Agile MBSE™?

What is Agile MBSE™ (Agile Model-Based Systems Engineering™)?

FAQ Variant(s): What is Agile Systems Engineering?

Agile MBSE™ = a hybrid Systems Engineering process that combines the strengths, and avoids the weaknesses, of "heavyweight" (a.k.a. "high ceremony", or "obese") Model-Based Systems Engineering (MBSE) processes and "lighweight" (a.k.a., "low ceremony" or "anorexic") Agile processes (e.g., Agile Software Development, Agile Engineering). The resultant "middleweight" Agile MBSE process is inherently more resilient (i.e., robust yet flexible) than either of its constituent processes, and consequently supports highly scaleable and simulatable system architectures.

As you might expect, a bona fide Agile MBSE Process requires a bona fide Agile SysML architecture modeling language to specify both MBSE work artifacts (e.g., System-of-System Architecture Model (SAM), Interface Control Docs) as well as itself (i.e., be self-descriptive). Towards that end PivotPoint has defined AgileML™ (Agile Modeling Language™), a "Lean" (as in Lean manufacturing and methods) subset of the OMG UML2/SysMLarchitecture modeling language standards that is extended for specifying scalable and simulatable Abile MBSE work artifacts.

gile MBSE™ 6D Enterprise Architecture Framework™

Agile MBSE™: 6D System M-Model

SysML Diagram Taxonomy for Agile MBSE™

Agile MBSE™ Process Features

It is essential that an Agile MBSE Process approach strives to meet or exceed the following goals:

Architecture-Centric Agile MBSE Process Features

Architecture-centric: The Agile MBSE process must emphasize a precise and complete System-of-Systems Architecture Model (SSADM) as the primary work artifact throughout the System Development Life Cycle (SDLC). i.e., SAM = system architecture "truth" (cf. Agile Manifesto). The SSADM should be organized using an scalable and simulatable Architecture Framework (e.g., ISO/IEC 42010, DoDAF, TOGAF) pattern with multiple Views/Viewpoints;
Support full SDLC with rigorous V&V: The Agile MBSE process must provide comprehensive support of all SDLC phases (Requirements, System Analysis, System Design, Implementation, System Integration &Testing);
Requirements-driven: All System Analysis, System Design, and Implementation elements on the "Left Side" of the System V-Model must directly or indirectly trace to System Functional and Non-Functional Requirements;
Test-driven: All System Test Cases on the "Right Side" of the System V-Model must exhaustively test the System Design and Implementation using "black-box" and "white-box" Test Cases at the Unit, Integration, and System levels;
Scalable: The Agile MBSE Process must scale recursively to accommodate Systems-of-Systems of arbitrary complexity;
Simulatable: The Agile MBSE process must be capable must be capable of Dynamic Simulation (a.k.a. Dynamic System Simulation) of all SysML Behavior diagrams (Activities, Sequences, State Machines) and Mathematical Modeling & Simulation (a.k.a. Mathematical ModSim, Mathematical M&S, Parametric Simulation) of all Parametric diagrams;
Pattern-based for reuse: The Agile MBSE process be based on proven pragmatic System Analysis, Design and Architecture patterns to improve architecture integrity and consitency, and promote reuse within and across enterprise models;
Integrate SE & Agile MBSE best practices: The Agile MBSE process must be capable of enhancing proven traditional Systems Engineering best practices and integrating them with evolving Agile MBSE best practices.

Agile MBSE Process Features

Quick, Regular Process Cadence: Short iterative, incremental Agile "Sprints" allow System-of-Systems Architecture & Design work artifacts to adapt to changing business and mission Requirements;
Proactive Testing: Test Cases are continuously refined to identify problems early in SDLC, especially Test Cases for Software Components;
Frequent Peer-to-Peer Reviews: Frequent personal interactions and informal peer-to-peer reviews streamline communications and reduce misunderstandings.

In addition, it is desirable that an Agile MBSE Process achieves the following goals:

Straightforward & systematic: The Agile MBSE process should be explained in a straightforward and systematic manner, so that it is easy for Systems Engineers to learn and apply;
Promote the use of open standards: The Agile MBSE process should support open standards for system architecture modeling and tool interoperability. These open standards include, but are not limited to SysML, UML 2, XMI, and AP233. These open standards should be used to specify the System-of-Systems Architecture & Design Model (SSADM) and to serve as a lingua franca among Systems Engineers and other stakeholders (Software Engineers, Electrical Engineers, Mechanical Engineers, Customers, etc.).

How should SysML be applied to an MBSE project? How is SysML commonly abused?

As SysML emerges as the de facto standard for Model-Based Systems Engineering (MBSE) approaches, several SysML usage modes of progressive rigor have become evident:
• LEAST RIGOROUS & MOST COMMON USAGE MODE —SysML-as-Pretty-Pictures: This is the least formal and least rigorous SysML usage mode. Unfortunately, it is also the most common way that SysML is abused. In SysML-as-Pretty-Pictures usage mode, SysML notation is used in lieu of ad hoc modeling notation (e.g., Visio or PowerPoint drawings), but relatively little attention is paid to SysML wellformedness and its underlying simulatable and executable semantics. Consequently, the SysML models generated in SysML-as-Pretty-Pictures mode are rarely capable of driving dynamic simulations or precisely specifying system architecture blueprints.
• SysML-as-Model-Simulation: This SysML usage mode is a significant improvement over SysML-as-Pretty-Pictures mode, since it emphasizes the simulation of system dynamic behavior and system parametric constraints. In SysML-as-System-Simulation mode, at least some of SysML behavioral diagrams (Activity, Sequence, State Machine diagrams) are exercised by a behavioral simulation engine. In addition, some of the Parametric diagram constraints may also be exercised by a constraint propagation engine (MATLAB/Simulink, OpenModelica, SysML tool proprietary plugin, etc.). This is an intermediate SysML usage mode for those who seek to escape from SysML-as-Pretty-Pictures language abuse.
• SysML-as-System-Architecture-Blueprint: This SysML usage mode is a substantive improvement over SysML-as-Model-Simulation mode, since it extends the latter to include the precise and complete specification of a System Architecture Model (SAM). The purpose of the SAM is to be sufficiently precise and complete to serve as the "system architecture truth" for all engineering processes involved in the system project, including systems engineers (SEs), software engineers (SWEs), electrical engineers (EEs), mechanical engineers (MEs), etc. In order for the SAM to serve as system architecture truth for a systems engineering project, the SAM must satisfy all Five C's of system architecture quality (Correct, Complete, Clear, Concise, and Consistent). This is a relatively advanced SysML usage mode, and is often a natural evolution of the SysML-as-System-Simulation mode.
• MOST RIGOROUS & RAREST SYSML USAGE MODE — SysML-as-Executable-System-Architecture: This SysML usage mode is a quantum improvement over the SysML-as-System-Architecture-Blueprint mode, since it extends the latter mode to make majority of SAM behavioral and parametric specifications simulatable and potentially executable. Executable in a MBSE context generally refers to the partial or fully automated generation of system interfaces, or system test cases.

What is the relationship between SysML and UML?

Short Answer:
Contrary to MBSE and tool-vendor Muddle-Driven Marketecture hype, the differences between the SysML and UML modeling languages are more lightweight and dialectical in nature than heavyweight and substantive. This should be expected since SysML was originally designed to be used by Systems Engineers collaborating with Software Engineers applying UML for software analysis and design, and SysML is defined as a modestly extended pragmatic subset of UML 2. (See SysML FAQ: Can SysML and UML model elements be combined in the same model? Indeed, although SysML adds two useful diagram usages to UML (Requirements diagrams extend UML Class diagrams; Parametric diagrams extend UML Class & Composite Structure diagrams), the other diagrams that SysML borrows from UML are either largely reused without modification (e.g., Use Case, Sequence, State Machine diagrams) or are modestly tweaked with lightweight customizations called stereotypes that lack substantive semantics (e.g., renaming Classes as Blocks and adding lightweight syntax and semantics for physical item flows; adding stereotypes to Activity diagrams without bona fide executable semantics).

Longer Answer:
SysML is defined as a lightweight dialect (Profile) of UML 2.x, the industry-standard modeling language for software-intensive applications. (The SysML Profile is lightweight in the sense that the changes that it makes to the underlying language are relatively modest in scope and extent, using a small number of simple stereotypes, tagged values, and constraints. Compare and contrast with a heavyweight Profile, which could significantly impact how the underlying language is used.) The advantage of defining SysML as a UML Profile is that it can reuse the relatively mature notation and semantics of UML 2.x, which many modeling tool vendors have already implemented. The disadvantage of specifying SysML as a UML Profile is that SysML inherits many of the problems associated with UML 2.x, such as gratuitously complex notation, imprecise semantics, and a dysfunctional diagram interoperability standard (XMI).

SysML offers systems engineers the following advantages over UML for specifying systems and systems-of-systems:
• SysML expresses systems engineering semantics (interpretations of notations) better than UML. It reduces UML's software bias and adds two new diagram types for requirements management and performance analysis: Requirement diagrams and Parametric diagrams, respectively.
• SysML is smaller and easier to learn than UML. Since SysML removes many software-centric and gratuitous constructs, the overall language is smaller as measured in diagram types (9 vs. 13) and total constructs.
• SysML model management constructs support the specification of models, views, and viewpoints that are architecturally aligned with IEEE-Std-1471-2000 (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems).

MBSE + SysML Public Training...
• Choose CAMEO or SPARX EA integrated tool training
• Secure Virtual (Online) Classrooms
• Taught by MBSE + SysML Experts w/ 10+ yrs experience

The following SysML-UML 2 Comparison table compares SysML diagrams with their UML counterparts where one exists. Where no UML diagram counterpart exists for a SysML diagram (e.g., Parametric and Requirement diagrams), it is marked N/A; similarly, where no SysML diagram counterpart exists for UML diagram (e.g., UML 2 Communication diagram), it is marked N/A .

SYSML DIAGRAM

PURPOSE

UML DIAGRAM ANALOG

Activity diagram (ACT or act)

[Behavioral diagram] An Activity diagram shows system behavior as control and data flows.
Useful for functional analysis.
Compare Flow Block Diagrams (FBDs) and Extended Functional Flow Block diagrams (EFFBDs), already commonly used among systems engineers.

UML::
Activity diagram

Block Definition diagram (BDD or bdd)

[Structural diagram] A Block Definition diagram shows system structure as components along with their Properties, Operations, and Relationships.
Useful for system analysis and design.

UML::
Class diagram

Internal Block diagram (IBD or ibd)

[Structural diagram] An Internal Block diagram shows the internal structures of system components, including their Parts and Connectors.
Useful for system analysis and design.

UML::
Composite Structure diagram

Package diagram (PKG or pkg)

[Structural diagram] A Package diagram shows how a model is organized into Packages, Views, and Viewpoints.
Useful for model management.

UML::
Package diagram

Parametric diagram (PAR or par)

[Structural diagram] A Package diagram shows parametric constraints between structural elements. Useful for performance and quantitative analysis.

N/A

Requirement diagram (REQ or req)

[Requirement diagram] A Requirement diagram shows system requirements and their relationships with other elements.
Useful for requirements engineering, including requirements verification and validation (V&V).

N/A

Sequence diagram (SD or sd)

[Behavioral diagram] An Sequence diagram shows system behavior as interactions between system components.
Useful for system analysis and design.

UML::
Sequence diagram

State Machine diagram (STM or stm)

[Behavioral diagram] A State Machine diagram shows system behavior as sequences of states that a component or interaction experience in response to events.
Useful for system design and simulation/code generation.

UML::
State Machine diagram

Use Case diagram (UC or uc)

[Behavioral diagram] A Use Case diagram shows system functional requirements as transactions that are meaningful to system users.
Useful for specifying functional requirements. (Note potential semantic overlap with functional Requirements specified in Requirement diagrams.)

UML::
Use Case diagram

Allocation Table

[Mapping table; not a diagram] An Allocation Table shows various kinds of assignment relationships (e.g., requirement allocation, functional allocation, structural allocation) between model elements.
Useful for facilitating automated verification and validation (V&V) and gap analysis.

N/A

Instances (but no Object diagram)

As per the OMG SysML 1.2 minor revision, Instance Specifications, but not Object diagrams are allowed.

UML::
Object diagram

N/A

UML::
Communication diagram

N/A

UML::
Component diagram

N/A

UML::
Deployment diagram

N/A

UML::
Interaction Overview diagram

N/A

UML::
Profile diagram

N/A

UML::
Timing diagram

What is the relationship between SysML and MBSE?

A recommended best practice for any Model-Based Systems Engineering (MBSE) approach is the synergistic application of Model-Based Languages, Model-Based Tools, Model-Based Processes, and Model-Based Architecture Frameworks, as shown in the System Architecture Tetrad figure below. After a decade of pragmatic experience applying SysML to tough Systems Engineering problems, SysML has emerged as the de facto Model-Based Language choice for MBSE projects.

Agile MBSE™ System-of-Systems Architecture Tetrad

Unfortunately, de facto standards for Model-Based Tools, Model-Based Architecture Frameworks, and Model-Based Processes have not yet emerged. Commercial and open-source Model-Based Tools that comply with the SysML language standard are available, but many improvements are needed, as you can see from the tool reviews on the MBSE Tool Reviews web. Model-Based Architecture Frameworks that organize System Architecture models defined with SysML are only required for defense applications, where DoD Architecture Framework (DoDAF) prevails. Model-Based Processes that support large-scale MBSE applications are the least mature quadrant of the System Architecture Tetrad pattern.

Bitter experience has show that MBSE projects that fail to properly balance the four parts of the System Architecture Tetrad tend to achieve poor or mixed results.

What is the relationship between MBSE and other Model-Driven/Model-Based acronym expressions (MDD, MDSE, MDE, MDA, MBE, MBSD)?

Model-Based Systems Engineering (MBSE) is frequently confused with several other acronym expressions that begin with either "Model-Based" or "Model-Driven". The short answer is that Model-Based Systems Engineering is a subdiscipline of the more generic Model-Based Engineering system development paradigm. MBE is a system development paradigm that emphasizes the use of rigorous visual modeling techniques throughout the System Development Life Cycle (SDLC); MBSE is a specialization of MBE that applies MBE principles and best practices to Systems Engineering applications.

For a longer and more thorough explanation of the relationships among Model-Based Systems Engineering, Model-Based Engineering, and related MBE subdisciplines, check out the Model-Based Engineering Forum and the Model-Based Engineering Visual Glossary.

Can SysML and UML model elements be combined in the same model?

Short Theoretical Answer:
In theory, SysML and UML model elements can be synergistically combined in the same model. Indeed, this was one of the language design goals of the SysML Partners' open source specification project:

• Support SysML + UML mixed language usage:
Ensure that SysML constructs can be synergistically combined with UML constructs in a model shared by Systems Engineers and Software Engineers, where the former use SysML and the latter use UML. The synergistic combination of SysML and UML should maximize requirements traceability and minimize semantic overlap between the two languages. “SysML Language Design Goals”, SysML Partners

Longer Practical Answer:
In practice, unfortunately, users frequently find it confusing and problematic to combine SysML and UML model elements in the same model, just as they find it befuddling and vexing to interchange SysML and UML models across supposedly XMI (XML Model Interchange) compliant modeling tools. It appears that the Object Management Group (OMG) is following a "family of languages" visual modeling design philosophy, as opposed to the "unification of languages" design philosophy that dominated UML 1.x adoption and revisions during the late 1990's and early 2000's. This misguided and poorly-executed design philosophy has resulted in a "Tower of Techno-Babble" anti-pattern for users who want to synergistically combine the OMG's most popular visual modeling languages (UML, SysML, BPMN), and it has resulted in a "Meta-Babble" anti-pattern for vendors relying on the gratuitously-complex Meta Object Facility (MOF) and XMI for reliable model interchange.

So, given the "Tower of Techno-Babble" anti-pattern described above, how can a team comprised of both Systems Engineers and Software Engineers specify a model that harmoniously combines SysML and UML model elements? The following outlines a technical approach based on the transitivity of requirements traceability dependencies (notably «satisfy» and «refine»), that has proven effective on numerous large, mixed modeling language projects:

Select a UML modeling tool that correctly implements SysML as a UML2 compliant profile and allows you to populate SysML diagrams with UML constructs and populate UML diagrams with SysML constructs.
UML modeling tools that support SysML vary widely in this regard, with some being more restrictive than others since the OMG specifications generally defer this sort of implementation detail to vendors. Check out SysMLtools.com for candidate SysML modeling tools that support SysML + UML2 mixed language usage.
Organize your model into well-defined Views along the lines of the following, where UML and SysML diagrams are combined in a complementary manner:
(See SysML «view» stereotype of Package for View notation and semantics.) Modelers should feel free to modify the following Views and their contents consistent with their chosen Model-Based Systems Engineering (MBSE) and/or Model-Driven Development (MDD) methods.
- Requirements «view»: Systems Engineers are primarily responsible for the completeness, correctness, and integrity of this View and the definition of its corresponding Viewpoint. Candidate diagram type contents include, but are not limited to, the following: UML/SysML Use Case and SysML Requirement diagrams.
- Requirements «view»: Systems Engineers are primarily responsible for the completeness, correctness, and integrity of this View and the definition of its corresponding Viewpoint. Candidate diagram type contents include, but are not limited to, the following: SysML Block Definition, Internal Block, Parametric, Activity, and State Machine diagrams. Other SysML diagrams may be added as needed.
- System Design «view»: Software Engineers are primarily responsible for the completeness, correctness, and integrity of this View and the definition of its corresponding Viewpoint. Candidate diagram type contents include, but are not limited to, the following: UML Class, Composite Structure, Sequence, Timing, State Machine, Component, and Deployment diagrams.
- ...other Views as needed for Implementation, Testing, etc.
Ensure bi-directional Requirements Traceability on both sides of the System V-Model:
The modeling team should designate and consistently apply appropriate dependencies for full requirements traceability across all Views. You can synergistically effect full traceability across the complementary Views described above by applying the following traceability dependency patterns within and across Views:
- Traceablity within the Requirements «view»: Define Refine («refine») dependencies between functional Requirements and the Use Cases that refine them.
- Traceability between the Requirements «view» & System Analysis «view»: Define Satisfy («satisfy») dependencies between Requirements and the Activities and Blocks that satisfy them. (Optional: As per common UML best practice, you can also define a Realization or Refine dependency between a Use Case and any Activity that realizes or refines it.)
- Traceability between the System Analysis «view» & System Design «view»: Define Refine dependencies between the SysML Blocks and Activities defined in the System Analysis «view» and the UML Classes and Sequences that refine them in the System Design «view».
- Traceability across other Views: Since Refine is a transitive relationship, System Design «view» model elements can be further refined and traced across other Views (e.g., Implementation/Construction, Deployment, Testing, etc.).

Combined SysML + UML2 Example Request: If you are interested in pursuing the technical approach outlined above, but need a combined SysML + UML2 example to better understand how it works, please contact us. If we receive sufficient requests for a combined SysML + UML2 example (say 10+ requests), we will post one to the SysML Forum.

Why do Systems Engineers need "Yet Another Modeling Language" (YAML)?
Why aren't DFDs, FFBDs, EFFBDs, IDEF0/IDEF1, and UML sufficient?

Many Systems Engineering processes still tend to be document-centric and employ a motley mix of diagram techniques that are frequently imprecise and inconsistent. In a manner similar to how Software Engineers sought a general-purpose modeling language (UML) to precisely specify software-intensive systems during the 1990s, many Systems Engineers are now seeking a general-purpose modeling language to specify complex Systems-of-Systems that include non-software components (e.g., hardware, information, processes, personnel, and facilities). UML cannot satisfy this need without modifications because of its software bias; hence the motivation for the SysML dialect of UML.

Even though SysML is based on UML, it reduces UML's size and software bias while extending its semantics to model requirements and parametric constraints. These latter capabilities are essential to support requirements engineering and performance analysis, two essential Systems Engineering activities.

Who maintains the SysML specification and how is it updated?

The Object Management Group (OMG) has adopted and maintains the OMG SysML version of the SysML specification. As with any OMG specification, minor revisions to OMG SysML are effected by Revision Task Forces (RTFs), and major revisions are effected by Requests for Proposals (RFPs). For more details regarding the OMG revision processes, see the the OMG web.

What is the relationship between open source SysML and OMG SysML™?

SysML was originally developed as an open source specification by the SysML Partners, an informal association of tool vendors and industry leaders. The SysML Partners submitted the SysML 1.0a open source specification to the Object Management Group (OMG) in November 2005. OMG SysML™ is derived from the open source SysML specification, and is trademarked and maintained by the OMG.

What are the strengths and weaknesses of SysML as an architectural modeling language for MBSE?

Although OMG SysML reuses many of UML2's diagrams and constructs, this new lightweight dialect (Profile) of SysML is much less mature than its linguistic parent because it exacerbates problems inherited from UML 2 and adds new problems by introducing two new diagrams types (Requirement and Parametric diagrams) that are relatively immature (v. 1.x vs. v. 2.y):

SYSML & UML 2 GENERAL ISSUES (Shared with UML 2.x parent language)

Language bloat.

Increase of UML 2.x voodoo semantics.

A common and fair criticism of UML 2.x is that it is gratuitously large and complex. While SysML marketecture indicates that SysML is a "smaller, simpler" language for systems engineers, the reality is that SysML itself also suffers from language bloat because it adds two new diagrams (Requirements and Parametrics) and substantially increases the number of stereotypes with imprecise semantics (see Increase of UML 2.x voodoo semantics below), while failing to explicitly exclude many redundant and software-centric UML 2 constructs from the seven UML 2 diagrams that it inherits. The bloat is exacerbated because the SysML specification provides no guidelines regarding how to combine SysML models with UML models for engineering teams that include both software engineers and system engineers.

Recommendations: Explicitly remove UML constructs not needed for SysML. Provide concrete guidelines regarding how to combine SysML models with UML models for engineering teams that include both software engineers and system engineers. Encourage tool vendors to support automated translation of diagrams shared between the two languages.

Another common and fair criticism of UML 2.x is that its semantics, including its purported executable semantics (a.k.a. the Action Semantics), are ambiguous and imprecise. While SysML marketecture indicates that SysML supports precise semantics for specifying parametric constraints, the reality is SysML defines only vague natural language semantics for ConstraintBlock, ConstraintProperty, and Context-Specific Values/Constraints. Similarly, the semantics for Activity diagram extensions related to continuous/discrete rates and probabilities lack formal precision.

Recommendations: Add precise semantics for Parametric and Requirement diagram constructs, and Activity diagram extensions.

SYSML-SPECIFIC ISSUES (Apply to SysML but not UML 2.x parent language)

Structural constructs for Physical and Information (Standard) Interfaces are gratuitously complex and confusing.

Instance Specifications are ambiguously defined and poorly integrated with the rest of SysML.

Parametric constructs are ambiguously defined and poorly integrated with the rest of SysML.

The semantics and notations for StandardPorts, FlowPorts, Provided & Required Interfaces, and ItemFlows were gratuitously complex and confusing in SysML v. 1.0 - 1.2, since they conflated dependency relationships with flow relationships. Unfortunately, the patches made to fix these problems with new constructs in the SysML v. 1.3 minor revision (FullPorts, ProxyPorts, InterfaceBlocks) have exacerbated these problems, rather than fix them.

Although Instance Specifications were recently added to SysML 1.2, Object diagrams were not, and many issues remain about their specialized usage within SysML.

Recommendations: Unify, simplify, and clarify the Physical and Information Interface syntax and semantics in the next major revision, SysML 2.0.

Although Instance Specifications were recently added to SysML 1.2, Object diagrams are clearly an afterthought in the language, and have never been fully integrated with the rest of SysML.

Recommendations: Add Object diagrams as a first-class SysML diagram type, and clarify the similarities and differences between SysML and UML Instance Specification syntax, semantics, and usages.

Parametric Constraint Blocks and Constraint Properties are ambiguously defined and poorly integrated with other SysML structural diagrams. The currently have the dubious distinction of being the least mature and most problematic SysML diagram to use.

Recommendations: Parametric Diagrams need a complete overhaul in the next SysML major revision (SysML 2.0). This overhaul should factor in lessons learned from building bi-directional bridges between SysML 1.x Parametric diagrams and 3rd-party mathematical modeling & simulation tools (e.g., MATLAB/Simulink, Mathematica).

Requirement constructs are incomplete and confusing.

Problems associated with Requirement diagrams include, but are not limited to, clarifying decomposition/containment semantics, categorization, defining basic properties, clarifying relationship semantics, and reducing the semantic overlap with Use Cases.

Recommendations: Replace Containment with Composition for Requirements decomposition. Retire Copy dependency. Provide additional Requirement properties for source, priority, risk, verifyMethod, etc.

Allocation relationships and tables are incomplete and ambiguous.

With the exception of the AllocateActivityPartition stereotype, the current specification fails to leverage the architectural integrity allocations of its parent language. In addition, the definitions of the Allocate and Allocated stereotypes strongly suggest conflated dependency and flow semantics, which are indicative of novice UML modelers ("which way does the arrow point?").

Recommendations: Replace Allocate dependencies with flows that use distinctive notation (not dashed arrows labeled with keywords). Require that implementations automatically generate Allocate dependencies for AllocateActivityPartitions.

ValueType-Type integration needs simplification and a SI Model Library.

The current usage of ValueTypes with Units and QuantityKinds (formerly Dimensions) and their integration with UML DataTypes needs to be clarified and simplified.

Recommendations: Simplify and predefine a standard SysML ValueType model library based on International System of Units (SI) standards.

What is the best way to learn SysML?

Learning any new language is challenging, whether it is a natural language (e.g., Japanese, Swahili, English) or an artificial language, such as SysML. Since SysML is a dialect (Profile) of UML 2, if you are fluent in UML 2—and understand how Parts, Ports and Connectors support component-based design—you should be able to learn the SysML dialect relatively quickly. On the other hand, if you have only dabbled with UML 1 and have succumbed to UML 1 worst practices (e.g., Use Case Abuse), your previous bad exposure to UML 1 may be a liability rather than an asset.

In order to increase your likelihood of achieving SysML language fluency, you may want to consider a multi-pronged approach to learning SysML. For example, if you have the opportunity you may want to start off with basic MBSE + SysML hands-on training, followed up by MBSE Expert coaching (mentoring) for On-The-Job (OTJ) training, which in turn is followed up with advanced MBSE + SysML hands-on training. For the best learning experience, ensure that all your MBSE + SysML training is taught by MBSE Expert practitioners with extensive application experience (10+ years) working on large System-of-System projects (100+ Engineers), and includes frequent hands-on practice sessions and Q&A sessions.

In addition, you should also read voraciously about SysML techniques and best practices, so that you can further benefit from the experience (and mistakes) of others.

Recommended SysML Tutorials and SysML Examples:
- SysML.org (#1 ranked SysML web site)
  - SysML Diagram Tutorial
  - SysML by Example Tutorial: Griffin Space Vehicle Project
- SysMLforum.com
  - Simulatable & Scalable SysML Examples for Agile MBSE
Recommended SysML books:
- Selected SysML Books for MBSE

You can find a listing of selected MBSE + SysML training resources on the SysML + MBSE Training & Certification page of this web.

Which language is easier to learn, SysML or UML?

The answer likely depends on whether you are a Systems Engineer or a Software Developer. If you are a Systems Engineer, you should expect SysML to be easier to learn, since it is smaller language and it is customized for your systems engineering applications. If you are a Software Developer, you will likely prefer UML's software-centric bias.

Can SysML be used as an Agile Architecture & Design (Agile Modeling) language?

Yes, SysML is emerging as an attractive alternative to its parent language, UML 2, for Agile Architecture & Design (a.k.a. Agile Modeling) applications.

Why is SysML an attractive alternative to UML? Consider that SysML is substantially smaller than UML 2.x, so it is easier to learn and apply, yet it is more semantically expressive than UML 2.x, so you can specify visual Requirements and Parametric Constraints as well as Analysis and Design artifacts. Stated otherwise, SysML is more agile and more semantically powerful, while UML is plodding and less semantically powerful. So it shouldn't be surprising that many software engineers and developers are looking at SysML as a "better UML."

How can I report a SysML issue or submit a SysML change request?

The current version of OMG SysML is v. 1.5, and an OMG SysML v 1.6 Revision Task Force (RTF) is working on proposed improvements to OMG SysML based on feedback from the SysML tool vendor and user communities. The OMG SysML v. 1.6 RTF's Issue List is public, contains issues dating back to 2006, and is organized into open and closed issues.

You can comment on any open issue by sending email to sysml-rtf@omg.org. In addition you can submit new issues, including change requests, by sending email to issues@omg.org.

How can readers submit new questions for this FAQ?

Please email your request for new questions to be answered using the Contact page.

MBSE + SysML Public Training...
• Choose CAMEO or SPARX EA integrated tool training
• Secure Virtual (Online) Classrooms
• Taught by MBSE + SysML Experts w/ 10+ yrs experience

SysML Versions

What is the current version of the SysML specification, and where can I download it?

The current version of the OMG SysML specification is OMG SysML v. 1.7, which is available from the SysML Specifications page of this web or can be downloaded from the OMG web.

You can find a OMG SysML v. 1.7 minor revision change summary as part of the Answer to the SysML FAQ: What is new in OMG SysML 1.7?.

What is new in the OMG SysML 1.6 minor revision?

OMG SysML v. 1.6 Minor Revision Change Summary:

Block-typed Properties without Associations: Properties typed by Blocks must no longer be defined as an end of an Association. Consequently, you can now create Part Properties in an Internal Block Diagram without modeling a Composition Association relationship in a Block Definition Diagram (BDD).
Interface Block Realization and Conjugated Ports: Interface Blocks can be Specialized (inverse of Generalized) by Blocks so that they Realize (i.e., Implement; cf. Inherit) the Interface Block’s Flow Properties. In addition, the Realized Interface Block Flow Properties can subsequently be Conjugated.
Property-Specific Types: The syntax and semantics of Property-Specific Types are clarified.
Improved Well-Formedness Rules: A substantial amount of precise Natural Language semantics has been replaced by OCL WFRs.
Naming and Compartment Labeling Conventions: Various tweaks were made to Stereotype names and Block compartment labels to improve consistency and readability. Binding Connector keyword notation supports both “«equal»” and the symbol “=“.

Unsubstantiated Claims:
N/A

Critical Commentary:

Change# 1 breaks the Definition/Usage dichotomy pattern of BDDs/IBDs, which is based on the Definition/Usage pattern of UML2 Class/Composite Structure diagrams, for no good reason. This will be impractical for SysML tool vendors to implement, and (if it has merit) should be deferred to the UML 2 major revision.
Change# 2 conflates Generalization/Inheritance with Realization semantics and indicates that the current Revision Task Force (RTF) is confused about the syntax and semantics of SysML’s parent language (UML 2.x). This is another non-minor change that should be outside the scope of a minor revision.
Change# 3 is an academic tweak to an impractical language feature.

Download:
You can download the OMG SysML v. 1.6 specification, as well as specifications for previous versions, from the SysML Specifications page.

What is new in the OMG SysML 1.5 minor revision?

OMG SysML v. 1.5 Minor Revision Change Summary:
As should be expected in a long (10+ years) series of minor OMG SysML 1.x minor revisions, the OMG SysML v. 1.5 minor revision includes only trivial tweaks to the language.

Allows Requirement properties and taxonomies to be defined by specializing the SysML Requirement stereotype. Also adds Requirement compartment notation to show Requirement relationships.
Adds Block compartment notation to show Signal Receptions.

Unsubstantiated Claims:
N/A

Critical Commentary:
It's not clear why the OMG bothered with such trivial revisions to OMG SysML 1.4. The time and effort squandered would be better spent accelerating the long overdue OMG SysML 2.0 revision process.

Download:
You can download the OMG SysML v. 1.5 specification, as well as specifications for previous versions, from the SysML Specifications page.

What is new in the OMG SysML 1.4 minor revision?

OMG SysML v. 1.4 Minor Revision Change Summary:
As opposed to the OMG SysML v. 1.3 minor revision, which introduced major changes to Physical Flows (see Critical Commentary in the SysML FAQ: What’s new in OMG SysML 1.3?), the OMG SysML v. 1.4 minor revision includes only minor changes to the language.

Improved support for opposition hierarchies: Support for references to nested Parts in composition hierarchies. Added Bound Reference to specify connected properties that constrained by the same type or value.
Added Element Group to organize constructs without Package semantics. (Element Group is a drawing convenience without well-defined semantics.).
Enhanced View and Viewpoint constructs.
Added notations for inherited features, behavior compartments, and Port features.
Added non-normative Quantity and Unit (QUDV) model libraries compatible with ISO 80000-1.
Various updates to abstract syntax, concrete syntax to improve model interchange capabilities.

Unsubstantiated Claims:

Improved OMG SysML diagram interchange capability

Critical Commentary:
Perhaps the OMG v. 1.4 Revision Task Force (RTF) attempted to compensate for the Physical Flow scope creep in OMG v. 1.3 by ensuring that OMG v. 1.4 included only bona fide minor revisions. However, they appear to have overcompensated, since many of minor revisions in OMG v. 1.4 are poorly defined or non-normative.

Download:
You can download the OMG SysML v. 1.4 specification, as well as specifications for previous versions, from the SysML Specifications page.

What is new in the OMG SysML 1.3 minor revision?

OMG SysML v. 1.3 Minor Revision Change Summary:

Redefinition of Physical Flows : Deprecation of Flow Specifications. Addition of Nested Ports and Proxy Ports, and support for hierarchically nested Interfaces.
Architectural alignment with UML v. 2.4.1 metamodel changes

Critical Commentary:
Although UML 1.x Flow Specifications were well known to be flawed due to their gratuitous complexity, their deprecation and replacement by two new (and unproven) physical Ports types (Nested Ports, Proxy Ports) in a minor revision risks compounding Physical Flow problems. Such significant structural changes to OMG SysML, which is merely a Profile of UML 2.x, should be undertaken in the scope of a major revision to SysML, not a minor revision. Further note that major revisions to UML and OMG SysML (i.e., UML 3.0 and SysML 2.0, respectively) are both long overdue since the OMG adopted UML 2.0 over thirteen years ago, and it adopted OMG SysML v. 1.0 over ten years ago.

Download:
You can download the OMG SysML v. 1.3 specification, as well as specifications for previous versions, from the SysML Specifications page.

What is new in the OMG SysML 1.2 minor revision?

OMG SysML v. 1.2 Minor Revision Change Summary:

Inclusion of UML Instances, Structured Activities, and multiple Item Flow notation
Improvements to Value Types related to Unit and QuantityKind
Synchronization with UML 2.3 metamodel changes

Download:
You can download the OMG SysML v. 1.2 specification, as well as specifications for previous versions, from the SysML Specifications page.

What is new in the OMG SysML 1.1 minor revision?

OMG SysML v. 1.1 Minor Revision Change Summary:

Mostly editorial corrections and bug fixes for OMG SysML v. 1.0.

Download:
You can download the OMG SysML v. 1.1 specification, as well as specifications for previous versions, from the SysML Specifications page.

SysML Diagrams & Modeling Techniques

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 for Agile MBSE™

Agile MBSE™ + SysML Expert
Training & Certification...

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

What is a SysML Requirement diagram and how is it used?

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.

Agile MBSE™ + SysML Expert
Training & Certification...

SysML Requirement Diagram:
Top-Level Requirements

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 and how is it used?

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

Agile MBSE™ + SysML Expert
Training & Certification...

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 Activity diagram and how is it used?

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

SysML Activity Diagram:
Top-Level Functions

SysML Activity Diagram:
Function Decomposition

Agile MBSE™ + SysML Expert
Training & Certification...

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 Block Definition Diagram (BDD) and how is it used?

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

Agile MBSE™ + SysML Expert
Training & Certification...

SysML Block Definition Diagram: Block Anatomy

SysML Block Definition Diagram (BDD):
System Block Anatomy

SysML Block Definition Diagram: System Context

SysML Block Definition Diagram (BDD):
System Context

SysML Block Definition Diagram (BDD):
System Interfaces

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 (IBD) and how is it used?

What is a SysML Internal Block Diagram?

Definitions

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

SysML BDD: Part Definition Example

SysML IBD: Part Usage Example

Agile MBSE™ + SysML Expert
Training & Certification...

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 Control Object Blocks.	* Bloctivity Anti-Pattern = Conflate Block and Activity syntax and semantics.

What is a SysML Parametric diagram and how is it used?

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

Agile MBSE™ + SysML Expert
Training & Certification...

SysML BDD: Constraint Block Definition

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 Sequence diagram and how is it used?

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 (seq): 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.

Agile MBSE™ + SysML Expert
Training & Certification...

SysML Sequence Diagram:
Top-Level Sequence

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 and how is it used?

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.

Agile MBSE™ + SysML Expert
Training & Certification...

SysML State Machine Diagram:
Top-Level State Machine

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 Package diagram and how is it used?

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

Agile MBSE™ + SysML Expert
Training & Certification...

SysML Package Diagram (PKG): Views & Viewpoints

SysML Package Diagram (PKG): System Design View

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
Package diagram (pkg)	Static Structure [Grouping]	Package [minor mods]	All SDLC phases

Usage Notes

BEST PRACTICE PATTERNS	ANTI-PATTERNS
* Use a Enterprise Architecture Framework (EAF) Package Patterns to organize the complexity of your System Architecture Model.	* Fractured-Framework Anti-Pattern: Ad Hoc/Chaotic Package organization.

What is a SysML Allocation Table and how is it used?

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.

Agile MBSE™ + SysML Expert
Training & Certification...

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.

What are the "Four Pillars" of SysML?
(What are the essential diagrams of SysML?)

The expression the Four Pillars of SysML refers to the four essential diagrams of SysML: Requirement, Activity, Block, and Parametric diagrams. The expression was coined by Cris Kobryn, the chair of the SysML Partners open source specification project, when he observed that 80+% of the time that the SysML Partners discussed SysML language features they were discussing features in these four diagrams. He further noted that, from an artificial language design perspective, the Activity and Block diagram pillars were more important than the other two, since they were based on proven UML2 diagram techniques that already successfully integrated (allocated) behaviors (functions) to structures.

Which SysML diagrams support Agile Modeling or Agile Methods (SCRUM, Crystal, etc.)?

Answer to be provided. (Contact us if you want this answer to be prioritzed.)

What is the difference between a structural diagram and a behavioral diagram?

As their names imply, a structural diagram emphasizes the static structures of the system entities, whereas a behavioral diagram emphasizes the dynamic behaviors of system entities.

What is the difference between a Block Definition Diagram (BDD) and an Internal Block Diagram (IBD)?

Block Definition Diagrams (BDDs) and Internal Block Diagrams (IBDs) work in a complementary manner to recursively generate structures of arbitrary complexity during System Analysis & Design. This is necessary because the System-of-System Engineering problem is fractal in nature, where systems can be concurrently composed and decomposed: ... Systems-of-Systems-of-Systems, Systems-of-Systems, Systems, Subsystems, Sub-Subsystems, Sub-Sub-Subsystems ...

The manner in which BDDs and IBDs complement each other is sometimes referred to as the BDD-IBD Definition-Usage dichotomy. Compare and contrast: UML Specification-Realization and Type-Instance dichotomies.

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.

SysML Block Definition Diagram (BDD):
System Components

SysML IBD: Part Usage Example

SysML Elements

What is the difference between a Block and a UML Class?

A SysML Block, which is the basic structural element used within a SysML model, is a stereotyped (customized) extension of a UML Class, which is the basic structural element used within a UML object model. Consequently, they are closely related to each other in terms of both anatomy and usage, where the former (Block) should be consider an extended customization of the latter (Class).

More specifically, a UML Class has Properties (a.k.a. attributes) that define its internal state, Operations (a.k.a., methods) that define its potential behaviors when interacting with other objects, and Ports that define unique interaction points for attaching provided and required Interfaces.

SysML Blocks extend the syntax and semantics of UML Classes by distinguishing among various kinds of Properties (Parts, References, Values) and include additional Ports for physical flows (Flow Ports [deprecated along with Flow Specifications in SysML v. 1.3], Full Ports, Proxy Ports).

What is the difference between a Block and a Package?

In both SysML and its parent language UML, a Package is a generic grouping mechanism for organizing various model elements and related diagrams within a unique namespace. A SysML Package is capable of containing any arbitrary SysML model element, including (but not limited to) Blocks.

A SysML Block is the basic structural element used within a SysML model, and is used analogously to how UML Classes are used to structure a UML object model. See SysML FAQ: What is the difference between SysML Block and UML Class?

Consequently, while a SysML Package may contain (provide a unique namespace for) Blocks and other SysML model elements, a SysML Block cannot own (be composed of) or contain SysML Packages or SysML diagrams.

Usage Note: Can SysML Blocks and Packages be used together in a complementary manner?: Yes, when recursively decomposing systems into subsystems, sub-subsystems, etc. It’s considered a best practice to recursively organize the model view Package structures in a manner similar to the recursive structural decomposition. A variation of this technique will also work for large, complex data structures.

What is a ValueType?
How does a SysML ValueType differ from a UML DataType?

A SysML ValueType is a stereotype of UML DataType that can be used to type a wide range of basic structural elements by their values, where these types can also include information about associated quantity kinds (via a QuantityKind tagged value) and units of measure (via a Unit tagged value).

ValueTypes can be applied to type many structural elements in a SysML model, including the following:

Blocks: Value Properties, Operation parameters & return values, atomic Flow Ports
Associations/Connectors: ItemFlows, Item properties
Activities: ObjectNodes, Pins, Activity Parameters
ConstraintBlocks: Constraint parameters

SysML defines three kinds of ValueTypes:

Primitive ValueType has no internal structure (no Value Properties of its own). SysML pre-defines four Primitive ValueTypes (String, Boolean, Integer, Real) and you can define more as needed.
Notation: Rectangle with stereotype «valueType» preceding the name.
Structured ValueType has internal structure, defined as Value Properties, and can be recursively nested.
Notation: Rectangle with stereotype «valueType» preceding the name, with optional compartment for Value Properties.
Enumerated ValueType is a list of literal string values, equivalent to a UML Enumeration.
Notation: Rectangle with stereotype «enumeration» preceding the name, with optional compartment for literal string values.

Consequently, whereas UML was limited to simple and structured DataTypes such as «dataType» Real and «dataType» DateTime, SysML is able to specify ValueTypes with QuantityKinds and Units. For example, «valueType» CelsiusTemp can be defined as a subtype of «valueType» Real, where QuantityKind = Thermodynamic Temperature, Unit = Centigrade Degree. «valueType» TimeDate can be defined with properties: year [QuantityKind = Time, Unit = Year]; month [QuantityKind = Time, Unit = Month]; …

SysML + UML 2 Mixed Language Usage:
Although SysML was originally designed to be used in a complementary manner with UML 2, where SysML ValueTypes could supplement UML 2 DataTypes, the SysML 1.3 minor revision has merged UML 2 DataTypes with SysML ValueTypes. See SysML Revision Task Force (SysML RTF) Issue 13345: Merge UML DataType into SysML ValueType.

Note that the change above does not preclude SysML + UML 2 mixed language usage in the same model. However, serious practitioners are encouraged to systematically partition the language elements in different model «view»’s and/or Packages. For example, use SysML model elements to specify the Functional Analysis «view» and UML 2 model elements to specify the Software Design in the System Design «view».

What is the difference between Generalization (“white triangle”) and Part Association (“black diamond”) relationships?

A Generalization (a.k.a. Inheritance) relationship is a “kind of” or “type of” relationship between two model elements, where one model element is generalized and the other end is specialized. A Generalization relationship is drawn as a an arrow where the tail is attached to the specialized model element, and a white triangle arrowhead is attached to the generalized model element.

A Part Association relationship is a “whole-part or “composition” relationship between two model elements, where one model element is the subject component and the other end is a part of the whole component. A Part Association relationship is drawn as an arrow where the tail is attached to the part element, and a black diamond arrowhead is attached to the whole component element.

What are the differences among Part Association (“black diamond”), Shared Association (“white diamond”), and Reference Association relationships?

The following kinds of Association relationships are defined in order of increasing semantics:

A Reference Association relationship is a nondescript relationship between two model elements, which indicates that one instance of the referencing model element may invoke operations or otherwise interact with instances of the referenced model element during an interaction between the two object. For example, if Block A has a Reference Association to Block B with Operation mumble, an instance of Block A may potentially send a message mumble to an instance of Block B during some interaction between the two objects.

A Part Association (a.k.a. Composition) relationship is a “whole-part relationship between two model elements, where one model element is the whole component and the other end is a part of the whole component, that is “owned by” the whole component. A Part Association relationship is drawn as an arrow where the tail is attached to the part element, and a black diamond arrowhead is attached to the whole component element. Part Association relationships manifest strong ownership semantics, where if the whole part is deleted or removed from the model, all the parts owned by the whole part will be deleted as well.

A Shared Association (a.k.a. Aggregation) relationship is a weaker form of the Part Association relationship described above. A Shared Association relationship is drawn as an arrow where the tail is attached to the part element, and a white diamond arrowhead is attached to the whole component element. Shared Association relationships manifest weak ownership semantics, where if the whole part is deleted or removed from the model, all the parts owned by the whole part will not be deleted.

What is a "cross-cutting" relationship in SysML and how is it used?

In the context of SysML and its parent language UML 2, a cross-cutting relationship is a relationship which crosses diagram types. A common example of a cross-cutting relationship would be a Requirement diagram <> relationships, since the model elements that satisfy Requirements are commonly found on other diagram types (e.g., Block Definition, Activity).

How does SysML enable Requirements Verification & Validation (V&V)

Since the terms verification and validation are commonly conflated among systems and software engineers, we first clarify the differences between them using Boehm's classic formal and informal definitions [Boehm 84]:

A. Definitions

Verification - to establish the truth of the correspondence between a software product and its specification. (Note: This definition is derived from the Latin word for "truth," veritas. Note also that data bases and documentation are fit subjects for verification, as well as programs.)
Validation - to establish the fitness or worth of a software product for its operational mission. (Note: This definition is derived from the Latin word for "to be worthy," valere.)

Informally, we might define these terms via the following questions:

Verification: "Am I building the product right?"
Validation: "Am I building the right product?"

— [Boehm 84] Guidelines for Verifying and Validating Software Requirements and Design Specifications

Agile MBSE™: 6D System M-Model

Requirement Validation is typically the responsibility of system Stakeholders, who review Requirement specifications (e.g., SysML Requirement diagrams) to determine that they define "the right product" to be built. Requirement qualities checked during Validation include, but are not limited to, the following: Correctness, Completeness, Consistency, Clarity (Unambiguousness), Conciseness, Feasibility, Necessity, and Prioritization.
SysML Support for Requirement Validation: SysML supports Requirement Validation by defining Requirements as first-class visual modeling elements that can be classified (e.g., Functional, Performance, Interface, Design Constraints), organized into hierarchies (via Containment relationships), and assigned properties (TaggedValues) as needed (e.g., Risk, VerifyMethod, Priority, Level-of-Effort).

Requirement Verification is typically the responsibility of System Engineers and Systems Analysts, who (as per [Boehm 84]) "establish the truth of the correspondence between" the systems engineering product and its Requirement specification.
SysML Support for Requirement Verification: SysML primarily supports Requirement Verification via two complementary relationships:

Satisfy («satisfy») dependency: The client model element fulfills a supplier Requirement. e.g., An Optimize Subsystem Activity Satisfies the 2.3.5 Optimize Subsystems Functional Requirement. [See example below.]
Verify («verify») dependency: The client TestCase («testCase») determines whether a supplier Requirement has been fulfilled. e.g., A Test Subsystem Optimization Activity «testCase» Verifies the 2.3.5 Optimize Subsystems Functional Requirement and Tests the SmartCarController Block in the System Design «view». [See example below.]

Another Requirement Verification best practice is to define a VerifyMethod property (TaggedValue) for Requirements with appropriate values (e.g., Analysis, Demonstration, Inspection, Test).

SysML Tools & Interoperability

What SysML modeling tools are available?

You can find a selected list of SysML modeling tools that are compliant with the current SysML specification on the SysML Tools web.

How can I select the best SysML modeling tool for my MBSE team or project?

Although the answer to this question will dependent upon your particular MBSE team and project needs, you can find some pragmatic guidelines in the How to Select a SysML Modeling Tool for MBSE article.

What evaluation criteria should I apply for selecting a SysML modeling tool for my MBSE team or project?

Although the answer to this question will dependent upon your particular MBSE team and their project needs, you can find some pragmatic guidelines in the How to Define SysML Tool Evaluation Criteria for MBSE article.

What is the best free and open-source SysML modeling tool?

You can find a selection of Free & Open Source Software (FOSS) SysML modeling tools in the Commercial, Free & Open Source SysML Tools for MBSE section.

How can I choose between the Sparx EA and MagicDraw/Cameo architecture modeling tools?

Both Sparx Enterprise Architect™ (Sparx EA) and MagicDraw™ / Cameo™ (Cameo Systems Modeler™ and Cameo Enterprise Architecture™) are capable and popular architectural modeling tools that actively compete against each other. PivotPoint offers integrated Model-Based Engineering training for both of these popular architecture modeling tools (see Custom Sparx Enterprise Architect Training & Certification and Custom MagicDraw™ & Cameo™ Training & Certification), and free, fully-enabled trial licenses are available for both tools to be used during training.

Which architecture modeling tool should you use for your PivotPoint Model-Based Engineering training? Both tools have different strengths and weaknesses ("pros" and "cons"), and your ultimate choice will depend upon many factors, not the least of which is your software tool budget! We encourage you to explore the many online reviews for both tools by searching the following queries:

Contact us to discuss details regarding Sparx EA vs MagicDraw/Cameo tool choices, as well as integrated architecture modeling tool training.

How can I choose between the MagicDraw and Cameo architecture modeling tools?

MagicDraw™ and Cameo™ (Cameo Systems Modeler™ and Cameo Enterprise Architecture™) are architectural modeling tools offered by the No Magic Inc. subsidiary of Dassault Systèmes. Simply stated, Cameo is a rebranding of MagicDraw, No Magic's flagship UML tool for software-intensive applications, for Model-Based Systems Engineering applications that use SysML (a dialect of UML 2 adapted for systems engineering). These two complementary architecture modeling tools are compared and contrasted in more detail below.

MagicDraw targets Software Engineers

MagicDraw is NoMagic's flagship enterprise architecture modeling tool that supports a wide range of popular modeling languages (UML 2, SysML, BPMN 2, etc.) and is capable of automatic static code generation (classes and interfaces) for popular Object-Oriented Programming Languages (Java, C#, C++, etc.). It also supports a wide range of plugins for data modeling, model simulation, and enterprise architecture frameworks (DoDAF 2, UPDM 2, TOGAF, etc.). MagicDraw is a popular choice for Software Engineers and Software Architects. See MagicDraw Editions for details.

Cameo targets Systems Engineers

Cameo Systems Modeler™ (CSM) is a collaborative Model-Based Systems Engineering (MBSE) environment based on MagicDraw that includes the SysML and Cameo Simulation Toolkit plugins, but does not include the Enterprise Architecture plugins bundled with Cameo Enterprise Architecture (CEA; see below). CSM is a popular choice for Systems Engineers seeking to simulate SysML system architecture models. See Cameo Systems Modeler Editions for details.
Cameo Enterprise Architecture™ (CEA) is also based on MagicDraw, and includes plugins for SysML, Cameo Data Modeler, Cameo Business Modeler and various enterprise architecture frameworks (DoDAF 2, MODAF, NAF 3 and UAF), but does not include the Cameo Simulation Toolkit plugin. CEA is a popular choice among Systems Engineers seeking to specify Enterprise Architecture Frameworks and data models with SysML. See Cameo Enterprise Architecture Editions for details.

Contact us to discuss details regarding MagicDraw/Cameo tool branding and plugin choices, as well as MagicDraw & Cameo architecture modeling tool training.

MBSE + SysML Public Training...
• Choose CAMEO or SPARX EA integrated tool training
• Secure Virtual (Online) Classrooms
• Taught by MBSE + SysML Experts w/ 10+ yrs experience

Advanced SysML Topics

What Model-Based methods and processes are compatible with SysML?

You can find a selected list of Model-Based methods and processes that are compatible with SysML on the MBSE Processes page.

What Model-Based architecture frameworks are compatible with SysML?

You can find a selected list of Model-Based architecture frameworks that are compatible with SysML on the Architecture Framework Forum web.

What is Model Management and why is it important?

Model Management is an umbrella term that refers to the use of Packages and related constructs to manage the complexity of large, complex Models that represent large, complex Systems. Model Management is important to a modeler because if she cannot manage the complexity of a large, complex model, there is no reason to expect she will be able to manage the complexity of a large, complex system.

Model Management uses Packages as a generic grouping construct, as well as the following stereotypes (customizations) of Package:

Package: Basic grouping construct for organizing model elements and diagrams that defines unique namespace semantics, as well as Import and Contains relationships. Packages can nested and stereotyped (i.e., customized) to further organize their contents.
Model («model»): The (system) Model stereotype organizes all model elements that describe the architecture of the system of interest, including all of its Views and Subystems.
View («view»)/Viewpoint («viewpoint»): The View stereotype organizes a projection (cf. set theory projection) on a Model from the perspective (Viewpoint) of a set of stakeholders (e.g., Customer, Systems Engineer, System Analyst, System Designer, Software Engineer, Test Engineer). A Model View conforms to the perspective of its Viewpoint. In SysML both View and Viewpoint are first class elements than can be precisely defined.
Subsystem («subsystem): The Subsystem stereotype decomposes a Model or its Views to reflect the logical or physical structure of the system of interest. Subsystems may be logical or physical abstractions, and if both types are present they should be distinguished by using stereotype keywords or some other distinctive notation. SysML and UML predefine the «subsystem» stereotype; users may define the «system» stereotype to complement the «subsystem» stereotype if the latter is not already predefined.
Model Library «modelLibrary»: The Model Library stereotype organizes model elements intended for reuse in a Model.
Framework «framework»: The Framework stereotype groups model elements that are intended to organize other models into Views, Subsystems, etc. Frameworks can conform to industry standards (DoDAF/MODAF, UPDM, TOGAF), corporate standards, or can be specified ad hoc.
Profile «profile»: The Profile stereotype organizes model elements used to customize domains, platforms, and processes. These model elements include Stereotypes, Tagged Values, and Constraints.

The notations for Package and its common stereotypes are shown in the Package Constructs figure below.

UML2/SysML Package Constructs

What is relation between a SysML model View and a ViewPoint?

A SysML system model View («view») defines a projection on a Model from the perspective of a set of stakeholders (e.g., Customer, Systems Engineer, Test Engineer), where the perspective is of a set of stakeholders is defined as a Viewpoint («view»). In SysML both View and Viewpoint are first class elements than can be precisely defined. SysML defines a Viewpoint as a stereotype (customization) of Class with tagged values (properties) for stakeholders, concerns, languages, methods, and purpose. A model View conforms to the perspective of its Viewpoint, as shown by a «conform» Dependency arrow.

For example, see the Views & Viewpoints figure below.

SysML Views & Viewpoints

What is relation between a SysML model View and a Subsystem?

Answer to be provided. (Contact us if you want this answer to be prioritzed.)

How can I specify SysML work artifacts for a MBSE project?

DISCLAIMER: The following content constitutes technical information; it does not constitute legal advice, and it does not establish an attorney-client relationship. If you need legal advice, please contact an attorney.

BACKGROUND - SysML-as-Executable-System-Architecture vs. SysML-as-Pretty-Pictures
Since Model-Based Systems Engineering (MBSE) technologies such as the SysML language and SysML modeling tools are frequently overhyped and underdelivered by MBSE evangelists and tool vendors, its important that you are able to distinguish between bona fide MBSE + SysML approaches that deliver quality SysML-as-System-Architecture-Blueprint work artifacts and bogus MBSE + SysML approaches that deliver SysML-as-Pretty-Pictures work artifacts. By specifying tool-independent and method-neutral Technical Requirements for your MBSE + SysML project deliverables, you can help ensure that your engineering or contractor team applies a bona fide, rather than a bogus, MBSE approach to your project.

Consider applying some variation of the following technical requirements to improve the quality of your MBSE + SysML project deliverables:

TECHNICAL REQUIREMENTS FOR MBSE + SYSML PROJECT DELIVERABLES (DRAFT)
The Systems Engineering Team (SE Team) assigned to the subject System project shall apply a rigorous Model-Based Systems Engineering (MBSE) approach that is fully documented and produces the following minimal set of project deliverables:

1.0 SYSTEM ARCHITECTURE MODEL (SAM)
The SE Team shall deliver a precise and complete System Architecture Model (SAM) as its primary project deliverable. The SAM shall serve as "system architecture truth" for all other System Development Life Cycle (SDLC) project deliverables (i.e., whenever there is a technical conflict between the SAM and another project deliverable, the former will technically prevail over the latter.). The SAM shall also demonstrate the MBSE principles and best practices described in the subsections below.

1.1 Industry Standards Compliance and Conformance: The SAM shall comply or conform with the following industry standards, which are listed in prioritized order (whenever there is a conflict among industry standards, the higher-priority industry standard will prevail):

OMG SysML: The SAM shall be specified using the OMG SysML architecture modeling language, the de facto industry standard for graphically specifying system engineering applications. The SAM shall be specified using OMG SysML v. 1.4 or later, and it must follow OMG SysML well-formedness rules for notation (graphical syntax) and semantics. …
INCOSE Systems Engineering Handbook and Guide to the Systems Engineering Body of Knowledge (SEBoK): …
ISO/IEC/IEEE 15288:2015 Systems and software engineering -- System life cycle processes: …
[Insert Enterprise Architecture Framework standard for relevant industry] (e.g., DoDAF 2, TOGAF 9, etc.)
[Insert Functional Safety standard for relevant Industry] (e.g., ISO 26262 Road vehicles – Functional safety)
[Insert Cybersecurity Framework Standard for relevant industry] (e.g., NIST Framework for Improving Critical Infrastructure v. 1.x)
…

…

1.2 Architecture-Centric: The SAM shall precisely and completely define the overall System Context and the System Architecture of the subject System throughout the System Development Lifecycle (SDLC). The System Context shall define the system scope in a clear and unambiguous manner for all System Stakeholders by explicitly defining the System-of-Systems of which the System is a part, as well as all other peer Systems with which the subject System interacts … The System Architecture shall be precisely and completely defined with sufficient clarity and detail so that it will be self-describing, and practical for a third party to bid and build the system without additional support materials. …
Detailed technical requirements to improve the precision and completeness of the SAM are described in the sections below …
…
1.3 Enterprise Architecture Framework Conformance: The SAM shall conform to a well-defined Enterprise Architecture Framework pattern that organizes all SAM elements into complementary SysML Views (horizontal layers of abstraction) that are rationally partitioned by SysML Packages, where all Views are defined by SysML Viewpoints (perspectives) meaningful to all System stakeholders. If an Enterprise Architecture Framework industry standard is not specified in the Industry Standards Compliance and Conformance section, the SE Team shall either adopt or adapt an industry standard Enterprise Architecture Framework, or alternatively define one precisely and completely using Views and Viewpoints …
…
1.4 Verification & Validation Support: The SAM shall demonstrate full Verification & Validation (V&V) support for all SAM model elements across the SDLC. The full V&V support shall extend to both sides (i.e., "Left Side" and "Right Side") of the industry standard System V-Model (a.k.a. System Vee Model) as specified in the System Life Cycle Process Models: Vee section of the SEBoK. As in SEBoK, the following sub-requirements refer to the "Left Side" and the "Right Side" of the System V-Model as per the original source [Forsberg, Mooz, and Cotterman 2005]:

"Left Side" of System V-Model: All System Architecture, Analysis, and Design model elements for work artifacts that comprise the "left side" of the System V-Model shall either directly or indirectly (i.e., transitively) satisfy the System Functional and Non-Functional Requirements specified in the System Requirements View of the SAM using SysML Satisfy dependency relationships. All demonstrations of System Requirement Satisfaction on the Left Side of the System V-Model shall be summarized by automated generation of appropriate Allocation Tables from the subject SAM …
"Right Side" of V-Model: All White-Box and Black-Box Test Cases for Unit, Integration and System verification and validation on the "Right Hand" side of the System V-Model shall test, verify, and validate all model elements on the "Left Side" of the System V-Model. All demonstrations of System Verification & Validation on the Right Side of the System V-Model shall be summarized by Allocation Takes automatically generated from the subject SAM …

…
1.5 Model-Based Simulation Support: The SAM shall demonstrate support for model-based simulations of SysML behavioral diagrams (Activity, Sequence, and State Machine diagrams) and model-based simulations of Parametric diagrams for Trade Studies applications …
…
1.6 Change Impact Analysis Support: The SAM shall demonstrate support for automated change impact analysis, whereby any change to any System Functional Requirement or Non-Functional Requirement shall result in a prioritized list of Architecture, Analysis, and Design model elements that are effected (i.e., impacted or changed) by the subject Requirement change. … The demonstration shall include one or more Allocation Tables that illustrate both the Requirement changes as well as their potential side effects (i.e., impacts) on other model elements.
…
1.N Tool-Independent & Tool-Proprietary Formats: The SAM in its entirety shall be delivered in all of the following tool-independent document formats: XMI (XML Model Interchange), HTML, RTF, and PDF. In addition, all SAM derived deliverables (see MODEL-BASED SRS, MODEL-BASED SDS, and MODEL-BASED ICDs sections below) shall be accompanied by the SAM View or specific Package from which it was derived in all the same tool-independent document formats listed above. …

Not withstanding the foregoing, the SE Team shall also provide the tool-proprietary format of the SysML compliant modeling tool used to generate the aforementioned SAM and SAM-derived deliverables in tool-independent formats. [Rationale: The System Integration Test (SIT) Team needs access to the SysML modeling tool-proprietary format for Quality Control purposes, so that they can efficiently apply model metrics and other diagnostics to the SAM to verify its correctness and completeness.] …
…
2.0 MODEL-BASED SYSTEM REQUIREMENTS SPECIFICATIONS (MODEL-BASED SRS)
All System Functional and Non-Functional requirements shall be precisely and completely specified in human-readable format in a System Requirements Specification (SRS) that is automatically generated from, or directly derived from, the SAM specified in the System Architecture Model section. At a minimum, the SRS shall define all Functional and Non-Functional Requirements as SysML Requirement elements in SysML Requirement diagrams, and it shall specify all System usage functions as SysML Use Case elements in SysML Use Case diagrams.

Both the SysML Requirement elements and SysML Use Case elements shall be hierarchically organized using the appropriate SysML relationships (Contains relationship and Includes dependency respectively). All Derived Requirements that are generated from existing Requirement shall be precisely specified using DeriveReqt dependencies…
Any semantic overlap that exists between SysML Functional Requirement elements and SysML Use Case elements shall be explicitly addressed and resolved using SysML Refine dependency relationships. …
…
3.0 MODEL-BASED SYSTEM DESIGN SPECIFICATIONS (MODEL-BASED SDS)
All System Designs shall be precisely and concisely specified in human-readable format in a System Design Specification (SDS) that is automatically generated from, or at least directly derived from, the SAM specified in the System Architecture Model section. At a minimum the SDS shall define all System and System Component static structures and dynamic behaviors in a manner that meets or exceeds the rigor described below.

3.1 System and Component Static Structures. The System and all of its Components shall be recursively specified as both black-box components and white-box components using SysML Block Definition (BDD) and SysML Internal Block Diagrams (BDD), respectively. The recursive specification of the System composition structure shall start with the System and will descend into Subsystem components, Sub-Subsystem components, etc. until the Block structures being specified are atomic (non-decomposable into SysML Parts).

All System Design structural components shall be fully specified as SysML Blocks with completely defined Properties (Part Property, Reference Properties, Value Properties), Operations and/or Signals, Constraints, Ports (Standard Ports, Proxy Ports, Full Ports), and Interfaces (Standard Interfaces, Interface Blocks). …
…
For more information regarding the precision and completeness required for specifying Ports and Interfaces, see the Model-Based ICD section …
…
3.2 System and Component Dynamic Behavior. The dynamic behavior of the System and its Components shall be precisely and completely specified by using a fully-integrated combination of SysML behavioral diagrams (Sequence, Activity, State Machine diagrams). At a minimum, all System and Component dynamic behavior shall precisely specify the following:

information (Data) Flow Interface interactions: All System and Component information (data) flow Interface interactions shall be precisely and completely specified using Sequence diagrams that show both synchronous and asynchronous communication sequences, as well as optional time constraints when appropriate. … As a matter of SAM architectural integrity, all Operations and Signals defined in Standard Interfaces in the Static Structural diagram must appear at least once in a Sequence diagram in the dynamic behavioral model. …
Physical Item Flow Interface interactions: All System and Component physical item flow interactions shall be precisely and completely defined via Item Flows in at least one Block Definition Diagram (BDD) + internal Block Diagram (IBD) matched pair, and must appear in at least one collaborative behavioral diagram (either an Activity or a Sequence diagram). …
System Critical Events. All dynamic behavior that is considered time critical, mission critical, life critical, or otherwise critical shall be precisely and completely specified by State Machine diagrams that are correctly and fully integrated with other related behavioral diagrams (e.g., Sequence and Activity diagrams).
…

…
4.0 MODEL-BASED INTERFACE CONTROL DOCUMENTS (MODEL-BASED ICD)
All System and System Component Interfaces shall be precisely and completely specified in human-readable Interface Control Documents (ICD) which are directly derived from work artifacts specified in the SAM in general, and the Model-Based SDS in particular, …
…
4.1 Information (Data) Flow Type interfaces. The ICD shall precisely and completely specify all Information (Data) Flow type interfaces in the following manner …
All Information Flow Interfaces shall be specified as SysML Standard Interfaces, where each Standard Interface is defined as a set of fully parameterized Operations and/or Signals, and each Interfaces is provided by at least one Block (specified by a Realize Dependency) , and is required by at least one other Block (specified by a Use Dependency relationship) …
…
In addition, the ICD shall include Sequence diagrams that show how all Interface Operations and/or Signals are used in at least one Sequence diagram interaction …
…
4.2 Physical Item Flow Type interfaces. The ICD shall precisely and completely specify all Physical Item Flow type interfaces in the following manner …
…

Please contact us to provide constructive feedback to improve the quality and utility of the MBSE technical requirements examples above.

Can SysML be customized by vendors or users?

Answer to be provided. (Contact us if you want this answer to be prioritzed.)

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.