SysML Forum
Everything related to SysML


SysML Frequently Asked Questions

  • GENERAL
  • Back to Top
    What is the Systems Modeling Language (SysML)?
    The Systems Modeling Language (SysML) is general purpose visual 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 (Profile = UML customization that uses Stereotypes, Tagged Values, and Constraints.)
    • SysML is an enabling technology for Model-Based Systems Engineering (MBSE)


    SysML & Visual Modeling Language Evolution

    SysML & Visual Modeling Language Evolution

    Reproduced by Permission © 2003-2013 PivotPoint Technology Corp.



    The SysML was originally developed as an open source specification project initiated in 2003 in response to OMG’s “UML for Systems Engineering” RFP. SysML contains nine diagram types, seven of which it shares in common with its parent language, along with one tabular notation (Allocation tables.) The SysML specification is publicly available for download, and includes an open source license for distribution and use. The most recent revision is OMG SysML v. 1.2. (See Specifications page.)

    SysML Diagram Taxonomy

    SysML Diagram Taxonomy

    Reproduced by Permission © 2003-2013 PivotPoint Technology Corp.



    Back to Top
    Rate This Entry
  • Back to Top
    Why use SysML?
    If you are a Systems Engineering and want to improve the precision and efficiency of your communications with fellow Systems Engineers and other system and business stakeholders, then SysML is an excellent choice for a lingua franca. (If on the other hand, you are a Software Developer or a Business Analyst who wants to improve communications with your peers and other system stakeholders, then UML or BPMN may be better choices.) Here's a list of reasons why Systems Engineers may want to use SysML and a Model-Based Systems Engineering approach for their work:
    • Facilitate communication among various stakeholders across the System Development Life Cycle
    • Capture and manage corporate Intellectual Property related to system architectures, designs, and processes
    • 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
    • Detect errors and omissions early in System Development Life Cycle

    Back to Top
    Rate This Entry
  • Back to Top
    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 visual 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 and verification, functional analysis and allocations, 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 as 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 visual modeling and tool interoperability (e.g., SysML, UML, 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 Model-Based Systems Engineering Forum.

    Back to Top
    Rate This Entry
  • Back to Top
    What is the relationship between SysML and Model-Based Systems Engineering (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.

    System Architecture Tetrad

    System Architecture Tetrad


    Reproduced by Permission © 2003-2013 PivotPoint Technology Corp.


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

    Back to Top
    Rate This Entry
  • Back to Top
    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.

    Back to Top
    Rate This Entry
  • Back to Top
    Who created the SysML?
    The SysML specification was created by the SysML Partners, a group of software tool vendors and industry leaders organized in 2003 to create a dialect of UML for systems engineering called SysML (Systems Modeling Language). The SysML Partners defined SysML as an open source specification that would satisfy the requirements of the OMG's "UML for Systems Engineering" RFP, and their specifications include an open source license for distribution and use.

    The SysML Partners were founded and chaired by Cris Kobryn, who previously chaired the UML 1.x and UML 2.0 specification teams. Kobryn coined the language name "SysML" (short for "Systems Modeling Language"), designed the original SysML logo, and organized the core language design team as an open source specification project. Sandy Friedenthal, chair of the OMG Systems Engineering Special Interest Group, served as Deputy Chair.

    You can find out more about the SysML Partners and other SysML contributors on the SysML Partners page of the SysML.org web.

    Back to Top
    Rate This Entry
  • Back to Top
    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.

    Back to Top
    Rate This Entry
  • Back to Top
    What is the latest version of SysML, and how can I obtain a copy?
    The latest version of the OMG SysML specification is OMG SysML 1.3, 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 1.3 minor revision change summary as an Answer to the SysML FAQ "What changes were made during the last minor revision of OMG SysML?"

    Back to Top
    Rate This Entry
  • Back to Top
    What changes were made during the last minor revision of OMG SysML (OMG SysML 1.3)?
    OMG SysML 1.3 minor revision change summary:
    • Physical Flows - Deprecation of Flow Specifications
    • Physical Flows - Addition of Nested Ports and Proxy Ports.
    • Synchronization with UML 2.4.1 metamodel changes

    Comments: Although Flow Specifications were known to be flawed due to their gratuitous complexity, it is odd that they are being deprecated (phased out) and replaced by two new (and unproven) physical Ports types in a minor release. Since these are significant structural changes for modeling physical flows, one would normally expect these changes to be made in a major, rather than a minor, revision.

    CHANGES TO PREVIOUS VERSIONS OF OMG SysML 1.x
    OMG SysML 1.2 minor revision change summary:
    • Inclusion of UML Instances, Structured Activities, and multiple Item Flow notation
    • Improvements to Value Types related to Unity and QuantityKind
    • Synchronization with UML 2.3 metamodel changes

    Back to Top
    Rate This Entry
  • Back to Top
    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.

    Back to Top
    Rate This Entry
  • Back to Top
    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.

    Back to Top
    Rate This Entry
  • Back to Top
    How mature is OMG SysML 1.x?
    Although OMG SysML reuses many of UML2's diagrams and constructs, this new dialect (Profile) of SysML is much less mature than its linguistic parent because it exacerbates problems inherited from UML 2 and adds new problems with its two new diagrams (Requirement and Parametric diagrams):

    • GENERAL ISSUES
      • Increase of UML 2.x 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 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 constructs and Activity diagram extensions.
    • SPECIFIC ISSUES
      • Structural constructs for Interfaces and Instances are complex and muddled.
        The semantics and notations for StandardPorts, FlowPorts, Provided/Required Interfaces, and ItemFlows are excessively complex and their usages are frequently counter-intuitive since they conflate dependencies with flows. 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 Ports/Interfaces/ItemFlows constructs. Add Object diagrams and clarify differences between SysML and UML Instance syntax semantics.
      • 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 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 arrrows labeled with keywords). Require that implementations automatically generate Allocate dependencies for AllocateActivityPartitions.
      • ValueType-Type integration needs simplification.
        The current usage of ValueTypes with Units and Dimensions and their integration with UML DataTypes needs to be clarified and simplified.
        • Recommendations: Simplify and predefine a standard ValueType library.

    Back to Top
    Rate This Entry
  • Back to Top
    What is the relationship between SysML and UML?
    SysML is defined as a dialect (Profile) of UML 2.x, the industry standard modeling language for software-intensive applications. 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-2013 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 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., Communication diagram).

    SYSML DIAGRAM

    PURPOSE

    UML DIAGRAM ANALOG
    Activity diagram
    [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
    [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
    [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
    [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
    [Structural diagram] A Package diagram shows parametric constraints between structural elements. Useful for performance and quantitative analysis.
    [No analogous diagram in UML]
    Requirement diagram
    [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]
    Sequence diagram
    [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
    [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
    [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]
    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


    Back to Top
    Rate This Entry
  • Back to Top
    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 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.

    Back to Top
    Rate This Entry
  • Back to Top
    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.

    Back to Top
    Rate This Entry
  • Back to Top
    Can SysML be used as an Agile Modeling language?
    Yes, SysML is emerging as an attractive alternative to its parent language, UML 2, for 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."

    Back to Top
    Rate This Entry
  • Back to Top
    How can readers submit new questions for this FAQ?
    Please email your questions using the Contact page.

    Back to Top
    Rate This Entry
  • SYSML DIAGRAMS & MODELING TECHNIQUES
  • Back to Top
    What are the "Four Pillars" 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.

    Back to Top
    Rate This Entry
  • Back to Top
    Which SysML diagrams support Agile Modeling or Agile Methods (SCRUM, Crystal, etc.)?
    Answer to be provided.

    Back to Top
    Rate This Entry
  • Back to Top
    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.

    Back to Top
    Rate This Entry
  • Back to Top
    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.

    Back to Top
    Rate This Entry
  • Back to Top
    What is a SysML Use Case diagram and how is it used?
    Answer to be provided.

    Back to Top
    Rate This Entry
  • Back to Top
    What is a SysML Activity diagram and how is it used?
    A SysML Activity diagram shows system functional behavior using a control and data flow model.

    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.

    Back to Top
    Rate This Entry
  • Back to Top
    What is a SysML Block diagram and how is it used?
    Block diagrams, where a Block can represent either a hardware or software component with interfaces, are the basic structural diagrams of SysML. 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.
    Back to Top
    Rate This Entry
  • Back to Top
    What is a SysML Internal Block diagram and how is it used?
    Answer to be provided.

    Back to Top
    Rate This Entry
  • Back to Top
    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-2013 PivotPoint Technology Corp.
    Back to Top
    Rate This Entry
  • Back to Top
    What is a SysML Sequence diagram and how is it used?
    Answer to be provided.

    Back to Top
    Rate This Entry
  • Back to Top
    What is a SysML Package diagram and how is it used?
    Answer to be provided.

    Back to Top
    Rate This Entry
  • Back to Top
    What is the difference between Generalization and Part Association (Composition) relationships?
    Answer to be provided.

    Back to Top
    Rate This Entry
  • Back to Top
    What is the difference between Part Association ("black diamond") and Shared Association ("white diamond") relationships?
    Answer to be provided.

    Back to Top
    Rate This Entry
  • Back to Top
    What is a "cross-cutting" relationship in SysML and how is it used?
    Answer to be provided.

    Back to Top
    Rate This Entry
  • Back to Top
    How can you define Requirements traceability across SysML diagram types?
    Answer to be provided.

    Back to Top
    Rate This Entry
  • Back to Top
    How can you combine a SysML and UML model of the same software-intensive system?
    Answer to be provided.

    Back to Top
    Rate This Entry
  • SYSML TOOLS & INTEROPERABILITY
  • Back to Top
    What SysML modeling tools are available?
    You can find a selected list of both commercial and FOSS (Free & Open Source Software) SysML tools that are available on the SysML Tools page.

    Back to Top
    Rate This Entry
  • Back to Top
    How should I select a SysML modeling tool for my project or team?
    Since the needs of MBSE projects and teams tend to be unique, the answer to this question will vary based on your project and team requirements. However, you can find general advice regarding SysML modeling tool selection on the SysML Tools web.

    Back to Top
    Rate This Entry
  • Back to Top
    What evaluation criteria should I use for SysML modeling tool selection?
    Since the needs of MBSE projects and teams tend to be unique, the answer to this question will vary based on your project and team requirements. However, you can find an example of weighted SysML tool evaluation criteria on the SysML Tools web.

    Back to Top
    Rate This Entry
  • Back to Top
    What is the difference between SysML compliance and conformance?
    In order to answer this question, we should first distinguish between the terms compliance and conformance as they relate to industry standards, since these terms are frequently conflated.

    Standards compliance is an informal industry term which indicates that a system or product provides at least partial support to a particular industry standard, but this partial support is typically not subjected to formal testing. In contrast, conformance is a more formal industry term which indicates that a system or product provides full support for a particular industry standard, where the conformance can be verified by formal testing. From these definitions it should be clear that compliance, which is loosely defined, is much easier for a vendor to claim than conformance, which should be subject to formal testing by a neutral third party, such as an international standards organization.

    Re OMG SysML compliance: The OMG SysML specification (see OMG SysML v. 1.2, Chapter 5) defines three compliance levels that reference both UML 2 metamodel baseline (UML4SysML) Packages and the SysML (Profile) Extension Packages that customize UML2 syntax and semantics for the SysML dialect. In addition, compliance for any given level can be further refined by three sub-classifications: compliance by abstract syntax (metamodel compliance), compliance by concrete syntax (notational compliance), and abstract syntax with concrete syntax compliance. Although vendors of OMG SysML compliant systems or products appear to be expected to offer documentation that describes specific OMG SysML compliance levels, this does not yet appear to be a common practice.


    Until recently, the OMG did not provide a standard test suite to formally and objectively test OMG SysML compliance; it was left up to SysML tool vendors to informally and subjectively provide their own documentation to describe their product compliance level. It should nor be surprising then, that many SysML tool vendors claim some sort of "OMG SysML support" but SysML language implementations are frequently inconsistent, and model interoperability is generally dysfunctional. However, in December 2011 six tool vendors participating in the OMG Model Interchange Working Group (MIWG) announced the public availability of a test suite and test case results that demonstrate UML and OMG SysML model interchange capability using the XML Metadata Interchange (XMI) standard. Information on the test suite is available at the MIWG Wiki.

    Given the past track records of SysML and UML tool vendors, it is too early to assume that SysML and UML tool interoperability problems have been completely resolved. However, SysML users are encouraged to perform their own due diligence regarding SysML tool interoperability by performing their own pragmatic tests. (For example, draw or borrow a medium-size OMG SysML model with a tool claiming OMG SysML compliance, export it using the OMG XMI interchange format, and attempt to import the exported XMI file into another competitive SysML tool that claims comparable OMG SysML compliance. If you can successfully import into the competitive tool without significant loss of information, you have confirmed interoperability.) You can inform the OMG about any concerns that you have regarding OMG SysML compliance, conformance, or any other technical issue by sending email to issues@omg.org.

    Back to Top
    Rate This Entry
  • Back to Top
    What is SysML certification, and how is it related to compliance and conformance?
    In order to answer this question, we must first distinguish between certification of products vs. certification of practitioners or users. In the context of international standards, product certification indicates that an accredited institution, such as an international standards body, affirms that a product complies or conforms with a specification standard. Achieving product certification generally requires that a product passes a formal testing process with a rigorous test suite. However, practitioner or user certification indicates that an accredited institution affirms that a practitioner of a standard has been tested to demonstrated knowledge or competency applying the subject standard.

    Re OMG SysML tool certification: Although the OMG does not yet formally certify OMG SysML tool compliance or performance, it has formed an informal working group to test OMG SysML compliance levels.

    Re OMG SysML practitioner certification: The OMG has established a certification program, the OMG-Certified Systems Modeling Professional™ (OCSMP™), that tests four levels of SysML modeling knowledge. You can find out more about the OCSMP certification from the OCSMP web page.

    Back to Top
    Rate This Entry
  • Back to Top
    Where can I find a Visio template ("stencil") for SysML?
    You can download free Visio templates and stencils for OMG SysML v. 1.0 from the SysML page of the "Software Stencils" web.

    This page includes SysML templates for Visio 2000, Visio 2002, Visio 2003, and Visio 2003, but as of this writing these SysML templates have not yet been updated to support the current version of OMG SysML, version 1.2.

    Caveat Modeler: While these free SysML Visio templates may be a quick and inexpensive way for you and your Systems Engineering team to start SysML modeling, you should be clear that there is a fundamental difference between slick SysML drawing tools that are clueless about SysML's notational and semantic well-formedness rules, and executable SysML modeling tools that enforce SysML's well-formedness rules, model management, and model executability (e.g., simulation, code generation, parametric constraint evaluation). Between these two SysML modeling tool choice extremes, the free SysML Visio templates cited above fall into the former category, whereas there are several bona fide SysML modeling tools that fall into the latter category. Stated otherwise, it is relatively easy to draw ill-formed and even non-sensical SysML diagrams with the free Visio templates if you are not yet fluent in the SysML language.

    You can find general advice regarding SysML modeling tool selection on the SysML Tools web.

    Back to Top
    Rate This Entry
  • Back to Top
    What does it mean for a SysML model or a SysML tool to be "executable"?
    Among visual modeling tools "executable" an umbrella term that describes one of several kinds of dynamic translation from a visual model:

    1) forward engineering (a.k.a. code generation): Forward engineering refers to the translation of a model into programming code that can be compiled and executed on a computer. In the case of SysML, several SysML modeling tools are capable of generating Object Oriented Programming Language (OOPL) code from SysML models or models in SysML's parent dialect (UML).
    2) model simulation (a.k.a. ModSim): Modeling simulation refers to the controlled interpretation of a behavioral model in discrete steps in order to imitate the behavior of the subject system. In the case of SysML, several behavioral diagrams are capable of simulation (State Machine, Activity, and Sequence diagrams), and several SysML modeling tools support model simulation either directly (within the modeling tool) or indirectly (via 3rd party plugins).
    3) constraint evaluation (a.k.a., constraint propagation, constraint enforcement): Constraint evaluation refers to the application of constraints or rules to a model in order to restrict its structure or behavior. Parametric diagrams are capable of parametric constraint evaluation, and several SysML modeling tools support parametric constraint evaluation either directly (within the modeling tool) or indirectly (via 3rd party plugins).

    You can find our more about executable SysML modeling tools on the SysML Tools web.

    Back to Top
    Rate This Entry
  • Back to Top
    Can I generate Java (or some other OO programming language) code from a SysML modeling tool?
    The answer to this question is SysML modeling tool dependent. There is at least one commercial SysML modeling tool that allows you to generate Object-Oriented Programming Language code directly from a SysML model. Other SysML modeling tools may require you to first translate your SysML model into UML, SysML's parent language, before generating code.

    From a methodology perspective the counterpoint to this question is: "Should I generate Java (or some other OO programming language code) from a SysML modeling tool?" While some methodologists may balk at the thought, it is clear that some modelers are finding that SysML is a "smaller, gentler UML 2" and are using it as such. Consequently, there should be no surprise that some modelers are finding new usages for SysML, such as code generation.

    Back to Top
    Rate This Entry
  • Back to Top
    Why can't I interchange SysML models between different SysML modeling tools?
    Since most SysML tools claiming OMG SysML compliance are being implemented as UML 2.x Profiles, they are dependent upon the UML 2.x XMI (XML Metadata Interchange) standard format for interoperability. While the XMI standard purports to facilitate the interchange of SysML/UML models, it has been largely ineffective in practice. There are at least two technical reasons for this. First and foremost, XMI attempts to solve a technical problem far more difficult than exchanging UML models; it attempts to provide a mechanism for facilitating the exchange of any language defined by the OMG's Metamodel Object Facility (MOF). Secondly, the UML 2.x Diagram Interchange specification lacks sufficient detail to facilitate reliable interchange of UML 2.x notations between modeling tools. Since SysML is a visual modeling language, this shortcoming is a showstopper for many modelers who don't want to redraw their diagrams.

    There are some indications that this unfortunate situation may be improving; see the answer to the What is the difference between SysML compliance and conformance? FAQ for further details. Keep in mind that you can communicate issues regarding OMG SysML interoperability, or any other OMG SysML problem, to the OMG by sending email to issues@omg.org.

    Back to Top
    Rate This Entry
  • Back to Top
    ADVANCED SYSML TOPICS
    Back to Top
    Rate This Entry
  • Back to Top
    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 Processes page.

    Back to Top
    Rate This Entry
  • Back to Top
    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.

    Back to Top
    Rate This Entry
  • Back to Top
    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 figure below.

    Package Constructs

    Package Constructs

    Reproduced by Permission © 2003-2013 PivotPoint Technology Corp.




    Back to Top
    Rate This Entry
  • Back to Top
    What is relation between a View and a ViewPoint?
    A 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-2013 PivotPoint Technology Corp.



    Back to Top
    Rate This Entry
  • Back to Top
    What is relation between a View and a Subsystem?
    Answer to be provided.

    Back to Top
    Rate This Entry
  • Back to Top
    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.
    Back to Top
    Rate This Entry
  • Back to Top
    Can SysML be customized by vendors or users?
    Yes, SysML can be customized by both vendors and users with the Profile mechanism it borrows from its UML parent. It is anticipated that SysML will be customized to model more domain-specific applications, such as automotive, aerospace, communications and transportation systems.

    Back to Top
    Rate This Entry
  • Back to Top
    Will there be other variations or dialects of the SysML?
    Since the SysML has been developed by an open source project, and includes an open source license for its distribution and use, others can freely modify, use and redistribute the SysML specification as long as they follow the conditions in the license. For example, the OMG adopted a variation of the SysML open source specification that they trademarked as "OMG SysML." Others may do the same as long as they follow the open source license for distribution and use.

    Back to Top
    Rate This Entry
  • Back to Top
    What is the roadmap for a SysML 2.0 major revision?
    The "OMG SysML Roadmap" section of the OMG SysML 1.2 specification stops with the OMG SysML 1.2 entry. Hopefully, the OMG is planning further ahead than this and is considering an OMG SysML major revision that will address some of SysML 1.x's significant shortcomings. Keep in mind that you can communicate your own OMG SysML issues to the OMG by sending email to issues@omg.org.

    Back to Top
    Rate This Entry