Static Consistency Checking of Web Applications with WebDSL Modern web application development frameworks provide web application developers with highlevel abstractions to improve their productivity. However, their support for static verification of applications is limited. Inconsistencies in an application are often not detected statically, but appear as errors at run-time. The reports about these errors are often obscure and hard to trace back to the source of the inconsistency. A major part of this inadequate consistency checking can be traced back to the lack of linguistic integration of these frameworks. Parts of an applications are defined with separate domain-specific languages, which are not checked for consistency with the rest of the application. Examples include regular expressions, query languages and XMLbased languages for definition of user interfaces. We give an overview and analysis of typical problems arising in development with frameworks for web application development, with Ruby on Rails, Lift and Seam as representatives.To remedy these problems, in this paper, we argue that domain-specific languages should be designed from the ground up with static verification and cross-aspect consistency checking in mind, providing linguistic integration of domain-specific sub-languages. We show how this approach is applied in the design of WebDSL, a domain-specific language for web applications, by examining how its compiler detects inconsistencies not caught by web frameworks, providing accurate and clear error messages. Furthermore, we show how this consistency analysis can be expressed with a declarative rule-based approach using the Stratego transformation language. Web applications are complex software systems that combine many technical concerns, such as database querying, input handling, user interface design, and navigation. Web application frameworks are often used to simplify web development and improve web developer productivity. A web framework consists of a set of APIs built on a generalpurpose programming language. Popular web frameworks include JBoss Seam, Lift, Ruby on Rails, and Django. These frameworks enable abstraction over many low-level details of normal web application development, avoiding handwritten boilerplate code, thus increasing developer productivity.. While web frameworks improve the clarity of the application and expressivity of developers that use it, applications containing inconsistencies (faults) often fail late, i.e. at run time or deployment time instead of at compile time. Even inconsistencies in applications written using a framework based on a statically typed language such as Java or Scala are often only revealed at deployment time or at run time. The errors produced when the application fails are often difficult to trace back to their origin and error messages are typically not domain-specific, exposing framework implementation details. A summary of our results is shown in Fig. 2 . Rather than tally the specific scores of the individual frameworks, we conclude that there are many cases where errors are not reported at the earliest possible opportunity, where errors are not easily traceable to their source, and where error messages are unclear or confusing. In the next section we discuss reasons in the design and implementation of the frameworks that cause these deficiencies.. Providing accurate, static checks at compile-time avoids failures at deployment-time or at run-time. Statically detected faults do not require failure-to-fault tracing and can be reported directly inside an IDE. Still, there are many classes of faults that are not statically detected by the frameworks in our survey. Reasons for this include that they use reflection and run-time code manipulation techniques, linguistically separated languages, and can only use static typing provided in the base language compiler. Instead, many faults are reported at run time, introducing a (small) performance penalty and often resulting in errors that are vague or hard to trace back to their originating fault.. We have illustrated how a language design that integrates sub-languages covering different (technical) domains allows checking of their consistent use. A key property of the language design is to choose explicit representations of elements, instead of programmatic encodings; e.g. explicit page references instead of string manipulation to construct URLs make it possible to check that only links to existing page definitions are created.. Given such a language design, the verification of the consistency of a web application can be expressed using declarative consistency checking rules comprising of name resolution, type analysis, and check rules composed by strategies. While the WebDSL compiler checks a lot of properties, it is not yet complete. WebDSL applications are not currently guaranteed to produce validating HTML, for instance. This is something we intend to investigate. Also, declarative rules could describe nesting restrictions of user-defined templates.. WebDSL is optimized for the construction of form-based interactive web information systems. It is currently not very well suited for building applications that mainly rely on heavy client-side JavaScript work. Improving support in this area will provide an opportunity for verification of Rich Internet Applications.. We also intend to investigate how we can further simplify the definition of compilers with static verification in Stratego, e.g. by even more declaratively defining scoping rules. In this paper we demonstrated that timely, accurate and adequate error reporting is problematic in current state-of-practice web frameworks, such as Ruby on Rails, Lift and Seam. While certain frameworks report some application inconsistencies at compiletime, many are only discovered later, at deployment or run time. The lack of consistency checking in otherwise statically checked languages can be contributed to the linguistic separation of these frameworks. Aspects of the applications are defined in separate DSLs whose consistency is not checked with the rest of the application.. In this paper we argued that DSLs should be designed from the ground up to enable static verification by linguistically integrating its sublanguages. Based on static verification and linguistic integration, the WebDSL language provides consistency checks that are reported at compile-time, can directly be traced back to their source, and provide clear, domain-specific error messages. We showed examples of error messages given by the WebDSL compiler. Subsequently we detailed the architecture and implementation of a consistency checker for a simplified version of the WebDSL language.

O B I O O O O O O B I I O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B I O O O B I O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Perspectives and challenges in nanoscale device modeling In this paper, we discuss the role of adequate modelling tools in the development of nanoelectronic technology and devices, including both down-the-roadmap Complementary Metal-Oxide-Semiconductor (CMOS) technology and alternative nanodevices. Such tools can enable understanding of the relevant physical mechanisms on the one hand, and performance evaluation and optimization of device structures, on the other hand. Relevant examples are discussed, drawn by our recent activity, including ballistic strained-silicon Metal-Oxide-Semiconductor Field-Effect-Transistors (MOSFETs), stress-induced leakage currents, nanocrystal memories, and silicon nanowire transistors. q I would like to focus on the following question: what should technology developers reasonably expect from device modelling? The answer is not obvious, since typically Technology Computer Aided Design (TCAD) tools-including both process and device simulators-are accurate, or 'predictive', only for a sufficiently stable and 'mature' technology, and after a lengthy calibration procedure [1] . This poses the issue of the relevance (or irrelevance) of device modelling for the development of a new technology node, in which new processes and/or materials are introduced, that are not under complete control until the technology is finally released, and for which doping profiles and geometry are not known with sufficient accuracy. Such problems become even more serious for nanoscale MOSFETs and alternative nanodevices, whose electrical properties are extremely sensitive to the presence of single defects and impurities, and to the finest details of the geometry.. I do not want to shed a negative light on TCAD. The positive aspect is that device modeling can be very useful even if it is not fully 'predictive', because it can still provide optimization guidelines, explanations of the characterization results, and insights of the transport mechanisms. Let me underline the fact that in many cases, even for just reproducing the qualitative behaviour, it is necessary to implement a very sophisticated and specific models.. In the following, I will show a few examples of significant insights that can be gained from detailed simulations of nanoscale devices, both 'secular' MOSFETs and alternative structures. Examples will be drawn from recent activities pursued at the University of Pisa and will only briefly mentioned here. The reader interested in a more complete description of the examples is referred to the cited papers. In this paper, I have presented a few issues in which detailed physical modelling of nanoscale devices can provide very useful insights of device behaviour, helping us to understand what are the physical aspects that are relevant to particular issues, what are the main trends, and on which aspects we have to focus in order to improve device behaviour. This can be the critical mission of nanoscale device modeling, requiring not huge do-it-all tools, but simulation tools with different degrees of sophistication, tailored to the particular problem at hand. The realm of 'predictive' simulation tools will probably be limited to mature technology and brute force calibration, and the problem of 'yesterday's technology modelled tomorrow' [1] will probably remain unsolved for quite some time.. I would like to extend these considerations to modelling and simulation of micro-and nanosystems, that represent the main focus of the European Micro and Nanotechnology Conference. In this domain, advanced modeling tools are even less used, probably because a complete tool would be even more complicated, the developers being forced to include multiple physical mechanisms. Also in this case, I believe the focus of modelling tools should be on solving very specific problems, and not on building the ultimate TCAD tool. In such a way, one can really provide precious inputs to technology developers, and-in time-build the appropriate hierarchy of abstraction levels that can lead to versatile and effective modelling tools.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Interactive

