Tutorial at SPLC 2013 August 27 th 2013 Motivation ivation - - PowerPoint PPT Presentation

 

Mahdi Bashari

University of New Brunswick

Ebrahim Bagheri

Ryerson University

Tutorial at SPLC 2013 August 27th 2013

 Motivation

ivation

 Introduction  Adaptation aspects  Overview of three DSPL approaches  Engineering of adaptive systems & DSPL  Research Challenges  Summary

2

 Motivation

ivation

• Softw

tware are Product duct Line ne

• Self-adaptive Systems
• Synergy

 Introduction  Adaptation aspects  Overview of three DSPL approaches  Engineering of adaptive systems & DSPL  Research Challenges  Summary

3

 Goal:

• Mass production and mass customization at the same

time

 How:

• Two phases to promote reuse:
• Doma

main in enginee gineering ring

• Ap

Application ation enginee gineering ing

 Benefits:

• Effort, quality, time to Market

4

(Hallsteinsen et al. 2008)

5

 Domain Engineering

• SPL infrastructure developed for the specific product

family

• Variability model
• Reference architecture
• Other PL assets

 Application Engineering

• Specific product built using a variability model per

customers’ needs

• Final product

6

 Domain engineering:

• Possible variation of products is captured in products

family.

• Variation of product is represented by variation points.
• Variation model is specified for selecting variants of

variation points.

 Application engineering :

• Customer requirements are elicited.
• Variant decision about each variation point is made.
• Variants are bound to the final product.

7

SPL Goal of variability Satisfy individual customer needs Binding time of variability Pre re- runtime me/Runtime Decision maker of the variant Application Engineer Method for selecting the variant reuse of shared assets conforming a variability model Model of variability Variability Model, Architecture model Lifetime of the variability model Pre-runtime

8

 Motivation

ivation

• Software Product Line
• Self-ad

adapt aptive e Syst stem ems

• Synergy

 Introduction  Adaptation aspects  Overview of three DSPL approaches  Engineering of adaptive systems & DSPL  Research Challenges  Summary

9

 Goal:

• Maintaining service in different situations

 How:

• Building application in two layers:
• Adaption

ion logic

• Ap

Application ation logic

 Benefits:

• Flexibility, reliability, efficiency

10

11

 Adaptation manager:

• Monitors the context of the system internally and

externally

• Analyzes the context for conditions where adaptation is

needed.

• Decides about the response plan following adaptation

policies.

• Carries out the decided plan by dynamic addition,

deletion, or modification of product features, or introducing changes in the architectural structure of the system.

12

13

 Enables monitoring of the system’s internal state

and provides the needed interface for adaptation manager.

 Enables runtime adaptation and provides the

needed interface for adaptation manager to perform the adaptation.

 Development of a self-adaptive system:

• Possible variation of system in runtime is captured.
• Variation of product is represented by variation points.
• Adaptation policy which defines variant selections in response

to changes in context is designed.

 Adaptation manager at runtime:

• Context of system is captured using monitoring sensors.
• Adaptation manager decides about the changes in variation

points according to context and adaptation policy.

• The variability changes is executed in managed application

14

SPL Self-ad adap apti tive Goal of variability Satisfy individual customer needs Maintaining service in situation change Binding time of variability Pre re- runtime me/Runtime Runtime Decision maker of the variant Application Engineer Application itself Method for selecting the variant reuse of shared assets conforming a variability model Following a set of adaptation policies Model of variability Variability model, Architecture model Adaptation policy, variability model, architecture model, context model Lifetime of the variability model Pre-runtime Runtime

15

(Alves et. al 2009)

 Motivation

ivation

• Software Product Line
• Self-adaptive Systems
• Synergy

ergy

 Introduction  Adaptation aspects  Overview of three DSPL approaches  Engineering of adaptive systems & DSPL  Research Challenges  Summary

16

 Managing variability self-adaptive systems is a

complex task.

 More consolidated methods systematically address

runtime variability.

 SPL & Self-adaptive systems have the similar goal

• f satisfying specific needs of various

environments and users through variability management.

17

 For their rich practices and models for managing

