Modeling Spatial and Temporal Variability with the HATS Abstract - - PowerPoint PPT Presentation

modeling spatial and temporal variability with the hats
SMART_READER_LITE
LIVE PREVIEW

Modeling Spatial and Temporal Variability with the HATS Abstract - - PowerPoint PPT Presentation

Modeling Spatial and Temporal Variability with the HATS Abstract Behavioral Modeling Language Ina Schaefer Technische Universit at Braunschweig, Germany 18 June 2011 http://www.hats-project.eu I. Schaefer SFM-11:CONNECT 0 / 60


slide-1
SLIDE 1

Modeling Spatial and Temporal Variability with the HATS Abstract Behavioral Modeling Language

Ina Schaefer

Technische Universit¨ at Braunschweig, Germany 18 June 2011 http://www.hats-project.eu

  • I. Schaefer

SFM-11:CONNECT 0 / 60

slide-2
SLIDE 2

Acknowledgment

The following HATerS contributed to this tutorial:

◮ Richard Bubel (Chalmers UT) ◮ Jan Sch¨

afer (TU Kaiserslautern)

◮ Reiner H¨

ahnle (Chalmers UT)

◮ Dave Clarke (KU Leuven) ◮ Einar Broch Johnson (U Oslo) ◮ Rudi Schlatte (U Oslo) ◮ Radu Muschevici (KU Leuven)

  • I. Schaefer

SFM-11:CONNECT 1 / 60

slide-3
SLIDE 3

HATS Facts

HATS: Highly Adaptable & Trustworthy Software Using Formal Models

◮ FP7 FET focused call Forever Yours ◮ Project started 1 March 2009, 48 months runtime ◮ Integrated Project, academically driven ◮ 9 academic partners, 2 industrial research, 1 SME ◮ 8 countries ◮ 805 PM, EC contribution 5,64 Me over 48 months ◮ web: www.hats-project.eu

  • I. Schaefer

SFM-11:CONNECT 2 / 60

slide-4
SLIDE 4

What Does HATS?

In a nutshell, we . . . develop a tool-supported formal method for the design, analysis, and implementation of highly adaptable software systems characterized by a high expectations on trustworthiness for target software systems that are . . .

◮ concurrent, distributed ◮ object-oriented ◮ built from components ◮ adaptable (variability, evolvability), hence reusable

Main focus: Software Product Line Engineering

  • I. Schaefer

SFM-11:CONNECT 3 / 60

slide-5
SLIDE 5

Motivation

Why formal?

◮ informal notations can’t describe software behavior with rigor:

concurrency, modularity, correctness, security, resources . . .

◮ formalization ⇒ more advanced tools

  • more complex products
  • higher automation: cost-efficiency

Why adaptable?

◮ changing requirements (rapid technological/market pace) ◮ evolution of software in unanticipated directions ◮ planned adaptability is a key to successful reuse

  • I. Schaefer

SFM-11:CONNECT 4 / 60

slide-6
SLIDE 6

Mind the Gap!

How to rigorously model behavior of large, distributed OO systems? Implementation-oriented Spec#, Java+JML

? ?

Design-oriented, architectural

UML, FDL, ALs Specification level Languages (examples)

  • I. Schaefer

SFM-11:CONNECT 5 / 60

slide-7
SLIDE 7

Mind the Gap!

How to rigorously model behavior of large, distributed OO systems? Implementation-oriented Spec#, Java+JML

? ?

Design-oriented, architectural

UML, FDL, ALs Specification level Languages (examples) Abstract behavioral HATS ABS language

  • I. Schaefer

SFM-11:CONNECT 5 / 60

slide-8
SLIDE 8

How?

A tool-supported formal method for building highly adaptable and trustworthy software

  • I. Schaefer

SFM-11:CONNECT 6 / 60

slide-9
SLIDE 9

How?

A tool-supported formal method for building highly adaptable and trustworthy software Main ingredients

1 Executable, formal modeling language for adaptable software:

