## 4 Handling Context in FamiWare
### Mapping ContextUML to FamiWare  
Here, we describe the ContextUML metamodel elements [20] that we use in the mapping with FamiWare. In ContextUML, _Context_ is a class that models the context information. This type is divided into two categories formalized by the subtypes _AtomicContext_ (low-level contexts that do not rely on other contexts, e.g., patient's location, if we consider a patient as user) and _CompositeContext_ (high-level contexts that aggregate multiple contexts, either atomic or composite, e.g., frequency of movement detection in a certain location). The type _ContextSource_ of ContextUML models the resources from which contexts are retrieved. As we advanced previously, we assume AmI systems with diversity of context providers (e.g., sensors, GPS, user preferences, and so on). The ContextUML metamodel provides two context source subtypes: _ContextService_ (provided by an autonomous organization, e.g., a glucose sensor), and _ContextServiceCommunity_ (that aggregates multiple context services in a unified interface, e.g., WhereAmI to refer the user's location). The class _CAMechanism_ formalizes mechanisms for context-awareness. ContextUML differentiates between two categories of context-awareness mechanisms by subtypes: _ContextBinding_ (automatic binding modeling of contexts to context-aware objects) and _ContextTriggering_. _ContextTriggering_ models the situation of context adaptation based on context information. For instance, when a user is in a sudden emergency situation, some services or devices of the AmI system must be reconfigured. A context triggering mechanism contains two parts: a set of context constraints, _ContextConstraint_ (e.g., a sudden and rapid movement of the user followed by a non-detection of movement may imply that the user has fallen), and a set of actions, _Action_ (e.g., search for the nearest sensor with camera, turn on the camera, record a video, and transmit it through the smartphone to the health center). Those actions must be executed if and only if all the context constraints are evaluated to true. Now we specify the mapping between ContextUML and the elements of FamiWare described in Section 3. Table 1 presents both the correspondences from ContextUML elements (for those elements with any correspondence) to the FamiWare feature model, and their implementation in the middleware. The _AtomicContext_ class in the ContextUML metamodel corresponds to the children of the ContextData feature in the FamiWare feature model (Figure 4). FamiWare Context-Awareness service implements this correspondence by subscribing to the corresponding FamiWare Monitoring service specified by the _ContextService_. The _ContextService_ class corresponds to the children of the Monitoring feature and it is implemented by a monitoring service. In FamiWare, which follows a publish/subscribe architecture, each monitoring service publishes a topic with the value of the monitored data and the context-Awareness service subscribed to those that have to be checked to detect possible context changes. At feature model level, as is shown in Figure 5(a), for every atomic context in a model, _i.e._, _AtomicContext_, we have to add a child optional feature of ContextData. Note that the _addFeature (father, child, variability)_ function adds the child feature to the father one (with the assigned variability: optional, mandatory and so on) only when this feature did not previously exist. As is shown in Figure 5(a), we have also to add the corresponding monitoring service as an optional child of the monitoring feature, with the name of the _ContextService_. Finally, a constraint between features must be considered (_addDependency_ function), which means that for every ContextData feature that exits its corresponding Monitoring feature is added to the feature model (e.g., _CMov implies Mov_). This means that if we want that a sensor will be aware of the movement, the monitoring service reading the data provided by a movement sensing unit must be instantiated.