translation

prediction

versus

conventional

post-editing

in

practice:

a

study

with

the

CasMaCat

workbench

We

conducted

a

field

trial

in

computer-assisted

professional

translation

to

compare

interactive

translation

prediction

(ITP)

against

conventional

post-editing

(PE)

of

machine

translation

(MT)

output.

In

contrast

to

the

conventional

PE

set-up,

where

an

MT

system

first

produces

a

static

translation

hypothesis

that

is

then

edited

by

a

professional

(hence

"post-editing"),

ITP

constantly

updates

the

translation

hypothesis

in

real

time

in

response

to

user

edits.

Our

study

involved

nine

professional

translators

and

four

reviewers

working

with

the

web-based

CasMaCat

workbench.

Various

new

interactive

features

aiming

to

assist

the

post-editor/translator

were

also

tested

in

this

trial.

Our

results

show

that

even

with

little

training,

ITP

can

be

as

productive

as

conventional

PE

in

terms

of

the

total

time

required

to

produce

the

final

translation.

Moreover,

translation

editors

working

with

ITP

require

fewer

key

strokes

to

arrive

at

the

final

version

of

their

translation.

Contemporary

professional

translators

rarely

produce

translations

entirely

from

scratch.

Instead,

they

increasingly

rely

on

translation

memories

(TM)

that

is,

data

bases

of

texts

that

have

already

been

translated,

and

their

translations.

At

translation

time,

translations

of

text

fragments

similar

to

the

actual

source

text

are

retrieved

from

the

data

base

and

edited

by

the

translator

to

bridge

the

mismatch

between

retrieved

text

fragments

and

an

actual

correct

translation

of

the

current

source

text.

As

the

quality

of

the

raw

output

of

fully

automatic

machine

translation

(MT)

systems

is

on

the

rise,

so

is

the

commercial

interest

in

integrating

MT

as

an

alternative

or

supplement

to

traditional

TMs

into

the

professional

translation

workflow.

Recent

studies

