Page 1
Abstract Behavioral Specification ofDistributed Object-Oriented Systems
Reiner Hahnle
Department of Computer Science, Software Engineering Group
HATS International School onFormal Models for Components and Objects
University Residential Center of Bertinoro
24–28 September, 2012
http://www.hats-project.eu
R. Hahnle HATS-FMCO Bertinoro 120924 0 / 72
Page 2
Structure of this Talk
1 Introduction: The HATS Project
2 The ABS Modeling Language
3 Software Product Line Engineering
4 Tool Chain, Case Studies
R. Hahnle HATS-FMCO Bertinoro 120924 1 / 72
Page 3
Part I: Introduction
The HATS Project
R. Hahnle HATS-FMCO Bertinoro 120924 2 / 72
Page 4
HATS Facts
HATS: Highly Adaptable & Trustworthy Software Using Formal Models
I FP7 FET focused call Forever Yours
I Project started 1 March 2009, 48 months runtime
I Integrated Project, academically driven
I 10 academic partners, 2 industrial research, 1 SME
I 8 countries
I 805 PM, EC contribution 5,64 Me over 48 months
I web: www.hats-project.eu
R. Hahnle HATS-FMCO Bertinoro 120924 3 / 72
Page 5
The EC FP7 Project HATS
In a nutshell, we . . .
develop a tool-supported formal modeling language (ABS)
for the design, analysis, and implementation of
highly adaptable software systems characterized by a
high expectations on trustworthiness
for target software systems that are . . .
I concurrent, distributed
I object-oriented
I built from components
I adaptable (variability, evolvability), hence reusable
Main focus: Software Product Line Engineering
R. Hahnle HATS-FMCO Bertinoro 120924 4 / 72
Page 6
Motivation
Why formal?
I informal notations can’t describe software behavior with rigor:
concurrency, compositionality, correctness, security,resource consumption . . .
I formalization ⇒ more advanced tools• more complex products• higher automation: cost-efficiency
Why adaptable?
I feature-rich software, deployment scenarios
I changing requirements (technology/market)
I evolution of software in unanticipated directions
I language-supported adaptability is a key tosuccessful reuse
R. Hahnle HATS-FMCO Bertinoro 120924 5 / 72
Page 7
Motivation
Why formal?
I informal notations can’t describe software behavior with rigor:
concurrency, compositionality, correctness, security,resource consumption . . .
I formalization ⇒ more advanced tools• more complex products• higher automation: cost-efficiency
Why adaptable?
I feature-rich software, deployment scenarios
I changing requirements (technology/market)
I evolution of software in unanticipated directions
I language-supported adaptability is a key tosuccessful reuse
R. Hahnle HATS-FMCO Bertinoro 120924 5 / 72
Page 8
Mind the Gap!
Design-oriented, architectural, structuralUML, FDL, etc.
Implementation levelJML, SPEC#, etc.
Minimalistic foundationalπ-calculus, ambient c., etc.
Abstract BehaviouralSpecification
ABS
+ executability
+ verifiability
+ usability
Realistic Abstract
R. Hahnle HATS-FMCO Bertinoro 120924 6 / 72
Page 9
Mind the Gap!
Design-oriented, architectural, structuralUML, FDL, etc.
Implementation levelJML, SPEC#, etc.
Minimalistic foundationalπ-calculus, ambient c., etc.
Abstract BehaviouralSpecification
ABS
+ executability
+ verifiability
+ usability
Realistic Abstract
R. Hahnle HATS-FMCO Bertinoro 120924 6 / 72
Page 10
A Single-Source Technology forHighly Adaptive, Concurrent Software Systems
UML class diagram
UML seqence chartbytecode
feature descr. lang.
runtime components
Maude
Scala Petri net
UML Behavior tree
Prosa specificationABS
R. Hahnle HATS-FMCO Bertinoro 120924 7 / 72
Page 11
The Main Innovations of HATS
A formal, executable, abstract, behavioral modeling language
I Combines state-of-art in verification, concurrency, specification, andprogramming languages communities
I Adaptability drives the design
Scalable tools developed in tandem with ABS
I Incremental, compositional
I Analytic and generative, static and dynamic techniques
Formalization of PLE-based development as main application
I Seamless, formalized models from feature level to executable code
I Define FM-based development methodology for PLE
R. Hahnle HATS-FMCO Bertinoro 120924 8 / 72
Page 12
The HATS Approach
A tool-supported formal modeling language forbuilding 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 scalability
3 Methodological, technological, and tool frameworkintegrating HATS tool architecture and ABS language
R. Hahnle HATS-FMCO Bertinoro 120924 9 / 72
Page 13
The HATS Approach
A tool-supported formal modeling language forbuilding 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 scalability
3 Methodological, technological, and tool frameworkintegrating HATS tool architecture and ABS language
R. Hahnle HATS-FMCO Bertinoro 120924 9 / 72
Page 14
Part II: ABS
The Abstract Behavioral Modeling Language (ABS)
R. Hahnle HATS-FMCO Bertinoro 120924 10 / 72
Page 15
Main Design Goals of ABS
ABS is designed with analysis/code generation tools in mind
I Expressivity carefully traded off with analysability• permit incremental/compositional static and dynamic analyses
I State-of-art programming language concepts• ADTs + functions + objects• type-safety, data race-freeness by design• modules, components• pluggable type systems, annotations
I Layered concurrency model
Upper tier: asynchronous, no shared state, actor-basedLower tier: synchronous, shared state, cooperative multitasking
I Modeling of variability/deployment a first-class concept• feature models, delta-oriented programming• deployment components
I Not only code analysis, but also code generation/model mining
R. Hahnle HATS-FMCO Bertinoro 120924 11 / 72
Page 16
ABS Design Principles
I Uniform, formal semantics
I Layered architecture: simplicity, separation of concerns
I Executability: simulation, rapid prototyping, visualization
I Abstraction: underspecification, non-determinism
I Tool integration as Eclipse-plugin, easy to install & use
I Feature-based reuse realized as delta-oriented programming
I Formalization of product families
Out of scope for this lecture (but addressed in ABS):
I Real-time ABS with deployment components ⇒ Einar’s lecture!
I Code evolvability supported through runtime components
I Behavioural interface contracts
R. Hahnle HATS-FMCO Bertinoro 120924 12 / 72
Page 17
Layered ABS Language Design
Real-Time ABSDeploymentComponents
DeltaModelingLanguages
RuntimeComponents
Local Contracts, Assertions
Behavioral Interface Specs
Syntactic Modules
Asynchronous Communication
Concurrent Object Groups (COGs)
Imperative Language
Object Model
Pure Functional Programs
Algebraic (Parametric) Data Types
Core ABS
Full ABS
⇐
⇐⇐
R. Hahnle HATS-FMCO Bertinoro 120924 13 / 72
Page 18
Layered ABS Language Design
Real-Time ABSDeploymentComponents
DeltaModelingLanguages
RuntimeComponents
Local Contracts, Assertions
Behavioral Interface Specs
Syntactic Modules
Asynchronous Communication
Concurrent Object Groups (COGs)
Imperative Language
Object Model
Pure Functional Programs
Algebraic (Parametric) Data Types
Core ABS
Full ABS
⇐
⇐⇐
R. Hahnle HATS-FMCO Bertinoro 120924 13 / 72
Page 19
Built-In Data Types and Operators
Built-In Data Types
data Bool = True | False;
data Unit = Unit; // for void return typesdata Int; // 4, 2323, −23data String; // ”Hello World”
Built-In Operators (Java-like Syntax)
I All types: == !=
I Bool: ~ && ||
I Int: + - * / % < > <= >=
I String: +
Construction of side effect-free operator expressions as usual
R. Hahnle HATS-FMCO Bertinoro 120924 14 / 72
Page 20
Built-In Data Types and Operators
Built-In Data Types
data Bool = True | False;
data Unit = Unit; // for void return typesdata Int; // 4, 2323, −23data String; // ”Hello World”
Built-In Operators (Java-like Syntax)
I All types: == !=
I Bool: ~ && ||
I Int: + - * / % < > <= >=
I String: +
Construction of side effect-free operator expressions as usual
R. Hahnle HATS-FMCO Bertinoro 120924 14 / 72
Page 21
User-Defined Algebraic 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>); // predefinedList<Int> l = [1,2,3]; // concrete list syntax
Type Synonyms
type Saft = Juice;
type Fruits = List<Fruit>;
R. Hahnle HATS-FMCO Bertinoro 120924 15 / 72
Page 22
User-Defined Algebraic 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>); // predefinedList<Int> l = [1,2,3]; // concrete list syntax
Type Synonyms
type Saft = Juice;
type Fruits = List<Fruit>;
R. Hahnle HATS-FMCO Bertinoro 120924 15 / 72
Page 23
User-Defined Algebraic 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>); // predefinedList<Int> l = [1,2,3]; // concrete list syntax
Type Synonyms
type Saft = Juice;
type Fruits = List<Fruit>;
R. Hahnle HATS-FMCO Bertinoro 120924 15 / 72
Page 24
Functions and Pattern Matching
def Int length(IntList list) = // function names lower−casecase list { // definition by case distinction and matchingNil => 0 ; // data constructor patternCons(n, ls) => 1 + length(ls) ;
// data constructor pattern with pattern variable_ => 0 ; // underscore pattern (anonymous variable)
} ;
def Int sign(Int n) =
case n {
0 => 0 ; // literal patternn => if (n > 0) then 1 else -1 ; // bound variable pattern
} ;
def A head<A>(List<A> list) = // parametric functioncase list {
Cons(x, xs) => x;
} ;
If no pattern in a case expression matches, a runtime error resultsR. Hahnle HATS-FMCO Bertinoro 120924 16 / 72
Page 25
Syntactic Sugar for Functions
Implicit Selector Functions
data File = File(String path, Int content) ;
// implicitly defines selector functions:def String path(File f) = ... ;
def Int content(File f) = ... ;
N-Ary Constructors for Associative Collection Types
data Set<A> = EmptySet | Insert(A, Set<A>);
def Set<A> set<A>(List<A> l) = // convention: lower case type namecase l {
Nil => EmptySet;
Cons(hd, tl) => Insert(hd, set(tl));
} ;
Set<Int> s = set[1,2,3];
R. Hahnle HATS-FMCO Bertinoro 120924 17 / 72
Page 26
Syntactic Sugar for Functions
Implicit Selector Functions
data File = File(String path, Int content) ;
// implicitly defines selector functions:def String path(File f) = ... ;
def Int content(File f) = ... ;
N-Ary Constructors for Associative Collection Types
data Set<A> = EmptySet | Insert(A, Set<A>);
def Set<A> set<A>(List<A> l) = // convention: lower case type namecase l {
Nil => EmptySet;
Cons(hd, tl) => Insert(hd, set(tl));
} ;
Set<Int> s = set[1,2,3];
R. Hahnle HATS-FMCO Bertinoro 120924 17 / 72
Page 27
Module System
Module System (inspired by Haskell)
module Drinks; // upper−case, defines syntactic scope, part of type namesexport Drink, Milk; // Water is not usable by other modulesimport * from N; // import anythingdata Drink = Water | Milk;
...
module Bar; // new module scopeimport Drinks.Drink; // qualified importimport Milk from Drinks; // unqualified importimport Water from Drinks; // not allowed − compilation error
Abstract Data Types
module Stack; // Module as Abstract Data Typeexport Stack<A>; // type constructors are hidden, only functions usabledata Stack<A> = EmptyStack | push(A, Stack<A>); // hiddendef Stack<A> createStack<A>(List<A> s) = ... ; // usable
R. Hahnle HATS-FMCO Bertinoro 120924 18 / 72
Page 28
Module System
Module System (inspired by Haskell)
module Drinks; // upper−case, defines syntactic scope, part of type namesexport Drink, Milk; // Water is not usable by other modulesimport * from N; // import anythingdata Drink = Water | Milk;
...
module Bar; // new module scopeimport Drinks.Drink; // qualified importimport Milk from Drinks; // unqualified importimport Water from Drinks; // not allowed − compilation error
Abstract Data Types
module Stack; // Module as Abstract Data Typeexport Stack<A>; // type constructors are hidden, only functions usabledata Stack<A> = EmptyStack | push(A, Stack<A>); // hiddendef Stack<A> createStack<A>(List<A> s) = ... ; // usable
R. Hahnle HATS-FMCO Bertinoro 120924 18 / 72
Page 29
ABS Standard Library
ABS Standard Library provided as Module
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) = ...
...
R. Hahnle HATS-FMCO Bertinoro 120924 19 / 72
Page 30
Demo
Eclipse ABS Perspective, Database.abs, F3, abslang.abs
R. Hahnle HATS-FMCO Bertinoro 120924 20 / 72
Page 31
Layered ABS Language Design
Real-Time ABSDeploymentComponents
DeltaModelingLanguages
RuntimeComponents
Local Contracts, Assertions
Behavioral Interface Specs
Syntactic Modules
Asynchronous Communication
Concurrent Object Groups (COGs)
Imperative Language
Object Model
Pure Functional Programs
Algebraic (Parametric) Data Types
Core ABS
Full ABS
⇐⇐
R. Hahnle HATS-FMCO Bertinoro 120924 21 / 72
Page 32
Object Model: Interfaces
Interfaces
I Provide reference types of objects (implementation abstraction)
I Subinterfaces allowed
I Multiple inheritance allowed
I Java-like syntax
I Reference types may occur in data types, but:no method calls in function definitions (possible side effects)
interface Baz { ... }
interface Bar extends Baz {
// method signaturesUnit m();
Bool foo(Bool b);
}
data BarList = Nil | Cons(Bar, BarList);
R. Hahnle HATS-FMCO Bertinoro 120924 22 / 72
Page 33
Object Model: Classes
Classes
I Only for object construction
I Class name is not a type
I Classes can implement several interfaces
I No code inheritance (instead delta-oriented programming is used)
// class declaration with parameters, implicitly defines constructorclass Foo(T x, U y) implements Bar, Baz {
// field declarationsBool flag = False; // primitive type field initialization mandatoryU g; // object type field initialization optional{ // optional class initialization blockg = y;
}
Unit m() { } // method implementationsBool foo(Bool b) { return ~b; }
}
R. Hahnle HATS-FMCO Bertinoro 120924 23 / 72
Page 34
Names of Interfaces and Classes
Suggested Naming Convention
I Class names only used at object creation
I All type declarations strictly to interfaces
Use e.g. Name for interface and NameImpl for implementing class
Modules Revisited
Type names and class names can be (and must be) imported/exported
R. Hahnle HATS-FMCO Bertinoro 120924 24 / 72
Page 35
Class Initialization, Active Classes
Class Initialization
I Optional class parameters = fields = constructor signature
I Fields with primitive types must be initialized when declared
I Optional init block executed first
Active Classes
I Characterized by presence of run() method
I Objects from active classes start activity after initialization
I Passive classes react only to incoming calls
Unit run() {
// active behavior ...}
R. Hahnle HATS-FMCO Bertinoro 120924 25 / 72
Page 36
Imperative Constructs
Sequential Control Flow
Loop while (x) { ... }
Conditional if (x == y) { ... } [else { ... }]
Synchronous method call x.m()
Local State Update and Access (Assignment)
Object creation new Car(Blue);
Field read x = [this.]f; (only on this object)
Field assignment [this.]f = 5; (only on this object)
Strong Encapsulation
ABS fields are object private (not merely class private as Java)
I Field access of a different object only via getter/setter methods
R. Hahnle HATS-FMCO Bertinoro 120924 26 / 72
Page 37
Other Statements
Skip
Do Nothing skip;
Return
Return value return PureExpr;
Must be last statement of method body
I Standard idiom: collect return value in result variable
Expressions as Statement
Execute for side effect Expr;
R. Hahnle HATS-FMCO Bertinoro 120924 27 / 72
Page 38
Blocks
ABS is a Block-structured Language
Blocks appear as:
I Statement
I Method body
I Optional class initialization block (between field and method decls.)I Optional implicit “main” method at end of module
• serves as starting point for program execution• at least one main block necessary for executing a program• module with main block selectable as execution target
Blocks
I Sequence of variable declarations and statements
I Data type variables are initialized, reference types default to null
I Statements in block are scope for declared variables
R. Hahnle HATS-FMCO Bertinoro 120924 28 / 72
Page 39
Demo
Eclipse ABS Perspective, F4, Account.abs
R. Hahnle HATS-FMCO Bertinoro 120924 29 / 72
Page 40
Layered ABS Language Design
Real-Time ABSDeploymentComponents
DeltaModelingLanguages
RuntimeComponents
Local Contracts, Assertions
Behavioral Interface Specs
Syntactic Modules
Asynchronous Communication
Concurrent Object Groups (COGs)
Imperative Language
Object Model
Pure Functional Programs
Algebraic (Parametric) Data Types
Core ABS
Full ABS
⇐⇐
R. Hahnle HATS-FMCO Bertinoro 120924 30 / 72
Page 41
Concurrency Model
Layered Concurrency Model
Upper tier: asynchronous, no shared state, actor-based
Lower tier: synchronous, shared state, cooperative multitasking
Concurrent Object Groups (COGs)
I Unit of distribution
I Own heap of objectsI Cooperative multitasking inside COGs
• One processor, several tasks• Intra-group communication by synchronous/asynchronous method calls• Multiple tasks originating from asynchronous calls within COG
I Inter-group communication only via asynchronous method calls
R. Hahnle HATS-FMCO Bertinoro 120924 31 / 72
Page 42
Cooperative Multitasking inside COGs
Multitasking
I A COG can have multiple tasks
I Only one is active, all others are suspended
I Asynchronous calls create new tasksI Synchronous calls block caller thread
• Java-like syntax: target.methodName(arg1, arg2, ...)
Scheduling
I Cooperative by special scheduling statements• Explicit decision of modeller
I Non-deterministic otherwise• User-defined configuration of schedulers via annotations
R. Hahnle HATS-FMCO Bertinoro 120924 32 / 72
Page 43
Object and COG Creation
Local Object Creation
this:A
new B();
COG Creation
this:A
new cog B();
R. Hahnle HATS-FMCO Bertinoro 120924 33 / 72
Page 44
Object and COG Creation
Local Object Creation
this:A new B();
COG Creation
this:A
new cog B();
R. Hahnle HATS-FMCO Bertinoro 120924 33 / 72
Page 45
Object and COG Creation
Local Object Creation
this:A new B(); this:A b:B
COG Creation
this:A
new cog B();
R. Hahnle HATS-FMCO Bertinoro 120924 33 / 72
Page 46
Object and COG Creation
Local Object Creation
this:A new B(); this:A b:B
COG Creation
this:A
new cog B();
R. Hahnle HATS-FMCO Bertinoro 120924 33 / 72
Page 47
Object and COG Creation
Local Object Creation
this:A new B(); this:A b:B
COG Creation
this:A new cog B();
R. Hahnle HATS-FMCO Bertinoro 120924 33 / 72
Page 48
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
R. Hahnle HATS-FMCO Bertinoro 120924 33 / 72
Page 49
Far and Near References
cog
object
near reference
far reference
LEGEND
R. Hahnle HATS-FMCO Bertinoro 120924 34 / 72
Page 50
Typesystem for Far and Near References
Pluggable Type and Inference System
I Statically distinguishes near from far references
I Ensures that synchronous calls are only done on near references
{
[Near] Ping ping = new PingImpl();
[Far] Pong pong = new cog PongImpl();
ping.ping("Hi"); // okpong.pong("Hi"); // error: synchronous call on far reference
}
I Most annotations can be inferred automatically (safe approximation)
R. Hahnle HATS-FMCO Bertinoro 120924 35 / 72
Page 51
Asynchronous Method Calls
Asynchronous Method Calls
I Syntax: target ! methodName(arg1, arg2, ...)
I Sends an asynchronous message to the target object
I Creates new task in COG of targetI Caller continues execution and allocates a future to store the result
• Fut<T> v = o!m(e);
R. Hahnle HATS-FMCO Bertinoro 120924 36 / 72
Page 52
Scheduling
Unconditional Scheduling
I suspend command yields control to other task in COG
I Unconditional scheduling point
Conditional Scheduling
I await g, where g is a polling guardI Guards are monotonically behaving expression, inductively defined as:
• b - where b is a side-effect-free boolean expression• f? - future guards• g & g - conjunction (not Boolean operator)
I Yields task execution until guard is true(continue immediately if guard is true already)
R. Hahnle HATS-FMCO Bertinoro 120924 37 / 72
Page 53
Synchronization and Blocking
Reading Futures
I f.get - reads future f and blocks execution until result is available
I Deadlocks possible (use static analyzer for detection)I Programming idiom: use await f? to prevent blocking (safe access)
• Fut<T> v = o!m(e);...; await v?; r = v.get;
Blocking vs. Suspension
Suspension lets other task in same COG continue (if any)
Blocking no task in same COG can continue until future resolved
R. Hahnle HATS-FMCO Bertinoro 120924 38 / 72
Page 54
Summary: ABS Concurrency Model
Method calls with shared heap access encapsulated in COGs
Distributed computation: asynch. calls/message passing/separate heap
COG
I One activity at a time
I One lock
I Cooperative scheduling
I Callbacks (recursion) ok
I Shared access to data
COG′COG′′
asynchr.call
message passing
no reentrance
insame thread
this:A new B(); this:A b:B
this:A new cog B(); this:A b:B
R. Hahnle HATS-FMCO Bertinoro 120924 39 / 72
Page 55
Summary: ABS Concurrency Model
Method calls with shared heap access encapsulated in COGs
Distributed computation: asynch. calls/message passing/separate heap
···
···
···
Heap
Lock >
COG′COG′′
asynchr.call
message passing
no reentrance
insame thread
this:A new B(); this:A b:B
this:A new cog B(); this:A b:B
R. Hahnle HATS-FMCO Bertinoro 120924 39 / 72
Page 56
Summary: ABS Concurrency Model
Method calls with shared heap access encapsulated in COGs
Distributed computation: asynch. calls/message passing/separate heap
···
···
···
Heap
Lock >
COG′COG′′
asynchr.call
message passing
no reentrance
insame thread
this:A new B(); this:A b:B
this:A new cog B(); this:A b:B
R. Hahnle HATS-FMCO Bertinoro 120924 39 / 72
Page 57
Demo
Driver.abs, Far/Near, Run as Java Backend (Debug)
R. Hahnle HATS-FMCO Bertinoro 120924 40 / 72
Page 58
Annotations and Assertions
Assertions
assert PureExpr;
To be used for runtime assertion checking or during formal verification
Annotations
Methods (and classes, interfaces) can carry annotations:
I Local contracts, including invariants
I Type annotations before any declaration
Predefined [LocationType: Near] T n; or briefly [Near] T n;
Meta annotation
[TypeAnnoptation] // declares data type as type annotationdata LocationType = Far | Near | Somewhere | Infer;
Easy realization of pluggable type systems
I Code instrumentation (e.g., resources, time bounds) ⇒ Einar’s lecture
R. Hahnle HATS-FMCO Bertinoro 120924 41 / 72
Page 59
Interaction with Environment
ABS has no I/O (implementation-independent)
Foreign Language Interface, ABS side
import * from ABS.FLI;
interface Hi { String hello(String msg); }
[Foreign]
class HiImpl implements Hi {
String hi(String msg) { return "default implementation"; }
}
Foreign Language Interface, Java side
I Extend Java class HiImpl c generated by ABS with desired behavior
I In Java use types ABSString, etc., inabs.backend.java.lib.types.*
R. Hahnle HATS-FMCO Bertinoro 120924 42 / 72
Page 60
Interaction with Environment
ABS has no I/O (implementation-independent)
Foreign Language Interface, ABS side
import * from ABS.FLI;
interface Hi { String hello(String msg); }
[Foreign]
class HiImpl implements Hi {
String hi(String msg) { return "default implementation"; }
}
Foreign Language Interface, Java side
I Extend Java class HiImpl c generated by ABS with desired behavior
I In Java use types ABSString, etc., inabs.backend.java.lib.types.*
R. Hahnle HATS-FMCO Bertinoro 120924 42 / 72
Page 61
Formal Semantics
SOS-style Semantics
Reduction rules on ABS runtime configurations
o[b,C , σ] || n〈b, o, σ, s〉 || b[l ] || · · ·
object
class state
task
PC
lock
COG >/⊥
Task id is used as future
A Typical Reduction Rule: creation of a new COG
n〈b, o, σ, T z = new cog C(v);s〉 →b′(>) || n′〈b′, o ′, σ′init , stask〉 || o ′[b′,C , σinit ] || n〈b, o, σ, s{z/o ′}〉
b′, o ′, n′ new; Tf ; s ′ init block C ; σinit = Tf ; stask = s ′{this/o ′; suspend}
R. Hahnle HATS-FMCO Bertinoro 120924 43 / 72
Page 62
Formal Semantics
SOS-style Semantics
Reduction rules on ABS runtime configurations
o[b,C , σ] || n〈b, o, σ, s〉 || b[l ] || · · ·
object
class state
task
PC
lock
COG >/⊥
Task id is used as future
A Typical Reduction Rule: creation of a new COG
n〈b, o, σ, T z = new cog C(v);s〉
→b′(>) || n′〈b′, o ′, σ′init , stask〉 || o ′[b′,C , σinit ] || n〈b, o, σ, s{z/o ′}〉
b′, o ′, n′ new; Tf ; s ′ init block C ; σinit = Tf ; stask = s ′{this/o ′; suspend}
R. Hahnle HATS-FMCO Bertinoro 120924 43 / 72
Page 63
Formal Semantics
SOS-style Semantics
Reduction rules on ABS runtime configurations
o[b,C , σ] || n〈b, o, σ, s〉 || b[l ] || · · ·
object
class state
task
PC
lock
COG >/⊥
Task id is used as future
A Typical Reduction Rule: creation of a new COG
n〈b, o, σ, T z = new cog C(v);s〉 →b′(>)
|| n′〈b′, o ′, σ′init , stask〉 || o ′[b′,C , σinit ] || n〈b, o, σ, s{z/o ′}〉b′, o ′, n′ new; Tf ; s ′ init block C ; σinit = Tf ; stask = s ′{this/o ′; suspend}
R. Hahnle HATS-FMCO Bertinoro 120924 43 / 72
Page 64
Formal Semantics
SOS-style Semantics
Reduction rules on ABS runtime configurations
o[b,C , σ] || n〈b, o, σ, s〉 || b[l ] || · · ·
object
class state
task
PC
lock
COG >/⊥
Task id is used as future
A Typical Reduction Rule: creation of a new COG
n〈b, o, σ, T z = new cog C(v);s〉 →b′(>) || n′〈b′, o ′, σ′init , stask〉
|| o ′[b′,C , σinit ] || n〈b, o, σ, s{z/o ′}〉b′, o ′, n′ new; Tf ; s ′ init block C ; σinit = Tf ; stask = s ′{this/o ′; suspend}
R. Hahnle HATS-FMCO Bertinoro 120924 43 / 72
Page 65
Formal Semantics
SOS-style Semantics
Reduction rules on ABS runtime configurations
o[b,C , σ] || n〈b, o, σ, s〉 || b[l ] || · · ·
object
class state
task
PC
lock
COG >/⊥
Task id is used as future
A Typical Reduction Rule: creation of a new COG
n〈b, o, σ, T z = new cog C(v);s〉 →b′(>) || n′〈b′, o ′, σ′init , stask〉 || o ′[b′,C , σinit ]
|| n〈b, o, σ, s{z/o ′}〉b′, o ′, n′ new; Tf ; s ′ init block C ; σinit = Tf ; stask = s ′{this/o ′; suspend}
R. Hahnle HATS-FMCO Bertinoro 120924 43 / 72
Page 66
Formal Semantics
SOS-style Semantics
Reduction rules on ABS runtime configurations
o[b,C , σ] || n〈b, o, σ, s〉 || b[l ] || · · ·
object
class state
task
PC
lock
COG >/⊥
Task id is used as future
A Typical Reduction Rule: creation of a new COG
n〈b, o, σ, T z = new cog C(v);s〉 →b′(>) || n′〈b′, o ′, σ′init , stask〉 || o ′[b′,C , σinit ] || n〈b, o, σ, s{z/o ′}〉
b′, o ′, n′ new; Tf ; s ′ init block C ; σinit = Tf ; stask = s ′{this/o ′; suspend}
R. Hahnle HATS-FMCO Bertinoro 120924 43 / 72
Page 67
Formal Semantics
SOS-style Semantics
Reduction rules on ABS runtime configurations
o[b,C , σ] || n〈b, o, σ, s〉 || b[l ] || · · ·
object
class state
task
PC
lock
COG >/⊥
Task id is used as future
A Typical Reduction Rule: creation of a new COG
n〈b, o, σ, T z = new cog C(v);s〉 →b′(>) || n′〈b′, o ′, σ′init , stask〉 || o ′[b′,C , σinit ] || n〈b, o, σ, s{z/o ′}〉
b′, o ′, n′ new; Tf ; s ′ init block C ; σinit = Tf ; stask = s ′{this/o ′; suspend}
R. Hahnle HATS-FMCO Bertinoro 120924 43 / 72
Page 68
Part III: Software Product Line Engineering
Feature Modelling and Software Product Lines
R. Hahnle HATS-FMCO Bertinoro 120924 44 / 72
Page 69
Background: Software Product Line Engineering
FeatureModel
Family Engineering
Product LineArtefacts Base
FeatureSelection
Application Engineering Product
R. Hahnle HATS-FMCO Bertinoro 120924 45 / 72
Page 70
Vision: A Model-Centric Development Method for PLE
Product Line Modelsexpressed in HATS ABS with
uniform formal semantics
consistencyanalysis
correctnessof reuse
familyvisualization
test casegeneration
validation,verification
codegeneration
productvisualization
rapidprototyping
test casegeneration
validation,verification
family evo-lution
productevolution
Family Engineering
Application Engineering[Schaefer & Hahnle, IEEE Computer, Feb. 2011]
R. Hahnle HATS-FMCO Bertinoro 120924 46 / 72
Page 71
Layered ABS Language Design
Real-Time ABSDeploymentComponents
DeltaModelingLanguages
RuntimeComponents
Local Contracts, Assertions
Behavioral Interface Specs
Syntactic Modules
Asynchronous Communication
Concurrent Object Groups (COGs)
Imperative Language
Object Model
Pure Functional Programs
Algebraic (Parametric) Data Types
Core ABS
Full ABS
⇓
R. Hahnle HATS-FMCO Bertinoro 120924 47 / 72
Page 72
Modelling Variability with ABS
Core ABS +
1 Feature Model documents variability abstractly
2 Delta Modules define units of behaviour
3 Configuration connects features to behaviour
4 Product Selection specifies deployment configurations
R. Hahnle HATS-FMCO Bertinoro 120924 48 / 72
Page 73
The Case for Feature-Oriented Programming
Feature Hierarchy often incompatible with Class Hierarchy
I Modern SW development (notjust SPFE) often feature-driven
I Mismatch between artefactscreated in analysis vs. codingphases
I Results in brittle/awkward classhierarchies
I “Built-in” disconnect betweenanalysts and implementors
Achieve separation of concerns: hierarchy vs. functionality of features
R. Hahnle HATS-FMCO Bertinoro 120924 49 / 72
Page 74
The Case for Feature-Oriented Programming
Feature Hierarchy often incompatible with Class Hierarchy
I Modern SW development (notjust SPFE) often feature-driven
I Mismatch between artefactscreated in analysis vs. codingphases
I Results in brittle/awkward classhierarchies
I “Built-in” disconnect betweenanalysts and implementors
Achieve separation of concerns: hierarchy vs. functionality of features
R. Hahnle HATS-FMCO Bertinoro 120924 49 / 72
Page 75
Feature Modelling by ExampleFeature Diagram of Account Example
Account
Type
Check Save
Overdraft FeeInt amount in [0..5]Int interest
interest=0 interest>0
excludes
R. Hahnle HATS-FMCO Bertinoro 120924 50 / 72
Page 76
Feature Modelling Language µTVL
µTVL: micro Textual Variability Language
Subset of TVL [Classen et al., SoCP 76(12):1130–1143, 2011]
I Attributes: only integers and booleans (no reals, enumerated types)
I Feature extensions: only additional constraints
I But: Multiple roots for orthogonal variability
R. Hahnle HATS-FMCO Bertinoro 120924 51 / 72
Page 77
“Account” ExampleFeature Model µTVL representation
root Account {
group allof {
Type {
group oneof {
Check {ifin: Type.i == 0;},
Save {ifin: Type.i > 0;
exclude: Overdraft;}
}
Int i; // interest rate of account},
opt Fee {Int amount in [0..5];},
opt Overdraft
}
}
R. Hahnle HATS-FMCO Bertinoro 120924 52 / 72
Page 78
“Accounts” ExampleSemantics
Straightforward translation to Boolean/Integer constraint formula
0 ≤ Account ≤ 1 ∧Type→ Account ∧Overdraft† → Account ∧Fee† → Account ∧Type + Fee† + Overdraft† = 3 ∧0 ≤ Type ≤ 1 ∧Check→ Type ∧ Save→ Type ∧ Save→ ¬Overdraft ∧Check + Save = 1 ∧0 ≤ Check ≤ 1 ∧ 0 ≤ Save ≤ 1 ∧ 0 ≤ Fee† ≤ 1 ∧ 0 ≤ Overdraft† ≤ 1 ∧Fee→ Fee† ∧ Overdraft→ Overdraft† ∧0 ≤ Save ≤ 1 ∧ 0 ≤ Check ≤ 1 ∧Fee→ (Fee.amount >= 0 ∧ Fee.amount <= 5) ∧Check→ (Type.i = 0) ∧ Save→ (Type.i > 0).
R. Hahnle HATS-FMCO Bertinoro 120924 53 / 72
Page 79
Feature Model Semantics
ABS constraint solver can:
I find solutions for a feature model
I check whether a product selection is a solution of a feature model
Product Selection |= JFeature ModelK
R. Hahnle HATS-FMCO Bertinoro 120924 54 / 72
Page 80
Delta Modelling
A software reuse mechanism aligned to feature-driven development
I No subclassing, only subtyping (no extends, only implements)
I No traits, mixins, . . .
Instead: Delta Modelling
I Base product (the core) with minimal functionality
I Variants (products) obtained by applying deltas to the base product
R. Hahnle HATS-FMCO Bertinoro 120924 55 / 72
Page 81
Delta Modelling
A software reuse mechanism aligned to feature-driven development
I No subclassing, only subtyping (no extends, only implements)
I No traits, mixins, . . .
Instead: Delta Modelling
I Base product (the core) with minimal functionality
I Variants (products) obtained by applying deltas to the base product
R. Hahnle HATS-FMCO Bertinoro 120924 55 / 72
Page 82
Application of Delta Modules
Core Software Product
Delta1 · · · Deltan
apply deltas
I Delta modules add, remove or modify classes
I Class modifications:add, remove or wrap fields and methods, add new interfaces, . . .
I Granularity of deltas at the method level
I Compiler checks applicability of deltas and generates resulting product
R. Hahnle HATS-FMCO Bertinoro 120924 56 / 72
Page 83
Core Accounts
module Account;
interface Account {
Int deposit(Int x);
}
class AccountImpl(Int aid, Int balance) implements Account {
Int deposit(Int x) {
balance = balance + x;
return balance;
}
}
R. Hahnle HATS-FMCO Bertinoro 120924 57 / 72
Page 84
Delta Modules of Accounts
delta DFee (Int fee); // Implements feature Feeuses Account;
modifies class AccountImpl {
modifies Int deposit(Int x) {
Int result = x;
if (x>=fee) result = original(x-fee);
return result;
}
}
delta DSave (Int i); // Implements feature Saveuses Account;
modifies class AccountImpl {
removes Int interest; // field removed & added with new initial valueadds Int interest = i; // modification of init blocks not supported
}
R. Hahnle HATS-FMCO Bertinoro 120924 58 / 72
Page 85
Application of Delta Modules
class AccountImpl(Int aid, Int balance)
implements Account {
Int interest = 0;
... }
delta DSave(3);
modifies class AccountImpl {
removes Int interest;
adds Int interest = 3; }
class AccountImpl(Int aid, Int balance)
implements Account {
Int interest = 3;
... }
R. Hahnle HATS-FMCO Bertinoro 120924 59 / 72
Page 86
Product Line Configuration
Two models: Feature Model and Delta Model (feature implementation)
FeatureModel
Core
Deltas
Modules
Configuration
How are they connected?
Product Configuration Language:
I application conditions to associate features and delta modules
I temporal delta ordering (partial)
I feature attribute value passing to delta modules
R. Hahnle HATS-FMCO Bertinoro 120924 60 / 72
Page 87
Product Line Configuration
Two models: Feature Model and Delta Model (feature implementation)
FeatureModel
Core
Deltas
Modules
Configuration
How are they connected? Product Configuration Language:
I application conditions to associate features and delta modules
I temporal delta ordering (partial)
I feature attribute value passing to delta modules
R. Hahnle HATS-FMCO Bertinoro 120924 60 / 72
Page 88
Product Line Configuration Example
productline Accounts;
features Type, Fee, Overdraft, Check, Save;
delta DType (Type.i) when Type ;
delta DFee (Fee.amount) when Fee ;
delta DOverdraft after DCheck when Overdraft ;
delta DSave (Type.i) after DType when Save ;
delta DCheck after DType when Check ;
I application condition (ensure suitable feature implementation)
I feature attribute value passing
I order of delta application (conflict resolution)
R. Hahnle HATS-FMCO Bertinoro 120924 61 / 72
Page 89
Product Selection
FeatureModel
ProductSelection
Configuration
ensuressatisfaction
Core
Deltas
Modules
SoftwareProduct
associates
guides
Co
de
Gen
eration
I Compiler flattens delta and core modules into core ABS model
R. Hahnle HATS-FMCO Bertinoro 120924 62 / 72
Page 90
Product Selection
FeatureModel
ProductSelection
Configuration
ensuressatisfaction
Core
Deltas
Modules
SoftwareProduct
associates
guides
Co
de
Gen
eration
I Compiler flattens delta and core modules into core ABS model
R. Hahnle HATS-FMCO Bertinoro 120924 62 / 72
Page 91
Examples of Product Selection
// basic productproduct CheckingAccount (Type{i=0},Check);
// Account with Fee and parameterproduct AccountWithFee (Type{i=0},Check,Fee{amount=1});
// should be refusedproduct SavingWithOverdraft (Type{i=1},Save,Overdraft);
R. Hahnle HATS-FMCO Bertinoro 120924 63 / 72
Page 92
Demo
Run Configurations
R. Hahnle HATS-FMCO Bertinoro 120924 64 / 72
Page 93
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 94
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
Java
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 95
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
Java
Classes
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 96
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
Java
Classes
Classes
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 97
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
Java
Classes
Classes
Classes
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 98
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
Java
Classes
Classes
Classes
Classes
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 99
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
Java
Classes
Classes
Classes
Classes
Classes
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 100
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
ABS
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 101
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
ABS
Delta Modeling
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 102
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
ABS
Delta Modeling
Components, Modules
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 103
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
ABS
Delta Modeling
Components, Modules
Actors
COGs
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 104
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
ABS
Delta Modeling
Components, Modules
Actors
COGs
Classes
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 105
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
ABS
Delta Modeling
Components, Modules
Actors
COGs
Classes
Algebraic Data Types
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 106
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
ABS
Delta Modeling
Components, Modules
Actors
COGs
Classes
Algebraic Data Types
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 107
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
ABS
Delta Modeling
Components, Modules
Actors
COGs
Classes
Algebraic Data Types
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 108
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
ABS
Delta Modeling
Components, Modules
Actors
COGs
Classes
Algebraic Data Types
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 109
Choice of Modeling Level
Application
Product variability
Architecture
Concurrency, distribution
Functionality
Data structures
ABS
Delta Modeling
Components, Modules
Actors
COGs
Classes
Algebraic Data Types
R. Hahnle HATS-FMCO Bertinoro 120924 65 / 72
Page 110
Part IV: Tool Chain, Case Studies
State of Implementation
R. Hahnle HATS-FMCO Bertinoro 120924 66 / 72
Page 111
The ABS Basic Tool Chain
Feature models, Productselections, Configurations,
Delta modules, Core ABS codeEmacs Mode
Parser
Extended AST
Rewriter
Core AST
Name Resolution
Resolved AST
Type Checker
Type-Checked AST
ABS Integrated Development Environment
Java Back EndMaude Back End Core ABS code gen.
Maude Files Java Files Core ABS Files
Maude VM Java VM
external data
internal data
ABS tool
existing tool
Legend
R. Hahnle HATS-FMCO Bertinoro 120924 67 / 72
Page 112
Capabilities of the ABS Tool Set
I ABS IDE (Eclipse-based), parser, compiler, type checker
I Type-based far/near analysis immersed into IDE
I Java, Maude, Scala† code generation
I Execution visualization
I Behavioral verification
I Monitor inlining
I Runtime components†
I Deployment components with timing constraints
I A type system for feature models and deltas∗
I Deadlock analysis†
I Automated resource (time, space) analysis ⇒ Elvira
I Automated test case generation
I Functional verification with a program logic (based on KeY)†
(† = under construction, ∗ = under construction)R. Hahnle HATS-FMCO Bertinoro 120924 68 / 72
Page 113
Beyond “Hello World”
Case Studies
I Trading System (CoCoME)
I Model of “Availability-to-Promise” functionality of SAP Hana DB
I Fredhopper Access Service (FAS) by SDL
• part of replication system of e-commerce application• model based on Java code of actual product• runtime vs. simulation cost described by linear polynomial
0
17.5
35
52.5
70
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 200
7500
15000
22500
30000
Runn
ing
time
[s]
Environments
Sim
ulat
ion
cost
Model simulation cost Implementation running time
R. Hahnle HATS-FMCO Bertinoro 120924 69 / 72
Page 114
Further Reading
E. B. Johnsen, R. Hahnle, J. Schafer, R. Schlatte, and M. Steffen.ABS: A core language for abstract behavioral specification.In B. Aichernig, F. S. de Boer, and M. M. Bonsangue, editors, Proc. 9thInternational Symposium on Formal Methods for Components and Objects (FMCO2010), volume 6957 of LNCS, pages 142–164. Springer-Verlag, 2011.
D. Clarke, N. Diakov, R. Hahnle, E. B. Johnsen, I. Schaefer, J. Schafer,R. Schlatte, and P. Y. H. Wong.Modeling Spatial and Temporal Variability with the HATS Abstract BehavioralModeling Language.In M. Bernardo and V. Issarny, editors, Formal Methods for Eternal NetworkedSoftware Systems, volume 6659 of Lecture Notes in Computer Science, pages417–457. Springer-Verlag, 2011.
R. Hahnle, M. Helvensteijn, E. B. Johnsen, M. Lienhardt, D. Sangiorgi, I. Schaefer,and P. Y. H. Wong.HATS abstract behavioral specification: the architectural view.In B. Beckert, F. Damiani, and D. Gurov, editors, Proc. 10th InternationalSymposium on Formal Methods for Components and Objects (FMCO 2011),Torino, Italy, Lecture Notes in Computer Science. Springer-Verlag, to appear, 2012.
. . . + the tutorial that will be written based on my lectures
R. Hahnle HATS-FMCO Bertinoro 120924 70 / 72
Page 115
Resources
Case studies, papers available at http://www.hats-project.eu/
Documentation, code available at http://tools.hats-project.eu/
R. Hahnle HATS-FMCO Bertinoro 120924 71 / 72
Page 116
Summary
I ABS, a language for abstract modeling of realistic systems
I Designed with analysability in mind
I Integrated tool set for design, analysis, and generation of artefacts
I Delta-oriented programming as feature-based reuse principle
I Formalization of product lines relates features and theirimplementation
R. Hahnle HATS-FMCO Bertinoro 120924 72 / 72