Aspect-oriented and Component Adaptation for Software Product Lines
Dynamic software adaptation for service oriented product lines
-
Upload
niels-claeys -
Category
Technology
-
view
62 -
download
0
description
Transcript of Dynamic software adaptation for service oriented product lines
Dynamic Software Adaptation for Service-Oriented Product Lines
Maarten ChristiaenNiels Claeys
Gomaa H.Hashimoto K.
2
Outline
1. Motivation2. SASSY framework3. Dynamic Software Adaptation for SPL4. Case study5. Conclusion6. Reflection
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
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
Dynamic Software Adaptation for SPL
Feature modeling in DSPL SOA architecture Adaptation pattern Changes to SASSY
DSPL: Feature modeling
Target system reconfiguration: defining run-time configurations Reconfigurable components: feature-component mapping
SOA: Architecture pattern SOA: loose coupling + self contained Coordinator: interconnection of service→ contain adaptation state Service: stateless
Reconfigure architecture
Executed by Change management: based on new structure Identify components affected Transition components to quiescent state→ adaptation pattern Replace components
SASSY: adaptation
Goal: selects new features
Adaptation patterns in component control
CM: issue changesMonitor: initiate change
Case study (1)
Feature-component mapping
Feature model
Case study (2)
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 patternsSelf architecting = switching between architectures created during SPL design
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
Reflection
+ Dynamic adaptation based on QoS+ Hierarchical replacement+ Reuse: SOA architecture patterns
- Multi-tenancy- No co-existing configurations- Smallest block service- Only use featuresexisting at design time→ no self architecting- No quantifiable results
Questions?