SysML FAQ: What is SysML?, Why use SysML?, Who created SysML?


Please contact us regarding any additions or corrections to be made to this page.

General Questions

What is SysML?
The Systems Modeling Language (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 open source SysML specification is publicly available for download, and includes an open source license for distribution and use. The most recent revision of SysML adopted by the Object Management Group is OMG SysML v. 1.4. For more information about the most recent version of SysML see the SysML FAQ What is the current version of SysML?.

For more information about SysML's origin, usage, and diagram types
please see the following SysML FAQs: Who created SysML?, Why use SysML?, What are the SysML diagram types?
Why use SysML?
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.

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

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.
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 there are three usage modes of progressive rigor in which it is being applied:
  • SysML-as-Pretty-Pictures: This is the most informal and least rigorous SysML usage mode. Unfortunately, it is also the most common way that SysML is abused. In SysML-as-Pretty-Pictures 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 semantics. Consequently, the SysML models generated in SysML-as-Pretty-Pictures model are rarely capable of driving dynamic simulations or precisely specifying system architecture blueprints.
  • SysML-as-System-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 simulation engine, and some of the Parametric diagram constraints are exercised by a constraint propagation engine (MATLAB/Simulink, OpenModelica, SysML tool proprietary plugin, etc.).
  • SysML-as-System-Architecture-Blueprint: This SysML usage mode is a substantive improvement over SysML-as-System-Simulation mode, since it stresses the use of SysML to precisely specify a System Architecture Model that serves as system architecture "truth", and which satisfies the 5 C's (Correct, Complete, Clear, Concise, and Consistent). This is the most advanced SysML mode, and since it typically also includes simulatable behavioral and Parametric diagrams, it should be considered an evolution of the SysML-as-System-Simulation mode.
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).

Relationship between SysML & UML

Relationship between SysML & UML

Reproduced by Permission © 2003-2017 PivotPoint Technology Corp.



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 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).
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 it is marked N/A (e.g., UML 2 Communication diagram).

  • 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.
  • [No analogous diagram in UML 2]
  • 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).
  • [No analogous diagram in UML 2]
  • 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.
  • [No analogous table in UML 2]
  • 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
  • [No analogous diagram in SysML]
  • UML::
    Communication diagram
  • [No analogous diagram in SysML]
  • UML::
    Component diagram
  • [No analogous diagram in SysML]
  • UML::
    Deployment diagram
  • [No analogous diagram in SysML]
  • UML::
    Interaction Overview diagram
  • [No analogous diagram in SysML]
  • UML::
    Profile diagram
  • [No analogous diagram in SysML]
  • UML::
    Timing diagram


SysML-UML 2 Comparison

Reproduced by Permission © 2003-2017 PivotPoint Technology Corp.


What is Model-Based Systems Engineering (MBSE)?
Model-Based Systems Engineering (MBSE), a.k.a. Model-Based Systems Development (MBSD), is a Systems Engineering 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, Verification & Validation (V&V), functional analysis, performance analysis, trade studies, and system architecture specification.

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 visual modeling best practices.

The term Model-Based Systems Engineering is popular among Systems Engineers who advocate the use of SysML as a standard visual 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 MBSE.Works web.
What is the relationship between SysML and MBSE?
A recommended best practice for any Model-Based Systems Engineering approach is the synergistic application of Model-Based Languages, Model-Based Tools, Model-Based Processes, and Model-Based Architecture Frameworks.
As an open standard Architecture Description Language (ADL) for Systems Engineering applications, SysML is the Model-Based Language of choice for many MBSE endeavors. However, if you don't choose and apply the other key enabling MBSE technologies properly (Modeling Tools, Model-Based Processes, and Architecture Frameworks) your MBSE project will likely achieve poor or mixed results.

System Architecture Tetrad

System Architecture Tetrad


Reproduced by Permission © 2003-2017 PivotPoint Technology Corp.


