The vision of Autonomic Computing and Self-Adaptive Software Systems aims at realizing software that autonomously manage itself in presence of varying environmental conditions. Feedback Control Loops (FCL) provide generic mechanisms for self-adaptation, however, incorporating them into software systems raises many challenges. The first part of this thesis addresses the integration challenge, i.e., forming the architecture connection between the underlying adaptable software and the adaptation engine. We propose a domain-specific modeling language, FCDL, for integrating adaptation mechanisms into software systems through external FCLs. It raises the level of abstraction, making FCLs amenable to automated analysis and implementation code synthesis. The language supports composition, distribution and reflection thereby enabling coordination and composition of multiple distributed FCLs. Its use is facilitated by a modeling environment, ACTRESS, that provides support for modeling, verification and complete code generation. The suitability of our approach is illustrated on three real-world adaptation scenarios. The second part of this thesis focuses on model manipulation as the underlying facility for implementing ACTRESS. We propose an internal Domain-Specific Language (DSL) approach whereby Scala is used to implement a family of DSLs, SIGMA, for model consistency checking and model transformations. The DSLs have similar expressiveness and features to existing approaches, while leveraging Scala versatility, performance and tool support. To conclude this thesis we discuss further work and further research directions for MDE applications to self-adaptive software systems.

1. Domain-Specific Modeling Language
for Self-Adaptive Software System
Architectures
Filip Křikava
PhD defense
Advisors: Philippe Collet and Johan Montagnat
CNRS, University of Nice Sophia Antipolis,
I3S Laboratory, MODALIS research group
November 22, 2013, Sophia Antipolis

2. Context and Motivation
Electronic Retailer - Application Diagram
Jeff Kephart - Autonomic Computing: The First Decade, ICAC’11 keynote
•
•
•
Ever growing complexity of computing systems
Taming this complexity by skilled IT professionals does not scale
New operation modes are needed
2

3. Towards Self-Adaptive Software Systems
•
Towards Self-Adaptive Software Systems
• Realizing system that adjusts themselves in accordance with some higher-level goals
3

4. Towards Self-Adaptive Software Systems
•
Towards Self-Adaptive Software Systems
• Realizing system that adjusts themselves in accordance with some higher-level goals
measures
Monitoring
events
decisions
Decision Making
Reconfiguration
sensors
effectors
Target System
Feedback Control Loop (FCL)
3
actions

5. Challenges
Engineering of self-adaptive software systems is a challenge
CONFIGURATIONS
API
AOP
+
Controller
-
⇥( N )
Target System
COMMANDS
Transduc
er
=
µ =
m
d
µ
d=
=
m
(N )µ
m
X
i=1
PROFILER
1
m
=
d
d
LOGS
Designing an adaptation engine
Integrating the adaptation
engine into the target system
4

6. Challenges
Engineering of self-adaptive software systems is a challenge
CONFIGURATIONS
API
AOP
+
Controller
-
⇥( N )
Target System
COMMANDS
Transduc
er
=
µ =
m
d
µ
d=
=
m
(N )µ
m
X
i=1
PROFILER
1
m
=
d
d
LOGS
Designing an adaptation engine
Integrating the adaptation
engine into the target system
4

7. Challenges
CONFIGURATIONS
API
AOP
+
Controller
-
⇥( N )
Target System
COMMANDS
Transduc
er
=
µ =
m
d
µ
d=
=
m
(N )µ
m
X
i=1
1
m
=
d
d
Integrating the adaptation engine into
the target system
Adaptation Engine
LOGS
Target System
Adhoc Implementations
•
•
•
PROFILER
Extensive handcrafting of non-trivial code
Cumbersome and error-prone
Accidental complexities
5

8. Challenges
CONFIGURATIONS
API
AOP
+
Controller
-
⇥( N )
Target System
COMMANDS
Transduc
er
=
µ =
m
d
µ
d=
=
m
(N )µ
m
X
i=1
1
m
=
d
d
Integrating the adaptation engine into
the target system
Adaptation Engine
PROFILER
LOGS
Target System
Reusing and adapting existing work
•
•
•
•
•
Often target specific types of adaptation problems (Bertran’12)
Require the use of certain adaptation mechanism (Garlan’04)
Applicable to single domain (Rouvoy’08) or technology (Asadollahi’09)
Do not support remoting or complex control schemes (Adamczyk’08, Gorton’06)
Limiting their applicability
6

9. Requirements
Identified requirements for integrating self-adaptation into software systems
Generality
•
•
Visibility
•
•
Domain-agnostic
Technology-agnostic
Reusability
•
Reusable FCL parts across adaptation scenarios
7
Explicit FCLs, their process and interactions
Verification support

10. Requirements
Identified requirements for integrating self-adaptation into software systems
Generality
•
•
Visibility
•
•
Domain-agnostic
Technology-agnostic
Reusability
•
Distribution
Reusable FCL parts across adaptation scenarios
Complex
control
•
•
Explicit FCLs, their process and interactions
Verification support
Composition
Reflection
7
•
Remote distribution of FCL

