Knowledge Evolution in Autonomic Software Product Lines

Transcription

1 Knowledge Evolution in Autonomic Software Product Lines Nadeem Abbas Linnaeus University Software Technology Group +46(0) Jesper Andersson Linnaeus University Software Technology Group +46(0) Danny Weyns Linnaeus University Software Technology Group +46(0) ABSTRACT We describe ongoing work in knowledge evolution management for autonomic software product lines. We explore how an autonomic product line may benefit from new knowledge originating from different source activities and artifacts at run time. The motivation for sharing run-time knowledge is that products may self-optimize at run time and thus improve quality faster compared to traditional software product line evolution. We propose two mechanisms that support knowledge evolution in product lines: online learning and knowledge sharing. We describe two basic scenarios for runtime knowledge evolution that involves these mechanisms. We evaluate online learning and knowledge sharing in a small product line setting that shows promising results. General Terms Software design, product-line management Keywords Software product-lines, self-adaptation, knowledge sharing, online learning 1. INTRODUCTION A Software Product Line (SPL) is a set of softwareintensive 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 SPL approach to software development offers valuable improvements in productivity and quality, with a positive impact on time to market, cost, and other business drivers [25, 31]. The basic philosophy behind SPL is strategic reuse of resources created and consumed throughout the software product family s life-cycles. The fundamental assumption is that similar software products developed by an organization may be classified as a product line. In a product line, products share features (commonalities) while providing 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. SPLC 11, August 21-26, 2011, Munich, Germany Copyright 2011 ACM /11/08...$ additional features (variability) for specialization. A Product Line Architecture (PLA) provides a single specification capturing the overall architecture of a series of closely related products [22]. It defines a set of variants and variation points to address variability in a product line. Products are instantiated by binding specific variants to variation points. Traditional SPLs mostly bind features statically, that is, before a product is delivered [14]. Products with statically bound features perform well in settings where changes to requirements, product environment, or other related concerns are rare, but suffer in more dynamic environments where such changes occur frequently. Examples include executing environments of pervasive and ubiquitous systems, ultralarge systems, etc. Such systems require a higher degree of adaptability [8, 14], enabling them to dynamically adapt to changing contexts and goals. We have previously described how industry expressed lack of support for such software product lines [3]. SPLs with these characteristics are known as Dynamic Software Product Lines (DSPLs). A DSPL supports different binding times. Some variation points related to the environment s static properties are bound before run time, while other variation points, more dependent on the dynamic environment and goals, are bound (rebound) at run time. A DSPL must support several variability mechanisms and its products require specialized support for dynamic binding [7, 10, 13, 30], that is, a variation point may be rebound with a different variant at runtime. An Autonomic Software Product Line (ASPL) [1] is a DSPL that supports autonomic product adaptation and evolution. Products of a ASPL are equipped with explicit control loops that offer support for self-adaptation characteristics, such as self-configuration and self-optimization [8, 24, 26]. ASPL products are provided with a dynamic variability mechanism implemented through three key processes that respectively (1) monitor the product and its context, (2) provide contextaware composition to realize the adaptation goals, and (3) perform online learning of the optimal composition decisions. The main focus of the community has been on technical aspects of Software Product Line Engineering (SPLE) to realize strategic reuse (such as product line analysis, modeling, and development), while the knowledge aspect has received less attention [15]. However, product lines maintain knowledge that constitutes the foundation for design decisions, for instance, when and how to bind variants to variation points. Knowledge in a product line originate from different source activities and artifacts. One major source is feedback (change requests, failure reports, etc.) from stakeholders and product line products. Another major source of knowledge