Abstract Behavioral Specification (ABS) language

2 Tool suite for ABS/executable code analysis & development:

Analytic functional/behavioral verification, resource analysis, feature consistency, RAC, types, TCG, visualization Generative code generation, model mining, monitor inlining, . . . Develop methods in tandem with ABS to ensure feasibility

3 Methodological and technological framework integrating

HATS tool architecture and ABS language

  • I. Schaefer

SFM-11:CONNECT 6 / 60

slide-10
SLIDE 10

Important Project Principles (I)

Ensuring relevance

◮ Apply to empirically highly successful development method:

Software product line engineering(PLE)

◮ Thorough requirements analysis, continuous evaluation

Feature Model Family Engineering Product Line Artefacts Base Feature Selection Application Engineering Product

  • I. Schaefer

SFM-11:CONNECT 7 / 60

slide-11
SLIDE 11

Important Project Principles (II)

Feasibility: ensure that analysis methods scale up Develop analysis methods in tandem with ABS language

◮ Incrementality

  • Delta modeling, delta specification, delta verification

◮ Compositionality

  • Concurrency model
  • Proof systems
  • I. Schaefer

SFM-11:CONNECT 8 / 60

slide-12
SLIDE 12

Important Project Principles (III)

Early evaluation

◮ Develop Core ABS first

Assertion Language Composition (COGs) Concurrency model Object Model Core Creol Pure Functional Language

ADT

  • I. Schaefer

SFM-11:CONNECT 9 / 60

slide-13
SLIDE 13

Important Project Principles (III)

Early evaluation

◮ Develop Core ABS first ◮ Layered language design

Feature Model (µTVL) Delta Modeling (DML) Product Line Configuration (CL) Product Selection (PSL) Behavioral Interface Language Assertion Language Composition (COGs) Concurrency model Object Model Core Creol Pure Functional Language

ADT

  • I. Schaefer

SFM-11:CONNECT 9 / 60

slide-14
SLIDE 14

Important Project Principles (III)

Early evaluation

◮ Develop Core ABS first ◮ Layered language design ◮ Provide tools early

Core AST Name Resolution Resolved AST Type Checker Type-Checked AST ABS IDE Java Back End Maude Back End Core ABS code gen. Maude Files Java Files Core ABS Files Maude VM Java VM

  • I. Schaefer

SFM-11:CONNECT 9 / 60

slide-15
SLIDE 15

The Main Innovations of HATS

A formal, executable, abstract, behavioral modeling language

◮ Cutting-edge research on modeling of concurrent, OO systems ◮ Combines state-of-art in verification, concurrency, specification, and

programming languages communities

◮ Adaptability drives the design

Scalable technologies developed in tandem with ABS

◮ Incremental, compositional ◮ Analytic as well as generative technologies

Formalization of PLE-based development as main application

◮ Leveraging formal methods tools to PLE ◮ Define FM-based development methodology for PLE

  • I. Schaefer

SFM-11:CONNECT 10 / 60

slide-16
SLIDE 16

Vision: a Model-Centric Development Method for PLE

Product Line Models expressed in HATS ABS with uniform formal semantics

consistency analysis correctness

  • f reuse

family visualization test case generation validation, verification code generation product visualization rapid prototyping test case generation validation, verification family evo- lution product evolution

Family Engineering Application Engineering

[Schaefer & H¨ ahnle, IEEE Computer, Feb. 2011]

  • I. Schaefer

SFM-11:CONNECT 11 / 60

slide-17
SLIDE 17

Main Design Goals of ABS

ABS A language for describing large, distributed information system families Key Properties

◮ Object-based, imperative, and functional ◮ Sequential, concurrent, and distributed ◮ Expressive yet analyzable ◮ Formal yet practical

Suitable for

◮ Static analysis ◮ Dynamic analysis ◮ Simulation ◮ Code generation

  • I. Schaefer

SFM-11:CONNECT 12 / 60

slide-18
SLIDE 18

Outline

