TEAM LinG
Hershey • London • Melbourne • Singapore
IDEA GROUP PUBLISHING
Advanced Topics in
Database Research
Volume 4
Keng Siau
University of Nebraska-Lincoln, USA
TEAM LinG
Acquisitions Editor: Mehdi Khosrow-Pour
Senior Managing Editor: Jan Travers
Managing Editor: Amanda Appicello
Development Editor: Michele Rossi
Copy Editor: April Schmidt
Typesetter: Cindy Consonery
Cover Design: Integrated Book Technology
Printed at: Integrated Book Technology
Published in the United States of America by
Idea Group Publishing (an imprint of Idea Group Inc.)
701 E. Chocolate Avenue, Suite 200
Hershey PA 17033
Tel: 717-533-8845
Fax: 717-533-8661
E-mail:
Web site:
and in the United Kingdom by
Idea Group Publishing (an imprint of Idea Group Inc.)
3 Henrietta Street
Covent Garden
London WC2E 8LU
Tel: 44 20 7240 0856

Juan Trujillo, Universidad de Alicante, Spain
Sergio Luján-Mora, Universidad de Alicante, Spain
Il-Yeol Song, Drexel University, USA
Chapter III
Does Protecting Databases Using Perturbation Techniques
Impact Knowledge Discovery? 96
Rick L. Wilson, Oklahoma State University, USA
Peter A. Rosen, University of Evansville, USA
Chapter IV
Simultaneous Database Backup Using TCP/IP and a Specialized
Network Interface Card 108
Scott J. Lloyd, University of Rhode Island, USA
Joan Peckham, University of Rhode Island, USA
Jian Li, Cornell University, USA
Qing (Ken) Yang, University of Rhode Island, USA
TEAM LinG
Chapter V
Towards User-Oriented Enterprise Modeling for
Interoperability 130
Kai Mertins, Fraunhofer Institute IPK, Berlin
Thomas Knothe, Fraunhofer Institute IPK, Berlin
Martin Zelm, CIMOSA Association, Germany
Chapter VI
Using a Model Quality Framework for Requirements
Specification of an Enterprise Modeling Language 142
John Krogstie, SINTEF ICT and IDI, NTNU, Norway
Vibeke Dalberg, DNV, Norway
Siri Moe Jensen, DNV, Norway
Chapter VII
Population of a Method for Developing the Semantic Web Using

COGEVAL: Applying Cognitive Theories to Evaluate
Conceptual Models 255
Stephen Rockwell, University of Tulsa, USA
Akhilesh Bajaj, University of Tulsa, USA
Chapter XIII
Quality of Analysis Specifications: A Comparison of FOOM
and OPM Methodologies 283
Judith Kabeli, Ben-Gurion University, Israel
Peretz Shoval, Ben-Gurion University, Israel
Chapter XIV
Interoperability of B2B Applications: Methods and Tools 297
Christophe Nicolle, Université de Bourgogne, France
Kokou Yétongnon, Université de Bourgogne, France
Jean-Claude Simon, Université de Bourgogne, France
Chapter XV
Possibility Theory in Protecting National Information
Infrastructure 325
Richard Baskerville, Georgia State University, USA
Victor Portougal, University of Auckland, New Zealand
Chapter XVI
Enabling Information Sharing Across Government Agencies 341
Akhilesh Bajaj, University of Tulsa, USA
Sudha Ram, University of Arizona, USA
About the Authors 367
Index 377
TEAM LinG
vi
Preface
The Advanced Topics in Database Research book series has been re-
garded as an excellent academic books series in the fields of database, soft-