variability in software development process, SPL infrastructures are used at runtime to develop self- adaptive systems.

 Major uses of SPL in design of self-adaptive

system:

• Variability models
• Product derivation approaches

18

SPL Self-adapt ptiv ive DSPL Goal of variability Satisfy individual customer needs Maintaining service in situation change Maintaining service in situation change Binding time of variability Pre- runtime me/Runtime Runtime Pre- runtime/Runti time me Decision maker of the variant Application Engineer Application itself Application Engineer/User/Appl ication itself Method for selecting the variant reuse of shared assets conforming a variability model Following a set of adaptation policy Use of SPL assets at runtime Model of variability Variability Model, Architecture model Adaptation policy, variability model, architecture model, context model Adaptation policy, variability model, architecture model, context model Lifetime of the variability model Pre-runtime Runtime Pre- runtime/runtime

19

 Motivation  Int

ntroduc

• ducti

tion

• n

 Adaptation aspects  Overview of three DSPL approaches  Engineering of adaptive systems & DSPL  Research Challenges  Summary

20

 Utilizes parts of SPL infrastructure to adapt at

runtime.

 DSPL Prope

perti ties es:

• Runtime reconfiguration
• Self-management (Optional)

 DSPL Goal:

• Market forces→individual environment/context situation

(Hallsteinsen et al. 2008)

21

 Runti

time me rec econf

• nfigura

igurati tion

• n: DSPL
• allows for dynamic variability: configuration and binding

at runtime,

• changes binding several times during its lifetime,
• introduces variation points [which] change during

runtime: variation point addition (by extending one variation point),

• deals with unexpected changes (in some limited way),

and

• deals with changes by users, such as functional or

quality requirements.

(Hallsteinsen et al. 2008)

22

 Sel

elf-ma manageme gement (Optional):

• “context awareness”
• “autonomic or self-adaptive properties”
• “automatic decision making”

(Hallsteinsen et al. 2008)

23

 When users’ requir

equiremen ements ts change ge at runtim ime

An automated transportation system(Helleboogh et al. 2009)

• The user wants to be able to change the operation mode of

transportation system in special situation (e.g. when goods arrive by truck)

24

 Wh

When en en envir ironment ment change ges s at runtim ime

Distributed nodes for Flood Monitoring (Bencomo et al. 2008)

• The node software priority over performance and power

efficiency changes according to likelihood of flood

25

 Motivation  Introduction  Ada

dapt ptati tion

• n aspe

pects ts

 Overview of three DSPL approaches  Engineering of adaptive systems & DSPL  Research Challenges  Summary

26

 Adaptation is change of system properties and

behavior at runtime in response to dynamically varying user needs and resource constraints.

27

28

 Degree of adaptation  Degree of autonomy  Adaptation trigger  Architectural platform  Adaptation goal  Evolution

 Beha

Behavioral vioral adaptation adaptation. The system dynamically changes its behavior within its existing structure. There is no change to the system structure or architecture.

• Parameterization
• Inheritance
• Try…catch

 Com

Compo ponent nent ada adapt ptation

• ation. Dynamic adaptation involves

replacing one component with another that has the same interface.

 Archit

hitectur ctural l adaptatio

• aptation. The software architecture has

to be modified as a result of the dynamic adaptation.

(Gomma et al. 2011)

29

 Basic

ic

 Man

anag aged ed

 Pred

edic icti tive

 Ada

dapt ptiv ive

 Aut

utonomic

• nomic

(Huebscher et al. 2008)

30

 Change

ge in in user er requir equiremen ements ts

Requires capturing user requirement

 Change

ge in in runnin ing g context xt

Requires capturing running context

31

 Compone

mponent-base based d pl platform

• rm
• has good granularity for adaptation
• is not designed to reconfigure at runtime (this problem is

handle by architectural styles)

 Ser

ervic ice-orie

• riented

ed pl platform

• rm
• has been build with the goal of reusing existing assets

for developing new products.

• consist of service which are loosely coupled which eases

adaptation of the system.

32

 Sel

elf-con config igurat uration ion

 Sel

elf-opti

• ptimi

miza zati tion

• n

 Sel

elf-heal ealin ing

 Sel

