Eine Architektur-DSL zur Beschrei- bung und formalen Verifika@on eingebeAeter Systeme Markus Völter voelter@acm.org www.voelter.de @markusvoelter
1 Industry Trends
Complexity
Mass Customization
Time To Market
2 Posi@oning and Current Challenges
Requirements + Architecture Specifica@on = Requirements + Architecture Itera@on 1 Itera@on 2 Itera@on 3 ... Itera@on n
Posi@oning System Requirements Acceptance System System Architecture Integra?on System Component Design Integra?on So<ware So<ware Architecture Intergra?on So<ware Implementa?on
Current Challenges I Integra@on of Different Viewpoints Different viewpoints/aspects are specified with different tools. Their integra@on in terms of referen@al integrity, seman@cs tooling and version control is tedious and error prone. Leads to Wissensverlust. Ubiquituous Tracing Many different norms require that (parts of) ar@facts are traced to other (p.o.) ar@facts. Ubiquituous tracing is currently not available. Suitable Abstrac@ons and Nota@ons Different viewpoints/stakeholders require different abstrac@ons and different nota@ons. Current tools cannot easily accomodate.
Current Challenges II „Live Models“ Models must be more than „just“ the specifica@on. Meaningful analyses, simula@on or deriva@on of other ar@facts are o]en not supported – helps models stay relevant over @me. Tool Produc@vity Many of today‘s modeling tools are just painful to use in terms of produc@vity and usability. A significant improvement is necessary to make people want to use these tools. Extensibility/Adaptability Tools, Languages and Analyses should be adaptable to the specific needs of domains, projects and organiza@ons.
3 IETS3 Approach
IETS3 Approach I A common, extensible tool plaaorm Supports Integra@on of Different Viewpoints because all are just languages on that same plaaorm. All models are stored in VCS with the associated diff/merge workflows. Supports Ubiquituous Tracing because traces can be aAached to arbitrary model elements and may point to another element or to targets outside the plaaorm. A Language Workbench as the Basis Every Viewpoint is expressed as a language that uses suitable abstrac@ons and nota@ons (text, diagrams, tables, math). It also supports modular Extensibility of all of these lagbuages. New, project-specific languages can be built. LWB is an IDE, with proven Produc@vity and and Usability.
IETS3 Approach II Increased Formality Supports different degrees of formality (non-formal, semi-formal and formal languages). This is the basis for Live Models in terms of analyses, simula@on and execu@on. In par@cular, analyses are integrated as first class ci@zens and include referen@al integrity checks, simple constraints, type systems and formal verifica@on tools. Incrementality We will support the incremental increase of formality both between languages (textual requirements vs. mathema@cal equa@ons) but also within languages (data item name -> type -> constraints -> overlap) to support the natural increase in precision as a specifica@on matures.
Levels of Formality Unstructured Read Prose documents, e.g. in Understand? Word or Excel Structured Prose++, ontologies, Referencing iden@fiable parts; DOORS. Tracing Links Precise Variables, numbers, Clear ranges, formulas, CNL Some Checks Measure @ RT Verifiable Consistent formalisms Type Checks (math, logics, tables, state Solving machines) Model Check‘g
Verifica@on Constraints/ Analy@cal Solving Type Checks In IDE In IDE Global Local Tricky Errors Rather Obvious Errors Explitly Triggered Real@me Feedback Harder to Build Simple to build Simula@on Run@me Checks In IDE or External Tool In System; Report in IDE? Global Global Op@miza@ons Op@miza@ons and Errors May take some @me to run Logged during Tests or in Field Expensive to Build Cost in the final system
4 Enabler: Language Workbench
Language Workbench (Mar@n Fowler, 2004) Freely define languages and integrate them
Language Workbench (Mar@n Fowler, 2004) + powerful edi@ng tes@ng refactoring debugging groupware language defini@on implies IDE defini@on
Language Workbench (Mar@n Fowler, 2004) + support for „classical“ programming and „classical“ modeling There‘s no difference!
A Language Workbench – a tool for defining, composing and using ecosystems of languages.
Open Source Apache 2.0 hAp://jetbrains.com/mps
V 3.3 is current V 3.4 to be released Summer 2016
[Language Workbench] Comprehensive Support for many aspects of Language Defini@on. + Refactorings, Find Usages, Syntax Coloring, Debugging, ...
[Projec@onal Edi@ng] Parsing Projec@onal Edi@ng
[Projec@onal Edi@ng] Syntac@c Flexibility Regular Code/Text Mathema@cal Tables Graphical
[Projec@onal Edi@ng] Syntac@c Flexibility Regular Code/Text Mathema@cal Tables Graphical
[Projec@onal Edi@ng] Language Composi@on L2 L1 Separate Files In One File Type System Type System Transforma@on Transforma@on Constraints Constraints Syntax IDE 50+ extensions to C 10+ extensions to requirements lang.
[Projec@onal Edi@ng] Modular Language Composi@on No change to defini@on of or L1 L2 in order to use them together. Embedding + L Adapt + = L Emb L Host Extension = L Base L Ext + Extension Composi@on L Ext2 = L Base + + L Ext1
4 Integra@on T vs. L
Performance Security Requirements Expres- Feature MPS sions Models High-Level Safety Component Behavior Architectures (User Extensions)
Core Languages
Aspects of System Models QoS/Non-Func. Performance Timing, Frequency Resources Security Behavior Safety Data Ranges Condi@ons Pre/Post Condi@ons Structure Protocol State Machines Signatures Modularity Provides/Uses
[Typical Integra@on] Tool A Tool B Tool B DSL 1 DSL 3 DSL 4 DSL 2 DSL 5
[Typical Integra@on: Problems] Syntax Essential Type System Semantics Accidental IDE Tools in general File Formats Implementation Platforms Bad or incomplete APIs Lossy/Undocumented File Formats Business Reasons
[Language-Oriented Applica@ons] Workbench DSL 1 DSL 2 DSL 3 ... DSL 4 DSL 5 DSL N
Integrate Every Tool into one? Realis@c? I H K G E J L F D C M A B
Integrate Every Tool into one? Realis@c? I H K G E J L F D C A B
Integrate Every Tool into one? Realis@c? G F CDE A B Guided by Cohesion & Coupling As with all other so<ware ...
5 Candidate Languages
Possible Languages - Structure Glossaries hNp://de.wikipedia.org/wiki/Glossar Ontologies hNp://de.wikipedia.org/wiki/Ontologie_%28Informa?k%29 Product Breakdown Structures hNp://en.wikipedia.org/wiki/Product_breakdown_structure Komponentendiagramme hNp://de.wikipedia.org/wiki/Komponentendiagramm Datenstrukturen
Possible Languages – Behavior I Boolesche Regeln (incl. Latching, Edge Detec?on, Zeitverzögerungen) Mathema@sche Abstrak@onen und Nota?onen mit Symbolen wie Bruchstrich, Sum-Symbol oder Wurzelzeichen Tabellarische Wertesammlungen mit Konsistenzregeln und Beziehungen Ablauvechreibungen/Prozess angelehnt an Ak?vitätsdiagramme Zustandsmaschinen hNp://de.wikipedia.org/wiki/Zustandsdiagramm_%28UML%29 Geschä]sregeln à la Drools hNp://en.wikipedia.org/wiki/Drools Message Sequence Charts hNp://de.wikipedia.org/wiki/Message_Sequence_Chart
Possible Languages – Behavior II Timing Diagramme hNp://de.wikipedia.org/wiki/Zeitverlaufsdiagramm Controlled Natural Language hNp://en.wikipedia.org/wiki/Controlled_natural_language Expressive Decision Tables hNp://ieeexplore.ieee.org/xpl/ar?cleDetails.jsp?tp=&arnumber=6800429 Parnas' Tables hNps://cs.uwaterloo.ca/~jmatlee/talks/parnas01.pdf BDD Spezifika@onen hNp://de.wikipedia.org/wiki/Behavior_Driven_Development
Possible Languages – Non-Func@onals Qualitäts-/SicherheitsaAribute Safety PaAerns Goal Structuring Nota@on (GSN) hNp://www.goalstructuringnota?on.info/ Failure Mode and Effects Analysis (FMEA) hNp://de.wikipedia.org/wiki/FMEA Fault Tree Analysis (FTA) hNp://en.wikipedia.org/wiki/Fault_tree_analysis
Possible Languages – Cross Cu{ng Feature Models hNp://en.wikipedia.org/wiki/Feature_model
5a Exis@ng Languages
Requirements
Feature Modeling
Func@onal Expressions
Data Modeling
Hierarchical Components
Performance Modeling I
Performance Modeling II
Performance Modeling III
6 Lessons Learned
Why Version Control
Why Version Control Consistency across Team
Why Version Control Consistency across Team Development History
Why Version Control Consistency across Team Development History Time Machine
Why Version Control Consistency across Team Development History Time Machine Branching (Feature, Version)
Why Version Control Consistency across Team Development History Time Machine Branching (Feature, Version) Support Staging
Recommend
More recommend
