The context-aware feature design activity is divided into four main activities, focused on the design of the features for context-aware systems introduced in Section 2.4.2: Information display, service execution, service personalisation, and the tagging of con- text to information.
6.3.1 Information display design
For the information display design sub-activity, the context-aware features that con- sist of displaying information are designed. When designing the information that is going to be displayed with respect to a context-aware feature, the definition of context provided in Section 2.4.5 is critical, as it helps to distinguish between context and other information of the system. This definition considers context only as the information which is used to characterise a situation of interest. Therefore, although the informa- tion which is displayed in a context-aware feature can be reused, or even derive from a sensor, it does not necessarily have to be related to context-information. For facilitat- ing the design of these types of services, a novel Diagram for Information handling is proposed, as it is illustrated in Figure 6.2.
The message stereotyped entities are the central unit in the Information Display Diagrams. Messages are formed of a string, and can additionally have information which is gathered from a sensor, but is not considered context (SensorInformation), or information from a context state (ContextState). The msg attribute in the message ste- reotype can reference SensorInformation or ContextState stereotyped elements. The message stereotype is intended for a stakeholder or a stakeholder profile, that will re-
0..* 1..* 1..* 1..* 0..* 0..* 0..* 0..* 0..* 0..* 1..* 1..* «stereotype» Message msg: String «stereotype» MessageInterface «stereotype» AndroidMessageInterface «stereotype» JavaMessageInterface «stereotype» OptionList «stereotype» ListItem list: ListItem «stereotype» SensorInformation id: String description: String value: ValueType «stereotype» Stakeholder id: String description : String type: StakeholderType power: PowerType support : SupportType «stereotype» ContextAwareFeature type: FeatureType interaction: InteractionType cost: CostLevel rec: RecommendationType «stereotype» ContextState id: String description: String isIndependent: boolean initialValue: boolean receives displays trace
Figure 6.2: Metamodel for the Information Display Diagram.
ceive that message. Messages can be in the form of an option list, displaying the list of possible context-aware features to be triggered. Finally, messages are also displayed in a certain label or text-based widget within a user interface, which can be Android or Java based. For this, traditional Java syntax for Strings can be used.
The purpose at this stage is to create the messages that will be displayed to the end-user stakeholders. Each existing user profile might prompt a different message or service in the same situation of interest. For this, the Information Display Diagram helps developers to design how the different messages and services will be presented to end-user stakeholders. For instance, let us review the example introduced in Figure 5.6, Section 5.4.2, and particularly let us design the Communicate that the bus will not arrive context-aware feature. For spatial reasons, let the display of the context-aware feature be constrained to a user profile of Primary Users, particularly to independent British primary users. The different characteristics for user profiles introduced for this example can be found in Figure 4.8. Figure 6.3 represents the main message that the independent British Primary User will receive. Note that the attribute msg of the mes- sage stereotype is not represented in this figure. Let this msg attribute be: The next bus you are waiting for is not going to arrive. The current weather is “+badWeather+”, per- haps is better to order a taxi and wait for it somewhere else. Choose one of the following
options: . Note that “+badWeather+” references the context state that will represent the current value at that time. In the same way, SensorInformation or ContextPrefer- ence stereotyped elements can also be referenced in the same way. Similarly, the option list to be displayed for this message is also represented, and traced to the corresponding context-aware features. Finally, the message is associated to the Android AlertDialog2, as this is the way in which this message will be represented.
<<message>>
Inform that there are no more buses comming and
that there is bad weather
<<messageInterface>> <<androidMessageInterface>> AlertDialog <<optionList>> No more buses comming for independent british primary user <<listItem>> Call secondary users <<listItem>> Share your location with the
secondary user <<listItem>> Wait in a more comfortable place <<listItem>> Order a taxi <<contextAttribute>> weather <<userProfile>> Independent British Primary User <<userProfileFeature Instance>> Independent <<userProfileFeature Instance>> British <<requirement>> <<contextAwareFeature>>
Communicate that the bus will not arrive
<<requirement>> <<contextAwareFeature>>
Call secondary user
<<requirement>> <<contextAwareFeature>>
Request primary user location <<requirement>> <<contextAwareFeature>> Suggest alternative places <<requirement>> <<contextAwareFeature>> Order a taxi <<displays>> <<receives>> <<Trace>> <<Trace>> <<Trace>> <<Trace>> <<Trace>>
Figure 6.3: Example of an Information Display Diagram for representing how messages are displayed for the context-aware feature introduced in Figure 5.6, Section 5.4.2.
6.3.2 Service execution, personalisation and tagging context to
information design
The sub-activity for service execution design is more centred on the design of services that are going to be triggered at execution time. As further explained in Section 2.4.2, services can be executed in a passive or active modality. The design of the active ex- ecution can be done using traditional UML Class, Sequence/Communication, State Machine/Activity diagrams. The design of the passive execution can also benefit from the Information Display Diagram, as it facilitates the way in which prompts or lists can be presented to the users.
For the service configuration and personalisation design sub-activity, there is a need to identify the different variables required for configuring or personalising the services. It does not really matter for which configuration modality (active or passive) these vari- ables are intended for, as they are expected to change dynamically with the changing preferences or needs that end-user stakeholders may have after interacting with the sys- tem.
However, it is important to distinguish two types of service configuration, as this can help to distinguish what is context from what is not. The first type represents the configuration of those context-attributes that can be used for triggering services. For example, in a scenario where there is a threshold temperature for turning on the heating, one user can set it to 17◦C and another user might prefer it to be triggered when having an ambient temperature of 14◦C. Note that this type of service config- uration design includes both the active and passive modalities introduced in Section 2.4.1. The remaining type of service configuration design consists of triggering the same service in different ways, according to the configuration values. Note that since these configuration variables are not used for identifying a situation of interest, but to configure the way in which the service is provided, the variables identified for the ser- vice adaptation can not be not considered as context. As it happens with the previous service configuration design type, this type can also be designed for active or passive modalities.
Once the variables are identified, the design has to be centred around the ways in which the information is going to be retrieved from the stakeholders, or is going to
be modified by intelligent agents. For cases in which the stakeholders have to input this information, this sub-activity provides a means for designing user interfaces that can be personalised to display information according to the different needs and prefer- ences of the users. For the design purposes of this sub-activity, traditional UML Class, Sequence/Communication, State Machine/Activity Diagrams can be used.
Finally, for tagging the context to information, the Information Display Diagram can be used, as well as traditional UML Class, Sequence/Communication, State Ma- chine/Activity diagrams.