This presentation explains a paper discussion the relation of software product lines and dynamic software adaptation.

1. Dynamic Software Adaptation for
Service-Oriented Product Lines
Maarten Christiaen
Niels Claeys
Gomaa H.
Hashimoto K.

2. 2
Outline
1. Motivation
2. SASSY framework
3. Dynamic Software Adaptation for SPL
4. Case study
5. Conclusion
6. Reflection

3. Motivation
SOA: increasingly popular
→ adapt environment + operational requirement

State of practice:

Build at design time

Based feature model

New:

Regenerate based on
QOS

Architecture and
adaptation patterns for
SOA

Change: behavior,
services, architecture

4. Three-layer Architecture: SASSY

Self Architecting
Software SYstem

Monitoring: trigger
adaption

Goal: transition
between architectures
based on trigger

Adaptation: execute
the plan of goal
management

5. 5
Dynamic Software Adaptation for SPL

Feature modeling in DSPL

SOA architecture

Adaptation pattern

Changes to SASSY

6. DSPL: Feature modeling

Target system reconfiguration: defining
run-time configurations

Reconfigurable components: feature-
component mapping

7. SOA: Architecture pattern

SOA: loose coupling + self contained

Coordinator: interconnection of service
→ contain adaptation state

Service: stateless

8. Reconfigure architecture

Executed by Change management:
based on new structure

Identify components affected

Transition components to quiescent state
→ adaptation pattern

Replace components

9. SASSY: adaptation

Goal: selects new
features

Adaptation patterns in
component control

CM: issue changes

Monitor: initiate
change

10. Case study (1)
Feature-component
mapping
Feature model

11. Case study (2)

12. Conclusions

Combined approach of:

SPL

SOA

dynamic software adaptation

Adapt dynamically different member of SPL

Towards adapting whole system
→ assume system can be divided in
independent architectural patterns

Self architecting = switching between
architectures created during SPL design

13. 13
Relation to Capita selecta

Inspired by SPL
→ Extended for dynamic configuration

Smallest building block = service

Not sufficient for SaaS

No support for multi-tenancy

Customizability for tenants not supported

14. Reflection
+ Dynamic adaptation
based on QoS
+ Hierarchical
replacement
+ Reuse: SOA
architecture patterns
- Multi-tenancy
- No co-existing
configurations
- Smallest block service
- Only use features
existing at design time
→ no self architecting
- No quantifiable results

15. Questions?