## 3 Context Acquisition and Analysis Using FamiWare
Furthermore, reconfiguration services, which perform the necessary tasks to self-adapt the system, have been implemented in FamiWare. Nevertheless, a certain AmI application may require the management of other context information not considered in FamiWare. In order to reuse the context-aware platform provided by FamiWare, it would be desirable that FamiWare allows the incorporation of new contexts. Then, if the application developer is interested in managing new contexts, both these contexts and their corresponding monitoring, must be added to the FamiWare family. However, if the Aml application developer is not familiar with feature models, SPLs, and the specific structure of the FamiWare feature model, then adding new contexts could be a difficult and error-prone task. Therefore, we propose a model-driven process to add new contexts automatically to FamiWare and to configure a particular instantiation of the middleware ready-to-install in all the devices involved in the Aml system. As we use a metamodel language, the developer can model contexts by using a common and standard language like UML instead of the tedious task of modifying directly the FamiWare feature model. To achieve this goal, as aforementioned, we define a mapping between the ContextUML metamodel and all the corresponding elements related to contexts in FamiWare. FamiWare feature model represents all the possible context information and changes. As shown in Figure 4, in this feature model we model the monitoring services that are dynamically observing the context, the context values which could be considered as context changes, and the corresponding plans to adapt the system to new contexts. Then, context elements to perform dynamic adaptation in FamiWare are collected by the monitoring services. For example, for the sensor devices we could have the following: battery, traffic, position, topology, state, movement, and so on. Hence, other monitoring services can also be considered in FamiWare, not only for devices, but also for users or environment, such as: user profile, current time, temperature, _etc_. These monitoring services are represented as optional features in the feature model  
Figure 4: Partial FamiWare feature model of monitoring and context-awareness services. Figure 3: Device interconnection using FamiWare. (see Figure 4). Furthermore, if needed, new monitoring services must be added as new optional features to the family. Then, different configurations in each device of an AmI system include only the required monitoring services for the application to avoid the wasting of unnecessary resources. Context-Awareness service (Figure 4) is responsible for the awareness of the context, using the data provided by the monitoring services, and initiates the reconfiguration process as a consequence of a context change. It is also defined as part of the feature model, since the list of monitored data used for context awareness is also variable. For example, in a specific device configuration of a certain AmI system, it may be useful to consider all its monitoring services observing the context, but in other configurations only the data about the position is considered to perform a reconfiguration. Figure 4 shows that this service is defined by the list of context data (optional) and the plan that must be chosen by this service when a context changes. We define a child feature for each context data, which specifies simple logical expressions that may trigger a context change, as _BatLT5_ (battery level less than 5%). To express that some reconfiguration tasks must be performed when the battery level is less than 5%, we must define a cross-tree constraint in the feature model, as is shown in the Dependencies in Figure 4: _BatLT5 implies Plan11_. This means that when the battery level of a sensor is under 5%, then _Plan11_ must be executed.