A commutative model composition operator to support software adaptation
1. A Commutative Model Composition
Operator to Support Software Adaptation
Sébastien Mosser, Mireille Blay-Fornarino & Laurence Duchien
(1) SINTEF IKT, NSS Dept, MOD group, Oslo, Norway
(2) I3S (UMR CNRS UNS 7071), Univ. of Nice Sophia Antipolis, France
(3) Inria Lille-Nord Europe, LIFL (UMR CNRS USTL 8022), Univ. of Lille1, France
8th European Conference on Modelling Foundations and Applications
Copenhagen, Denmark - 05.07.2012
11. Context:
Need for commutativity
Software Adaptation 5
12. Big Picture: Adaptation Loop
«monitors» Adaptation
Engine
F1
System F2
Composition
F1 F2 F3 F4 Engine F3
Context F4
6
13. Big Picture: Adaptation Loop
«monitors» Adaptation
Engine
{F1,F2,F3} «triggers» F1
System F2
Composition
F1 F2 F3 F4 Engine F3
Context’ «yields» F4
System
F1 F2 F3 F4
6
14. Big Picture: Adaptation Loop
«monitors» Adaptation
Engine
F1
System Composition F2
F1 F2 F3 F4 Engine F3
Context’ F4
6
15. Big Picture: Adaptation Loop
«monitors» Adaptation
Engine
F1
System Composition F2
F1 F2 F3 F4 Engine F3
Context’’ F4
6
16. Toy Example
• A simple model «m»
m
• Two classes, «C1» & «C2»
C1 C2
• No inheritance (top-level)
• Two «adaptations»
• «S»: adds a super-class
Observable
• «A»: adds an aggregation
Persistence
• Works on «top-level» classes
7
17. Functional Representation of Adaptation
adaptations mS [Batory04]
as functions,
SC
S: m ↦ mS
producing
models
C1 C2
models are S(m)
constants
mA
m
C1 C2
C1 C2
A(m)
AC
A: m ↦ mA a1 a2 8
18. Problem: {A,S} selected simultaneously
mAS
mS
SC
SC
C1 C2
C1 C2
AC
a3
m S(m) A(S(m))
C1 C2
mSA
mA
SC
C1 C2
C1 C2
AC
a1 a2 AC
a1
A(m)
a2
S(A(m)) 9
19. The problem is not «interactions» or «ordering»
mSA mAS
SC SC
C1 C2 C1 C2
AC AC
a1 a2 a3
A(S(m)) S(A(m))
10
20. The problem is not «interactions» or «ordering»
mSA mAS m'
SC SC SC
C1 C2 C1 C2 C1 C2
AC AC AC
a1 a2 a3 a1 a2
A(S(m)) S(A(m)) (A||S)(m)
e.g., critical pair analysis
We need a «commutative composition operator»
10
21. Objectives
• Reusability
• Allow quantifiers (e.g., ∀)
• Retro-compatibility
• Must support «sequence»
• Determinism
• Ordering «when required»
• Inconsistency Detection
• Detect problems on the fly
11
22. (c) lokaltog
Action Set Representation Operators as set composition
12
23. From Action Sequences ...
«Every model can be expressed as a sequence of
elementary construction operation» [Blanc et al, ICSE’08]
m = [ add(C1, Class),
m add(C2, Class) ]
C1 C2
m’ = [ add(C2, Class),
add(C1, Class) ]
m’ ≠ m ! 13
24. ... to Action Sets
Added relations Deleted relations
m = (An, Ar, Dn, Dr) m
C1 C2
Added nodes Deleted nodes
m = ( { add(C1, Class), add(C2, Class)}, ∅, ∅, ∅)
m ∪ m’= (An∪A’n, Ar∪A’r, Dn∪D’n, Dr∪D’r) 14
25. Relation with Adaptation Functions
mS
m SC
C1 C2
C1 C2
mS = S(m) = m ∪ s(m)
= ( {add(C1, Class), add(C2, Class)}, ∅, ∅, ∅)
∪( {add(SC, Class)},
{add(C1,SC,In...), add(C2,SC, In...)}, ∅, ∅) 15
28. Inconsistency detected => Ordering needed!
Added relations Deleted relations
m = (An, Ar, Dn, Dr)
Added nodes Deleted nodes
• A model «m» is detected as inconsistent if (among others):
• a relation added in Ar is defined between elements deleted in Dn
• a node deleted in Dn is still involved in relations added in Ar
• It identifies situations where the parallel composition is not suitable (ordered).
18
29. The Car Crash Crisis
Implementation & Validation
Management System 19
30. Implementation: A Composition DSL
composition ordered(m) {
a(model: m) => (output: m_a);
s(model: m_a) => (output: m_sa); S(A(m))
} => (m_sa);
composition parallel(m) {
s(model: m) => (output: m_p);
a(model: m) => (output: m_p); (A||S)(m)
} => (m_p);
• Language compiler implemented with ANTLR
• Adaptation functions as Prolog (SWI) predicate (quantifiers, unification)
• Run-time link with Java/EMF through the SWI-PL framework
http://code.google.com/p/gcoke/ 20
31. The Car Crash Crisis Management System
• Common case study to compare Aspect-oriented Modelling approaches
• TAOSD special issue + ECMFA’11 paper (9 approaches described)
• Domain: Modelling of a Crisis Management System
• 8 main success scenario (e.g., «capture witness report»)
• 27 business extensions (e.g., «interrupted call», «fake information»)
• 3 non-functional requirements (i.e., «security», «persistence», «statistics»)
• Huge artefacts (hundreds of elements, thousands of relations)
21
32. Implementing the CCCMS [TAOSD’10]
• Facts:
• 29 features to be composed to produce the system
• 146 composition directives, (up to 5 features on shared points)
• Feedback: 120 possibilities
• 73% of the composition were not ordered (i.e., obtained through ||)
• The remaining 27% were ordered «by requirements»
• Some were identified by the inconsistency detection mechanisms!
22
34. Summary
Quantifiers can be used
Reusability ✔
«independently»
Supports both sequential &
Retro-compatibility ✔
parallel compositions
Ordering only if needed,
Determinism ✔
Commutativity elsewhere
Inconsistency Identify adaptation
✔
detection inconsistencies
24
35. Perspectives
• Short term: strengthen validation!
• Run-time adaptation still at the PoC level, application to the REMICS UC
• Long-term: enlarge application domains
• Cloud-Computing: models@run.time & adaptation
• EU funded projects (Call 8): MODAClouds, PaaSage, Broker@Cloud
• Internet of Things: on-the-fly re-configuration
• Internal project (MODERATES)
25
36. Thanks for your attention!
A Commutative Model Composition
Operator to Support Software Adaptation
Sébastien Mosser, Mireille Blay-Fornarino & Laurence Duchien
graphics by C.Line & sxc.hu