Hyper-Agility: A Model-Driven Software Agility from Design-Time to Run-Time

1
 
Hyper-Agility:
A Model-Driven Software Agility
from Design-Time to Run-Time
Dr. Benoit Combemale
benoit.combemale@irisa.fr
http://www.irisa.fr/triskell/perso_pro/combemale
With the help (and the slides) of:
Jean-Marc Jézéquel, Olivier Barais, Brice Morin, and Gregory Nain

Hyper-Agility:
A Model-Driven Software Agility
from Design-Time to Run-Time
1

Benoit Combemale (IRISA, Triskell), Oct. 2010.
Agile Software Development
2
Agile ( Software Development )

Agile Software
3
( Agile Software ) Development

Outline
4
• The Need for Hyper-Agility
• From Software Product-Lines (SPL) …
… to Dynamic Adaptive Systems (DAS)
• (Aspect-Oriented) Modeling from Design to Runtime
• Models@Runtime to Support Dynamic Adaptation

Manifesto for
Agile Software Development
• Individuals and interactions
!over processes and tools
• Working software
!over comprehensive documentation
• Customer collaboration
!over contract negotiation
• Responding to change
!over following a plan
5

The need for
Agile Software @ Design Time
6

The need for
6
- Reutilisability
- Durability

The need for
6
- Reutilisability
- Durability
- Platform

The need for
6
- Reutilisability
- Durability
- Platform
Time To Market!
=> Large Scale Agile Development

(A) Manifesto for
• Individuals and interactions (over processes and tools)
➡ separation of concerns
• Working software (over comprehensive documentation)
➡ early execution, validation & verification
• Customer collaboration (over contract negotiation)
➡ domain-specific concept
• Responding to change (over following a plan)
➡ automatic (re-)composition
7

(A) Manifesto for
➡ separation of concerns
➡ early execution, validation & verification
➡ domain-specific concept
➡ automatic (re-)composition
7
➡ Technological Support for Agile Development!

Software Product Lines (SPL)
8

• Families of related software products
8

• The products have a common part and a variable part
8

...
• color = {black}
• full keyboard, touch screen, stylus
• MMS
• GPS
• TCP/IP
• Internet calling
Nokia Product Line
Nokia 3710 Nokia 5230 Nokia 5800 Nokia N900
• color = {plum}
• keypad,large keys
• MMS
• GPS
• TCP/IP
• FM Radio
• color = {white,black}
• touch screen
• MMS
• GPS
• TCP/IP
• FM Radio
• color = {red, blue, black}
• keypad, touch screen, stylus
• MMS
• GPS
• TCP/IP
• FM Radio
8

...
• color = {black}
• MMS
• GPS
• TCP/IP
Nokia Product Line
• color = {plum}
• MMS
• GPS
• TCP/IP
• FM Radio
• touch screen
• MMS
• GPS
• TCP/IP
• FM Radio
• MMS
• GPS
• TCP/IP
• FM Radio
Common
features
8

...
Variable features:
• color
• input method
• radio
• color = {black}
• MMS
• GPS
• TCP/IP
Nokia Product Line
• color = {plum}
• MMS
• GPS
• TCP/IP
• FM Radio
• touch screen
• MMS
• GPS
• TCP/IP
• FM Radio
• MMS
• GPS
• TCP/IP
• FM Radio
Common
features
8

Benoit Combemale (IRISA, Triskell), Oct. 2010. 9
The need for
Agile Software @ Run Time

• Home-automation to help disabled people stay home
• Aging society
• Hospital have limited resources, rooms, etc
•"Very short stays
• Long stays very expensive for people and society
• Houses, flats, etc should be equipped
• How do we produce a program for each of them:
• Individuals and interactions
• Working software
• Customer collaboration
• Responding to change
Example Application Domain
10

EnTiMid : Integrating IoS & IoT  
(Grégory Nain PhD, cf. [ServiceWave ’08])
•OSGi based
•MDE centric
•Generative Approach
Controlling Boiler/Shutters from GoogleAgenda through a browser or an iPhone
11

