SysML 2.0 Formalism: Requirement Benefits, Use Cases, and Potential Language Architectures Formalism WG December 6, 2016

Overview Requirements Review Formalism Use Cases Potential Language Architectures

Language = Syntax + Semantics + Vocabulary Concrete: What you see (rectangles, lines, text). Abstract: What you say (“block”, “item flow”) Interchange/API: What computers read/write. Semantics What’s possible to conclude about the things being modeled when using the syntax. Vocabulary (libraries) Predefined syntactic (modeling) elements.

Requirements (General) Uniform syntactic interpretation Everyone looking at SysML diagrams should Describe them the same way (using SysML terminology). Agree on whether they are “legal” SysML (well-formedness). Uniform semantic interpretation Reach the same conclusions about the things being modeled. Including whether it is possible to draw any conclusions at all (consistency). Everyone = Modelers, teachers, consultants, spec writers, modeling / execution / analysis tool builders

Requirements Review (Semantics 1) S1) SysML 2.0 shall have a declarative semantics expressed in mathematical logic and/or other semantics with a translation to declarative semantics in mathematical logic. Benefits: Reduced ambiguity: Semantics expressed in natural language causes miscommunication between users, and diverging implementations. This requirement (combined with S2) enables vendors to build tools for model checking, execution/simulation, and analysis that give the same results for the same models. Then users can learn a consistent SysML semantics by using these services on their models. More integrated language: Some engineering concepts are inherently different but must be integrated, such as structure and behavior. This requires abstractions that apply to both, but are not engineering-specific, i.e. mathematical, enabling SysML to integrate its concepts better.

Requirements Review (Semantics 2) S2) Semantics shall be modeled in SysML; specifically, SysML 2.0 shall include domain-independent model libraries that are automatically used when models are created. Benefits: Makes the mathematical semantics of S1 accessible to non-mathematicians. Simplifies the language when model libraries can be used without additional abstract syntax (reduces the amount of abstract syntax). Enables SysML to be improved and extended more easily by changes and additions to model libraries, rather than always through abstract syntax.

Requirements Review (Abstract Syntax 1) AS1) The SysML 2.0 abstract syntax shall be independent of notation. Benefits: Support non-SysML visualizations: Engineers and project managers need a wide variety of visualizations for information captured in models, including non-SysML graphics, tables, and reports. SysML’s abstract syntax should not inhibit creating these visualizations. Simpler model and tool construction: Sometimes the same notion has multiple standard notations in SysML, such as temporal precedence in interactions, state machines, and activities. The abstract syntax should represent these notions once. This makes is it easier for modelers to keep diagrams consistent and for vendors to construct tools that operate on models (model checking, execution/simulation, analysis).

Requirements Review (Abstract Syntax 2) AS2) The SysML 2.0 abstract syntax shall be modeled formally (including abstract syntactic constraints). Benefits: Reduced ambiguity: Syntax expressed in natural language, such as abstract syntax constraints, causes miscommunication between users, and diverging implementations. This requirement enables vendors to build tools for model construction and checking that give the same results. Then users can learn SysML consistently across tools.

Requirements Review (Concrete Syntax 1) CS1) Any SysML 2.0 concrete syntax shall include a formal model and interchange format/API for diagram/text information that is not included in the abstract syntax, but is linked to the abstract syntax (e.g., DD’s DI). Benefits: Enables diagrams to look the same across tools, at least for those aspects that modelers control (e.g., node positioning and line routing).

Requirements Review (Concrete Syntax 2) CS2) All examples of concrete syntax in the SysML 2.0 specification shall be accompanied by a model for them, as in CS1.  Benefits: The Model Interchange Working Group (MIWG) found that most tool interchange problems were due to differences in translating graphics to instances of abstract syntax. Providing models for all diagrams in the specification will help iron out these differences.

Requirements Review (Extensibility) E1) If SysML 2.0 is extensible, the syntax and semantics (including model libraries) shall all be extensible. Benefits: Language specification includes syntax, semantics, and vocabulary, so extending a language requires all of these to be extensible.

Requirements Review (In Progress) Formalism Features: Requirements for features that the language will support. (e.g., modeling derived relationships/properties, using classification features, etc.). Learning Curve Reduction/Sketching: Currently, a general requirement on the group is to not suggest something that would overly constrain model-users.

Overview Requirements Review Formalism Use Cases Potential Language Architectures

Formalism Use Cases (Hybrid SUV) Engineers identify a set of hazards associated for the vehicle. They capture this material in the system model, along with potential mitigations that are tied to elements of the design. Throughout the design process, the engineers put together analyses (fault trees, formal verification, etc.), and the SME automatically constructs the assurance case arguments (using the hazards, mitigations, analyses and design information tied to the mitigations) which expresses whether or not the system is safe to use. Engineers identify undesirable events (bad combinations of states, actions, interactions, values, etc.) during design and use the SME to automatically generate fault trees to study how they can improve the design to avoid these events.

Formalism Use Cases (Hybrid SUV) Engineers for the Hybrid SUV read a paper about a model constructed for a component of their design. The paper uses a reasoner (though they don’t mention which one) on a model to verify that the design is consistent. When the engineers download the model and integrate it with theirs, they know any inconsistencies found by their own reasoners are not due to the component.

Overview Requirements Review Formalism Use Cases Potential Language Architectures

Architecture Approaches Evaluated Against Formalism Requirements Under each approach we will show how the approach aligns with our requirements using the notation: Y(es) – Satisfies N(o) – Cannot Satisfy M(aybe) – Can Be Satisfied Divided according to whether a connection is maintained to UML.

Approaches That Maintain UML Connection (1) Use UML without changes or additions. Potentially use MEF or MOF instead of stereotypes and/or replace XMI with OWL or RDF textual syntax (e.g., via MOF2RDF). S1: N S2: N AS1: N AS2: M CS1: Y CS2: M E1: N

Approaches That Maintain UML Connection (2) Use UML without changes, but add mathematical and model library representation of UML/SysML semantics, and potential changes to extension mechanism and interchange format as in #1. S1: Y S2: Y AS1: N AS2: M CS1: Y CS2: M E1: Y

Approaches That Maintain UML Connection (3) Use UML without changing the concrete classes, but refactoring and specializing UML metamodel from (metamodel of) formal language (e.g., OWL, IDEAS, DOLCE), plus changes in #2. S1: Y S2: Y AS1: M AS2: M CS1: Y CS2: M E1: Y

Approaches That Maintain UML Connection (4) Treat SysML as a branch of UML. New/updated SysML metaclasses would replace some of UML / SysML 1.x, plus changes in #2. S1: Y S2: Y AS1: M AS2: M CS1: M CS2: M E1: Y

Approaches That Break From UML (5) Develop a new language from the ground up (abstract and concrete syntax, and textual, mathematical, and modeled semantics) with a mapping to a UML profile. S1: Y S2: Y AS1: M AS2: M CS1: M CS2: M E1: Y

Approaches That Break From UML (6) Same as #5 (completely new language), but keep the current SysML/UML concrete syntax. S1: Y S2: Y AS1: M AS2: M CS1: M/Y CS2: M E1: Y

Approaches That Break From UML (7) Same as #5 (completely new language), but do not standardize concrete syntax. S1: Y S2: Y AS1: M AS2: M CS1: N CS2: N E1: Y

Questions/Comments?