SysML 2.0 Formalism: Semantics Introduction, Requirements & Benefits/Use Cases Formalism WG March 21, 2017.

Slides:



Advertisements
Similar presentations
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Advertisements

Modelling Class T05 Conceptual Modelling – Domain References: –Conceptual Modeling of Information Systems (Chapters 1.2.1, 2, 3) –A practical Guide to.
Chapter 3 Data Modeling Copyright © 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 2.
Object-Oriented Analysis and Design
Train Control Language Teaching Computers Interlocking By: J. Endresen, E. Carlson, T. Moen1, K. J. Alme, Haugen, G. K. Olsen & A. Svendsen Synthesizing.
UML CASE Tool. ABSTRACT Domain analysis enables identifying families of applications and capturing their terminology in order to assist and guide system.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Syntax & Semantic Introduction Organization of Language Description Abstract Syntax Formal Syntax The Way of Writing Grammars Formal Semantic.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
A Z Approach in Validating ORA-SS Data Models Scott Uk-Jin Lee Jing Sun Gillian Dobbie Yuan Fang Li.
Introduction to MDA (Model Driven Architecture) CYT.
Agenda 1. Introduction 2. Overview of SU-MoVal 3. OCL-based Model Validation 4. QVT-based Transformations 5. Demo of SU-MoVal 6. Conclusion and Future.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
Specializing and extending the UML
1 UML Basic Training. UML Basic training2 Agenda  Definitions: requirements, design  Basics of Unified Modeling Language 1.4  SysML.
Chapter 7 System models.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
TextBook Concepts of Programming Languages, Robert W. Sebesta, (10th edition), Addison-Wesley Publishing Company CSCI18 - Concepts of Programming languages.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
UML Use Case Diagramming Guidelines. What is UML? The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing,
Fall 2010 CS4310 Requirements Engineering A Brief Review of UML & OO Dr. Guoqiang Hu Department of Computer Science UTEP 1.
Integrating SysML and OWL2 (only the static part of SysML Block Diagrams) October 2009 Henson Graves Lockheed Martin Aeronautics.
Programming Languages and Design Lecture 3 Semantic Specifications of Programming Languages Instructor: Li Ma Department of Computer Science Texas Southern.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
© 2000 Franz Kurfess System Design Methods 1 CSC 205: Software Engineering I Dr. Franz J. Kurfess Computer Science Department Cal Poly.
International Workshop 28 Jan – 2 Feb 2011 Phoenix, AZ, USA Ontology in Model-Based Systems Engineering Henson Graves 29 January 2011.
Modeling Formalism Modeling Language Foundations System Modeling & Assessment Roadmap WG SE DSIG Working Group Orlando – June 2016.
Defects of UML Yang Yichuan. For the Presentation Something you know Instead of lots of new stuff. Cases Instead of Concepts. Methodology instead of the.
1 Modeling Formalism (Modeling Language Foundations) System Modeling Assessment & Roadmap Working Group Meeting – SE DSIG Reston – March, 2016 Yves BERNARD.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
SysML v2 Formalism Requirements Formalism WG September 15, 2016.
Language = Syntax + Semantics + Vocabulary
SysML 2.0 Requirements for Visualization
Modeling Formalism Modeling Language Foundations
Describing Syntax and Semantics
Advanced Computer Systems
UNIFIED MEDICAL LANGUAGE SYSTEMS (UMLS)
Systems Engineering Concept Model (SECM) Update
Introduction to Formal Methods
UML Diagrams By Daniel Damaris Novarianto S..
Common MBSE Modeling Questions and How Ontology Helps
Integrating SysML with OWL (or other logic based formalisms)
SysML 2.0 Requirements for Visualization
SysML 2.0 Formalism Requirements and Potential Language Architectures
Course Outcomes of Object Oriented Modeling Design (17630,C604)
SysML 2.0 Formalism: Requirement Benefits, Use Cases, and Potential Language Architectures Formalism WG December 6, 2016.
SysML v2 Formalism: Requirements & Benefits
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Syntactic Requirements
UML Diagrams Jung Woo.
Abstract descriptions of systems whose requirements are being analysed
Daniel Amyot and Jun Biao Yan
Knowledge Representation
SysML 2.0 Concept and Needs for Visualization
Introduction to SysML v.2.0 Metamodel (KerML)
Chapter 2, Modeling with UML, Part 4 UML 2 Metamodel
ece 720 intelligent web: ontology and beyond
Chapter 9 Use Cases.
Chapter 20 Object-Oriented Analysis and Design
Compilers Principles, Techniques, & Tools Taught by Jing Zhang
Overview of the ETSI Test Description Language
Software Architecture & Design
Presentation transcript:

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)