11. Requirements
Identified requirements for integrating self-adaptation into software systems
Generality
•
•
Visibility
•
•
Domain-agnostic
Technology-agnostic
Reusability
•
Distribution
Reusable FCL parts across adaptation scenarios
Complex
control
•
•
Explicit FCLs, their process and interactions
Verification support
•
Remote distribution of FCL
Tooling
•
•
Composition
Reflection
Lightweight approach
7
Prototyping
Automating

12. Objectives
“
Provide an approach to facilitate
systematic integration of self-adaptive
mechanisms into software systems through
feedback control loops.
”
8

13. Contributions
Integrating the adaptation engine into the target system
CONFIGURATIONS
API
AOP
+
Controller
-
⇥( N )
measures
Target System
decisions
Decision Making
COMMANDS
Transduc
er
=
µ =
m
d
µ
d=
=
m
(N )µ
PROFILER
Monitoring
m
X1
i=1
m
=
d
d
Reconfiguration
LOGS
events
sensors
effectors
actions
Target System
Contributions
Feedback Control Definition Language
Generality
Visibility
Reusability
Distribution
Complex control
Facilitates
language
use
The ACTRESS Modeling Environment
Tooling
The SIGMA Model Manipulation Languages
Lightweight approach
9
Facilitates
tooling
implementation

14. Plan
1. Feedback Control Definition Language
2. The ACTRESS Modeling Environment
3. The Sigma Model Manipulation Languages
4. Conclusions and Perspectives
10

15. Plan
1. Feedback Control Definition Language
2. The ACTRESS Modeling Environment
3. The Sigma Model Manipulation Languages
4. Conclusions and Perspectives
11

16. Feedback Control Definition Language
1. Raise the level of abstraction
Generality
Visibility
Reusability
General Purpose
Language (GPL)
2. Fine-grained decomposition of FCL elements
Monitoring
Decision Making
Reconfiguration
3. Explicit interactions
measures
decisions
events
Complex
control
actions
4. Provide reflection and composition capabilities
5. Embed remoting
Distribution
12

17. Feedback Control Definition Language
1. Raise the level of abstraction
2. Fine-grained decomposition of FCL elements
Domain-Specific Modeling
3. Explicit interactions
4. Provide reflection capabilities
5. Embed remoting
13

18. Feedback Control Definition Language
1. Raise the level of abstraction
2. Fine-grained decomposition of FCL elements
Domain-Specific Modeling
3. Explicit interactions
4. Provide reflection capabilities
5. Embed remoting
measures
Decision Making
Monitoring
events
decisions
Reconfiguration
sensors
effectors
actions
13

19. Feedback Control Definition Language
1. Raise the level of abstraction
2. Fine-grained decomposition of FCL elements
Domain-Specific Modeling
3. Explicit interactions
4. Provide reflection capabilities
5. Embed remoting
measures
Decision Making
Monitoring
events
•
decisions
Reconfiguration
sensors
effectors
actions
Feedback Control Loop
• Sequence of interconnected processes
• Inputs x State -> Output
• Reactive
• Concurrent
• Dynamic
13

20. Feedback Control Definition Language
1. Raise the level of abstraction
2. Fine-grained decomposition of FCL elements
Domain-Specific Modeling
3. Explicit interactions
4. Provide reflection capabilities
5. Embed remoting
actor
measures
Decision Making
Monitoring
events
•
decisions
actor
Reconfiguration
sensors
effectors
actor
actions
•
Feedback Control Loop
• Sequence of interconnected processes
• Inputs x State -> Output
• Reactive
• Concurrent
• Dynamic
The Actor Model
• Network of actors communicating via
•
•
•
•
13
message passing
Message x State -> Message(s)
Reactive
Concurrent
Dynamic

21. Feedback Control Definition Language
actor
actor
measures
Decision Making
Monitoring
events
•
actor
decisions
•
Reconfiguration
sensors
effectors
The Actor Model
• Network of actors communicating via
•
•
•
•
•
•
•
•
actions
Feedback Control Loop
• Sequence of interconnected processes
• Inputs x State -> Output
• Reactive
• Concurrent
• Dynamic
14
message passing
Message x State -> Message(s)
Reactive
Concurrent
Dynamic
Thread safe
Scalable
Remoting support
Programming support

22. Feedback Control Definition Language - Adaptive Element
measures
Monitoring
events
decisions
Decision Making
Reconfiguration
sensors
effectors
actions
in input
out output
Controller
Processor
out output
in input
in input
Processor
out output
in input
out output
Effector
Sensor
Target System
15

23. Feedback Control Definition Language - Adaptive Element
measures
Monitoring
events
decisions
Decision Making
Reconfiguration
sensors
effectors
actions
out output
in input
providedSensor
providedEffector
in input
out output
Controller
Processor
out output
in input
in input
Processor
out output
in input
out output
Effector
Sensor
Target System
15