(Koehn

Flournoy

and

Duran

Plitt

and

Masselot

Federico

et

al.

Green

et

al.

have

concluded

that

post-editing

is,

on

average,

more

efficient

than

translating

from

scratch.

However,

the

optimal

form

of

human-computer

interaction

in

the

context

of

translation

is

still

an

open

research

question..

The

open-source

project

CasMaCat

addresses

two

needs

in

this

area:

first,

it

provides

a

new

post-editing

workbench

for

professional

translators

that

is

unobtrusive,

yet

provides

support

to

the

translator

when

it

is

relevant

to

do

so;

and

second,

it

is

able

to

log

user

activity

in

detail

and

thus

record

research

data

that

can

shed

light

on

the

mental

processes

underlying

human

translation

in

a

computer-assisted

translation

(CAT)

setting..

CasMaCat

builds

on

the

open-source,

web-based

post-editing

tool

MateCat

and

adds

several

major

capabilities

to

the

framework:.

It

offers

interactive

translation

prediction

(ITP;

Barrachina

et

al.

as

an

alternative

to

classical

post-editing.

The

ITP

functionality

used

in

this

study

has

been

implemented

by

means

of

the

Thot

toolkit

for

statistical

MT

(Ortiz-Martínez

and

Casacuberta

Various

auxiliary

features

and

customisations

have

been

implemented

to

help

tailor

the

MateCat

tool

to

the

individual

translator's

preferences.

They

are

described

in

Sect.

CasMaCat

can

log

user

activity

in

detail

and

with

precise

timing

information:

key

strokes,

mouse

activity,

and

translator's

gaze

(if

used

in

combination

with

an

eye

tracker).

Without

eye

tracking,

the

tool

can

be

easily

deployed

in

a

web

browser,

eliminating

the

need

for

specialised

hardware

or

software

to

run

experiments.

The

logs

from

the

user

study

discussed

in

this

paper

are

available

online

for

further

analysis

at

CasMaCat

can

be

used

with

an

e-pen

as

an

alternative

input

device

(Alabau

et

al.

Such

an

interface

is

comfortable

and

effective

in

a

number

of

situations.

First,

it

is

suited

for

post-editing

sentences

with

only

few

errors,

as

it

is

often

the

case

for

sentences

with

strong

fuzzy

matches

in

TM,

or

during

revision

of

human

post-edited

sentences.

Second,

it

allows

to

perform

such

tasks

while

commuting,

travelling

or

away

from

the

desk

for

other

reasons.

The

e-pen

interface

is

also

able

to

recognise

gestures

for

interactive

text

editing,

using

a

highly

accurate,

high-performance

gesture

recogniser

(Leiva

et

al.

We

have

presented

results

of

a

comparative

evaluation

of

two

ITP

systems

versus

conventional

PE

in

a

professional

setting.

The

first

("ITP")

provides

only

text

prediction;

the

second

("AITP")

offers

additional

functionality

designed

to

aid

the

translator/editor

in

the

translation

and

post-editing

process.

Our

results

show

that

the

ITP

system

accomplishes

what

it

was

designed

to

do:

ITP

minimises

the

number

of

key

strokes

required

to

generate

the

translations.

Nevertheless,

the

translation

time

per

segment

was

slightly

higher

in

ITP

mode

than

in

conventional

PE

mode.

However,

depending

on

how

processing

times

were

measured,

the

difference

was

small:

according

to

the

Fdur

measure,

processing

in

ITP

mode

took

only

longer

than

conventional

PE.

Our

findings

also

suggest

that

certain

types

of

users

may

benefit

more

from

ITP

as

their

familiarity

with

this

mode

of

processing

increases.

In

contrast,

the

processing

time

results

were

worse

for

the

AITP

system.

This

suggests

that

some

of

the

advanced

features

that

were

incorporated

might

not

be

useful

to

increase

user

productivity.

However,

we

should

keep

in

mind

that

more

complex

systems

may

have

a

steeper

learning

curve.

Considering

that

translators

were

already

experienced

post-editors,

we

may

suspect

a

slight

experimental

bias

in

favour

of

conventional

PE

in

the

way

the

study

was

set

up.

To

reduce

the

influence

of

familiarity

versus

novelty,

a

respective

study

would

have

to

be

longitudinal,

observing

translator/editor

performance

and

interaction

with

the

tool

over

extended

periods

of

time..

The

analysis

presented

in

this

paper

aggregates

results

for

the

different

system

configurations

across

users

and

text

segments.

A

logical

next

step

is

to

look

in

more

detail

at

the

individual

editors

and

texts

in

order

to

determine

factors

that

determine

which

mode

of

editing

works

best

for

whom

under

which

conditions.

Improving

the

productivity

of

translators

is

and

has

been

a

major

driver

of

MT

research.

The

hope

is

that,

in

many

cases,

post-editing

MT

output

will

help

translators

to

perform

their

work

faster.

Several

studies

were

performed

to

evaluate

the

potential

benefit

with

generally

positive

results.

Measured

reductions

in

translation

time

typically

range

somewhere

between

and

(Flournoy

and

Duran

Guerberof

Federico

et

al.

sometimes

even

reaching

as

high

as

(Plitt

and

Masselot

The

various

studies

differ

in

numerous

parameters,

which

makes

direct

comparisons

difficult:

-translator's

level

of

experience:

volunteer/student

(Koehn

versus

professionals

(Plitt

and

Masselot

Guerberof

-suitability

of

the

MT

system,

especially

when

comparing

older

(Krings

and

more

recent

(Plitt

and

Masselot

studies;

-the

PE

interface

and

subjects'

familiarity

with

it;

-language

pairs

and

text

domain;

-the

way

the

data

were

collected

and

filtered..

Another

question

that

has

been

addressed

is

how

post-editing

fares

in

comparison

to

translation

from

scratch

in

terms

of

final

translation

quality.

Koehn

found

that

non-professionals

are

generally

both

faster

and

produce

better

translations

when

post-editing,

a

result

that

is

consistent

with

later

work

by

Plitt

and

Masselot

as

well

as

Green

et

al.

showing

a

strong

reduction

in

translation

time

and

a

lower

error

rate

for

professional

translators

as

well.

Interestingly,

Plitt

and

Masselot

also

found

that

the

difference

between

individual

translators

is

much

stronger

than

between

language

pairs

and

MT

systems

of

varying

quality.

Following

this

work,

Skadiņš

et

al.

observed

(slight)

negative

effects

of

the

post-editing

setting

for

both

productivity

and

quality

for

some

translators

but

still

affirm

the

overall

helpfulness

of

MT

suggestions..

Along

with

the

MT

systems,

PE

environments

have

developed

over

time,

recently

converging

towards

web-based

setups

(Koehn

Green

et

al.

which

integrate

several

aids

in

a

single

interface.

Despite

extensive

research

on

Confidence

Estimation

for

MT,

such

annotation

has

yet

to

be

integrated.

Bach

et

al.

for

example,

suggested

visualising

word-level

confidences

by

type

size..

Besides

quantity

and

quality,

the

translation

process

itself

has

been

studied

for

many

years,

starting

with

explicit

collection

of

translators'

thoughts

using

Think

Aloud

Protocols

(Krings

Possible

interference

with

the

translation

process

quickly

led

to

passive/indirect

collection

of

user

activity

such

as

the

logging

of

keystrokes

and

mouse

movement

(Langlais

et

al.

and,

more

recently,

gaze

data

(O'Brien

Doherty

et

al.

Carl

By

presenting

multiple

languages

simultaneously

in

an

ecologically

valid

environment,

the

combination

of

workbench

and

logging

functions

also

offers

a

unique

opportunity

to

investigate

broader

issues

of

applied

bilingual

cognitive

processing.

B I I O O B O O O O O O O O O O O B I O O O O O O B I I O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O B I I O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Sequential decision making with partially ordered preferences : Sequential decision making under uncertainty Partially ordered preferences Sets of probability measures Criteria of choice Consequentialist and resolute norms Linear and multilinear programming This paper presents new insights and novel algorithms for strategy selection in sequential decision making with partially ordered preferences; that is, where some strategies may be incomparable with respect to expected utility. We assume that incomparability amongst strategies is caused by indeterminacy/imprecision in probability values. We investigate six criteria for consequentialist strategy selection: Γ -Maximin, Γ -Maximax, Γ -Maximix, Interval Dominance, Maximality and E-admissibility. We focus on the popular decision tree and influence diagram representations. Algorithms resort to linear/multilinear programming; we describe implementation and experiments. It is often possible, in a decision problem, to express preferences that are completely ordered; that is, for every two alternatives, the decision maker either prefers one to the other, or is indifferent between them. In fact, expected utility theory is based on the assumption that revealed preferences are completely ordered. However, preferences are often partially ordered; examples can be found in the theory of CP-nets and the theory of nondeterministic planning, as briefly discussed in Section 2. When preferences are partially ordered, two alternatives may be incomparable and incomparability may fail to be transitive.. In this paper we focus on preferences that can be represented by a single utility function and a set of probability measures. Whenever there are incomplete or partial beliefs, or disagreements amongst experts concerning chances, one may fail to assign a precise probability value to every event, thus producing a partial order with respect to expected utility [3, 46, 73] . This is the situation we wish to focus on. Section 2 contains the necessary background on these topics.. The literature describes many criteria of choice when preferences are partially ordered [71] . These criteria are covered in Section 3 and can be roughly divided into two groups: (1) criteria that enforce a complete ordering amongst choices (Γ -Maximin, Γ -Maximax and Γ -Maximix); and (2) criteria that select a set of incomparable actions (Interval Dominance, Maximality and E-admissibility). Practical approaches to decision making with sets of probabilities have been mainly limited to the first category; however, recent discussions [60] have highlighted theoretical and behavioral problems when using this group of criteria, and the second group of criteria has been advocated as a more adequate approach. Nevertheless, incomparability comes at a cost, and very little has been observed in the literature in terms of algorithmic progress, mainly due to computational complexity and inability to deal with incomparable choices.. There are also distinct behavioral norms when it comes to sequential decision making with partially ordered preferences; that is, whenever a sequence of decisions must be made. For instance, a decision maker may be resolute in that she commits herself to a complete strategy once and for all, or consequentialist in that she allows herself to change the current strategy in case another one is appropriate in view of the future possible choices.. The interplay between criteria of choice, behavioral norms, and models such as decision trees and influence diagrams has not been explored in the literature; this paper aims at filling this gap to some extent. There are indeed insights to be learned from an organized discussion of criteria of choice and behavioral norms; for instance, we discuss in Section 5 the fact that the standard LIMID model clashes with a consequentialist stance.. Another, more substantial, contribution of the paper is the development of algorithms for consequentialist sequential decision making expressed through decision trees [56] and influence diagrams [34] . Algorithms for decision making under Γ -Maximin and similar criteria have appeared in many settings [58, 69, 74] , while algorithms for decision making under. Maximality and E-admissibility have been suggested by Kyburg and Pittarelli [43] and proposed more recently by Kikuti et al. [42] and Utkin and Augustin [72] . 1 Section 3 presents algorithms and computational analysis for several criteria of choice. The most valuable contribution of Section 3 is the algorithm for E-admissibility. We also present a new algorithm for strategy selection using linear programming in a family of decision trees where partial preferences have considerable regularity. Sections 4 and 5 respectively present algorithms for decision making in problems specified through decision trees and influence diagrams. We should note the scarcity of previous literature on influence diagrams under partially ordered preferences, perhaps due to the fact that several criteria of choice require the manipulation of an exponential number of strategies. To reduce this complexity, we examine "ordered" LIMIDs, and we analyze both their conceptual foundation (in particular their clash with consequentialism) and their computational properties.. In short, we present novel results and algorithms for sequential decision making with decision trees and influence diagrams, plus new insights for single-stage decision making under Interval Dominance and E-admissibility. The broader goal of the paper is to combine both the philosophical underpinnings and the computational properties of partially ordered preferences, a combination we feel is missing in the current literature. This paper has examined the selection of strategies in sequential decision making when preferences are partially ordered. In particular, we have focused on preference patterns that are encoded through a single utility and a set of probability measures. A partial order over strategies introduces subtle ingredients into the decision problem, as we have several criteria of choice and behavioral norms, episodes of incoherent/inconsistent choice, and varying degrees of computational gain. We have tried to shed some light into these matters from a consequentialist perspective, and to present algorithms that select strategies by solving sequences of optimization programs. Most algorithms employ multilinear programming, and some particular cases can be tackled by linear programming. Clearly, algorithms based on multilinear programming can be adapted to handle interval-valued utility, as we then have products between probabilities and utilities that must be optimized over; we have refrained from discussing interval-valued utility so as to limit the length of the paper.. The current literature on sequential decision making with partially ordered preferences can be roughly divided in two streams. The philosophical debate tends to favor abstract comparisons amongst criteria and norms, with little consideration of computational costs. On the other hand, if one looks at techniques that do involve decision making with partially ordered preferences, such as nondeterministic planning and CP nets, and even the theory of LIMIDs, one finds detailed study of computational costs but little attention to criteria, norms, and consistency. We hope that this paper strikes some needed balance between conceptual discussion and computational development, and helps shorten some of the gaps between these viewpoints. In particular we believe that the effect of the consequentialist perspective is currently not appreciated in the artificial intelligence literature, exactly where this norm is most adequate as one must deal with bounded agents.. We can summarize our contributions as follows. We have first derived new algorithmic techniques for Interval Dominance and E-admissibility (using insights by Kyburg and Pittarelli [43] , as done independently by Utkin and Augustin [72] ). We also presented a brief analysis of incoherent choice with Interval Dominance. More importantly, we have studied decision trees with partially ordered preferences, by presenting a consequentialist backward induction framework with multilinear and linear programming instantiations, and by noting that different criteria do affect the computational properties of backward induction. We have then applied these insights to influence diagrams, and actually to ordered LIMIDs, where the technology of credal networks (d-separation and multilinear programming) is used as much as possible. We have also presented experiments with a complete implementation of the algorithms for influence diagrams. Given the lack of literature on influence diagrams with indeterminacy and imprecision in probability values, our results are a first step in understanding this powerful but intricate model. We have noted already that recently Huntley and Troffaes [35] and de Campos and Ji [19] have presented specialized algorithms respectively for Maximality in decision trees and for Γ -Maximax in influence diagrams, that can be more efficient than the algorithms discussed in this paper in particular problems.. An important subject this paper has not tackled is Markov Decision Processes (MDPs). MDPs are probably the most prominent model for sequential decision making under uncertainty in use in artificial intelligence today, and could likewise benefit from partial preference orderings. It should be noted that the initial translation into the framework of MDPs is not difficult, in fact there is a considerable amount of publications that deal with MDPs with sets of probability (usually referred to as Markov Decision Processes with Imprecise Probabilities) [33, 58, 74] . The topic deserves an investigation of its own; additionally, there are many questions that must be answered before partial preferences can be extensively used in MDPs, such as how to deal with act-state dependence and how to choose between the set of incomparable choices suggested by criteria such as Maximality and E-admissibility.. We certainly leave many avenues for future exploration. A necessary next step is a detailed empirical characterization of computational effort in solving decision trees and influence diagrams, including a comparison between multilinear and linear programming schemes whenever the latter are possible. It would also be important to characterize the class of influence diagrams that can be solved through reduced programs (that is, programs that deal with small subsets of chance and decision nodes, passing back interval-valued expected utility). There are also conceptual questions that deserve further scrutiny, as there are other criteria of choice and behavioral norms besides the ones investigated in this paper. Even within the scope of criteria discussed in this paper, there are questions to answer. For instance: we have produced algorithms that compute all E-admissible strategies; perhaps in practice one should be content with just one E-admissible strategy?

O O O O B I I O B I I I I B I I B I I I B I I B I I I B I I I O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Impact analysis of database schema changes We propose static program analysis techniques for identifying the impact of relational database schema changes upon object-oriented applications. We use dataflow analysis to extract all possible database interactions that an application may make. We then use this information to predict the effects of schema change. We evaluate our approach with a case-study of a commercially available content management system, where we investigated 62 versions of between 70k-127k LoC and a schema size of up to 101 tables and 568 stored procedures. We demonstrate that the program analysis must be more precise, in terms of context-sensitivity than related work. However, increasing the precision of this analysis increases the computational cost. We use program slicing to reduce the size of the program that needs to be analysed. Using this approach, we are able to analyse the case study in under 2 minutes on a standard desktop machine, with no false negatives and a low level of false positives. Databases are widely used to store, query and update large data sets. Database management systems (DBMSs) are designed to address the complex issues that arise when providing persistence of data, such as concurrent access and efficient execution of complex queries over large datasets. It is often cost-effective to use general purpose DBMSs rather than application specific solutions and for this reason, many modern software applications rely on DBMSs.. A database schema defines the data structure of a database. If the system requirements change, the database schema may require changes, most commonly requiring additional information and relationships to be stored [27] . As more information is added, and as the schema becomes more complex the level of coupling and dependency between application and database increases. This level of coupling may become problematic when the database schema requires changes.. The effects of database schema change upon applications is currently often estimated manually by application experts [2] . Assessing these effects manually is both fragile and difficult [17] , and can be frequently incorrect [20] . Moreover impact analysis from code inspections can be prohibitively expensive [22] . Therefore, in this paper we address the problem of assessing the effects of database schema change in a more reliable and cost-effective way.. Relational DBMSs are currently the most popular type of DBMS [6] . At the same time applications that create, update and query data in such enterprise applications are often written using object-oriented programming languages, such as C++, Java and C#. This results in the so-called impedance mismatch problem, which denotes the significant conceptual gap between object-oriented applications and relational databases. This mismatch complicates impact analyses because many of the techniques used to help overcome the mismatch complicate program analyses.. We present an approach for predicting the impact of relational database schema changes upon object-oriented applications. The main contribution of this paper is the presentation of techniques to extract dependency relationships between applications and database schemas, which are suitably precise for the purpose of impact analysis but still computationally feasible. The precision of our analysis comes from using a recognised k-CFA contextsensitivity [26] , but with a higher value of k than used in previous related work. We reduce the computational cost by reducing the size of the original program through program slicing. Our implementation of both program slicing and dataflow analysis is built using Microsoft's Phoenix framework [21] . We then use the results of the dataflow analysis to reason about dependency relationships, and we use CrocoPat [4] for the final impact calculation. We evaluate our approach using a commercial content management system as a case study. We have considered a version history of two years, which had 62 different versions of the schema with corresponding application changes. We have used our implementation to analyse the three versions with the most significant changes. The version we present in this paper has 78 kLOC of C# with 417 ADO.NET invocations each of which may perform multiple queries or call multiple stored procedures. The case study shows that the precision of the dataflow analyses in related work are insufficient and also, that our combination of program slicing with a precise k-CFA dataflow analysis, produces accurate and precise results in under 2 minutes on a standard desktop machine.. The paper is further structured as follows. In Section 2, we give a motivating example and describe the common data access practices for which such analyses are significant. We describe our approach n Section 3 and its implementation in Section 4. In Section 5, we present the results of the case study. We describe related work in Section 6 and we discuss the main findings in Section 7. We conclude the paper in Section 8. We have investigated the problem of analysing the impact of database schema changes upon object-oriented applications. We found that current string analysis techniques, whilst useful in other areas, require an increase in context-sensitivity in order to be useful for impact analysis. This increase in precision could have a vastly increased computational cost. To counter this, we reduce the parts of the program to which the analysis is applied with program slicing. We have demonstrated the feasibility of this approach by applying our analysis to a case study of significant size.. Our case study uses recommended and widely accepted architectural patterns and software engineering practices. We argue that because these architectures and techniques are in widespread use our results are generalisable to other similar enterprise applications.. In future research we hope to investigate alternatives to program slicing for reducing the cost of the dataflow analysis, and how the availability of impact analysis techniques may affect the development of database applications. The major interesting result of our work is that program analysis of database queries, may not be as simple as it would initially seem. The problem of string analysis for queries has been admirably studied in related work. However, as illustrated by our motivating example, and confirmed by our case study, we have found that these existing techniques require increased precision in order to be useful for our purposes, which comes at an additional computational cost. We claim that this cost can be reduced by using a dependency analysis such as program slicing. There is a great deal of work related to software change impact analysis [3, 23, 17] . However, we are only aware of one similar project that focussed on impact analysis of database schemas [16] . This earlier work focuses on object-oriented databases whereas we consider relational databases. We argue that the object-relational impedance mismatch makes this a significantly different problem, however we take inspiration from the approach defined here, especially the work on visualisation of results, which we do not currently address.. There have been a number of recent works investigating program analysis techniques for extracting database queries from applications. Amongst these were two important papers which initially inspired our work. Firstly the string analysis of Christensen et al. and secondly, the dynamic query type checker of Gould et al. [12] , both of which we discussed in Section 3. We also discussed the string analysis of Choi et al. [7] , the basis of our own query analysis.. Although we have only discussed k-CFA as a way of implementing a context-sensitive dataflow analysis, there are alternatives [18] . Such alternatives need to make sure that they also provide the ability to associate query definitions, executions and the use of query results across multiple method calls. We suspect that such alternatives will prove to be very similar to k-CFA in many respects, and we identify this as an area for future work.. We argued that a context-sensitive dataflow analysis is expensive, and therefore we have used program slicing to reduce the amount of dataflow analysis. There are other options to reduce the cost of k-CFA analysis such as demand driven interprocedural dataflow analysis [13] . However, such techniques are comparable to slicing, producing very similar results. We chose slicing as it is a well-understood concept that can be applied to many different programming languages. However, as discussed slicing is not prescriptive, and we plan to investigate other forms of dependency analysis in future work.. Some related work has been made in analysing transparent persistence [29] using program analysis, although the focus here is on providing optimisation of queries. This work bears similarity to work on extracting queries from legacy applications [9] , however these techniques are tailored to languages where queries are effectively embedded. This ignores many of the problems we have dealt with in this paper, but may provide an insight into how embedded persistence technologies could be incorporated into our approach in the future, and insights into formalisation of such techniques.. There has also been some related work produced by the testing community [15] . However, the program analysis used in this research, suffers from the same precision problems as the other program analysis techniques mentioned. We also note that database oriented testing in general, does not eliminate the requirement for change impact analysis, and we consider such work to be orthogonal.. The database community has the concept of schema evolution which we argue is orthogonal to our approach. We are not aware of any work from this community which directly measures the impact of a schema change upon applications, using techniques such as dependency analysis. However, we expect that our techniques can be used to help inform schema evolution approaches, and we fully expect schema evolution techniques to be just as applicable for managing change as before.. Ultimately the approach outlined in this paper does not aim to replace any existing techniques for database change, but only help to extract tacit information to aid these techniques. We have developed a prototype system that we call SUITE (Schema Update Impact Tool Environment). The architecture of SUITE is shown in Figure 6 . It shows SUITE's key constituent components and the possible interactions between them. As described above, we use the RSF file format [30] to store the results of the dataflow analysis, we write impact calculation programs in RML, and we use the CrocoPat [4] tool to execute these programs. The eventual output of this process is a text-based impact report.. We are currently targetting only C# applications that use SQL Server databases. We have implemented a slicing algorithm and dataflow analysis on top of the Microsoft Phoenix framework [21] , and extract the schema information using ADO.NET. We note that Phoenix provided considerable support for analysis of compiled .NET binaries, and the conversion to a static single assignment (SSA) form, upon which we build the implementation of the program slicing and dataflow analysis. The total size of the SUITE implementation to date is 19 KLOC written in C#.

B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Garbage collection for multicore NUMA machines Modern high-end machines feature multiple processor packages, each of which contains multiple independent cores and integrated memory controllers connected directly to dedicated physical RAM. These packages are connected via a shared bus, creating a system with a heterogeneous memory hierarchy. Since this shared bus has less bandwidth than the sum of the links to memory, aggregate memory bandwidth is higher when parallel threads all access memory local to their processor package than when they access memory attached to a remote package. This bandwidth limitation has traditionally limited the scalability of modern functional language implementations, which seldom scale well past 8 cores, even on small benchmarks.This work presents a garbage collector integrated with our strict, parallel functional language implementation, Manticore, and shows that it scales effectively on both a 48core AMD Opteron machine and a 32-core Intel Xeon machine. Inexpensive multicore processors and accessible multiprocessor motherboards have brought all of the challenges inherent in parallel programming with large numbers of threads with non-uniform memory access (NUMA) into the Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. MSPC'11, June 5, 2011, San Jose, California, USA. Copyright c 2011 ACM 978-1-4503-0794-9/11/06. . . $10.00 foreground. Functional programming languages are a particularly interesting approach to programming parallel systems, since they provide a high-level programming model that avoids many of the pitfalls of imperative parallel programming. But while functional languages may seem like a better fit for parallelism due to their ability to compute independently while avoiding race conditions and locality issues with shared memory mutation, implementing a scalable functional parallel programming language is still challenging. Since functional languages are value-oriented, their performance is highly dependent upon their memory system.. Our group has been working on the design and implementation of a parallel functional language to address the opportunity afforded by multicore processors. In this paper, we focus on the design of our memory system and parallel garbage collector. This system is designed to minimize required synchronization and to maximize locality, two features which have proven crucial to the scalability of our system on larger machines. Recent work on other functional languages has shown that the memory system is the limiting factor to improved performance for many types of code [MPS09, And10] . Our work has been guided by measurements of a number of parallel benchmarks; we present detailed results from a representative subset of these programs. This paper makes the following contributions:. 1. We demonstrate a modern functional language that makes effective use of a large number of modern NUMA multicore processors. The best recent work scales to no more than 12 cores, and we demonstrate good utilization of all available cores on both 32 and 48 core machines. This scaling is demonstrated through a set of small but representative benchmarks across a variety of physical memory allocation strategies.. 2. We describe our garbage collector, which provides excellent performance on multicore, NUMA machines. While some of the individual ideas in the garbage collector build on classic work [App89, DL93, DG94], we present a novel approach that, when combined with other aspects of our runtime architecture designed to maximize locality, avoids bottlenecks due to excessive memory traffic.. The remainder of the paper is organized as follows. In the next section, we describe our language and runtime system. Section 3 lays out the architecture of our garbage collector. Section 4 contains a detailed evaluation of our implementation using some representative benchmarks. Due to length constraints, a discussion of related work is omitted. We have demonstrated a garbage collector designed to make effective use of the memory hierarchy and that scales very well on a large number of processor cores. Keys to this design are private minor heaps that are collected concurrently with program execution and in parallel with one another and a major heap architecture that allows parallel collections while avoiding increasing traffic on the memory bus. Though some aspects of our system would need to be enhanced, for example with write barriers or static analysis, in the context of systems that permit and encourage frequent unrestricted memory mutation, we believe that these techniques are readily applicable to other runtimes. The 128 GB physical memory is provided by thirty-two 4 GB dual ranked RDIMMs, evenly distributed among four sets of eight sockets, with one set for each processor. As shown in Figure 8 , these nodes, processors, and RAM chips form a hierarchy with significant differences in available memory bandwidth and number of hops required, depending upon the source processor core and the target physical memory location. Each 6 core node (die) has a dual-channel double data rate 3 (DDR3) memory configuration running at 1333 MHz from its private memory controller to its own memory bank. There are two of these nodes in each processor package. Bandwidth between each of the nodes and I/O devices is provided by four 16-bit HyperTransport 3 (HT3) ports, which can each be separated into two 8-bit HT3 links. Each 8-bit HT3 link has 6.4 GB/s of bandwidth. The two nodes within a package are configured with a full 16-bit link and an extra 8-bit link connecting them. Three 8-bit links connect each node to the other three packages in this four package configuration. The remaining 16-bit link is used for I/O. Table 1 shows the bandwidth available between the different elements in the hierarchy.

B I O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


What are suspicious VoIP delays? Voice over IP (VoIP) is unquestionably the most popular real-time service in IP networks today. Recent studies have shown that it is also a suitable carrier for information hiding. Hidden communication may pose security concerns as it can lead to confidential information leakage. In VoIP, RTP (Real-time Transport Protocol) in particular, which provides the means for the successful transport of voice packets through IP networks, is suitable for steganographic purposes. It is characterised by a high packet rate compared to other protocols used in IP telephony, resulting in a potentially high steganographic bandwidth. The modification of an RTP packet stream provides many opportunities for hidden communication as the packets may be delayed, reordered or intentionally lost. In this paper, to enable the detection of steganographic exchanges in VoIP, we examined real RTP traffic traces to answer the questions, what do the "normal" delays in RTP packet streams look like? and, is it possible to detect the use of known RTP steganographic methods based on this knowledge? In this study delays and losses of voice (RTP) packets during real VoIP traffic were inspected in detail. Modifying the RTP packet stream potentially provides many of opportunities for hidden communication, as the packets may be delayed, reordered or intentionally lost. To assess whether RTP streams are suitable for steganographic purposes, an experiments was conducted, in which 100 average VoIP calls (of typical duration, connection path length, codec, loss concealment method and jitter buffer sizes) were performed. The experimental data was evaluated with respect to RTP packet losses including physical losses and losses caused by jitter buffer, where late packet drops and buffer overflows were distinguished, and the corresponding results for such losses were presented. Most importantly, the results were analysed to evaluate the feasibility of implementing RTP steganographic methods based on real VoIP traffic.. Steganographic traffic is harder to detect, when its characteristic is similar to normal (innocent) traffic that can be observed in a network. The results obtained proved that some of the proposed methods may be quite easily detected, as, e.g., reordering was not present in the captured data, thus the feasibility of such methods is questionable. On the other hand, when steganographic method mimics some often-observed behaviour of the protocol, its detection may be hard. For example, LACK may mimic delay spikes, characteristic formation of packets which can lead to packet drops at the receiving end. In result, this method is quite feasible, and thus it may be considered as a threat to network security. LACK can use RTP packet sequences that will surely lead to jitter buffer losses by causing late packet drops or jitter buffer overflows. LACK may provide a potential steganographic bandwidth of hundreds of bits per second and be more difficult to detect than the other steganographic methods considered here. Further research concerning analysing VoIP traffic should identify often-observed protocols behaviours (packet exchanges) that can be utilized by potential new steganographic methods. Usage of such methods can lead to hiding of steganographic data that may be even more difficult to detect.. In future work, more VoIP data must be analysed to verify and confirm with greater accuracy the results obtained and presented in this paper. Moreover, it was shown that some steganographic methods utilising RTP can pose a serious threat to network security, hence detection solutions must be designed and developed.

O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Structural features in content oriented XML retrieval The structural features of XML components are an extra source of information that should be used in a contentoriented retrieval task on this type of documents. In this paper we explore one of the structural features from the INEX collection [1] that could be used in content-oriented search. We analyse the gain this knowledge could add to the performance of an information retrieval system and present a first approach on how this structural information could be extracted from a relevance feedback process to be used as priors in a language modelling framework. This paper is part of on going work where we analyse information available in the structure of the documents and show how this information can be useful for content oriented XML retrieval. We analyse the relevance assessments for INEX 2004 [1] and compare the structural information available in the set of elements that has been judged relevant to the structural information in retrieved elements and in the collection in general. The differences in structural characteristics between relevant elements and other elements could be exploited to improve retrieval results.. In this paper, we study the potential of one type of structural information: the containing journal of an element. We have shown that the distribution of a structural characteristic (journal information) differ for relevant elements and other elements. Experiments have shown that the use of this information can improve retrieval effectiveness.. While query terms typically are distributed across many elements in all journals, relevant elements tend to cluster in a few journals. We showed this information is useful in a retrieval setting and leads to significant performance improvements.. We would like to stress that even though the experiments described in this paper are a very naive approach to exploiting the structural information, we improve significantly over the baseline. The experiments reported here do not modify the modelling of content information in any sense. We believe there is great potential for using the information gathered from the structure to improve the modelling of content. For example, to update the background estimates, to recompute IDF values or to do a journal specific query expansion.

B I O O O B I O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Representing design tradeoffs in safety-critical systems Different fault-tolerance strategies have been shown to be effective at achieving fail-safe behavior in a number of safetycritical application domains with different dependability, service, and cost requirements. A technique for comparing the domain profiles and their fault-tolerance strategies could assist architects of new safety-critical systems in choosing an appropriate fault-tolerance strategy. We suggest an approach using Kiviat graphs to visually represent the dependability, service, and cost profile of a system, and show how such a graph can be used to analyze automotive x-by-wire applications. Safety-critical systems increasingly rely upon computerized controls to provide advanced services and safety features that are impracticable to realize in hardware alone. Meeting the safety and service requirements of these softwareintensive systems is challenging, not only because they are often more complex than their electromechanical predecessors, but also because their dependability and safety requirements are often greater [4] .. Safe software-based system design has been successful in some application domains where safety engineering for electromechanical systems has previously been well established.. Both the rail and commercial aviation industries use standard fault-tolerance techniques to minimize critical system failure rates to meet industry-determined standards. The techniques they choose, however, may vary according to the safety, service, and cost requirements of the particular system being designed. In railroads, signaling and switching systems that regulate traffic often use dual two-of-two redundancy because they have very high service availability demands over a long mission time. In commercial aircraft flight control systems, reliability and availability are also very high, but with a much shorter mission time. Therefore, the fault-tolerance level necessary to meet the safety and service requirements of a flight control system can often be achieved through triple-modular redundancy.. As other safety-critical application domains transition to greater reliance on software, a natural reaction of system designers might be to simply apply the same safety-critical strategies used in these well-established systems. If faulttolerance strategy X works for application A, why not use it in application B? The problem with this approach is that it often only takes into account the reliability and availability requirements of the new and existing systems, without considering differences in other system requirements. For example, strategy X may be too expensive to implement or excessive in application B. Also, safety requirements depend on the application domain.. A visual representation of high-level system requirements might be a useful tool for system designers trying to see the "big picture" of the application domain. There are a number of ways to model the detailed behavior of specific implementations, but relatively few tools for comparing application domain properties prior to system design. In this paper we propose a new technique that uses Kiviat graphs to profile system dependability, service, and cost requirements. We then demonstrate how these graphs can be used to consider safety design strategies for automotive X-by-wire applications. This work is not a proof of concept or implementation, but rather is a suggestion for a way to think about domain-specific requirements in safe system design. This paper has presented a possible technique for comparing application domain properties and demonstrated its use in the comparison of three general safety-critical application domains. The main purpose of such a tool would be to provide system architects with a structured way of comparing attributes of different application domains prior to system design. Future work in this field would require a more thorough definition of the parameters to be analyzed, more detailed analysis of specific systems, and verification of the results of analysis.

O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Constraint satisfaction for planning and scheduling problems The areas of planning and scheduling (from the Artificial Intelligence point of view) have seen important advances thanks to application of constraint satisfaction techniques. Currently, many important real-world problems require efficient constraint handling for planning, scheduling and resource allocation to competing goal activities over time in the presence of complex state-dependent constraints. Solutions to these problems require integration of resource allocation and plan synthesis capabilities. Hence to manage such complex problems planning, scheduling and constraint satisfaction must be interrelated. This special issue on Constraint Satisfaction for Planning and Scheduling Problems compiles a selection of papers dealing with various aspects of applying constraint satisfaction techniques in planning and scheduling. The core of submitted papers was formed by the extended versions of papers presented at COPLAS'2009: ICAPS 2009 Workshop on Constraint Satisfaction Techniques for Planning and Scheduling Problems. This issue presents novel advances on planning, scheduling, constraint programming/constraint satisfaction problems (CSPs) and many other common areas that exist among them. On the whole, this issue mainly focus on managing complex problems where planning, scheduling, constraint satisfaction and search must be combined and/or interrelated, which entails an enormous potential for practical applications and future research. Over the last few years, there have been great advances in Artificial Intelligence (AI) planning, scheduling and constraint satisfaction.. There exist two almost completely separated communities in the field of Intelligent Manufacturing and in Planning and Scheduling. They have different individuals and focusing on different groups of conferences, workshops and other activities as well as mostly publishing in different journals. Intelligent Manufacturing can be considered as a subfield of those interested in applying Intelligent Technologies in general to manufacturing, while AI Planning and Scheduling is related to Computer Science. A further separation arises from the fact that similar terms are used to mean rather different things. Thus planning in the AI sense does not correspond to planning in the manufacturing sense. Consider the example of production planning, where AI Planning is an abstract approach to generating sequences of actions to meet goals from a defined initial state, meanwhile production planning often starts with templates containing sequences of actions and allocates resources to them, making it closer to what in AI would be called scheduling. Some production planning is at least as much concerned with computational geometry, as for example, generating the machining sequences needed to produce particular parts.. There is a closer match in the use of the term scheduling, but the term is typically used in the AI community to cover a wider range of activities than those covered by the term in the manufacturing community. In any case, constraint satisfaction plays an important role in planning and scheduling from both Intelligent Manufacturing and Artificial Intelligence points of views. This special issue is mainly focused on the integration of constraint satisfaction techniques to planning and scheduling problems in the AI context. Planning in AI aims at finding a sequence of actions which allows an executive agent to transform an initial state into another state that satisfies some goals [4] . This sequence is typically produced in a partial order, that is, with only essential ordering relations between the actions, so that actions not so ordered appear as pseudo-parallel and can be executed in any order while still achieving the desired goals. However some models do explicitly represent true parallelism between the actions.. Scheduling is responsible for deciding which resources to allocate to actions and when to allocate them in order to satisfy the problem constraints [3] . Scheduling is considered to be the organization of a known sequence of actions or a set of sequences along a time-line such that execution is carried out efficiently or possibly optimally. This also includes allocation of a set of resources to such sequences of actions so that a set of efficiency or optimality conditions are met. Scheduling task can therefore be seen as selecting among the various action sequences in a partialorder plan the particular order that meets efficiency or optimality conditions and filling in all the resourcing detail to the point at which each action can be executed.. Constraint satisfaction is one of the most successful problem solving paradigms in AI. Since its original development over 35 years ago [6] , it has found numerous applications in almost all areas of AI. Briefly, a constraint satisfaction problem (CSP) consists of a set of variables, each variable is associated to a finite domain, and there exists a set of constraint among the variables. The main goal in a CSP is to find an instantiation of a value to each variable in such a way that all constraints are satisfied.. Constraint Satisfaction Problems were successfully applied to many areas such as configuration, planning, scheduling and resource allocation, and form the basis of a significant software industry. With the increasing use of the Internet, many of these applications now pose themselves in a multi-agent setting where variables and/or constraints of the problem are controlled by different agents. Distributed constraint satisfaction addresses this setting.

O O O B O B O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O B B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Improving test suites for efficient fault localization The need for testing-for-diagnosis strategies has been identified for a long time, but the explicit link from testing to diagnosis (fault localization) is rare. Analyzing the type of information needed for efficient fault localization, we identify the attribute (called Dynamic Basic Block) that restricts the accuracy of a diagnosis algorithm. Based on this attribute, a test-for-diagnosis criterion is proposed and validated through rigorous case studies: it shows that a test suite can be improved to reach a high level of diagnosis accuracy. So, the dilemma between a reduced testing effort (with as few test cases as possible) and the diagnosis accuracy (that needs as much test cases as possible to get more information) is partly solved by selecting test cases that are dedicated to diagnosis. In practice, no clear continuity exists between the testing task and the diagnosis one, defined in this paper as the task of locating faults in the program code. While the former aims at generating test data and oracles with a high fault-revealing power, the latter uses, when possible, all available symptoms (e.g. traces) coming from testing to locate and correct the detected faults. The richer the information coming from testing, the more precise the diagnosis may be. This need for testing-for-diagnosis strategies is mentioned in the literature [1, 9] , but the explicit link from testing to diagnosis is rarely made. In [17] , Zeller et al. propose the Delta Debugging Algorithm which aims at isolating the minimal subset of input sequences which causes the failure. Delta Debugging automatically determines why a computer program fails: the failure-inducing input is isolated but fault localization in the program code is not studied.. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Considering the issue of fault localization, the usual assumption states that test cases satisfying a chosen test adequacy criterion are sufficient to perform diagnosis [1] . This assumption is verified neither by specific experiments nor by intuitive considerations.. Indeed, reducing the testing effort implies generating a minimal set of test cases (called a test suite in this paper) for reaching the given criterion. By contrast, an accurate diagnosis requires maximizing information coming from testing for a precise crosschecking and fault localization. For example, the good diagnosis results obtained in [9] are reached thanks to a large amount of input test data. These objectives thus seem contradictory because there is no technique to build test cases dedicated to an efficient use of diagnosis algorithms.. The work presented in this paper proposes a test criterion to improve diagnosis. This test-for-diagnosis criterion (TfD) evaluates the 'fault locating power' of test cases, i.e. the capacity of test cases to help the fault localization task. This TfD criterion allows bridging the gap between testing and diagnosis: an existing test suite which reveals faults is improved to satisfy the TfD criterion so that diagnosis algorithms are used efficiently. The goal is to obtain a better diagnosis using a minimal number of test cases.. To define the TfD criterion we identify the main concept that reduces the diagnosis analysis effort. It is called Dynamic Basic Block (DBB) and depends both on the test data (traces) and on the software control structure. The relationship between this concept and the diagnosis efficiency is experimentally validated. Experimental results also validate the optimization of test suites that satisfy the TfD criterion, in comparison with coverage-based criteria.. All the experiments use the algorithm proposed by Jones et al. [9] for diagnosis. We apply a computational intelligence algorithm (bacteriologic algorithm [3] ) to automatically optimize a test suite for diagnosis, with respect to a criterion. Finally, we use mutation analysis [6, 14] to systematically introduce faults in programs. The efficiency of a test suite for fault localization is estimated on the seeded faults. This estimate experimentally validates the benefit provided by the TfD criterion based on DBB for fault localization.. Since the scalability issue is crucial when dealing with fault localization, the whole approach is integrated in an optimization process which allows dealing with the possibly large size of the program under diagnosis. Section 2 details the algorithm proposed by Jones et al. in [9] . Section 3 investigates the relationship between testing and diagnosis. The proposed model identifies a test criterion that fits the diagnosis requirements. Section 4 details a technique to automatically generate test cases with respect to the criterion defined in section 3. Section 5 presents the experimental validation of the technique while section 6 discusses the practical use and the scalability of the technique in the testing/debugging process of a program. Section 7 concludes this paper. This work establishes an explicit connection between testing and diagnosis. Specifically, the main contribution is the identification of a "test for diagnosis criterion" which is defined to ensure a satisfactory "fault locating power" for a test suite with respect to the studied diagnosis techniques. This criterion consists in maximizing the number of distinguished dynamic basic blocks. The benefits of such a criterion are two-fold:. • It allows minimizing the number of test cases required for an accurate diagnosis. It thus reconciles the actual test practices with the diagnosis requirements.. • It provides a way to automatically estimate the quality of a particular test suite with respect to the diagnosis requirements. This estimation can be used to improve a test suite in order to improve the efficiency of the diagnosis aid technique.. The technique is experimentally validated on an OO system made of over a thousand statements. We detail a method to apply this technique on large programs. In future work, experiments will be carried out to evaluate whether classical test adequacy criteria can efficiently isolate DBBs. Jones' diagnosis algorithm is applied on the 87 mutants detected by the test suite (the diagnosis algorithm cannot help locating a fault if no test case detects it).. The results displayed on Figure 4 clearly illustrate two different behaviours for the algorithm: faults in mutants 1 to 46 are easily located (in average 4,3% of the system's code has to be examined before locating the fault) while faults in mutants 47 to 87 are very difficult to locate. For these last mutants an average of 24.76% of the system code is suspected and it can go up to 43% for mutants 60 and 68.. Using the diagnosis matrices, we computed the size of the dynamic basic block that contains the actual faulty statement for each mutant ( Figure 5 ). For mutants 1 to 46 the blocks have an average size of 3.4 whereas the size of DBBs for mutants 47 to 87 is mostly 90 with few small blocks of 8 statements (average is 60).. It appears that the faults that are difficult to localize are mostly located in large dynamic basic blocks (comparing Figure 4 and Figure 5 ), which shows a strong correlation between the size of the dynamic basic block and the accuracy of the diagnosis algorithm. For this particular experiment, the large dynamic basic block corresponds to the initialization code of the BOOK system. The diagnosis aid techniques considered in this paper are helpful for large programs. The method we propose for optimizing tests should then be scalable enough to be applied on large systems. As shown with VIRTUALMEETING case study, the approach can be applied on several thousand statements. Yet, on a much bigger system, even if it is fully automated, the optimization process may be really time-consuming.. To deal with scalability, we propose an incremental methodology, which reduces the diagnosis scope step-by-step. In a large system, a subset of code must be selected and test cases are improved to maximize the number of DBBs (i.e. minimize the size of DBBs) in this subset. Several techniques can be used to select this sub-set of code that contains the fault to locate:. • The tester expertise: She may allow selecting a particular sub-set of the system's classes regarding the test cases that failed. More generally, the tester may know from which subsystem the problem comes.. • Using failed test cases execution traces: if an error is detected by a test, there is a faulty statement in its trace. To locate this faulty statement, the test suite can be optimized to distinguish as many DBBs as possible in the set of statements executed by the test case that detects the error.. • Using a diagnosis algorithm: the most suspicious DBBs are automatically selected by the diagnosis algorithm. Then, the local optimization process is used to split those DBBs.. Then, the test case optimization will try to break the DBBs in this subset of the program code. Figure 8 summarizes this local test suite optimization process.. Using the local optimization process allows an incremental approach for fault localization and improves the scalability of the technique. Next section discusses some remaining problems regarding the link between the testing task and the diagnosis one.

O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O