2 are activities and artifacts related to the evolution of product line core assets, such as availability of updated components, algorithms, frameworks/apis, data structures etc. Knowledge management plays an important role in the success of various activities of product line engineering [16]. In traditional SPLs the knowledge changes only when the SPL evolves during planned offline maintenance or evolution cycles [28]. However today s computing landscape is more dynamic with frequent changes in goals, environment, and implementation technology. Consequently what we call knowledge at one point in time, may quickly become obsolete. We have not seen any efforts capitalizing on knowledge evolution and knowledge-oriented product line engineering in a dynamic software product line setting. In this work we explore how a SPL may benefit from knowledge derived by, and shared among member products at run time. This mimics to some degree the behavior of traditional life-cycle activities where products in a SPL incorporate lessons learned in other products during regular planned evolution [28]. The motivation for sharing knowledge at run time is that products may self-optimize and thus improve quality faster compared to traditional SPL evolution strategies. For example, one product derives new knowledge and shares it with other products in the SPL. New knowledge may trigger either internal adaptation (products adapt themselves) or external adaptation (products adapted by another application). Additionally, new knowledge will contribute to improvements in quality of future products in the SPL [20]. The contribution of this work is an extension of ASPLs with two mechanisms that provide support for run-time knowledge evolution: online learning and knowledge sharing. ASPL products have online learning mechanism that continuously evolve a product s internal knowledge and, in addition, may trigger internal adaptations. With the mechanisms in place, ASPL products derive new knowledge that they may share with other products in the product line. Based on the conjecture that products in a product line benefit from knowledge sharing, we hypothesize that the products overall quality can be improved by run-time knowledge sharing and evolution. The remainder of this article is organized as follows. Section 2 describes autonomic software product lines and their main activities: context profiling, context aware composition, and online learning. In Section 3, we discuss how ASPLs can be extended with knowledge sharing mechanisms, and provide an example of knowledge sharing. Related work is discussed in Section 4. We conclude and discuss avenues of future research in Section ASPL An ASPL is a DSPL [14] that provides a dynamic variability mechanism to develop self-adaptive products capable to (re-)configure and optimize themselves with respect to changes in their context and goals [1]. An ASPL, as depicted in Figure 1, involves three key processes: (1) context-profiling, (2) context-aware composition [5], and (3) online learning. These processes together provide for autonomic productline product evolution. Processes 1 and 2 are performed at development time to profile a product and create baseline knowledge for a product line, while processes 2 and 3 are included in all product configurations and are performed at run time. Processes 2 and 3, contribute a dynamic variability mechanism. More details about these key processes follow. Product Line Evolution Product Line Evolution Management Control Flow Information Flow Selected Variant Dispatch Table Adaptation Context Profiling Variants Offline Training Knowledge Base Product Configuration Deployment Context Profiles Legend Monitor Online Learning Execute AE Product Figure 1: Autonomic Software Product Line Reflecive Computation 1..* Reasons about and acts upon Monitor Analyze Plan Execute monitors 0..* Subsystem 0..* adapts 1..* Reflection Model 1..* Reflective Subsystem Autonomic Element Figure 2: FORMS description of an Autonomic Element To achieve self-adaptive characteristics in the ASPL products, we use Autonomic Elements (AE) [8, 18] to realize the three key processes. The AE is a basic building block in autonomic and self-adaptive computing [4, 12, 17]. Its architecture is based on the the notion of reflection described by Maes [21], and implements a MAPE-K (Monitor, Analyze, Plan, Execute and Knowledge) control loop to adapt or control a software system. To monitor and adapt specific aspects of the underlying software system it requires monitor and execute interfaces. The underlying software system here is a reconfigurable product. The AE also provides interfaces that other components may use for monitoring and adapting the AE component itself. This is shown more clearly in Figure 4 where and Online Learning AE require and provide sensor and effector interfaces to monitor and perform adaptive actions on the system under control. A single AE instance may contain multiple instances of its subcomponents, e.g., multiple monitors monitoring different system aspects. This is illustrated in a more detailed FORMS [32] model (FOrmal Reference Model for Self-adaptation) shown in Figure 2. Reflection Model and Reflective Computation are the two primitives of self-adaptation defined in the FORMS model. A reflection model represents meta-level information (knowledge) and reifies subsystem entities, such as subsystem components, context attributes, etc. The reflective computation uses reflection models to