cialized Network Interface Card”, introduces a prototype device driver, Real-
time Online Remote Information Backup (RORIB) in response to the problems
in current backup and recovery techniques used in e-business applications. The
chapter presents a true real time system that is hardware and software inde-
pendent that accommodates to any type of system as the alternative to the
extremely expensive Private Backup Network (PBN) and Storage Area Net-
works (SANs).
Chapter V, “Towards User-Oriented Enterprise Modeling for
Interoperability”, introduces user oriented Enterprise Modeling as a means to
support new approaches for the development of networked organizations. The
chapter discusses the structuring of user requirements and describes the initial
design of the Unified Enterprise Modeling Language (UEML) developed in a
research project sponsored by the European Union.
Chapter VI, “Using a Model Quality Framework for Requirements Speci-
fication of an Enterprise Modeling Language”, introduces a Model Quality Frame-
work that tackles the selection and refinement of a modeling language for a
process harmonization project in an international organization. The harmoniza-
tion project uses process models that prioritize what was to be implemented in
the specialized language and develops a support environment for the new har-
monized process.
Chapter VII, “Population of a Method for Developing the Semantic Web
Using Ontologies”, introduces an ONTOMETRIC method that allows the evalu-
ation of existing ontologies and making better selection of ontologies.
Chapter VIII, “An Evaluation of UML and OWL Using a Semiotic Quality
Framework”, systematically evaluates the Unified Modeling Language (UML)
and Web Ontology Language (OWL) models by using a semiotic quality frame-
work. The chapter highlights the strengths and weaknesses of the two model-
ing languages from a semiotic perspective. This evaluation better assists re-
searchers in the selection and justification of modeling languages in different
scenarios.

a controlled experiment, which compares the quality of equivalent analysis models
of the two methodologies, using a unified diagrammatic notation.
Chapter XIV, “Interoperability of B2B Applications: Methods and Tools”,
introduces a Web-based data integration methodology and tool framework called
X-TIME in supporting the development of Business-to-Business (B2B) design
environments and applications. The chapter develops X-TIME as the tool to
create adaptable semantic-oriented meta models in supporting interoperable
information systems and building cooperative environment for B2B platforms.
Chapter XV, “Possibility Theory in Protecting National Information Infra-
structure”, introduces a quantitative approach called Possibility theory as an
alternative to information security evaluation. This research responds to the
national concern of the security of both military and civilian information re-
sources due to information warfare and the defense of national information
infrastructures. This approach is suitable for information resources that are
vulnerable to intensive professional attacks.
Chapter XVI, “Enabling Information Sharing Across Government Agen-
cies”, attends to the increased interest in information sharing among govern-
ment agencies with respect to improving security, reducing costs, and offering
better quality service to users of government services. The chapter proposes a
comprehensive methodology called Interagency Information Sharing (IAIS) that
uses eXtensible Markup Language (XML) to facilitate the definition of infor-
mation that needs to be shared. The potential conflicts and the comparison of
IAIS with two other alternatives are further explored.
viii
TEAM LinG
These 16 chapters provide an excellent sample of the state-of-the-art re-
search in the field of database. I hope this book will be a useful reference and
a valuable collection for both researchers and practitioners.
Keng Siau
University of Nebraska-Lincoln, USA

TEAM LinG
2 Liu, Pu and Ruiz
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
complex workflow activities independently from their underlying
implementation mechanisms. Finally, it offers an open architecture that
supports user interaction as well as collaboration of workflow systems of
different organizations. Furthermore, our business process restructuring
approach enables the dynamic restructuring of workflows while preserving
the correctness of ActivityFlow models and related instances. We report a
set of simulation-based experiments to show the benefits and cost of our
workflow restructuring approach.
INTRODUCTION
The focus of office computing today has shifted from automating individual
work activities to supporting the automation of organizational business pro-
cesses. Examples of such business processes include handling bank loan
applications, processing insurance claims, and providing telephone services.
Such a requirement shift, pushed by technology trends, has promoted the
workflow management systems (WFMSs) based computing infrastructure,
which provides not only a model of business processes but also a foundation on
which to build solutions supporting the coordination, execution, and management
of business processes (Aalst & Hee, 2002; Leymann & Roller, 2000). One of the
main challenges in today’s WFMSs is to provide tools to support organizations
to coordinate and automate the flow of work activities between people and
groups within an organization and to streamline and manage business processes
that depend on both information systems and human resources.
Workflow systems have gone through three stages over the last decade.
First, homegrown workflow systems were monolithic in the sense that all control
flows and data flows were hard-coded into applications, thus they are difficult
to maintain and evolve. The second generation of workflow systems was driven

