Extending the MVC Design Pattern towards a Task-Oriented Development Approach for Pervasive Computing Applications [original]

Extending the MVC Design Pattern towards a

Task-Oriented Development Approach for

Pervasive Computing Applications

Patrick Sauter1, Gabriel Vögler2, Günther Specht1, Thomas Flor2

1 Universität Ulm, Fakultät für Informatik, Abt. Datenbanken und Informationssysteme,

89069 Ulm, Germany

{patrick.sauter, specht}@informatik.uni-ulm.de

2 DaimlerChrysler, Research & Technology, Software Architectures, Postfach 2360,

89013 Ulm, Germany

{gabriel.voegler, thomas.flor}@daimlerchrysler.com

Abstract. This paper addresses the implementation of pervasive Java Web ap-

plications using a development approach that is based on the Model-View-

Controller (MVC) design pattern. We combine the MVC methodology with a

hierarchical task-based state transition model in order to achieve the distinction

between the task state and the view state of an application. More precisely, we

propose to add a device-independent TaskStateBean and a device-specific

ViewStateBean for each task state as an extension to the J2EE Service to

Worker design pattern. Furthermore, we suggest representing the task state and

view state transition models as finite state automata in two sets of XML files.

1 Introduction

The use of the Model-View-Controller design pattern (MVC, cf. [1]) is very common

in User Interface development. Yet, an important practical goal of pervasive applica-

tion development – maximizing the number of supported devices while minimizing

code redundancy – is not necessarily achieved by employing an arbitrary MVC-based

development methodology.

In particular, a typical problem of pervasive application development is to provide

client-adapted user interfaces [2]. For example, a dialog that fits onto a single Web

page on a PC (e.g. a complex form) must be fragmented into several sub-dialogs on a

device with a small screen size (e.g. a PDA or a cellphone).

MVC-based approaches allow supporting such adaptations without rewriting the

entire user interface code. A result of the decomposition of the architecture into

model, view and controller is that device-independent and device-specific code is

decoupled into separated components. In order to support an additional device, only

the view (and for more complex applications sometimes the controller) must be rewrit-

Proc. Int. Conf. on Architecture of Computing Systems - Organic and Pervasive Computing

(ARCS 2004), Augsburg, 23.-26. March 2004, Spinger-Verlag, LNCS 2981, 2004, pp. 309-321

ten or at least adapted. However, this might lead to many "similar" view and controller

components with partial code redundancy.

A widely used MVC-based pattern for J2EE applications is the Service to Worker

design pattern (cf. [3]). It covers many aspects of practical interest when implementing

a single-client (mainly desktop browser) Java-based Web application. Although it

does suggest using an explicit state transition model that is stored in an XML file, this

model does not fully satisfy the needs of pervasive applications with differing screen

flow on different devices. Only global transitions such as global JSP state transitions

(e.g. “switch from searchmask.jsp to resultlist.jsp”) are specified, so a device with a

different screen flow would require its very own screen flow model and thus probably

a different set of JSP files.

It is therefore necessary to identify similarities between the screen flow models of

the devices and introduce a more abstract task-based (as described in [4]) model that

all devices have in common. To take on this issue, we suggest using a two-stage hier-

archical model of JavaBeans to store information separately about the state of the

(device-independent) task flow and the state of the (device-specific) view flow of the

application.

This paper extends the Service to Worker design pattern in order to support multi-

device Web applications by introducing a task-based two-stage hierarchical state tran-

sition model.

The rest of the paper organizes as follows: In section 2, existing work in the range

of UI development for pervasive computing is discussed. Section 3 contemplates the

task-based development methodology, describes a task-based implementation algo-

rithm for pervasive Web applications and gives a suitable definition for the term

"task". In section 4, we take a look at the Service to Worker design pattern from the

viewpoint of pervasive computing. We will then introduce an extension and describe

an implementation approach for pervasive applications in greater detail, illustrated by

several UML diagrams and code examples. In section 5, we will discuss the additional

design-time and run-time benefits of the separation between an application’s task state

and its view state; more specially, we consider the possibilities to facilitate the devel-

opment process and the ability to change devices "on the fly".

2 Related Work

The specific requirements of pervasive applications have been widely discussed in [2,

4, 5, 6, 7]. In particular, Banavar et. al. [4] describe a programming model that strictly