3 reasons about, and adapt underlying base level subsystems. The Autonomic Element, in Figure 2, is a specialization of a Reflective-Subsystem, which is an instance of a Subsystem. The Reflective Subsystem contains a number of Reflective Computation and Reflection Model primitives. The multiplicity indicates that multiple instances may co-exist. Reflection Models are key for this work since they encode and represents knowledge. The ASPL specializes these FORMS primitives further and maps them to features and eventually component variants, for instance, multiple variants for monitoring the performance of a subsystem under control and multiple analyzer variants. 2.1 Illustrative example To support the presentation of this work we use Matrix- Multiplication (MM), a small scale ASPL [1], as an illustrative example. The Matrix-Multiplication products take two square matrices of size N as input and return a product matrix as a result. Component variants for the product line are the 5 different algorithm implementations: Inline, Baseline, BaselineSparse, Recursive, and Strassen. Supported context attributes are: input matrix size, density and their data structure representation. Performance in terms of minimal execution time is the self-optimization goal for derived products. For a detailed description of the Matrix-Multiplication ASPL we refer the interested reader to [1]. 2.2 Context Profiling Context profiling is a development time process that prepares a baseline knowledge base for context-aware composition. Context profiling maps actual contexts to variants found to be optimal, as a result of offline training or learning, with respect to the product optimization goal. As shown in Figure 2, context profiling involves offline training that invokes all variants in a selection of distinguished contexts, and establishes a baseline knowledge base, before a product is configured and deployed. Training data, used for offline training, typically comprises a set of context attributes, variants, and variant attributes. A context attribute is a property-value pair, e.g., for a matrixmultiplication product: input matrix size N = 1000, and density d = 0.5. A variant is an implementation of a software component [29]. Adhering to the component interface and behavioral semantics (e.g., matrix multiplication), variants of a component may differ from one another in their behavior implementations, data representation, or some other properties. A variant attribute is a property-value pair, e.g., execution time T = 5440 in msec, memory occupied M = 4 in MB, etc. Variant attributes are functions of a set of certain context attributes. For instance, in the matrix multiplication product line, the Strassen variant V, invoked with size N = 1000, and density d = 0.5 takes msec execution time. Here the variant attribute execution time is a function of the (problem size, problem density) context attributes. Context-profiling uses the context-aware composition mechanism to call each component s variants in all distinguished contexts, and uses the AE structure to monitor, analyze, and capture variant attributes of interest in the knowledge base. The variants information in the knowledge base is mapped to context attributes with respect to the product line goals in the form of a dispatch table. At present, we use a simple table data structure to model and implement a dispatch table, but we plan to investigate other suitable knowledge representations [9, 27], such as decision tree, ontologies etc. Once the offline training is completed, an initial knowledge base is available for context-aware composition, the subsequent activity that adapts products at run time. 2.3 Composition Context-aware composition enables adaptation of ASPL products based on their current context and goals by (re- )binding best-fit variants at run time. It is in principle a reflective subsystem that reflects on the structure and behavior of ASPL products. Context-aware composition is modeled as an AE and implements a generalized dynamic dispatch. The dynamic dispatch uses the dispatch table, established during context-profiling, as its primary source of knowledge. The dispatch table provides information about the best suited component variant for a given call context. Figure 3 shows a high-level description of the run-time behavior of the context-aware composition AE. The Monitor component monitors the base-level subsystem (deployed product) and provides a call context. The Analysis and Plan components analyze the call context and consult the knowledge base (dispatch table) to retrieve a best-fit variant. The dispatch manager (Execute) binds the variant to the variation point and invokes it. Seq: Context-aware composition manager: AEManager dispatchtable vp11 : VariationPoint c : ComponentVariant getbestfitvariant(c:callcontext) bind(c : ComponentVariant) invoke() lookup() Figure 3: Dynamic Dispatch-Sequence Diagram 2.4 Online Learning The baseline knowledge base used for context-aware composition is derived offline. However, at run time, a number of issues may invalidate this knowledge. 1. Offline training is typically imperfect and likely to have errors or sub-optimal information due to various causes, e.g., imperfect training data and measurements. 2. A product s context is dynamic with frequent changes in goals, environment, and implementation technology. 3. Product line evolution includes evolution of core assets, such as features, variants, and architectures. These issues require that an ASPL and its products include mechanisms for knowledge derivation and evolution. Online learning is a dynamic knowledge evolution mechanism. As shown in Figure 4, online learning operates on top of context-aware composition. It adapts the context-aware composition by providing new knowledge to the contextaware composition s knowledge base. The context-aware composition in turn adapts the behavior of the underlying product, as described above. The realization of the learning mechanism is divided in three phases: (1) instrumentation, (2) monitored execution,