As an open standard Architecture Description Language (ADL) for Systems Engineering applications, SysML is the Model-Based Language of choice for many MBSE endeavors. However, if you don't choose and apply the other key enabling MBSE technologies properly (Modeling Tools, Model-Based Processes, and Architecture Frameworks) your MBSE project will likely 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:
  1. 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.

  2. 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.
    • System Analysis or Functional Analysis «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.

  3. Define Requirements traceability dependencies/allocations across Views
    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+UML Example Request: If you are interested in pursuing the technical approach outlined above, but need a combined SysML + UML example to better understand how it works, please contact us. If we receive sufficient requests for a combined SysML+UML 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 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.
      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.
    • Increase of UML 2.x voodoo semantics.
      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 parent language)
    • Structural constructs for Physical and Information (Standard) Interfaces are gratuitously complex and confusing.
      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.
    • Instance Specifications are ambiguously defined and poorly integrated with the rest of SysML.
      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 constructs are ambiguously defined and poorly integrated with the rest of SysML.
      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 2and understand how Parts, Ports and Connectors support component-based designyou 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 SysML hands-on training, followed up by expert coaching (mentoring) for On The Job training, which in turn is followed up with advanced SysML hands-on training. For the best learning experience, ensure that all your SysML training is taught by expert practitioners with extensive application experience on large projects, and includes frequent hands-on practice sessions and Q&A sessions.

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

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

You can find a listing of selected SysML tutorials on the SysML Tutorials page of this web.

