NextGenSysML Part 3 – Language Architecture and Formalism Requirements
This blog post presents the SysML v2 language architecture and formalism requirements. The previous blog post gave an overview of the general requirements on proposals for OMG Request for Proposals (RFP). Following blog posts present details of specific sections of the RFP’s.
A fundamental concept of a modeling language architecture is the metamodel. It defines the concepts of the language. For example, the following figure depicts a simplified extract of the UML metamodel.
The figure shows the definition of the UML model elements Actor, Class, and UseCase. All are specializations of the abstract concept BehavioredClassifier. They inherit beside others the capability to own a behavior element. A typical example is a UseCase that owns an Activity to specify the control and object flow of the use case steps.
Another capability inherited from the BehavioredClassifier is the rectangle notation. You probably know that rectangles in a diagram depict classes. However, also Actors and UseCases can be depicted by rectangles instead of sticky people or ellipse notation. In the UML specification document, you find much more detailed and of course complete metamodel specifications.
SysML v1 uses the profile/stereotypes extension mechanism to define the SysML model elements as an extension of UML. For example, the next figure depicts the definition of the SysML Block element. It is a stereotype extending the UML Class element. Of course, the SysML specification contains a more detailed definition of the Block element with constraints, semantics, and notation specifications.
The following figure shows the relationship between SysML v1 and UML. SysML v1 is a profile of UML. The StandardProfile is part of the UML specification and defines some common stereotypes. SysML also uses it.
Actually, SysML v1 imports only a subset of UML called UML4SysML, and not the complete UML metamodel.
A significant innovation of SysML v2 compared to SysML v1 is that it does not require being a profile of UML anymore. Literally, the requirements state:
Proposals for SysML v2 shall be specified using a metamodel that includes abstract syntax, concrete syntax, semantics, and the relationships between them.
and
Proposals for the SysML v2 metamodel shall be specified in MOF or SMOF.
The requirements open the solution space for SysML v2. It still can be again a UML profile, but also a modeling language with a complete new metamodel independent of UML.
In any case, it must be based on the Meta Object Facility (MOF) respectively the MOF Support for Semantic Structures (SMOF). MOF is the basis of all OMG modeling languages. The SysML Submission Team (SST), i.e., the team that currently works on the new SysML v2 specification, works on a new metamodel independent of UML. That enables implementations of system concepts in SysML without constraints imposed by the UML metamodel. For example, the SysML v1 model elements Allocate and ElementGroup have some issues due to the underlying UML metamodel.
A non-mandatory requirement for SysML v2 states that model libraries shall define the SysML v2 semantic. They extend the base declarative semantic. This language architecture also simplifies the user-specific extension the language. Instead of using stereotypes you can extend the language defining model library elements.
Another non-mandatory requirement asks for SysML v2 semantics defined using mathematical logic. The correctness of a model can be proofed by mathematical proofs instead of executing the model.
Also, a non-mandatory requirement specifies that a subset of the SysML v2 semantics shall be complete and decidable.
In addition to the SysML v2 metamodel, the RFP also asks for a SysML v2 UML profile:
Proposals for SysML v2 shall be specified as a SysML v2 profile of UML that includes, as a minimum, the functional capabilities of the SysML v1.x profile, and a mapping to the SysML v2 metamodel.
The SysML v2 profile can only provide a subset of the SysML v2 metamodel capabilities because the underlying UML constrains it. The purpose of the SysML v2 profile is to enable a broader range of vendor implementations and offer a migration path from SysML v1 models via SysML v2 profile models to SysML v2 metamodel models.
Speaking of migration, SysML v2 shall also provide a mapping to UML for concepts shared by both modeling languages.
The definition of a modeling language consists of three main pillars: abstract syntax, concrete syntax, and semantic. The semantic defines the meaning of a model element, and the concrete syntax defines the notation. The abstract syntax defines the structure of the model element. If you are a computer scientist, you know that the view depends on the data, but the data shall not depend on the view. The same is required for SysML v2, i.e., the abstract syntax shall not depend on the notation (concrete syntax). Thus, in addition to the standardized SysML diagrams, any other user-specific view can be used.
The views standardized by SysML v2 must provide an unambiguous mapping to the abstract syntax as well as examples given in the specification.
Although the diagrams, i.e., graphical views, play an essential role in modeling, it is sometimes useful to edit or view model data textually. A non-mandatory requirement for SysML v2 asks for a textual SysML notation. The combination of graphical and textual SysML editors and viewers makes it a powerful engineering environment for multiple purposes. The Action Language for Foundational UML (Alf) is a potential candidate for the textual notation. Of course, Alf must be extended and modified for SysML v2.
SysML is a general-purpose modeling language for systems engineering and does not cover any specialties of a domain like space or avionics, or a methodology like SYSMOD, OOSEM, or Harmony. In practice, you must customize SysML for your specific needs. It cannot be used effectively out-of-the-box as the primary language in an MBSE environment.
SysML v1 provides the profile and stereotype model elements to extend the language. SysML v2 shall also include a mechanism to subset and extend the syntax and semantics. Instead of a profile/stereotype mechanism, the extension could be done by model libraries (see above).
The exchange of model between different modeling tools was a challenge from the beginning of SysML (and UML). It is time to resolve that issue. SysML v2 may provide a format for interchanging the abstract and concrete syntax (notation, diagrams) representation of a model. This is only a non-mandatory requirement, but the SST team has a strong focus on it and will provide a model exchange capability.
The exchange of models often requires a mapping of model elements from one format to another — for example, the import or export of the model data from or to Excel. A non-mandatory requirement states that SysML v2 may provide a capability to specify model mappings and transformations.
The next blog post covers the cross-cutting requirements that apply to all model elements like a unique identifier, groupings, or several general relationships between model elements. Stay tuned!
Previous blog posts of this series:
- NextGenSysML Part 0 – Next Generation Modeling: SysML v2 and SysML API & Services – Introduction
- NextGenSysML Part 1 – Overview SysML v2 and SysML API & Services RFP’s
- NextGenSysML Part 2 – The General OMG Requirements
Planned future blogs posts:
- NextGenSysML Part 4 – Cross-cutting Requirements
- NextGenSysML Part 5 – Properties, Values & Expressions Requirements
- NextGenSysML Part 6 – Structure Requirements
- NextGenSysML Part 7 – Interface Requirements
- NextGenSysML Part 8 – Behavior Requirements
- NextGenSysML Part 9 – Requirements Requirements
- NextGenSysML Part 10 – Verification Requirements
- NextGenSysML Part 11 – Analysis Requirements
- NextGenSysML Part 12 – Example model and Conformance Requirements
- NextGenSysML Part 13 – SysML API & Services Overview
- NextGenSysML Part 14 – SysML API & Services: Architecture and Conformance Requirements
- NextGenSysML Part 15 – SysML API & Services: Service Requirements