elf-pr protecti ecting

(Kephart et al. 2003)

33

 Evolution is the degree to which unanticipated or

unforeseen changes, e.g. adding new features, can be absorbed by the system at runtime.

 Boun

unde ded d Adapt ptati ation. n.

• Adaptation policies remain same at runtime.
• Context variation is anticipated at design time and is

accommodated by DSPL models.

 Open

en Adaptatio ptation. n.

• Adaptation policies can be updated at runtime (e.g. according

to feedback).

• New variants can be introduced at runtime (when facing

unanticipated situations).

34

 Motivation  Introduction  Adaptation aspects  Over

ervie iew w of three ee DSPL app pproache ches

• MADAM
• Models@Runtime
• MoRE

 Engineering of adaptive systems & DSPL  Research Challenges  Summary

35

36

 MADAM is a framework for developing mobile and

distributed applications that adapt dynamically to changes in context (at launch time and during use).

 Applications must adapt to such changes in order to sustain

availability, usability and usefulness

Dimen ensi sion

• n

Value Degree of dynamism Component adaptation Degree of autonomy autonomous Adaptation trigger Change in running context Architecture platform Component-based Adaptation goal Self-optimizing Evolution Bounded

37

selects application variant architecture model

components nodes noise position light

user context affect

• peration

adapts monitors adaptation middleware Service technician preferred quality influence user’s needs provided quality adaptable application

network QoS shared devices battery

system context monitors describes relation describes relation

(Floch et al. 2006)

38

(Hallsteinsen et al. 2006)

39

(Floch et al. 2006)

40

(Floch et al. 2006)

41

 Configurable product bases which are extended to

be used at runtime are utilized in building the new configuration of the system after adaption.

 Motivation  Introduction  Adaptation aspects  Over

ervie iew w of three ee DSPL app pproache ches

• MADAM
• Models@R

ls@Run unti time

• MoRE

 Engineering of adaptive systems & DSPL  Research Challenges  Summary

42

43

 A framework for adaptive applications by adopting ideas

from software product line and aspect oriented design at runtime.

Dimen ensi sion

• n

Value Degree of dynamism Architecture adaptation Degree of autonomy autonomous Adaptation trigger Change in running context Architecture platform Component-based Adaptation goal Self-configuring/Self-

• ptimizing

Evolution Open

44

(Morin et al. 2009)

45

Comple plex x event nt monit itor

• ring:

ng: This component observes runtime events generated by probes integrated into the System and updates context model of system accordingly.

46

Goal-based ased reason

• nin

ing g engine ine Selects features from feature model following the reasoning model adapted to the current context.

47

Aspect ect model we weaver er receives a derived feature model from the reasoning engine. For each of the features of this model, the weaver composes a corresponding aspect to the base model to produce the targeted architecture model.

48

Conf nfigur gurat atio ion n invaria ariant nt check cker er checks if the architecture model is consistent and revokes the adaptation if it is not.

49

Conf nfigur gurati ation n manager ger receives new configuration of the system and is responsible to reconfigure the system using the services offered by the platform

50

 Feature models are used at runtime to model the

variability of the system.

 Variants of the system are selected by configuring

the feature model at runtime according to context.

 The configuration of the final product is built using

Aspect Model Weaving from SPL product derivation.

 Motivation  Introduction  Adaptation aspects  Over

ervie iew w of three ee DSPL app pproache ches

• MADAM
• Models@Runtime
• MoRE

 Engineering of adaptive systems & DSPL  Research Challenges  Summary

51

52

 A framework for developing pervasive applications (such as

smart home) that adapt dynamically to changes in available services and devices to maintain system service.

Dimen ensi sion

• n

Value Degree of dynamism Architecture adaptation Degree of autonomy autonomous Adaptation trigger Change in running context Architecture platform Service-oriented Adaptation goal Self-healing Evolution Bounded

53

54

(Cetina et al. 2009)

55

 Conditions are states of system and environment.

