- 1 -

Software and Efficiency Metrics for Context-Aware Mobile Applications CASPAR RYAN AND PABLO ROSSI1 School of Computer Science & IT, RMIT University

As mobile applications become more pervasive, the need for assessing their quality, particularly in terms of efficiency (i.e.

performance and resource utilisation), increases. Although there is a rich body of research and practice in developing metrics for

traditional software, there has been little study on how these relate to the adaptation of context-aware mobile applications.

Therefore, this paper defines and empirically evaluates metrics to capture software, resource utilisation and performance

attributes, for the purpose of modelling their impact on the execution of context-aware mobile applications.

To begin, a critical analysis of the problem domain identified a number of specific software, resource utilisation and performance

attributes, and the relationships among them. For each attribute, a concrete metric and technique of measurement was defined.

Based on the relationships among attributes, a series of hypotheses were then proposed, and tested empirically using linear

correlation analysis. The results supported the hypotheses thus demonstrating the impact of software code attributes on the

efficiency of mobile applications at runtime.

As such, more formal models in the form of mathematical equations were presented in order to facilitate runtime decisions

regarding the adaptation of mobile objects in a context-aware environment. Preliminary empirical evaluation of a local

adaptation algorithm was carried out using a typical application and an existing mobile application framework. Furthermore,

synthetic data and test cases were used to test the scalability of a selected global adaptation algorithm. Finally, a number of

further global adaptation strategies were presented as a case for future work.

Categories and Subject Descriptors: D.2.8 [Software]: Software Engineering - Metrics; C. [Computer Systems Organization]:

Computer-Communication Networks – Distributed Systems

General Terms: Measurement, Experimentation

Additional Key Words and Phrases: Mobile Software, Context-Awareness, Efficiency

1. INTRODUCTION

It has been recognised that applications with distributed components differ from traditional non-

distributed applications along a number of dimensions including communication type, latency,

concurrency, partial versus total failure, and referencing/parameter-passing strategies [Emmerich, 2000].

1 Email: {caspar,pablo}@cs.rmit.edu.au

- 2 -

Context-aware mobile applications are even more complex than their non-mobile distributed

counterparts, since they involve connections between executable software components or objects that can

migrate from node to node within a heterogeneous software and hardware environment [Jing et al., 1999;

Ryan and Westhorpe, 2004]. Such environments can be highly dynamic, changing over time as users and

devices roam between networks [McGovern and Ryan, 2004] resulting in CPUs becoming loaded and

unloaded and network hot spots or congestion points being in a constant state of flux.

Given these differences, this paper argues that it is necessary to extend established software

engineering metrics and models before applying them to the emerging domain of adaptive mobile

applications. Note that it has been argued before, in the domain of web applications, that traditional

methods and metrics should be re-assessed before being applied to a new domain [Ruhe et al., 2003].

A context-aware adaptive mobile application framework called MobJeX [Ryan and Westhorpe, 2004]

is being developed, in conjunction with the work described in this paper, as part of the Applications

Program of the Australian Telecommunications Cooperative Research Centre (ATcrc). MobJeX is a

software development platform with a middleware component enabling dynamic application adaptation

based on runtime resource monitoring and declarative rule specification, thus dynamically supporting the

transparent distribution of application objects at runtime to supporting devices in a heterogeneous Internet

environment.

In this context, application adaptation refers to the ability of an application, or the underlying

middleware, to modify its behaviour in response to changes in environmental context, (e.g. available

network bandwidth or CPU load changes). In the case of MobJeX, adaptation is achieved via object

mobility, in which individual system components, potentially down to the discrete object level, can

migrate through the system whilst maintaining location transparency via remote object references. The

decision of when and how object migration should be performed is dependent on factors such as available

resources and the nature of the interaction between objects. As such, this serves as an area of study in this

paper which proposes and tests metrics to model the impact of software code attributes (which

- 3 -

characterise objects and their interactions) upon resource utilisation (of resources such as network, CPU

and memory) and performance.

The rest of this paper is organised as follows: Section 2 begins with a review of related work, with an

emphasis on prior studies involving the specification of metrics for distributed systems. Section 3,

through a critical analysis of the problem domain, identifies a number of specific software, resource and

performance attributes, and the relationships among them, with a concrete metric and technique of

measurement defined for each attribute. This facilitates the empirical testing of hypotheses related to these

attributes using linear correlation analysis in Section 4, providing support for the hypotheses and thus

demonstrating the relationship between software code attributes and the efficiency, in terms of

performance and resource utilisation, of mobile applications. To demonstrate a practical application of the

metrics, section 5 proposes a number of different adaptation strategies, thereby facilitating the efficient

placement of mobile objects at runtime, in a context-aware mobile application framework. A local

adaptation algorithm is evaluated by implementation in the MobJeX framework, involving the use of a

real mobile application. Furthermore, the scalability of a global adaptation algorithm is measured using

synthetic data and test cases. Finally, section 6 closes with a summary, conclusions and discussion of

future work.

2. RELATED WORK

Although many software metrics have been defined for traditional applications [Fenton and Pfleeger,

1996], a much smaller number relate to distributed applications in general, and few, if any, consider the

unique characteristics of mobile applications in terms of adaptability and context-awareness, as is the

subject of this paper.

Nevertheless, this section provides a review of related work in terms of the specification of metrics for

the measurement of software attributes of distributed applications, and in some cases the computational

and networking environments in which they execute. For the purposes of comparison, this section is

divided into to two subsections. Firstly, offline metrics are considered in section 2.1, where offline refers

- 4 -

to measurements derived from static design artefacts such as class or sequence diagrams, or non executing

source code. In contrast, section 2.2 is concerned with metrics that are dynamically collected at runtime

and thus the value of which may change in response to variations in the computational or networking

environment, or changes in the behaviour of the application itself.

2.1. Offline measurement

[Shatz, 1988] proposed a metric for measuring communication complexity in distributed Ada

programs, describing total complexity as the weighted sum of two components. Firstly, local complexity,

which reflects the complexity of the individual tasks (disregarding their interactions with other tasks), was

measured using traditional metrics such as lines of code or cyclomatic complexity. Secondly,

communication complexity, which reflects the complexity of interactions among tasks, was derived by

representing the programs as Petri nets and measuring the number of rendezvous which can be executed

concurrently at a given point in time. Neither empirical evaluation nor discussion about the practical

utility was presented.

[Cheng, 1993] also proposed a set of complexity metrics for distributed programs. Like [Shatz, 1988],

the metrics were defined based on graph representations for 1) multiple control flows (non-deterministic

parallel control-flow net), 2) multiple data flows (non-deterministic parallel definition-use net) and 3)