Entimid
Cf demonstration at « fete de la science 2009 »
http://www.irisa.fr/videos/fete-sciences-2009/
12

Many Different Needs 1/2Picturefromhttp://www.apt.gc.ca
•Living at home
•Motion troubles
•Memory loss
•Speaks French (only)
•Home equiped with :
•LonWorks (lights)
•Velux (shutters)
Mrs. Dupont
13

Many Different Needs 2/2
•English student
•Living at home
•He had an accident
•He likes technology
•Wheelchair equipped with
remote access for:
•Lights and shutters (KNX)
•Multimedia (UPnP)
Picturefromhttp://ditwww.epﬂ.ch
Mr. John Doe
14

# Software Product Lines (SPL)
Their needs
Medical/technical staff should be able to
•Check their health state
•Check home conﬁguration (shutters, lights, heaters…)
Both
Mrs. Dupont Mr. Doe
Some daily tasks should be
automated (motion troubles)
or reminded (memory loss).
Would like to control
everything remotely, with a
uniﬁed protocol
15

#Protocols
! Low-level protocols: KNX, X2D, X10, etc
! High-level protocols: http, UPnP, DPWS, etc
#Devices
! Lights, heaters, shutters, etc
#Web services
!GoogleAgenda, skype, WeatherForecast, MSN
!PaaS: Nurse as a Service, Food Delivery, Ooshop
#Adaptation to handicap/current health state
! Motion, memory, perception, etc
#Dynamic reconfiguration
➡Dynamic Adaptable System
Different variability dimensions
16

(A) Manifesto for
Agile Software @ Run Time
17
➡ multiple variability dimensions
➡ dynamic adaptation
➡ user-driven dynamic adaptation
➡ context-sensitive and safe dynamic adaptation

Outline
18

Autonomic Computing
Jeffrey O. Kephart, David M. Chess, "The Vision of Autonomic Computing",
IEEE Computer, vol. 36, no. 1, pp. 41-50, Jan. 2003, doi:10.1109/MC.2003.1160055
19

Towards more complex DAS
• Dynamic Adaptive Software (DAS) development:
! Adaptation logic often embedded into application logic
! Adaptation logic hard-coded using low-level APIs
! Readability, maintainability, and communication with other
stakeholder not easy
• Exponential growth of possible configurations
! Convergence with Dynamic Software Product Lines
! N features, N tending to be larger and larger
• 2N potential program configurations, 2N x (2N-1) transitions
20

#Explosion of the number of possible configurations of Entimid
! 1014 possible configurations! " 1028 transitions!
#Dynamic Adaptation
! Evolution of the handicap
! No service interruption
• Rebooting the system cannot be a solution (lives depend on the system)
#Reliability
! Safe migration path  
from a valid configuration to another valid configuration
! Performance issue (time) not critical
Challenging Example [ICSE’09]
21

Related works
22

Related works
Dynamic Adaptation
Reliability, Validation
Variability Management
U
22

Related works
B. Cheng et al. 
ICSE’06, AOSD’09
Dynamic Adaptation
Reliability, Validation
Variability Management
J. Whittle et al. 
MODELS’07
B. Morin et al. 
MODELS’08
S. Appel et al. 
ICSE’06 M. Mezini et al.
FSE’04
E. Figueiredo et al. 
ICSE’08
K. Czarnecki et al.
GPCE’06
P. David et al.
SC’06
F. Fleurey et al.
Models@Run.Time’08
Hallsteinsen et al.
Computer’08
OSGi, Fractal, 
OpenCOM, etc
Garlan et al. 
Computer’04
U Oreizy et al. 
ICSE’98
22