coordination and management of the flow of activities implemented as Web
services.
Although workflow research and development have attracted more and
more attention, it is widely recognized that there are still technical problems,
ranging from inflexible and rigid process specification and execution mecha-
nisms, insufficient possibilities to handle exceptions, to the need of a uniform
interface support for various types of workflows, that is, ad hoc, administrative,
collaborative, or production workflows. In addition, the dynamic restructuring of
business processes, process status monitoring, automatic enforcement of consis-
tency and concurrency control, recovery from failure, and interoperability
between different workflow servers should be improved. As pointed out
by Sheth et al. (1996), many existing workflow management systems use Petri-
nets based tools for process specification. The available design tools typically
support definition of control flows and data flows between activities by connect-
ing the activity icons with specialized arrows, specifying the activity precedence
order and their data dependencies. In addition to graphical specification lan-
guages, many workflow systems provide rule-based specification languages
(Dayal, Hsu & Ladin, 1990; Georgakopoulos et al., 1995). Although these
existing workflow specification languages are powerful in expressiveness, one
of the common problems (even those based on graphical node and arc program-
ming models) is that they are not well-structured. Concretely, when used for
modeling complex workflow processes without discipline, these languages may
result in schemas with intertwined precedence relationships. This makes debug-
ging, modifying, and reasoning of complex workflow processes difficult (Liu &
Meersman, 1996).
In this chapter, we concentrate our discussion on the problem of flexibility
and extensibility of process specification and execution mechanisms as well as
the dynamic restructuring of business processes. We introduce the ActivityFlow
specification language for structured specification and flexible coordination of
workflow activities and a set of workflow activity restructuring operators to

clude the chapter with a discussion on related works and a summary in the
Related Work and Conclusion section.
BASIC CONCEPTS OF ACTIVITY FLOW
Business Process vs. Workflow Process
Business processes are a collection of activities that support critical
organizational and business functions. The activities within a business process
have a common business or organizational objective and are often tied together
by a set of precedence dependency relationships. One of the important problems
in managing business processes (by organization or human) is how to effectively
capture the dependencies among activities and utilize the dependencies for
scheduling, distributing, and coordinating work activities among human and
information system resources efficiently.
TEAM LinG
Dynamic Workflow Restructuring Framework for Long-Running Processes 5
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
A workflow process is an abstraction of a business process, and it consists
of activities, which correspond to individual process steps, and actors, which
execute these activities. An actor may be a human (e.g., a customer represen-
tative), an information system, or any of the combinations. A notable difference
between business process and workflow process is that a workflow process is
an automated business process; namely, the coordination, control, and commu-
nication of activities is automated, although the activities themselves can be
either automated or performed by people (Sheth et al., 1996).
A workflow management system (WFMS) is a software system which
offers a set of workflow enactment services to carry out a workflow process
through automated coordination, control, and communication of work activities
performed by both humans and computers. An execution of a workflow process
is called a workflow case (Hollingsworth & WfMC, 1995; WfMC, 2003). Users
communicate with workflow enactment services by means of workflow clients,

permission of Idea Group Inc. is prohibited.
services, and interoperability with external workflow management systems. Our
focus is on the ActivityFlow process definition facilities, including the ActivityFlow
meta model (see ActivityFlow Meta Model section), the ActivityFlow workflow
specification language (see ActivityFlow Process Definition Language section),
and graphical notation for ActivityFlow process definition based on UML
Activity diagrams.
ActivityFlow Meta Model
The ActivityFlow meta model describes the basic elements that are used to
define a workflow process schema, which describes the pattern of a workflow
process and its coordination agreements. In ActivityFlow, a workflow process
schema specifies activities that constitute the workflow process and dependen-
cies between these constituent activities. Activities represent steps required to
complete a business process. A step is a unit of processing and can be simple
(primitive) or complex (nested). Activity dependencies determine the execution
order of activities and the data flow between these activities. Activities can be
executed sequentially or in parallel. Parallel executions may be unconditional;
that is, all activities are executed, or conditional, and only activities that satisfy
the given condition are executed. In addition, activities may be executed
repeatedly, and the number of iterations may be determined at run-time.
A workflow process schema can be executed many times. Each execution
is called a workflow process instance (or a workflow process for short), which
is a partial order of activities and connectors. The set of activity-precedence-
dependency relationships defines a partial order over the given set of activities.
The connectors represent the points where the control flow changes. For
instance, the point where control splits into multiple parallel activities is referred
to as split point and is specified using a split connector. The point where control
Figure 1. Reference architecture of Workflow Management Coalition
TEAM LinG
Dynamic Workflow Restructuring Framework for Long-Running Processes 7

