The software should be able to adapt, during its execution, without requiring any (or as little as possible) explicit user intervention, to new and sometimes even unexpected situations, and to the appearance, disappearance or modification of features discovered in available feature clouds. Composition and adaptation of appearing and disappearing features in the feature cloud should react to context changes autonomously. Autonomous behaviour adaptation to the context and to new entities can be managed at the programming level using COP and service adaptivity [ 13, 11 ]. Such ideas could also be explored to manage the adaptation of user interface and database objects.

Software systems should be aware of their current execution context and surrounding environment (including the user) in order to exhibit the most appropriate behaviour according to the situation at hand.

More strongly, software systems should have an explicit representation of the current context of use [ 21 ], to reason about it, and dynamically adapt their behaviour appropriately to the current context.

The software should not only carry the notion of context at its heart, but should also have an explicit representation of its users, so as to be able to best adapt to users’ preferences, desires, and habits. In particular, user information could be regarded as a subset of the “context of use” to which the software should adapt. This appears as an independent characteristic, given that it is crucial for users to perceive a deep level of customization to their preferences, for them to adopt and feel in control of the technology.

The technology used to achieve such dynamic adaptation to context should provide su cient guarantees that the software keeps on exhibiting predictable behaviour according to the initial expectancies of the system, even when unforeseen changes occur. Di↵ erent approaches to assure the consistency of behaviour adaptations have been proposed. The majority of these approaches present a formal run-time model that manages newly introduced behaviour, verifying/validating that such behavior complies with the formal model [ 15, 12, 23, 34 ].

Related to the previous characteristic, the software should be su ciently robust and resilient to unexpected changes, so that it keeps on functioning, though perhaps with reduced functionality (i.e., applying self-healing techniques [ 36 ], for example by resorting to some default behaviour), as opposed to crashing or aborting with an error.

A software system that is continuously undergoing changes at run time may quickly become overwhelming to end users, who may get the feeling they are no longer in control of the system. To avoid user discomfort due to the ever-changing behaviour of the system it is desirable to provide users with enough feedback about the decisions taken by the system, so that they regain control over the system.

Adaptation should be automated, in the sense that it should not require explicit user intervention (or only a very minimum). Interactions with the user should be informative or to request preference settings in the light of new adaptations.

Adaptations to the system should be non-intrusive, not hindering users in the tasks they are currently executing, even for those cases where the software needs to inform the user about important changes.

The software technology should be scalable in terms of number of contexts, features, users, or collaborating devices that can be handled. Well-designed modularisation, composition, scoping and verification mechanisms need to be foreseen to achieve such scalability.

The technology should not be too complex and should be designed carefully, and with the necessary tool and development support, so that developers and users feel “at home” with the technology and “at ease” to build or compose such systems.

Related to the properties of resilience and predictability, and given the high evolutivity of contextoriented systems, there is a strong need for formalisms and techniques to verify relevant properties of the system, whether it be during analysis and design time, or at run time. If at run time, again, the verification and its e↵ ects should be as non-intrusive as possible.

All characteristics above should be integrated at di↵ erent technological and process levels in a unified way. At the technological level, the behavioural, user interface, and database aspects of context-awareness in the system should be reconciled. This, by realising the concepts of context awareness at each level with a unified API, so that the integration of all three levels is smooth; as opposed to current solutions were no such integration exists. Similarly, at the process level, requirements, design models and source code should be unified, to ease the integration of the di↵ erent domains, while still focusing on each of their individual concerns. For example, the use of extended variability models with notions of context awareness could be an entry point for unifying context awareness and adaptation concepts present in all three perspectives, to build next generation software systems. (1) In software development, variability models can be mapped to specific programming language constructs defining and managing behaviour adaptations [ 17 ]. (2) In information systems, variability models can be used to introduce data adaptations, without changing the data definition models [ 1 ]. (3) In HCI, such models could be used to define the di↵ erent adaptation possibilities of user interfaces [ 9 ].

Finally, and maybe even most importantly, to achieve the vision presented in this paper, the software should be user-tailorable at run time, allowing users to select and deselect which software features they would like to include or exclude in their software system, even while the system is running.