4 Monitor Sensor Effector Monitor Sensor Effector Analyze Analyze Sensor Probabilistic Selection Dispatch Table Plan Plan Effector Product Execute Execute Figure 4: Online Learning in ASPL and (3) learning. In addition, each phase includes several modes. The instrumentation phase is initiated when an instrumentation monitor senses that the context-aware process is activated. Based on the learning model, instrumentation execute preempts the context-aware composition and shifts control to online learning. The learning process analyzes the current context and decides which alternative variant to invoke and how to monitor its behavior with respect to the given quality goals. In addition, it installs a trap that will shift execution back to the context-aware composition process at the end of the learning activity. Then the learning process is executed which makes the system entering a monitored execution mode. A monitor component monitors how the variant under evaluation performs with respect to the goals and provides statistics for analysis. After completion, control is returned to the learning process which enters learning analysis. In this stage, the measured properties are compared to the knowledge of the knowledge base. Depending upon the result it may decide to update the knowledge base. This completes the cycle of reflective computations and control is returned to the context-aware composition mechanism. 3. ONLINE KNOWLEDGE SHARING Knowledge provides a basis for decision making throughout a product line s life-cycle, thus it is vital for all product line engineering activities [16]. In traditional SPLs, knowledge evolves at a pace determined by product line evolution activities [28]. New and changed goals, failure reports, and changes in operational conditions are represented as change requests and may originate from a single or multiple stakeholders and products in a product line. Change requests are analyzed, prioritized, and some are realized as modifications to the software product line s assets. Eventually new product instances or product patches are generated and deployed. However, in traditional SPLs, the rate at which changes are incorporated is rather slow. Such product lines lack support for products deployed in more flexible environments where goals and the execution context change more frequently. In such settings, new knowledge may be derived in a product (e.g., using a learning mechanism), but there is no mechanism installed to immediately share new knowledge with other products. Other products in SPL could benefit from this knowledge and take the measures required to improve. To our knowledge, no mechanisms exist to share, update, and reflect knowledge among product line products at run time. We believe that by evolving product line knowledge at run time, products may gradually improve their quality and contribute to the improvements of all product line products. Based on this assumption, we propose two knowledge evolution mechanisms for ASPLs: (1) online learning and (2) online knowledge sharing. ASPL products already have a built-in online learning mechanism that continuously evolves the product s internal knowledge base and, in addition, may trigger internal adaptations. We propose that new knowledge, derived by a product either through online learning or any other mechanism may be shared with other member products through a knowledge sharing mechanism. Online knowledge sharing is a proposed extension to ASPL [1]. As shown in Figure 5, it is a process by which product line products exchange knowledge at run time. The motivation for sharing knowledge at run time is that products may self-optimize and thus improve quality faster capitalizing on knowledge derived by other products, reducing the overall online learning efforts among products in a product family. Extending ASPL with support for knowledge sharing requires that the Autonomic Software Product Line Engineering (ASPLE) is represented as a run-time entity 1. The ASPLE manages and shares knowledge among its products but it may also, in some situations, initiate and control product adaptations. For example, if a product detects a faulty component, causing a failure, and reports this back to the ASPLE, the ASPLE would directly initiate an adaptation of all products that uses the erroneous variant and force them to adapt instantly. We distinguish two types of adaptation that knowledge sharing may trigger: internal and external. With internal adaptation, a product itself triggers and controls its adaptation process using its two AEs, and Online Learning AE. If adaptation is triggered or controlled by the ASPLE run-time entity we call it external adaptation, illustrated by the trigger relationship from the ASPLE to the product. 3.1 Understanding Knowledge Exchange An SPL maintains knowledge about product features, product domain, design artifacts, components and variants, and additional artifacts. This knowledge originates from a large number of activities and artifacts, such as domain and requirements analysis, design artifacts, test results, change requests, defect reports, product performance logs, statistics from quality measures, etc. The variety of activities and artifacts make knowledge a complex entity. Based on an analysis of different types and origins of knowledge, we identified two basic scenarios for knowledge evolution: Product Line Driven Knowledge Evolution (PLDKE) and Product Driven Knowledge Evolution (PDKE). The two scenarios involve several sub-scenarios based on different ori- 1 In general, humans may be included in the automation loop, which is also the case for our current implementation.