treats task logic and user interaction separately. They make the suggestion to start with

creating a superior task-based model for program structure that covers the user's ab-

stract interaction and the application logic and then continue with creating a subordi-

nate navigation model that covers the flow of the view elements. At the time being, the

model-based methodology is not yet supported by major programming tools or design

patterns. Our suggested development strategy is fundamentally based on this task-

driven development methodology.

There are several pervasive computing projects that aim at devising a high-level UI

design language for abstract user interaction (cf. [8, 9] as well as IBM’s PIMA project

[http://www.research.ibm.com/PIMA/]). Any of these approaches proceed similarly:

the modeling phase of the abstract user interaction in the respective language is fol-

lowed by a semi-automatic generation of the device-specific code. Although our paper

describes a less automated development process, the two-stage hierarchical state tran-

sition model presented in the subsequent section could well be used by any of these

languages to support the advanced run-time characteristics described later in this pa-

per. Furthermore, the two JavaBeans specified in section 4 could also be created by

the code generator of the respective high-level language.

In general, the contribution of this paper is the combination of the well-proven

MVC methodology with the separation of an application’s task state and its view state.

The result is a practical task-based implementation guideline for pervasive Java-based

Web applications.

3 The Task-Based Development Approach

As a general approach for developing pervasive applications with multi-device capa-

bilities, Banavar et. al. [4] suggest modeling the task logic prior to the user interaction

(i.e. the screen flow). The task flow of an application, as we define it, must, in contrast

to its screen flow and, without loss of generality, be common to all devices. We there-

fore need to redefine or at least narrow the definition of the term task so that it satis-

fies our requirements.

A task, as defined by Bergman et. al. [10], is a unit of work to be performed by the

user. This definition, however, does not specify the granularity of a task in comparison

with a subtask. A task, as we use it, must comply with the following requirements:

• It must not be too fine-grained such that a step in a subsequent task could be part

of the current task without affecting the functionality of the application. For ex-

ample, all text fields of a search mask that a user can fill in without requiring any

additional system interaction must necessarily belong to the same task.

• It must not be too coarse-grained such that there exist two steps within a single

task with one step requiring input data that is to be produced as the output of an-

other step within the same task. For example, the search mask and the result list of

a search engine query ought to belong to separate tasks.

In other words, a task must consist of steps which logically belong together from both

the user's and the system's point of view. The purpose of this definition is that a task

could well be displayed on a single view, i.e. on a single Web page.

Example

The database application discussed in this section is a typical example for Web-based

intranet applications: A company wants to make its corporate employee directory (cf.

Figure 1) accessible from various client platforms, e.g. a typical desktop browser and

a PDA (with an HTML browser). On a desktop PC, due to its plentiful screen size, the

application might consist of only three Web sites: the search mask, the result list and

an additional more detailed employee profile page. Although it might be only a rule of

thumb, in this example each of the three desktop browser Web sites should represent

exactly one task according to the preceding definition: the entire search mask as the

entry point, the result list displaying the results of the directory query and the detailed

employee profile page displaying the results of a second query of the selected em-

ployee displaying a greater number of attributes from the directory. That is, task flow

and screen flow are identical on the desktop browser.

Fig. 1 depicts how the first page of this example Web application might be rendered on a desk-

top and a PDA browser, where only the most frequently used input fields are displayed at first.

expand

reduce

On the PDA, however, task flow and screen flow might differ because of its limited

screen size. For example, it might be sensible to display only a reduced search mask

as an entry point with a subset of only the most frequently used input fields (e.g. only

first and last name as well as the department code) and an additional “Expand search

mask” button that would bring on all search fields. This click on the “Expand search

mask” button would only alter the view state of the application, not its task state. In

expanded state, the user would be expected to scroll down in order to find all search

fields. We shall refer to this example in subsequent sections.

A Task-Based Design Cycle for Pervasive Computing Applications

The idea of a task-driven development methodology must now be put into a more

concrete and practical development guideline. As an implication to our definition of

the term “task” in combination with the task-based development approach, we suggest

that the development of a pervasive Web application should proceed as follows:

1. Model the task flow of the application in order to express user requirements, e.g.

using a UML activity diagram.

2. Since each of these tasks should comply with the above definition, each of these

tasks is to be represented by a single view component. That is, create a view com-

ponent (e.g. an empty JSP file) for each device and for each task.

3. For each target device and for each task, check if the capabilities of the device

allow a one-to-one relationship between a task and a view. In other words, deter-

mine if it is feasible and sensible to display the task on the particular device as a

single view component.

4. If this is the case for a particular view component, the view flow and the task flow

are identical for this page and no changes have to be made. Go to step 7.

5. If this is not the case, the task has to be assigned several view states. That is, part of

the task has to be grouped on separate screens or maybe even left out completely,

e.g. on a cellphone with an extremely restricted screen size and very little memory.

6. Use the additionally available view state information to enable the user to switch

from one view of the same task to another. In a J2EE Web application environ-

ment, this could be accomplished by adding embedded Java code to a given JSP

file (which represents the task state). This file retrieves the view state information

and thereby decides which segment of the JSP file (e.g. either the “reduced” or the

“expanded” part) to display. Furthermore, view state change buttons must be pro-

vided, e.g. by inserting an “Expand search mask” button.

7. Optimize the device-specific presentation, for example by adjusting font sizes or

defining CSS files.

The advantages of this approach are the clear-cut separation between global task

state and view state, both at design-time (a Web design team could create complex

view flow structures without affecting the team implementing task flow and business

logic) and at run-time (as we will show in section 5).

See Figure 2 for how this algorithm might transform into application states and

state transitions for the previously mentioned employee search example.

searchmask.jsp

resultlist.jsp

employeeprofile.jsp

expand

reduce

showReduced

SearchMask

showEntire

SearchMask

startSearch

backTo

SearchMask

backToSearchMask

...

... ...

...

... ...

...

task state

view state

Fig. 2 depicts a possible result of the algorithm for the previously mentioned corporate direc-

tory application example on a PDA device. The labels of the arrows correspond to action

names. Each task state is represented by a single JSP file.

4 Design Patterns for the Implementation

After introducing our task-based design cycle for pervasive computing applications we

now want to discuss a design pattern for its realization within a J2EE environment. In

order to add multi-device capabilities, we now take up the idea of separating task logic

and user interaction and therefore extend a well-known design pattern of the J2EE

presentation tier [3]:

The Service to Worker Pattern

The Service to Worker pattern is a design pattern that primarily addresses the devel-

opment of single-client Web applications. In particular, it decouples business logic

from the view components and allows explicit state transition handling. We therefore

consider it suitable for the type of Web applications discussed in this paper, i.e. typi-

cal thin-client intranet applications. Although many of the succeeding concepts can

also be used in combination with other Core J2EE Patterns

[http://java.sun.com/blueprints/corej2eepatterns/] or the more general MVC design

pattern, the Service to Worker pattern provides the best basis for our extensions to

facilitate pervasive computing application development.

The Service to Worker pattern is a combination of the Front Controller and the

View Helper patterns in the J2EE presentation tier. For a more rigorous discussion on

the Service to Worker J2EE design pattern, cf. [3] and [http://java.sun.com/j2ee/]. Its

main feature added to the MVC architecture is the ability to comprise the state transi-

tion logic into a dedicated dispatcher class rather than the controller. The dispatcher

accesses an XML file that defines all existing states and associates user actions with

state transitions.

In contrast to existing MVC-based frameworks for pervasive computing Web ap-

plications (e.g. MVC-Portlets of IBM WebSphere Everyplace Access Portal Server

4.2.1), the concept described in this paper does not use multiple device-specific con-

troller classes. In our approach, the controller has only two responsibilities: pass on

every request to the dispatcher and, when required, call the appropriate business ser-

vice. Yet, these business services are only called when the application’s task state

changes. And since all devices have the underlying task state transition model in

common, a single device-independent controller class is sufficient.

Extension of the Service to Worker Pattern

The Service to Worker pattern does not yet fully satisfy the needs of pervasive com-

puting development. As mentioned in the previous subsection, Sun Microsystems'

specification of the Service to Worker pattern introduces a dispatcher class to handle

state transitions. However, neither does it prescribe how to model the state transition

logic (inside the XML file), nor does it include a description of the runtime compo-

nent which realizes this model. Furthermore, since the Service to Worker pattern is

designed for single device access, the issue of device-specific views has to be ad-

dressed. Even the algorithm provided in section 3 does not give any implementation

details. We will take on these issues now by describing an implementation approach in

great technical detail.

For the purpose of modeling the device-independent state transition logic we use an

XML file named mappings.xml (as suggested by

[http://java.sun.com/blueprints/patterns/FrontController.html]). For the device-specific

view logic we utilize an additional file named viewmappings.xml for each sup-

ported device. Both describe a finite state automaton, defining states, actions and

transitions.

We suggest implementing these automata as two dedicated JavaBeans classes:

TaskStateBean and ViewStateBean (cf. Figure 3). Both are initialized with

data of the XML files described above. At runtime, they provide a getState() and

a doAction(String) method. The former returns the current state and the latter

performs the assigned action and returns either the new state or throws an exception if

the action is illegal. Additionally, the TaskStateBean can reference a device-

specific ViewStateBean for each task state if the view state of a previously com-

pleted task has to be retained. For example, if the user clicks on “Back to search

mask” which he left in expanded state, it could again be rendered in expanded state

when the user returns.

Device-specific renderings are achieved by view components (JSP files) that are

particular to exactly one device. There exists a single JSP file for every task/device

combination which contains view-specific markup and therefore must also include

code for accessing the ViewStateBean information. All JSP files may be placed

together with the appropriate viewmappings.xml in a device-specific subfolder

(e.g. /pda) in order to deliver straightforward naming conventions.

Client

Client Controller

Controller Dispatcher

Dispatcher View

View

Helper

TaskStateBean

TaskStateBean ViewStateBean

ViewStateBean

1..*

Fig. 3 depicts the class diagram of the extended Service to Worker design pattern. The added

elements are the two JavaBeans classes.

After setting up the general structure we now want to discuss the component inter-

action by Figures 4 and 5 which refer to the example described above.

Consider the situation in which a PDA user fills in the search mask of the corporate

employee directory example. In this scenario, the TaskStateBean is in the state

"searchmask.jsp" and references the PDA version of the ViewStateBean

which initially is in the state "showReducedSearchMask".

Next, the user clicks the "start search" button. This leads to the creation of an

HTTP GET request with the action parameter "startSearch", which is then sent to

the controller (e.g., http://host/controller?action=startSearch). At this point, the re-

quest object will be enriched with information about the delivery context by the

pervasive computing environment. For example, the IBM WebSphere Everyplace

Access Server looks up the User-Agent string of the HTTP header in its device

database and maps it to one of its pre-defined device class (e.g. “Pocket Internet Ex-

plorer” is recognized as a “PDA” device). An attribute indicating this piece of infor-

mation about the device class will then be added to the request object.

The controller reads the action value ("startSearch"), calls some helper class

to handle the query (i.e., invoke a LDAP service) and then calls the dispatcher to dis-

play the results. Next, the dispatcher calls doAction("startSearch") of the

TaskStateBean in order to determine what JSP file to display next. In this case,

the action causes a task state transition, so the return value is "resultlist.jsp".

Additionally, the TaskSateBean initializes a ViewStateBean for the new task

state and sets it to the default view state. According to the device class detected ear-

lier, the dispatcher now displays "resultlist.jsp" of the /pda directory. Be-

fore generating the final markup, the embedded code of the JSP file queries the

ViewStateBean to decide which view elements to display. Figure 4 gives an im-

pression of how the internal handling sequence of the application for the “Start

search” scenario might look like.

Client Controller Dispatcher

View

request

delegate

request

get data

Helper

ValueBean

Business

Service

get property

retrieve content

TaskState

Bean

do action ViewState

Bean

get state

“startSearch"

Fig. 4 depicts the internal sequence for handling a click on the “Start search” button, i.e. a

typical task state changing action.

The internal object interaction of a click on the “Expand search mask” (instead of

"start search"), however, might look fundamentally different. Therefore, Figure 5

(view state change) differs from Figure 4 (task state change) in so far as no business

service has to be accessed.

Client Controller Dispatcher View TaskState

Bean ViewState

Bean

request delegate

request do action

"reload"get state

do action

ValueBean

get property

“reduce"

“showRedu-

cedSearch-

Mask"

Fig. 5 refers to a typical view state changing action such as a click on the “Reduce search

mask” button on the PDA.

In the situation of Figure 5, the submitted action ("reduce") is not a task state

changing action, so the TaskStateBean delegates the action handling to the

ViewStateBean. After the ViewSateBean has changed its state, the Task-

StateBean returns the old task state ("searchmask.jsp"). Consequently, the

dispatcher calls the same JSP file ("searchmask.jsp"). But this time, the get-

State() method inside the embedded JSP code returns a different view state, which

causes to display different markup.

Figures 6 and 7 give an impression of how the previously mentioned search mask

of the employee directory example might be put into XML and JSP code.

<taskstate> <name>searchmask.jsp</name>

showReducedSearchMask

</defaultviewstate>

<viewstate> <name>showReducedSearchMask</name>

<actionname>expand</actionname>

<switchTo>showEntireSearchMask</switchTo>

</transition>

...

</viewstate>

<viewstate> <name>showEntireSearchMask</name>

<actionname>reduce</actionname>

<switchTo>showReducedSearchMask</switchTo>

</transition>

...

</viewstate>

...

</taskstate>

...

Fig. 6 depicts how the /pda/viewmappings.xml file might look like; cf. also Fig. 2.

<html>

...

<% if (myViewStateBean.getState().

equals("showEntireSearchMask")) { %>

...

<a href="controller?action=reduce">Reduce Mask</a>

<% } else if (myViewStateBean.getState().

equals("showReducedSearchMask")) { %>

...

<a href="controller?action=expand">Expand Mask</a>

<% } %>

...

</html>

Fig. 7 shows the corresponding JSP file /pda/searchmask.jsp.

Notice that addressing actions is a mere implementation detail and depends on the

set of available technologies of the Web application server. For a JSP-based portal

environment, for example, the Java Specification Request (JSR) 168 (cf.

[http://www.jcp.org/en/jsr/detail?id=168] and Figure 8) defines a dedicated set of JSP

tags for generating dynamic Uniform Resource Identifiers (URIs) which, when re-

quested, enforce the invocation of an action handling method.

<portlet:param name="action" value="expand"/>

</portlet:actionURL>" >Expand Search Mask</a>

Fig. 8 shows sample JSP code according to the JSR 168 (version 1.0) specification.

In general, this section points out that the separation of task state and view state ef-

fects the implementation of Web application in two ways: Both the dynamic informa-

tion about the current state (which in this case is represented by JavaBeans objects)

and the static state transition information (which we suggested storing in XML files)

have to be subdivided into their task state and view state components.

5 Additional Benefits of the Separation between Task State and

View State

The previous section describes a general solution of how to design task-based perva-

sive computing applications. We now discuss some additional benefits of our ap-

proach, which provides a solution to some typical pervasive computing issues.

Changing Devices “on the Fly”

The strict separation of task state and view state allows the implementation of a rather

advanced feature that lets the behavior of the application move closer to the vision of

pervasive and ubiquitous computing that applications should seamlessly move from

one device to another tracking the user [6, 7].

Consider the situation that a user of a Web application submits a query to the em-

ployee search engine of his company on his PDA and alters the view state of the result

list that is particular to this gadget. As he enters his office, he doesn't want to enter the

query again on his desktop PC, so he logs in and in case the task state of the previous

session and its value beans have been left unchanged, he is shown the result list in a

desktop PC browser format, and not the search mask.

This behavior could obviously not be realized if the two devices had different task

models, e.g. different JSP file names, because even if the state of the application was

handed over to the other device, it would not be guaranteed that this state (e.g.

“somePdaSpecificResultList.jsp”) still is defined for the new device (e.g. if the desk-

top browser only features a single “resultlist.jsp” file). The separation of task state and

view state is the key to support such behavior. When using the method described in

this paper, it is assured that the two devices have their task state models in common.

So, a dynamic device change could be implemented by simply handing over the “old”

TaskStateBean to the “new” dispatcher class of the device. More precisely, the

ViewStateBean could either be destructed or retained as a separate object to pos-

sibly support the use of a single Web application with multiple devices in succession.

That is, the implementation effort would merely be limited to the provision of a cen-

tralized TaskStateBean (and value beans) management, but still the underlying

application and business logic architecture would not have to be changed at all.

Using the XML Task Definition for Code Generation

Now, all the information required for both task state and view state transitions is com-

pletely accessible in the XML files. This allows partial automatization of the devel-

opment process as defined in section 3.

One way to utilize this information is to manually create one JSP file for each task

state as specified in the mappings.xml file (e.g. including typical HTML or WML

headers) and to create one subsection inside the appropriate JSP file for each view

state based on the information in the viewmappings.xml file. (This is essentially

the functionality of steps 2 and 6 in the algorithm of section 3.) For small projects,

manual execution of the algorithm might be sufficient. However, the task model in-

cluded in the XML files described above is a good starting point for code generation,

which could be helpful for larger projects with changing requirements.

Furthermore, since the task state transition information is also included in the map-

pings.xml file, the development environment could also offer the developer the

appropriate set of actions that should be used in the respective JSP file. For example,

the development environment might, based on the information given in the map-

pings.xml file, suggest that the searchmask.jsp file contains a link or a button

with the action "startSearch".

Also the viewmappings.xml data could be used in a similar way. In the exam-

ple of the finite view state automaton of the search mask (cf. Figure 2), the develop-

ment environment could generate navigation elements (e.g. a navigation bar) inside

the search mask automatically. This navigation element would offer the user the func-

tionality to switch from one view to another, e.g. from reduced to expanded state.

The main benefit of this approach is on the one hand less implementation effort and

on the other hand assistance in maintaining a consistent user interface, because

changes made to the XML files will be cascaded down to the JSP files.

6 Conclusions

This paper describes a development approach for Web applications that support mul-

tiple devices in a J2EE environment. The separation of task state and view state allows

a more structured development approach and advanced run-time characteristics. In

particular, device changes on the fly can be supported with little effort by retaining the

device-independent task state information. The cost of adding support of another de-

vice to a given Web application involves merely the presentation and view state layer.

No changes have to be made to the task state transition model, while developers are

still offered full control of design and usability (e.g. grouping and ordering) issues.

However, this approach does not work for applications with device-specific task

flow, e.g. if an internet shop requires a cellphone customer to sign another agreement

before an order can be legally accepted. Furthermore, the XML file schemas used in

the example are only suggestions and have not yet been formally specified.

References

1. E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable

Object-Oriented Software. Addison-Wesley, 1995.

2. G. Voegler, T. Flor: Die integrierte Client-Entwicklung für PC und Mobile Endgeräte

– am Beispiel der Portaltechnologie. In: Klaus Dittrich, Wolfgang König, Andreas

Oberweis, Kai Rannenberg, Wolfgang Wahlster (eds.): Informatik 2003 – Innovative

Informatikanwendungen (Band 1). GI-Edition – Lecture Notes in Informatics (LNI),

P-34. Köllen Verlag, Bonn, 2003, 207-211.

3. Sun Microsystems. Core J2EE Patterns. 2002.

http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceToWorker.html

4. G. Banavar, J. Beck, E. Gluzberg, J. Munson, J. Sussman, D. Zukowski. Challenges:

An Application Model for Pervasive Computing. August 2000. Proc. 6th ACM

MOBICOM, Boston, MA.

5. J. Burkhardt, H. Henn, S. Hepper, K. Rindtorff, T. Schäck. Pervasive Computing:

Technology and Architecture of Mobile Internet Applications. Addison-Wesley,

2002.

6. U. Hansmann, L. Merk, M. Nicklous, T. Stober. Pervasive Computing Handbook.

Springer, 2001.

7. G. Banavar, A. Bernstein. Software Infrastructure and Design Challenges for Ubiqui-

tous Computing Applications. 2002. Communications of the ACM, December 2002.

8. F. Giannetti. Device Independence Web Application Framework (DIWAF). HP Labs.

W3C Workshop on Device Independent Authoring Techniques, 25-26 September

2002, SAP University, St. Leon-Rot, Germany.

9. F. Paternò, C. Santoro. One Model, Many Interfaces. Proceedings Fourth Interna-

tional Conference on Computer-Aided Design of User Interfaces, pp. 143-154, Klu-

wer Academics Publishers, Valenciennes, May 2002.

10. L. Bergman, T. Kichkaylo, G. Banavar, J. Sussman. Pervasive Application Develop-

ment and the WYSIWYG Pitfall. Lecture Notes in Computer Science, vol. 2254,

2001, pp. 157-172, May 2001.