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 [email protected]

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

http://www.irisa.fr/prive/jezequel

Hyper-Agility:


1





Hyper-Agility:


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



6



6

- Reutilisability - Durability



6


- Platform



6


- Platform

Time To Market!=> Large Scale Agile Development


(A) Manifesto for Agile Software @ Design Time

• 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 Agile Software @ Design Time

• 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

➡ Technological Support for Agile Development!


Software Product Lines (SPL)

8


Software Product Lines (SPL)• Families of related software products

8


Software Product Lines (SPL)• Families of related software products• 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

• Families of related software products• The products have a common part and a variable part

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


...


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

http://www.irisa.fr/videos/fete-sciences-2009/


Entimid

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

12

http://www.irisa.fr/videos/fete-sciences-2009/


Many Different Needs 1/2Pi

ctur

e fro

m h

ttp://

ww

w.ap

t.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)

Pict

ure

from

http

://di

tww

w.ep

fl.ch

Mr. John Doe

14


# Software Product Lines (SPL)

Their needs

Medical/technical staff should be able to

•Check their health state

•Check home configuration (shutters, lights, heaters…)

Both

Mrs. Dupont Mr. DoeSome daily tasks should be automated (motion troubles) or reminded (memory loss).

Would like to control everything remotely, with a unified 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

• Individuals and interactions (over processes and tools) ➡ multiple variability dimensions • Working software (over comprehensive documentation) ➡ dynamic adaptation • Customer collaboration (over contract negotiation) ➡ user-driven dynamic adaptation • Responding to change (over following a plan) ➡ 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


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.

[email protected]’08

Hallsteinsen et al.

Computer’08

OSGi, Fractal,OpenCOM, etc

Garlan et al.Computer’04

UOreizy 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


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

Bookstate : StringUser

borrow

return

deliver

setDamaged

reserve

Use case model

Platform Model



Distribution

Fault tolerance

Security

Functional behavior


borrow

return

deliver

setDamaged

reserve

Use case model

Platform Model



AOMDE = Pleonasm because

a Model is an Abstraction of an Aspect of Reality for a given Purpose

Distribution

Fault tolerance

Security

Functional behavior


borrow

return

deliver

setDamaged

reserve

Use case model

Platform Model



Design Model



Distribution

Fault tolerance

Security

Functional behavior


borrow

return

deliver

setDamaged

reserve

Use case model

Platform Model



Design Model

Code Model



Distribution

Fault tolerance

Security

Functional behavior


borrow

return

deliver

setDamaged

reserve

Use case model

Platform Model



Design Model

Code Model



Distribution

Fault tolerance

Security

Functional behavior


borrow

return

deliver

setDamaged

reserve

Use case model

Platform Model



Design Model

Code Model



Change one Aspect and Automatically Re-Weave: From AORE, SPL to DAS

Distribution

Fault tolerance

Security

Functional behavior


borrow

return

deliver

setDamaged

reserve

Use case model

Platform Model



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 Benefits and Challenges", In 3rd Workshop on Model-Driven Tool & Process Integration, in conjunction with ECMFA'10, 2010.

http://www.irisa.fr/triskell/perso_pro/combemale/teaching/mde/


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



MOF(M3 Level)

Metamodel(M2 Level)

require require


produces produces


(meta-) metamodels

input(meta-)models

Written in Kermeta/KET


30


Meta-code generator

code generator



MOF(M3 Level)

Metamodel(M2 Level)

require require


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

Runningsystem

34


Big picture

Model@runtime

Runningsystem

34


Big picture

Model@runtime

Runningsystem

Metamodel

34


Big picture

Device controllers

Light Shutter

Model@runtime

Runningsystem

Metamodel

EnTiMid

34


Big picture

Device controllers

Light Shutter

Model@runtime

Runningsystem

Metamodel

EnTiMid Design-timeValidation

34


Big picture

Device controllers

Light Shutter

Model@runtime

Runningsystem

EnTiMid Design-timeValidation

34


Big picture

Device controllers

Light Shutter

Model@runtime

Runningsystem

EnTiMid

Pict

ure

from

http

://w

ww.

apt.g

c.ca

Had a flu last week

" stayed in bed

" a nurse every day

Design-timeValidation

34


Big picture

Device controllers

Light Shutter

Targetconfiguration

Model@runtime

Runningsystem

EnTiMid

Pict

ure

from

http

://w

ww.

apt.g

c.ca

Had a flu last week

" stayed in bed

" a nurse every day

DerivationAOM


34


Big picture

Device controllers

Light Shutter

Targetconfiguration

Model@runtime

Runningsystem

EnTiMid

Pict

ure

from

http

://w

ww.

apt.g

c.ca

Had a flu last week

" stayed in bed

" a nurse every day

DerivationAOM


Runtime Validation

34


Big picture

Device controllers

Light Shutter

Targetconfiguration

Model@runtime

Runningsystem

EnTiMid

Pict

ure

from

http

://w

ww.

apt.g

c.ca

Had a flu last week

" stayed in bed

" a nurse every day

DerivationAOM


Runtime Validation

ScriptGenerator

34


Big picture

Device controllers

Light Shutter

Targetconfiguration

Model@runtime

Runningsystem

EnTiMid

Pict

ure

from

http

://w

ww.

apt.g

c.ca

Had a flu last week

" stayed in bed

" a nurse every day

Now in a better shape

DerivationAOM


Runtime Validation

ScriptGenerator

34


Big picture

Device controllers

Light Shutter

Targetconfiguration

Model@runtime

Runningsystem

EnTiMid

Pict

ure

from

http

://w

ww.

apt.g

c.ca

Had a flu last week

" stayed in bed

" a nurse every day

Now in a better shape

DerivationAOM


Runtime Validation

ScriptGenerator

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 synchronizationintrospection + listeners


36





Conforms to

The running system


Reasoning

Context info.

Context model

Design- models


36





Woven model (target)

Conforms to

The running system


Reasoning

Context info.

Context model

Design- models


36






Conforms to

The running system


Validation

Reasoning

Context info.

Context model

Design- models


36






Conforms to

Analyzer The running systemadapts


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





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

http://www.kermeta.org







validation





Feed-back loop

42








validation





Feed-back loop

42








validation





Feed-back loop

42








validation





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