5 Product Line Evolution Product Line Evolution (Knowledge) Management ASPLE Context Profiling Variants Off-line Training Knowledge Base Context Profiles Legend Control Flow Information Flow Selected Variant Dispatch Table Local Monitor Knowledge/Feedback Global Adaptation Product Configuration Deployment On-line Learning MAPE Context Aware Composition-MAPE Execute Product Figure 5: Extended ASPL with Online Knowledge Evolution gin of knowledge. For example, in PDKE new knowledge may originate from defect reports, online performance analysis, and from online learning. PLDKE: In PLDKE, the product line drives evolution based on new knowledge (e.g., introduction of a new variant), and pushes knowledge towards member products dynamically. Figure 6(a) illustrates PLDKE. (1) A new variant enters the product line and triggers an evolution process controlled by Product Line Evolution(Knowledge) Management. (2) Information about the new variant and its characteristics is added to the product line s knowledge base. (3) The knowledge about availability and characteristics is forwarded to the member products. Member products initially don t know when to use the new variant because the ASPLE does not provide performance data of the new variant since that is context dependent. (4) Products use their built-in online learning mechanism to learn and derive new knowledge about the new variant, for instance, its performance. This new knowledge may trigger an internal adaptation in a product, which will optimize performance. (5) Products can share new knowledge directly with other products or indirectly via the ASPL using the PDKE scenario described below. (6- a) An alternative to direct knowledge sharing with other products is to report back to product line evolution management. (6-b) The ASPL may share the information derived by product P 1 with product P n and other member products. PDKE: With PDKE, member products derive new knowledge and share it with other products either directly or indirectly through the product line. Figure 6(b) illustrates PDKE. (1) Product P 1 derives new information either using the built-in online learning mechanism, or from some other source activities, such defect reports, test results etc. (2-a) Products can share this new information directly with other products or (2-b) report back to the product line evolution management. Product line evolution management and product both can process this new information to derive new knowledge. (3) Product line evolution management updates its knowledge base to integrate the new knowledge, and (4) shares it with member products. Sharing of new knowledge in both scenarios is further explained below as direct product communication, and indirect product communication. Direct Product Communication: The horizontal double sided arrows in Figure 6 that connect products indicate direct product knowledge sharing. Products share knowledge directly with their associated products. Different communication styles such as push, pull, broadcast etc. can be used for direct inter-product knowledge sharing. We assume that each product accepts to share knowledge and that each product is responsible for how to use shared knowledge. The receiver products process new knowledge which may eventually trigger internal adaptations. Ideally a knowledge manager component need to be implemented to take care of knowledge evolution. Indirect Product Communication: The vertical double sided arrows in Figure 6 that connect the ASPLE and its products represent indirect product knowledge sharing. A product in operation may send a defect report, change request, or knowledge update as a feedback to the product line evolution management. Processing the feedback may generate new knowledge, for example processing of a defect report may reveal new or incorrect product features. The ASPLE may use this knowledge to develop new products with improved quality, or push it towards other products in operation. Another strategy is that products subscribes to and pull new knowledge from the product line s knowledge base as it becomes available. The ASPLE is responsible for receiving, processing, storing knowledge and support different communication styles with the products, for instance push and pull protocols [2]. Another option is that the ASPLE itself initiates external adaptations in its products. In a scenario where a failure is detected in one product the product-line evolution management may decide to recall a feature variant. This is achieved through external adaptations where the ASPLE directly updates the context-aware composition s dispatch tables in the products. 3.2 Example To illustrate PLDKE and to evaluate the online learning mechanism, we performed a simple experiment where we

