Convex normal functions revisited The lattice L u of upper semicontinuous convex normal functions with convolution ordering arises in studies of type-2 fuzzy sets. In 2002, M. Kawaguchi and M. Miyakoshi [5] showed that this lattice is a complete Heyting algebra. Later, J. Harding, C. Walker, and E. Walker [4] gave an improved description of this lattice and showed it was a continuous lattice in the sense of Gierz et al. [3] .In this note we show the lattice L u is isomorphic to the lattice of decreasing functions from the real unit interval [0; 1] to the interval [0; 2] under pointwise ordering, modulo equivalence almost everywhere. This allows development of further properties of L u . It is shown that L u is completely distributive, is a compact Hausdor topological lattice whose topology is induced by a metric, and is self dual via a period two antiautomorphism.We also show the lattice L u has another realization of natural interest in studies of type-2 fuzzy sets. It is isomorphic to a quotient of the lattice L of all convex normal functions under the convolution ordering. This quotient identi es two convex normal functions if they agree almost everywhere and their intervals of increase and decrease agree almost everywhere.Mathematics Subject Classi cations (2000) 06B10, 06B15. The algebra of truth values of type-2 fuzzy sets [8] consists of the set M = [0; 1] [0;1] of all mappings from [0; 1] to [0; 1], together with operations formed as convolutions [7] of the basic operations on the unit interval. In particular, binary operations u; t on M are de ned by setting (f u g)(x) = supff (y)^g(z)jy^z = xg;. (f t g)(x) = supff (y)^g(z)jy _ z = xg:. A unary operation : is de ned by :f (x) = f (1 x) and constants 0; 1 by 0(x) = 1 if x = 0 and 0(x) = 0 otherwise and 1(x) = 1 if x = 1 and 1(x) = 0 otherwise. While the algebra (M; u; t; :; 0; 1) satis es some of the properties of bounded lattices, it is not a bounded lattice. In particular, the absorption laws f t(f ug) = f and f u(f tg) = f do not hold in M . However, there are subalgebras of M of natural interest that do form bounded lattices. It is in several of these that our interest here lies.. We say a function f from [0; 1] to [0; 1] is normal if 1 is the supremum of its image, and strongly normal if it attains the value 1. We say f is convex if it lies above all its chords; that is, if x y z, then f (y) f (x) _ f (z). Let L be the set of convex normal functions, L 1 the set of convex strongly normal functions, and L u the set of convex strongly normal functions that are upper semicontinuous, meaning that the inverse image f 1 [1 ; 1 ] of each closed interval with 0 1, is closed. All three are subalgebras of M , and furthermore all are bounded distributive lattices with the operations u; t being meet and join, and 0; 1 being the lower and upper bounds. The operation : makes these into De Morgan algebras [1] . A primary focus in [4] is to show each of these lattices is complete.. As L, L 1 , and L u are lattices, they have an associated partial ordering de ned through the meet and join operations u and t. This ordering, which we call the convolution ordering, is not the usual pointwise ordering on functions. For instance, the function 1 is the largest element of L, yet takes the value zero at all points except x = 1 where it takes value 1. The convolution ordering can seem quite unnatural and di cult to work with.. A primary contribution of [4] is to realize the lattices L, L 1 , and L u isomorphically as lattices of real-valued functions under the usual pointwise ordering. The idea is very simple. A convex function f from [0; 1] to [0; 1] is increasing on some initial segment, then decreasing on some terminal segment. One straightens out the function f to produce a function f from [0; 1] to [0; 2] by taking the mirror image about the line y = 1 of the increasing portion of f and leaving the remainder of f alone. For instance, the function 1 which takes the value 0 on [0; 1) and takes value 1 at x = 1 yields the function (1) taking value 2 on the interval [0; 1) and value 1 at x = 1. A complete account is found in [4] .. Using this technique, it is shown in [4] that the lattice L is isomorphic to the lattice D of all decreasing functions from [0; 1] to [0; 2] having 1 as an accumulation point when ordered under the usual pointwise ordering. It is also shown that L 1 is isomorphic to the lattice D 1 of all functions in D taking the value 1, and L u is isomorphic to the lattice D u of functions in D 1 that are band semicontinuous, meaning that the inverse image f 1 [1 ; 1 + ] of each band centered at 1 is closed. In this note we show that the representation of L u can be further improved. Let X be the set of all decreasing functions from the interval [0; 1] to [0; 2] under the pointwise ordering. Then for each f in X there is a unique band semicontinuous function agreeing with f almost everywhere (abbreviated: a.e.). So for the relation on X of equivalence a.e., each equivalence class of contains a unique member of D u . It follows that D u , and hence L u , is isomorphic to the lattice X= of decreasing functions from [0; 1] to [0; 2] modulo equivalence a.e. Certainly this lattice X= seems an object of natural interest. Using this representation we are able to establish a number of further properties of the lattice L u . We show L u is complete, and completely distributive. From this, the earlier results that L u is a distributive continuous lattice and a Heyting algebra follow. We also show that L u is a compact Hausdor topological lattice under a topology induced by a metric that is simply described using an integral. So the lattice L u has a most satisfying collection of properties.. It seems natural in the study of type-2 fuzzy sets to consider the notion of equivalence a.e. directly in the context of the lattice L of convex normal functions. One immediately sees that care is required as the bounds 0 and 1 of the lattice L both take value 0 at all but a single point, hence agree a.e. So the relation of equivalence a.e. provides an equivalence relation on L, but not a lattice congruence, and is of limited use. The correct notion seems to come from a strengthening of this relation. We say two convex normal functions f; g agree convexly almost everywhere (abbreviated: c.a.e.) if f and g agree a.e. and their intervals of increase and decrease agree a.e. We write f g if f and g agree c.a.e. For the isomorphism : L ! D that straightens out convex functions, we have f and g agree c.a.e. if and only if f and g agree a.e. It follows that is a congruence on L and that L= is isomorphic to D= , which in turn is isomorphic to X= , and hence to L u . So our lattice L u is isomorphic also to the lattice of convex normal functions modulo equivalence c.a.e., a lattice that seems natural in considerations of type-2 fuzzy sets.. This paper is organized in the following manner. In the second section we derive some basic properties of the relation of equivalence a.e. on X and show X= is a complete, completely distributive lattice. In the third section we use results of Birkho [2] to show the pseudometric d(f; g) = R jf (x) g(x)j dx on X yields a metric on X= , and that the metric topology on X= is a compact Hausdor topology making X= a topological lattice. In the fourth, and nal, section, we show the lattice X= of decreasing functions modulo equivalence a.e., the lattice L u of convex upper semicontinuous convex normal functions under convolution order, and the lattice L= of convex normal functions under convolution order modulo equivalence c.a.e. are pairwise isomorphic.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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


