MODELS for ADAPTABILITY Paola Inverardi Software Engineering and - - PowerPoint PPT Presentation

models for adaptability
SMART_READER_LITE
LIVE PREVIEW

MODELS for ADAPTABILITY Paola Inverardi Software Engineering and - - PowerPoint PPT Presentation

MODELS for ADAPTABILITY Paola Inverardi Software Engineering and Architecture Group Dipartimento di Informatica Universit degli Studi dell'Aquila I-67100 L'Aquila, Italy What are Models? An idealized view of the system suitable for


slide-1
SLIDE 1

Software Engineering and Architecture Group Dipartimento di Informatica Università degli Studi dell'Aquila I-67100 L'Aquila, Italy

MODELS for ADAPTABILITY

Paola Inverardi

slide-2
SLIDE 2

SEAMS 2006

2

SEA Group

What are Models?

»

An idealized view of the system suitable for reasoning, developing, validating a real system

»

Better if formal, e.g. rigorous, mathematical-logical flavour, etc.

slide-3
SLIDE 3

SEAMS 2006

3

SEA Group

WHAT is ADAPTABILITY?

»

The ability to change a system according to context variations, e.g. driven by QoS requirements

slide-4
SLIDE 4

SEAMS 2006

4

SEA Group

ADAPTABILITY II

»

But …Still remaining the same

»

Adaptability makes sense only if it preserves something …the Invariant

slide-5
SLIDE 5

SEAMS 2006

5

SEA Group

A more serious example

»

What is the invariant here? The surface surface

slide-6
SLIDE 6

SEAMS 2006

6

SEA Group

Even better/worse

»

Invariant ??? The 3D function function

slide-7
SLIDE 7

SEAMS 2006

7

SEA Group

A more familiar example … (Tivoli-Inverardi)

Component 1 Component 3 Component 2 Connector Free Architecture Connector Based Architecture Component 1 Component 3 Component 2

Connector local views of each component deadlock-freeness

Component 1 Deadlock-free Connector Based Architecture Component 3 Component 2

Deadlock-free Connector Behavioral property

Component 1 Failures-free Connector Based Architecture Component 3 Component 2

Failure-free Connector

Connector code (assembly code)

Structure changes – equivalent behavior

slide-8
SLIDE 8

SEAMS 2006

8

SEA Group

What are the models and fomalisms

»

An architectural model i.e. constraints on the way components can interact

»

Behavioural model for components -- LTS

»

Behavioral equivalence on LTS

»

Temporal logic – Buchi Automata

»

Model Checking

slide-9
SLIDE 9

SEAMS 2006

9

SEA Group

Running software application Monitor its performance Reconfigure it dynamically Decide its next running configuration a framework We want to … We reach our aims by means

  • f …
  • Ex. 2 - PERFORMANCE : system reconfiguration

Caporuscio-Di Marco-Inverardi

Non

slide-10
SLIDE 10

SEAMS 2006

10

SEA Group

PERFORMANCE : system reconfiguration

The LIRA framework

(Castaldi-Carzaniga-Inverardi-Wolf)

slide-11
SLIDE 11

SEAMS 2006

11

SEA Group

Which models?

»

System dynamic model (LTS etc)

»

Queueing Network models (+-extended) derived from the dynamic models

»

Models analysis

»

Performance indices evaluation

slide-12
SLIDE 12

SEAMS 2006

12

SEA Group

First conclusion – 1 --

»

Models for adaptability must be able to express the invariant essence of the system not the variable one …

»

Easier for structure :

  • topological constraints (Jeff&Jeff)
  • Graph grammars (Le Metayer, etc.)
  • Category Theory (Fiadeiro-Maibaum etc.)

What about behavior?

slide-13
SLIDE 13

SEAMS 2006

13

SEA Group

Invariant -- continue

Behavioral/Semantics invariance Difficult in general: non-computable restrictions Examples:

  • Type systems (can be also structure … ArchJava)
  • Behavioral equivalence checks (Allen&Garlan , process

algebras) better preorders

  • Models checking and evaluation
  • Constraints programming
  • Code/component certification – Proof Carrying Code
slide-14
SLIDE 14

SEAMS 2006

14

SEA Group

An orthogonal issue: Static VS Dynamic

»

Is adaptability static or dynamic? The system adapts at run time how and when the adaptation is computed does not change the problem it is just a matter

  • f cost. Cost of the adaptation that maintains the

invariant. At the end it is just a pointer in the control link stack … The real issue is what is the invariant and how do we maintain it?

  • Ex. Functional Languages and Higher order functions

(a’ la ML) (ponlimorphic types, type inference)

slide-15
SLIDE 15

SEAMS 2006

15

SEA Group

Following the 3D function example

Build the n-dimension space fix in the context the variable points that matter Design the overall system with all its possible fluctations. extract/ elicit the function, i.e. the non variable non variable essence of the system Example: If we consider a service and a QoS space that can dynamically vary then the function is the “optimal “ correlation among the points in the space to achieve the “best” overall QoS

slide-16
SLIDE 16

SEAMS 2006

16

SEA Group

An initial attempt to rephrase all this

»

S = software system

»

SS = Static description of S { the code, the structure of the code,

the language it has been written, the developing artifact, the language in which it is described and all the models that can from these information be deduced (control flow graphs, slicing models, etc.)}

»

D = {behavior of S} dynamic description of S

»

C = {description of the running context} c ∈ C (might not be under the system control, otherwise just an input)

»

<i> = input (known variability points)

» »

R R suitable equivalence relation on D. R R ⊆ DxD

slide-17
SLIDE 17

SEAMS 2006

17

SEA Group

Formalization 2 --- Re-configuration

Re-Configuration Let Γ be the set of configurations γ = <SS, c, <i>>

  • Def. Let →reconf ⊆ Γ x Γ such that γ →reconf γ’ iff SSγ ≠ SS’ γ’

re-configuration requires a change in the structure of S, formalizes the context and monitors the execution environment.

slide-18
SLIDE 18

SEAMS 2006

18

SEA Group

Formalization 2 --- Adaptability

Adaptation S can be adapted to S’ wrt an equivalence R R if <SS, c, <i>> →reconf<SS’, c, <i>> (SS ≠ SS’) and D R R D’. R R can assess functional or non functional properties More appropriately R R should be a congruence relation that preserves contexts of use of the system thus modeling the user’s observable view In other words we require that adaptation implies a change in the static structure of the system. (e.g. we do not consider weak adaptation as adaptation)

slide-19
SLIDE 19

SEAMS 2006

19

SEA Group

Conclusions

Many dimensions to consider

Behavior Structure/constraints Cost/Validation

slide-20
SLIDE 20

SEAMS 2006

20

SEA Group

My opinion: Focus on Invariants

»

Structure Software architectural models/Styles, patterns, etc.

»

Behavior Abstract behavior, Types/signatures, Behavioral equivalences

»

Cost/Validation Interplay between static and dynamic analysis, clients and servers, compiled and interpreted

slide-21
SLIDE 21

SEAMS 2006

21

SEA Group

Do not stop looking for models … may be that …

Under the formal suite also models … …. have an heart …

slide-22
SLIDE 22

SEAMS 2006

22

SEA Group

References

»

Woss proceedings