• 𝑂𝑓𝑥𝑊𝑝𝑚𝑣𝑛𝑓𝑢𝑠𝑗𝑑𝑇𝑓𝑜𝑡𝑝𝑠, 𝐵𝑚𝑏𝑠𝑛𝐺𝑏𝑗𝑚𝑣𝑠𝑓, 𝐹𝑛𝑞𝑢𝑧𝐼𝑝𝑛𝑓

 Resolutions are sets of feature

activations/deactivations when a condition triggers.

• 𝑆𝐹𝑛𝑞𝑢𝑧𝐼𝑝𝑛𝑓 =

{(𝑃𝑑𝑑𝑣𝑞𝑏𝑜𝑑𝑧𝑇𝑗𝑛𝑣𝑚𝑏𝑢𝑗𝑝𝑜, 𝐵𝑑𝑢𝑗𝑤𝑓), (𝐽𝑜𝐼𝑝𝑛𝑓𝐸𝑓𝑢𝑓𝑑𝑢𝑗𝑝𝑜, 𝐵𝑑𝑢𝑗𝑤𝑓), (𝑀𝑗𝑕ℎ𝑢𝑗𝑜𝑕𝐶𝑧𝑃𝑑𝑑𝑣𝑞𝑏𝑜𝑑𝑧, 𝐽𝑜𝑏𝑑𝑢𝑗𝑤𝑓)}

56

57

 Feature models are used at runtime to model the

variability of the system.

 Variants of the system are selected by configuring

the feature model at runtime according to context.

 Motivation  Introduction  Adaptation aspects  Overview of three DSPL approaches  Engi

gine neeri ring ng of adap aptiv tive e systems ms & DS DSPL

• Conceptual

ptual Model

• Architecture
• MAPE-K Loop
• Process
• Research Highlights

 Research Challenges  Summary

58

 Self-adaptive systems are designed in two layers

• Application logic: focuses on application functionality
• Adaptation logic: focuses on application adaptability

 The two-layer design promotes separation of

concerns and results in a system

• which is less complex and easier to extend
• whose components are reusable

59

60

(Kephart et al. 2003)

61

 The MAPE-K loop corresponds to product derivation in SPL  SPL models can be used as knowledge (e.g. variable model,

decision making,…)

 SPL inspires approaches which can be used in planning and

executing in the MAPE-K loop (e.g. configurable product family)

 SPL has different motives for creating new variants of

software; therefore, the SPL infrastructure is not used in monitoring and analyzing

 The output of product derivation in SPL is a new product,

while that of the MAPE-K loop is a set of changes in the current product.

63

 Motivation  Introduction  Adaptation aspects  Overview of three DSPL approaches  Engi

gine neeri ring ng of adap aptiv tive e systems ms & DS DSPL

• Conceptual Model
• Archit

itect cture ure

• MAPE-K Loop
• Process
• Research Highlights

 Research Challenges  Summary

64

(Kramer et al. 2007)

65

66

(Morin et al. 2009) Goal Management Change Management Component Control

67

(Hallsteinsen et al. 2006) Goal Management Change Management Component Control

 Motivation  Introduction  Adaptation aspects  Overview of three DSPL approaches  Engi

gine neeri ring ng of adap aptiv tive e systems ms & DS DSPL

• Conceptual Model
• Architecture
• MAPE-K

K Loop

• Process
• Research Highlights

 Research Challenges  Summary

68

 involves capturing properties of the environment

that are of significance to the adaptive properties

• f the system.

 could be: Physical (e.g. temperature) or Virtual (e.g.

CPU utilization, response time).

 is done using sensors  have been widely used in networks and distributed

systems.

69

 Context models represent formally the parts of the

context which are important for making decisions about the configuration of the software application.

 OWL (Web Ontology Language)

• Is a Markup language
• Enables context sharing & context reasoning

.

70

71

(Wang et al 2004)

 Motivation  Introduction  Adaptation aspects  Overview of three DSPL approaches  Engi

gine neeri ring ng of adap aptiv tive e systems ms & DS DSPL

• Conceptual Model
• Architecture
• MAPE-K

K Loop

• Process
• Research Highlights

 Research Challenges  Summary

72

 Rule

le-ba base sed.

• d. Decision making is performed by following

a set of rules which determine what particular action should be performed in each context.