You can find a listing of selected SysML publications (including books, papers, and articles) on the SysML Publications 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.4, and an OMG SysML v 1.5 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.4 RTF's Issue List (http://www.omg.org/issues/sysml-rtf.open.html) 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.

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.4, 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.4 minor revision change summary as part of the Answer to the SysML FAQ: What is new in OMG SysML 1.4?.
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 Comment 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. Add 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 Comment:
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 and UML (i.e., SysML 2.0 and UML 3.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?
The SysML specification defines nine (9) diagram types, which are shown in the SysML Diagram Taxonomy figure below, and one tabular notation (Allocation tables). Of the nine diagram types, four diagram types are considered behavioral or dynamic (Activity, Sequence, State Machine, and Use Case), four diagram types are considered structural or static (Block Definition, Internal Block, Parametric, and Package) and the remaining diagram type is reserved for declaring requirements (Requirement).

Usage Note: Allocation tables are used for defining cross-cutting relationships between diagram types, and are useful to checking both semantic well-formedness rules and architectural integrity rules. A common example of a behavior-to-structure Allocation is the mapping of behavioral Activities in Activity diagrams to the structural Blocks in a Block Definition diagram via Activity Partitions (commonly referred to as "swim lanes"). A common example of a structure-to-structure Allocation is the mapping of Interface structures to the Block structures that realize or implement them.

SysML Diagram Taxonomy

SysML Diagram Taxonomy

Reproduced by Permission © 2003-2017 PivotPoint Technology Corp.


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 a SysML Requirement diagram and how is it used?
A SysML Requirement diagram shows relationships among visual Requirements constructs, and the model elements that fulfill and verify them.

Requirement diagrams can be used for specifying and managing system functional and non-functional requirements (e.g., performance).

Usage Note: Requirement diagrams that specify functional requirements can semantically overlap Use Case diagrams defining similar functions.
What is a SysML Use Case diagram and how is it used?
Answer to be provided. (Contact us if you want this answer to be prioritzed.)
What is a SysML Activity diagram and how is it used?
A SysML Activity diagram shows the functional behavior of a system using a control flows and data flows.

Systems Engineers can use Activity diagrams to specify function independent of structure (form) by not using Partitions (swimlanes)
Business Analysts can use Activity diagrams to represent business processes.

Compare and contrast: SA/SD EFFBDs, DFDs; BPMN Business Process Diagrams.
What is a SysML Block Definition Diagram (BDD) and how is it used?
A SysML Block Definition Diagram shows the static structure of a system using components called Blocks which are connected to other Blocks via Interfaces. A Block can represent a hardware, software, and "wetware" (organizational) components.

There are two kinds of Block diagrams in SysML, and they are designed to be used in a complementary manner: Block Definition diagrams and Internal Block diagrams.

Block Definition diagrams (BDD's) are used to define "black-box" components with external interfaces, where the external interfaces can support both information flows (via Standard Ports and Interfaces) and physical flows (via Flow Ports and Flow Specifications). SysML BDDs are derived from UML2 Class diagrams.

Internal Block diagrams (IBD's) are used to show the "white-box" perspective of Block components, where Connectors show how internal Parts are "wired" to external interfaces and each other. SysML IBDs are derived from UML2 Composite Structure diagrams.
What is a SysML Internal Block diagram and how is it used?
A SysML Internal Block diagram shows the internal static structure of a system using internal components called Parts which are connected via Connectors.

There are two kinds of Block diagrams in SysML, and they are designed to be used in a complementary manner: Block Definition diagrams and Internal Block diagrams.

Block Definition diagrams (BDD's) are used to define "black-box" components with external interfaces, where the external interfaces can support both information flows (via Standard Ports and Interfaces) and physical flows (via Flow Ports and Flow Specifications). SysML BDDs are derived from UML2 Class diagrams.

Internal Block diagrams (IBD's) are used to show the "white-box" perspective of Block components, where Connectors show how internal Parts are "wired" to external interfaces and each other. SysML IBDs are derived from UML2 Composite Structure diagrams.
What is the difference between a Block Definition Diagram (BDD) and an Internal Block Diagram (IBD)?
In order to understand the differences between Block Definition Diagrams and Internal Block Diagrams, one must first understand that they both feature the basic structural element of SysML, the block. A block is defined in SysML as follows:

block: a modular unit of system structure that encapsulates its contents, which include Properties, Operations, and Constraints. Blocks are essentially components that can both provide and require Interfaces for both information and physical flows. Blocks can be recursively decomposed into Parts, where each Part must also be defined by a Block.

A Block Definition Diagram (bdd or BDD) shows Blocks, their contents and relationships; in contrast, an Internal Block Diagram (ibd or IBD): shows the internal structure of a Block, showing its Parts and including its interaction points to other Parts of the system.

Usage Note: Block Definition Diagrams can be used in conjunction with Internal Block Diagrams to define system structures as trees of modular components, such as a System-of-Systems decomposition in a System Context diagram. A Block Definition Diagram (BDD) specifies a Block as a black-box representation whose white-box Part realization (implementation) is defined via an Internal Block Diagram (IBD). In this manner, BDD and IBD diagrams complement each other, and facilitate recursive design techniques. Blocks define their Parts, where each Part can have a different usage or role in the context of the Block that encapsulates it.

Related Constructs & Concepts
see: UML specification-realization dichotomy
compare and contrast: UML::Class, Composite Structure, and Component diagrams
What is a SysML Parametric diagram and how is it used?
A SysML Parametric diagram is a kind of Internal Block Diagram that shows constraint relationships between Blocks and their internal Properties or Parts.

Parametric diagrams can be used to show how a change to the value of one structural property of a system (a system Parameter) can impact the values of others. They are useful for specifying system design and architectural constraints, and are generally considered essential for specifying Trade Studies using SysML.
Parametric Diagram Example - zoom
Parametric Diagram Example
Reproduced by Permission © 2003-2017 PivotPoint Technology Corp.
What is a SysML Sequence diagram and how is it used?
Answer to be provided. (Contact us if you want this answer to be prioritzed.)
What is a SysML State Machine diagram and how is it used?
Answer to be provided. (Contact us if you want this answer to be prioritzed.)
What is a SysML Package diagram and how is it used?
Answer to be provided. (Contact us if you want this answer to be prioritzed.)

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) which define its potential behaviors when interacting with other objects, and Ports which 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 instances 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 note 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?"
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.]

SysML Requirements V&V

Requirements Verification & Validation


Reproduced by Permission © 2003-2017 PivotPoint Technology Corp.



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.

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.

Package Constructs

Package Constructs

Reproduced by Permission © 2003-2017 PivotPoint Technology Corp.


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.

Views & Viewpoints

Views & Viewpoints

Reproduced by Permission © 2003-2017 PivotPoint Technology Corp.


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.)
Can SysML and UML be used together in the same project?
Yes, SysML and UML are designed to be used together in the same project, where the Software Engineers use SysML for Requirements and System Analysis, and the Software Engineers use UML for Software Design. Unfortunately, many important details about how UML-SysML joint usage will work efficiently in practice are not addressed in the OMG SysML specification. The underlying problem is not mixed UML-SysML tool support, since many SysML tool vendors are UML tool vendors who implement SysML as a UML profile. In the more detailed answer that follows we assume that most UML-SysML tool vendors will be able to provide their users with "SysML only," "UML only," and "UML-SysML combined" usage modes or perspectives (the Eclipse term).

In order to understand the pragmatic problems of SysML-UML joint usage, let's consider the case of a large engineering project with many Systems Engineers and Software Engineers collaborating, where the former choose to specify Requirements and System Analysis in SysML and the latter select to specify Software Design in UML. The problems they encounter will range from linguistic overlap, where notations and semantics are similar, but differ in subtle yet important ways, to linguistic divergence, where there is no straightforward translation between the two. An example of relatively straightforward linguistic overlap is the translation between SysML Activity diagrams and UML Activity diagrams, where both diagram types use the same naming conventions, but the former make some modest notational extensions to the latter. UML profiles and stereotypes were designed to handle this case, so mixed teams using both SysML and UML Activity diagrams should not be confused by this mixed language usage.

Less straightforward is the linguistic overlap between SysML Block Definition/Internal Block diagrams and UML Class/Internal Structure/Component diagrams, where there are several issues involved in translating the former to the latter. These range from gratuitously different naming conventions (Blocks vs. Classes vs. Components), to more substantial issues such as adding SysML constructs with ambiguous semantics (e.g., SysML Item Flows) and diverging from UML's Class-Part-Instance trichotomy. (SysML has only recently added Instance Specifications with the SysML 1.2 minor revision and the ramifications of this change have not yet been fully worked out.)

There are also substantive linguistic divergence problems associated with at least one of SyML's new diagram types, Parametric diagrams. The SysML provides notation, but sparse semantics for this new diagram type, which introduces a constraint-logic paradigm that is not fully integrated into UML's object-component paradigm. In addition, SysML's Allocation relationships and UML's Trace/Refine relationships are ambiguous and overlap, so it is frequently unclear how to map SysML System Analysis constructs to UML Software Design constructs. For these reasons, project teams who plan to use both SysML and UML on large project should be aware that they will likely encounter both subtle and substantive translation and traceability problems. Hopefully vendors and methodologists will work out these problems soon, after they gain more experience applying SysML to real projects.
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-System-Architecture-Blueprint 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.):

  1. 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. …
  2. INCOSE Systems Engineering Handbook and Guide to the Systems Engineering Body of Knowledge (SEBoK): …
  3. ISO/IEC/IEEE 15288:2015 Systems and software engineering -- System life cycle processes: …
  4. [Insert Enterprise Architecture Framework standard for relevant industry] (e.g., DoDAF 2, TOGAF 9, etc.)
  5. [Insert Functional Safety standard for relevant Industry] (e.g., ISO 26262 Road vehicles – Functional safety)
  6. [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 Vee Model (a.k.a. System V-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 Vee Model as per the original source [Forsberg, Mooz, and Cotterman 2005]:
  • "Left Side" of System Vee Model: All System Architecture, Analysis and Design model elements for work artifacts that comprise the "left side" of the System Vee 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 Vee Model shall be summarized by automated generation of appropriate Allocation Tables from the subject SAM …
  • "Right Side" of Vee 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 Vee Model shall test, verify and validate all model elements on the "Left Side" of the System Vee Model. All demonstrations of System Verification & Validation on the Right Side of the System Vee 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:
  1. 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. …
  2. 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). …
  3. 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.)

OMG SYSML, UML, and UNIFIED MODELING LANGUAGE are trademarks of the Object Management Group. All other product and service names mentioned are the trademarks of their respective companies.