24. Feedback Control Definition Language - Illustration
QoS management control of web servers by content delivery adaptation
•
•
•
Typical example of a control-based solution to a well-known and well-scoped problem
Design of a sophisticated control mechanisms
Integration left for adhoc implementation
16

25. Feedback Control Definition Language - Illustration
QoS management control of web servers by content delivery adaptation
Goal: maintain server load around some pre-set value
Idea: service time = fixed overhead + data-size dependent overhead
Prerequisite: preprocessed content (different quality and size)
Abdelzaher et al., 1999, 2002
17

26. Feedback Control Definition Language - Illustration
QoS management control of web servers by content delivery adaptation
Goal: maintain server load around some pre-set value
Idea: service time = fixed overhead + data-size dependent overhead
Prerequisite: preprocessed content (different quality and size)
/photo.jpg
/1/photo.jpg
full quality
/2/photo.jpg
degraded quality
Abdelzaher et al., 1999, 2002
17

27. Feedback Control Definition Language - Illustration
QoS management control of web servers by content delivery adaptation
Goal: maintain server load around some pre-set value
Idea: service time = fixed overhead + data-size dependent overhead
Prerequisite: preprocessed content (different quality and size)
/photo.jpg
/1/photo.jpg
full quality
/2/photo.jpg
degraded quality
d
n
loa
rmal
o
over
load
Abdelzaher et al., 1999, 2002
17

28. Feedback Control Definition Language - Illustration
QoS management control of web servers by content delivery adaptation
Goal: maintain server load around some pre-set value
Idea: service time = fixed overhead + data-size dependent overhead
Prerequisite: preprocessed content (different quality and size)
/photo.jpg
/1/photo.jpg
full quality
/2/photo.jpg
degraded quality
d
n
loa
rmal
o
over
load
serve from
tree #2
serve from
tree #1
Rejection
Level
...
Minimum Content
Full Content
Abdelzaher et al., 1999, 2002
17

29. Feedback Control Definition Language - Illustration
QoS management control of web servers by content delivery adaptation
Goal: maintain server load around some pre-set value
Idea: service time = fixed overhead + data-size dependent overhead
Prerequisite: preprocessed content (different quality and size)
/photo.jpg
/1/photo.jpg
full quality
/2/photo.jpg
degraded quality
d
n
loa
rmal
o
over
load
serve from
tree #2
serve from
tree #1
Rejection
Level
...
Minimum Content
Full Content
Abdelzaher et al., 1999, 2002
17

30. Feedback Control Definition Language - Illustration
QoS management control of web servers by content delivery adaptation
Goal: maintain server load around some pre-set value
Idea: service time = fixed overhead + data-size dependent overhead
Prerequisite: preprocessed content (different quality and size)
/photo.jpg
/1/photo.jpg
full quality
/2/photo.jpg
degraded quality
d
n
loa
rmal
o
over
load
serve from
tree #2
Using FCDL
serve from
tree #1
Generality
Visibility
Reusability
Rejection
Level
...
Minimum Content
Full Content
Abdelzaher et al., 1999, 2002
17

31. Feedback Control Definition Language - Illustration
QoS management control of web servers by content delivery adaptation
Goal: maintain server load around some pre-set value
Idea: service time = fixed overhead + data-size dependent overhead
Prerequisite: preprocessed content (different quality and size)
/photo.jpg
/1/photo.jpg
full quality
/2/photo.jpg
degraded quality
d
n
loa
rmal
o
over
load
serve from
tree #2
Using FCDL
serve from
tree #1
Generality
Rejection
Level
Visibility
Distribution
Reusability
Complex control
...
Minimum Content
Full Content
Abdelzaher et al., 1999, 2002
17

32. Feedback Control Definition Language - Illustration
1. Compute the number of requests (r) and size of responses (w)
2. Compute the requests rate (R), bandwidth (W) and utilization (U)
3. Compute severity of adaptation (G)
18

33. Feedback Control Definition Language - Illustration
1. Compute the number of requests (r) and size of responses (w)
processor Accumulator {
push in port input: long
pull out port sum: long
}
out sum
out sum
responseSizeCounter
: Accumulator
requestCounter
: Accumulator
in input
out requests
accessLogParser
: AccessLogParser
processor AccessLogParser {
push in port lines: String
push out port size: int
push out port requests: int
}
out size
in lines
out lines
file=/var/log/apache2/access.log
accessLog
: FileTailer
Generality
active sensor FileTailer {
push out port lines: String
Visibility
}
Reusability
access_log
19
property file: String

34. Feedback Control Definition Language - Illustration
2. Compute the requests rate (R), bandwidth (W) and utilization (U)
loadMonitor
: LoadMonitor
scheduler
: PeriodTrigger
out utilization
in requests
out output
in input
in size
initialPeriod=10s
out sum
out sum
responseSizeCounter
: Accumulator
requestCounter
: Accumulator
in input
out requests
accessLogParser
: AccessLogParser
out size
active processor PeriodTrigger<T> {
pull in port input: T
push out port output: T
in lines
out lines
file=/var/log/apache2/access_log
accessLog
: FileTailer
}
Generality
Visibility
Reusability
access_log
20
property initialPeriod = 10.seconds