• Event-condition-action (ECA) policies

 Go

Goal-based

• based. These approaches specify criteria that

characterise the desirable configuration of the system but leave to the system the task of finding out how to achieve the configuration having those characteristics.

• AI Planning

 Ut

Utility lity-based based. . This set of approaches define a quantitative level of desirability for each state.

• Optimization

73

 Analysis determines when a change is required by

analyzing the symptoms provided through monitoring and the history of the system.

 Analysis implicates the following:

• Event and conditions, in rule-based approaches.
• The current state of the system while achieving goals, in

goal-based approaches.

• The current utility and state of the system, in utility-

based approaches.

74

 Motivation  Introduction  Adaptation aspects  Overview of three DSPL approaches  Engi

gine neeri ring ng of adap aptiv tive e systems ms & DS DSPL

• Conceptual Model
• Architecture
• MAPE-K

K Loop

• Process
• Research Highlights

 Research Challenges  Summary

75

 Planning involves taking into account the state of the

system in order to select a new variant of the managed element.

 Planning can be done in two levels in DSPL:

• Feature level
• Architectural level

 In DSPL, planning in feature level is similar to product

configuration in SPLE.

 Feature level planning improves separation of concern.  If feature level is used, feature configuration should be

mapped to the architectural level configuration.

76

77

 Variability Model  Adaptation Policy  Architecture Model

78

 Enumer

erati tion

• n of the

e system em varia iants

• Explicitly lists variants of the system and their

corresponding configurations are listed.

 Pros.

• Simple
• Easier to validate

 Cons.

• has limitations for large systems

79

 Type

pes

• The variation of the system is defined by a set of

variation points. Variation points allow variants of same type to be replaced for each other.

 Pros.

• Simple
• Manageable

 Cons.

• Cross-cutting variations constraint

80

(Hallsteinsen et al. 2006)

81

 Fea

eature e Mode del

• A feature model provides a tree-like structure that shows

the organization of features. In a feature model, features are hierarchically organized by structural constraints.

• A feature model supports cross-cutting variations using

integrity constraints.

 Pros.

• Formal representation
• Tool support

82

(Parra et al. 2009)

 Used to define architectural model of the system (e.g.

UML component model)

• Architecture Definition Language (ADL)
• Domain Specific Modeling Language (DSML)

 Used for:

• Current architecture of the system
• Target architecture of the system

 Usually represented by a graph-like structure where

nodes are components and arcs represent binding.

 Is available at runtime and should be memory efficient

83

 Stat

ate e Trans ansition ition Di Diag agram ram

• States represent variants of a system in adaptation
• Transitions represent the possible transitions between

variants

• Guard of transitions determine when a transition can happen

 Planning at design time  Pros

• Simple
• Easy validation

 Cons

• State explosion
• Hard to modify after design (mostly for evolution at runtime)

84

85

 Event-Conditio

• ndition-Act

ctio ion n rules

• Events are changes in environment (e.g. network traffic) or system state

(e.g. processor usage) or a combination of these.

• Condition represent the current conjuration of the system and its

context.

• Actions are changes over features or components.

 Planning at design time  Pros.

• Readability and elegance of each individual rules
• Efficient process
• Easy to Modify (by adding removing new rules)

 Cons.

• Scalability (Possibility of conflicting rules)
• Application of stateless manner is limited
• Validation

86

87

(Parra et al. 2009)

 A goal-based model defines

• How changes(e.g. inclusion/exclusion of features) impact the

goal of the system in a specific context.

• When the system should change.

 Planning at runtime  Reducing to satisfiability problem (SAT), constraint

satisfaction problem (CSP).

 Pros.

• More likely to find the best adaptation

 Cons.

• Hard to design
• More resource usage

88

 Utility-based model defines

• A utility function representing desirability of a configuration
• How changes(e.g. inclusion/exclusion of features) impact the

goal of the system

• When the system should change according to utility

 Planning at runtime  Pros.

• More likely to find the best adaptation

 Cons.

• Hard to design
• More resource usage

89

90

(Floch et al. 2006)

 These approaches fill the gap between features and

architecture.

 No situation specific development is possible unlike