6 1 Product Line Evolution (Knowledge) Management Knowledge 2 Product Line Evolution (Knowledge) Management Knowledge 3 6-a 2-b 6-b 3 4 Legend Control Flow Information Flow Selected Variant Product Pn 5 4 Product P1 Product Pn 2-a 1 Product P1 (a) Product Line Driven Knowledge Evolution (PLDKE) (b) Product Driven Knowledge Evolution (PDKE) Figure 6: Knowledge Evolution in Software Product Lines introduce a new variant in the Matrix-Multiplication ASPL at run time. For simplicity, the new variant is known to be the best one (with respect to the optimization goal) and is introduced by replacing the earlier known worst variant. The introduction of a new component provides new knowledge (of a new variant) to the running Matrix-Multiplication product. For Matrix-Multiplication, Strassen is currently known to be a best-variant with time complexity O(n 2.81 ). We use this knowledge in the experiment and select Strassen as the new variant because it will give us considerable improvements. When the product line is in operation a Strassen variant is introduced as a core asset by replacing a low performing variant, Inline. As described earlier in Section 2, ASPL product lines use a knowledge base to derive products variants best suited for a given context. However initially when a new best known variant is introduced the knowledge base has information about its existence, but not about its performance. Hence it does not know when to use the new variant. This is because the knowledge base is established offline (context-profiling) at a time when the new variant was a known-unknown. Introducing the Strassen variant invalidates the product s knowledge base. The knowledge is no longer optimal with respect to its optimization goal, which results in non-optimal design decisions in the context-aware composition mechanism. The online learning mechanism will now step up and evaluate the new variant for this product. The online learning will eventually invoke and evaluate the Strassen variant. Step by step it will derive knowledge about the variant s performance characteristics and eventually will trigger an internal adaptation that self-optimizes the product by introducing Strassen as the best fit. However the new knowledge in this case will be local. This example illustrates how new knowledge (a new variant) shared among products by the ASPLE, is processed locally by the products learning mechanisms that determine how to capitalize on this new knowledge locally. We have not yet evaluated the options we have discussed for online knowledge sharing. 4. RELATED WORK The research presented in this paper is based on the principles of Autonomic Software Product Lines [1]. An ASPL is a particular type of Dynamic Software Product Line (DSPL) [14, 19]. Hallsteinsen et al. [14] identify dynamic variability, (re-)configuration, self-management, and adaptation as required properties for DSPLs. Additionally they specify context-awareness, autonomic or self-adaptation, and automatic decision making as optional properties of DSPL. ASPLs support all these properties using principles of reflection and autonomic control loops. The online learning mechanism is an example of an automatic decision making mechanism that makes decisions about modifications to another decision mechanism, context-aware composition. To our knowledge no examples of knowledge sharing, at run time, among DSPL products exists. Several feature-based approaches to develop dynamically reconfigurable products exist [11, 19, 30]. Lee and Kang [19] suggest a feature-oriented approach where a product line is analyzed in terms of its features and their binding time. The 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 re-configurator manages reconfiguration activities including when to reconfigure, what to reconfigure, and how to reconfigure. One major issue with the approach is that it does not specify any mechanism to deal with unexpected changes in system context and requirements, or to incorporate new features in a product line. In ASPL the online learning and the proposed knowledge sharing provide for this. Cetina et al. [6] discuss and analyze popular DSPL architectures, and propose mixed DSPL. Mixed DSPL is an intermediate alternative between connected and disconnected DSPL. Connected DSPL is one that is in-charge of product adaptation, while in Disconnected DSPL, a product itself controls its adaptation. Mixed DSPLs produce scenario-aware configurable products that depending on the scenario may