◮ Modeling Concurrent Systems with Core ABS ◮ Modeling Spatial Variability in Full ABS ◮ Modeling Temporal Variability in Full ABS

  • I. Schaefer

SFM-11:CONNECT 13 / 60

slide-19
SLIDE 19

Layered ABS Language Design

Feature Model (µTVL)1 Delta Modeling (DML) Product Line Configuration (CL) Product Selection (PSL) Behavioural Interface Language Assertion Language Composition (COGs) Concurrency model Object Model Core Creol Pure Functional Language

ADT

1Based on: A. Classen, Q. Boucher, P. Heymans. A Text-based Approach to Feature

Modelling: Syntax and Semantics of TVL. SCP 2010.

  • I. Schaefer

SFM-11:CONNECT 14 / 60

slide-20
SLIDE 20

Core ABS

  • I. Schaefer

SFM-11:CONNECT 15 / 60

slide-21
SLIDE 21

Built-In Data Types and Operators

Built-In Data Types

data Bool = True | False; data Unit = Unit; data Int; // 4, 2323, −23 data String; // ”Hello World”

  • I. Schaefer

SFM-11:CONNECT 16 / 60

slide-22
SLIDE 22

Built-In Data Types and Operators

Built-In Data Types

data Bool = True | False; data Unit = Unit; data Int; // 4, 2323, −23 data String; // ”Hello World”

Built-In Operators

◮ All types:

== !=

◮ Bool:

~ && ||

◮ Int:

+

  • *

/ % < > <= >=

◮ String:

+

  • I. Schaefer

SFM-11:CONNECT 16 / 60

slide-23
SLIDE 23

User Defined Data Types

User-Defined Data Types

data Fruit = Apple | Banana | Cherry; data Juice = Pure(Fruit) | Mixed(Juice, Juice);

  • I. Schaefer

SFM-11:CONNECT 17 / 60

slide-24
SLIDE 24

User Defined Data Types

User-Defined Data Types

data Fruit = Apple | Banana | Cherry; data Juice = Pure(Fruit) | Mixed(Juice, Juice);

Parametric Data Types

data List<T> = Nil | Cons(T, List<T>);

  • I. Schaefer

SFM-11:CONNECT 17 / 60

slide-25
SLIDE 25

User Defined Data Types

User-Defined Data Types

data Fruit = Apple | Banana | Cherry; data Juice = Pure(Fruit) | Mixed(Juice, Juice);

Parametric Data Types

data List<T> = Nil | Cons(T, List<T>);

Optional Selectors (since v1.1)

data Person = Person(String name, Int age, String address);

implicitly defines corresponding functions, e.g.,

def String name(Person) = ... ;

  • I. Schaefer

SFM-11:CONNECT 17 / 60

slide-26
SLIDE 26

Functions and Pattern Matching

def Int length(IntList list) = // function names lower−case case list { // definition by case distinction and matching Nil => 0 ; Cons(n, ls) => 1 + length(ls) ; _ => 0 ; // anonymous variable matches anything } ; def A head<A>(List<A> list) = // parametric function case list { Cons(x, xs) => x; } ;

  • I. Schaefer

SFM-11:CONNECT 18 / 60

slide-27
SLIDE 27

ABS Standard Library

ABS Standard Library

module ABS.StdLib; export *; data Maybe<A> = Nothing | Just(A); data Either<A, B> = Left(A) | Right(B); data Pair<A, B> = Pair(A, B); data List<T> = ...; data Set<T> = ...; data Map<K,V> = ...; ... def Int size<A>(Set<A> xs) = ... def Set<A> union<A>(Set<A> set1, Set<A> set2) = ... ...

  • I. Schaefer

SFM-11:CONNECT 19 / 60

slide-28
SLIDE 28

Object Model: Interfaces

Interfaces

◮ Types of objects ◮ Multiple inheritance

interface Baz { ... } interface Bar extends Baz { // method signatures Unit m(); Bool foo(Bool b); }