SPL (extensive reuse)

• Configurable Product Family

 A change in the features of the system is mapped to

changes in architecture.

• Direct link
• Transformation rule
• Aspect Model Weaving
• Common Variability Language(CVL)

91

 Direct mapping between features in feature model to

architectural fragments in system implementation.

 By selecting/deselecting features mapped fragments

activated/deactivated

 Pros.

• Simplicity
• Realization

 Cons.

• Separation of concern
• Not applicable in many cases

92

93

 The relation between feature model and architecture is

represented by using a set of rules (e.g. prepositional logic rules).

 After selecting/deselecting features, corresponding

changes should be made in architecture such that the rules hold.

 Pros

• More complex relations between features and architecture

are enabled.

 Cons.

• Hard to find rules
• Hard to derive architectures which sustain the rules

94

95

 Automates the generation of detailed architecture

from high level designs.

 In aspect model weaving:

• The application commonalities are represented in a

base model.

• Each feature of the system is mapped to a set of aspect

models which are woven into the base model to create the final model of the system.

 Examples:

• SMARTADAPTORS
• Kompose

96

97

 Motivation  Introduction  Adaptation aspects  Overview of three DSPL approaches  Engi

gine neeri ring ng of adap aptiv tive e systems ms & DS DSPL

• Conceptual Model
• Architecture
• MAPE-K

K Loop

• Process
• Research Highlights

 Research Challenges  Summary

98

 Enabling runtime reconfiguration

• Reflective Middleware
• provides a model of the system in which any change in the

system will be reflected in the model and similarly any change in the model is reflected on the system.

• Introspection:
• accesses the representation of system behaviour using this model.
• Intercession:
• reconfigures the system by modifying this model

99

100

 Component Model defines

• the semantics of components
• the syntax of components
• the composition of components

 Hierarchal component model allows

• each component to be made of smaller components.
• changes in different levels of granularity.

 OpenCOM is a language-independent, component-based

middleware which supports:

• Hierarchal structure
• Reflection using graph representation of architecture
• Adding a node to the graph results in the deployment of a new

component

• Removing an arc results in the breaking of an inter-component

binding

101

102

(Coulson et al. 2004)

103

(Coulson et al. 2004)

 Services  Reflection  Dynamic install, start, restart and uninstall of services  Bundle

• A bundle is the deliverable application
• A bundle registers zero or more services
• Searches can be used to find services registered by other

bundles

• OSGi defines a standard set of services for bundle (e.g. for

lifecycle management)

 OSGi Wire

• connection between a Producer service and a Consumer

service.

106

Hardware Bundle Bundle Bundle Operating System OSGi Java VM Bundle (Application) Driver Driver Driver

= service interface exported and imported by bundles 107

(Marples et al. 2001)

 public interface GPS {

… }

 public void foo( BundleContext context ) {

Garmin garmin = new Garmin(…); Hashtable properties = new Hashtable(); properties.put( "vendor", "garmin" ); ServiceRegistration reg = context.registerService( GPS.class.getName(), garmin, properties ); }

 public void bar( BundleContext context ) {

ServiceReference ref = context.getService( GPS.class.getName() ); GPS gps = context.getService( ref ); … }

108

 Motivation  Introduction  Adaptation aspects  Overview of three DSPL approaches  Engi

gine neeri ring ng of adap aptiv tive e systems ms & DS DSPL

• Conceptual Model
• Architecture
• MAPE-K Loop
• Process
• Research Highlights

 Research Challenges  Summary

109

 Two phases

• Domain Engineering:
• Defining Context model
• Defining binding units & binding time
• Defining feature to architecture link
• Designing runtime reconfiguration
• Application Engineering
• Analyzing binding time
• Customizing adaptation manager

110

 Motivation  Introduction  Adaptation aspects  Overview of three DSPL approaches  Engi

gine neeri ring ng of adap aptiv tive e systems ms & DS DSPL

• Conceptual Model
• Architecture
• MAPE-K Loop
• Process
• Research

ch Highl hlights ights

 Research Challenges  Summary

113

 BPEL provides a language for the formal

specification of business process behavior based exclusively on Web Services.

