SysML FAQ: What are the pros & cons of SysML as a architecture modeling language for MBSE applications?

Language bloat.

Increase of UML 2.x voodoo semantics.

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

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

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

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

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

The semantics and notations for StandardPorts, FlowPorts, Provided & Required Interfaces, and ItemFlows were gratuitously complex and confusing in SysML v. 1.0 - 1.2, since they conflated dependency relationships with flow relationships. Unfortunately, the patches made to fix these problems with new constructs in the SysML v. 1.3 minor revision (FullPorts, ProxyPorts, InterfaceBlocks) have exacerbated these problems, rather than fix them. Although Instance Specifications were recently added to SysML 1.2, Object diagrams were not, and many issues remain about their specialized usage within SysML. • Recommendations: Unify, simplify, and clarify the Physical and Information Interface syntax and semantics in the next major revision, SysML 2.0.

Although Instance Specifications were recently added to SysML 1.2, Object diagrams are clearly an afterthought in the language, and have never been fully integrated with the rest of SysML. • Recommendations: Add Object diagrams as a first-class SysML diagram type, and clarify the similarities and differences between SysML and UML Instance Specification syntax, semantics, and usages.

Parametric Constraint Blocks and Constraint Properties are ambiguously defined and poorly integrated with other SysML structural diagrams. The currently have the dubious distinction of being the least mature and most problematic SysML diagram to use. • Recommendations: Parametric Diagrams need a complete overhaul in the next SysML major revision (SysML 2.0). This overhaul should factor in lessons learned from building bi-directional bridges between SysML 1.x Parametric diagrams and 3rd-party mathematical modeling & simulation tools (e.g., MATLAB/Simulink, Mathematica).

Requirement constructs are incomplete and confusing.

Problems associated with Requirement diagrams include, but are not limited to, clarifying decomposition/containment semantics, categorization, defining basic properties, clarifying relationship semantics, and reducing the semantic overlap with Use Cases. • Recommendations: Replace Containment with Composition for Requirements decomposition. Retire Copy dependency. Provide additional Requirement properties for source, priority, risk, verifyMethod, etc.

Allocation relationships and tables are incomplete and ambiguous.

With the exception of the AllocateActivityPartition stereotype, the current specification fails to leverage the architectural integrity allocations of its parent language. In addition, the definitions of the Allocate and Allocated stereotypes strongly suggest conflated dependency and flow semantics, which are indicative of novice UML modelers ("which way does the arrow point?"). • Recommendations: Replace Allocate dependencies with flows that use distinctive notation (not dashed arrows labeled with keywords). Require that implementations automatically generate Allocate dependencies for AllocateActivityPartitions.

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

The current usage of ValueTypes with Units and QuantityKinds (formerly Dimensions) and their integration with UML DataTypes needs to be clarified and simplified. • Recommendations: Simplify and predefine a standard SysML ValueType model library based on International System of Units (SI) standards.