various program dependencies (process dependency net). As above, no empirical support was provided,

nor was a discussion of how the metrics could be used within the software engineering process.

Based on the smallest event communication group (SECG) concept, [Tsuar and Horng, 1998]

proposed a metric to quantify the complexity of distributed programs, which was defined in terms of the

number of events of a SECG. Although, the metric was experimentally evaluated with a moderately

complex example, it was not made clear how it could be used by practitioners.

[Morasca, 1999] proposed a set of measures for capturing a number of internal attributes (namely size,

length, complexity, and coupling) of software specifications written with Petri nets for concurrent

- 5 -

systems. These measures were theoretically evaluated against a property-based approach that has been

discussed in the literature, however an empirical evaluation was not provided.

A measurement suite to quantify design attributes of distributed systems was presented by [Rossi and

Fernandez, 2003]. The proposed measures were obtained from formal models derived from intuitive

models of the problem domain. Although these measures were theoretically evaluated following a

framework proposed in the literature, they were not the subject of an empirical evaluation. As a follow-up

to the previous study, [Rossi and Fernandez, 2004] used the models to provide an estimation of runtime

performance, but did not consider the impact of resource utilisation and thus overall efficiency.

2.2. Runtime Measurement

In [Noble et al., 1997], a technique was proposed to support application aware adaptation [Jing et al.,

1999] in client/server applications by measuring network bandwidth, CPU load, and battery power. In

another case, [Flinn and Satyanarayanan, 1999] proposed the use of a metric battery power, in order to

assist energy-aware adaptation based on a trade-off between energy consumption and application quality

for mobile applications. However, both proposals were concerned only with a small number of

environment metrics, and neither provided details about the measurement of software attributes.

A study by [McGregor et al., 1999] considered the online collection of dynamic software metrics, in

terms of number of invocations and response time for methods of distributed objects. However, although

the study attempted to measure method level metrics, it was done at the application level outside of the

object implementing the method. As such, the response time of a method could only be measured

accurately if the call was a single level deep between mobile components.

A paper describing the proposed adaptation engine for FarGo [Gazit et al., 2000] , considered the

online collection of both software and environmental metrics, but did not discuss how such metrics could

be collected in practice. Additionally, the software metrics proposed were measured only at the complet

(component cluster) level rather than the level of individual objects and methods as is the case in the

present paper.

- 6 -

[Arisholm et al., 2004] proposed a system for dynamically measuring object coupling, for the purpose

of determining the structural properties of software, by collecting metrics via internal measurement within

the object itself. However the chosen metrics, namely number of invocations and lines of code, were

defined in the context of non-distributed applications.

[Chen et al., 2004] investigated object level metrics needed by distributed applications to offload code

compilation to different hosts by measuring compilation cost and class migration time. In addition, a

software metric, number of invocations, was measured as was the condition of the communication

channel. It should be noted that the focus of the paper was primarily on the specific scenario of distributed

compilation, rather than distributed execution as is the case herein.

Finally, a framework for developing adaptive distributed applications described by [Silva et al., 2003],

included a discussion of the online collection of both software and resource metrics. However, the paper

did not provide a clear practical rationale for the metrics, nor provide an empirical evaluation.

2.3. Summary

The first observation regarding the state-of-the-art of distributed software measurement is that most of

the proposed measures were derived for distributed applications whose components were assumed to be

allocated to a fixed host and thus not mobile. To the best of our knowledge, the measurement of mobile

distributed applications has not yet been attempted.

Secondly, most measures for distributed software presented in the literature were not evaluated

empirically, and in some cases there was no explicit link between the measures of interest and some

external quality attribute such as efficiency, reliability or maintainability. These problems, among others,

result in few metrics having successfully gone past the definition phase and thus being used in practice

[Briand et al., 2002].

Finally, the usefulness and/or practical applicability of the proposed metrics has not been explicitly

discussed. This is problematic since many authors suggest that for software measures to be useful in real

- 7 -

projects they should be characterised by practical properties [Card and Glass, 1990; Grady and Caswell,

1987].

In summary, the studies analysed in this section suffer at least one of the following shortcomings:

• metrics are not empirically evaluated and/or have no clear practical applicability

• software or environmental metrics are considered in isolation to each other

• when software metrics are collected, it is not clear what software attributes are being measured or

what effect these will have on external quality attributes

• metrics are not collected during the runtime execution of a distributed application and are

therefore not applicable to the runtime adaptation of mobile applications

Therefore, given these shortcomings, it seems appropriate to develop and empirically evaluate a new

suite of metrics to support the unique aspects of mobile distributed software. These metrics, which are

designed to be collected at runtime, are presented in the following section.

3. SPECIFICATION OF ATTRIBUTES AND METRICS

As discussed previously, this paper is concerned with the effect of software and resource attributes on

the runtime mobility of software components, and the subsequent impact on application efficiency. For

the purpose of this paper, in line with ISO 9126-1 [ISO/IEC, 2003], efficiency is considered to be a high-

level quality attribute comprising the sub-attributes performance (the capability of software to provide

appropriate response and processing times, and throughput rates) and resource utilisation (the capability

of software to use appropriate amounts and type of resources when the software performs its function).

Software is considered to be more efficient as performance increases and resource utilisation decreases.

From a critical analysis of the problem domain a number of software code attributes were identified

that were likely to have an impact on different efficiency attributes in a mobile application context. Next,

concrete metrics were derived for each of the attributes in a form that could be measured or estimated at

runtime within a middleware environment for each of the attributes. The complete set of derived

- 8 -

attributes, their descriptions, and their associated metrics and units of measurement are listed in Table 1,

with grouping from top to bottom being by software, performance and resource utilisation respectively.

Note that additional attributes such as object life span and participation in critical scenarios were

identified but considered beyond the scope of this paper and thus left to future work. Details of how each

measure was quantified can be found in Table 2.

The next stage of the model derivation process, again via a critical analysis of the problem domain,

was the formulation of hypotheses expressing the intuitive multi-way relationships between software,

resource utilisation, and performance attributes. Hypotheses P1-P4 are concerned with the impact of

software attributes on performance, whilst hypotheses RU1-RU8 relate to the effect of software attributes

on resource utilisation. Finally, RUP1-RUP4 express the general effect of resource utilisation on

performance.

Note that the resource utilisation measures are derived from the ratio of raw usage and total capacity

and expressed by a load metric; e.g. the attribute memory utilisation is measured by the metric memory

load [ML] which is derived from the ratio of allocated memory (memory usage [MU]) and available

memory (memory capacity [MC]) as shown in Table 1. Therefore this section presents hypotheses

concerning resource utilisation in terms of load metrics.

- 9 -

Table 1 Software, Performance and Resource Utilisation Attributes and Metrics