of information objects to be accessed from different information resources.
• An activity: is either an elementary activity or a composite activity. The
execution of an activity consists of a sequence of interactions (called
Figure 2. UML graphical representation of AND-split, OR-split, AND-join,
and OR-join
TEAM LinG
8 Liu, Pu and Ruiz
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
events) between the performer and the workflow management system, and
a sequence of actions that change the state of the system.
• An elementary activity: represents a unit of work that an individual, a
machine, or a group can perform in an uninterrupted span of time. In other
words, it is not decomposed any further in the given domain context.
• A composite activity: consists of several other activities, either elementary
or composite. The nesting of activities provides higher levels of abstraction
that help to capture the various structures of organizational units involved
in a workflow process.
• A role: is a placeholder or description for a set of actors, who are the
authorized performers that can execute the activity. The concept of
associating roles with activities not only allows us to establish the rules for
association of activities or processes with organizational responsibilities but
also provide a flexible and elegant way to grant the privilege of execution
of an activity to individuals or systems that are authorized to assume the
associated role.
• An actor: can be a person, a group of people, or an information system, that
are granted memberships into roles and that interact with other actors while
performing activities in a particular workflow process instance.
• Information objects: are the data resources accessed by a workflow
process. These objects can be structured (e.g., relational databases), semi-

:CREDITCHECK, A
3
:CHECKRESOURCE, A
11
:INSTALLNEWCIRCUIT,
and B:ALLOCATECIRCUIT (see Figure 4(A)). A: TELECONNECT is ex-
ecuted when an enterprise’s client requests telephone service installation.
Activity A
1
:CLIENTREGISTER registers the client information, and activity
A
2
:CREDITCHECK evaluates the credit history of the client by accessing
financial data repositories. Activity A
3
:CHECKRESOURCE consults the facility
database to determine whether existing facilities can be used, and B:
ALLOCATECIRCUIT attempts to provide a connection by allocating existing
resources, such as allocating lines (C: ALLOCATELINES), allocating slots in
switches (A
8
:ALLOCATESWITCH, A
9
:ALLOCATESWITCH), and preparing
a bill to establish the connection (A
10
:PREPAREBILL) (see Figure 4(B)). The
activity of allocating lines (C:ALLOCATELINES) in turn has a number of
subtasks, such as selecting nearest central offices
(A

ActivityFlow provides a number of facilities to support advanced concepts,
such as a variety of possibilities for handling errors and exceptions. For example,
at the activity specification stage, we allow the workflow designers to specify
valid processes and the compensation activities. At run-time, additional possibili-
ties are offered to support recovery from errors or crashes by triggering
alternative executions defined in terms of user-defined compensation activities
or system-supplied recovery routines.
Time dimension is very important for the deadline control of workflow
processes. In ActivityFlow, we provide a construct to allow the workflow
designer to specify the maximum allowable execution durations for both the
activities (i.e., subactivities or component activities) and the process (i.e., top
activity). This time information can be used to compute deadlines for all activities
in order to meet an overall deadline of the whole workflow process. When an
activity misses its deadline, special actions may be triggered. Furthermore, this
time information plays an essential role in decisions about priorities and in
monitoring deadlines and generating time errors in the case that deadlines are
missed. It also provides the possibility to delay some activities for a certain
amount of time or to a specific date.
The third additional feature is the concept of workflow administrator
(WFA). Modern business organizations build the whole enterprise around their
key business processes. It is very important for the success of process-centered
organizations that each process has a WFA who is responsible for monitoring the
workflow process according to deadlines, handling exceptions and failures,
Figure 4. Telephone service provisioning workflow

TEAM LinG
Dynamic Workflow Restructuring Framework for Long-Running Processes 11
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
which cannot be resolved automatically. More specifically, the WFA is able to

1996) but also essential for correct coordination among activities in accomplish-
ing a workflow process. These basic requirements include:
• activity structure (control flow) and information exchange between actors
(data flows) in a workflow process;
• exception handling, specifying what actions are necessary if an activity
fails or a workflow cannot be completed; and
• activity duration, specifying the estimated or designated maximum allow-
able execution time for both the workflow process (top activity) and its
TEAM LinG
12 Liu, Pu and Ruiz
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
constituent activities. This time information is critical for monitoring
deadlines of activities and for providing priority attributes, specifying
priorities for activity scheduling.
Main Components of a Workflow Specification
In ActivityFlow, a workflow process is described in terms of a set of
activities and the dependencies between them. For presentation convenience in
the rest of the chapter, we refer to a workflow process as top activity and
workflow component activities as subactivities. We use activities to refer to both
the process and its component activities when no distinction needs to be made.
Activities are specified by activity templates or so-called parameterized
activity patterns. An activity pattern describes concrete activities occurring in
a particular organization, which have similar communication behavior. An
execution of the activity pattern is called an instantiation (or an activity instance)
of the activity pattern. Informally, an activity pattern consists of objects,
messages, message exchange constraints, preconditions, postconditions, and
triggering conditions (Liu & Meersman, 1996).
Activities can be composed of other activities. The tree organization of an
activity pattern a is called the activity hierarchy of α. The set of activity

