Autonomic Software Product Lines (ASPL) Nadeem Abbas
Jesper Andersson
Welf Löwe
Linnaeus University Software Technology Group +46(0)470 767548
Linnaeus University Software Technology Group +46(0)470 708460
Linnaeus University Software Technology Group +46(0)470 708495
[email protected]
[email protected]
[email protected]
ABSTRACT We describe ongoing work on a variability mechanism for Autonomic Software Product Lines (ASPL). The autonomic software product lines have self-management characteristics that make product line instances more resilient to context changes and some aspects of product line evolution. Instances sense the context, selects and bind the best component variants to variation-points at run-time. The variability mechanism we describe is composed of a profile guided dispatch based on off-line and on-line training processes. Together they form a simple, yet powerful variability mechanism that continuously learns, which variants to bind given the current context and system goals.
Categories and Subject Descriptors D.2 [Software Engineering]: Software Product Lines, Dynamic Software Product Lines—variability management; D.2 [Software Engineering]: Autonomic Computing—autonomic elements, autonomic products; D.2.9 [Software Engineering]: Management—self-managing software systems; D.2.11 [Software Engineering]: Software Architectures— autonomic product line architecture
General Terms off-line training, on-line, MAPE-K
Keywords variability, variants, variation-points, autonomic elements, context, goals
1.
INTRODUCTION
High quality, time-to-market, and low cost development are universal business goals for software industry [7]. To achieve these goals, well defined business strategies that improve productivity and efficiency are required. In the
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ECSA 2010, August 23-26, 2010 Copenhagen, Denmark Copyright 2010 ACM ACM 978-1-4503-0179-4/10/08 ...$10.00.
324
manufacturing world, products in the same product category, from the same manufacturer, share features and components. Similarly, software products, in a same category, e.g. database, operating systems, web application, share a lot (features, components, protocols) to form product families [24]. This opens a window of opportunity for businesses to come up with a reuse strategy inspired by production engineering, product line engineering. “Software Product Line (SPL) is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way” [23]. The basic philosophy behind SPL is strategic reuse of assets, including requirements, domain knowledge, architecture knowledge, code or software components, test cases, etc. Product line engineering has benefited industries by reducing development time and costs along with improving quality of the products. Due to all its potential, order-ofmagnitude improvements in time to market, cost, productivity, and quality, SPL has emerged as one of the most promising software development strategies [22]. An established software product line consists of a set of architectural artifacts and a number of component variants that together capture the software product lines’ scope, i.e., commonalities and variabilities of the product range. New products are instantiated from the product line and over time the product line evolves to meet new product requirements. During instantiation, software engineers make design decisions where they bind specific variants to variationpoints in the product line architecture. Software products delivered by classic SPLs have static bindings of the underlying components, and lack support for dynamic reconfiguration. Such products may perform well in a static world with few or no changes in requirements, environment, or other related concerns. However, in a dynamic world we need selfadaptive products that may adapt according to the current requirements, context, and goals; and improved support for such software product lines [2]. The fact that product lines may evolve due to external changes calls for extensions to the classical software product line approaches. Dynamic Software Product Lines (DSPL) extends the classic SPL approach with means to instantiate reconfigurable products that may adapt to changes in their requirements or environment [13]. Dynamic variability (dynamic changes in variation-points and bindings), context awareness, autonomic or self-adaptation, and autonomic decision making are some of the required properties for DSPL,
Component Variants
prescribed by Hallsteinsen et al. [13]. Our approach, autonomic SPL, described in Section 4 exhibits all these characteristics, as it provides for a context-aware, profile guided, dispatch mechanism to deliver reconfigurable products in an autonomic manner. The remainder of this paper is organized as follows. Section 2 discusses the concept of variability. In Section 3, we introduce the field of autonomic computing with a focus on autonomic elements. Our ASPL approach is introduced in Section 4, further discussed and exemplified in Section 5, and evaluated in Section 6. In Section 7, we discuss related work. Section 8 concludes and discusses future work.
System Goals
System Context
Variation Point
2.
SOFTWARE VARIABILITY
Software variability is the ability of a software system or any other software artifact to be efficiently extended, changed, customized or configured for use in a specific context. It is abstracted as variants and variation-points. Software products in a domain share a set of common features. These common features within a product family are mixed with product-specific variations or differences resulting in product variability. Product line engineering exploits commonalities among similar products, along with handling variability in an efficient manner. In this paper we address a certain class of systems, systems with built in support for evolution and context-awareness. This adds another set of variability dimensions. The Product Line Architecture (PLA) is pivotal for managing variability. It is an abstraction of a product line and serves developers as a skeleton or blueprint for the actual systems. It provides “a single specification capturing the overall architecture of a series of closely related products” [21]. Further, the PLA defines a set of mandatory elements, variants, and variation-points. Mandatory elements represent commonalities and are part of every product in the product line. Whereas variants and variant-points together deal with product line variability. A variant corresponds to one of the alternatives specifically designed and developed to address a particular variability. Variation-points in a PLA represent insertion points for product variants, i.e., variants are bound to the system through these points. Binding may take place as early as in requirements analysis or as late as at run-time, whenever required by the system and whenever sufficient knowledge is available. Variation-points may also be unbound (left open) or rebound with a different variant. This is due to changes in the product’s requirements, including the product’s context. Figure 1 depicts variability in relation to component variants, system goals, and system context. Each variant set implements specific features, i.e., a combination of functionality and quality requirements, and may be bound to variation-points. Variant selection depends on a system’s goals and context. The bi-directional dependencies depicted by the arrows in Figure 1 indicate complex semantics effecting the decision process. For instance, the current context may impose restrictions on the variant set and that the currently bound variant restricts what is reified as context. In an evolving system, the goals, the context and available variants form the basis for the design decision. The context represents all variables that affect the variants’ behaviors and directly or indirectly affect to what extent a variant fulfills its contract. The goals and context are the decisive factor for design decisions where software engineers select which
325
Figure 1: Variability: Variants, Goals and Context variant to bind to a variation point. A challenge is that neither the product line architecture nor the goals and context are fix-points. A product line evolves over time due to goal evolution; new variants are added, old ones are removed, products evolve and context changes at run-time. This implies that design decisions will have to change at run-time to adapt the system. This calls for new, more flexible and adaptable, types of variability mechanisms that can adapt to and manage changes autonomously [2]. To address this challenge we introduce ASPLs, a new variability mechanism proposed in this paper to develop and manage dynamic software product lines. Autonomic computing provides basis for the Autonomic SPLs, therefore at first we briefly describe related concepts from autonomic computing in the next Section.
3.
AUTONOMIC COMPUTING
Autonomic Computing (AC) [19] is a fundamental component in our effort towards self-managing product-line instances. Its primary goal is to design and develop system that are able to adapt to changes in the system itself or in the system’s environment. The vision aims at self-managing systems that can adapt, optimize, evolve, and manage themselves or another system, ideally with no or minimal human intervention. The idea is inspired by the human autonomic nervous system [15, 17, 19]. Kephart et al. enumerate four characteristics of a self-managing system: self-configuration, self-optimization, self-healing, and self-protection [19, 1, 15]. The Autonomic Element (AE) is the basic building block in autonomic computing systems [19, 10]. The AE is a software component that (partially) achieves some self-managing characteristics by managing sub-systems. The basic structure of an autonomic element is depicted in Figure 2. An autonomic element implements a MAPE-K loop. MAPEK (Monitor, Analyze, Plan, Execute, and Knowledge) is a concept that constitutes a control loop [4]. It monitors and controls one or more underlying managed elements [1]. A managed element may be hardware, such as a printer, a router, or software, such as a database, a directory service, or another AE. The MAPE-K like autonomic elements may also control parts of or specific aspects of a software system, such as, load-balancing. The MAPE-K control loop parts are: Monitor: This part is responsible for monitoring the managed resources and collect, aggregate, and filter data.
Sensor
Effector
Analyze
Monitor
Plan
Knowledge
Sensor
Execute Effector
Managed Element
Figure 2: Autonomic Element: MAPE-K Loop Monitoring is done through sensors. Analyze: This part of the loop analyzes data reported by the monitor part. Analysis aims at understanding what the current state is and if measures should be taken. Plan: In the plan part an action plan is prepared on the basis of the analysis results. The plan is a number of measures that will move the system from its current to a desired state Execute: In this part the plan is executed and controlled. Effectors perform the planned actions on the managed resource. Knowledge: Knowledge source is central to the control loop and is accessible by all parts in the loop. Apart from data collected and analyzed, it contains additional knowledge such as architectural models, goal models, policies, and change plans [1]. The MAPE-K loop is controlled by a manager, an embedded part of an autonomic element that coordinates the individual activities. Several autonomic elements may be combined to achieve the desired behaviors. For instance, you may have several autonomic elements in a distributed system that are responsible for load-balancing locally. These are coordinated by a central autonomic element, which is responsible for managing load-balancing at the system level. The interface and the way these autonomic elements interact with each other is defined by an autonomic computing architecture.
4.
TOWARDS AUTONOMIC SPLS
The combination of autonomic computing and the software product line approaches gives rise to the notion of autonomic software product lines (ASPLs). The ASPL instance has the ability to self-manage variations in its context and variations in the product line itself. We model an autonomic software product line architecture based on autonomic computing architecture supported by on-line training to deal with dynamic variation and product line evolution. The Software Engineering Institute (SEI) provides a framework [23] for software product lines. It defines three essential activities to achieve a software product line : core asset development, product development, and management. Core assets are the basic components of an SPL that together compose a product. It can be technical or business
326
artifacts, such as requirement specification, reference architecture, some software component or its variants. The core assets abstract both commonalities and variabilities among the products, providing a reusable set of artifacts. A number of software components and their variants according to variability requirements are developed and added to the product line. In the context of ASPLs, we assume that the autonomic elements, including knowledge models, and autonomic computing architecture models are core assets. The managed elements could be either a product line, a single product, another core asset, or part of a core asset. With the core assets in place, we continue with product instantiation. Here, a software product is composed by integrating basic software components from a pool of core assets according to a production plan, a strategy, and individual software product requirements. In this step the autonomic elements must be instantiated to meet product specific requirements. In our model, the autonomic elements implement run-time variability mechanisms that provide self-management properties, for instance, self-optimization. The third essential activity is Management [23]. A product line with relatively broad scope renders it too complex [14] and difficult to manage the core assets. Therefore, maintenance and evolution of such large scale software product lines will become a problem in itself. Another perspective of the manageability problem in SPL descends from the system’s point of view. Just like any software systems, SPL products are subject to evolution and change, requiring continuous maintenance, optimization and update efforts. Evolution of the product line itself and the context in which its products are deployed is the management problem that motivates this work. Our hypothesis is that employing autonomic elements at variation points and dynamically composing a product from a set of core components and a context, constitutes a mechanism that resolves some evolution management concerns. How self-management characteristics for product lines can be implemented by means of autonomic elements is easier to describe with a scenario. The basis for such a scenario is a product line instance or part of such an instance that will be the Managed Element, which is managed by an Autonomic Element, as depicted in Figure 2. In this scenario, the Monitor part of the MAPE-K loop uses sensors to probe current system context attributes. Monitored data consisting of problem properties and system context is forwarded to the analysis part. Different context attributes and system properties demand different components (variability) in the product. Therefore, these context attributes correspond to variability requirements in a product line. Analysis evaluates context attributes (monitored data) in consultation with production plan, product line scope and other auxiliary data in a knowledge base. Based on the facts from the analysis and individual product requirements, plan prepares a product plan. The product plan lists core components (variants), component interfaces, and their interconnection. The plan is then forwarded to the Execute activity. The execute part takes responsibility to implement the product plan by dynamically binding core components together in a software product adapted to the current context. The autonomic element uses SPL knowledge, such as architectural models and variants, to guide these steps. This outlines the autonomic software product line approach. We discuss the approach and its realization in more
detail below.
5.
Sensor
AUTONOMIC SPL IN PRACTICE
To implement autonomic software product lines, we extend our Profile Guided Composition Model [3]. The profile guided composition uses off-line training to create a component and goal specific profile. The profile reflects how components behave with respect to the goal and is used at run-time by a dynamic dispatch that senses the context and dispatches the best-fit component variant. We distinguish three phases; (1) system design, (2) off-line training, and (3) dynamic product instantiation. During the design phases, the product line is scoped, a production plan and supporting infrastructure for product composition are defined, and all core components and their admissible variants are designed and developed. For presentation purposes, we distinguish two cases, a closed world, where the set of contexts and core assets are fixed, and an open world, where both both contexts and core assets may evolve.
5.1
Effector Online Training
Analyze
Monitor
327
Concern Learning Models Models
Sensor
Execute
Effector
Profile Guided Dispatch
Analyze
Plan
Dispatch Table
Monitor
Closed World
In a closed world, the ASPL derives new instances at runtime based on monitored context information. Products are composed and open variation-points get bound under the control of a MAPE-K loop. The loop requires sufficient knowledge to make informed decisions about which variant to bind for a given context. That knowledge is attained from off-line training. To that end, we define training data, which is used to find the best suitable components and variants for a product given some context(s) and management goal(s). When the core components, variants and the training infrastructure is ready, we perform off-line training. Training data provide artificial call context for this process. During off-line training best fit variants for given contexts system goals are computed and stored in a dispatch table. Each of the component’s variants is called with all specified context attributes. Variants’ behavior is monitored and analyzed with respect to the optimization goal. A dispatch table, representing the autonomic element’s knowledge, is prepared. It stores indexes of best fit variants against all instances of context attributes. There is a possibility that we may miss a best fit variant to be captured due to poor training data, noise from the environment or some other factors. For example, a variant which is actually the best fit is first invoked on its worst case input or is disturbed by some other process, and hence it is ignored in the best variant selection process. Once the off-line training is completed and the dispatch tables are populated, the autonomic product line is ready for deployment. The monitor part of the bottom-most autonomic element in Figure 3, uses sensors to probe on-line context attributes. The monitored data is forwarded to the analysis part. Here the context attributes correspond to the variability decision-space of the product line. Different context attributes and system properties demand different variants (variability) in the product. The analysis activity evaluates context attributes in consultation with the dispatch table in the knowledge base. The best fit variants with respect to the current system context are retrieved from the dispatch table and become a part of the product plan. This corresponds to the plan part in MAPE-K loop. The product plan is then forwarded to the execute part that binds the selected best fit variants to their corresponding variationpoints according to the plan.
Plan
Sensor
Execute Effector
Base-level system
Figure 3: An Autonomic SPL Instance
5.2
Open World
In the closed world setup described above, we do not consider the fact that we may have errors in our knowledge base and the fact that product lines and individual products evolve. Evolution affects the core-assets, for instance, addition or removal of variants, and affects the product’s context. The strategy presented above is not capable to deal with such changes and will result in sub-optimal products due to flaws in the dispatch table. To resolve these issues, we introduce an on-line learning mechanism in the autonomic product line. The on-line learning empowers SPL with self-management characteristics. To autonomically control the on-line learning process, we add another MAPE-K loop on the top of the existing MAPE-K loop, as depicted in the Figure 3. Base level system in the figure represents a product line instance, the MAPE-K loop in the middle is the profile guided dispatch variability mechanism, while the top most MAPE-K loop controls an on-line training process. Instead of selecting the best fit variant from the dispatch table, the MAPE-K loop for on-line training uses a learning strategy to optimize the knowledge on the level beneath, i.e., to modify the dispatch table. One example of such a strategy is an on-line training loop that randomly intervenes with the profile guided dispatch. It selects a non-optimal variant with a probability indirectly proportional to their “distance” from the optimum variant as derived in off-line training. It monitors and evaluates its behavior w.r.t the optimization goal, and compare it to the existing best fit variant. If the non-optimal variant performs better than it will replace the existing so called best fit (actually sub-optimal) variant in the dispatch table
for the current context. The probability table will also be updated according to these new settings. The on-line training mechanism uses, besides the probability table, other concern models such as measurement and evaluation models for the optimization goals as well as information about available learning strategies to be employed in training. This strategy deals with both of the aforementioned problems, core asset and context evolution: • Core asset: If new variants are added or existing ones removed, the dispatch table at the bottom-most MAPE loop becomes invalid. The self-optimization mechanism will gradually improve the situation. If a new variant arrives, this will, over time, be “tested” against the current variant champion for all existing contexts. • Context: If a product is moved to a new context or if the context changes over time, the dispatch table does not guarantee to be valid. The self-optimization strategy will make sure that alternative variants are executed and new contexts are added to the dispatch table. In this section we have outlined a straightforward online learning mechanism. We recognize the fact that this problem is indeed very complex and requires more advanced strategies than the one described here.
6.
EVALUATION
To evaluate our ASPL approach, we implemented a simple product line for a matrix multiplication application. The implemented software product line is an extension of our experiments from the profile guided composition technique [3]. The goal of the product line is to return a self-optimizing matrix multiplication product that takes two square matrices as input and returns their product matrix as a result. To model variability in the product line we apply variations in the system context and use different algorithms for the multiplication. Varying context properties selected here are: input matrix size, density, and data structure representation. For off-line training, we generate two square matrices m1 and m2 of size 1 to 1024, with a stride of 16, and data elements of type double precision. Density (ratio of zero to non-zero data elements) of the matrices has two distinct variations: sparse and dense. A sparse matrix has more zero elements than the non-zeros whereas in dense matrix all data elements are non-zeros. Apart from the matrix data, we also vary the data structure representation (either suitable for dense or sparse matrix) for the two matrices. These varying context attributes provide artificial call context for the product line. Here we consider only one optimization goal and that is performance optimization, in terms of execution time required to perform matrix multiplication. The optimization goal remains static, i.e., it does not change during the product life cycle. Another dimension of variability is modeled in terms of five algorithms used for matrix multiplication, namely: Baseline, BaselineSparse, Inlined, Recursive, and Strassen. Explanation of these algorithms is beyond scope of this article, so we just assume them as representative of variants for a product. These five algorithms are instantiated as the product variants. Hence there were five candidates in the variant
328
repository, out of which a best-fit variant is picked to compose a product based on the optimization goal and context attributes. At first, the product line is trained off-line under the control of a MAPE-K loop. Execution time for all the five variants is monitored, analyzed and the variant returning best execution time is tagged in the dispatch table. Once the off-line training is completed, the autonomic matrix multiplication product line is ready for instantiation. To test and evaluate the productivity, we provide variable context (matrix sizes, data density and data structure) to the product line. The product line probes context attributes with the help of a monitor, analyze them and retrieves a best-fit variant (under current context) from the knowledge base (dispatch table). Figure 4(a) shows performance of the product (optimized algorithm) composed by our autonomic product line with comparison to the other original simple products. X-axis in the graph represents size of the square matrices used during evaluation, whereas the Y-axis marks execution time in milli seconds consumed by the variants. The ‘SPLProduct’ (down in the order) composed by our ASPL executes faster than all other simple matrix multiplication implementations. Note that the SPLProduct instantiated by out ASPL approach outperforms all plain input variants as it may dynamically switch from one variant to another during recursive calls with varying contexts. Self-optimization characteristic of the ASPL approach was also evaluated. As mentioned earlier, the closed-world ASPL setup may suffer from sub-optimal entries in the dispatch table. To realize self-optimization, we added an on-line learning strategy based on probability tables derived during offline training, as described in Section 5. This enables the ASPL to remove sub-optimal entries from the dispatch table. Figure 4(b) shows the optimization results of the on-line learning process. The on-line learning has slightly improved the autonomic matrix multiplication product line in terms of the optimization goal. This endorses credibility of our simple off-line training as well, since both the curves in Figure 4(b) are almost close. This shows that the simple off-line training based SPL has satisfactory performance. Even if there remain some errors in off-line training, they are likely to be removed and optimized autonomically by the on-line learning process on the top.
7.
RELATED WORK
The autonomic variability management approach presented in this work is closely related to ongoing research in domains of dynamic software product lines (DSPL) [13, 12, 5, 26, 6, 20, 8, 9], context-oriented programing (COP) [25, 11, 18, 16] and self-managing autonomic systems [5, 15, 17, 19]. Context information becomes extremely important when we apply product line development approach to build autonomic pervasive systems. COP is a novel programming approach aimed to facilitate development of context-oriented products. It allows to design products with number of gaps or open-terms which are later filled by selecting pieces of code from a repository of candidates. The selection process is guided by execution context and product goals [18]. The key objective is to fill the gaps with best-fit code (variants). This is what Our ASPL do by dynamically dispatching bestfit variants to the variation-points. In future, we plan to dig more in COP domain and analyze how the achievements in the COP domain can be used for the benefits of our ASPL
approach. Gomaa and Hussein [12] suggested to apply dynamic software reconfiguration patterns as a solution to build dynamically reconfigurable products. The dynamic software reconfiguration pattern specifies how a set of components that make up a design, an architecture or a product family specific architecture pattern dynamically cooperate to change the configuration of the product to a new configuration. Reconfiguration scenarios (to address different reconfiguration requirements) and a change management model are required for a reconfiguration pattern. Product family engineering, target system configuration, and target system reconfiguration are the three major activities in their proposed Reconfigurable Evolutionary Product Family Life Cycle (REPFLC). However the details about the activities in REPFLC are very abstract. Another issue is that there is no autonomic mechanism to trigger adaptation or reconfiguration process. It requires a user to specify changes in product configuration. In relation to their work, out ASPL approach have a built in mechanism, MAPE-K loop, to trigger and control the reconfiguration process dynamically. Several different feature based approaches [20, 26, 9] to develop dynamically reconfigurable products have been presented. Lee and Kang [20] suggested a feature-oriented approach in which a product line is analyzed in terms of its features and their binding time. This feature binding analysis serves as a key design driver to identify and manage variation points. Dynamically reconfigurable core assets are developed based on the feature binding analysis. A dynamic reconfigurator takes care of the reconfigurations activities including: when to reconfigure, what to reconfigure, and how to reconfigure. Performance of this approach depends on the likelihood of feature binding analysis. It does not specify any mechanism to deal with unexpected changes in system context, requirements, or to incorporate new features in the product line. In our ASPL approach we have special emphasis on self-optimization based on run-time context and product goals. To replace feature binding analysis we have an off-line training mechanism during which we analyze all the features and tag the best-fit variant in a decision (dispatch) table. The binding decisions (dispatch table) are further updated to remove any noise and to incorporate both new variants and features during on-line learning. Trinidad et al. [26] proposed another feature based DSPL model. They have four key steps in their proposal. Step-1 requires to define core architecture by identifying core product line features. Step-2 transforms core architecture to a dynamic architecture based on non-core variable features. In step-3, a configurator component is developed that provides dynamic behavior for a product line, similar to reconfigurator component in Lee and Kang’s approach [20]. The configurator dynamically receives feature de/activation requests, validates them, and performs feature de/activation accordingly. Step-4 leads to an initial product defined by selecting an initial set of core and non-core features. In relation to our work, we have a MAPE-K control loop with embedded dispatch mechanism that works as a configurator to dynamically de/activate variants. Feature based DSPL model proposed by Trinidad and colleagues does not provide low level details, such as how the adaptation process is triggered or what starts reconfiguration process, how configurator performs de/activation of non-core features. The unique combination of off-line and on-line training
329
with multiple coupled MAPE-K control loops results in a dynamically adaptable product line architecture. Reducing the management problem for SPLs is crucial and the ASPL approach contributes with some interesting results here. Off-line training provides a well justified knowledge base for on-line, self-managed, feature binding analysis and decision making. Future changes in technology, product environment, functional or quality requirements are also to some extent supported by self-management through on-line learning.
8.
CONCLUSIONS AND FUTURE WORK
We have presented an approach to software product line management that introduces autonomic elements as variability mechanisms. Autonomic elements provide contextbased reasoning capabilities to a product line, hence, the products themselves may reason about and bind the best variants at run-time based on the current application context. Adding reasoning to a product line is not novel in itself, but we demonstrated how autonomic elements, controlling other autonomic elements, may be used to realize software product lines, capable of self-managing software product line and context evolution. The model we presented is simple and straightforward but the initial evaluations show promising results. We will further investigate how to improve both the closed-world and open-world approaches, including context prediction and sensing, training setup, and on-line sensing and reasoning. In addition, we plan to further verify our proposed model of ASPL and on-line learning method. We also plan to evaluate our ASPL approach in comparison to other popular approaches of classic SPL and DSPL. We will perform extensive testing, where we plan to intentionally seed errors in the dispatch table, then let the on-line learning mechanism improve the self-management properties gradually by detecting and removing these errors. These experiments aim at verifying the robustness of the approach. So far, we have focused on one self-management characteristic, self-optimization. In our plans for the future we also have other characteristics that we will study using the autonomic product line approach.
9.
REFERENCES
[1] An Architectural Blueprint for Autonomic Computing, White Paper, 2006. [2] J. Andersson and J. Bosch. Development and use of dynamic product-line architectures. IEE Proceedings Software, 152(1):15–28, February 2005. [3] J. Andersson, M. Ericsson, C. Kessler, and W. L¨ owe. Profile-Guided Composition. In Proceedings of the 7th International Conference on Software Composition, pages 157–164. Springer-Verlag New York Inc, 2008. [4] Y. Brun et al. Engineering Self-Adaptive Systems Through Feedback Loops. Software Engineering for Self-Adaptive Systems, 5525:48–70, 2009. [5] C. Cetina, J. Fons, and V. Pelechano. Applying Software Product Lines to Build Autonomic Pervasive Systems. In 12th International Software Product Line Conference, pages 117–126. IEEE, 2008. [6] C. Cetina, V. Pelechano, P. Trinidad, and A. Cortes. An Architectural Discussion on DSPL. In Proceedings
[7]
[8]
[9]
[10]
[11] [12]
[13]
[14]
[15] [16]
[17]
[18]
[19] [20]
[21]
[22] [23] [24]
[25]
of the 12th International Software Product Line Conference (SPLC 2008), pages 59–68, 2008. P. Clements and L. Northrop. Software Product Lines: Practices and Patterns. Addison-Wesley Reading MA, 2001. T. Dinkelaker, R. Mitschke, K. Fetzer, and M. Mezini. A Dynamic Software Product Line Approach Using Aspect Models at Runtime. In First Workshop on Composition and Variability’10 Rennes, 2010. P. Fernandes, C. Werner, and L. Murta. Feature Modeling for Context-Aware Software Product Lines. In Proceedings of the 20th International Conference on Software Engineering & Knowledge Engineering (San Francisco, CA, USA, 2008). M. Fuad and M. Oudshoorn. System Architecture of an Autonomic Element. In Fourth IEEE International Workshop on Engineering of Autonomic and Autonomous Systems, 2007. EASe’07, pages 89–93, 2007. M. Gassanenko. Context-Oriented Programming. EuroForth’98, 1998. H. Gomaa and M. Hussein. Dynamic Software Reconfiguration in Software Product Families. Software Product-Family Engineering, pages 435–444, 2004. S. Hallsteinsen, M. Hinchey, S. Park, and K. Schmid. Dynamic Software Product Lines. Computer, 41(4):93–95, 2008. P. Heymans and J. Trigaux. Software Product Line: State of the Art. Technical report, Institut d’Informatique FUNDP, Namur, 2003. M. Hinchey and R. Sterritt. Self-Managing Software. Computer, 39(2):107–109, 2006. R. Hirschfeld, P. Costanza, and O. Nierstrasz. Context-oriented programming. Journal of Object Technology, March-April 2008, ETH Zurich, 7(3):125–151, 2008. M. Huebscher and J. McCann. A Survey of Autonomic Computing - Degrees, Models, and Applications. ACM Computing Surveys (CSUR), 40(3):7, 2008. R. Keays and A. Rakotonirainy. Context-oriented programming. In MobiDe ’03: Proceedings of the 3rd ACM international workshop on Data engineering for wireless and mobile access, pages 9–16, 2003. J. Kephart and D. Chess. The Vision of Autonomic Computing. Computer, 36(1):41–50, 2003. J. Lee and K. Kang. A Feature-Oriented Approach to Developing Dynamically Reconfigurable Products in Product Line Engineering. Software Product Line Conference, International, 0:131–140, 2006. H. Muccini and A. Van Der Hoek. Towards Testing Product Line Architectures. Electronic Notes in Theoretical Computer Science, 82(6):99–109, 2003. L. Northrop. SEI’s Software Product line Tenets. IEEE software, 19(4):32–40, 2002. L. Northrop, P. Clements, et al. A Framework for Software Product Line Practice, Version 5.0, 2007. D. L. Parnas. On the Design and Development of Program Families. IEEE Transactions on Software Engineering, SE-2(1):1–9, 1976. A. Rakotonirainy. Context-Oriented Programming for
330
Pervasive Systems. In Proceddings of the ACM Dynamic Languages Symposium. Citeseer, 2002. [26] P. Trinidad, A. Ruiz-Cort´es, J. Pena, and D. Benavides. Mapping Feature Models onto Component Models to Build Dynamic Software Product Lines. DSPL [1 2], 2007.
(a) Autonomic Matrix Multiplication Product Line vs Simple Multiplication Product
(b) Self-Optimization of the SPL with On-line Learning Figure 4: Performance Evaluation
331
