eingebeAeter Systeme Markus Vlter voelter@acm.org www.voelter.de - - PowerPoint PPT Presentation

Markus Völter voelter@acm.org

www.voelter.de @markusvoelter

Eine Architektur-DSL zur Beschrei- bung und formalen Verifika@on eingebeAeter Systeme

1

Industry Trends

Complexity

Mass Customization

Time To Market

2

Posi@oning and Current Challenges

Requirements + Architecture

Requirements Architecture Itera@on 1 Itera@on 2 Itera@on 3 Itera@on n Specifica@on = + ...

Requirements System Architecture System Design So<ware Architecture So<ware Implementa?on So<ware Intergra?on Component Integra?on System Acceptance System Integra?on

Posi@oning

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

• ther (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.

Unstructured Structured Precise Verifiable

Prose documents, e.g. in Word or Excel Prose++, ontologies, iden@fiable parts; DOORS. Variables, numbers, ranges, formulas, CNL Consistent formalisms (math, logics, tables, state machines) Read Understand? Referencing Tracing Links Clear Some Checks Measure @ RT Type Checks Solving Model Check‘g

Levels of Formality

Verifica@on

Constraints/ Type Checks Analy@cal Solving Simula@on Run@me Checks

In IDE Local Rather Obvious Errors Real@me Feedback Simple to build In IDE Global Tricky Errors Explitly Triggered Harder to Build In IDE or External Tool Global Op@miza@ons May take some @me to run Expensive to Build In System; Report in IDE? Global Op@miza@ons and Errors Logged during Tests or in Field Cost in the final system

4

Enabler: Language Workbench

Freely

define integrate

them languages and

Language Workbench

(Mar@n Fowler, 2004)

powerful

edi@ng tes@ng refactoring debugging

language defini@on IDE defini@on

implies

+

groupware

Language Workbench

(Mar@n Fowler, 2004)

support for

„classical“

programming

„classical“

modeling

and

+

Language Workbench

(Mar@n Fowler, 2004)

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]

+ Refactorings, Find Usages, Syntax Coloring, Debugging, ...

Comprehensive Support for many aspects of Language Defini@on.

Parsing Projec@onal Edi@ng

[Projec@onal Edi@ng]

Regular Code/Text Mathema@cal Tables Graphical

Syntac@c Flexibility

[Projec@onal Edi@ng]

Regular Code/Text Mathema@cal Tables Graphical

Syntac@c Flexibility

[Projec@onal Edi@ng]

L2 L1

Separate Files In One File Type System Transforma@on Constraints Type System Transforma@on Constraints Syntax IDE

Language Composi@on

[Projec@onal Edi@ng]

50+ extensions to C 10+ extensions to requirements lang.

No change to defini@on of or

Modular Language Composi@on

[Projec@onal Edi@ng]

L2 L1

in order to use them together.

LHost LEmb

+

Embedding

=

LAdapt + LBase LExt

+

Extension

=

LBase LExt1

+

Extension Composi@on

=

LExt2

+

4

Integra@on T vs. L

MPS

Requirements Component Architectures Feature Models Expres- sions Performance Safety Security (User Extensions) High-Level Behavior

Core Languages

Aspects of System Models

Structure

Signatures Modularity Provides/Uses

Behavior

Data Ranges Condi@ons Pre/Post Condi@ons Protocol State Machines

QoS/Non-Func.

Performance Timing, Frequency Resources Security Safety

[Typical Integra@on]

DSL 1

Tool A

DSL 2 DSL 3

Tool B

DSL 4

Tool B

DSL 5

[Typical Integra@on: Problems]

Syntax Type System Semantics IDE Tools in general File Formats

Essential Accidental

Implementation Platforms Bad or incomplete APIs Lossy/Undocumented File Formats Business Reasons

[Language-Oriented Applica@ons]

DSL 1

Workbench

DSL 2 DSL 3 DSL 4 DSL 5 DSL N

...

Integrate Every Tool into one? Realis@c?

G I K A M B J C F H L E D

Integrate Every Tool into one? Realis@c?

G I K A B C F H L E D J

Integrate Every Tool into one? Realis@c?

A B CDE F G

Cohesion & Coupling

As with all other so<ware ...

Guided by

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

How do you achieve Consistency

Strict Language Cross-References Modulariza@on and Reuse Automa@c Deriva@on based on rules (transforma@on, genera@on)

Common Respository Version Control System Periodic, Global Checks/Reports

The Language is not Enough

Language Great IDE Analyses Refactorings Tes@ng Debuggers

Abstrac@ons Nota@ons Syntax Coloring Code Comple@on Goto Defini@on Relevant Good Errors Aligned with Processes Write Tests Run them Report Back Animate Execu@on Simulators

GOOD GREAT

Requirements on the tool

Be a great LWB

Support all the language goodness we talked about so far.

• bviously

Produc@vity

Quickly evolve the language as the (understanding of) domain changes

Performance

Nobody wants to work with a sluggish tool

Scalability

Non-trivial languages and significant model sizes

Evolu@on Support

Migrate exis@ng models as the languages evolve.

Friendliness

Don‘t overwhelm end users with too much „cru]“

Explorability

Ensure the language can be explored

Does this scale?

Does the approach scale?

If structure, formaliza@on, and tool support don‘t scale,

What are the alterna@ves? Excel? Wikis? Prose Documents?

then what will??

Do the tools scale?

In terms of overall system size?

Yes, the system has to be broken down into models

• f manageable size, as usual. This requires some thought.

In terms of team size?

Yes, since we rely on established version control systems (git) to deal with groupware aspects; and yes, diff/merge works as expected.

In terms of language complexity?

Yes, in par@cular, since you can modularize the language defini@ons.

Can I find the people to do this?

Can I find the people to do this?

Yes, but it is a significant change, so:

• it may be a significant educa@on/training effort.
• a few people might not get it
• a few people may not want to do it.

Can I find the people to do this?

Yes, but it is a significant change, so:

• it may be a significant educa@on/training effort.
• a few people might not get it
• a few people may not want to do it.

8

Summary

System Specifica@on requires an integrated mix of increasingly formal languages.

IETS3 is developing an IDE

based on these principles.

s

• u

r c e

[Read & Learn]

Thank you!

voelter@acm.org www.voelter.de @markusvoelter