SysML ForumEverything related to SysML

Everything related to SysML

Unified Modeling Language, UML, and OMG SysML are trademarks of the Object Management Group. All other product and service names mentioned are the trademarks of their respective companies.

Back to Top

Q: How mature is OMG SysML 1.x?


A: 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:
  • 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.
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