Download SysML 2 RFP

SysML 2.0 Formalism:
Semantics Introduction,
Requirements & Benefits/Use Cases
Formalism WG
March 21, 2017
Overview
• Language Definition Introduction
• Language Definition Requirements & Benefits/UseCases
• Language Feature Requirements (Status)
2
Overview
• Language Definition Introduction
• Language Definition Requirements & Benefits/UseCases
• Language Feature Requirements (Status)
3
Language Definition =
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) model elements (Engine, Propellor, weight).
4
Example: Natural Language
• Syntax = grammar
• Concrete: Verbs appear between nouns (in English)
• Abstract: ‘Verb’, ‘Noun’, ‘subjectNoun’, ‘objectNoun’.
• Interchange/API: UNICODE
• Semantics
• Verbs between nouns => Objects described by the nouns are
involved in behaviors described by the verbs.
• Vocabulary (dictionary) = words
• Particular nouns (‘mountain’, ‘road’) and verbs (‘climb’, ‘drive’).
5
Verbs appear
between nouns
subject
Abstract
Syntax
Verb
predicate
Sentence
object
Noun
Objects described by nouns
are involved in behaviors
described by verbs
Concrete
Syntax
Semantics
‘Operations’
Using the
Language
«isA»
Langauge
Definition
Example: Natural Language
Model
(as AS)
subject
«lib»
Chase
predicate
Dog
chases cat
«lib»
‘Dog chases cat’
Dog
object «lib»
Cat
Fido and Fluffy
are involved in a
chasing behavior
Things
Described
By Words
Fido
Model
(as CS)
Semantics
Applied
to Things
Being
Described
Fluffy
Fido chases Fluffy at 2pm ET March 1, 2017
6
‘Operations’
Abstract
Syntax
type
Block
«instanceOf»
Using the
Language
Langauge
Definition
Example: SysML
Model
(as AS)
Dog
owned
attribute
owned
attribute
Property names
appear at the end of
association lines
Property
chases
Properties have values on things
modeled by their owning block. The
values are modeled by the property’s type
type
Dog
chases
Cat
Cat
Fido must be a
dog and Fluffy
must be a cat
Things
Being
Modeled
Fido
Concrete
Syntax
Semantics
Model
(as CS)
Semantics
Applied
to Things
Being
Modeled
Fluffy
Fido chases Fluffy at 2pm ET March 1, 2017
7
Formally defined, eg,
Diagram Definition
Abstract
Syntax
Concrete
Syntax
Semantics
Model
Interpreting the
Language
‘Operations’
Formally defined
= about the things
being modeled
«instanceOf»
Using the
Language
Langauge
Definition
Benefit: Uniform Interpretation
SysML Semantics
Semantics Applied
Manually to Things
Being Modeled
Things
Being
Modeled
8
Model
Formally defined, eg,
Diagram Definition
Formally defined
= about the things
being modeled
SysML
Semantics
«interprets»
Langauge
Definition
Abstract
Syntax
Using the
Language
Benefit: Uniform Interpretation (Automated)
Things
Being
Modeled
Semantics
Semantics Applied
Automatically to Things
Being Modeled
By Tooling Built Manually
«controlledBy»
‘Operations’
Interpreting the
Language
SysML
Semantics
Concrete
Syntax
9
Informal Semantics
• Syntactic metaphors that suggest formal semantics
• Inheritance (suggesting generalization semantics)
• Token flow (suggesting temporal semantics)
• Shorthand expansions
• Property means property of a block (instead of property
semantics).
• Application/methodology
• Requirement, design, test (instead of classification semantics)
10
Overview
• Language Definition Introduction
• Language Definition Requirements & Benefits/UseCases
• Language Feature Requirements (Status)
11
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).
12
Everyone = Modelers, teachers, consultants, spec writers, modeling / execution / analysis tool builders
Requirements Review (FML 1)
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:
1) 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.
2) 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
13
concepts better.
Mathematical Logic Example
UML Generalization
From UML 2.5 Specification:
Vehicle
“Every instance of car is
an instance of vehicle”
Car
How can this be specified more precisely?
Mathematical Logic Example
OWL SubClassof
subset of
Vehicles
SubClassOf(Car, Vehicle)
Cars
From OWL 2 Direct Semantics:
CE denotes a class expression;
⋅ C is the class interpretation function that assigns to each class C ∈ VC a subset (C)C ⊆ ΔI
= a thing
Langauge
Definition
Abstract
Syntax
Using the
Language
Benefit: Uniform Interpretation (Automated)
Model
subset of
=
SysML
Semantics
«interprets»
B
Things
Being
Modeled
SysML
Semantics
B
Formal
Semantics
Semantics Applied
Automatically to Things
Being Modeled
By Tooling Built Manually
«controlledBy»
Interpreting the
Language
‘Operations’
A
A
16
Requirements Review (FML 2)
SysML 2.0 semantics shall be modeled in domain-independent SysML
2.0 model libraries that are automatically used when models are
created.
Benefits:
1) Makes the mathematical semantics of S1 accessible to non-mathematicians.
2) Simplifies the language when model libraries can be used without additional
abstract syntax (reduces the amount of abstract syntax).
3) Enables SysML to be improved and extended more easily by changes and
additions to model libraries, rather than always through abstract syntax.
17
Requirements Review (FML 3)
SysML 2.0 abstract syntax shall be independent of notation.
Benefits:
1) 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.
2) Simpler model and tool construction: Sometimes the same notion has
multiple standard notations in SysML, such as temporal precedence in
interations, 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
18
models (model checking, execution/simulation, analysis).
Requirements Review (FML 4)
SysML 2.0 syntax shall be modeled formally (including 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.
19
Requirements Review (FML 5)
Any SysML 2.0 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).
Benefits:
Enables diagrams to look the same across tools, at least for those aspects that
modelers control (e.g., node positioning and line routing).
20
Requirements Review (FML 6)
All examples of notation in the SysML 2.0 specification shall be
accompanied by instances of the syntax models.
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.
21
Requirements Review (FML 7)
Where SysML 2.0 is extensible, the syntax, semantics, and 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.
22
Requirements Review (FML 8)
SysML 2.0 syntax shall be specified in a subset of SysML 2.0.
Benefits:
Enables SysML to be defined, implemented, and extended without learning a
separate language.
23
Overview
• Language Definition Introduction
• Language Definition Requirements & Benefits/UseCases
• Language Feature Requirements (Status)
24
Language Features Requirements
• Requirements on the language itself rather than how it is
defined.
• Inspired by formal approaches.
• Currently considering:
• Graphical specification of derived properties and relationships
• Distinguish classification vs capabilities
• Learning curve reduction & model sketching
• Logic modeling
25
Graphical specification of derived properties
and relationships
26
26
Classification vs Capability Features
• Are block features always available?
• Classification: No.
• Capability: Yes.
Plane
crew : Person [0..*]
flown : Flight [0..*]
tail# : String
• If I have a plane with tail # “ER284H”, can it be
• given a crew? Maybe, if it’s not an UAV.
• flown? Yes, otherwise it’s not a plane.
ER284H : Plane
crew = ?
flown = ?
tail# = “ER284H”
UAV
crew : Person [0]
^flown : Flight [0..*]
Logic Modeling
Results
Graphical Logic Modeling
Benefits
30
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.), while
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 (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.
31
Formalism Use Cases (Hybrid SUV)
• Engineers for the Hybrid SUV acquire a model for a component they
would like to use with their design. The documentation references
the verification of the design obtained by using reasoning tool that
the engineers do not have. When the engineers download the model
and integrate it with theirs, they know any inconsistencies found by
their own reasoners are not due to flaws internal to the component’s
design.
32
Questions/Comments?
33