1. SysML v2 Formalism Requirements Formalism WG September 15, 2016

2. Overview Driving Requirements Background on Formalism Formalism Requirements

3. Overview Driving Requirements Background on Formalism Formalism Requirements

4. Driving Requirements Specification shall – Include precise semantics that reduces ambiguity and enables concise representation of the concepts. – Derive language from a well-specified logical formalism that can leverage the model for a broad range of analysis and model checking.

5. Analysis and Model Checking Broad range of analysis and model checking, including: – Validating that the model is logically consistent, answering questions such as the impact of a requirement or design change, or assess how a failure could propagate through a system. – Enabling integration with a diverse range of equation solvers, provers, and execution environments, including for quantitative data.

6. Overview Driving Requirements Background on Formalism Formalism Requirements

7. Language = Syntax + Semantics + Vocabulary Syntax – 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. 7

8. Language Specifications Language Specification SyntaxSemantics Concrete Interchange/ API Graphical Textual Operational Declarative Abstract Model Theoretic / Denotational Vocabulary / Libraries Application Independent Application Dependent 8

9. Overview Driving Requirements Background on Formalism Formalism Requirements

10. 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 – Everyone looking at SysML diagrams should Reach the same conclusions about the things being modeled. Including whether it is possible to draw any conclusions at all (consistency). 10

11. Who’s “Everyone”? Modelers, teachers, consultants, spec writers. – They understand each others’ models the way the authors intended. Modeling tool builders – Their tools instantiate abstract syntax the same way (MIWG) for all diagrams. Analysis tool builders – Their tools produce same results for all instances of abstract syntax. 11

12. Syntactic Requirements (Specific) Abstract syntax and library specifications – Shall be notation-independent. Concrete syntax specification – Shall include model and interchange/API for diagram/text information that is not included in abstract syntax, but linked to abstract syntax (eg, DD’s DI/DG). – All examples shall be accompanied by a model for them, as above. 12

13. Semantic Requirements (Specific) Semantics shall be: – expressed in mathematical logic – or a translation to mathematical logic. Semantics shall be modelled: – Shall include domain-independent model libraries. – Abstract syntax shall specify patterns of (automatically) using library elements with instances of abstract syntax. 13

14. Mathematical Logic Example From UML 2.5 Specification: UML Generalization How can this be specified more precisely? Vehicle Car “Every instance of car is an instance of vehicle”

15. Mathematical Logic Example OWL SubClassof From OWL 2 Direct Semantics: CE denotes a class expression; ⋅ C is the class interpretation function that assigns to each class C ∈ V C a subset (C) C ⊆ Δ I Vehicles = a thing Cars subset of SubClassOf(Car, Vehicle)

16. Modeling Semantics Example act TakePicture FocusShoot Modelers see: Modelers mean: “Focus before shooting when taking a picture” How do tool (builder)s know that?

17. Modeling Semantics Example bdd SysML Model Library « activity » TakePicture step1 : Focus : happensBefore happensBefore happens During step2 : Shoot « activity » Activity Occurrence SysML provides a library of temporal relations… …and specifies how tools use it when instantiating the metamodel:

18. Modeling Semantics step2 step1 Focus Meta model owned attribute Class owned action Activity Property Action Take Picture happensDuring -1 Activity Occurrence Shoot Model Library System Model step1 Focus 3/15/09 10-11amET : step2 Shoot 3/15/0911-12pmET : : happensBefore TakePicture step1 : Focus : happensBefore owned attribute owned action Activity Property Action happensBefore happens During Meta model Modeling tools Library of temporal relations…... used to give model semantics step2 : Shoot Class Simulation tools & operators Activity Occurrence TakePicture 3/15/09 10-12pmET : SysML Model Library System Model happens Before happens During Activity Occurrence

19. Semantic and Syntactic Requirements (Specific) Where SysML v2 is extensible, semantics and syntax shall also be extensible.

20. Formalism Requirements: Semantics: 1) SysML v2 shall have at least a declarative semantics expressed in mathematical logic or have a translation to mathematical logic. (Definition: Classically, mathematical logic is considered to be made up of set theory, model theory, recursion theory, proof theory, and construction mathematics (constructivism). In addition, we are also considering category theory and type theory.) ExampleExample 2) Semantics shall be modelled; specifically, SysML v2 shall include domain-independent model libraries, and abstract syntax shall specify patterns of (automatically) using them with instances of abstract syntax. Abstract Syntax: 1) The SysML v2 abstract syntax shall be independent of notation. Concrete Syntax: 1) Any SysML v2 concrete syntax shall include a 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/DG). 2) All examples of concrete syntax in the specification shall be accompanied by a model for them, as above. Semantics and Syntax: 1) If SysML v2 is extensible, the syntax and semantics shall both be extensible. Formalism Feature: 1) SysML v2 shall enable model users to define derived properties and relationships in their models without necessarily using a constraint language. ExampleExample

21. Questions / Comments?

22. Not Used

23. Formalism Feature SysML v2 shall enable modelers to define derived properties and relationships in their models without using a constraint language.

24. Mathematical Logic Example From UML 2.5 Specification: UML Generalization vs. OWL SubClassof From OWL 2 Direct Semantics: CE denotes a class expression; ⋅ C is the class interpretation function that assigns to each class C ∈ V C a subset (C) C ⊆ Δ I Back

25. Modeling Semantics act TakePicture FocusShoot Modeler sees: step1 Focus 3/15/09 10-11amET : step2 Shoot 3/15/0911-12pmET : : happensBefore TakePicture step1 : Focus : happensBefore owned attribute owned action Activity Property Action happensBefore happens During Meta model Modeling tools see: Library of temporal relations…... used to give model semantics step2 : Shoot Class Simulation tools / Operators see: Activity Occurrence TakePicture 3/15/09 10-12pmET :

26. Things Being Modeled Things being modeled: – Cars built (structure) – Driven around (behavior). Compare things being modeled to a model, eg, cars might not – Cars might not be built as model directs. – Might not behave as modeled.

27. Declarative & Operational Semantics Declarative – Tells whether a thing being modeled actually obeys the model. Operational – Creates a thing being modeled that obeys the models (ie, satisfies declarative semantics).

30. Consider these potential approaches to the SysML v2 metamodel foundations: Approaches that Maintain Connection to UML: Use UML without replacing anything -> Profile + equivalent MOF model (extension->generalization & stereotypes->metaclasses). Potentially replace XMI with OWL or RDF (potentially via MOF2RDF). Use UML without changing the metamodel -> Add additional representation of UML/SysML semantics as a mathematical representation (model theory/type theory/category theory/etc.) Otherwise, same as above. Use UML without changing the concrete classes -> specialize UML metamodel from formal language (e.g., OWL, IDEAS Foundations). Treat SysML v2 as a branch of UML -> Similar foundations, but SysML v2 metaclasses replace some UML metaclasses/SysML v1.x stereotypes and open the potential to make changes to the foundations of the UML metamodel.

31. Consider these potential approaches to the SysML v2 metamodel foundations (cont): Approaches that completely break from UML: Brand new everything->Go back to 1989 (‘87 if we reinvent state machine diagrams). Develop a language from the ground up that has concrete syntax that will have mappings to implementations (SysML v2 Language->UML profile, SysML v2 Language->Vitech schema, etc.) Mostly brand new everything -> Derive SysML v2 metamodel from pre-existing non-UML foundations (e.g., OWL 2, IDEAS Foundations, etc.) Focus on abstract syntax/semantics->Leave implementation (concrete syntax) up to vendors, e.g., UML profile, Vitech schema(s), whatever tools that don’t focus on diagrams do, etc.