35. Feedback Control Definition Language - Illustration
3. Compute severity of adaptation (G)
loadMonitor
: LoadMonitor
scheduler
: PeriodTrigger
out utilization
in requests
utilController
: UtilizationController
out output
in input
in size
in utilization
out contentTree
initialPeriod=10s
out sum
k=?
U*=?
out sum
responseSizeCounter
: Accumulator
requestCounter
: Accumulator
in input
out requests
accessLogParser
: AccessLogParser
out size
in lines
in contentTree
out lines
file=/var/log/apache2/access_log
accessLog
: FileTailer
adaptor
: ContentAdaptor
Generality
Visibility
Reusability
content_tree
access_log
21

36. Feedback Control Definition Language - Illustration
Complete model of the first prototype
composite ApacheQOS {
control
layer
ApacheQOS
loadMonitor
: LoadMonitor
scheduler
: PeriodTrigger
out utilization
in requests
out output
in input
in size
k=?
U*=?
in utilization
out sum
responseSizeCounter
: Accumulator
requestCounter
: Accumulator
in input
in input
out requests
system
layer
feature
feature
feature
feature
feature
feature
feature
out contentTree
initialPeriod=10s
out sum
feature accessLog = new FileTailer {
file = “/var/log/apache2/access_log”
}
utilController
: UtilizationController
accessLogParser
: AccessLogParser
file=/var/log/apache2/access_log
connect accessLog.lines to
accessLogParser.lines
connect accessLogParser.size to
responseSizeCounter.input
connect accessLogParser.requests to
requestsCounter.input
connect requestCounter.output to
loadMonitor.requests
connect responseSizeCounter.output to
loadMonitor.size
connect loadMonitor.utilization to
scheduler.input
connect scheduler.output to
utilController.utilization
connect utilController.contentTree to
adaptor.contentTree
out size
in lines
in contentTree
out lines
accessLog
: FileTailer
adaptor
: ContentAdaptor
}
Generality
Visibility
Reusability
22
accessLogParser = new AccessLogParser
requestCounter = new Accumulator
responseSizeCounter = new Accumulator
loadMonitor = new LoadMonitor
scheduler = new PeriodTrigger<Double>
utilController = new UtilizationController
adaptor = new ContentAdaptor

37. Feedback Control Definition Language - Composition
Hierarchical organization of Adaptive Elements
using composites
ApacheQOS
composite name
loadMonitor
: LoadMonitor
initialPeriod=10s
out utilization
control
layer
utilController
: UtilizationController
in requests
out output
in input
in size
in utilization
out contentTree
scheduler
: PeriodTrigger
out sum
k=?
U*=?
out sum
responseSizeCounter
: Accumulator
requestCounter
: Accumulator
in input
in input
system
layer
out size
in contentTree
out requests
composite ApacheWebServer {
ApacheWebServer
out size
property accessLogFile: String
!
accessLogParser
: AccessLogParser
out requests
in lines
in contentTree
out lines
port promotion
accessLog
: FileTailer
adaptor
: ContentAdaptor
feature accessLog = new FileTailer {
file = accessLogFile
}
in contentTree
out requests
out size
server
: ApacheWebServer
feature accessLogParser = new AccessLogParser
feature adaptor = new ContentAdaptor
!
connect accessLog.lines to accessLogParser.lines
file=/var/log/apache2/access_log
Generality
Visibility
promote accessLogParser.size
promote accessLogParser.requests
promote adaptor.contentTree!
Reusability
}
23

38. Feedback Control Definition Language - Composition
QOSControl
QOSControl
utilization
: UtilizationMonitor
out utilization
in size
in requests
in utilization
in input
out output
scheduler
: PeriodTrigger
utilController
: UtilizationController
out utilization
in utilization
in input
in requests
utilization
: UtilizationMonitor
utilController
: UtilizationController
in requests
out contentTree
in size
in size
scheduler
: PeriodTrigger
ApacheQOS
out contentTree
LighttpdQOS
in requests
in requests
out contentTree
control
layer
control
layer
out contentTree
in size
control
: QOSControl
in size
control
: QOSControl
out size
system
layer
system
layer
out size
out requests
out contentTree
in size
in requests
out contentTree
out output
in contentTree
apache
: ApacheWebServer
Generality
Visibility
Reusability
24
out requests
in contentTree
lighttpd
: LighttpdWebServer