Attribute Definition Metric Unit

Object Compilation Volume

The size of an executable module (e.g. Java .class file) Executable Code Size (ECS) byte

Object Serialisation Volume The size of a serialised object Serialised Object Size (SOS) byte

Object Memory Volume The size of an in-memory object Object Memory Size (OMS) byte

Method Execution Volume

The size of the extra memory required during the execution of a method

Execution Memory Size (EMS) byte

Method Body Intensity

The processing intensity of a method in terms of executable statements/instructions

Number of Executed Instructions (NEI) int

Method Interface Volume

The combined size of the parameters of a method interface

Size of Serialised Parameters (SSP) byte

Softw

are

Method Invocation Frequency

The rate of occurrence of method invocation Number of Invocations (NI) int

Method Execution Cost

The execution cost of a method, ignoring any overhead associated with call semantics

Method Execution Time (ET) ms

Method Invocation Cost

The cost of calling a method, independent of its actual processing e.g. marshalling etc.

Method Invocation Time (IT) ms

Object Migration Cost

The cost of moving an object instance (e.g. serialised Java object) between hosts Migrate Instance Time (MIT) ms Pe

rfor

man

ce

Class Migration Cost The cost of moving a class implementation (e.g. Java .class file) between hosts Migrate Class Time (MCT) ms

Network Capacity (NC) byte/s

Network Usage (NU) byte/sNetwork Utilisation The ratio of usage and total network capacity

Network Load (NL) NL = NU / NC × 100 %

Memory Capacity (MC) byte

Memory Usage (MU) byte Memory Utilisation The ratio of usage and total memory capacity

Memory Load (ML) ML = MU / MC × 100 %

Processor Capacity (PC) int/s

Processor Usage (PU) int/s

Reso

urce

Util

isat

ion

Processor Utilisation The ratio of usage and total processor capacity

Processor Load (PL) PL = PU / PC × 100 %

- 10 -

Table 2. Measurement details

Metric Measurement details

ECS File.length() returns the size of a file.

SOS A special method — ObjectMeter.getSerialisedSize() — was written to serialise an object into an array of bytes and return the length of the array.

OMS Instrumentation.getObjectSize() returns the amount of memory consumed by an object.

EMS Estimated by analysing the source code.

NEI Estimated by analysing the source code2.

SSP Analogous to SOS

NI Estimated by analysing the source code.

ET System.currentTimeMillis() is placed before and after the method body and the difference is calculated.

IT System.currentTimeMillis() is placed before and after the method invocation to get total response time (RT) with invocation time (IT) calculated as IT = RT – ET.

MIT System.currentTimeMillis() is placed before and after the object instance migration and the difference is calculated.

MCT System.currentTimeMillis() is placed before and after the object class migration and the difference is calculated.

NU, NC PDH variables accessed via JNI.

MU, MC Runtime.totalMemory() – Runtime.freeMemory(), Runtime.totalMemory().

PU, PC PDH3 variables accessed via the Java Native Interface (JNI).

2 This metric should not be confused with the constant lines of code (LOC) since it refers to executed rather than total coded instructions. A line of code (i.e. an instruction) may be executed several times or not executed at all depending on the context. Therefore although NEI may be constant (e.g. in the absence of branches or conditionals), in most cases an average or typical value of NEI would be used.

3 Windows specific performance data accessed by a Java Native Interface to the performance data helper API (pdh.dll) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/perfmon/base/using_the_pdh_interface.asp

- 11 -

P1. The larger the serialisation volume of an object, the greater the object migration cost across a

network link. [+SOS +MIT]

P2. The larger the compilation volume of an object, the greater the class migration cost across a

network link (assuming the class is not cached and must be transmitted with the object instance

above) [+ECS, +MCT]

P3. The larger the volume of a method interface, the higher the remote method invocation cost [+SSP,

+IT]

P4. The greater the intensity of a method body, the higher the execution cost [+NEI, +ET]

RU1. The more intensive the body of a method, the greater the processor utilisation [+NEI, +PL].

RU2. The higher the invocation frequency of a method, the greater the processor utilisation [+NI, +PL]

RU3. The larger the serialisation volume of an object, the greater the network utilisation required to

migrate the object [+SOS, +NL]

RU4. The larger the compilation volume of an object, the greater the network utilisation required to

migrate the object (assuming the class is not cached and must be transmitted with the object

instance) [+ECS, +NL]

RU5. The larger the interface volume of a method, the greater the network utilisation required to invoke

it remotely [+SSP, +NL]

RU6. The higher the invocation frequency of a method, the greater the network utilisation [+NI, +NL].

RU7. The larger the memory volume of an object, the greater the memory utilisation upon creating a

new instance [+OMS, +ML].

RU8. The larger the execution volume of a method, the greater the memory utilisation [+EMS, +ML].

RUP1. As network utilisation increases, object migration cost increases [+NL, +MIT].

RUP2. As network utilisation increases class migration cost increases [+NL, +MCT].

- 12 -

RUP3. As network utilisation increases, method invocation cost increases [+NL, +IT].

RUP4. As processor utilisation increases, method execution cost increases [+PL, +ET].

Note that there are no relationships and hypotheses concerning the effect of performance and resource

utilisation on software attributes, because software attributes are independent of performance and

resource utilisation. The same applies with performance versus resource utilisation.

Also note that the authors identified other potential relationships that are not expressed by hypotheses.

For example as memory utilisation increases, paging could affect performance. Furthermore, as processor

utilisation increases there will inevitably be an effect on performance attributes such as method invocation

cost. However since these factors were not expected to have a primary effect, and in the interests of

studying a manageable set of relationships in this paper, the analysis of such relationships is left to future

work.

4. EMPIRICAL EVALUATION

This section describes an empirical evaluation designed to test statistically the relationship between

metrics, as expressed by the hypotheses introduced in section 3. For each hypothesis, experimental data

was collected using a synthetic Java application, with the measurement of metrics obtained either through

internal instrumentation of the code, or from the operating system via system calls. All tests were

executed in a university research computing lab using two identical machines (Pentium IV 1.8 GHz, 256

MB, Windows 2003 Enterprise Server) in a client server configuration via a 100 Mbps Ethernet link. The

test machines were disconnected from the main university network.

To broaden the applicability of the tests beyond the simple configuration described above, where

possible4 tests were replicated with different devices (e.g. laptops, PDAs and smart-phones), networks

4 Note that the hypotheses concerning relationships involving resource utilisation were only measured on Windows since we did not have access to the necessary resource metrics from Java on the other platforms.

- 13 -

links (e.g. 56 Kbps modem, ADSL, 11 Mbps wireless) and Operating Systems (Symbian, Windows

Mobile Edition, Linux).