  • I. Schaefer

SFM-11:CONNECT 20 / 60

slide-29
SLIDE 29

Object Model: Classes

Classes

◮ Only for object construction ◮ No type ◮ No inheritance

// class parameters class Foo(T x, U y) implements Bar, Baz { // fields Bool flag = False; U g; { // optional initialization block g = y; } Unit m() { } // method implementations Bool foo(Bool b) { return ~b; } }

  • I. Schaefer

SFM-11:CONNECT 21 / 60

slide-30
SLIDE 30

Imperative Constructs

Sequential Control Flow

◮ Loop (while (x) { ... }) ◮ Conditionals (if (x == y) then ... else ...) ◮ Synchronous method calls (x.m())

State Update and Access

◮ Object creation (new Car(Blue)) ◮ Field reads (x = this.f) (only on this) ◮ Field assignments (this.f = 5;) (only on this)

  • I. Schaefer

SFM-11:CONNECT 22 / 60

slide-31
SLIDE 31

Concurrency Model

Layered Concurrency Model Upper tier: asynchronous, no shared state, actor-based Lower tier: synchronous, shared state, cooperative multitasking Concurrent Object Groups (COGs)

◮ Unit of distribution ◮ Own heap of objects ◮ Communicate by asynchronous method calls ◮ Cooperative multitasking inside COGs

  • I. Schaefer

SFM-11:CONNECT 23 / 60

slide-32
SLIDE 32

Object and COG Creation

Local Object Creation this:A

  • I. Schaefer

SFM-11:CONNECT 24 / 60

slide-33
SLIDE 33

Object and COG Creation

Local Object Creation this:A new B();

  • I. Schaefer

SFM-11:CONNECT 24 / 60

slide-34
SLIDE 34

Object and COG Creation

Local Object Creation this:A new B(); this:A b:B

  • I. Schaefer

SFM-11:CONNECT 24 / 60

slide-35
SLIDE 35

Object and COG Creation

Local Object Creation this:A new B(); this:A b:B COG Creation this:A

  • I. Schaefer

SFM-11:CONNECT 24 / 60

slide-36
SLIDE 36

Object and COG Creation

Local Object Creation this:A new B(); this:A b:B COG Creation this:A new cog B();

  • I. Schaefer

SFM-11:CONNECT 24 / 60

slide-37
SLIDE 37

Object and COG Creation

Local Object Creation this:A new B(); this:A b:B COG Creation this:A new cog B(); this:A b:B

  • I. Schaefer

SFM-11:CONNECT 24 / 60

slide-38
SLIDE 38

Far and Near References

Far References Refer to objects belonging to a different COG Near References Refer to objects belonging to the current COG