39. Feedback Control Definition Language - Distribution
Distribution
Visibility
Remote Distribution of Adaptive Elements
Apache
ApacheQOS
endpoint=akka.tcp://actress@remote-main/user/ApacheQOS/control
in requests
in requests
out contentTree
in size
out contentTree
control
: QOSControl
ApacheQOS.control
in size
referenced feature
composite
out size
out requests
feature
out size
in contentTree
out requests
Apache.apache
in contentTree
apache: ApacheWebServer
endpoint=
akka.tcp://actress@remote-apache/user/Apache/apache
network
remote-main
remote-apache
// deployed at remote-apache
composite Apache {
feature apache = new ApacheWebServer { ... }
feature control = ref ApacheQOS.control @ "akka://remote-main/user/ApacheQOS/control"
}
// deployed at host remote-main
composite ApacheQOS {
feature control = new QOSControl { ... }
feature apache = ref Apache.apache @ "akka://remote-apache/user/Apache/apache"
// ...
}
25

40. Feedback Control Definition Language - Reflection
Adaptive Element Reflection
Complex
control
meta-control
layer
ApacheQOS
in load
Visibility
periodController
: PeriodController
provided in setPeriod
QOSControl
provided in setPeriod
out output
control
layer
out period
in requests
out contentTree
sysLoadTrigger
: PeriodTrigger
in size
in input
control
: QOSControl
setPeriod
promotion
system
layer
out output
out size
out requests
sysLoad
: SystemLoad
...
in contentTree
provided effector
in input
out output
...
scheduler
: PeriodTrigger
apache
: ApacheWebServer
active processor PeriodicTrigger<T> {
pull in port input: T
push out port output: T
provided effector setPeriod: Long
}
property initialPeriod = 10.seconds
composite QOSControl {
// ...
promote scheduler.setPeriod
// ...
}
26

41. Feedback Control Definition Language - Reflection
Complex
control
Adaptive Monitoring Pattern
Visibility
meta-control
layer
ApacheQOS
in load
Reusability
out period
periodControl
: AdaptiveMonitoring
provided in setPeriod
QOSControl
provided in setPeriod
in requests
control
layer
out contentTree
in size
control
: QOSControl
setPeriod
promotion
system
layer
out output
out size
out requests
sysLoad
: SystemLoad
in contentTree
...
provided effector
in input
out output
scheduler
: PeriodTrigger
apache
: ApacheWebServer
27
...

42. Feedback Control Definition Language - Interaction Contracts
out sum
in input
: Accumulator
•
•
Activated on input push request
Activated on sum pull request
28

43. Feedback Control Definition Language - Interaction Contracts
in reset
out sum
in input
out output
: Accumulator
•
•
•
•
•
•
•
Activated on input push request
Activated on reset push request
Activated on input / reset request
Activated on sum pull request
Activated on input push request always pushing data on output
Activated on reset push request always pushing data on output
....
29

44. Feedback Control Definition Language - Interaction Contracts
When it receives data on its input port, it
pushes to its output port the input value plus
the sum of all the input values it has received
since the last time the reset port was
triggered, similarly, when pulled on the sum
port, it returns the sum of all the input values
since the last reset, and finally receiving any
data on its reset port, sets the current
accumulated value back to 0.
if (!input.isEmpty()) {
value += input.get
output.send(value)
} else if (!reset.isEmpty()) {
reset.get()
value = 0
} else if (!sum.isEmpty()) {
sum.send(value)
} else {
throw new IllegalStateException("Invalid execution")
}
in reset
out sum
in input
out output
: Accumulator
•
•
•
Behavior not explicitly stated in the architecture - Black Box
Limits verification support
Limits code-generation support
30

45. Feedback Control Definition Language - Interaction Contracts
Interaction Contracts
Visibility
Describe allowed interactions among components
in reset
out sum
in input
processor Accumulator {
push in port reset: int
push in port input: long
pull out port sum: long
push out port output: long
out output
: Accumulator
31
}
act onInput(input; ; output)
act onSum(sum; ; )
act onReset(reset; ; )

46. Feedback Control Definition Language - Interaction Contracts
Interaction Contracts
Visibility
Describe allowed interactions among components
in reset
out sum
in input
processor Accumulator {
push in port reset: int
push in port input: long
pull out port sum: long
push out port output: long
out output
: Accumulator
}
act onInput(input; ; output)
act onSum(sum; ; )
act onReset(reset; ; )
Originally developed by Cassou et al. for SCC systems
•
Our extensions
•
•
•
•
•
•
Elements with multiple output ports
Multiple port connections
Composites
Composite interaction contract inference algorithm
Optional contracts
Completion verification algorithm
31

47. Plan
1. Feedback Control Definition Language
2. The ACTRESS Modeling Environment
3. The Sigma Model Manipulation Languages
4. Conclusions and Perspectives
32

48. ACTRESS Overview
The ACTRESS Modeling Environment
•
•
Reference implementation of FCDL based on Eclipse Modeling Framework
Facilitate the use of FCDL
Modeling
Code Generation
Verification
Tooling
33