#How to validate DAS?
! Specify everything!
• all the configurations: >1014
• all the transitions: ~1028
! Model checking, code generation
#Problems
! Explosion: Time consuming, error-prone
! Evolution of the system (not predicted)
• Stop all -> Evolve the specifications -> model check
-> re-generate -> re-deploy
Validation VS Variability management…
23

#How to manage dynamic variability?
! Do not focus on configurations!
• Write reconfiguration scripts, encapsulating « features »
! Depending on the context and/or user needs
• Choose the most adapted scripts
• Executes all the selected scripts to dynamically adapt the system
#Problems
! Scripts written by hand (calls to reconfiguration API)
! Interactions, dependencies between scripts?
! Does the configuration (after executing scripts) make sense?
• Hopefully yes…
Validation VS Variability management…
24

•Focus on variability, not on configurations
•Build (derive) configurations when needed
• JIT, On demand at runtime, caching…
•Validate configurations before actual adaptation
•Automate the reconfiguration process
DSPL for Agile Software @ Run Time
25

Outline
26

Naive Model Driven Engineering

Modelling activity

Modelling activity
Code Model

Modelling activity
Functionality
Code Model

Modelling activity
Safety
Reliability
Security, survivability,
robustness
Functionality
Code Model
Fault tolerance

Aspect Oriented  
Model Driven Engineering

Distribution
Fault tolerance
Security
Functional behavior
Book
state : String
User
borrow
return
deliver
setDamaged
reser
ve
Use case model
Platform
Model
Aspect Oriented  

Distribution
Fault tolerance
Security
Functional behavior
Book
state : String
User
borrow
return
deliver
setDamaged
reser
ve
Use case model
Platform
Model
Aspect Oriented  
AOMDE = Pleonasm because
a Model is an Abstraction of an
Aspect of Reality for a given Purpose

Distribution
Fault tolerance
Security
Functional behavior
Book
state : String
User
borrow
return
deliver
setDamaged
reser
ve
Use case model
Platform
Model
Aspect Oriented  
Design
Model

Distribution
Fault tolerance
Security
Functional behavior
Book
state : String
User
borrow
return
deliver
setDamaged
reser
ve
Use case model
Platform
Model
Aspect Oriented  
Design
Model
Code
Model

Distribution
Fault tolerance
Security
Functional behavior
Book
state : String
User
borrow
return
deliver
setDamaged
reser
ve
Use case model
Platform
Model
Aspect Oriented  
Design
Model
Code
Model
Change one Aspect and
Automatically Re-Weave:
From AORE, SPL to DAS

Distribution
Fault tolerance
Security
Functional behavior
Book
state : String
User
borrow
return
deliver
setDamaged
reser
ve
Use case model
Platform
Model
Aspect Oriented  
Design
Model
Code
Model
Change one Aspect and
Automatically Re-Weave:
From AORE, SPL to DAS
★ Supports about MDE available at http://www.irisa.fr/triskell/perso_pro/combemale/teaching/mde/
★ Vincent Mahé, Benoit Combemale, Juan Cadavid, "Crossing Model Driven Engineering and Agility: Preliminary Thought on
Beneﬁts and Challenges", In 3rd Workshop on Model-Driven Tool & Process Integration, in conjunction with ECMFA'10, 2010.

Weaving Aspects: SmartAdapters
(Brice Morin PhD)
• SmartAdapters: a generic framework for AOM
!Built with Kermeta (a tool to build tools)
!Can be adapted to different modeling languages
• Aspect Model
!What?
➡Advice model = model fragment
!Where?
➡Pointcut model = model fragment
!How?
➡Composition protocol = imperative script
29

Meta-code  
generator
code  
generator
Metamodel
(conforms to MOF)
Aspect Model
(conforms to Metamodel)
MOF
(M3 Level)
Metamodel
(M2 Level)
require require
Java EMF +
Drools* code
produces produces
*Drools (JBoss Rules)
(meta-)
metamodels
input
(meta-)models
SmartAdapters @ Design Time
30