• Captures business logic and behavior of service

interactions

• Supports service composition at executable level

 BPEL draws upon concepts and constructs from

imperative programming languages, and extends them to those related to Web services and business processes

114

116

 Considering features as fragments of BPEL code  Dynamic Aspect Weaving allows the incorporation

• f new aspects in runtime in a program.
• A BPEL code is selected as base model
• Every model variant is expressed in terms of

substitutions that it needs to incorporate into the base model to include that variant.

117

118

 Ability to introduce the variants which were not

considered at design time and introducing them into the system at runtime.

 In order to:

• Handle unanticipated situations
• Enhance efficiency

 Two types of evolution:

• Evolution on how the system adapts
• Modifying ECA rules
• Evolution on system variants
• Discovering new web services addressing features

119

120

 Motivation  Introduction  Adaptation aspects  Overview of three DSPL approaches  Engineering of adaptive systems & DSPL  Res

esea earch ch Challen enges ges

 Summary

121

 Formalizing concepts

• Need for exact definition of concepts used in DSPL

 Process

• Requirement engineering
• Adaptation engineering

 Decentralized DSPL

• Interaction between DSPL

 Experience reports

122

123

 Run-time Verification

• Ensuring safety of adaptation

 Testing and assurance.

• Different variants of the system work correctly
• The combinations of adaptations do not make the

system inconsistent

 Evaluation and quality of adaptation

• Safety, security, and performance evaluation

 Implementation tools

• To be used in practice

 Motivation  Introduction  Adaptation aspects  Overview of three DSPL approaches  Engineering of adaptive systems & DSPL  Research Challenges  Summar

mary

124

 In this tutorial we covered:

• Motivation for DSPL
• Adaptation aspects
• Designing a Dynamic Software Product Line
• Architecture
• MAPE-K Loop
• Research Challenges

125

(Hallst steinse einsen et et al. 2008) 8) Hallsteinsen, Svein, Mike Hinchey, Sooyong Park, and Klaus Schmid. "Dynamic software product lines." Computer 41, no. 4 (2008): 93-95. (Al Alves es et et al. 2009) 9) Alves, Vander, Daniel Schneider, Martin Becker, Nelly Bencomo, and Paul Grace. "Comparitive study of variability management in software product lines and runtime adaptable systems." (2009): 9-17. (Hell llebo eboogh

• gh et

et al. 2009) 9) Helleboogh, Alexander, Danny Weyns, Klaus Schmid, Tom Holvoet, Kurt Schelfthout, and Wim Van Betsbrugge. "Adding variants on-the-fly: Modeling meta-variability in dynamic software product lines." In Proceedings of the Third International Workshop on Dynamic Software Product Lines (DSPL@ SPLC 2009), pp. 18-27. 2009. (Benc encom

• mo et

et al. 2008) 8) Bencomo, Nelly, Peter Sawyer, Gordon S. Blair, and Paul Grace. "Dynamically Adaptive Systems are Product Lines too: Using Model-Driven Techniques to Capture Dynamic Variability of Adaptive Systems." In SPLC (2), pp. 23-32. 2008.

126

(Cetina etina et a et al. 2009 2009) Cetina, Carlos, Pau Giner, Joan Fons, and Vicente Pelechano. "Autonomic computing through reuse of variability models at runtime: The case of smart homes." Computer 42, no. 10 (2009): 37-43. (Gomaa aa et a et al. 2011) 1) Gomaa, Hassan, and Koji Hashimoto. "Dynamic software adaptation for service-oriented product lines." In Proceedings of the 15th International Software Product Line Conference, Volume 2, p. 35. ACM, 2011. (Huebsche scher et a et al. 2008) ) Huebscher, Markus C., and Julie A.

• McCann. "A survey of autonomic computing—degrees, models, and

applications." ACM Computing Surveys (CSUR) 40, no. 3 (2008): 7. (Kephar art et a et al. 2003) Kephart, Jeffrey O., and David M. Chess. "The vision of autonomic computing."Computer 36, no. 1 (2003): 41-50. (Floch et et al 2006) Floch, Jacqueline, et al. "Using architecture models for runtime adaptability."Software, IEEE 23.2 (2006): 62-70.