Behavioral attestation for web services (BA4WS) Service Oriented Architecture with underlying technologies like web services and web service orchestration opens new vistas for integration among business processes operating in heterogeneous environments. However, such dynamic collaborations require a highly secure environment at each respective business partner site. Existing web services standards address the issue of security only on the service provider platform. The partner platforms to which sensitive information is released have till now been neglected. Remote Attestation is a relatively new field of research which enables an authorized party to verify that a trusted environment actually exists on a partner platform. To incorporate this novel concept in to the web services realm, a new mechanism called WS-Attestation has been proposed. This mechanism provides a structural paradigm upon which more finegrained solutions can be built. In this paper, we present a novel framework, Behavioral Attestation for Web Services, in which XACML is built on top of WS-Attestation in order to enable more flexible remote attestation at the web services level. We propose a new type of XACML policy called XACML behavior policy, which defines the expected behavior of a partner platform. Existing web service standards are used to incorporate remote attestation at the web services level and a prototype is presented, which implements XACML behavior policy using low-level attestation techniques. Service Oriented Architecture (SOA) is a software paradigm for achieving loose coupling and addressing interoperability concerns among business partners. It allows business agility and flexibility as needed by today's complex business processes. However, the benefits of SOA cannot be completely delivered until a secure environment exists at each respective business partner site. In this regard, several web service security standards are in practice like WS-Security [12] for addressing confidentiality and integrity of XML documents, WS-Trust [11] for trust negotiation among business partners and XACML [27] for the specification of access policies. These standards focus on security issues relating to a service provider platform only. Security issues arising after the release of a resource to a service requester platform such as its further dissemination and usage control etc., have mostly been neglected. These issues require some tamper proof security mechanisms at the service requester platform, which cannot be realized using software-based solutions alone [14, 20] .. In order to provide hardware based security, the Trusted Computing Group (TCG) [5] has introduced a new technology, called Trusted Computing. In this technology, PCs, consumer electronic devices, PDA's and other mobile devices are equipped with a special hardware chip called Trusted Platform Module (TPM). In accordance with other security hardware extensions (cf. [13, 14] ) the Trusted Platform Module (TPM) is empowered with cryptographic mechanisms to remotely certify the integrity of the application or system software running on the device. This feature -called Remote Attestation -provides assurance that a trusted environment actually exists on a remote platform.. We believe that the advent of trusted computing technology and particularly remote attestation will change the way in which security aspects are envisioned while integrating business processes with each other. Among such efforts [28, 25] , WS-Attestation [28] is a prominent approach for the incorporation of remote attestation in to the web services architecture. However, this approach is focused on highlevel communication between different entities involved in a remote attestation scenario but does not deal with the problem of specifying the trustworthiness of a service requestor platform at a fine-grained level. TCG defines trust as, "the expectation that a device will behave in a particular manner for a specific purpose" [6] . In the stated goal of TCG, trust is associated with the expected behavior of a platform for a specific purpose, such as web service access or usage of an object.. In this paper, we present a novel approach -Behavioral Attestation for Web Services (BA4WS) -where the expectations from a service requestor platform regarding the usage of an object are specified in a concrete XACML policy called XACML behavior policy. The XACML behavior policy is built on top of WS-Attestation in order to enable a more fine-grained and flexible mechanism for incorporating attestation at the web services level.. Outline: Section 2 presents our motivations with the help of a use case from medical domain and provides the background information about remote attestation and WSAttestation. We describe the XACML behavior policy in Section 3. The BA4WS framework is detailed in Section 4. Our prototype system is presented in Section 5. We conclude this paper and present our ongoing work in Section 6. In this paper, we have presented a novel framework -BA4WS -which enables finer-granular attestation at the web services level. Our framework incorporates XACML on top of WS-Attestation. We have introduced a new type of XACML policy called behavior policy. This policy allows an administrator to specify her expectations from an SR platform regarding the enforcement of her usage policies. Thus the SP can verify, before releasing a protected object, that its usage policies will indeed be enforced as expected.. Currently, the mappings between usage conditions and behavior conditions are not automatic. This feature requires a comprehensive transformation framework which is part of our ongoing work. Further, the specification of a more flexible usage control model, such as UCON [19] and the behavior of XACML obligations will also be explored in our future work. For the demonstration of our BA4WS framework, we have developed a prototype of the delegated model discussed in Section 4. In our prototype, the SP sends an XACML behavior policy to a VS. We have constructed this VS specifically for performing attestation of a Linux Fedora Core system. The SP asks this VS to perform validation on its behalf through the behavior policy. Here, we do not discuss the mechanism of communication between the involved parties. Instead, we discuss the details of XACML function extension for incorporating attestation at the web services level and the means of integrity measurement. Since we build the whole framework on existing web services standards, the interested reader may refer to [7, 28] for a detailed discussion regarding the mechanism of communications. In the following, we first present the details of XACML function extensions. Afterwards, a brief note on the evaluation of our prototype implementation is given.

B I 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 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 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 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 B I O O O O O O O O O O O O O O O B I 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 B I 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 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 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 B I O O O B I 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 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 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 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 B I 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


KBRE:

a

framework

for

knowledge-based

requirements

engineering

Abstract

Detecting

inconsistencies

is

a

critical

part

of

requirements

engineering

(RE)

and

has

been

a

topic

of

interest

for

several

decades.

Domain

knowledge

and

semantics

of

requirements

not

only

play

important

roles

in

elaborating

requirements

but

are

also

a

crucial

way

to

detect

conflicts

among

them.

In

this

paper,

we

present

a

novel

knowledgebased

RE

framework

(KBRE)

in

which

domain

knowledge

and

semantics

of

requirements

are

central

to

elaboration,

structuring,

and

management

of

captured

requirements.

Moreover,

we

also

show

how

they

facilitate

the

identification

of

requirements

inconsistencies

and

other-related

problems.

In

our

KBRE

model,

description

logic

(DL)

is

used

as

the

fundamental

logical

system

for

requirements

analysis

and

reasoning.

In

addition,

the

application

of

DL

in

the

form

of

Manchester

OWL

Syntax

brings

simplicity

to

the

formalization

of

requirements

while

preserving

sufficient

expressive

power.

A

tool

has

been

developed

and

applied

to

an

industrial

use

case

to

validate

our

approach.

In

this

paper,

we

described

a

new

KBRE

aimed

at

providing

a

more

effective

requirements

analysis

process

that

also

incorporates

support

for

the

detection

and

explanation

of

inconsistencies,

redundancies,

and

overlaps

within

a

given

set

of

requirements.

In

the

KBRE

model,

domain

knowledge

and

semantics

of

requirements

are

centralized

in

the

form

of

an

ontology

while

requirements

are

expressed

in

an

intuitive

requirements

specification

language

based

on

the

MOS.

Both,

the

ontology

and

the

requirement

specifications,

are

directly

translated

into

the

description

logic

SROIQ

that

provides

a

logical

and

reasoning

system

to

yield

a

sophisticated,

yet

practical,

means

to

unveil

inherent

problems

in

a

given

requirements

set.

Our

approach

allows

the