Meta-code  
generator
code  
generator
Metamodel
(conforms to MOF)
Aspect Model
MOF
(M3 Level)
Metamodel
(M2 Level)
require require
Java EMF +
Drools* code
produces produces
(meta-)
metamodels
input
(meta-)models
Written in
Kermeta/KET
30

Meta-code  
generator
code  
generator
Metamodel
(conforms to MOF)
Aspect Model
MOF
(M3 Level)
Metamodel
(M2 Level)
require require
Java EMF +
Drools* code
produces produces
(meta-)
metamodels
input
(meta-)models
Written in
Kermeta/KET
Visitor on the metamodel:
- 2 passes for the pointcut
- 2 passes for the advice
30

Java EMF +Drools
code Runtime AOM
Weaver
In memory base model
In memory woven model
SmartAdapters @ Run Time
31

! Adoption/Ease of Use
! " Directly rely on domain concepts (here, architecture)
! Expressiveness
! "Flexible pointcut language (model snippet)
! "Advice Sharing
! Performances
! " Compilation to Java/EMF + Drools
! " Weaving «in memory»
! Agility
! " Generative techniques
! Tool support
! " Integrated into DiVA Studio
AOM @ Run Time: Conclusion
32

Outline
33

Big picture
Running 
system
34

Big picture
Model 
@runtime
Running 
system
34

Big picture
Model 
@runtime
Running 
system
Metamodel
34

Big picture
Device
controllers
Light Shutter
Model 
@runtime
Running 
system
Metamodel
EnTiMid
34

Big picture
Device
controllers
Light Shutter
Model 
@runtime
Running 
system
Metamodel
EnTiMid Design-time 
Validation
34

Big picture
Device
controllers
Light Shutter
Model 
@runtime
Running 
system
EnTiMid Design-time 
Validation
34

Big picture
Device
controllers
Light Shutter
Model 
@runtime
Running 
system
EnTiMid
Picturefromhttp://www.apt.gc.ca
Had a flu last week
" stayed in bed
" a nurse every day
Design-time 
Validation
34

Big picture
Device
controllers
Light Shutter
Target 
configuration
Model 
@runtime
Running 
system
EnTiMid
Had a flu last week
" stayed in bed
" a nurse every day
Derivation 
AOM
Design-time 
Validation
34

Big picture
Device
controllers
Light Shutter
Target 
configuration
Model 
@runtime
Running 
system
EnTiMid
Had a flu last week
" stayed in bed
" a nurse every day
Derivation 
AOM
Design-time 
Validation
Runtime 
Validation
34

Big picture
Device
controllers
Light Shutter
Target 
configuration
Model 
@runtime
Running 
system
EnTiMid
Had a flu last week
" stayed in bed
" a nurse every day
Derivation 
AOM
Design-time 
Validation
Runtime 
Validation
Script 
Generator
34

Big picture
Device
controllers
Light Shutter
Target 
configuration
Model 
@runtime
Running 
system
EnTiMid
Had a flu last week
" stayed in bed
" a nurse every day
Now in a better shape
Derivation 
AOM
Design-time 
Validation
Runtime 
Validation
Script 
Generator
34

Technical Approach
• Separating business and adaptation concerns
• AOM to analyse and reconfigure crosscutting
features dynamically
• MDE to raise the level of abstraction
• models at runtime,
• model composition
• automatic reconfiguration
35

The running system
Generating reconfiguration scripts
36

Architecture Metamodel
- component, port, binding, etc 
- invariants
Reflection model
(source)
Conforms to
The running system
Strong synchronization 
introspection + listeners
36

- invariants
Reflection model
(source)
Conforms to
The running system
Reasoning
Context info.
Context
model
Design-
models
36

- invariants
Reflection model
(source)
Woven model
(target)
Conforms to
The running system
Reasoning
Context info.
Context
model
Design-
models
36

- invariants
Reflection model
(source)
Woven model
(target)
Conforms to
The running system
Validation
Reasoning
Context info.
Context
model
Design-
models
36

