=Paper=
{{Paper
|id=Vol-553/paper-4
|storemode=property
|title=A Unified Approach to Model Non-Functional Properties of Mobile Context-Aware Software
|pdfUrl=https://ceur-ws.org/Vol-553/paper4.pdf
|volume=Vol-553
|dblpUrl=https://dblp.org/rec/conf/models/BerardinelliCM09
}}
==A Unified Approach to Model Non-Functional Properties of Mobile Context-Aware Software==
https://ceur-ws.org/Vol-553/paper4.pdf
A Unified Approach to Model Non-Functional
Properties of Mobile Context-Aware Software ?
Luca Berardinelli, Vittorio Cortellessa, and Antinisca Di Marco
Dipartimento di Informatica
Università dell’Aquila
Via Vetoio, 67010 Coppito (AQ), Italy
{luca.berardinelli,vittorio.cortellessa,antinisca.dimarco}@univaq.it
Abstract. 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 offer
the best quality (intended as a combination of non-functional proper-
ties) 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 in-
troduce a framework to uniformly model different 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 environ-
ment. 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 Magic-
Draw modeling environment, with the support of existing UML profiles
for modeling context-awareness and non-functional properties. We finally
show an example of modeling and analysis of reliability in the eHealth
domain.
1 Introduction
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 effectively 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 specific 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 [20].
?
This work has been partly supported by the Italian Project PACO (Performability-
Aware Computing: Logics, Models, and Languages) funded by MIUR.
2 Berardinelli, Cortellessa, Di Marco
The limitation of hardware resources has brought to develop specific 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 effects 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 specific characteristics of mobility
and context-awareness, in this framework the interdependencies between them
can be captured and the cross-effects can be considered. Thus certain types of
analysis, that were not feasible with specific models, are enabled in our frame-
work 1 .
Fig. 1. Context as a combination of multiple attributes.
In Figure 1 we represent our idea of context, as the combination of attributes
that can come from different domains. In particular, in this paper we focus on
physical and logical location-awareness and hardware platform awareness. Our
approach [5] does not limit the context definition to these domains, as it is ex-
tensible to any attribute or set of attributes that may contribute to the context
definition. This modular approach allows also to provide restricted context rep-
resentations in all cases where only few context attributes are necessary (e.g.,
logical mobility is not allowed).
Non-functional properties of mobile context-aware software systems obvi-
ously also depend on the characteristics of software services provided in each
specific context. Different implementations of the same service may be available,
possibly exploiting code mobility paradigms [10], so they can be dynamically
1
Our approach has been conceived for multiple types of non-functional analysis [5],
although in this paper (for sake of space) we only provide an example of reliability
analysis.
An Unified Approach to Model NFPs of Mobile Context-Aware SA 3
chosen in order to provide the service implementation that better fits the ex-
ecution context 2 . We name context-aware, adaptable applications the software
systems able to provide services in these settings.
The paper is organized as follows: Section 2 briefly describes the basic ideas
behind our framework, Section 3 presents the UML implementation of the frame-
work driven by an eHealth application example, in Section 4 we show how to
conduct a reliability analysis, Section 5 introduces the related work, and finally
Section 6 concludes the paper.
2 A Unifying Modeling Approach to the
Context-Awareness
In our approach, context-awareness is intended as the property of software to
manage knowledge related to the context, where the context is defined here as
a combination of (physical and logical) location and hardware platform charac-
teristics.
The framework proposes a uniform representation of the location and hard-
ware 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 plat-
form 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 defined in isolation or, through remote firing, can affect 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 fluctuation 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.
4 Berardinelli, Cortellessa, Di Marco
mobility, hardware platform evolution). Obviously not all the combinations are
allowed, for example a certain configuration 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 defined, 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 specified 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 figure) the list of provided services and their behaviors chosen
for the specific 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.
Fig. 2. The Context Superstate.
Transitions have to be defined in this unifying statechart. Being each su-
perstate 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 different statecharts is very similar to the problem
of combining stochastic behaviors of concurrent processes. The latter has been
faced with different approaches, among which Stochastic Process Algebra seems
to be a promising notation to be applied to our case as well [19].
More details on the notation-independent framework can be found in [5].
An Unified Approach to Model NFPs of Mobile Context-Aware SA 5
3 UML-based modeling of a context-aware software
application
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 sys-
tem as perceived and used by external actors (Use Case Diagram, UCD) along
with their behavioral specifications (Sequence Diagram, SD). A Physical Mobil-
ity Manager is assigned to the nomadic users that exploit the system services
while moving with their mobile devices [17, 13].
The Component View (CV) represents the software architecture (Com-
ponent Diagram, CD). It is integrated with mobility annotations that allow to
distinguish logically mobile from fixed software artifacts [13]. A Logical Mobility
Manager [13] is associated to each component whose implementation is (even
partially) mobile.
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 different places (Dynamic Deployment Diagram, dynDD),
and (ii) several detailed hardware device specifications (hwDD). A Hardware
Configuration Manager describes a resource whose state (e.g. its current amount)
may vary at runtime.
<> <> <>
System UML Profilie for
<>
Mobile System
ServiceView DeploymentView <>
<>
MARTE_Profile
PhysicalMobilityManager HwConfigurationManager
SD DynamicDD
UCD DeviceSpecs <>
<> <>
<>
ContextModelingProfile
ComponentView
<>
LogicalMobilityManager <>
CD DAM
Fig. 3. The System Model.
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 sev-
eral profiles to enable model-based reliability analysis [7] of the specified system.
The applied profiles are MARTE [3], that includes the Dependability Analysis
Model [6], and the UML Profile for Mobile Systems [13]. We have also devised
3
The complete UML model can be downloaded at
http://www.di.univaq.it/cortelle/docs/eHealthSystemModel.rar.
6 Berardinelli, Cortellessa, Di Marco
and applied a preliminary version of a Context Modeling profile to support the
modeling of the manager statechart 4 .
<> <> <>
<>
Client.exe AppServer Database ImageServer
SOFTWARE
<> <> <> <> ARTIFACTS
<>
LEVEL
{failure = "PSI_WAN"}
<>
WAN {failure = "PSI_LAN"}
<>
<> <> <>
HOSTS
PDA AppHost DbHost ImageServerHost LEVEL
<> <>
LAN
{failure = "PSI_WAN"}
<>
<> <> <>
PHYSICAL
LOCATIONS
<>
LEVEL
<>
Open Air
<>
<>-PSI_WAN : NFP_Real [1] = 0.004
<> ImageServerLoc
3G : WAN <>-PSI_WAN : NFP_Real [1] = 0.007
<>
Doc's Home EDGE : WAN
<>PSI_WAN : NFP_Real [1] = 0.003{redefines PSI_WAN} <>
<>
<>
Data 3G : WAN
<> <> 802.11n : LAN 3G : WAN ServerLoc <>
<> <>
Surgery Patient's Home <>-PSI_LAN : NFP_Real [1] = 0.001 802.11g : LAN
Fig. 4. The Dynamic Deployment Diagram.
3.1 Modeling the software architecture
The reference example is a eHealth system that provides a service called Re-
questPatientInfoPage: a doctor is able to retrieve mixed media information on
his/her patients, such as text with or without different kind of images that re-
fer 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 profile). In our modeling approach, services are
provided by a component-based system whose architectural description is given
by a Component Diagram (CD). The CD identifies the software components,
their interconnections and the executable artifacts implementing them. More-
over, it specifies which component is mobile and the component failure proba-
bility needed for the analysis methodology [7] applied in Section 4.
In Figure 4 the dynamic DD of the application is shown. It is inspired to the
diagram introduced in [13], and it basically contains two types of information: (i)
the allocation of the software artifacts (SchedulableResources) on the execution
4
Hereafter the typewritten words are model variables (following the MARTE [3]
recommendations), whereas the italicized ones are stereotypes of profiles.
An Unified Approach to Model NFPs of Mobile Context-Aware SA 7
environments (GaExecHost) through deployment relationships (CurrentDeploy-
ment, AllowedDeployment) between the Software Artifacts and the Hosts levels,
and (ii) the positioning of the execution hosts (e.g. PDA) on different physical
locations using associations (CurrentLocation, AllowedLocation) between Hosts
and Physical Locations levels. The dynamic nature of the dynDD derives from
the need to change the current and allowed relationships between levels whenever
logical and/or physical mobility events take place.
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).
Different Places can provide different 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 de-
sign choices and/or hardware limitations. Moreover the available connections
can have different non-functional characteristics that affect the properties of the
service provision: in our case, the service reliability is influenced by the network
failure probability (i.e. PSI WAN) [7] whose value is bound to the CurrentNode-
Location association and varies when the doctor moves across the other allowed
physical locations (i.e. AllowedNodeLocation).
Lastly, Figure 5 shows the hardware components making up the doctor’s PDA
[3]. In particular the PDA can connect to a WAN network using its HwEnd-
Point 3G card. Indeed we specify that a 3G WAN network is available (i.e.
the black-colored port named 3G:WAN) both when the doctor is at his/her
home or outside, but with different reliability characteristics (see the redefined
PSI WAN variable in Figure 4). We also declare here those variables (e.g. DISK’s
memorySize, BATTERY’s capacity) that will be referred by the hardware con-
figuration managers (see Section 3.2).
<>
PDA
<> <> <>
CPU <> 3G Card
<> BATTERY
{frequency = "currFrequency" , {connectedTo = WAN,
DISK resMult = 1} {capacity = "capacity", resMult = 1}
{memorySize = "memorySize", <>-currHwConfig : NFP_String [1] resMult = 1}
resMult = 1} <>-currFrequency : NFP_Frequency [1] <>-capacity : NFP_Energy [1] = (1100,mAh)
<>-currHwConfig : NFP_String [1]
<>
DISPLAY
{resMult = 1}
Fig. 5. The hardware platform specification of the doctor’s PDA.
3.2 Modeling the Context-Awareness
In this section we model the context-awareness of the eHealth application fol-
lowing our approach. In Section 3.3, we will describe how the *-awareness can
influence different behavior specifications of the same system service.
8 Berardinelli, Cortellessa, Di Marco
Physical Location-Awareness - The modeling of the Physical Location
Awareness takes inspiration from some previous works [13, 17]. We define a Phys-
ical Mobility Manager associated to each system nomadic user (i.e. in our case
the doctor).
A UML StateMachine is defined where each state represents both the current
physical location (Place) and physical resources in the surroundings (together
referred as physical configuration, PhyConfig) 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 PhyConfig state defines the actual
ends of the Current- and AllowedNodeLocations relationships among execution
hosts and places on the dynDD (Figure 4, [13]).
Logical Location-Awareness - Logical mobility is informally defined as
the capability to dynamically change the bindings between code fragments and
the location where they are executed [10]. We adopt the UML-based solution
proposed in [13] based on a statechart called Logical Mobility Manager. In a
Logical Mobility Manager a state corresponds to the current allocation (Current-
Deployment) of the software components (MobileCode) to the proper execution
platforms (GaExecHost, Figure 4). State transitions represent the possible re-
deployment of the mobile software artifacts through the communication channels
(HwMedia on Figure 4) to other platform devices (AllowedDeployment).
Hardware Platform Awareness - The third dimension of the context-
awareness, as defined in this paper, takes into account the detailed hardware
specification of the execution environment. We specify in Figure 6(b) the Hard-
ware Configuration Managers for hardware resources of Figure 5 whose internal
configuration (HwConfig) can influence the service behavior.
Figure 6 illustrates the BATTERY, Display and CPU’s managers as sepa-
rate statechart that model the states and transitions of corresponding hardware
components (Figure 5). Each state specifies a set of nfpConstraints (based on
variables defined on the configured hardware component) [3] to hold the current
configuration (see the battery manager in Figure 6(b)).
In addition, a remote firing transition (BATTERY2LowPowerDowngrade)
highlights how the remaining BATTERY capacity (currCapacity) influences
the status of the CPU by firing a remote transition that limits its clock frequency
(currFrequency).
3.3 Modeling the service behaviors
The eHealth modeling is completed by the specification 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.
An Unified Approach to Model NFPs of Mobile Context-Aware SA 9
Fig. 6. Physical Mobility and Hardware Configuration Managers.
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) defined 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 configuration 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 Lumping the awareness in a unique model
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) stat-
echart. In particular, we have considered the doctor’s Physical Mobility Manager
and the PDA Display Hardware Configuration 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 different 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.
10 Berardinelli, Cortellessa, Di Marco
Fig. 7. The Interaction Overview Diagram for the RequestPatientInfoPage service.
4 An example of reliability analysis
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 [7] to study the relia-
bility of a software architecture as a function of the reliability of its components,
its connectors and other structural parameters. We have tailored that model to
the case of context-awareness and we have used it to estimate the reliability of
an example service (as modeled in Section 3) in different superstates.
As illustrated in Section 2, we assume that the set of services available to
users can be different across the superstates due to changes in the resource
characteristics. Moreover, different implementations of the same services can
be provided in different superstates in order to adapt the service behavior to
different hardware configurations. In order to denote superstate-specific services
(and components implementing them), as well as other system parameters, we
introduce the following notation: x|σ . 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 Sk |σ be the implementation of Sk provided in the σ superstate; and finally
let Ci |σ (i = 1, . . . , N ) be the set of components implementing Sk |σ .
An Unified Approach to Model NFPs of Mobile Context-Aware SA 11
Let θi |σ be the probability of failure of Ci |σ , and let bpi |σ be the number of
activations of Ci |σ within the dynamics of Sk |σ .
Let ψ |σ be the probability of failure of the connector between Ci |σ and
Cj |σ , and let int |σ be the number of interactions between these two com-
ponents within the dynamics of Sk |σ .
Hence, we have reformulated the model in [7] to the case of context-aware
service reliability as follows:
N
Y Y
R(Sk |σ ) = (1 − θi |σ )bpi |σ · (1 − ψ |σ )int |σ (1)
i=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 θi |σ ’s can be extracted from an annotated Component Diagram mod-
eling the software architecture of the application, ψ ’s from a Deployment
Diagram like the one in Figure 4, and structural parameters bpi |σ and int
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 repre-
sents the context management of the eHealth application. For sake of space we
do not show this process here, but we compute the reliability of RequestPa-
tientInfoPages service (RPIP-service) in two different contexts, that are: Ope-
nAir/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 effect 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 different 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 − service|CD ) = 0.9386 and R(RP IP − service|BW 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 different if superstates with different
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
12 Berardinelli, Cortellessa, Di Marco
Components Client AppServer Image Server DB
θ i |σ 0.010 0.003 0.003 0.001
bpi |σ 1 1 2 (σ = CD) 4
0 (σ = BW D)
Connectors Client, AppServer, AppServer,
AppServer Image Server DB
ψ |σ 0.010 0.003 0.001
int |σ 2 4 (σ = CD) 8
0 (σ = BW D)
Table 1. Reliability model parameters.
studied by simply comparing the service reliability in different contexts (e.g. the
failure probability of components may change if different versions of the same
service are implemented with different 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 state-
chart for context management allows to make analysis across different 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 Related work
Several approaches have been introduced in the last few years to manage mobil-
ity and adaptation at the middleware level. Among these, very relevant work has
been done within the framework of the MUSIC project [15]. Basing on a com-
bined resource and context model the MUSIC middleware monitors the context
and the resources to catch their changes and adapts the application to fulfill the
users’ QoS (Quality of Service) requirements. The approach uses QoS predic-
tors and utility functions to support the adaptation process. The adaptation is
based on the concept of service plan [16], that is a platform-independent specifi-
cation containing information on service configurations, its dependencies on the
environment and its QoS and characteristics.
All the MUSIC contributions can be used at run time given that the applica-
tion has been developed to be context-aware and QoS validated. As assessed in
[16], the information the MUSIC middleware needs to properly work is specified
in the service plan, but such information is collected at the design time.
As opposite to MUSIC project and other middleware contributions (e.g.
ReMMoC [11]), we provide a support to model and analyze non-functional prop-
erties of such systems before their implementation and deployment. For example,
with our framework it would be possible to automatically generate the (MUSIC)
An Unified Approach to Model NFPs of Mobile Context-Aware SA 13
service plan and provide the QoS models that work as predictors in the MUSIC
adaptation process.
Another interesting project is DiVA [2], which aims at providing an inte-
grated framework for managing dynamic variability in adaptive systems. Differ-
ently from other approaches where the dynamic adaptation is handled at code
level [14], DiVA exploits both Model-Driven and Aspect-Oriented technologies
to define an architectural model (including base, variant and adaptation mod-
els) at design time [9]. The composition and validation at runtime of alternative
models allow: (i) the choice of the system configuration that best adapts to the
changed execution context, and (ii) the deployment and execution of the cho-
sen configuration supported by a reflective middleware [18, 4]. However, such
approach does not provide any support for non-functional analysis.
Grassi et al. in [12] have proposed a modeling framework for QoS-aware self-
adaptive software applications that present several similarities with our frame-
work. Such framework, based on the definition of an intermediate pivot language
(i.e. D-KLAPER), is aimed at providing instruments to transform software mod-
els into non-functional models and analyze QoS characteristics while changes in
the application and/or its environment may occur.
Our work improves the approach in [12] for several aspects: (i) context-
awareness and mobility are based in our approach on a set of attributes whose
evolution is modeled through Statecharts, whereas in [12] a set of triggers has to
be specified in isolation; (ii) the previous difference allows us to introduce depen-
dencies among events that cannot apparently modeled with D-KLAPER; (iii) we
have implemented our approach in UML, so to prove that such language has the
potential to represent triggers and (simple) adaptation mechanisms, whereas this
part of D-KLAPER still does not find any correspondence in UML. However,
on the other side, the work in [12] also presents some advantages, such as: (i) to
explicit represent adaptation actions, (ii) to take into account the non-functional
costs of such actions, (iii) to generate a Markov Reward Model that allows to
study non-functional properties even in non steady states of the system.
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 [8]
to extend the Darwin ADL for modeling Service Oriented Computing systems.
Modes are also language primitives in the Architecture&Analysis Description
Language (AADL) [1] for modeling Real-Time&Embedded Systems. In both
cases they can be used to model the structural evolution of software architecture
at runtime. Besides components, AADL allows the modal specification of all its
modeling elements like system, connectors and properties. Thus, our logical and
hardware managers can be modeled as AADL component’s modes whereas the
overall context manager as system’s modes. In AADL, it is also possible to model
the physical mobility by means of system’s modes. However, in this case, it can’t
be associated to a system user as we do associating the manager to UML Actors.
Therefore, differently to AADL, our UML-based modeling approach can be (i)
”sized” for different definitions of context and (ii) used as a general ”modal-
based” modeling approach for software system of multiple domain.
14 Berardinelli, Cortellessa, Di Marco
6 Conclusions
We have introduced an unifying approach to the modeling of location- and hard-
ware platform-awareness aimed at analyzing non-functional properties of soft-
ware 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 affect non-
functional properties. Such separate models can be used in isolation or variously
combined to study the behavior of such system under different types of changes.
Besides, with previous modeling approaches cross-dependencies among at-
tributes were hard to capture because they were represented with different mod-
els or not represented at all. With our unifying approach all attributes are in-
tegrated 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 affect non-functional prop-
erties. As long as this evolution can be represented through a state machine,
the mechanisms presented here can be applied to integrate these additional con-
cepts to the context evolution. We are also working to increase the complexity
of statechart remote firing 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 tradeoff analysis between different
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 [12] as a general target model is very
interesting to allow more complex types of analysis.
References
1. Architectural and Analysis Description Language, http://www.aadl.info/ .
2. DynamIc VAriability in complex, adaptive systems, Research Project,
http://www.ict-diva.eu/ .
3. UML Profile for MARTE, OMG document ptc/08-06-09, Object Management
Group, Inc. (2008), http://www.omgmarte.org/Documents/Specifications/08-06-
09.pdf.
4. Nelly Bencomo. Supporting the Modelling and Generation of Reflective Middleware
Families and Applications using Dynamic Variability. Phd thesis, Computing De-
partment, Lancaster University, 2008.
An Unified Approach to Model NFPs of Mobile Context-Aware SA 15
5. Di Marco A. Berardinelli L., Cortellessa V. An unified approach to
model non-functional properties of mobile context-aware software. Techni-
cal Report 003-2009, Computer Science Department, University of L’Aquila,
http://www.di.univaq.it/cortelle/docs/report-003-2009.pdf.
6. Simona Bernardi, José Merseguer, and Dorina C. Petriu. Adding dependability
analysis capabilities to the marte profile. In Proc. of MoDELS ’08, pages 736–750.
Springer-Verlag, 2008.
7. Vittorio Cortellessa, Harshinder Singh, and Bojan Cukic. Early reliability assess-
ment of uml based software models. In Proc. of WOSP ’02, pages 302–309. ACM,
2002.
8. Jeff Magee Dan Hirsch, Jeff Kramer and Sebastian Uchitel. Modes for software
architectures. In European Workshop on Software Architecture (EWSA ’06), pages
113–126. LNCS 4344, 2006.
9. Franck Fleurey, Vegard Dehlen, Nelly Bencomo, Brice Morin, and Jean-Marc
Jézéquel. Modeling and validating dynamic adaptation. Models@Runtime Work-
shop in conjunction with MODELS 2008, 2008.
10. Alfonso Fuggetta, Gian Pietro Picco, and Giovanni Vigna. Understanding code
mobility. IEEE Trans. Softw. Eng., 24(5):342–361, 1998.
11. Paul Grace, Gordon S. Blair, and Sam Samuel. A reflective framework for discovery
and interaction in heterogeneous mobile environments. Mobile Computing and
Communications Review, 9(1):2–14, 2005.
12. Vincenzo Grassi, Raffaela Mirandola, and Enrico Randazzo. Model-driven as-
sessment of qos-aware self-adaptation. In Software Engineering for Self-Adaptive
Systems, pages 201–222, 2009.
13. Vincenzo Grassi, Raffaela Mirandola, and Antonino Sabetta. A uml profile to
model mobile systems. In UML, pages 128–142, 2004.
14. P. Inverardi, F. Mancinelli, and M. Nesi. A declarative framework for adaptable
applications in heterogeneous environments. In Proc. of SAC ’04, pages 1177–1183,
2004.
15. IST-MUSIC Project. Middleware Support for Self-Adaptation in Ubiquitous and
Service-Oriented Environments. http://www.ist-music.eu/.
16. Sten A. Lundesgaard, Ketil Lund, and Frank Eliassen. Service plans for context-
and qos-aware dynamic middleware. Distributed Computing Systems Workshops,
International Conference on, 0:70, 2006.
17. Antinisca Di Marco and Cecilia Mascolo. Performance analysis and prediction of
physically mobile systems. In Proc. of WOSP, pages 129–132, 2007.
18. Brice Morin, Franck Fleurey, Nelly Bencomo, Jean-Marc Jézéquel, Arnor Solberg,
Vegard Delhen, and Gordon Blair. An aspect-oriented and model-driven approach
for managing dynamic variability. In MODELS’08, volume 5301/2008 of LNCS,
pages 782–796, 2008.
19. Rocco De Nicola, Joost-Pieter Katoen, Diego Latella, Michele Loreti, and Mieke
Massink. Model checking mobile stochastic logic. Theor. Comput. Sci., 382(1):42–
70, 2007.
20. Gian Pietro Picco, Amy L. Murphy, and Gruia-Catalin Roman. Lime: Linda meets
mobility. In Proc. of ICSE ’99, pages 368–377, New York, NY, USA, 1999. ACM.