The empirical data was analysed using linear correlation analysis [Freund and Wilson, 1998] (via

SPSS [SPSS, 1998]), a technique commonly used in exploratory software engineering research [Briand et

al., 1995]. The hypotheses established in section 3 were statistically significant at the 0.01 level and all

correlation coefficients were greater than 0.95, indicating a non-trivial association of the code metrics

with efficiency metrics (the raw data is available upon request). All correlation coefficients were positive,

implying greater usage of resources and higher times (i.e. worse performance).

As stated previously, the authors are aware of factors not encompassed by the metrics described in this

paper, which may have an impact on performance. These include scheduling policies, memory

management, garbage collection etc., the effect of which can be seen in the form of the outliers in Figure

1. Nevertheless the linear relationship of the actual independent and dependent factors is clearly visible

and dominant.

Having established the significance of the simple pair wise relationships, the next step was to examine

composite relationships affecting the performance of distributed objects in a mobile application. Figure 2

shows the impact on total method response time [RT] (method invocation time [IT] + execution time

[ET]), for both local and remote method invocations, as method body intensity [NEI] and method

interface volume [SSP] grow. From this graph we can draw a number of useful conclusions. Firstly, for

two machines with identical processing power and load, the factor that differentiates the total method

response time for local versus remote calls, is the invocation cost incurred by the interface volume of the

call parameters. Therefore, in terms of selecting candidates for distributed versus local execution, it is

clear that methods whose computational intensity is high [NEI] compared to their communication

requirements [SSP], are less impacted by remote execution.

- 14 -

0

100

200

300

400

500

600

700

800

900

1000

0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000

Object Compilation Volume (ECS [Kb])

Perf

orm

ance

(MIT

[Ms]

)

Figure 1. Scatterplot of Object Compilation Volume versus Migration Performance

Figure 3 shows the impact of processor load on remote versus local method call response time for a

combination of high and low load client and server machines. Method invocation volume remains null

due to a void interface, and thus invocation time remains constant (which means that all variation in RT is

due to ET). The graph expresses the difference in terms of remote minus local response time. Therefore,

as expected, as load increases on the client (and thus the site of the local call) the response time of the

remote call becomes less than the local call.

- 15 -

localremote

0500

10001500

20002500

3000NEI [+ET] x 1000 0

200400

600800

10001200

14001600

SSP [+IT] - KBytes

0

50

100

150

200

250

300

MRT - ms

Figure 2. Comparison of Local and Remote Method Response Time (RT = ET + IT)

-600

-400

-200

0

200

400

600

800

0 50 100 150 200 250 300

NEI [Millons]

ETL -

ETR [M

illis

econ

ds]

High Load Client - Low Load Server Low Load Client - Low Load ServerHigh Load Client - High Load Server Low Load Client - High Load Server

Figure 3. Impact of processor load on local (ETR) versus remote method execution time (ETL)

- 16 -

5. PRACTICAL APPLICATION – ADAPTATION OF MOBILE APPLICATIONS

Software engineering measurement is not merely about defining new metrics, but about building new

theories that can help solve practical problems [Briand et al., 2002]. As stated previously, one of the main

goals of this research is to provide middleware support enabling mobile applications to maintain specified

levels of quality, particularly efficiency.

Consequently, this section defines, and provides initial testing for, a number of adaptation models

represented as a series of mathematical equations based on the metrics introduced in section 3 and

empirically evaluated in section 4. In general, the practical application of these models is within an

adaptive mobile application framework in which an intelligent system controller collects software code

metrics describing the objects that constitute applications in the system, as well as information about the

computational environment in which the software is running, and makes either proactive or reactive

decisions in terms of object clustering and placement. In this context, two broad adaptive decision making

strategies were proposed, with each represented as mathematical models which were then implemented as

algorithms and empirically evaluated. This allowed not only the testing of the algorithms’ efficacy, but

the identification of specific directions for future work. These strategies are presented below with Section

5.1 concerned with local adaptation, and section 5.2 global adaptation.

5.1. Local Adaptation

Local adaptation is dynamic and reactive, involving an individual node making a decision to move

one object at a time to another host when either a performance or resource utilisation threshold is met.

This type of adaptation is expected to have a significantly lower performance overhead than global

adaptation (section 5.2). As such it would take place more frequently, in order to maintain pre-specified

levels of performance and resources utilisation in a dynamic environment comprising a constantly

changing set of resources, as initially described in section 1.

- 17 -

5.1.1. Modelling Local Adaptation

For clarity, performance and resource utilisation are treated separately in the following subsections,

although it should be noted that efficiency is achieved by obtaining a balance between these two factors.

Performance

Equation 1 describes the general performance case for object migration based on local

adaptation. Migration occurs when the performance difference between two nodes (rtd), following

migration of an object from one node (currentC) to another (destinationD), exceeds a specific threshold

(rtk).. The performance difference is measured in terms of aggregate method response time (rt) across a

certain number of invocations (ni) for all methods of the object being considered for migration.

This equation could also be used for load balancing in terms of resource utilisation (as described in the

following subsection) where a negative rtk specifies the lowest bounds of performance degradation

acceptable in order to balance load. Note that variables in non-italicised bold represent previously defined

metrics from Table 1.

motrtrtrtm

i

Di

Ciid −⎥

⎦

⎤⎢⎣

⎡−×= ∑

