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: email@example.com 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.