Modeling context-awareness is becoming a primary activity for software engineers that design applications for mobile devices. In fact, software applications running on such devices need to be aware of their context (that may rapidly change) to adapt their services and o®er the best quality (intended as a combination of non-functional properties) in any context. Thus the need of instruments to manage mobility, context-awareness and non-functional characteristics is critical to build software systems in ubiquitous and mobile domain. In this paper we introduce a framework to uniformly model di®erent types of mobility and context-awareness so that the modeling and analysis of non-functional properties of such systems can be supported in an integrated environment. To enable non-functional analysis, we devise the integration of non-functional parameters in the modeling framework. In particular, we present an UML implementation of our framework within the MagicDraw modeling environment, with the support of existing UML pro¯les for modeling context-awareness and non-functional properties. We ¯nally show an example of modeling and analysis of reliability in the eHealth domain.
The evolution of portable devices and their increasing pervasiveness in everyday life have motivated a growing interest for methodologies, techniques and tools that allow to e®ectively develop and analyze software systems running on such devices. The main characteristics of portable devices are mobility and limitation of hardware resources. Both these aspects require speci¯c characteristics of the deployed software systems that must be considered along the whole software lifecycle, starting from the architecture design phase.
Mobility can be either physical or logical. Physical mobility takes into account
the transfers of a portable device among a certain number of physical locations.
Logical mobility is achieved through online re-deployment actions on software
components [
The limitation of hardware resources has brought to develop speci¯c releases of software products. The available amount of such resources can vary at runtime, thus new approaches have been introduced to produce software able to adapt to changes in the available resources (and in the execution environment).
Mobility and limited resources obviously have a large impact on the quality of software systems (intended as a combination of non-functional properties). Their bad e®ects are today passively accepted as unavoidable fees to pay in the domain of advanced portable systems. As opposite, if opportunely managed, they can become powerful instruments in the hands of software developers to maintain an acceptable level of user-perceived quality even in presence of changes and degradations in the surrounding environment.
Goal of this paper is to introduce an unifying framework to model mobility and context-awareness aspects of software systems. The framework is aimed at producing software models that embed, beside these two aspects, the parameters needed to non-functional analysis. Beside the speci¯c characteristics of mobility and context-awareness, in this framework the interdependencies between them can be captured and the cross-e®ects can be considered. Thus certain types of analysis, that were not feasible with speci¯c models, are enabled in our framework 1.
In Figure 1 we represent our idea of context, as the combination of attributes
that can come from di®erent domains. In particular, in this paper we focus on
physical and logical location-awareness and hardware platform awareness. Our
approach [
Non-functional properties of mobile context-aware software systems
obviously also depend on the characteristics of software services provided in each
speci¯c context. Di®erent implementations of the same service may be available,
possibly exploiting code mobility paradigms [
The paper is organized as follows: Section 2 brie°y describes the basic ideas behind our framework, Section 3 presents the UML implementation of the framework driven by an eHealth application example, in Section 4 we show how to conduct a reliability analysis, Section 5 introduces the related work, and ¯nally Section 6 concludes the paper. 2
In our approach, context-awareness is intended as the property of software to manage knowledge related to the context, where the context is de¯ned here as a combination of (physical and logical) location and hardware platform characteristics.
The framework proposes a uniform representation of the location and hardware platform awareness (and the mechanisms that rule them), and allows to (separately or jointly) manage these properties within the same framework. Context-awareness of software systems is expressed through a set of attributes associated to system elements such as software components and hardware platform devices. The evolution of an attribute (or a set of attributes) is modeled by a stochastic statechart whose states model the attribute "value" (e.g., the status of a resource or the logical location for a component) whereas the transitions model the events (such as location change or resource degradation) triggering the attribute changes as well as the probability of the event occurrence. Of course, changes in the context attributes may induce adaptation actions.
On the basis of the modeling approach introduced above, physical location-, logical location- and hardware platform-awareness must be properly combined depending on the type of context-awareness suitable for the modeled application. Each of them can be de¯ned in isolation or, through remote ¯ring, can a®ect the other ones. Even for sake of reliability analysis, these facets can be considered together or in isolation, depending on the facets of interest of the software system. For example, one can investigate only the system reliability °uctuation due to an extreme physical mobility of users without considering at all the state of resources on portable devices.
Therefore the three types of statecharts have to be lumped, when necessary for analysis purposes, in one statechart that models the runtime evolution of a mobile context-aware software system. Each state of such statechart (that we call superstate) represents a possible context, and it is obtained from the combination of three states, one for each statechart (i.e. physical mobility, logical 2 Note that our approach in its current version does not intend to address run-time problems, but it is a support for developing and maintaining such software systems. Runtime usage of this approach introduces additional issues (such as the complexity of analysis models) that we devise as future work. mobility, hardware platform evolution). Obviously not all the combinations are allowed, for example a certain con¯guration of hardware devices cannot allow a certain deployment of software components to devices. Therefore, in order to build a consistent unique model, only superstates that are feasible combinations of states have to be considered.
Once this set of superstates has been de¯ned, a list of provided services and their corresponding behaviors have to be associated to each state. In fact, if multiple behaviors for some service are available, then the behavior to be adopted must be speci¯ed in each superstate where the service can be provided.
In Figure 2 the synthesis of states from the three statecharts into an unique superstate is represented in an UML-like notation. A superstate represents the context as partitioned in four sectors, one for each type of awareness plus (at bottommost of ¯gure) the list of provided services and their behaviors chosen for the speci¯c superstate. Awareness managers (represented as statecharts) are introduced in each sector. Across physical and logical location awareness sectors the Dynamic Deployment Diagram illustrated in Figure 4 is also sketched.
Transitions have to be de¯ned in this unifying statechart. Being each
superstate obtained by lumping three states of their respective statecharts, the
transitions outgoing these latter states have to be opportunely combined (along
with their probabilities) to build up transitions outgoing the superstate. Note
that the problem of lumping di®erent statecharts is very similar to the problem
of combining stochastic behaviors of concurrent processes. The latter has been
faced with di®erent approaches, among which Stochastic Process Algebra seems
to be a promising notation to be applied to our case as well [
More details on the notation-independent framework can be found in [
In this section we present the UML 2.0 implementation of our approach to the modeling of non-functional properties of context-aware software.
The UML modeling is organized in Service, Component and Deployment Views, as shown in Figure 3.
The Service View (SV) models the services provided by the software
system as perceived and used by external actors (Use Case Diagram, UCD) along
with their behavioral speci¯cations (Sequence Diagram, SD). A Physical
Mobility Manager is assigned to the nomadic users that exploit the system services
while moving with their mobile devices [
The Component View (CV) represents the software architecture
(Component Diagram, CD). It is integrated with mobility annotations that allow to
distinguish logically mobile from ¯xed software artifacts [
The Deployment View (DV) models: (i) the current/allowed allocation of software artifacts on execution environments (e.g. handheld devices) that can physically move across di®erent places (Dynamic Deployment Diagram, dynDD), and (ii) several detailed hardware device speci¯cations (hwDD). A Hardware Con¯guration Manager describes a resource whose state (e.g. its current amount) may vary at runtime.
<<GaAnalysisContext>>
System
ServiceView PhysicalMobilityManager SD UCD
ComponentView LogicalMobilityManager CD
DeploymentView HwConfigurationManager DynamicDD DeviceSpecs <<apply>>
<<profile>> UML Profilie for Mobile System <<apply>> <<apply>> ContextM<<oprdofeileli>n>gProfile <<apply>> <<import>> <<profile>> MARTE_Profile <<import>> <<import>> <<profile>>
DAM
These views are illustrated in the following subsections through a set of UML diagrams modeling a eHealth application 3.
The diagrams are suitably annotated with additional information from
several pro¯les to enable model-based reliability analysis [
The applied pro¯les are MARTE [
<<CurrentDeployment>> The reference example is a eHealth system that provides a service called RequestPatientInfoPage: a doctor is able to retrieve mixed media information on his/her patients, such as text with or without di®erent kind of images that refer to their personal data, their medical histories and patient-related diseases through his PDA (MobileElement )
The RequestPatientInfoPages service is supposed to be the most frequently
invoked (basing on the user pro¯le). In our modeling approach, services are
provided by a component-based system whose architectural description is given
by a Component Diagram (CD). The CD identi¯es the software components,
their interconnections and the executable artifacts implementing them.
Moreover, it speci¯es which component is mobile and the component failure
probability needed for the analysis methodology [
In Figure 4 the dynamic DD of the application is shown. It is inspired to the
diagram introduced in [
In Figure 4, the RequestPatientInfoPages service on the user-side is available
if the user PDA is able to connect (DaConnector ) to a WAN network (HwMedia).
Di®erent Places can provide di®erent types of network connections (i.e. typed
Ports of the Places), but not all of them are exploitable by the service (such
as the white-colored port 802.11n:LAN at Doctor's Home) due to particular
design choices and/or hardware limitations. Moreover the available connections
can have di®erent non-functional characteristics that a®ect the properties of the
service provision: in our case, the service reliability is in°uenced by the network
failure probability (i.e. PSI WAN) [
Lastly, Figure 5 shows the hardware components making up the doctor's PDA
[
<<hwDMIeSmKory>> {memorySize = "memorySize", resMult = 1} <<HwI/O>> DISPLAY {resMult = 1}
<<GaEPxDecAHost>> <<hwProcessor>>
CPU
{frequency = "currFrequency" ,
resMult = 1}
<<var>>-currHwConfig : NFP_String [
BATTERY
{capacity = "capacity",
resMult = 1}
<<var>>-capacity : NFP_Energy [
3G Card {connectedTo = WAN, resMult = 1} In this section we model the context-awareness of the eHealth application following our approach. In Section 3.3, we will describe how the *-awareness can in°uence di®erent behavior speci¯cations of the same system service.
Physical Location-Awareness - The modeling of the Physical Location
Awareness takes inspiration from some previous works [
A UML StateMachine is de¯ned where each state represents both the current
physical location (Place) and physical resources in the surroundings (together
referred as physical con¯guration, PhyCon¯g ) at the time when users demand for
services. The transitions are triggered either by physical moves of the nomadic
users or by changes in physical resources in the surroundings. Figure 6 shows
the doctor mobility pattern (i.e. the one of his/her PDA) where the physical
transfer from his/her home to the patient's one is highlighted along with the
probabilities of the moves (GaStep). 5. A PhyCon¯g state de¯nes the actual
ends of the Current- and AllowedNodeLocations relationships among execution
hosts and places on the dynDD (Figure 4, [
Logical Location-Awareness - Logical mobility is informally de¯ned as
the capability to dynamically change the bindings between code fragments and
the location where they are executed [
Hardware Platform Awareness - The third dimension of the contextawareness, as de¯ned in this paper, takes into account the detailed hardware speci¯cation of the execution environment. We specify in Figure 6(b) the Hardware Con¯guration Managers for hardware resources of Figure 5 whose internal con¯guration (HwCon¯g ) can in°uence the service behavior.
Figure 6 illustrates the BATTERY, Display and CPU's managers as
separate statechart that model the states and transitions of corresponding hardware
components (Figure 5). Each state speci¯es a set of nfpConstraints (based on
variables de¯ned on the con¯gured hardware component) [
In addition, a remote ¯ring transition (BATTERY2LowPowerDowngrade) highlights how the remaining BATTERY capacity (currCapacity) in°uences the status of the CPU by ¯ring a remote transition that limits its clock frequency (currFrequency). 3.3
The eHealth modeling is completed by the speci¯cation of *-aware service's behaviors. Figure 7 shows a Interaction Overview Diagram associated to the RequestPatientInfoPages, with two possible behaviors. 5 Note that self-transitions on all states are represented, because they are implicitly activated with the remaining amount of probability to achieve 1 on the sum of outgoing transition probabilities of a state.
In the Standard Behavior the doctor, once logged in, invokes the distributed service, and the server-side components DaComponent are in charge of retrieving data from a local database and, if needed, from a image server for patients' x-rays or disease-related images. Finally the result is displayed on the client (Figure 7). The service behavior can be determined by the current context condition (see Figure 6) de¯ned by the current values of the managers' model variables. Hence, the same service can have multiple implemented behaviors whose activation is driven by the logics expressed within the managers.
Figure 7 shows two alternative behaviors, enabled by conditions that refer to the actual state of several hardware con¯guration managers. In particular the StandardBehavior allows the retrieval of both text and images about the patient only if enough DISK space and BATTERY power are available (reading the current value of the currHwConfig vars), otherwise the ResourceConstrained behavior will be executed that excludes the interaction with the image server (the "white" lifeline and related messages in Figure 7) 6. 3.4
For the sake of the reliability analysis made in Section 4 we lump some of the awareness managers introduced in Section 3.2 to obtain the unifying (UML) statechart. In particular, we have considered the doctor's Physical Mobility Manager and the PDA Display Hardware Con¯guration Manager (both in Figure 6(b)). This choice allows, on one end to keep the example as simple as possible, and on the other end to keep into account two di®erent types of awareness, as we will show in Section 4. The lumping process brings to an unifying statechart with eight feasible potential superstates, i.e. the cartesian product of the manager state spaces. 6 For sake of illustration, in Section 4 we simplify the conditions for the activation of
ResourceConstrained behavior by basing only on the display characteristics.
In this section we show an example of reliability analysis, as a proof of concept that our approach not only allows to introduce all information necessary to model non-functional attributes, but it also enables non-functional analysis that supports critical decisions in a context-aware domain.
The target of our analysis here is a model introduced in [
As illustrated in Section 2, we assume that the set of services available to users can be di®erent across the superstates due to changes in the resource characteristics. Moreover, di®erent implementations of the same services can be provided in di®erent superstates in order to adapt the service behavior to di®erent hardware con¯gurations. In order to denote superstate-speci¯c services (and components implementing them), as well as other system parameters, we introduce the following notation: xj¾. It denotes the interpretation of term x in the ¾ superstate.
Let Sk be one of the system services (e.g. RequestPatientInfoPages of Section 3); let Skj¾ be the implementation of Sk provided in the ¾ superstate; and ¯nally let Cij¾ (i = 1; : : : ; N ) be the set of components implementing Skj¾.
Let µij¾ be the probability of failure of Cij¾, and let bpij¾ be the number of activations of Cij¾ within the dynamics of Skj¾.
Let Ã<i;j>j¾ be the probability of failure of the connector between Cij¾ and Cj j¾, and let int<i;j>j¾ be the number of interactions between these two components within the dynamics of Skj¾.
Hence, we have reformulated the model in [
N R(Skj¾) = Y(1 ¡ µij¾)bpij¾ ¢ i=1
Y (1 ¡ Ã<i;j>j¾)int<i;j>j¾ <i;j> (1)
In a certain superstate, the reliability of a service is given by the probability that all components and connectors implementing it do not fail all the times they are used (i.e. numbers of activations over components and interactions over connectors).
The µij¾'s can be extracted from an annotated Component Diagram modeling the software architecture of the application, Ã<i;j>'s from a Deployment Diagram like the one in Figure 4, and structural parameters bpij¾ and int<i;j> from a Sequence Diagram like the one in Figure 7.
Following the process illustrated in Section 2, the managers introduced for this example in Section 3 can be lumped in a unique statechart that represents the context management of the eHealth application. For sake of space we do not show this process here, but we compute the reliability of RequestPatientInfoPages service (RPIP-service) in two di®erent contexts, that are: OpenAir/ColorDisplay (CD) and OpenAir/BWDisplay (BWD). We assume that in the former context the Standard Behavior of the Application Server is adopted, whereas the Resource Constrained Behavior is adopted in the latter case, thus we can show the e®ect of changing context on the service reliability.
In Table 1 the values adopted for the reliability model parameters have been summarized, where the parameters referring to the components are placed in the top rows and the ones referring to the connectors in the bottom rows. Note that all values are invariant with respect to the context ¾, with the exception of the number of activations and interactions of the Application Server. This is due to the di®erent behaviors that this component adopts in the considered contexts.
By applying the equation (1) the following values for the service reliability are obtained: R(RP IP ¡ servicejCD) = 0:9386 and R(RP IP ¡ servicejBW D) = 0:9557. The service reliability is higher in the context where a back-and-white display is used basically due to the adapted behavior of the Application Server that does not interact with the Image Server to collect the patient's images. This behavior allows to avoid additional activations and interactions that in the best case do not increase the service reliability, and in all other cases (due to non-zero failure probabilities of components and connectors) worsen it, as shown in this simple numerical example.
This example results would be even di®erent if superstates with di®erent physical locations of a mobile device are considered, as in that case the failure probabilities of connectors may also change. Yet many other scenarios can be studied by simply comparing the service reliability in di®erent contexts (e.g. the failure probability of components may change if di®erent versions of the same service are implemented with di®erent types of components).
Beyond the numerical analysis shown in this section, our approach opens multiple possibilities for the system analysis. The construction of a single statechart for context management allows to make analysis across di®erent contexts. For example, by solving the lumped statechart as a Markov Chain, the steady state probabilities can be obtained that represent the probability to sojourn in each state. The average reliability of a certain service across contexts can be simply obtained by summing the service reliability in each superstate weighted by the steady state probability. 5
Several approaches have been introduced in the last few years to manage
mobility and adaptation at the middleware level. Among these, very relevant work has
been done within the framework of the MUSIC project [
All the MUSIC contributions can be used at run time given that the
application has been developed to be context-aware and QoS validated. As assessed in
[
As opposite to MUSIC project and other middleware contributions (e.g.
ReMMoC [
Another interesting project is DiVA [
Grassi et al. in [
Our work improves the approach in [
Finally, our idea of managing all context- and mobility-related aspects with
statecharts is very close to the concept of modes. Modes has been proposed in [
We have introduced an unifying approach to the modeling of location- and hardware platform-awareness aimed at analyzing non-functional properties of software systems. As a proof of concept, we have provided an example of reliability analysis.
One of the peculiar properties of our approach to the context and mobility modeling is its modularity. We allow to separately model with statecharts any characteristic (single or multiple attributes) that may change and a®ect nonfunctional properties. Such separate models can be used in isolation or variously combined to study the behavior of such system under di®erent types of changes.
Besides, with previous modeling approaches cross-dependencies among attributes were hard to capture because they were represented with di®erent models or not represented at all. With our unifying approach all attributes are integrated within the same model, dependencies are explicitly modeled, and basic adaptation actions that derive by context changes can be managed with the same instruments.
This work has been conceived to be extendable, and two main directions we see at the moment for extending it. On one side, the concept of context can be extended by embedding other attributes that can a®ect non-functional properties. As long as this evolution can be represented through a state machine, the mechanisms presented here can be applied to integrate these additional concepts to the context evolution. We are also working to increase the complexity of statechart remote ¯ring mechanisms without increasing the complexity of the lumping step through the support of process algebras-based techniques. On the other side, these types of analysis can be carried out for other non-functional properties, such as performance, and further tradeo® analysis between di®erent attributes can be devised.
As future work we plan to make explicit the adaptation actions (beside the
simple replacement of a service behavior) in order to take into account their
non-functional properties. Also, we are studying the possibility to adopt this
approach at runtime as a support, for example, of self-adaptive systems. Finally,
the idea of using a Markov Reward Model [