=1)(NI (1)

where

• mot: total time for migration of object (see equation 1a)

• rti: actual (or estimated) total response time of method i (see equation 1b)

• m: number of methods of the object

mot = MCT(ECS, NL) + MIT(SOS, NL) (1a)

rti = ITi(SSP, NL) + ETi (NEIi, PL) (1b)

Equations 1a and 1b summarise relationships that are implicit in the hypotheses of section 3. Firstly,

total object migration time comprises both class migration time (assuming it is not cached), which is a

function of executable code size and network load, and instance migration time which is a function of

- 18 -

serialised object size and network load. Secondly, total method response time consists of method

invocation time (which is a function of the size of the serialised parameters and network load) plus

method execution time (which is a function of the number of executed instructions and processor load).

Resource Utilisation

Equation 2 models the decision making process concerning whether an object should be migrated in

order to more evenly distribute resource load across nodes. Migration occurs when the difference (rld)

between the current and future resource load (ru/rc) of two nodes, following migration of an object from

one node (currentC) to another (destinationD), exceeds a user-defined threshold (rlk). This avoids over-

reactive behaviour wherein the migration of an object has an insignificant impact on utilisation.

The basic formula of equation 2 has been generalised for the three resource types investigated in this

paper: memory, network and processor5. Note however that for each of these three resource types, specific

definitions of the sub-variables (rui and ruF ) of object resource usage (ruO) are given. These definitions,

which are expressed in terms of the metrics presented in this paper, are provided for memory (mui and

muF), network (nui and nuF) and processor (pui and puF) in equations 2b-2d respectively. As in the

previous section, non-italicised bold indicates metrics from Table 1.

D

OD

C

OC

D

D

C

C

d rcruru

rcruru

rcru

rcrurl +

−−

−−= (2)

where

• ruC, ruD: resource usage at the current and destination nodes of the object respectively

• rcC, rcD: total resource capacity of the current and destination nodes of the object respectively.

• ruO: object resource usage (see equation 2a)

5 Other resources such as mass-storage capacity and power consumption are to be studied in future work.

- 19 -

Equation 2a defines the resource usage of an object (ruO) comprising a fixed usage component (ruF)

plus an average, based on the usage of individual methods (rui). Note that the fixed usage component only

applies in the case of memory whereby an object has a portion of memory allocated to it that is

independent of the memory used by the methods of the object itself. However in the case of network and

processor, only the behaviour of the methods themselves impacts upon usage and thus the fixed

component is set to zero in both these cases.

mru

rurumi iFO ∑=+= 1 (2a)

where

• m: number of methods of the object

• ruF: fixed resource usage (independent of method usage)

• rui: resource usage of method i

muF = OMS, mui = EMS × NI (2b)

nuF = 0, nui = SSPi × NI/s (2c)

puF = 0, pui = NEIi × NI/s (2d)

Equation 2b shows that in the case of memory utilisation, the fixed usage component is defined by the

static object memory size (OMS), and the per method component by execution memory size (EMS).

Equation 2c shows that the network usage of each method call is defined by the size of serialised

parameters of the call (SSP) and the number of times the method is invoked per second (NI/s). Equation

2d is essentially the same but with number of executed instructions per second and its effect on processor

usage being the primary factor of interest. Note that in practice a function would be required to

approximate processing capacity (PC) in NEI/s for a given processor and virtual machine combination.

- 20 -

5.1.2. Empirical Evaluation

When applying the local adaptation models of the previous section, a reactive/adaptive decision is

typically triggered by the utilisation of a resource that at some point in time exceeds a predetermined

threshold. The objective of this adaptation is to distribute the utilisation of resources whilst maintaining

(or improving) performance.

However, performance and resource utilisation are attributes that generally conflict with each other

and since compromises may have to be reached, this decision is not trivial even for the simplest scenario

of two objects and two machines. Additionally, a more typical case may involve numerous application

objects and many nodes, and thus achieving an effective decision requires an appropriate process.

Therefore, in order to test the ability of our model to support such decision making, whilst yielding a

tangible benefit in terms of efficiency, an empirical study was conducted by deploying a prototype of a

Taxi Dispatching System (TDS) on the MobJeX framework [Ryan and Westhorpe, 2004]. The TDS

application (see Appendix) was chosen because it is simple enough to be described within this paper, but

complex enough in terms of its design, functionality and object topology, to provide meaningful

evaluation of the new metrics and models presented in this paper. Furthermore, the TDS application has

sufficient scope to suggest explicit directions for future work.

MobJeX was chosen since it directly represents the type of middleware to which the metrics and

models presented in this paper are aimed, and provides a working implementation of an object mobility

system, system controller and resource monitoring framework. For the TDS experiment, software metrics

were collected directly via instrumentation in the TDS code, whereas resource utilisation and performance

metrics were obtained via MobJeX.

The local adaptation decisions (which determine if and when a given object should migrate to another

host) were calculated offline with MobJeX supporting the adaptation via object migration where

necessary. Therefore, the intention of this experiment is not to evaluate the efficiency of the metric

collection and adaptation process itself, although this is the subject of ongoing work. Rather, this

- 21 -

experiment aims to demonstrate that the model and metrics presented herein can support the objective

placement of application objects to hosts in a distributed mobile application, in order to improve

efficiency compared with the baselines of no adaptation or random adaptation. Furthermore, neither was

the focus of this experiment the efficacy of a particular adaptation strategy tailored for a specific

application such as the TDS, but rather an exploratory or prima facie evaluation of the practical

application of metrics and derived models to a representative distributed application.

Figure 4. MobJeX administration console showing deployment of the TDS application

The experiment was conducted under the same laboratory conditions, using three machines of the

same specification, as described in section 4. Figure 4 is a screen shot of the administration console of

MobJeX, showing the TDS application loaded with its five mobile objects allocated onto three nodes

based on the algorithm presented in Figure 5 and evaluated in the rest of this section. The mobility

subsystem of MobJeX is presented in detail in [Ryan and Westhorpe, 2004] but is summarised here to

help illustrate the experimental procedure that was followed. Briefly, the [s] icon represents a service

- 22 -

(individual host), whilst the [r] and [t] components are object containers (runtime and transport manager

respectively) forming an intrinsic part of the mobility subsystem. The [m] components (mobjects) are

mobile objects, which can be transparently moved at runtime between hosts.

// load balance for varying rlk and rtk

do

set ruk

set rtk

// load balance for current rlk and rtk

do

// o is an object and n is a node

S = set of tuples <o, n, rld, rtd>

satisfying eq1 and eq2

if S = ø then

exit loop

else

if priority is rl then

s = tuple with maximum rld

else // priority is rt

s = tuple with maximum rtd

end if

migrate o(s) to n(s)

end if

while system-load unbalanced

while system-load unbalanced

Figure 5. Local Adaptation Algorithm

Figure 5 lists the high-level pseudo-code of the local adaptation algorithm based on equations 1 and 2

from the previous section. The basic operation involves two load balancing loops whereby rlk and rtk are

varied until a load balance is reached such that the difference in resource utilisation across nodes can no

longer be improved. This algorithm was applied to the TDS application, which started with all of the main

application objects on a single node. The application was then adapted (favoring rl in terms of memory

- 23 -

load over rt) by migrating objects to two other nodes until the balanced memory load state (in which

object migration could not improve the difference in memory load between nodes) was reached.

Note that the TDS application design, based on five main object classes (a location manager [lm],

client manager [cm], job manager [jm], taxi manager [tm], and user interface [ui]), was done using

established Object-Oriented techniques [Jacobson et al., 1999]. A brief description of the main scenarios

of the Taxi Dispatching System can be found in the Appendix.

Both the local and the random adaptation strategies began with all application objects residing on node

1, and thus no balance of memory load. Applying the local adaptation algorithm of Figure 5 to the no

adaptation case (where the initial state consisted of all of the objects on one node) involved three cases of

object migration, resulting in node 1 containing [ui] and [jm], node 2 [tm] and [lm], and node 3 [cm] —

see Figure 6. The random allocation was similar, with [ui] and [lm] residing on node 1, [cm] and [tm] on

node 2, and [jm] on node 3.

Figure 6. Object migration during adaptation

The maximum memory load difference was calculated for both the random object distribution as well

as the placement resulting from the application of the local adaptation strategy. Additionally, response

time data was collected for 14 usage scenarios with each executed and measured 100 times. The object

call graph of the scenarios spanned from 2 to greater than 10 method calls.

The maximum memory load difference between the three nodes in the random distribution was above

50% whereas the difference in the local adaptation version was under 25%. Of additional note, the

N2 N3

N1

cm

ui

jm

tm

lm

cm

- 24 -

average scenario response time for the local adaptation version was 504ms versus 845ms for random

adaptation. Therefore not only did the local adaptation algorithm provide better memory load balance,

which was the principal aim of this study, it also provided superior performance and thus greater

efficiency as well.

Thus in summary, although the local adaptation algorithm and the models on which it is based, are

relatively simple, they illustrate the benefit of applying the metrics of this paper to a practical application,

thus providing a basis for further large scale studies. Also, note that the performance improvement

compared with the baseline random adaptation was achieved in the least favourable situation of identical

resource capacities and similar resource usages, in which there is less flexibility in terms of adaptation,

thus again demonstrating a promising outcome. For a more detailed treatment of local adaptation based on

the metrics described in this paper, see [Rossi and Ryan, 2005]. The paper presents an empirical study

involving a more sophisticated local adaptation strategy based on a combined efficiency model that

evaluates both performance and resource utilisation tradeoffs at the same time using a weighted power

mean technique.

5.2. Global Adaptation

In contrast to local adaptation, which reactively responds to changes in application behaviour or the

environment by moving individual objects, global adaptation involves proactive analysis of the

application as a whole, with optimisation performed in terms of mapping objects or object clusters to

nodes for the entire application in a single pass. Whilst this strategy is likely to be expensive, it has the

potential to yield the greatest efficiency, and thus would be run at start-up, in periods of low application

activity, or on demand. Note that in practice, global adaptation and local adaptation are complementary

rather than mutually exclusive, and if combined appropriately, should give middleware systems greater

flexibility in terms of providing adaptation support for mobile applications.

Given the availability of information about the environment and the application, as provided by the

metrics specified in this paper, and given the desire to obtain an object placement that achieves optimal

- 25 -

efficiency, perhaps the most obvious global adaptation strategy is to develop an optimization model and

solve it. Doing so produces an optimal placement or allocation for the objects of a given application given

a specific set of nodes with a known capacity and monitored utilisation. As with the previous section on

local adaptation, separate models are provided for performance and resource utilisation.

5.2.1. Modelling Global Adaptation

Performance

This optimization model will minimise the sum of all method response times (performance) for all

possible application method call scenarios. The factors considered for optimising the response time of

different object layouts are the execution time and invocation time of all methods of all objects for all user

scenarios. The execution time of a method is dependent on its number of executable instructions and the

number of times it is invoked, while the invocation time of a method is dependant of the size of its

parameters and its number of invocations—assuming the calling object is not collocated. Therefore, the

objective function that we wish to minimize is:

∑=

+=N

n n

n

n

n tssptneiZ1 NCPC

, with

∑ ∑= ∈ ⎥

⎥⎦

⎤

⎢⎢⎣

⎡××=

O

o Mmmmnon

O

atnei1

, NINEI and

∑∑ ∑= = ∈ ⎥

⎥⎦

⎤

⎢⎢⎣

⎡×−=

O

o

O

o Mmmmnonon

OO

aatssp1 1'

,',',

* NISSP

(3)

subject to the following constraints:

1. Objects cannot be split across nodes, that is ao,n = 1 (if object o is allocated to node n) or ao,n = 0

(otherwise).

2. Each object is unique and it can run on only one node (no copies of the same object):

11 , =∑ =

N

n noa , o∀ (4)

- 26 -

3. Memory Usage by the objects cannot exceed the available capacity on each node:

nO

o ono omua MC≤×∑ =1 , , n∀ , with omuo = OMSo + max {EMSm| oMm∈ } (5)

where:

• Mo: the set of methods of object o;

• Mo,o’: the set of methods of object o invoked by object o’ ( ooo MM ⊆', );

• O: the number of application objects; and

• N: the number of network nodes.

As a simplification, since this model is concerned with performance rather than resource utilisation, it

considers the network and processor to be unlimited resources, leaving memory as the only constrained

resource. Note that memory could also be seen as an unlimited resource if we consider virtual memory,

but this would introduce additional complexity to the model since the overhead of paging would need to

be taken into account.

Resource Utilisation

If the application uses a private network then the network can generally be used to full capacity, but if

the application uses a public network, where each data packet has a monetary cost, then a model can be

proposed to minimise network communication among the application objects.

The optimization model will minimise the sum of network usage of all methods for all application

scenarios (equation 6). The first factor of the sum represents the amount of information exchanged by two

objects, while the second factor annuls the first factor if the two objects are located in the same node since

a local call is assumed and thus no network communication required. Therefore, the objective function

that we wish to minimize is:

∑∑ ∑= = = ⎥

⎥⎦

⎤

⎢⎢⎣

⎡

⎥⎥⎦

⎤

⎢⎢⎣

⎡ −×=

O

o

O

o

N

n

nonooo

aatsspZ

1 1' 1

',', 2

, with [ ]∑∈

×=',

',ooMm

mmootssp NISSP (6)

subject to the following constraints:

- 27 -

1. Objects cannot be split across nodes, that is ao,n = 1 (if object o is allocated to node n) or ao,n = 0

(otherwise).

2. Each object is unique and it can run on only one node (no copies of same object):

11 , =∑ =Nn noa , o∀ (7)

3. Memory Usage by the objects cannot exceed the available capacity on each node:

[ ] nOo ono omua MC≤×∑ =1 , , n∀ , with omuo = OMSo + max {EMSm | oMm∈ } (8)

where:

• Mo: the set of methods of object o

• Mo,o’: the set of methods of object o invoked by object o’ (Mo,o’ ⊆ Mo).

• O: the number of objects

• N: the number of nodes

As a simplification, the model assumes that all links have the same unitary cost, but it can be easily

extended to include different costs. Furthermore, since this model is concerned only with resource

utilisation, it does not include the potential constraint of a minimum level of performance. This constraint

would be part of an efficiency model which would combine performance and resource utilisation.

5.2.2. Evaluation

Since a global adaptation strategy based on an optimisation model was expected to be computationally

expensive, its empirical evaluation involved synthetic testing (as opposed to the application testing of the

local adaptation algorithm of the previous section). Therefore, in order to test the scalability of this

approach, object layouts of increasing size were created and tested, with the application and

environmental information generated randomly in order to represent a spectrum of operating conditions.

- 28 -

All these models were run through an optimization solver (LINGO6), which varied the location of the

objects on the different nodes to find the solution set that minimized the value of the objective function.

The models were computed on a 3GHz Pentium IV PC with the various solution times listed in Table 3.

Table 3. Time required to solve optimization problems as the number of variables grows

Model Variables Time (without initial solution) Time (with initial solution)

1 15 00h00m01.11s 00h00m00.50s

2 30 00h00m03.13s 00h00m13.67s

3 60 00h02m07.77s 00h03m19.89s

4 120 00h07m51.58s 00h15m43.95s

5 240 01h21m26.11s 01h42m59.27s

6 480 26h12m06.81s 09h11m04.16s

From the results in Table 3, it can be seen that only small models are suitable for online adaptation.

For example, a model of 120 variables represents the problem of allocating 15 object clusters to 8

machines or 20 objects to 6 machines. A model solved without an initial solution is representative of the

allocation of object clusters at start-up, which is performed offline, whereas a model solved with an initial

solution is representative of online reallocation. In each case, their solutions were computed in times of

similar order of magnitude, given the worst case scenario (i.e. all environment metrics changed). When a

new model is solved based on a previous solution, the time required to find a new solution decreases as

the number of changes in the environment decreases. It should be noted that the solution of the models

solved without initial values were used as the initial solution for the models solved with initial values.

6 LINGO is a solver for optimization models and it is a product of LINDO Systems, Inc (http://www.lindo.com).

- 29 -

5.2.3. Alternative Global Adaptation Strategies

Although the global adaptation strategy described in the previous section provides an optimal result, it

is computationally expensive and therefore not suitable for runtime adaptation of large applications

comprising many mobile objects. Consequently, this section proposes some alternative global adaptation

techniques which although may not produce such an optimal solution (as is also the case with local

adaptation), are still expected to provide significant gains in efficiency with relatively low computational

cost. Note that unlike the previous techniques these have not been implemented and tested and as such

should be considered primarily as suggestions for future work.

Genetic Algorithm

One possible heuristic strategy is a genetic algorithm [Haupt and Haupt, 1998] that provides good

results for large optimization problems in a reasonable time. The algorithm starts with a generation of

random solutions (individuals), which is reproduced until the offspring fitness can no longer be improved

or a specified stop criterion has been reached. An individual is composed of chromosomes representing

the allocation of a mobile object to a device, with the fitness of an individual being how well it meets the

optimisation criteria, which could for example include the models described in section 5.2.1. Individuals

are reproduced using different genetic operators such as chromosome mutation and crossover with a high-

level flow-chart of the algorithm shown in Figure 7.

The dominant consideration with respect to the processing time of the genetic adaptation algorithm is

the evaluation of the fitness of each individual in the population. Fortunately, this time-consuming

operation can be performed independently and thus performance could be improved by parallelization.

For example, subsets of each generation could be evaluated at separate processing nodes with each node

measuring the fitness of the local individuals.

- 30 -

Figure 7. Genetic algorithm flow-chart

Graph Based Approach

The first step in this approach is to generate a run-time dependency matrix (RDM) from the total

object graph of an application. This matrix captures the run-time interaction or coupling across objects. A

cell of the matrix represents the degree (or index) of co-locality dependence of a pair of objects, and at the

software level is a function of the code metrics SSP and NEI. As an example, Figure 8 depicts the RDM

of a simple application consisting of three objects, which represents, at the service or facade [Gamma et

al., 1994] level, a small distributed application based on a model/view/controller (MVC) approach

[Fowler, 2002].

O1 O2 O3

O1 - i12 i13

O2 i21 - -

O3 i31 - -

Figure 8. Object graph of a small OO application, and its corresponding RDM.

The second step is to apply a clustering technique [Jain et al., 1999; Kwok and Ahmad, 1999] to

partition the matrix so objects that are tightly coupled and thus have a high co-locality dependence

(according to the co-locality index) are grouped together. As an example, although our simple MVC

O3

O2

O1

Create Initial Population

Evaluate Fitness

Select Individuals

Reproduce Mutate Test Convergence

START END

- 31 -

application could be clustered in different ways as shown in Figure 9, there is a high probability that one

of the combinations would result in greater efficiency.

The final step is to map the clusters to nodes which could be done using a process similar to that

described by the local adaptation algorithm of section 5.1, however substituting cluster based variables

such as ruCL for object based variables such as ruO.

Figure 9. Two ways of clustering the same application.

6. SUMMARY AND CONCLUSIONS

Having recognised that distributed applications differ from their traditional centralised counterparts,

and that context-aware mobile applications are even more complex, this paper has introduced a suite of

metrics for such applications. Specifically, these metrics model the impact of software code attributes

upon performance and resource utilisation, in terms of memory, network, and CPU, in context-aware

mobile applications.

Having defined these metrics from a comprehensive and critical analysis of the problem domain, a

series of hypotheses relating the metrics were proposed and tested empirically using linear correlation

analysis. With the results demonstrating the impact of software code attributes on the efficiency of mobile

applications, more formal models in the form of mathematical equations were proposed, in order to

facilitate dynamic adaptation of mobile objects in a context-aware mobile application framework.

Preliminary empirical support for a local adaptation model was obtained by studying a practical

application, using a typical mobile system running on the MobJeX framework. More specifically the test

demonstrated that applying a local adaptation strategy resulted in application efficiency, in terms of

- 32 -

performance and resource utilisation, clearly exceeding that of a baseline random object distribution or no

distribution at all.

Finally, the scalability of an optimising global adaptation algorithm was measured using synthetic data

and test cases, demonstrating that while the results produced by this approach are useful for small

problems or for offline adaptation, an alternative heuristic approach may be more appropriate for medium

to large problems. For example, given the similarities between this problem and a traditional scheduling

problem we envisage that an approach using genetic algorithms [Haupt and Haupt, 1998] should provide

good results for large problems in a reasonable time.

6.1. Future Work

Although this paper has made a significant foray into an area that is not yet well understood, there are a

number of limitations and opportunities that remain to be explored in the future which include, but are not

limited to:

• Evaluation of the software code attributes and their associated metrics against other quality

attributes such as reliability.

• Analysis of additional resources such as mass-storage and power [Chen et al., 2004].

• Specification of heuristic global adaptation strategies such as those based on genetic algorithms or

clustering techniques.

• Integration of the adaptation models into the MobJeX framework, and the empirical evaluation of

their effectiveness.

• Evaluation of the run-time overhead of metrics collection and its impact on application efficiency

under MobJeX.

In closing, the present authors believe this paper to be one of the few reported empirical studies of

metrics for distributed software, and the first involving the specific case of adaptive context-aware mobile

- 33 -

applications. The results encourage further large-scale studies and it is expected that such a pursuit will

suggest modifications and improvements to the metrics suite as additional understanding is achieved.

7. APPENDIX

The Taxi Dispatching System (TDS) is intended to help an operator efficiently dispatch a fleet of taxis

or limousines in response to calls from corporate customers. The system records details of currently

working drivers and their present location, in order to control the allocation of taxis to incoming jobs.

Drivers interact with the system via a local device connected by a wireless link, or via mobile phone when

such a link is not available. In addition to immediately dispatching taxis in response to a customer call,

the system supports a booking operation, where the customer requests that a taxi be made available at

some time in the future. In this case, the system should dispatch a taxi automatically (without operator

intervention) at the appropriate time. The system calculates the charge for each job and updates the

customer account accordingly. Finally, the system maintains a list of customer accounts and manages the

periodic generation of invoices.

ACKNOWLEDGMENTS

This work is part of the Applications Program of the Australian Telecommunications Cooperative

Research Centre: http://www.atcrc.com/

REFERENCES

ARISHOLM, E., L. BRIAND, et al. (2004). "Dynamic coupling measurement for object-oriented software."

IEEE Transactions Software Engineering 30(8): 491-506.

BRIAND, L., S. MORASCA, et al. (1995). Theoretical and Empirical Validation of Software Product

Measures, International Software Engineering Research Network.

BRIAND, L. C., S. MORASCA, et al. (2002). "An operational process for goal-driven definition of

measures." Software Engineering, IEEE Transactions on 28(12): 1106-1125.

CARD, D. and R. GLASS (1990). Measuring software design quality, Prentice-Hall, Inc.

- 34 -

CHEN, G., B.-T. KANG, et al. (2004). "Studying energy trade offs in offloading computation/compilation

in Java-enabled mobile devices." Parallel and Distributed Systems, IEEE Transactions on 15(9): 795-

809.

CHENG, J. (1993). Complexity metrics for distributed programs. International Symposium on Software

Reliability Engineering, IEEE.

EMMERICH, W. (2000). Engineering Distributed Objects, Wiley.

FENTON, N. and S. PFLEEGER (1996). Software Metrics: A Rigorous and Practical Approach. London,

International Thompson Computer Press.

FLINN, J. and M. SATYANARAYANAN (1999). Energy-aware adaptation for mobile applications.

Symposium on Operating Systems Principles, Kiawah, Island, ACM.

FOWLER, M. (2002). Patterns of Enterprise Application Architecture, Addison-Wesley.

FREUND, R. and W. WILSON (1998). Regression Analysis: Statistical Modeling of a Response Variable,

Academic Press.

GAMMA, E., R. HELM, et al. (1994). Design Patterns: elements of reusable object-oriented software.

Massachusetts, USA, Addison Wesley Longman, Inc.

GAZIT, H., I. BEN-SHAUL, et al. (2000). Monitoring-based dynamic relocation of components in Fargo.

nternational Symposium on Agent Systems and Applications and Fourth International Symposium on

Mobile Agents, Springer-Verlag.

GRADY, R. and D. CASWELL (1987). Software Metrics: Establishing a Company-wide Program, Prentice-

Hall.

HAUPT, R. and S. HAUPT (1998). Practical Genetic Algoritms. New York, John Wiley & Sons.

ISO/IEC (2003). Information Technology - Software Product Quality - Part 1: Quality Model. Geneva,

International Standards Organisation.

JACOBSON, I., G. BOOCH, et al. (1999). The Unified Software Development Process. Reading,

Massachusetts, Addison-Wesley.

- 35 -

JAIN, A. K., M. N. MURTY, et al. (1999). "Data Clustering: A Review." ACM

Computing Surveys 31(3).

JING, J., A. HELAL, et al. (1999). "Client-Server Computing in Mobile Environments." ACM Computing

Surveys 31(2): 118-157.

KWOK, Y.-K. and I. AHMAD (1999). "Static Scheduling Algorithms for Allocating Directed Task Graphs

to Multiprocessors." ACM Computing Surveys 31(4).

MCGOVERN, J. and C. RYAN (2004). Adaptive Consistency Management Support for Limited Capacity

Devices in Ad-hoc Mobile Networks. International Symposium on Collaborative Technologies and

Systems, San Diego, USA, SCS.

MCGREGOR, J., I. CHO, et al. (1999). "Collecting metrics for CORBA-based distributed systems."

Empirical Software Engineering 4: 217-240.

MORASCA, S. (1999). Measuring attributes of concurrent software specifications in Petri nets. Sixth

International Software Metrics Symposium.

NOBLE, B., M. SATYANARAYANAN, et al. (1997). Agile application-aware adaptation for mobility.

Symposium on Operating Systems Principles, Saint-Malo, France, ACM.

ROSSI, P. and G. FERNANDEZ (2003). Definition and validation of design metrics for distributed

applications. Ninth International Software Metrics Symposium, Sydney, IEEE.

ROSSI, P. and G. FERNANDEZ (2004). Design Measures for Distributed Information Systems: an Empirical

Evaluation. International Workshop on Software Audit and Metrics (In conjunction with ICEIS),

Porto.

ROSSI, P. and C. RYAN (2005). An Empirical Evaluation of Dynamic Local Adaptation for Distributed

Mobile Applications. Proc. of 2005 International Symposium on Distributed Objects and Applications

(DOA 2005), Larnaca, Cyprus, Springer-Verlag.

RUHE, M., R. JEFFERY, et al. (2003). Using Web objects for estimating software development effort for

Web applications. Ninth International Software Metrics Symposium.

- 36 -

RYAN, C. and C. WESTHORPE (2004). Application Adaptation through Transparent and Portable Object

Mobility in Java. International Symposium on Distributed Objects and Applications (DOA 2004),

Larnaca, Cyprus, Springer-Verlag.

SHATZ, S. (1988). "Towards Complexity Metrics for Ada Tasking." IEEE Transactions Software

Engineering 14(8): 1122-1127.

SILVA, F., M. ENDLER, et al. (2003). Developing Adaptive Distributed Applications: A Framework

Overview and Experimental Results. CoopIS/DOA/ODBASE (LNCS 2888), Springer.

SPSS, I. (1998). SPSS 8.0: User Guide. Chicago, SPSS Inc.

TSUAR, W. and S. HORNG (1998). "A New Generalised Software Complexity Metric for Distributed

Programs." Information and Software Technology 40(5-6): 259-269.