7 switch from Connected to Disconnected DSPL and vice versa. Connected and Disconnected DSPLs relate to our internal and external adaptations, and to some extent to knowledge sharing. However the shared knowledge is restricted to instructions and no decentralized knowledge derivation and management exists. Hamza et al. [15] have recently proposed the Knowledge- Oriented Product Line Engineering (KOPLE) approach that aims to draw benefits from research in the field of Knowledge Engineering. The authors argue that several practical challenges and problems in SPLE can be effectively resolved if analyzed from knowledge perspective. The KOPLE approach is yet in its initial stages. However we believe it is a promising approach that will contribute to our effort on knowledge derivation and sharing in DSPL settings. Lutz et al. [20] propose to use defect reports to build requirements knowledge in product lines. The authors state that using defect reports from previous product-line members can improve quality of future product-line members by reducing their requirements related defects. The authors use the extended feature model to capture relevant productline requirements knowledge. The new knowledge is then propagated as structured anecdotes of paradigmatic defect across the product line. This work is much in line with ours. However, it is not clear at this moment how we may map these offline activities to run-time activities. 5. CONCLUSIONS AND FUTURE WORK Online knowledge sharing in a product line seems to be a promising approach to continuously and timely improve the quality of product-line products. We have described online learning and introduced knowledge sharing mechanisms for knowledge evolution. However these mechanisms are both in their early stages and require additional analysis, development, and evaluation work. In this work we describe how the online learning mechanism may derive new local knowledge about a new variant in a small product line with restricted scope. The new variant is the global knowledge provided by the ASPLE. We plan to develop the online learning mechanisms further, investigating alternative learning strategies and machine learning techniques. In addition, we plan to validate and verify our approach with context-profiling, context-aware composition, and online learning mechanisms for product lines with larger scope in terms of features, variants, context attributes and optimization goals. The approach has been evaluated for alternative behavior (algorithms), alternative architectures (data-representation), and alternative deployment architectures (exploiting parallelism in hardware architecture). However we still need to extend the support in ASPL with monitors and analysis features for additional variant attributes and combinations. Planning must be further elaborated for instance to assure timely invocation of training, and execution requires alternative dynamic binding mechanism. To support knowledge sharing in product lines we proposed an extension to the ASPL with two types of knowledge sharing direct product communication and indirect product communication. Product line management in concert with the products may use these mechanisms to share new information. Furthermore, we plan for different knowledge sharing protocols, for instance, publish-subscribe. Knowledge originates at different places. For an ASPL and its products we identified two basic knowledge evolution scenarios: Product Line Driven Knowledge Evolution and Product Driven Knowledge Evolution. The product line drives evolution in PLDKE. As new knowledge is derived, e.g., a new variant is introduced and context profiled by the ASPLE. The ASPLE pushes knowledge to products that, for instance, have subscribed or that the ASPLE knows will benefit from the knowledge. PDKE represents the opposite where products derive new knowledge and share it with other products directly or indirectly via the product line. Each of the two scenarios may involve several sub-scenarios, specialized by different sources and knowledge types. For example, in PDKE new knowledge may originate either from online performance analysis that recognizes a violation of a service level agreement, or as a result of online learning. We believe that investigation and evaluation of these basic scenarios will reveal new aspects, challenges and problems. The knowledge sharing mechanism will be scoped and implemented based on the findings of this analysis. The simple implementations made so far was used in the example to illustrate that this is a viable approach for continuous online evolution and quality optimization for autonomic software product lines. In our future work, we plan to study the implications of scaling up the approach to more complex SPLs. As more complex settings will introduce multiple concerns, it will require a more thorough study of evaluation of the approach. As always with self-adaptive behavior, there are additional concerns that must be addressed. For instance, a better understanding of the limitations with the approach. Examples of limitations include the types and frequency of adaptation. If the learning time is greater than the time between changes in the context or to the goals, we have to trade-off, for instance, optimality with performance. Other issues are assurances, stability, and trust. We believe that our approach where evolution and adaptation is controlled and managed by the ASPLE and verified at run time provides a solid basis for both stability and run time assurances. Still, decentralized control of adaptations and online learning will impact, for instance, stability. However, this is something we believe is controllable and we plan to study this in our future work. The third issue, trust, is of a different kind since it is more an organizational issue than a technical. For a product-line used within an organization sharing information typically causes no problem. However if products from the same product-line are installed at different organizations, possibly two or more market competitors, the situation is different. Here it is unlikely that the organizations are willing to share all information. This is also something that we plan to study and address in future work. A stakeholder analysis and a study of different business models for knowledge sharing will form the basis for a configurable knowledge sharing framework, consisting of features that will support different stakeholders interests and sharing models. Product associations are currently controlled by the ASPL engineers and are fixed at deployment. In our future work, we plan to extend this with dynamic, adaptive associations. 6. REFERENCES [1] N. Abbas, J. Andersson, and W. Löwe. Autonomic software product lines (ASPL). In Proceedings of the 4th European Conference on Software Architecture: Companion Volume, pages ACM, (2010).