  • I. Schaefer

SFM-11:CONNECT 25 / 60

slide-39
SLIDE 39

Far and Near References

Far References Refer to objects belonging to a different COG Near References Refer to objects belonging to the current COG Pluggable Type and Inference System

◮ Statically distinguishes near from far references ◮ Ensures that synchronous calls are only done on near references

{ [Near] Ping ping = new PingImpl(); [Far] Pong pong = new cog PongImpl(); ping.ping("Hi"); // ok pong.pong("Hi"); // error: synchronous call on far reference }

  • I. Schaefer

SFM-11:CONNECT 25 / 60

slide-40
SLIDE 40

Asynchronous Method Calls

Asynchronous Method Calls

◮ Syntax: target ! methodName(arg1, arg2, ...) ◮ Sends an asynchronous message to the target object ◮ Caller continues and gets a future to the result

  • Fut<T> v = o!m(e);
  • I. Schaefer

SFM-11:CONNECT 26 / 60

slide-41
SLIDE 41

Cooperative Multitasking inside COGs

Multitasking

◮ A COG can have multiple tasks ◮ Only one is active, all others are suspended ◮ Asynchronous calls create new tasks

Scheduling

◮ Cooperative by special scheduling statements ◮ Non-deterministic otherwise

  • Configuration of scheduling is worked on
  • I. Schaefer

SFM-11:CONNECT 27 / 60

slide-42
SLIDE 42

Scheduling and Synchronization

Unconditional Scheduling

◮ suspend command yields control to other task in COG ◮ Unconditional scheduling point

Conditional Scheduling

◮ await g, where g is a guard ◮ Guards can be

  • b - where b is a side-effect-free boolean expression
  • f? - future guards
  • g & g - conjunction

Future Reading

◮ f.get - reads future f and blocks execution until is resolved ◮ Deadlocks possible ◮ Use await f? to prevent blocking, e.g.,

  • Fut<T> v = o!m(e);...; await v?; r = v.get;
  • I. Schaefer

SFM-11:CONNECT 28 / 60

slide-43
SLIDE 43

Scheduling and Synchronization (2)

Synchronization of Concurrent Activities

◮ Wait until result of an asynchronous computation is ready

  • await g, where g is a monotonically behaving polling guard expression
  • ver v? and v is a future reference (has future type)

◮ Retrieve result of asynchronous computation and copy into a future

  • v.get, where v is a future referring to a finished task

◮ Programming idiom:

Fut<T> v = o!m(e);...; await v?; r = v.get;

◮ Conditional scheduling point

  • I. Schaefer

SFM-11:CONNECT 29 / 60

slide-44
SLIDE 44

Tool Demo - Core ABS

◮ Eclipse-Plugin ◮ Type Checking ◮ Java Code Generation ◮ Simulation

Tools are available at http://tools.hats-project.eu/

  • I. Schaefer

SFM-11:CONNECT 30 / 60

slide-45
SLIDE 45

Modeling Spatial Variability

  • I. Schaefer

SFM-11:CONNECT 31 / 60

slide-46
SLIDE 46

ABS Language Layers

Feature Model (µTVL) Delta Modeling (DML) Product Line Configuration (CL) Product Selection (PSL) Behavioural Interface Language Assertion Language Composition (COGs) Concurrency model Object Model Core Creol Pure Functional Language

ADT

  • I. Schaefer

SFM-11:CONNECT 32 / 60

slide-47
SLIDE 47

Spatial Variability - Product Line Engineering

Feature Model Family Engineering Product Line Artefacts Base Feature Selection Application Engineering Product

  • I. Schaefer

SFM-11:CONNECT 33 / 60

slide-48
SLIDE 48

Variability Modelling: Feature Modelling

A product can be seen as selection of features.

  • I. Schaefer

SFM-11:CONNECT 34 / 60

slide-49
SLIDE 49

Variability Modelling: Feature Modelling

A product can be seen as selection of features.

  • I. Schaefer

SFM-11:CONNECT 34 / 60

slide-50
SLIDE 50

Variability Modelling: Feature Modelling

A product can be seen as selection of features.

  • I. Schaefer

SFM-11:CONNECT 34 / 60

slide-51
SLIDE 51

Variability Modelling: Feature Modelling

A product can be seen as selection of features.

  • I. Schaefer

SFM-11:CONNECT 34 / 60

slide-52
SLIDE 52

Variability Modelling: Feature Modelling

A product can be seen as selection of features. Feature model describes all possible feature combination.

  • I. Schaefer

SFM-11:CONNECT 34 / 60

slide-53
SLIDE 53

Hello World Example

Feature Diagram

MultiLingualHelloWorld Language Repeat German French Dutch English

Int times in [0..1000] times > 0 Repeat → Repeat.times ≥ 2 ∧ Repeat.times ≤ 5

  • I. Schaefer

SFM-11:CONNECT 35 / 60

slide-54
SLIDE 54

Feature Modelling Language µTVL

µTVL: micro textual variability language Extended subset of TVL

◮ Attributes: only integers (no enums) ◮ Feature extensions: only additional constraints ◮ But: Multiple roots for orthogonal features

  • I. Schaefer

SFM-11:CONNECT 36 / 60

slide-55
SLIDE 55

Feature Modelling Language µTVL

µTVL: micro textual variability language Extended subset of TVL

◮ Attributes: only integers (no enums) ◮ Feature extensions: only additional constraints ◮ But: Multiple roots for orthogonal features

Why? Reduction of many semantical constraints in TVL to pure syntactical constraints.

  • I. Schaefer

SFM-11:CONNECT 36 / 60

slide-56
SLIDE 56

Hello World Example

root MultiLingualHelloWorld { group allof { Language { group oneof { English, Dutch, French, German } },

  • pt Repeat {

Int times in [0..1000]; times > 0; } } } extension English { ifin: Repeat -> (Repeat.times >= 2 && Repeat.times <= 5); }

  • I. Schaefer

SFM-11:CONNECT 37 / 60

slide-57
SLIDE 57

Grammar of µTVL

Model ::= (root FeatureDecl)∗ FeatureExtension∗ FeatureDecl ::= FID [{ [Group] AttributeDecl∗ Constraint∗ }] FeatureExtension ::= extension FID { AttributeDecl∗ Constraint∗} Group ::= group Cardinality { [opt] FeatureDecl, ([opt] FeatureDecl)∗ } Cardinality ::= allof | oneof | [n1 .. *] | [n1 .. n2] AttributeDecl ::= Int AID ; | Int AID in [ Limit .. Limit ] ; | Bool AID ; Limit ::= n | ∗ Constraint ::= Expr ; | ifin: Expr ; | ifout: Expr ; | require: FID ; | exclude: FID ; Expr ::= True | False | n | FID | AID | FID.AID | UnOp Expr | Expr BinOp Expr | ( Expr ) UnOp ::= ! | - BinOp ::= || | && | -> | <-> | == | != | > | < | >= | <= | + | - | * | / | %

  • I. Schaefer

SFM-11:CONNECT 38 / 60

slide-58
SLIDE 58

Hello World Example

Semantics

µTVL models translated into integer constraints.

0 ≤ MultiLingualHelloWorld ≤ 1 ∧ Language → MultiLingualHelloWorld ∧ Repeat† → MultiLingualHelloWorld ∧ Language + Repeat† = 2 ∧ 0 ≤ Language ≤ 1 ∧ English → Language ∧ Dutch → Language ∧ German → Language ∧ 1 ≤ English + Dutch + German ≤ 1 ∧ 0 ≤ English ≤ 1 ∧ 0 ≤ Dutch ≤ 1 ∧ 0 ≤ German ≤ 1 ∧ 0 ≤ Repeat† ≤ 1 ∧ Repeat → Repeat† ∧ 0 ≤ Repeat ≤ 1 ∧ 0 ≤ Repeat.times ≤ 1000 ∧ Repeat.times > 0 ∧ English → (Repeat → (Repeat.times ≥ 2 ∧ Repeat.times ≤ 5)).

  • I. Schaefer

SFM-11:CONNECT 39 / 60

slide-59
SLIDE 59

Variability Modelling: Delta Modelling

How is variability realised on the ABS program level?

◮ No subclassing (only subtyping) ◮ No traits

  • I. Schaefer

SFM-11:CONNECT 40 / 60

slide-60
SLIDE 60

Variability Modelling: Delta Modelling

How is variability realised on the ABS program level?

◮ No subclassing (only subtyping) ◮ No traits

Approach: (Core-)Delta Modelling

◮ Base product (the core) ◮ Variants are composed by applying deltas to the base product

  • I. Schaefer

SFM-11:CONNECT 40 / 60

slide-61
SLIDE 61

Application of Delta Modules

Core New product Delta1 · · · Deltan

apply deltas

◮ Delta modules add, remove or modify classes ◮ Class modification consists of adding, removing or wrapping fields and

methods, adding new interfaces, etc.

◮ Applies to a core model.

  • I. Schaefer

SFM-11:CONNECT 41 / 60

slide-62
SLIDE 62

Core Hello World

interface Greeting { String sayHello(); } class Greeter implements Greeting { String sayHello() { return "Hello world"; } } class Application { Unit run() { Greeting bob; bob = new Greeter(); String s = ""; s = bob.sayHello(); } }

  • I. Schaefer

SFM-11:CONNECT 42 / 60

slide-63
SLIDE 63

Delta Modules of Hello World

delta Nl { modifies class Greeter { modifies String sayHello() { return "Hallo wereld"; } } } delta Rpt (Int times) { modifies class Greeter { modifies String sayHello() { String result = ""; Int i = 0; while (i < times) { result = result + original(); i = i + 1; } return result; } } }

  • I. Schaefer

SFM-11:CONNECT 43 / 60

slide-64
SLIDE 64

Application of Delta Modules

class Greeter implements Greeting { String sayHello() { return "Hello world"; } }

delta Nl { modifies class Greeter { modifies String sayHello() { return "Hallo wereld"; } } }

class Greeter implements Greeting { String sayHello() { return "Hallo wereld"; } }

  • I. Schaefer

SFM-11:CONNECT 44 / 60

slide-65
SLIDE 65

Syntax

DeltaDecl ::= delta TypeId [DeltaParams] { ClassOrIfaceModifier∗ } ClassOrIfaceModifier ::= adds ClassDecl | modifies class TypeName ImplModifier∗ { Modifier∗ } | removes class TypeName ; | adds InterfaceDecl | modifies interface TypeName ImplModifier∗ { Modifier∗ } | removes interface TypeName ; ImplModifier ::= adds TypeName | removes TypeName Modifier ::= adds FieldDecl | removes FieldDecl | adds MethDecl | modifies MethDecl | removes MethSig

  • I. Schaefer

SFM-11:CONNECT 45 / 60

slide-66
SLIDE 66

Syntax

Continuation

DeltaParams ::= (DeltaParam (, DeltaParams)∗ ) DeltaParam ::= Identifier HasCondition∗ | Type Identifier HasCondition ::= hasField FieldDecl | hasMethod MethSig | hasInterface TypeName

  • I. Schaefer

SFM-11:CONNECT 46 / 60

slide-67
SLIDE 67

Variability Modelling: Product Line Configuration

Two models: Feature Model and Delta Model Feature Model Deltas Core Modules How are they connected?

  • I. Schaefer

SFM-11:CONNECT 47 / 60

slide-68
SLIDE 68

Variability Modelling: Product Line Configuration

Two models: Feature Model and Delta Model Feature Model Deltas Core Modules Configuration

application conditions and delta ordering

How are they connected? Product Configuration Language

  • I. Schaefer

SFM-11:CONNECT 47 / 60

slide-69
SLIDE 69

Example of a Product Line Configuration

productline MultiLingualHelloWorld { features English, Dutch, French, German, Repeat; delta Nl when Dutch; delta Fr when French; delta De when German; delta Rpt(Repeat.times) after De, Nl, Fr when Repeat; }

  • I. Schaefer

SFM-11:CONNECT 48 / 60

slide-70
SLIDE 70

Syntax of a Product Line Configuration

Configuration ::= productline TypeId { Features ; Deltas } Features ::= features FID (, FID )∗ DeltaClauses ::= DeltaClause (, DeltaClause)∗ DeltaClause ::= delta DeltaSpec [AfterCondition] [ApplicationCondition] ; DeltaSpec ::= TypeName [( DeltaArgs )] DeltaArgs ::= DeltaArg (, DeltaArg)∗ DeltaArg ::= FID | FID.AID | DataExp AfterCondition ::= after TypeName (, Name )∗ ApplicationCondition ::= when Expr

  • I. Schaefer

SFM-11:CONNECT 49 / 60

slide-71
SLIDE 71

Product Selection

Feature Model Product Selection Configuration Deltas Core Modules Software Product

satisfies uses apply Deltas

◮ Compiler flattens Deltas and Core Module into Core ABS model

  • I. Schaefer

SFM-11:CONNECT 50 / 60

slide-72
SLIDE 72

Example of Product Selections

// basic product with no deltas product P1 (English) { new Application(); } // apply deltas Nl and Repeat product P2 (Dutch, Repeat{times=10}) { new Application(); } // apply deltas En and Repeat, but it should be refused because ”times > 5” product P3 (English, Repeat{times=6}) { new Application(); }

  • I. Schaefer

SFM-11:CONNECT 51 / 60

slide-73
SLIDE 73

Tool Demo - Spatial Variability Modeling

◮ µTVL - Checking Product Selections ◮ µTVL - Finding Valid Feature Selections ◮ Product Generation from Full ABS Models

Tools are available at http://tools.hats-project.eu/

  • I. Schaefer

SFM-11:CONNECT 52 / 60

slide-74
SLIDE 74

Modeling Temporal Variability

  • I. Schaefer

SFM-11:CONNECT 53 / 60

slide-75
SLIDE 75

Temporal Variability

Temporal Variability refers to unanticipated changes of systems. System evolution occurs due to

◮ changing user requirements ◮ changing application contexts and environments ◮ feature extensions, removals and modifications ◮ products no longer maintained ◮ bug fixes and quality improvements

  • I. Schaefer

SFM-11:CONNECT 54 / 60

slide-76
SLIDE 76

Product Line Evolution

t2 = t1 + x Variants at t1

v1 v3 v2 v4 v3 v2

Variants at t2

  • I. Schaefer

SFM-11:CONNECT 55 / 60

slide-77
SLIDE 77

Evolving Delta-oriented Product Lines

t2 = t1 + x

Core 1 n

Core/Deltas at t1 Core/Deltas at t2

Core’ ’1 ’n’ Dynamic Delta

Modification of Core Modification of Deltas

  • I. Schaefer

SFM-11:CONNECT 56 / 60

slide-78
SLIDE 78

Dynamic Delta Modeling

Dynamic delta modules can

◮ add new class and interface declarations

to the core module or to delta modules

◮ modify existing class declarations by

  • adding new field and method definitions
  • modifying existing method definitions
  • simplifying classes by

removing redundant field and method declarations

Dynamic delta modules are more restrictive than spatial delta modules to avoid errors during (asynchronous) runtime evolution.

  • I. Schaefer

SFM-11:CONNECT 57 / 60

slide-79
SLIDE 79

Dynamic Delta Modeling - Example

dyndelta ExtendedGreeting { modifies class Greeter { // Adds a new method to the class Greeter adds String i_am_bob () { return ", I am Bob!"; } modifies String say_hello() { return = original() + this.i_am_bob(); } }

  • I. Schaefer

SFM-11:CONNECT 58 / 60

slide-80
SLIDE 80

Dynamic Delta Modeling - Example

Continuation

modifies delta De { modifies class Greeter { modifies String i_am_bob() {return ", ich bin Bob!" ;} } } modifies delta Nl { modifies class Greeter { modifies String i_am_bob() {return ", ick ben Bob!" ;} } } }

  • I. Schaefer

SFM-11:CONNECT 59 / 60

slide-81
SLIDE 81

Summary and Upcoming Features

This Tutorial

◮ Modeling of Concurrent Systems with Core ABS ◮ Modeling of Spatial Variability with µTVL, Delta Modeling, Product

Line Configuration, Product Selection

◮ Modeling of Temporal Variability with Dynamic Deltas ◮ Demos of Tool Suite and Development Environment

  • I. Schaefer

SFM-11:CONNECT 60 / 60

slide-82
SLIDE 82

Summary and Upcoming Features

This Tutorial

◮ Modeling of Concurrent Systems with Core ABS ◮ Modeling of Spatial Variability with µTVL, Delta Modeling, Product

Line Configuration, Product Selection

◮ Modeling of Temporal Variability with Dynamic Deltas ◮ Demos of Tool Suite and Development Environment

Upcoming Developments

◮ Improvement of Languages and Tool Support ◮ Type Checking of Product Lines ◮ Tool Support for Dynamic Deltas

  • I. Schaefer

SFM-11:CONNECT 60 / 60