Note that the characteristics described above for our vision of feature clouds touch upon similar characteristics targeted by other kinds of systems that manage and o↵ er software services aware of their context. A typical example of such systems is that of service mashups. Mashups are introduced to integrate data from multiple sources and provide extended services from said data sources’ combination. Mashups proved useful as visualisation services, by combining geo-location information with some other service’s data. For example, a common visualisation mashup is to display posts for a social media outlet in a map. This can be used to measure tra c and use trends for a particular area during a particular period of time. Furthermore, mashups can use sensor data to specialize provided services to the current situation in the surrounding environment [ 6 ]. Mashup definitions are sequential, following a defined structure in which data can be combined. While the idea behind mashups is to o↵ er services where the user is the main concern, mashups’ sequential definition makes them di cult to control by end users. This is due to the rigidity of such definitions, where to reject an adaptation, users would need to reject the full mashup. Even more, mashups are proposed as tools for developers, managing mashups may be too complex for end users. Dynamic mashup solutions are explored to tackle the rigidity problem. Dynamic mashup definitions [ 41 ] introduce service types as a means to group services providing similar functionality and abstract the interaction with concrete mashup services. This model also permits the dynamic selection of mashups according to the surrounding environment. Unfortunately, the definition of mashups remains largely targeted to developers and technical users; regular end users would struggle to control the mashups faced with the complexity of their programming language encoding. Moreover, such definition takes place at development time for all possible execution environments. Users do not have the possibility to tailor their system for particular environments accepting di↵ erent sets of adaptations in each one.

Recent approaches propose the idea of service composition using an autonomous process where fine-grained service composition is learnt from their interaction in a particular environment [ 11 ]. This proposal follows feature clouds’ ideas of composing fine-grained behaviour definitions from a cloud of features. Nonetheless, the proposal is fully automated, leaving end users out of the loop, which may compromise the approach’s acceptance. 4

( () characteristics marked as (() It is not easy to strike a right balance in achieving all characteristics presented in Section 3 within a single unified approach, since many of them have competing goals. Di↵ erent fields may prefer di↵ erent solutions or trade-o↵ s towards achieving these characteristics. Reconciling all these competing views and solutions requires a truly multi-disciplinary approach within and across fields. We now present an overview of competing characteristics in the development of user-centric context-aware systems, which is summarised in Table 1. Characteristics marked as ) represent that a middle ground must be found between the two characteristics, whereas ) represent a conflicting objective between the characteristics, and only one of them can be attained successfully. Each of the trade-o↵ s is evaluated with respect to one of the perspectives to develop adaptive systems.

Dynamic adaptation Dynamic adaptation Dynamic adaptation Context awareness Verifiability Automation Integration

Whereas scalability in terms of the number of contexts, users, or devices to be handled may remain manageable (since these are often restricted by the scope of the application), the vision of having online feature clouds containing a myriad of fine-grained features may pose a major scalability issue. The problem of combining features selected from a feature cloud is acute, since features are not necessarily di↵ erent, some features may provide behaviour similar to others, while the di↵ erentiation between them is key to the system’s quality of service. Moreover, each feature is applicable to certain contexts. Problems such as: (1) how to assure all (and only) relevant features are discovered by users, (2) how to develop features that manage dependencies with unforeseen features, and (3) how to handle incompatibilities between features, become even more problematic with the system’s envisioned granularity and scale.

Having an automated feature composition mechanism also poses a major challenge (apart from the scalability challenge presented above). Indeed, not only features that were designed to work together can be combined, but the composition with all features in the cloud could be possible. To some extent, the composition mechanism will do its best to combine any features users find relevant to combine, even when this was not anticipated. This could occur often given the potential size and dynamicity of feature clouds, which makes it impossible to foresee all possible combinations, as some features will only appear in the environment long after the deployment of others.

Given the competing goals of high dynamicity, adaptability, and context-awareness on the one hand, versus guaranteeing predictability, resilience and robustness on the other, it may not always be possible to compose the desired combination of features. In such cases, the composition mechanism needs to resort to a best-e↵ ort approach to propose a composition that is robust while remaining as close as possible to the user’s desires. Deciding what is the ‘best’ solution is challenging as it may depend on the context and goals of the application as well as on the user’s perception.

Finally, probably the most important challenge to be addressed for the technology to mature, will be to create adaptive systems that users can understand, accept, and ultimately adopt. This touches upon many of the aforementioned characteristics and challenges such as user centricity, predictability, resilience, non-intrusiveness, user feedback, automation, scalability and user-tailorability. Empirical studies as well as test scenarios (e.g., A/B testing) are required to assess whether these systems are desirable or acceptable by users and in what form. 5