49. ACTRESS - Modeling Support
xFCDL (Extended FCDL)
•
•
•
utilController
: UtilizationController
Textual DSL for authoring FCDL models
Additionally supports
• Modularity
• Java interoperability
• Implementation specification using Xbase
Eclipse IDE support
in utilization
k=?
U*=?
out contentTree
controller UtilizationController {
// ...
// interaction contract
act activate(utilization; ; contentTree)
// beginning of Xbase implementation
implementation xbase {
var G = M
// interaction contract
act activate {
// computes the error
val E = targetUtilization - utilization
// computes new extend of adaptation
G = G + k * E
// correct bounds
if (G < 0) G = 0
if (G > M) G = M
}
34
}
// returns the result
G

50. ACTRESS - Code Generation Support
ApacheQOS
loadMonitor
: LoadMonitor
out utilization
in requests
utilController
: UtilizationController
initialPeriod=10s
out output
in input
in size
in utilization
scheduler
: PeriodTrigger
out sum
out sum
responseSizeCounter
: Accumulator
requestCounter
: Accumulator
in input
k=?
U*=?
out contentTree
FCDL Model
in input
out size
out requests
in contentTree
server
: ApacheWebServer
Model-to-Text
transformation
ACTRESS
Domain
Framework
Code generator
Xbase compiled to Java
Skeleton implementation
ACTRESS Runtime
ApacheQOS
apache
control
utilization
accessLogParser
accessLog
adaptor
scheduler
composite
actor
containment
actor
actor with
event listener
responseSizeCounter
message
passing
requestCounter
loadMonitor
Executable System
35
utilController

51. ACTRESS - Code Generation Support
Skeleton Implementation
utilController
: UtilizationController
in utilization
@SuppressWarnings("all")
public class UtilizationControllerAct extends AdaptiveElementAct {
// ...
k=?
U*=?
protected double activate(final double utilization) {
// TODO: compute and output value for contentTree port
}
out contentTree
// ...
}
Prescriptive
Descriptive
Visibility
36

52. ACTRESS - Verification Support
FCDL Verification
37

53. ACTRESS - Verification Support
Model Well-Formedness
•
•
•
•
Data-type compatibility
Port connections
Required properties
and others
meta-model constraints
(SIGMA)
FCDL Verification
37

54. ACTRESS - Verification Support
Model Well-Formedness
•
•
•
•
Architecture
Data-type compatibility
Port connections
Required properties
and others
meta-model constraints
(SIGMA)
•
•
•
FCDL Verification
37
Consistency
Determinacy
Completeness
interaction contracts
verification
(SIGMA)

55. ACTRESS - Verification Support
Model Well-Formedness
•
•
•
•
Architecture
Data-type compatibility
Port connections
Required properties
and others
meta-model constraints
(SIGMA)
•
•
•
FCDL Verification
User Structural Constraints
@OCL(invDifferentSource="self.ports
->select(p | p.name = 'size' || p.name = 'requests') // select ports
->collect(p | p.connections) // select their connects
->collect(p | p.parent) // select owning instances
->asSet()->size() == 2 // there must be two different ones
")
processor LoadMonitor {
xFCDL OCL Annotations
37
Consistency
Determinacy
Completeness
interaction contracts
verification
(SIGMA)

56. ACTRESS - Verification Support
Model Well-Formedness
•
•
•
•
Architecture
Data-type compatibility
Port connections
Required properties
and others
meta-model constraints
(SIGMA)
•
•
•
Consistency
Determinacy
Completeness
interaction contracts
verification
(SIGMA)
FCDL Verification
User Structural Constraints
@OCL(invDifferentSource="self.ports
->select(p | p.name = 'size' || p.name = 'requests') // select ports
->collect(p | p.connections) // select their connects
->collect(p | p.parent) // select owning instances
->asSet()->size() == 2 // there must be two different ones
")
processor LoadMonitor {
xFCDL OCL Annotations
(
User Temporal Constraints
activate
→ (♦
FCDL to PROMELA
activate
transformation
SPIN model checker
37
activate ))
ac

57. ACTRESS Evaluation
Case Study 1
DAGMan 1
DAGMan 2
...
Users
Submit jobs
User Interface
Spawns
Submit
workflows
Executes
schedd
DAGMan N
HTCondor Client Host
HTCondor cluster
of worker nodes
38

58. ACTRESS Evaluation
Case Study 1
DAGMan 1
User Interface
DAGMan 2
...
Users
Submit jobs
Spawns
Submit
workflows
Executes
schedd
DAGMan N
HTCondor Client Host
HTCondor cluster
of worker nodes
Case Study 2
User Interface 1
Users
Submit
Submit
jobs
workflows
Users
Users
Executes
User Interface 2
Central schedd
...
HTCondor cluster
of worker nodes
User Interface N
38

59. FCDL / ACTRESS Evaluation
Generality
•
•
•
•
Visibility
Potentially any self-* property
FCDL is technology agnostic
xFCDL with Xbase depends on Java
ACTRESS runtime depends on Java
•
•
•
Reusability
•
Reused elements across scenarios
39
Explicit FCLs
Explicit AE
Explicit AE interactions

60. FCDL / ACTRESS Evaluation
Generality
•
•
•
•
Visibility
Potentially any self-* property
N ∗ = 1000,
FCDL is technology agnostic Nc = 5000, p = 5, ρ0 = 10
xFCDL with Xbase depends on Java
ACTRESS runtime depends on Java
•
•
•
Explicit FCLs
Explicit AE
Explicit AE interactions
Reusability
•
Reused elements across scenarios
Reuse
1
2
1
2
39

61. FCDL / ACTRESS Evaluation
Generality
•
•
•
•
Visibility
Potentially any self-* property
N ∗ = 1000,
FCDL is technology agnostic Nc = 5000, p = 5, ρ0 = 10
xFCDL with Xbase depends on Java
ACTRESS runtime depends on Java
•
•
•
Reusability
•
Distribution
Reused elements across scenarios
•
Complex control
•
Explicit FCLs
Explicit AE
Explicit AE interactions
Case Study 2 deployed on 10 Grid5000 hosts
Tooling
•
All case studies use hierarchical control
Eclipse based modeling environment
Reuse
1
2
1
2
39

62. FCDL / ACTRESS Evaluation
Generality
•
•
•
•
Visibility
Potentially any self-* property
N ∗ = 1000,
FCDL is technology agnostic Nc = 5000, p = 5, ρ0 = 10
xFCDL with Xbase depends on Java
ACTRESS runtime depends on Java
•
•
•
Reusability
•
Distribution
Reused elements across scenarios
•
Complex control
•
Explicit FCLs
Explicit AE
Explicit AE interactions
Case Study 2 deployed on 10 Grid5000 hosts
Tooling
•
All case studies use hierarchical control
Eclipse based modeling environment
Overall implementation effort
1
2
1
2
40

63. FCDL / ACTRESS Evaluation
Generality
•
•
•
•
Visibility
Potentially any self-* property
N ∗ = 1000, Nc = 5000,
FCDL is technology agnostic p = 5, ρ0 = 10
xFCDL with Xbase depends on Java
ACTRESS runtime depends on Java
•
•
•
Reusability
•
Distribution
Reused elements across scenarios
•
Complex control
•
Explicit FCLs
Explicit AE
Explicit AE interactions
Case Study 2 deployed on 10 Grid5000 hosts
Tooling
•
All case studies use hierarchical control
Eclipse based modeling environment
Overall implementation effort
1
Separation of concerns
2
1
2
41

64. Plan
1. Feedback Control Definition Language
2. The ACTRESS Modeling Environment
3. The Sigma Model Manipulation Languages
4. Conclusions and Perspectives
42

65. SIGMA
ACTRESS Modeling Environment
Model Manipulation
Model Consistency
Checking
Model
Transformations
Eclipse Modeling Framework (EMF)
43

66. SIGMA
ACTRESS Modeling Environment
Model Manipulation
Model Consistency
Checking
Model
Transformations
Eclipse Modeling Framework (EMF)
GPL
•
•
•
Low level of abstraction
Limited expressiveness
Accidental complexities
43

67. SIGMA
ACTRESS Modeling Environment
Model Manipulation
Model Consistency
Checking
Model
Transformations
Eclipse Modeling Framework (EMF)
GPL
•
•
•
External DSLs
•
•
•
•
•
Low level of abstraction
Limited expressiveness
Accidental complexities
43
Limited tool support
Limited versatility
Limited interoperability
Limited testability
Accidental complexities

68. SIGMA
ACTRESS Modeling Environment
Model Manipulation
Model Consistency
Checking
Model
Transformations
Eclipse Modeling Framework (EMF)
GPL
•
•
•
Low level of abstraction
Limited expressiveness
Accidental complexities
Internal DSLs
•
•
•
•
•
Internal DSLs in Scala for model manipulation
Embeds domain-specific constructs into a GPL
Small API
Efficient
Directly reuse the host language infrastructure
SIGMA
Lightweight approach
43
External DSLs
•
•
•
•
•
Limited tool support
Limited versatility
Limited interoperability
Limited testability
Accidental complexities

69. SIGMA
Quick Example
Check that all instances within a composite have unique names

70. SIGMA
Quick Example
Check that all instances within a composite have unique names
OCL
invariant UniqueNamesWithinType:
parent.allFeatures->forAll(e | e <> self implies e.name <> self.name);

71. SIGMA
Quick Example
Check that all instances within a composite have unique names
OCL
invariant UniqueNamesWithinType:
parent.allFeatures->forAll(e | e <> self implies e.name <> self.name);
SIGMA
def invUniqueNamesWithinType =
self.parent.allFeatures forall (e => e != self implies e.name != self.name)

72. SIGMA
Quick Example
Check that all instances within a composite have unique names
OCL
invariant UniqueNamesWithinType:
parent.allFeatures->forAll(e | e <> self implies e.name <> self.name);
SIGMA
def invUniqueNamesWithinType =
self.parent.allFeatures forall (e => e != self implies e.name != self.name)
•
•
•
Similar expressiveness
Easy to edit
Easy to test
•
•
Easy to debug
Easy to integrate into model
manipulation workflow

73. SIGMA
Quick Example
Check that all instances within a composite have unique names
OCL
invariant UniqueNamesWithinType:
parent.allFeatures->forAll(e | e <> self implies e.name <> self.name);
SIGMA
def invUniqueNamesWithinType =
self.parent.allFeatures forall (e => e != self implies e.name != self.name)
•
•
•
Similar expressiveness
Easy to edit
•
•
Easy to test
Easy to debug
Easy to integrate into model
manipulation workflow
def invUniqueNamesWithinType =
self.parent.allFeatures find (e => e != self && e.name == self.name) match {
case None => Passed
case Some(e) =>
Error(s”Element $e has the name”)
.quickFix(“Rename ‘${self.name}’ to ‘${self.name}’_2”) {
self.name += “_2”
}
}
•
•
Different levels of severity
User feedback
•
•
Inconsistency repair
and more

74. SIGMA
Architecture
Requirements
SIGMA
•
Tool support
•
Expressiveness
•
Usability
•
Model-to-Text Transformation
Model-to-Model Transformation
Task-specific
DSLs
Testability
Model Consistency Checking
Model Navigation
Model Modification
SIGMA EMF bridge
Scala
Eclipse Modeling Framework (EMF)
ANR-09-SEGI-012
ANR EMERGENCE
45
Common
Infrastructure

75. Plan
1. Feedback Control Definition Language
2. The ACTRESS Modeling Environment
3. The Sigma Model Manipulation Languages
4. Conclusions and Perspectives
46

76. Summary
•
Combining self-adaptive software systems with principles of MDE to provide
systematic and tooled approach for integrating control mechanisms into
software applications.
•
Design of a domain-specific modeling language for defining complex
feedback control loop architectures on a flexible, high level of abstraction.
•
A reference implementation and tools facilitating the language use including
modeling, code synthesis and verification support.
•
A family of internal DSLs in Scala for lightweight model manipulations
including model consistency checking, model transformations.
47

77. Summary
•
Combining self-adaptive software systems with principles of MDE to provide
systematic and tooled approach for integrating control mechanisms into
software applications.
•
Design of a domain-specific modeling language for defining complex
feedback control loop architectures on a flexible, high level of abstraction.
•
A reference implementation and tools facilitating the language use including
modeling, code synthesis and verification support.
•
A family of internal DSLs in Scala for lightweight model manipulations
including model consistency checking, model transformations.
•
Materialized in 2 software stacks
•
The ACTRESS Modeling Environment
http://fikovnik.github.io/Actress
•
The SIGMA Model Manipulation DSLs
http://fikovnik.github.io/Sigma
47

78. Perspectives
Short-term further work
•
•
Improvements in both ACTRESS and SIGMA implementations
Extend the validation on more use cases, gather more experience
Further Research Directions
•
On Self-Adaptive Software Systems
•
•
•
•
Towards Higher-Level Abstractions
Towards Model@run.time
Towards DSL composition
On Model Manipulations
•
•
•
Towards deep DSL embedding
Towards domain-specific optimization and error checking
Taming the leaking abstraction of internal DSLs
48

79. Merci!
•
P. Collet, F. Křikava, J. Montagnat, M. Blay-Fornarino, D. Manset. Issues and Scenarios for SelfManaging Grid Middleware, Workshop on Grids meets autonomic computing (GMAC '10), 2010
•
F. Křikava, P. Collet, M. Blay-Fornarino. Uniform and Model-Driven Engineering of Feedback
Control Systems, International Conference on Autonomic Computing (ICAC'11), 2011 short paper
•
F. Křikava, P. Collet. A Reflective Model for Architecting Feedback Control Systems,
International Conference on Software Engineering and Knowledge Engineering (SEKE'11), 2011
•
F. Křikava, P. Collet. On the Use of an Internal DSL for Enriching EMF Models, Workshop on OCL
and Textual Modelling (OCL'12), 2012
•
F. Křikava, P. Collet, R. France. Actor-based Runtime Model of Adaptable Feedback Control
Loops, Workshop on models@run.time (MRT'12), 2012
•
F. Křikava, P. Collet, R. France. ACTRESS: Domain-Specific Modeling of Self-Adaptive Software
Architectures, International Conference on Dependable and Adaptive Distributed Systems, SAC’14
(to appear)
•
F. Křikava, P. Collet, R. France. Exploring Internal Domain-Specific Languages for Model
Manipulations, International Conference on Programing Languages, SAC’14, short paper (to
appear)
SIGMA model manipulation DSLs have been also presented at:
•
•
EclipseCon Europe 2012 Modeling Symposium − Enriching EMF Models with Scala, Ludwigsburg, Germany
Scala Workshop 2013 − Model Manipulation Using Embedded DSLs in Scala, Montpellier, France
49