sources

of

these

problems

to

be

traced

along

the

requirements

goal

graph

that

results

from

the

application

of

the

GORE

method

to

requirements

elicitation.

Automatically

generated

explanations

can

guide

requirements

engineers

toward

feasible

conflict

resolution

methods

in

case

of

conflicting

requirements..

Our

KBRE

method

has

produced

some

promising

results.

The

MOS

is

sufficient

for

representing

a

wide

range

of

requirements.

Yet,

there

are

certain

features

that

cannot

be

formalized

in

MOS.

For

example,

we

are

currently

unable

to

formalize

temporal

properties,

as

MOS

is

not

equipped

to

capture

those

aspects.

Moreover,

in

the

KBRE

model,

the

requirements

problems

can

only

be

detected

if

the

related

concepts,

roles,

and

instances

as

well

as

their

relationships

are

declared

in

the

ontology.

As

a

consequence,

specific

requirements

problems

may

escape

detection

if

the

ontology

is

not

powerful

(i.e.,

descriptive)

enough.

Given

the

limitation

of

OWL

expressiveness

in

dealing

with

temporal

operators,

we

intend

to

extend

the

requirements

specification

language

with

temporal

constructors.

Significant

upgrades

would

then

be

expected

in

the

underlying

reasoner

to

cope

with

the

extensions

of

the

specification

language.

In

addition,

we

are

planning

to

work

on

an

automated

mechanism

to

produce

warnings

to

requirements

engineers

in

the

situations

when

potential

concepts,

roles,

instances,

and

their

relationships

are

not

declared

in

the

ontology.

Finally,

more

comprehensive

evaluation

will

need

to

be

carried

out

in

order

to

assess

the

effectiveness

of

our

framework

in

varying

problem

domains

and

detailed

requirements

engineer

feedback

on

our

approach

and

toolset..

System

needs

to

provide

a

forum

for

discussions

(System

SubClassOf

supportFeature

SOME

Forum)..

System

supports

the

creation

of

user

groups

to

facilitate

the

connection

(System

SubClassOf

supportFeature

SOME

UserGroup)..

If

the

system

supports

any

type

of

group

communication,

then

no

forum

is

needed

(supportFeature

SOME

GroupCommunication

NOT

(SubClassOf

supportFeature

SOME

Forum))..

But

without

a

proper

characterization

of

the

associated

relationship

between

the

capture

concepts,

no

problems

can

manifest

