A Methodology for Planning, Analysis, Design
and Implementation of Collaborative Databases:
Introducing AWT Software
by:
Farhad Daneshgar
School of Computing Sciences,
University of Technology, Sydney (Australia)
e-mail: fdaneshg@socs.uts.edu.au
Abstract
This paper is based on previous work on collaborative process modelling, and introduces a
methodology for the design and implementation of databases that specifically maintain actors'
awareness about various aspects of collaboration. This collaborative database system can be used as a
complementary subsystem in other types of collaborative databases systems and workflow applications.
Process Awareness Framework (PAF) is used to derive a set of collaborative structures (or, structures
for short) that can be used for constructing the database. Using this framework, a model of collaborative
process is built first. This model is representative of a collaborative process which uses a a set of
collaborative semantic objects and their relationships to one another within the process. This model is
then used to identify the collaborative structures within the process that carry awareness information
relevant to the process. In other words, these structures are basically records consisting of a set of
collaborative semantic objects/concepts that together make up various levels of awareness of the actors
within the collaborative process. These structures can then be used to populate the proposed
collaborative database. This paper also introduces, for the first time, a software that implements this
methodology using a network management application.
Introduction
Despite the exceptionally productive and long history of database system research,
research on analysis, design and implementation of the collaborative databases is still
in its infancy. Currently there are very few methodologies for supporting activities
involved in planning, analysis, design and implementation of collaborative database
applications during their lifecycles.
Collaborative databases are now becoming the underlying framework of CSCW
(Computer Supported Cooperative Work) systems, and are fundamentally changing
the way many organisations operate. The collaborative database introduced in this
paper is a special kind of database that specifically supports interactions/collaboration
among a group of collaborating actors by providing required awareness information to
the actors. This database can also be used to identify communication improvement
prriorities within the collaborative process by identifying collaborative objects that
need to be put within the focus of the actors in order to satisfy certain organisational
communication requirements that relate to the collaboration among the actors.
This paper provides one such methodology for planning, analysis, design and
implementation phases of the collaborative database lifecycle. Section 1 of this paper
is allocated to an overview of the Process Awareness Framework (PAF) and how this
framework can be used to build a collaborative process model . Section 2 describes
how to derive and normalise structures from this model, and to design the proposed
darabase system. Section 3 deals with implementation issues of the proposed
collaborative database and introduces the Aware Ware Template (AWT) software
which was developed by the writer for this purpose. AWT is a LotusNOTES-based
database template which is based on the methodology of this paper. Conclusions are
made in the final Section.
1. An overview of the Process Awareness Framework (PAF)
PAF was first introduced by the writer as a means by which:
(i)
awareness levels of the actors who perform various tasks (by assuming certain
roles) within the collaborative process can be measured,
(ii) communication improvement priorities in collaborative processes can be
identified, and
(iii) the collaborative process can be progressively improved [Daneshgar 97a] .
PAF consists of the following two components:
(i)
(ii)
a Collaborative Business Process Map (CBPM), and
a new model for process awareness of the actors within the collaborative
process.
The above two components are discussed in more details in the following paragraphs.
(i) Collaborative Business Process Map (CBPM)
CBPM is a planning and analysis tool that maps a collaborative process into a number
of collaborative semantic objects that are linked together to implement certain process
goal.
CBPM is a connected graph made of several objects serving as its arcs and vertices.
Readers are advised to refer to [Daneshgar 98] for mathematical formalisation of CBPM.
Figure 1 shows CBPM for a network management process where a group of network
specialists and network users collaboratively participate in a network troubleshooting
process (see [Ray 96] and [Daneshgar 97b] for more details).
In this Figure, the User reports the problem to the Operator. Operator assigns a
'trouble ticket' (or T-Ticket) to the problem and then sends it to the 'Technician' for
technical considerations. Technician fixes the problem and arranges a meeting with
the Test Coordinator for further tests. Technician may then place a Change Request to
the Change Manager for changing certain aspects of the network in order to apply the
solution to the troubled network. Change Manager may then discuss the issue with the
Users and assess the impact of the proposed change. A list of the collaborative
semantic objects used in CBPM and their definitions follow:
Simple Tasks (also called 'Tasks'): These are objects with a set of attributes
and actions to achieve a specific goal using certain artefact called role artefact. Each
simple task is uniquely identifiable by a combination of one or more of its attributes
(eg., goal, ID number, description, etc.) and/or their actions. On the CBPM, simple
tasks are graphically represented by certain vertices. In Figure 1 simple tasks are
shown by 12 vertices labelled P1 to P12.
Collaborative Task: is composed of two simple tasks that have a common
goal; and as a result of this, they must share the same task artefact. A collaborative
task is always associated with a unique task artefact, as well as with two simple tasks.
On the CBPM, collaborative tasks are uniquely identifiable by a pair of associated
simple task vertices and an arc representing their common task artefact. The five
collaborative tasks in Figure 1 are:
1. P1-ta5-P2,
2. P11-ta3-P10,
3. P3-ta4-P4,
4. P6-ta2-P5, and
5. P9-ta1-P8.
Actors: These are human agents that enact a set of simple tasks by assuming
one or more roles. There is no direct graphical representation for these objects on the
CBPM, but actors are represented indirectly by the roles that these actors assume
within the process.
Role: a set of norms expressed in terms of obligations, privileges, and rights.
On CBPM, roles are uniquely identifiable by certain vertices. Roles in Figure 1are
shown by r1, r2, r3, r4 and r5.
Role Artefact: This object carries knowledge about how to perform a simple
task. Role artefacts are either possessed by an actor, or the actor knows how to obtain
them when required. For this reason it is assumed here that role artefacts can be stored
either within the actors' minds, (in such a way that others can not easily access and
use this knowledge), or are stored in certain organised knowledge bases in such a way
that the contents can only be fully understood by those who can access the stored
information. Role artefacts are graphically represented by the arcs that connect a role
vertex to a simple task vertex. The 12 role artefacts in Figure 1 are shown by ra1 to
ra12 .
Task Artefact: an object which carries knowledge about how various actions
associated with a collaborative task are executed. Contrary to the role artefacts where
they may or may not exist within organised knowledge bases, it is assumed here that
task artefacts are always kept within the organisational knowledge bases so that they
can be accessed and used by multiple actors when they enact various roles for
performing their collaborative tasks. On CBPM, each task artefact is uniquely
identifiable by an arc that connects two simple task vertices together. Examples of the
task artefacts are 'a business contract', 'an e-mail', 'a dataflow diagram prepared by an
analyst for a programmer', etc. In Figure 1, task artefacts are shown by ta1 to ta5.
Interaction Acts: these are the way actors exchange (or create, or modify) task
artefacts when performing a pair of related simple tasks. It may include any of the
following actions:
* sending a task artefact,
* transmission of a task artefact,
* creating a task artefact,
* modifying a task artefact,
* perception of a task artefact (ie., dealing with ambiguities), and
* processing (that is, using/exchanging) a task artefact.
Currently, there is no graphical representation of the interaction acts on CBPM.
Interaction: is a set of interaction acts. On the CBPM interactions are
represented indirectly by a unique task artefact.
P1
impact
control
ta5
P2
impact
analysis
ra9
P11
implmnt
change
request
ra11
r1
ra8
r2
Change
Mangr
User
P3
report
ra12
the
problem
ra10
ta3
ta4
P12
P10
place
change
request
P4
IWP
receive
problem
ra5
P9
arrange
meeting
ta1
P8
approve
time for
meeting
ra7
r4
ra2 Technici
an
ra4
P6
receive
T-Ticket
P5
ta2
assign
T-Ticket
r3
ra6
Operator
ra3
P7
try solve
problem
ra1
r5
Test
Coordin
ator
Figure 1: CBPM for a typical network management environment (extracted from [Daneshgar97b]
)
(ii) The Awareness Model:
This is the second component of the PAF. It provides a new definition for process
awareness of actors in collaborative processes, as well as a measure for this
awareness [Daneshgar 97a]. Awareness model defines process awareness in terms of the
objects that were introduced in 1(i) above, and therefore can interact with the CBPM
in a consistent manner.
According to this model, process awareness is knowledge about the objects that lead
an actor (which is another object) to an understanding of various aspects of the
collaborative process. Such awareness is defined in terms of the actor's own roles, the
roles that other actors play, the simple and collaborative tasks, the interactions among
the actors, and finally the process itself (due to their irrelevance, two higher levels of
awareness, that is 'the relationship of the process with other existing processes', and
'the history of the process in the past and across the industry' are not discussed in this
paper).
Level-0 awareness: An actor's level-0 awareness is awareness about the
objects that lead the actor to knowledge about all the simple tasks that the actor
performs within the process. In Figure 1, level-0 awareness for the actor called 'User'
is a set of the following objects:
(r2+ra11+P2) + (r2+ra12+P3)
Level-1 awareness: This is a sum of the actor's level-0 awareness, plus
awareness about the objects that lead the actor to knowledge about other related roles.
In Figure 1 the User has two related roles to whom s/he interacts with. These are:
Change Manager ('r1'), and Operator ('r3'). For the User to fully understand r1 and r3
roles, s/he must have contextual knowledge about all the objects that link these two
roles to the User (linkage is established by a common task artefacts). Therefore, level1 awareness for the User will be: (bold objects are the added portions to the User's
level-0 awareness):
(r2+ra11+P2+ta5) + (r2+ra12+P3+ta4) +
(ta4+P4+ra7+r3) +
(ta5+P1+ra9+r1)
Notice that the above structures are re-grouped (in the expense of repeating some
objects such as ta4 and ta5 twice) in such a way that each structure consists of exactly
four objects: role, role artefact, simple task, and task artefact. Such deliberate
regrouping is necessary for later stages of design where each structure must contain
one link object (called 'key field' in relational databases). This link object is the shared
task artefact object. As will be shown later, those structures that are not collaborative
(that is, those that contain a simple task which is not related to any other simple task)
are left unchanged.
Level-2 awareness: An actor's level-2 awareness is his/her level-1 awareness,
plus an awareness about all other (or, the rest of) roles within the process. Level-2
awareness is knowledge about the human boundary of the process. Level-2 awareness
for the User in Figure 1 is: (bold objects are additions to the User's level-1 awareness)
(r2+ra11+P2+ta5) +
(r2+ra12+P3+ta4) +
(ta4+P4+ra7+r3) +
(ta5+P1+ra9+r1) +
(r1+ra8+P11+ta3) +
(ta3+P10+ra5+r4) +
(r4+ra2+P9+ta1) +
(ta1+P8+ra1+r5)
Since the User is indirectly linked to the Technician through two paths (one through
the Operator, and the other through the Change Manager), a second alternative also
exists for the User's level-2 awareness as follows:
(r2+ra11+P2+ta5) +
(r2+ra12+P3+ta4) +
(ta4+P4+ra7+r3) +
(ta5+P1+ra9+r1) +
(r3+ra6+P5+ta2) +
(ta2+P6+ra4+r4) +
(r4+ra2+P9+ta1) +
(ta1+P8+ra1+r5)
Level-3 awareness: an actor's level-3 awareness is his/her level-2 awareness,
plus awareness about all the interactions (represented by the task artefacts) that occur
between any two roles within the process. From his/her level-2 awareness, the User
already is aware of the interactions between him/her self and the Change Manage (that
is 'ta5'), between him/her self and the Operator (that is, 'ta4'), between the Change
Manager and the Technician (that is, 'ta3'), and between the Technician and the Test
Coordinator (that is, 'ta1'). The only remaining interaction within the process that the
User is not aware of yet is the interaction between the Technician and the Operator
(that is, 'ta2'). Therefore, if one of the following structures is added to the User's level2 awareness, his/her awareness level will raise to level-3 (bold objects are added
portions to the User's level-2 awareness).
Alternative 1:
r4+ra4+P6+ta2
Alternative 2:
r3+ra6+P5+ta2
Level-4 awareness: The highest level of process awareness that an actor can
possibly have is an awareness about the way all interactions fit together to form the
process. In other words, this level of awareness will bring all the remaining objects
within the focus of the actor. The remaining objects on the CBPM which have not yet
been put within the focus of the User are:
(ra10+P12) + (ra3+P7)
If the above portion is added to the User's level-3 awareness the result will constitute
the User's level-4 awareness. At this level the User is aware of ALL the collaborative
semantic objects that form the process as well as their relationships to one another;
and for this reason we may call this the highest level of 'process awareness'
2. The Collaborative Structures
As seen before, CBPM is a connected graph that consists of several objects linked
together to represent a collaborative process. As a connected graph, CBPM consists of
several paths. Each path, in turn, can be regarded as a structure. Each structure
partially defines various levels of awareness within the process.
One question is why the methodology in this paper is so tightly linked to the
awareness? A justification for choosing an awareness framework for designing
collaborative database of this paper follows.
In many collaborative database applications, maintaining the awareness of
the actors can be regarded as a fundamental goal.
One of the main aims of designing a collaborative database may be to store and
retrieve the collaborative objects (that is, actors, their tasks, artefacts they use, etc.)
and their relationships as a requirement for enabling these actors to collaborate with
others. This collaboration is closely dependent on the level of awareness that the
actors have of one another within the process. In other words, actors in a potentially
collaborative process may never collaborate if they are not aware of other actors, the
tasks that these other actors perform, and many other relevant collaborative semantic
objects within the process.
Moreover, one actor's action/queries in collaborative databases will affect the other
actors' actions/queries; and therefore these databases must be accommodated with a
mechanism that maintain required awareness among the actors.
The CSCW literature suggests various types of such interactive effect including
articulation work [Gerson 86], situated action [Allen 84], mutual influence [Robinson 91],
etc. Obviously, such effect is not present in the traditional (non-collaborative)
databases where user interactions with the database are supported by the database
management system regardless the interaction effects that may exist between different
users of the database.
On the other hand, despite the fact that CSCW literature provides many kinds of
awareness (eg, awareness through seeing at a glance [Heath 91], gaze awareness
[Hutachi 96], virtual workspace awareness [Rodde 96], Shared Feedback Awareness
[Dourish 92], etc.), this paper introduces a new version of the process awareness first
introduced in [Hawryszkiewycz 95]; that is, the knowledge that the actors may have
aboutvarious aspects of the collaborative process.
For the above reasons, it seems appropriate to choose a design methodology for
collaborative databases that is based on an awareness framework that facilitates
collaboration.
A second aim of the database design for collaborative systems may be to provide a
model of the collaborative process that supports collaboration among the actors rather
than the collaboration being hindered in any way by the collaborative database system
itself. Again, an awareness framework will assist the database design process by
providing awareness information to the actors.
And finally, a third aim of the database design for collaborative systems may be to
support required collaboration within the process with such requirements being
determined by the nature of the tasks the actors perform, as well as the organisational
culture that may dictate the degree and intensity of collaboration expected from the
actors. For instance, an Army officer ("Army" being a 'closed' culture) working on a
highly confidential project (assuming the 'confidentiality' of the tasks being the
dominant attribute of the tasks) may not necessarily appreciate higher levels of
awareness for majority of his/her subordinates; whereas an R&D Manager in Silicon
Valley (an 'open' culture) may seek the highest possible level of process awareness
for the majority of his/her department members. Having a measure for awareness, in
the form of various awareness levels as discussed before, will certainly facilitate
determination of the density and the acceptable level of collaboration that are
required/expected from the actors.
At this stage, it is appropriate to introduce the following two concepts:
Actual Level of Awareness: is the awareness level that the actor possesses
within the process. It is represented by an integer number ranging from zero to four
representing various levels of awareness.
Required Level of Awareness: is an awareness that is attached to each task
and represents the expected awareness from the actor who is associated with that task
so that the task can be performed successfully (and according to the expectations).
Such expectation may arise either from the nature of the task, or from the
organisational culture, or a combination of both. Similar to the actual level of
awareness, required level of awareness is also represented by an integer ranging from
zero to four.
Introducing a Methodology for Designing Collaborative Databases which
Maintain Awareness:
These are the steps for designing a collaborative database using PAF:
STEP 1: Identify the collaborative objects of the process. Any conventional
method (eg, 'interviewing', 'observation', 'document research', etc.) can be used to
identify these objects.
STEP 2: Identify the relationships among these objects. For doing this we
need to associate:
- all the task artefacts with their related pairs of simple tasks,
- all the simple tasks with their related role artefacts,
- all the role artefacts with their related roles, and
- all the roles with their related actors.
STEP 3: Draw the CBPM (similar to the Figure 1).
STEP 4: Analyse the CBPM, and derive various levels of awareness that are
associated with each simple-task. This was done in Section 1(ii) above. This
methodology allows each simple task to carry a separate value representing its own
required awareness, even though two or more of these simple tasks may be
performed by the same actor at any given time. In other words, actors may share their
process awareness among various tasks that they perform within the process. This is
why the structures in 1(ii) were grouped in parentheses so that awareness levels
associated with (or required by) each simple task can be easily identifiable.
STEP 5: Normalise the structures derived in STEP 4 (by removing redundant
objects and/or combining them) in such a the following ways:
(i) Since one design objective is to support collaboration among the actors, the
structures in 1(ii) must be further normalised in such a way that each new
normalised structure starts and ends with a role object. This is so because a
structure that starts and ends with a role object incorporates all the contextual
information (in the form of other objects) that any of the roles in each tail of the
structure would need to collaborate with the role in the other tail of the structure.
Obviously, an exception is where a simple task does not participate in a
collaborative task; that is, the simple task is not related to any other simple task
(and therefore to any other role) within the process (eg, P7 and P12 in Figure 1),
in which case these structures remain unchanged. Using the example in Figure 1,
the normalised version of the structures in 1(ii) will be the following set of
structures.
(1) r1,ra9,P1,ta5,P2,ra11,r2
(2) r2,ra12,P3,ta4,P4,ra7,r3
(3) r3,ra6,P5,ta2,P6,ra4,r4
(4) r4,ra2,P9,ta1,P8,ra1,r5
(5) r4,ra5,P10,ta3,P11,ra8,r1
(6) r1,ra10,P12
(7) r4,ra3, P7
(ii) Since another major design objective is to support required collaboration that is
expected from each simple task, all the structures produced in the previous stage
must be further normalised in such a way that to each simple-task an integer
number, ranging from 0 to 4, be attached representing the required level of
awareness for that particular simple task. The seven structures in stage 'ii' above
will then be expanded to the following 12 structures since each of the structures 1
to 5 in the 'ii' above consists of two simple tasks, and each of these simple tasks is
entitled to be associated with its own awareness level, and therefore they need to
have a structure of their own. Also, notice that as a result of splitting these five
structures into ten new normalised structures, the last two fields of each of these
new ten structures are deleted since they will be redundant. Following is a list of
12 structures:
(1) r1,ra9,P1,ta5,P2, 4
(2) r2,ra12,P3,ta4,P4, 2
(3) r3,ra6,P5,ta2,P6, 4
(4) r4,ra2,P9,ta1,P8, 1
(5) r4,ra5,P10,ta3,P11, 3
(6) r1,ra10,P12, 0
(7) r4,ra3, P7, 1
(8) r2,ra11,P2,ta5,P1, 2
(9) r1,ra9,P1,ta5,P2, 4
(10) r4,ra4,P6,ta2,P5, 4
(11) r5,ra1,P8,ta1,P9, 1
(12) r1,ra8,P11,ta3,P10, 4
STEP 6: The collaborative database can now be constructed by populating the
database with the structures developed in Step 5 using the software that is introduced
in the next Section.
3. Introducing Aware Ware Template (AWT) Software:
A Tool for Implementing PAF Methodology
AWT (or, Aware Ware Template) is a NOTES database template developed by the
writer that transforms a CBPM into a NOTES database. Its various search algorithms
determine various paths leading to different awareness levels. AWT is also capable of
identifying any awareness gaps that may exist between the actual and required levels
of awareness. This information can further be used to remove such undesirable gap in
order to enhance collaboration within the process.
More specifically, AWT is capable of performing the following tasks:
(i) it constructs a NOTES database equivalent of the CBPM by storing various
collaborative structures and their relationships to one another;
(ii) it provides an on-line questionnaire so that the actual level of awareness
associated with each simple task is determined;
(iii) it provides a search facility for identifying various objects on the CBPM that
constitute required levels of awareness for each task; and finally,
(iv) it identifies all the objects that constitute awareness gap that may exist between
the results found in (ii) and (iii) above. This information, in turn, can be used to
enhance collaboration by removing this undesirable gap.
Documents within the AWT are represented by a Form - which is a blank version of
the document, ready to be filled in. Documents within the AWT's database are
represented by a form with the following properties:
Title:
Fields:
"1. Task-Form" | "TF"
Req_Level
Role_Art
role_id
Task_Art
Task_Name
Rel_Task_Id
'required level of awareness for this task
'role artefact used for this task
'the ID of the role who performs this task
'Task artefact used by this role for performing
' this task (if any)
'The name of the task
'the task ID of the related task (if any)
The above six fields correspond to the six fields that appear on the structures of the
Step 5 above. Table 1 shows these 12 documents.
Task Simple
ID
Tasks
P3
reporting a
problem
P4
receiving
problem
report
P5
assigning a
T-Ticket to
problem
P6
receiving a
T-Ticket
P7
trying to
solve the
problem
P1
impact
control
P2
impact
analysis
P10 placing
change
request
P11 implement
change
request
P8
approve
meeting time
P9
P12
arrange a
meeting
Issue Work
Permit
Role
Role
Artefact
knowledge
of NOTES
knowledge
of NOTES
Req'd
Level
2
Operator
knowledge
of Telecom
4
T-Ticket
Technician
knowledge
of Notes
textbooks
4
T-Ticket
1
<N/A>
CM
Standards
User Org.
Documents
organisatio
nal
procedure
Organsatnal
procedure
4
CM
form
CM
form
change
request
4
change
request
personal
diary
1
Meeting
Schedule
personal
diary
OS
Schedule
1
Meeting
Schedule
<N/A>
User
Operator
Technician
Change
Manager
User
Technician
Change
Manager
Test
Coordinato
r
Technician
Change
Manager
1
2
3
0
Task
Artefact
problem
report
problem
report
Table 1: Lotus-NOTES documents for the 'problem solving' process in a network management
environment.
A complete (but simplified) dialogue between the user of the database (who is usually
either an 'actor' or his/her manager) is shown in the following paragraphs:
===================================================
<session begins>
SYSTEM:
USE0R:
Do you wish your "AWARENESS GAP" be determined?
<user selects "YES">
SYSTEM:
USER:
Please  the Simple Task for which the Awareness Information is required:
< user selects P3>
SYSTEM:
From the following list, choose all the Simple Tasks that you are aware of:
P1, P2, P3, P4, P5, P6, P7, P8, P9, P10, P11, P12
P1, P2, P3, P4, P7, P9 and P10
USER:
SYSTEM:
USER:
SYSTEM:
USER:
SYSTEM:
From the following list, choose all the Roles that you are aware of:
r1, r2, r3, r4 and r5
r2 and r3
From the following list, choose all the Task Artefacts that you are aware of:
ta1, ta2, ta3, ta4 and ta5
ta5
Your 'actual awareness' currently is not sufficient for performing P3. You need
to know about the following objects:
1. P8; P11 (Simple Tasks)
2. r1; r4; r5 (Roles)
3. ta1; ta3; ta4 (Task Artefacts)
Do you wish to see complete recored of your Required Awareness for P3?
User:
Yes
SYSTEM:
Following objects represent the User's Required Awareness for P3:
Level-0:
1. User; Reporting the problem to Operator; (using) knowledge of
NOTES
2. User; Performing impact analysis; (using) User Organisation's
documents
--------------------------------------------------------------------------------Level-1:
1. User; (is related to) Operator; (for) Reporting the problem to
Operator;
2. User; (is related to) Change Manager; (for) Impact analysis
--------------------------------------------------------------------------------Level-2: (other roles are:)
1. Technician; (for) receiving T-Ticket from Operator;
2. Technician; (for) trying to solve the problem;
3. Technician; (for) arranging a meeting with Test Coordinator);
4. Test Coordinator; (for) approving the Technician's proposal;
5. Technician; (for) placing a Change Request;
--------------------------------------------------------------------------------<session terminates>
===================================================================
4. Conclusions
This paper introduces a methodology that can be used to analyse, design and
implement a special type of collaborative database that can potentially enhance
collaboration by identifying awareness requirements of the actors within the process.
This special collaborative database system can be used in conjunction with (or, as a
complementary subsystem of) other types of collaborative databases.
As a by-product of this research, the paper also introduces a software that implements
the design methodology of this paper. As results from the scenario in the last part of
Section 3 shows, the proposed collaborative database satisfies the design objectives
mentioned before in the following ways:
(i) it stores the collaborative objects and the relationships between these
objects in order to support user activities (of whatever kind) within the process,
(ii) it implements a model of collaborative process that supports collaboration
among the actors rather than the collaboration being hindered in any way by the
collaborative database system itself. This is done by providing all the necessary
awareness information to the actors for various tasks.
(iii) it supports users for their required level of collaboration and not for what
they actually are. In this way, the database provides a list of the objects that constitute
the actor's awareness gaps that are outside the focus of the actor. By doing this,
collaboration can be enhanced if such 'gap' is removed (that is, if the actor gains extra
'awareness' about various aspects of the collaborative process).
REFERENCES:
[Allen 84] Allen T. J., "Managing the Flow of Technology", MIT Press, Cambridge, 1984.
[Daneshgar 97a], Farhad Daneshgar, "A CSCW Approach For: Enhancing Collaboration in
Enterprise Environments", Proceedings of CAiSE'97 DC (Consortium on Advanced
Information Systems Engineering), Barcelona, Spain, June 1997.
[Daneshgar 97b] Daneshgar Farhad and Pradeep Ray "Cooperative Management Based on
Awareness Modelling", Proceedings of the 8th IEEE/IFIP International Workshop on
Distributed Systems Operations and Management (DSOM'97), Sydney, Australia,
October 1997.
[Daneshgar 98] Daneshgar Farhad "An Awareness Framework for Business Processes", PhD
Thesis, School of Computing Sciences, University of Technology, Sydney (Australia),
November 1998.
[Gerson 86] Gerson E & S Star, "Analysing due process in the workplace", New York, ACM
Transactions on Office Information Systems 4(3), 1986.
[Hawryszkiewycz 95] Hawryszkiewycz Igor, "An Object Oriented Approach for CSCW
System Design", Proceedings of the 14th International Conference, OOER'95: ObjectOriented and Entity-Relationship Modelling, Gold Coast, Australia, 1995.
[Hawryszkiewycz 97] Hawryszkiewycz Igor "Designing the Networked Enterprise", Artech
House Inc, Boston, USA, 1997.
[Heath 91] Heath C., and P. Luff "Collaboration Activity and Technological Design: Task
Coordination in London Undergroun control room", Proceedings of ECSCW91, Kluwer,
Dordrecht, 1991.
[Hutachi 96] Hutachi Ikado, "Gaze Awareness" A video presented in CSCW'96 conference,
Boston, USA, November 1996.
[Ray 96], Pradeep Ray, Igor Hawryszkiewycz and Michael Fry, "Group Cooperation in
Network Operations and Management", IEEE International Communications Conference
(ICC'96), Dallas USA, June 1996
[Robinson 91] Robinson M, "Computer Supported Cooperative Work: Cases and Concepts",
Proceedings of Groupware 91, SERC, P O Box 424, 3500 AK Utrecht, the Netherlands,
1991.
[Rodden 96] Rodden Tom, "Populating the Application: A Model of Awareness for
Cooperative Applications", Proceedings of CSCW'96, Cambridge, MA, 1996.