business process or in the organization. Each actor is described by actor ID
and role name. We distinguish two types of roles in the first prototype
implementation of ActivityFlow: user and system, denoted as USER and
SYS respectively.
• Data Declaration: The data declaration unit consists of the declaration
of the classes to which the parameters of the activity belong and the set of
messages (or methods) needed to manipulate the actual arguments.
Constraints between these messages are also specified in this unit (Liu &
Meersman, 1996).
• Procedure: The procedure unit is defined within a begin and end bracket.
It describes the composition of the activity, the control flow and data flow
of the activity, and the pre- and postcondition of the activity. The main
component of the control flow includes activity-execution-dependency
specification, describing the execution precedence dependencies between
children activities of the specified activity and the interleaving dependen-
cies between a child activity and children of its siblings or between children
activities of two different sibling activities. The main component of the data
flow specification is defined through the activity state-transition dependen-
cies.
Dynamic Assignments of Actors
The assignment of actors (humans or information systems) to activities
according to the role specification is a fundamental concept in WFMSs. At run-
time, flexible and dynamic assignment resolution techniques are necessary to
react adequately to the resource allocation needs and organizational changes.
ActivityFlow uses the following techniques to fulfill this requirement:
• When the set of actors is empty, the assignment of actors can be any users
or systems that belong to the roles associated with the specified activity.
When the set of actors is not empty, only those actors listed in the
associated actor set can have the privilege to execute the activity.
• The assignment of actors can also be done dynamically at run-time. The

activities declaratively and incrementally, allowing reasoning about correctness
and security of complex workflow activities independently from their underlying
implementation mechanisms.
In addition, we provide four constructs to model various dependencies
between activities. They are precede, enable, disable, and compatible. The
semantics of each construct are formally described in Table 1. The construct
precede is designed to capture the temporary precedence dependencies and the
existence dependencies between two activities. For example, “A precede B”
specifies a begin-on-commit execution dependency between the two activities:
“B cannot begin before A commits”. The constructs enable and disable are
utilized to specify the enabling and disabling dependencies between activities.
One of the critical differences between the construct enable or disable and the
construct precede is that enable or disable specifies a triggering condition and
an action being triggered, whereas precede only specifies an execution prece-
dence dependency as a precondition that needs to be verified before an action
can be activated, and it is not an enabling condition that, once satisfied, triggers
the action. The construct compatible declares the compatibility of activities A
1
and A
2
. It is provided solely for specification convenience since two activities are
compatible when there is no execution precedence dependency between them.
TEAM LinG