(cf.

Fig.

We

wish

to

emphasize

this

point

here,

in

particular,

to

motivate

the

need

for

proper

knowledge

representation

in

RE..

Next,

we

demonstrate

how

the

ontology

editor

can

be

used

to

define

concepts,

roles,

instances,

domain

knowledge,

rules,

and

constraints

(cf.

Fig.

In

particular,

we

show

how

''UserGroup''

can

be

defined

as

a

sub-concept

of

''GroupCommunication''.

Next,

we

show

how

to

use

the

reasoner

in

analyzing

requirements

to

identify

inconsistencies

and

how

the

provided

explanations

may

help

requirements

engineers

get

more

insights

into

the

problem

(cf.

Fig.

In

the

next

step,

we

present

the

requirement

query

support

provided

by

REInDetector..

We

particularly

make

a

query

to

analyze

a

partial

set

of

requirements

which

does

not

contains

all

requirements

involved

in

the

inconsistency.

The

results

from

the

reasoner

indicates

that

there

is

no

inconsistency

in

this

set

of

requirements

(cf.

Figure

In

the

final

step

of

the

demonstration,

we

show

how

the

identified

inconsistency

can

be

resolved.

In

this

case,

that

is

done

by

removing

one

of

the

inconsistent

requirements

(cf.

Fig.

REInDetector,

accompanied

with

a

demo

scenario

and

user

quick-start

guide

are

available

for

download

at:

The

related

works

to

our

approach

can

be

categorized

into

two

groups;

one

is

ontology

formal

representation

languages

which

allow

automated

analysis

and

reasoning

and

another

include

the

approaches

for

detecting

inconsistencies

in

RE.

The

formal

languages

proposed

in

the

community

of

knowledge,

ontology,

and

RE

can

be

classified

into

two

categories:

languages

based

directly

on

logics

and

controlled

subsets

of

English

which

is

translatable

to

logics

for

reasoning.

The

works

fall

into

the

first

category

include

the

following:

RML

(Greenspan

et

al.

TELOS

(Mylopoulos

et

al.

FRORL

(Tsai

et

al.

KAOS

requirements

representation

language

(Dardenne

et

al.

Van

Lamsweerde

Formal

Tropos

(Fuxman

et

al.

Despite

of

the

fact

that

these

representation

languages

are

very

powerful

with

the

expressiveness

inherited

from

logics

and

that

KAOS

language

and

Formal

Tropos

are

computationally

less

complex

than

DL

as

they

are

built

based

on

linear

temporal

logic

that

falls

into

the

complexity

class

of

PSPACE-complete

(Sistla

and

Clarke,

which

is

simpler

than

MOS's

complexity

(Kazakov

they

are

fairly

complicated

and

normally

require

technical

training

for

their

use

and

elaboration

(Jaramillo

et

al.

In

addition,

Controlled

Natural

Languages

(CNLs)

has

been

a

recently

emerging

area.

Research

in

this

field

has

attempted

to

overcome

the

limitations

of

traditional

logic-based

representation

languages

by

proposing

different

sub-sets

of

English

which

are

transformable

to

logics

or

formal

languages

to

allow

automated

analysis

and

reasoning.

Some

examples

of

well-known

CNLs

include

ACE

(Fuchs

et

al.

PENG

(Schwitter

(Pratt-Hartmann

and

SOS

(Cregan

et

al.

ACE,

PENG,

and

are

transformable

to

first-order

logic

(FOL),

represent

a

great

combination

of

logics

and

natural

languages

and

thus

are

powerful

in

both

expressiveness

and

user-friendliness.

However,

except

which

is

proved

to

be

equivalent

to

the

decidable

sub-set

of

FOL

(in

term

of

expressiveness),

other

languages

are

known

to

be

undecidable.

Moreover,

although

possessing

great

expressiveness

power,

these

languages

are

proved

not

suitable

to

represent

concepts,

roles

and

their

relationships,

due

to

their

syntactic

constraints

(inherited

from

English

grammar)

(Schwitter

et

al.

In

particular,

ACE

neither

provides

explicit

constructs

for

enumerations

nor

allows

data

type

properties

to

be

defined.

In

addition,

representing

relationships

between

roles

or

specifying

disjoints

entities

are

very

complex

in

ACE..

SOS

is

the

language

most

comparable

to

MOS.

It

is

a

controlled

natural

language

which

is

transformable

to

to

allow

the

representation

of

OWL

ontologies

and

automated

reasoning.

The

disadvantage

of

SOS

is

that

it

is

equivalent

to

while

MOS

is

equivalent

to

which

is

more

expressive.

More

precisely,

better

supports

qualified

number

restrictions,

property,

and

data

type

expressivity..

MOS

offers

us

a

good

option

for

balancing

between

the

user-friendliness,

efficiency

and

expressiveness

of

a

representation

language.

MOS,

with

its

expressions

constructed

from

natural

language

words,

has

been

proved

to

be

well-received

by

non-logicians

(Cregan

et

al.

In

addition,

being

transformable

to

DL,

a

decidable

sub-set

of

FOL,

MOS

guarantees

the

sound

and

complete

reasoning.

Moreover,

using

MOS

is

also

benefited

from

the

availability

of

various

reasoners

for

DL.

Furthermore,

although

possessing

less

expressive

power

than

FOL

or

temporal

logics

(MOS

is

not

able

to

allow

temporal

operators),

MOS

is

powerful

in

its

representation

of

domain

knowledge,

with

concepts,

roles,

and

instances

and

their

relationships,

the

key

focus

of

our

work

here..

A

main

limitation

of

MOS

is

that

it

is

not

capable

of

representing

temporal

constraints.

For

instance,

a

requirement

such

as

''When

the

user

chooses

to

show

his/her

online

status,

the

user's

status

button

will

always

reflect

the

user's

availability

on

the

system''

cannot

be

expressed

in

the

language..

In

the

next

part

of

this

section,

we

discuss

the

key

related

research

approaches

that

have

been

proposed

for

dealing

with

the

problem

of

detecting

requirements

inconsistencies

in

RE..

WinWin

(Boehm

et

al.

is

a

human-based

collaborative

approach

designed

for

detecting

conflicts

between

stakeholders'

win

conditions.

This

approach

does

not

provide

explicit

support

for

conflict

detection.

It

and

its

QARCC

extension

(Boehm

and

In

instead

allow

stakeholders

to

enter

win

conditions,

and

these

conditions

are

associated

with

quality

attributes.

Based

on

the

predefined

knowledge

base

of

potential

conflicting

quality

attributes,

potential

conflicts

between

win

conditions

are

flagged.

Although

this

approach

can

produce

fast

and

precise

results

in

some

situations,

it

may

not

be

complete

and

sound

because

the

correctness

of

the

identification

process

heavily

depends

on

the

completeness

of

the

knowledge

base.

In

addition,

it

is

labor-intensive

and

difficult

to

be

applied

for

large

models..

Similar

to

WinWin,

Robinson

and

Pawlowski

proposed

a

technique

called

DealScribe

following

the

a

human-based

collaborative

approach.

In

DealScribe,

stakeholders

are

expected

to

identify

conflicts

between

the

root

requirements,

which

are

the

most

general

requirements

defined

for

the

relevant

concepts

in

the

models.

The

stakeholders

are

expected

to

explore

and

indicate

the

interactions

between

all

the

possible

pairs

of

root

requirements

in

the

models.

An

interaction

may

be

characterized

as

''very

conflicting,''

''conflicting,''

''neutral,''

''supporting,''

or

''very

supporting.''

The

conflicts

among

requirements

in

the

models

would

then

be

detected

based

on

these

interactions.

This

technique

has

similar

drawbacks

to

those

of

WinWin..

Sharing

the

same

idea

of

predefining

potential

conflicting

software

quality

attributes

with

WinWin

and

DealScribe,

Egyed

and

Grunbacher

also

introduce

the

concept

recovering

dependencies

among

requirements.

This

facilitates

the

incremental

exploration

of

conflict

identification

based

on

the

automated

traceability

of

the

dependency

as

the

requirements

evolve.

Although

this

approach

avoids

the

time-intensive

and

error-prone

process

in

the

other

two

approaches,

its

soundness

could

be

challenged

as

the

identification

of

conflicts

still

heavily

relies

on

the

predefined

potential

conflicts

among

quality

attributes.

In

addition,

neither

the

use

of

domain

knowledge

and

semantics

of

requirements

nor

requirements

conflicts

explanations

are

supported

in

this

approaches..

KAOS

(Dardenne

et

al.

Van

Lamsweerde

is

a

comprehensive

framework

aimed

at

supporting

the

process

of

RE

including

the

management

of

conflicts

among

requirements.

In

KAOS,

requirements

are

formalized

in

linear

temporal

logic

(LTL)

to

enable

the

identification

of

conflicts

using

formal

reasoning

methods.

Three

of

such

techniques

are

described

in

(Van

Lamsweerde

et

al.

including

using

regressing

negated

assertions,

divergence

patterns,

and

divergence

identification

heuristics.

In

addition,

other

types

of

conflicts

such

as

process-level

deviations

or

instance-level

deviations

can

also

be

detected

using

consistency

rule

checks..

KAOS

provides

a

very

rigorous

approach

for

detecting

conflicting

requirements.

However,

as

mentioned

above,

the

use

of

LTL

in

specifying

requirements

requires

requirements

engineers

to

be

sufficiently

familiar

with

LTL

and

be

able

to

correctly

specify

requirements

in

LTL.

Thus,

its

applicability

in

practice

can

be

fairly

limited

(Dwyer

et

al.

In

addition,

although

KAOS

supports

the

creation

and

maintenance

of

domain

knowledge

through

the

use

of

its

conceptual

meta-model,

the

concepts,

roles,

and

instances

in

the

problem

domain

as

well

as

the

semantics

of

requirements

cannot

be

adequately

expressed

and

reasoned

in

LTL

(Breaux

et

al.

Tropos

(Fuxman

et

al.

is

a

framework

that

provides

formal

and

mechanized

analysis

of

early

requirement

specifications.

The

requirements

analysis

in

Tropos

is

done

using

the

model

checking

approach

with

the

support

of

a

specification

language

called

Formal

Tropos

which

is

developed

from

the

combination

of

the

i*

modeling

language

(Chung

and

the

temporal

specification

language

inspired

by

KAOS.

Similar

to

the

specification

language

in

KAOS,

the

Formal

Tropos

is

also

too

complicated

to

be

used

in

practice.

In

addition,

the

semantics

of

requirements

cannot

be

defined

sufficiently

in

Tropos

as

the

framework

uses

no

sub-classing

or

specification

of

structures,

and

thus,

the

domain

and

instance-level

are

not

distinguished

in

the

formalization

(Breaux

et

al.

Hence,

explanations

of

conflicts

are

not

provided

in

both

frameworks.

Lauenroth

and

Pohl

proposed

an

approach

for

dynamically

checking

consistencies

among

domain

requirements

in

Product

Line

Engineering.

The

detection

of

inconsistencies

in

their

work

is

based

on

the

combination

of

the

variability

model,

which

is

for

representing

the

variances

among

different

products

in

the

same

product

line,

and

the

domain

requirements

specification

model.

The

dynamic

check

for

inconsistencies

is

accomplished

by

using

a

contradiction

function

which

conforms

to

the

model

checking

methods.

Yet,

explanations

for

conflicting

requirements

as

well

as

domain

knowledge

and

semantics

of

requirements

are

not

supported..

We

are

aware

of

a

few

works

in

the

area

of

ontology-based

RE

that

are

close

to

our

approach.

Siegemund

et

al.

proposed

building

an

ontology

to

support

the

RE

process.

However,

their

focus

was

mainly

on

tracking

the

interactions

among

requirements

(e.g.,

supporting,

retracting,

etc.).

Inconsistency

detection

is

for

identifying

conflicts

between

these

interactions

rather

than

between

the

requirements

themselves.

In

addition,

Kaiya

and

Saeki

also

use

ontology

to

define

semantics

in

requirements'

domain.

However,

they

translate

concepts

in

requirements

into

UML

class

diagrams

in

which

each

class

represents

a

concept

and

introduce

different

types

of

links

to

represent

relations

among

these

classes.

Based

on

these,

some

inconsistencies

can

be

detected.

The

process

of

translation

is

omitted

in

this

work.

The

disadvantage

of

this

approach

is

that

it

is

not

able

to

express

some

complex

requirements

which

can

be

done

with

MOS

(i.e.,

conditioning

requirements

such

as

''a

user

has

failed

logins

attempt,

their

account

will

be

locked'').

Moreover,

modeling

semantics

with

UML

class

diagrams

would

cause

complexity

when

the

number

of

requirements

evolves..

Although

sharing

the

same

objectives

of

detecting

inconsistencies

in

RE,

the

works

of

Grundy

et

al.

Kamalrudin

et

al.

and

Weston

et

al.

have

a

different

focus.

Grundy

et

al.

address

the

problem

of

inter-model

consistency

in

software

development

environment

tools.

They

focus

on

managing

inconsistencies

in

multiple

views

which

are

derived

from

a

common

repository.

The

automated

identification

of

inconsistency

is

facilitated

based

on

representing

the

artifacts

in

the

repository

by

using

a

special

kind

of

graph.

Very

limited

explanation

of

the

inconsistency

root

cause

is

provided.

Kamalrudin

et

al.

focus

on

detecting

inconsistencies

between

specifications

at

different

levels

of

abstraction,

while

Weston

et

al.

propose

an

approach

for

checking

inconsistencies

among

semantics

compositions

in

aspect-oriented

requirements.

As

these

use

semi-formal

representations,

more

limited

inconsistency

and

overlap

detection

can

be

achieved

than

in

our

description

logic-based

approach..

To

summarize,

there

have

been

a

number

of

different

approaches

sharing

common

objectives

with

our

work.

The

key

differentiation

between

the

existing

approaches

and

our

model

lies

in

the

ability

of

our

framework

to

store

domain

knowledge

and

semantics

of

requirements

which

assist

requirements

engineers

not

only

in

elaborating

requirements

but

also

in

identifying

requirements

problems.

Moreover,

explanations

for

conflicting

requirements

are

an

integral

part

of

our

RE

process

model

allowing

requirements

engineers

to

have

a

better

understanding

into

the

nature

of

the

detected

problems.

Finally,

our

approach

and

our

requirements

specification

language

permit

requirements

to

be

formalized

in

a

simple

and

intuitive

syntax,

making

it

easy

for

practitioners

to

understand

and

communicate

between

each

other.

O O O O O B I O O B 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 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 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 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 O O O O O O O O O O O O O O O O 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 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


How Was Your Day? Evaluating a Conversational Companion Abstract-The "How Was Your Day" (HWYD) companion is an embodied conversational agent that can discuss work-related issues, entering free-form dialogues while discussing issues surrounding a typical work day. The open-ended nature of these interactions requires new models of evaluation. Here, we describe a paradigm and methodology for evaluating the main aspects of such functionality in conjunction with overall system behavior, with respect to three parameters: functional ability (i.e., does it do the "right" thing conversationally), content (i.e., does it respond appropriately to the semantic context), and emotional behavior (i.e., given the emotional input from the user, does it respond in an emotionally appropriate way). We demonstrate the functionality of our evaluation paradigm as a method for both grading current system performance, and targeting areas for particular performance review. We show correlation between, for example, automatic speech recognition performance and overall system performance (as is expected in systems of this type), but beyond this, we show where individual utterances or responses, indicated as positive or negative, characterize system performance, and demonstrate how our combination evaluation approach highlights issues (both positive and negative) in the companion system's interaction behavior. C OMPANION technologies, or companions, refer to an emerging form of interaction between people and technologies [1] . The term "companion" has been used naturally, without specific definition, in the EU projects Semaine (www.semaine-project.eu) and LIREC (www.lirec. eu), which explored the design of digital and robotic companions. Wilks [2] has characterized the companion concept as a personalized conversational, multimodal interface, one that knows its owner and is implemented on a range of platforms, both static and mobile. For us, companions are advanced spoken language dialogue systems that attempt to go beyond the limited functionality of current task-oriented dialogue systems by being cooperative, collaborative dialogue partners and forming long-term relationships with the people who interact with them. Uniting these views is that companions foreground the social and affective, unlike other approaches to interaction that foreground the efficiency, effectiveness, or utility of technologies.. The volume edited by Wilks [1] contains 24 chapters devoted to wide-ranging discussions of companion issues, from falling in love with a companion to being a Victorian companion. Benyon and Mival [3] argue that companions aim to change human-computer interaction (HCI) into human-companion relationships. This builds upon the ideas of affective computing [4] and designing for the emotional involvement of people with technologies. Companions may be represented as "virtual human" onscreen characters or as embodied conversational agents (ECA), but do not have to be. Companions encompass the widest possible range of devices and forms of interaction that woven together produce a relationship-building experience for people.. Companions represent the maturation of a concept that has been in computing and HCI since it earliest days. Weizenbaum [5] developed his program ELIZA in the late 1960s. It was able to hold remarkably convincing conversations (through a type-written interface) that many people clearly found engaging. Chatbots are available online that perform a similar function. However, these systems do not have any underlying purpose other than to chat. Companions and ECAs are interactive technologies that aim to achieve higher conversational or relationship goals. They draw upon research into software engineering, speech and language, artificial intelligence, and theories of conversation and interaction, politeness, humor, personality, emotion, trust, social presence as well as other theories of human relations [6] . Companions are in particular designed to develop and maintain longer term socio-emotional relations with users or to focus the establishment of trust, for example, by utilizing conversational strategies to support humor [7] , politeness [8] , or empathy [9] .. The challenge that we address in this paper is how should companions be evaluated. We present the detailed evaluation of a specific instantiation of the companion concept. This is the "How Was Your Day?" (HWYD) companion, an ECA developed to have engaging conversational interactions with the typical office worker returning home after work. The HWYD system was developed as part of the EU funded integrated project COMPANIONS investigating the companion concept. Several other companion concepts were developed including a senior companion aimed at having conversations with older people and a health and fitness companion aimed at encouraging people to exercise more. The aim of the HWYD companion was to showcase a sophisticated model of natural dialogue interaction using a speech-based interface. The scenario was chosen because it was seen to be representative of the sort of deployment that companions in the home could offer in a few years' time. A large screen in the home would display the avatar who would greet the users when they got home, and be capable of holding conversations around 40 officerelated topics in the context of asking about a person's working day [10] .. The aim of the laboratory-based evaluation of the companion was to provide summative data about the performance of the system across a range of representative scenarios and to explore the more general issues of evaluating companions. The system was evaluated in the form that the developers delivered it ( Fig. 1 ) with the exception of one scenario (see Section 3). Although it is unusual for users to be able to see the workings of an ECA, the interface served to highlight the performance of the system in terms of accessed modules and of the recognized speech and emotions. 1 The paper is laid out as follows. This section describes the HWYD companion system and discusses some previous efforts to evaluate spoken dialogue systems. Section 2 introduces the proposed evaluation paradigm for companions with its subjective and objective measures. Section 3 elaborates on the evaluation methodology and on how user studies were set up and performed. The scenarios adopted for those studies play a vital role in the evaluations and are described in detail in Section 4. Results of experimental user studies carried out along these lines are presented and analyzed in Section 5. Section 6 finally discusses the experiences from the experimental evaluations. We have presented the evaluation of a novel piece of software that was developed to explore the concept of an artificial companion. The companion engaged in interactions with people through an on-screen avatar conducting conversations about how their day at work had been. In 2013, this is still a novel form of interaction. There are only a few ECAs such as GRETA [27] able to engage in these sorts of interactions, and the commercial state-of-the-art Apple Siri, only deals with focused commands with a few "canned" responses to more general questions. We expect companion technologies to develop rapidly over the next few years. In developing the evaluation paradigm for the HWYD companion, we also make a larger contribution to the evaluation of companions in general.. One limitation of the study was the ability of the companion to recognize speech which, coupled with a relatively slow response time, led to a poorer user experience than could have been the case. Until these issues are fixed, system conversations are obviously always going to be suboptimal. However, we can see from the appropriateness scores that the underlying DM is performing relatively well in selecting responses that people thought were appropriate. Another limitation of the study was that we did not seek to perform a component analysis, although some components require particular attention. In particular, the overall high ASR Word Error Rate hampers many efforts to create companionable dialogues. Given this, the system performed reasonably well, although it has no particular strategies for managing speech error.. Furthermore, the study did not investigate longitudinal interaction with the companion, as the version that we had was not robust enough to be deployed in people's homes or without the support of a research assistant. The sampling of participants for the study thus also had to be restricted to people that would tolerate a lengthy laboratory evaluation. The study hence involved 12 participants, all affiliated to one single university, but with different academic positions. This does not invalidate the results, but it should be clear that the sample might only partially be representative for those intended to use the system.. At the stage of development of the HWYD companion, a scenario-based laboratory evaluation was appropriate. The scenarios themselves were developed to test particular features of the companion's performance on negative and positive dialogues of different types. Thus, the evaluation can be criticized for the lack of ecological validity. The study was performed in a laboratory environment and the next step would obviously be to test the companion with a more longitudinal approach placed in a natural workplace or everyday setting. However, we do not feel that this either compromises the results obtained or the overall evaluation method.. The evaluation scenarios (Section 4.2) were chosen to test specific conditions of the HWYD companion and were able to show some performance issues. For example, there was an implicit belief that the system would perform better with long user utterances, but this was shown not to be the case. As with most spoken language systems, shorter (although significantly longer than most task-based systems) focused utterances proved most successful. The appropriateness annotation provides several interesting features when analyzing dialogues. Specific annotation gives developers key insights into areas of system performance that can be addressed at both micro and macro levels. At micro level, a list of utterances can be output from the system (and surrounding context) and be judged to be inappropriate on some level (providing direction for system improvements). At macro level, the graphs of distribution of labels indicate conversation trajectories that can be useful characterizations of both scenarios and systems.. The traditional objective measures of dialogue quality identified in Section 5.1 obviously remain important for companion interaction. The WER and CER obtained in the evaluation are both high. Clearly, if the speech recognizer fails to correctly register what the person says, subsequent interactions will be less effective. The number of turns and words per utterance are also important metrics, though in the case of companions they should not necessarily be minimized. If the goal is to engage the user in conversations, longer utterances may be appropriate in some circumstances whereas shorter utterances with more turn-taking may be better in others. Work on these measures of appropriateness and their relative weighting needs to continue.. An interesting point to note is that in the participant interviews after all sessions, length of delay in response was considered far less an issue than the timing of the response as well as knowing if and when a response was coming. Participants wanted feedback regarding the state of the companion during the response delay: if the companion was going to deliver a response or not (several utterances per dialogue receive no reply). The largest frustration was when they started talking again but the companion proceeded to talk over them.. In more general terms, the evaluation paradigm can be used to look at a broad range of companions. Speech is central to these technologies and it is important to strive for a natural dialogue between a companion and its owner. This can be measured in terms of response time, appropriateness score, and utterance length. A natural dialogue will be mixed initiative, which can be measured by the length of system and user turns. A good dialogue will also demonstrate stickiness as measured in terms of length of the overall interaction and whether people return to interact with the system. The look and behavior of the avatar is a clear part of the overall user experience as emphasized in the face and body modeling of systems such as GRETA [27] . In line with the idea of relational agents [6] and of moving from interaction to relationships [3] , the social, emotional, and psychological aspects of the interaction contribute to the user experience and can be measured through questions such as those included in the user questionnaire. Finally, the utility of a companion is an issue. Companions can span the spectrum of utility from being highly useful (providing information, or caring for someone) to being quite nonutilitarian (e.g., like a pet) but still providing important support to individuals: being able to discuss your working day with your companion may be just what you need.. David Benyon is currently a professor of human-computer systems, the director of the Centre for Interaction Design, and the faculty director for interdisciplinary research at Edinburgh Napier University, Scotland. He has received funding from several European funding programs and developed a number of novel theoretical ideas on human-computer interaction concerning the sense of self and place in mixed reality environments and also published on semiotics and experientialism applied to new media. He is the author of Designing with Blends (MIT Press, 2007) and Designing Interactive Systems (Pearson, second ed. 2010).. Bjö rn Gambä ck is currently a professor of language technology in the Department of Computer and Information Science, the Norwegian University of Science and Technology, and the head of European Collaborations at SICS, Swedish ICT Research AB. He has been at the Royal Institute of Technology and universities in Saarbrü cken, Helsinki, and Addis Ababa. He has managed a dozen national and international projects and published more than 100 scientific papers on subjects such as conversational agents, spoken dialogue translation, system and user evaluation, and machine learning applied to language processing.. Preben Hansen received the PhD degree in information studies and interactive media from Tampere University, Finland. He is currently an assistant professor in the Department of Computer and Systems Sciences, Stockholm University. He works with research questions in the areas of information seeking (IS) and information retrieval (IR), including theoretical models of IS and IR processes, empirical studies of users and the use of interactive information access systems, and collaborative environments.. Oli Mival received BA (Hons) degree in psychology from Edinburgh University and the PhD degree in human-computer interaction from Edinburgh Napier University. He is a senior research fellow and the director of the future interaction network at the Centre for Interaction Design, Edinburgh Napier University, Scotland. His research interests include developing, designing and implementing new forms of interface and interaction experience.. Nick Webb is currently a visiting assistant professor in the Department of Computer Science, Union College, New York. His research encompasses a range of language processing applications, including information extraction, question answering and dialogue systems, computer science education, and social robotics. He was a principal investigator of the National Science Foundation-funded Social Robotics Consortium of the Capital Region, and is co-PI of the Social Robotics Workshop, funded by the National Center for Women and Information Technology.

O O O O O O O O O O O O O O O O O O O O O O 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 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 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 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 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 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 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 B I I 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 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 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 B 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 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 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 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 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 B 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 O O O O O O O O O O O O O O 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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


Deep typechecking and refactoring Large software systems are typically composed of multiple layers, written in different languages and loosely coupled using a string-based interface. For example, in modern webapplications, a server written in Java communicates with a database back-end by passing in query strings. This widely prevalent approach is unsafe as the analyses developed for the individual layers are oblivious to the semantics of the dynamically constructed strings, making it impossible to statically reason about the correctness of the interaction. Further, even simple refactoring in such systems is daunting and error prone as the changes must also be applied to isolated string fragments scattered across the code base.We present techniques for deep typechecking and refactoring for systems that combine Java code with a database back-end using the Java Persistence API [10] . Deep typechecking ensures that the queries that are constructed dynamically are type safe and that the values returned from the queries are used safely by the program. Deep refactoring builds upon typechecking to allow programmers to safely and automatically propagate code refactorings through the query string fragments.Our algorithms are implemented in a tool called QUAIL. We present experiments evaluating the effectiveness of QUAIL on several benchmarks ranging from 3,369 to 82,907 lines of code. We show that QUAIL is able to verify that 84% of query strings in our benchmarks are type safe. Finally, we * Supported in part by the NSF grants CCF-0427202, CNS-0541606, and CCF-0546170.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. show that QUAIL reduces the number of places in the code that a programmer must look at in order to perform a refactoring by several orders of magnitude. Large software systems are built in multiple layers, employing various systems, languages, and run-times. For example, companies like Amazon, Google, and Yahoo all produce software that has three basic tiers: a browser front-end using HTML and Javascript, a middle-tier running Java, .NET, or a similar stack of server technology, and a storage tier using a relational database or other long-lived storage platform. A successful integration of these layers must enjoy three properties: it must be efficient, in that it must be able to exploit the beneficial properties of the individual layers; it must be usable, in that it must allow engineers to easily utilize the full range of functionality available in the individual layers; and it must be safe, in that it must prevent errors due to interactions that cut across the different layers.. Unfortunately these three properties have hitherto resisted reconciliation. For example, consider the problem of interfacing between an object-oriented programming language and a relational database. A number of approaches exist for translating data to and from objects and relations, each of which attempts to deal with the so-called "impedance mismatch" [13] that exists between relational data and objectoriented data.. Orthogonal persistence solutions [1, 12] map the entire database into a collection of persistent objects that are directly manipulated and navigated in the programming language. This approach is safe, as the programming language's type system is in full control, but is often hard to use and sacrifices opportunities for optimization of data access. In particular, the programming language and database are tightly coupled, resulting in a system whose data design is dependent on programming language decisions, which in turn leads to a less efficient and harder to use data store.. Language-based solutions [18, 15] extend programming languages like Java [23] or C [2] with syntax inspired by functional programming constructs [24, 5] that can be directly compiled into database queries. Not only are these approaches safe, but they can also be efficient. In particular, the programming language and database can be more loosely coupled than in an orthogonal persistence solution, resulting in improvement efficiency of data storage and retrieval. However, the usability of these techniques remains to be seen. One barrier to adoption is that these techniques hide the structure of the generated queries, which can lead to unexpected performance bugs.. Finally, call-level interfaces [20] such as Toplink [6] , EJB [14] , JDO [17] , and Hibernate [9] -recently consolidated under the Java Persistence API (JPA) [10, 11] standard for Java -allow developers to describe mappings of relational constructs onto Java types, which can then be queried using SQL-like query strings. This approach is both flexible and efficient because the query strings are expressed in a language specifically designed for data access, but are less safe as the host language is unaware of the content of the query strings, and is unable to apply its type constraints to those queries. This approach has the loosest coupling between programming language and database, and makes it easy for developers to efficiently query for and use data from the database without having any direct knowledge of the relational structures used to hold that data, but at the cost of a loss of safety.. In general the approach of loosely coupling different systems using a string-based interface with a domain-specific interfacing language is flexible, can leverage the properties of each layer effectively, does not force the developer to learn another language or paradigm, and hence is widely adopted by large-scale system developers.. Unfortunately, this approach is unsafe in that it greatly complicates two standard software engineering tasks: typechecking and refactoring. Large systems that are made of loosely coupled heterogeneous components have little support for performing typechecking at the boundaries of different languages. Furthermore, performing even simple refactoring in such systems is daunting and error prone, because the required changes cut across different layers, causing subtle bugs to slip between the cracks.. As an illustrative example, consider the Java code snippet from Figure 1 . In this snippet, Q0 is an abbreviation for the query string shown at the top of the figure. On line 2 the code creates a JPA query that returns the set of books owned by a given person ?1. The person ?1 is a parameter System.out.println(book.name); 8: } Figure 1 . Sample JPA Code to the query, and this parameter is set (on line 3) using a call to setParameter. Once the parameter is set, the query is executed (on line 4), and the result of the query, a list of Book objects, is stored in the result variable. The code then proceeds to print the name of each book in the result list (on lines [5] [6] [7] [8] . Note how in this code the Book and Person classes crosscuts both Java and the query language: they are meaningful in both contexts.. This code snippet illustrates two of the main difficulties in writing and maintaining JPA code:. Type Errors: As objects are passed to and from the database back-end through a single interface (namely setParameter and getResultList), these interfaces use Object for the type of parameters and results, which leads to the compiler missing type errors. For example, if a Car object were passed in to setParameter on line 3, the compiler would not be able to flag this as a type error. Furthermore, because getResultList() returns a list of Objects, the variable on line 4 is declared as List<Object>, not List<Book>, and as a result there is an additional cast on line 6, which at run-time may fail if the programmer uses the wrong type in the type cast.. Refactoring Errors: As names of classes appear in query strings, for example in Q0, changing the name of a class involves renaming all the queries that mention the class. Unfortunately, there is little support for helping the programmer make sure that all such strings have been renamed. The class-rename refactoring in Eclipse does not refactor such strings, and furthermore forgetting to rename a string does not lead to a type error, unlike renaming a class directly in Java, where forgetting to rename a mention of the renamed class leads to a type error.. Our broad research agenda is to address these problems, and thus reconcile safety, usability and efficiency, by developing techniques and tools for deep typechecking and deep refactoring -type-checking and refactoring that cut across different languages and systems. In this paper we present techniques for deep typechecking and refactoring for sys-tems that combine Java code with a database back-end using JPA.. For deep typechecking, the main challenges lie in the fact that the problem cuts across Java and the JPA query languages in non-trivial ways. First, the Java code manipulates strings that represent JPA queries, making it difficult to identify the queries that are executed. Second, the Java code sets the parameters to the JPA queries, and uses the results that they produce, which requires tracking where these results flow to determine if they are used correctly.. We address these challenges by using different techniques for analyzing Java and JPA queries. We use a dataflow analysis on the Java side to compute the set of query strings that may be executed at a particular call site to getSingleResult, and to propagate the result type of executed queries through the code to make sure that downcasts will not fail at run-time. On the JPA side, we use a type system, augmented with some simple constructs to represent sets of queries, to determine if a query (or set of queries) typechecks. Working together, these two techniques allow us to identify (1) what query strings are executed by the Java code, (2) whether these query strings typecheck given the parameters that the Java code has set on them, and (3) whether the results of these queries are used correctly in the Java code.. For deep refactoring, the main challenge lies in updating raw strings that represent JPA queries or fragments of queries which are concatenated together by the Java code. Fragments are particularly difficult, not only for an automated tool, but also for humans, because there is no context available for understanding the query -it is difficult to tell if a given substring should be refactored without knowing the context in which the substring is typed.. We address this challenge by building upon deep typechecking as follows. First our algorithm tags each query fragment with an identifier that uniquely determines the Java string literal that the fragment originated from. The string dataflow analysis used for deep typechecking is used to compute the set of complete tagged query strings that reach an execution site. Next, our algorithm performs refactorings in the context of an entire query, using the deep typechecker as a subroutine to determine the types of identifiers. Finally, our algorithm propagates the changes back to the Java code using the tags.. In summary, this paper takes a step towards enabling developers to safely combine different layers using efficient and flexible call-level interfaces. In particular, we make the following concrete contributions:. • Deep Typechecking. We present techniques for checking that the parameters set by the Java code on JPA queries are of the correct type, that all parameters of a query are set before it is executed, and that the returned values of JPA queries are used correctly in the Java code (Section 3). Figure 2 . Query Type Checking. • Deep Refactoring. We present techniques for performing class-rename and field-rename refactorings on classes and fields that may appear in query strings (Section 4). Our refactoring technique renames not only direct references from the Java code, but also references that appear in query strings that the Java code manipulates.. • Experimental validation. We implemented the above techniques in a tool called QUAIL, and present the results of running QUAIL on a variety of benchmarks (Section 5), the largest of which is Roller, a web blogging software system comprising 82,907 lines of code. We show that QUAIL is able to verify that 84% of query execution sites in the Java code use types correctly (the remaining cases are false-positives where we incorrectly report safe query executions as potential errors), and we show that our tool reduces the number of places in the code that a programmer must look at to perform refactorings by several orders of magnitude. We begin with an overview of Deep Typechecking and Refactoring using simplified versions of examples taken from the Roller code base. In this paper we presented QUAIL, a tool for deep typechecking and refactoring Java code that uses query strings to interact with databases, thereby allowing programmers to use the efficient and flexible string-based interface in a safe manner. Based on our experiences building and evaluating QUAIL, we believe there are several avenues for future work. First, we would like to improve the precision of our technique to eliminate the few false positives where we incorrectly flag safe query executions as potential errors. For example, we would like to extend QUAIL so that it can typecheck queries with dynamically generated parameters, i.e., where the parameters are created and set by iterating over a list or array. Second, we would like to enrich the type system to prove more properties statically. For example, verifying that queries which are called with getSingleResult indeed determine at most one object. This would require a more precise modelling of the constraints of the database schema, e.g. primary keys, to verify that the query returned a unique result. Further, we would like to do some basic semantic sanity checking on the queries, e.g. that the WHERE clause is not a tautology or contradiction. Finally, we would like to extend our techniques to obtain deep versions of other software engineering tasks that are standard within a single language. Examples include deep code completion, where the tool would run in an online manner and suggest class and field completions for query string fragments, and deep impact analysis, where the tool would alert the programmer to the string fragments that may change due to alterations in the database schema or vice versa. The research most closely related to our work can be partitioned into several categories.. Static Analyses for checking multi-lingual software are the most closely related line of work. Of these, we have drawn inspiration from [21] which gives a static technique for typechecking the SQL queries dynamically generated by programs using JDBC [8] . The technique is based on using a string analysis [3] to compute an automaton overapproximating the set of strings that can be sent as queries, and an algorithm for typechecking the automaton. In contrast to QUAIL, this work focuses on the typechecking the SQL queries against the database schema, and unlike QUAIL, ignores parameterized queries and return value type checking. Further, as JDBC provides lower-level access to the database (in contrast to the higher level Object-Relational Map of JPA), the question of deep refactoring does not arise.. Further afield, there have been several recently proposed static analyses for checking multilingual software. Examples include [7] which presents a type system and dataflow anal-ysis for checking the correctness of the OCaml/C foreign function interface, and [19] which presents a system for ensuring the type safety of programs that combine C and Java.. Orthogonal Persistence is an approach to integrating programming languages and databases in a manner that entirely sidesteps the need for deep typechecking and refactoring. Here, the entire database is exposed to the programmer as a collection of objects that can be navigated. Examples include the PJAMA [1] and THOR [12] projects. In this tight coupling, the string based interface is eliminated and hence one can directly use the language's typechecking and refactoring tools. The drawback with this approach is that it sacrifices the bulk-access optimizations possible by using SQL. To recover some of the benefits of these optimizations [22] proposes the use of abstract interpretation to statically extract SQL queries from the code. It remains to be seen whether in practice the query extraction yields systems with competitive performance.. Programming Languages supporting SQL allow programmers to efficiently interact with the database while staying within a single programming language. This is achieved by providing syntax to describe queries in a manner that permits efficient compilation to SQL. Two classical examples are the DBPL [18] and Tycoon [15] languages. More recently proposals include the functional languages Kleisli [24] , and Links [5] which provides a single unified language for Web-programming. A more backwards-compatible approach are special extensions to existing languages, like Linq [2] for C , and [23] for Java. The most compatible approach is to embed queries as instances of special classes within Java [4] or C++ [16] . As for orthogonal persistence, each of these approaches eliminate the need for deep typechecking and refactoring. However, we conjecture that adoption has been limited by the fact query strings provide a more flexible and readable way to harness all of SQL, in contrast to these approaches which only incorporate restricted subsets. Moreover, there is a large amount of legacy code that would have to be rewritten to benefit from these techniques.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O