Overview Language Definition Introduction Language Definition Requirements & Benefits/UseCases Language Feature Requirements (Status)

Language Definition = 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) model elements (Engine, Propellor, weight).

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’).

Example: Natural Language Concrete Syntax Verbs appear between nouns subject Langauge Definition Abstract Syntax Verb predicate Sentence Noun object Objects described by nouns are involved in behaviors described by verbs Semantics Model (as CS) (as AS) «lib» Dog Chase predicate subject object chases cat ‘Dog chases cat’ Cat Using the Language «isA» Things Described By Words Fido Fluffy Fido chases Fluffy at 2pm ET March 1, 2017 ‘Operations’ «describedBy» Semantics Applied to Things Being Described Fido and Fluffy are involved in a chasing behavior

Fido chases Fluffy at 2pm ET March 1, 2017 Example: SysML Property names appear at the end of association lines Concrete Syntax Langauge Definition Abstract Syntax type Model (as CS) chases owned attribute Cat Dog «instanceOf» Using the Language (as AS) type Block Property Properties have values on things modeled by their owning block. The values are modeled by the property’s type Semantics ‘Operations’ Things Being Modeled Fido Fluffy Fido chases Fluffy at 2pm ET March 1, 2017 «instanceOf» chases Fido must be a dog and Fluffy must be a cat Semantics Applied to Things Being Modeled

Benefit: Uniform Interpretation Formally defined, eg, Diagram Definition Concrete Syntax Langauge Definition Abstract Syntax Formally defined = about the things being modeled Semantics Using the Language Model «instanceOf» SysML Semantics Interpreting the Language «interprets» «implementedBy» Semantics Applied Manually to Things Being Modeled ‘Operations’ Things Being Modeled

Benefit: Uniform Interpretation (Automated) Formally defined, eg, Diagram Definition Concrete Syntax Abstract Syntax Langauge Definition Formally defined = about the things being modeled Semantics Using the Language Model SysML Semantics ‘Operations’ Things Being Modeled Interpreting the Language «interprets» «controlledBy» Semantics Applied Automatically to Things Being Modeled «implementedBy» By Tooling Built Manually

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)

Overview Language Definition Introduction Language Definition Requirements & Benefits/UseCases Language Feature Requirements (Status)

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 (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: 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.

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 = a thing 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

Benefit: Uniform Interpretation (Automated) subset of Abstract Syntax Langauge Definition Formal Semantics A = B Using the Language Model SysML Semantics «interprets» SysML Semantics Semantics Applied Automatically to Things Being Modeled By Tooling Built Manually «implementedBy» Interpreting the Language «implementedBy» «controlledBy» Things Being Modeled ‘Operations’

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: 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 (FML 3) 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 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 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.

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).

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.

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.

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.

Overview Language Definition Introduction Language Definition Requirements & Benefits/UseCases Language Feature Requirements (Status)

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

Graphical specification of derived properties and relationships 26

Classification vs Capability Features Are block features always available? Classification: No. Capability: Yes. 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. Plane crew : Person [0..*] flown : Flight [0..*] tail# : String ER284H : Plane crew = ? flown = ? tail# = “ER284H” UAV crew : Person [0] ^flown : Flight [0..*] Plane crew : Person [0..*] flown : Flight [0..*] UAV crew : Person [0] ^flown : Flight [0..*] FlownPlane ^crew : Person [0..20] flown : Flight [1..*] UnflownPlane ^crew : Person [0..20] flown : Flight [0]

Figure 9.15 - Usage example of item flows in internal block diagrams Item Flow Example Figure 9.15 - Usage example of item flows in internal block diagrams Modeler thought the upper right item flow meant any fluid could flow (capability), not just water, as indicated by the flow properties. http://issues.omg.org/browse/SYSMLR-328 It’s actually only a classification.

Figure 9.16 - Usage example of item flow decomposition Item Flow Example Figure 9.16 - Usage example of item flow decomposition Only pistons, crankshafts, and cams flow, not any engine part.

Logic Modeling Results Graphical Logic Modeling Benefits

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.

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.

Questions/Comments?