- invariants
Reflection model
(source)
Woven model
(target)
Conforms to
Analyzer The running system
adapts
Delayed synchronization
Validation
Reasoning
Context info.
Context
model
Design-
models
36

Aspect Weaving and Validation
• N aspects " 2N possible programs
! Each aspect can be woven or not
! However, there are some constraint
• Design-time validation
! As much as possible, but not always possible due to combinatorial explosion
! Evolution of requirements, once the system is deployed prevent 100%
beforehand validation
• Complemented with runtime validation
! Invariant checking, simulation, etc
! Performed on the model, not on the running system
! Possibly performed outside of the running system
37

Wrap-up
• (Aspect-Oriented) Modeling from Design to
Runtime
38

Handling Variability in DAS
• (D)SPL approach to tame
!The combinatorial explosion of configurations
!The quadratic explosion of transitions
• AOM to automatically build configuration
!Runtime validation before adapting the running system
!Simple roll-back
• MDE to automate reconfiguration
!Generation of safe reconfiguration scripts
39

Models@runtime
• Aspect as variability units raised at the model level
! No explicit representation of ALL possible configurations
! Configurations obtained by weaving most adapted aspects on demand
at runtime
• MDE for automation of model composition
! Model Based Validation, Generation of reconfiguration scripts
• Applications
! DiVA: Airport Crisis Management, CRM
! Home Automation for Dependent Persons
• Spin-off from INRIA/U. Rennes to leverage this technology…
Brice Morin, Olivier Barais, Jean-Marc Jézéquel, Franck Fleurey, Arnor Solberg, "Models@ Run.time to Support
Dynamic Adaptation", IEEE Computer, vol. 42, no. 10, pp. 44-51, Oct. 2009, doi:10.1109/MC.2009.327
Brice Morin, Olivier Barais, Grégory Nain, and Jean-Marc Jézéquel, "Taming Dynamically Adaptive Systems
with Models and Aspects", 31st International Conference on Software Engineering (ICSE'09), May 2009.
40

Conclusion
• Hyper-Agility
!Agile (Software Development) + (Agile Software) Development
• Agile Software
!Technological support for large-scale agile development
• AOMDE to tame software agility
41

Scientific objectives of Triskell:
Combine formal methods & established practice
• Contracts and Aspects: from
Requirements to Design to Runtime
– Requirements by Contract, Analysis and
Design by Contract (inc. QoS)
– Aspect-Oriented Requirements & Design
– Integration of IoT &IoS
• Model-Based Testing
– requirement based testing,
requirement validation
– design based testing, design
validation
42

validation
Feed-back loop
42

validation
• Executable MetaModeling
– tools for building tools for building software
• Eg an aspect weaver for weaving aspect at runtime to handle safe
dynamic adaption of complex system
– Thanks to Kermeta this is not just meta-bla-bla
• It works for real! Have a look at http://www.kermeta.org/
Feed-back loop
42

validation
• Executable MetaModeling
– tools for building tools for building software
• Eg an aspect weaver for weaving aspect at runtime to handle safe
dynamic adaption of complex system
– Thanks to Kermeta this is not just meta-bla-bla
• It works for real! Have a look at http://www.kermeta.org/
Feed-back loop
Team Members (1st Sept., 2010): 8 Faculty or INRIA members, 1 INRIA delegation,
2 Post-Doc, 15 PhD students, and 4 Temporary Engineers
Scientific Leader: Jean-Marc Jézéquel (Prof., Univ. Rennes 1)
42

MERCI !
43

Hyper-Agility: A Model-Driven Software Agility from Design-Time to Run-Time

More Related Content

Viewers also liked (14)

Similar to Hyper-Agility: A Model-Driven Software Agility from Design-Time to Run-Time (20)

More from Benoit Combemale (20)

Recently uploaded (20)

Hyper-Agility: A Model-Driven Software Agility from Design-Time to Run-Time