127

128

(Hallst steinse einsen et et al. 2006) ) Hallsteinsen, Svein, Erlend Stav, Arnor Solberg, and Jacqueline Floch. "Using product line techniques to build adaptive systems." In Software Product Line Conference, 2006 10th International,

• pp. 10-pp. IEEE, 2006.

(Morin rin et et al. 2009) 09) Morin, Brice, Olivier Barais, J-M. Jézéquel, Franck Fleurey, and Arnor Solberg. "Models@ run. time to support dynamic adaptation." Computer 42, no. 10 (2009): 44-51. (Par Parra a et et al. 2009) 09) Parra, Carlos, Xavier Blanc, and Laurence Duchien. "Context awareness for dynamic service-oriented product lines." In Proceedings of the 13th International Software Product Line Conference, pp. 131-140. Carnegie Mellon University, 2009. (Kramer amer et et al. 2007) 7) Kramer, Jeff, and Jeff Magee. "Self-managed systems: an architectural challenge." In Future of Software Engineering, 2007. FOSE'07, pp. 259-268. IEEE, 2007. (Lee ee et et al. 2012) 12) Lee, Jaejoon, Gerald Kotonya, and Daniel Robinson. "Engineering Service-Based Dynamic Software Product Lines." Computer (2012): 49-55.

129

(Wang ng et et al. 2004) Wang, Xiao Hang, D. Qing Zhang, Tao Gu, and Hung Keng Pung. "Ontology based context modeling and reasoning using OWL." In Pervasive Computing and Communications Workshops, 2004. Proceedings of the Second IEEE Annual Conference on, pp. 18-22. IEEE, 2004. (Goma maa et et al. 2004) Gomaa, Hassan, and Mohamed Hussein. "Dynamic software reconfiguration in software product families." In Software Product-Family Engineering, pp. 435-444. Springer Berlin Heidelberg, 2004. (Ach Acher er et et al. 2011) ) Acher, Mathieu, Philippe Collet, Philippe Lahire, Sabine Moisan, and J-P. Rigault. "Modeling variability from requirements to runtime." In Engineering

• f Complex Computer Systems (ICECCS), 2011 16th IEEE International Conference
• n, pp. 77-86. IEEE, 2011.

(Cou

• ulson

son et et al. 2004) Coulson, Geoff, Gordon S. Blair, Paul Grace, Ackbar Joolia, Kevin Lee, and Jo Ueyama. "A component model for building systems software." (2004): 684-689 (Brune neton

• n et

et al. 2006) Bruneton, Eric, Thierry Coupaye, Matthieu Leclercq, Vivien Quéma, and Jean‐Bernard Stefani. "The fractal component model and its support in java."Software: Practice and Experience 36, no. 11‐12 (2006): 1257-1284.

130

(Marples ples et et al. 2001) ) Marples, Dave, and Peter Kriens. "The open services gateway initiative: An introductory overview." Communications Magazine, IEEE 39, no. 12 (2001): 110-114. (Lee et et al. 2006) ) Lee, Jaejoon, and Kyo Chul Kang. "A feature-oriented approach to developing dynamically reconfigurable products in product line engineering." In Software Product Line Conference, 2006 10th International, pp. 10-pp. IEEE, 2006. (Alferez erez et et al. 2011) Alferez, Germán H., and Vicente Pelechano. "Context-aware autonomous web services in software product lines." In Software Product Line Conference (SPLC), 2011 15th International, pp. 100-109. IEEE, 2011. (Bares esi 2012) ) Baresi, Luciano, Sam Guinea, and Liliana Pasquale. "Service- Oriented Dynamic Software Product Lines." Computer (2012): 42-48. (Perrou

• uin

in et et al. 2012) ) Perrouin, Gilles, Brice Morin, Franck Chauvel, Franck Fleurey, Jacques Klein, Yves Le Traon, Olivier Barais, and J. Jezequel. "Towards flexible evolution of dynamically adaptive systems." In Software Engineering (ICSE), 2012 34th International Conference on, pp. 1353-1356. IEEE, 2012.

131

 Thank you!