8 [2] J. Andersson. A deployment system for pervasive computing. In Proceedings of the International Conference on Software Maintenance, ICSM 00, pages , Washington, DC, USA, IEEE Computer Society. [3] J. Andersson and J. Bosch. Development and use of dynamic product-line architectures. Software, IEE Proceedings, 152(1):15 28, (2005). [4] J. Andersson, R. De Lemos, S. Malek, and D. Weyns. Modeling dimensions of self-adaptive software systems. Software Engineering for Self-Adaptive Systems, pages 27 47, (2009). [5] J. Andersson, M. Ericsson, and W. Löwe. Automatic rule derivation for adaptive architectures. In Proceedings of the 7th Working IEEE/IFIP Conference on Software Architecture, WICSA 08, pages , Washington, DC, USA, (2008). IEEE Computer Society. [6] C. Cetina, J. Fons, and V. Pelechano. Applying software product lines to build autonomic pervasive systems. In Proceedings of the 12th Int. Software Product Line Conference, pages IEEE, (2008). [7] C. Cetina, V. Pelechano, P. Trinidad, and A. Cortes. An architectural discussion on DSPL. In Proceedings of the 12th International Software Product Line Conference (SPLC 08), pages 59 68, (2008). [8] B. Cheng, R. de Lemos, H. Giese, et al. Software engineering for self-adaptive systems: A research roadmap. Software Engineering for Self-Adaptive Systems, pages 1 26, (2009). [9] R. Davis, H. Shrobe, and P. Szolovits. What is a knowledge representation? AI magazine, 14(1):17, (1993). [10] T. Dinkelaker, R. Mitschke, K. Fetzer, and M. Mezini. A dynamic software product line approach using aspect models at runtime. In Proceedings of the 9th IEEE International Conference on Computer and Information Technology, pages CEUR-WS.org, (2010). [11] P. Fernandes, C. Werner, and L. Murta. Feature modeling for context-aware software product lines. In Proceedings of the 20th Int. Conf. on Software Engineering & Knowledge Engineering, San Francisco, CA, USA, (2008). [12] M. Fuad and M. Oudshoorn. System architecture of an autonomic element. In Proceedings of the 4th IEEE International Workshop on Engineering of Autonomic and Autonomous Systems, (EASe 07), pages IEEE Computer Society, (2007). [13] H. Gomaa. Designing software product lines with UML: from use cases to pattern-based software architectures. Addison Wesley Longman Publishing Co., Inc. Redwood City, CA, USA, (2004). [14] S. Hallsteinsen, M. Hinchey, S. Park, and K. Schmid. Dynamic software product lines. IEEE Computer, 41(4):93 95, (2008). [15] H. Hamza, J. Martinez, and J. Mugartza. KOPLE: Knowledge-oriented product line engineering. In Proceedings of the ACM Int. Conf. on Object Oriented Programming Systems Languages and Applications Companion, pages ACM, (2010). [16] H. S. Hamza and G. M. Aly. Using product line architectures to leverage systematic reuse of business knowledge: an industrial experience. In Proceedings of the 2010 Workshop on Knowledge-Oriented Product Line Engineering, KOPLE 10, pages 5:1 5:5, New York, NY, USA, (2010). ACM. [17] P. Horn. Autonomic Computing: IBM s Perspective on the State of Information Technology. Computing Systems, 15, (2001). [18] J. Kephart and D. Chess. The vision of autonomic computing. Computer, 36(1):41 50, (2003). [19] J. Lee and D. Muthig. Feature-oriented variability management in product line engineering. Communications of the ACM, 49(12):55 59, (2006). [20] R. Lutz and N. Rouquette. Using defect reports to build requirements knowledge in product lines. In Proceedings of the 2nd Int. Workshop on Managing Requirements Knowledge (MARK), pages 12 21, sept. (2009). [21] P. Maes. Concepts and experiments in computational reflection. In Conference proceedings on Object-oriented programming systems, languages and applications, pages ACM, [22] H. Muccini and A. Van Der Hoek. Towards Testing Product Line Architectures. Electronic Notes in Theoretical Computer Science, 82(6):99 109, (2003). [23] L. Northrop, P. Clements, and Others. A framework for software product line practice, version 5.0, (2007). [24] P. Oreizy, M. Gorlick, R. Taylor, and Others. An architecture-based approach to self-adaptive software. Intelligent Systems and their Applications, 14(3):54 62, (1999). [25] K. Pohl, G. Böckle, and F. Van Der Linden. Software product line engineering: foundations, principles, and techniques. Springer-Verlag New York, Inc., (2005). [26] M. Salehie and L. Tahvildari. Self-adaptive software: Landscape and research challenges. ACM Transactions on Autonomous and Adaptive Systems, 4(2):14, [27] J. F. Sowa. Knowledge representation: logical, philosophical and computational foundations. Brooks/Cole Publishing Co., Pacific Grove, CA, USA, (2000). [28] M. Svahnberg and J. Bosch. Evolution in software product lines: Two cases. Journal of Software Maintenance, 11: , November (1999). [29] C. Szyperski. Component Software: Beyond Object-Oriented Programming. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2nd edition, (2002). [30] P. Trinidad, A. Cortés, J. Pena, and D. Benavides. Mapping feature models onto component models to build dynamic software product lines. In Proceedings of the 1st Workshop on Dynamic Software Product Line, (DSPL 07), pages 51 56, (2007). [31] F. Van Der Linden, K. Schmid, and E. Rommes. Software product lines in action: the best industrial practice in product line engineering. Springer-Verlag, New York Inc, (2007). [32] D. Weyns, S. Malek, and J. Andersson. FORMS: A formal reference model for self-adaptation. In Proceeding of the 7th international conference on Autonomic computing (ICAC 10), pages , New York, NY, USA, (2010). ACM.