- Email: [email protected]
Chapter 7 Approaching design for integrated CSCW-DAI systems
The Design of Computer Supported Cooperative Work and Groupware Systems D. Shapiro, M. Tauber and R. Traunmaller (Editors) 9 1996 Elsevier Science B.V. All rights reserved.
101
Chapter 7
Approaching Design for Integrated CSCW-DAI Systems Dirk E. Mahling
Department of Information Science University of Pittsburgh
Introduction "Men work together," he said from the heart, "whether they work together or apart." ROBERT FROST, A Tuff of Flowers
Cooperation and coordination are increasingly being recognized as determinants of success in a wide variety of endeavours. In particular, knowledge concerning the coordination in our pursuit of complex activities has gained the interest of the research community and the business world. Complex tasks such as assessing ecologies and economies, designing large scale technologies, or
102
Dirk E. Mahling
supervising major construction projects, are fields that require an explicit design methodology to cope with coordination and cooperation issues. In addition, these artifacts allow us to cope with demands and changes in our physical environment, our social structures, and our cultural activities. Our daily life is substantially influenced by the machines, buildings, and tools that surround us. Just as we and our society are influenced by the artifacts, they themselves are influenced by the way we build and employ them (Ach, 1905). Increasing complexity and the need for coordination in our society leads to increased complexity and cooperation features in the artifacts demanded, while the use of tools that enable cooperation shapes the structure of group work. The design of systems, cooperative or not, has mostly been an elusive art rather than a firm science. Bringing design closer to the scientific disciplines has been attempted, for instance, in software engineering and in knowledge engineering, with varying degrees of success. While some interactive systems could be built and refined without an explicit methodology governing the design process, cooperative systems require a more systematic approach. It becomes necessary to move from the art of system design to an engineering approach for cooperative systems. In addition, cooperative systems require a broader view of design than is usually taken in software engineering. Recent approaches, such as cognitive engineering, social engineering, or usability testing, to name just a few, are essential for the effectiveness and acceptance of such systems. This means that knowledge about the intended domain and the usage of the system should guide the design. The constructive use of theoretical knowledge is referred to as "proactive". This chapter addresses the design needs of intelligent, cooperative systems and suggests a design approach for such sygtems. The next section introduces intelligent human-computer cooperative systems, the particular type of cooperative systems considered here when designing for cooperation. The following section combines proven and recent design and analysis approaches into a system design method. The next section shows how the method can be used to create a generic architecture, while the last section points to future work.
Human computer cooperation systems As no coherent design methodology exists for conventional systems, it is extremely hard to attack the design problem for cooperative systems generically. This chapter therefore limits methodological considerations in
Approaching Designfor Integrated CSCW-DAISystems
103
CSCW (Computer Supported Cooperative Work) to a special type of cooperative system: Human Computer Cooperation Systems (HCCS), an integration of cooperating people and distributed knowledge-based machine agents. Human computer cooperation systems (HCCS) concentrate on providing means for cooperation among spatially or temporally separated people or organizational units working on complex tasks. A major step toward accomplishing this goal is to regard machines and software programs as not only facilitators of communication among people but also as active participants in project management, problem solving, and task execution (Croft & Lefkowitz, 1988; Haugeneder et al., 1989; Imagine, 1990). Such intelligent agents may range from simple printers and sensors over numerically controlled machines to sophisticated knowledge bases and expert systems. Viewing human and machine agents as partners in communication, cooperation, problem solving, and task execution extends the conventional paradigm to HumanComputer Cooperative Work (HCCW), which allows all participants to work on common goals and their own objectives. Such systems are thus trying to integrate cooperation and support concepts from CSCW and DAI (Distributed Artificial Intelligence). Goal-based cooperative work therefore is the interaction among a group of people in order to achieve their individual and group goals. Goals are derived from wishes and intentions in individual and group processes, which have yet to be more closely understood and formalized. While goals can be formalized to describe desired states in a model, wishes and intentions remain elusive. But even the complexity of formal goals in typical environments needs to be handled by problem solving and planning mechanisms (Fox, 1981). Cooperation comes about as the necessary result from this complexity and the limited knowledge of individuals and organizations. These interactions occur not only in sharing the performance of an activity, as is usually assumed in multi-agent planning (Rosenschein, 1982), but also for initial planning and resolution of conflicts during the activity. Examples of goal-based cooperation include project management, collaborative authoring, and office work. In designing such systems, one is concerned with facilitating group interaction and providing support for individual activities. There are currently two perspectives used as basis for the design of Human Computer Cooperation System. One focuses on problem solving by supporting planning (Lefkowitz & Croft, 1989; Barber, 1983), and the other on communication (Winograd, 1987; Malone et al., 1986). Each of these approaches complements the other, and there
104
Dirk E. Mahling
is a need for an integrated perspective to effectively support complex cooperative tasks such as project management In most cooperative work environments, some of the activities performed by the agents are routine and others are non-routine. The latter require explicit planning before they are performed. The goals and activities of different agents may be interdependent. They may be subgoals of some higher level goal, or the effects of an agent's action may preclude another agent's activity. Supporting communication between agents can help them coordinate this activity appropriately, but it should also be possible for a CSCW system to provide active support in generating and executing complex plans.
Proactive design approach for cooperation Techniques and methods to help design cooperative systems arose as answers to needs of practioners in the field or they grew out of theoretical research. Applications can most frequently be found in the areas of software interfaces to computers, airplane cockpits, or nuclear powerplant control centers. It is not surprising to find new developments in the area of interface design or usability engineering only loosely integrated with existing practices. Few design techniques add ways to achieve proactive use of scientific knowledge, yet every engineering discipline needs to develop methods, which are based upon its underlying sciences. Using scientific knowledge to predict, design, or create is proactive and therefore distinct from the retroactive scientific analysis or explanations of systems and their behavior. To move the design and construction of interactive systems closer to the engineering disciplines, proactivity is necessary. The method starts by mapping the social, cognitive, and functional territory (Mahling, 1990), thereby accounting for the diversity of participating agents and their heterogeneous cooperative settings. This mapping process includes traditional task and goal analysis, ethnographic methods, and other behavioral and analytical techniques. After the mapping survey of users, tasks, communications, and cooperation patterns has reached a stable level, the formation of a model can start. For this purpose, existing models and theories in the scientific body of knowledge can be used to embed, explain, or predict findings. To be relevant for cooperative systems, special attention in this phase should be given to coordination science, the theory of communicative processes (social as well as informational), and, of
Approaching Designfor Integrated CSCW-DAISystems
105
course, social psychology. Examples for the relation between theories and systems are: 9 speech act theory -COORDINATOR (Winograd, 1987) 9 argumentative writing - WHAT (Hashim, 1991) 9 communication acts (Kedzierski, 1982)
Support in system development
environments
9 organization audit and analysis - DEVA (Rein, 1992) Facts and observations that can not be covered in this way may point to additional theoretical research. Eventually a model should be synthesized that integrates data from the mapping process, existing models and theories, which are applicable, and sub models from additional research. Based on this synthesized model, implications can be drawn for how to design or modify the collaboration among human and machine agents. Rapid prototyping in conjunction with user-centered design and user participation is used to build initial versions of a solution for cooperation problems. These solutions are iteratively refined, until operational usability goals are reached (Whiteside et al., 1987). This method attempts to accommodate concerns and ideas expressed in the recent approaches to design. It also tries to capture the core of the newly developed view of system building. Recent approaches to system engineering put a strong emphasis on users as agents in communicative and cooperative settings. This is reflected in the participation of users in conceptual design phases, the ethnographic emphasis of spiraling-in on questions important to users, and the active use of evaluations and resulting redesign. Another trend can be recognized in the formalization of cognitive parameters and in efforts to integrate requirements and specification languages. This hints at a design language, which can be used in all phases of the system building process and which allows one to capture user needs on cognitive and social levels, as well as traditional aspects of requirements and specification languages. A powerful idea which has rarely found realization is the use of knowledge for system design. System designers would be able to take a qualitative leap if they could readily access relevant knowledge in the body of science that is closely related to the design problems at hand. This proactive use of theoretical knowledge would make constructive use of findings, rather than explaining design failures retroactively, thereby enhancing design quality and increasing system stability.
106
Dirk E. Mahling
The design method can be summarized as follows: 1
Requirements a Domain/Task/Ontological Analysis b User/Group Analysis c Communication/Cooperation Analysis
2
Model Formation a Connections to existing Theories and Findings b Selection of the best fitting Alternative c Required Extensions or Adaptations d Synthesis into a coherent (formal) Model
3
System Design and Implementation a (Formally) deriving System Specifications b Optimization: Functional, Architectural, Cognitive, Socio-Cooperative c Rapid Prototyping Usability Testing a Evaluation with Users b Iterative Redesign
The details of the method are discussed in the following subsections.
Requirement analysis To start building a system, software engineering teaches us, a thorough specification and requirement analysis must be performed (Yourdon, 1989). This analysis helps us understand the purpose and the intended functionality of the system. Dealing with knowledge-based systems, this analysis has to extend to the knowledge, or ontological, level to capture underlying meanings and connections that would usually not be modelled in data analysis. In particular three requirements should be defined: tasks, context, entities
Which tasks should the system perform and how should it do that in the context of the overall work paradigm. Which ontological entities are encountered? How should they be represented? How do they relate to the tasks of the system and the purpose of the overall organization? single users, user groups, organizational units, organizations
Which requirements are posed by the cognitive abilities of single users for the interface and task support capabilities of the system? Which types of user
Approaching Designfor Integrated CSCW-DAISystems
107
groups exist? What type of social interaction occurs currently between the individuals in these groups, what interaction occurs among the groups, and how would that be affected or changed by a system? Which parts of an organization are to use the system and how is that going to affect the organizational structure?
cooperation and communication Which communication structures exist currently and how should communication be changed? Which communication media and channels does that affect? How is communication embedded in the organizational context? Which cooperation techniques can be employed? On what types of communication do these cooperation methods rely? A number of more or less formal tools and notations already exist to support requirement analysis activities. Most prominent are conventional tools from the domain of software engineering. Hierarchical data flow diagrams, state transition diagrams, and entity relationship diagrams can be used in the process of task and context requirement analysis (Yourdon, 1989). An important distinction can be drawn between functional modeling and behavioral modeling (Wallace et al., 1987). Basic relations between functions are precedence, dominance, parallelism, and feedback. A task or function preceeds another one when its output is the input to a following task or function. A task dominates another task, when its output is control data for the other task. Parallelism indicates the independence of the two tasks, while feedback occurs when ouput data flows back to a preceeding task. The behavioral perspective of a system is concerned with its dynamic features. It provides a model of the type of activity the system will perform at a certain point in time. The behavioral model is needed since not all temporal aspects are covered by the functional model. Examples are the combination of inputs to generate certain outputs or exceptions that might occur outside the system. Event modeling in state transition diagrams is an approach to issues in behavioral modeling. Most social and psychological methods of data gathering, such as interviews, questionnaires, structured observation, free recall, or form filling are adequate to gather user and organizational requirements. Ethnographic techniques and other tools from anthropology can help to formulate relevant questions. Analysis of cognitive workload and role activity theory are more formal approaches to derive user and group requirements. Organizational requirements can be
108
Dirk E. Mahling
assessed with tools and methods described in Mintzberg's organizational studies (Mintzberg, 1979). Communication and cooperation requirements should be built on the results of the preceeding two steps. Communication can either be analyzed on an operational level using Hoare's language for communicating sequential processes (CSP) (Hoare, 1985) or on a higher level of abstraction using a structuration approach (Lyytinen, 1990). While CSP is a formal language with primitives such as prefix (wait for event then activate task) or disjunction (wait for event I or event 2 and depending on that do either task 1 or task 2), structuration views machines in the cooperation process in a threefold way. Machines can either be seen as communication media, as shared materials for the objects created in the work process, or as tools which help to manipulate materials. Practical and discourse consciousness are distinguished with goal generation, means generation, and evaluation belonging to the discourse and manipulative actions and control actions belong to the practical consciousness. On the coordination side, certain coordination components can be identified (Malone, 1988): 9 goals 9 activities 9 actors 9 interdependencies Goals and activities as well as actors should have been identified in earlier stages of this analysis process. The major task here is to identify and manage the dependencies between tasks and the conflicts between user or group goals. Interdependencies such as prerequisites, shared resources, or simultaneity are generic, while the manufacturability of a machine part or the information sharing about customer visits from various departments is domain specific. The outcome of the requirement analysis stage should be a set of goals and contextual parameters, which should ideally be formalizeable to further guide the design process. The more formal the specifications, the stronger the design implications in later design stages. The design process can be viewed as a search through a search space with the goal being partially defined but the path from the current state to the goal being the problem. While the goals have a guiding function in the further design process, task analysis, coordination models, and user models provide the contextual constraints for selecting the best path through the design problem space.
Approaching Designfor Integrated CSCW-DAI@stems
109
M o d e l formation When the goals and tasks of the users have been formally analyzed, theories in cognitive science, social science, and other relevant fields relating to these goals and tasks should be found and customized. This is a difficult task which today is often neglected because it requires interdisciplinary communication and cross referencing to identify relevant theories. It can be achieved via keyword search or other matching patterns. Formalization and computerized tools to aid in this task may be motivated through developing design and engineering methodologies. If the goal, for instance, is to build an expertise transfer system, recall of knowledge becomes crucial. Previous experiments, models, and theories in cognitive psychology about recall of activities should therefore be found and related to the particular goals at hand. Frequently, existing models or theories do not fit the design problem completely. Though major issues are addressed, certain crucial details might inhibit the immediate use of an established theory. In this case additional research must be completed to either customize or extend the existing model. This research might be theoretical in nature, or involve experiments with people. With these extensions, augmentations, and customizations, a dedicated model can be constructed that allows system designers to obtain operational answers. Formal rigor in the expression of results of the analysis and in the representation of the synthesized model help to capitalize on existing knowledge.
Design and realization The synthesized model, the results from the analyses, and the design goals provide a basis for design implications. While the contextual results from the analyses provide constraint-based boundaries of the design space, the design goal marks a position in the design space that should be reached. The synthesized model can be seen as the means that help the designer to walk in the design space towards the goal. The stronger and more expressive the chosen design language, the more tangible the implications for the initial design can be. Goals and context could, for instance, be expressed in well formed formulae. This design language would allow the use of an inference engine to draw design conclusions, similar to meta-planning. This step in the methodology translates static knowledge into new design. It is an engineering idea that needs to be refined and developed in more detail in the future, as the true power of the method is located here.
110
Dirk E. Mahling
Ideally, these design implications form a coarse, initial draft of the design of the whole system. This initial draft can be refined using more conventional methods. The cognitive parameters can be optimized using quantitive methods of cognitive engineering (Fisher, 1988). Various hardware optimizations and system engineering optimizations and refinements can also be performed at this point. To realize the optimized version of the initial design, rapid prototyping techniques should be used. Rapid prototyping allows the involvement of users to quickly verify secondary design decisions. Rapid prototyping of the interactive human-computer system also allows one to test design alternatives and to alter, without major effort, parts of the system. When a stable implementation of the first design has been found, usability testing and redesign can start (Whiteside et al., 1987).
Process summary of the method Having introduced the components of the method, we can now assemble the major steps, tools, and documents into a design process. Starting with the requirement analysis, tools described above, such as state transition diagrams, structurational analysis, or CSP, are used to generate (formal) requirement specifications. These specifications are the basis for querying the body of scientific and engineering knowledge in search of theories and models that could be relevant to the problem at hand. The requirement specifications also result in a set of operational usability goals, which define at the beginning of the design process what the functional, non-functional, and behavioral goals of the system should be. The query to the body of knowledge results in a set of candidate theories. Now it must be decided if the candidate theories are overlapping or disjunct and how well they fit the scope of the requirements. Identifying areas of overlap permits the computation of goodness of fit parameters and selection of one or a set of theories from the candidates. Still there might be areas where the selected theory is not applicable to the requirements. In that case additional research should be conducted to supplement the selected theory. With this additional research, a synthesized model can be constructed. The synthesized model acts as control and source, matching the needs stated by the requirements on the basis of general design principles. Specific architectures and system design specifications should be generated at this point. On the basis of these specifications, one can run a number of optimization processes, such as quantitative cognitive engineering tools or design
Approaching Designfor Integrated CSCW-DAISystems
111
postprocessors. All the above activities should produce an intial sketch for a system that is now ready for rapid prototyping. Rapid prototyping quickly integrates with usability engineering. Feedback from the users changes the prototype; attainment of usability goals can be forecast. At this stage it is necessary to identify larger deviations from the usability goals and other deficiencies that become apparent in the system. Early recognition of these factors permits starting the iterative design process. Here it becomes necessary to return to previous stages in design method and spiral upwards until the usability goals are met.
Using the method in analysis and design To illustrate the practical use of the method presented in the last section, consider designing an agent and activity model that could accommodate people and knowledge-based machine agents, therefore serving as a generic computational cooperation environment.
HCCS requirements To identify the fairly abstract requirements for such a system it is impossible to draw on highly formal methods such as hierarchical data flow diagrams or CSP. Instead, structuration analysis and high level task analysis for the functional side of the requirements, coordination theory for the cooperative aspects, and Mintzberg's organizational design analysis tools for the people/organizational aspect are used. Following this method, the following non-formal requirements emerge:
Distribution Collaboration among the members of a team takes place in a (partly) asynchronous and distributed manner.
Diversity A team may have a wide variety of members, ranging from simple sensors to complex software systems to humans, which have drastically varying functionalities and capabilities.
Flexibility The cooperation roles of the individual members of a team are not totally predetermined on the basis of a rigid organizational structure; rather they can
Dirk E. Mahling
112
be adopted dynamically during the work process, depending on the technical competence of the collaborative agents and the structure of the collaborative task.
Redundancy The various partners' competences may be overlapping and even competing, leading to increased requirements concerning the modeling of the overall cooperation process.
Stability Teams are able to withstand the loss of overall communication for a while or the total loss of individual members, though they may not function as smoothly or as efficiently.
Selecting a theory for model formation Taking this set of requirements to a library and starting, for instance, a keyword search yields an overwhelming amount of retrievals. A large number of the retrieved items can quickly be disregarded. Still the number of candidates remains fairly high. Current information retrieval systems permit the formulation of fairly complex, boolean queries that can limit the returned set dramatically with a high probability of retrieving relevant items. Other IR systems employ AI-methods or neural nets to retrieve a handlable set of highly relevant items. Using such systems, the following candidate items are presented" 9 speech act theory (Winograd, 1987) 9 enactment theory (Ach, 1905; Vallacher & Wegner, 1985) 9 Diplans (Holt, 1988) 9 process engineering (Curtis et al., 1992) 9 CSCW conceptual framework (Schmidt, 1990) To identify a single candidate or a set of supplementary ones, we must now assess the relevance and extent to which the requirements are covered. One can start by omitting the conceptual framework from consideration because it is directed at analysis, not at synthesis. Diplans is a notation that also carries some analysis features with it. It is not as easy to omit because these graphs can be used as a notation for future cooperative scenarios. Still they can not provide content answers to the requirements. Process engineering seems like a good candidate since the task and coordination requirements can provide some
Approaching Designfor Integrated CSCW-DAI@stems
113
answers. On the human/organization side this candidate becomes weak, as it does for the flexibility requirement. Enactment theory has been applied to study phenomena as diverse as motivation, cognitive workload, and exercise science. The study of speech acts, for example, can be viewed as a very specialized enactment theory. Enactment theory defines an enactment as the building block of human activities. An enactment is a conscious, goal-directed series of operations of a human being, controlled by will, directed towards shaping reality. An enactment contains operations, conducted by a human, which transform states of reality into other states, serving a purpose (Klaus & Buhr, 1972). It has a hierarchical structure and can possibly consist of other actions. Context and opportunity are also addressed. The concept of the actor in enactment theory is given particular consideration, noting the interaction between actor and context. Therefore, enactment theory is chosen as the theoretical basis for the design of our HCCS .'
HCCS design based on enactment theory To start deriving design implications one returns to the requirements. Flexibility and distribution of tasks requires an explicit design of task flow. Going to enactment theory, highly formalized properties of enactment chains can be directly translated into control constructs:
Task Initialization Including exchange of beliefs, commitments to goals, and resolution of goal or belief conflicts.
Actions concerning the planning and scheduling of tasks Including negotiation of contracts, detection of resource decomposition of complex tasks, commitments to subtasks, etc.
violations,
Task Execution Including monitoring, execution feedback, etc.
Evaluation Including effort/result evaluation, indexing of exceptions, etc. An agent 2 engaged in goal-based cooperative work in the above sense is in enactment theory characterized by a set of beliefs that result from the performance of this work. These beliefs are a basis for the coordination of the activities of the agent. The characteristics of an agent derived directly from enactment theory are:
114
Dirk E. Mahling
Wishes:
Unarticulated intentions of an agent that might lead to goals.
Goals:
Desired future states of the contextual world, individual to the agent or shared with others.
Activity Knowledge:
Knowledge about how to achieve domain goals.
Plans:
Current planned domain activities for achieving goals.
Roles:
An agent's responsibilities for a part of a plan of another agent. Organizational structure may be viewed as a set of relatively static roles.
Capabilities:
The potential roles an agent can play.
Priorities:
The relative importance attached to a domain activity, among the agent's multiple ongoing activities.
Preferences:
The choice of a particular course of action, among alternatives.
Expectations:
The expectations an agent has about others' actions, such as expecting a reply to a message, or a report of completion of an activity.
Sharing beliefs is an important aspect of cooperation in enactment theory. An agent may be aware of the plans, roles and capabilities of other agents. Performance of generic activities leads to this sharing of beliefs. For instance, during establishment of commitments for roles in a plan, an agent may communicate a portion of the plan as a context to other agents. It is conservative to assume that beliefs of agents about others are simple, and agents hold views of other's beliefs (probably incorrect) such as those mentioned above. The resulting architecture is a set of machine agents (nodes) for assisting people in goal-based cooperative work. A node extends the problem solving support of conventional human-computer planning systems (Lefkowitz & Croft, 1989) by supporting negotiation, communication and sharing of beliefs in goalbased activity. The architecture of a node is shown in figure . Eventually a cooperative knowledge based planning system emerges that can assist people in performing and coordinating multiple interdependent activities. It uses non-linear, hierarchical planning for generating plans for an agent's goals in domains where the activities are loosely structured and underspecified. In addition it monitors the performance of the planned activities. The planner,
Approaching Designfor Integrated CSCW-DAISystems
115
domain description, and execution monitor modules in figure constitute the machine part of the system. In the distributed architecture, the AI-planner provides the problem solving support for the generic activities of execution, monitoring and planning.
Future work This chapter has presented a preliminary proposal for a design method that is focussed on human computer cooperation systems. It showed how the method could be used to derive a distributed system on an underlying enactment basis. In future, we plan to refine the design method and widen the types of systems that can be generated with it. In particular, we are planning to generate a stable version of the system architecture and start conducting usability studies. This will lead us into the later stages of the design method. We are interested in generating notations and tools that would allow a more comfortable application of the design method. This would entail moving toward a more formal design language which would allow us to specify and verify in a stricter fashion and to automate the derivation of some of the design implications.
116
Dirk E. Mahling
References Ach, N., 1905, Ober die Willenstiitigkeit und das Denken, Vandenhoeck. Barber, G., 1983 'Supporting organizational problem solving with a work station', ACM TOOLS, 1, pp 45-67. Croft, W. B. & L. S. Lefkowitz, 1988, 'Knowledge-based support of cooperative activities', in A. H. Bond & L. Gasser (eds), Readings in Distributed Artificial Intelligence, Morgan Kaufman, pp 599-605. Imagine Consortium, 1990, 'Imagine: Integrated Multi-Agent Interactive Environment', Technical Report, Esprit Imagine, Commission of the European Communities,. Curtis, B., M. Kellner & J. Over, 1992, 'Process modeling', Communications of the ACM, 35: 9. Fisher, D. L., 1988, 'Optimization in cognitive engineering', Lecture Notes for Cognitive Engineering Seminar, IEOR 689, May, Department of Industrial Engineering, University of Massachusetts. Fox, Mark S., 1981, 'An Organizational View of Distributed Systems', IEEE Transactions on Systems, Man and Cybernetics 11, pp 70-80. Hashim, S., 1991, 'WHAT: An argumentative apporach for organizing and documenting research activities', Journal of Organizational Computing, 1: 3, pp 275-302. Haugeneder, H., D. Scheidhauer, & D. Steiner, 'Teamware: Computergestfitzte L6sung komplexer Aufgaben im distribuierten Mensch-Maschine Team', Technical Report KIK 1-89, DFKI (German Research Center for AI). Hoare, C., 1985, Communicating Sequential Processes, Prentice Hall. Holt, A., 1988, 'Diplans: A new language for the study and implentation of coordination', ACM TOOLS 6: 2, pp 109-125. Kedzierski, B., 1982, 'Communication and management support in system development environments,' Proc. CH182, New York NY: ACM. Klaus, G. & M. Buhr, 1972, Philosophisches W6rterbuch, VEB Deutscher Verlag der Wissenschaften. Lefkowitz, L. & W. B. Croft, 1989, 'Planning and execution of task in cooperative work environments', in Proc. IEEE Conference on AI and Applications. Lyytinen, K., 1990, 'Computer supported cooperative work issues and challenges: a structurational approach', Technical Report, Jyvaskyla University, Finland. Mahling, D. E., 1990, A Visual Language for Knowledge Acquisition, Display and Animation by Domain Experts and Novices, PhD thesis, University of Massachusetts. T. Malone, 1988, 'What is coordination theory?' Technical Report, Cambridge, MA: MIT.
Approaching Designfor Integrated CSCW-DAI Systems
117
Malone, T., K. Grant, K. Lai, R. Rao, & D. Rosenblitt, 1986, 'Semistructured messages are surprisingly useful for computer supported coordination',, in Proc. CSCW 86. Mintzberg, H., 1979, The Structure of Organizations, Prentice Hall. Rein, G., 1992, 'Collaboration Technology for Organization Design', HICSS 26, Hawaii. Rosenschein, J., 1882, 'Synchronization of multi-agent plans', in AAA/, pp. 115-119. Schmidt, K., 1990, 'Analysis of cooperative work', Technical Report, Rise National Laboratory, Roskilde, Denmark. Vallacher, R. R. & D. M. Wegner (eds), 1985, A theory of action identification, Hillsdale NJ: Lawrence Erlbaum. Wallace, J., J. Stockenberg, & R. Charette, 1987, A Unified Methodologyfor Developing Systems, New York NY: McGraw Hill. Whiteside, J., J. Benett, & K. Holtblatt, 1987, 'Usability Engineering: Our experience and evolution', in M. Helander (ed), Handbook of Human-Computer Interaction, Amsterdam: North-Holland. Winograd, T., 1987, 'A language/action perspective on the design of cooperative work', HCI, 3:1 pp 3-30. Yourdon, E., 1989, Modern Structured Analysis, Prentice Hall.
Notes In order to create certain links additional psychological research was conducted. It is skipped here to concentrate on the major points in this example. An agent in this model need not be a single individual. An agent can be any group of people, e.g. a department or an organization.
101
Chapter 7
Approaching Design for Integrated CSCW-DAI Systems Dirk E. Mahling
Department of Information Science University of Pittsburgh
Introduction "Men work together," he said from the heart, "whether they work together or apart." ROBERT FROST, A Tuff of Flowers
Cooperation and coordination are increasingly being recognized as determinants of success in a wide variety of endeavours. In particular, knowledge concerning the coordination in our pursuit of complex activities has gained the interest of the research community and the business world. Complex tasks such as assessing ecologies and economies, designing large scale technologies, or
102
Dirk E. Mahling
supervising major construction projects, are fields that require an explicit design methodology to cope with coordination and cooperation issues. In addition, these artifacts allow us to cope with demands and changes in our physical environment, our social structures, and our cultural activities. Our daily life is substantially influenced by the machines, buildings, and tools that surround us. Just as we and our society are influenced by the artifacts, they themselves are influenced by the way we build and employ them (Ach, 1905). Increasing complexity and the need for coordination in our society leads to increased complexity and cooperation features in the artifacts demanded, while the use of tools that enable cooperation shapes the structure of group work. The design of systems, cooperative or not, has mostly been an elusive art rather than a firm science. Bringing design closer to the scientific disciplines has been attempted, for instance, in software engineering and in knowledge engineering, with varying degrees of success. While some interactive systems could be built and refined without an explicit methodology governing the design process, cooperative systems require a more systematic approach. It becomes necessary to move from the art of system design to an engineering approach for cooperative systems. In addition, cooperative systems require a broader view of design than is usually taken in software engineering. Recent approaches, such as cognitive engineering, social engineering, or usability testing, to name just a few, are essential for the effectiveness and acceptance of such systems. This means that knowledge about the intended domain and the usage of the system should guide the design. The constructive use of theoretical knowledge is referred to as "proactive". This chapter addresses the design needs of intelligent, cooperative systems and suggests a design approach for such sygtems. The next section introduces intelligent human-computer cooperative systems, the particular type of cooperative systems considered here when designing for cooperation. The following section combines proven and recent design and analysis approaches into a system design method. The next section shows how the method can be used to create a generic architecture, while the last section points to future work.
Human computer cooperation systems As no coherent design methodology exists for conventional systems, it is extremely hard to attack the design problem for cooperative systems generically. This chapter therefore limits methodological considerations in
Approaching Designfor Integrated CSCW-DAISystems
103
CSCW (Computer Supported Cooperative Work) to a special type of cooperative system: Human Computer Cooperation Systems (HCCS), an integration of cooperating people and distributed knowledge-based machine agents. Human computer cooperation systems (HCCS) concentrate on providing means for cooperation among spatially or temporally separated people or organizational units working on complex tasks. A major step toward accomplishing this goal is to regard machines and software programs as not only facilitators of communication among people but also as active participants in project management, problem solving, and task execution (Croft & Lefkowitz, 1988; Haugeneder et al., 1989; Imagine, 1990). Such intelligent agents may range from simple printers and sensors over numerically controlled machines to sophisticated knowledge bases and expert systems. Viewing human and machine agents as partners in communication, cooperation, problem solving, and task execution extends the conventional paradigm to HumanComputer Cooperative Work (HCCW), which allows all participants to work on common goals and their own objectives. Such systems are thus trying to integrate cooperation and support concepts from CSCW and DAI (Distributed Artificial Intelligence). Goal-based cooperative work therefore is the interaction among a group of people in order to achieve their individual and group goals. Goals are derived from wishes and intentions in individual and group processes, which have yet to be more closely understood and formalized. While goals can be formalized to describe desired states in a model, wishes and intentions remain elusive. But even the complexity of formal goals in typical environments needs to be handled by problem solving and planning mechanisms (Fox, 1981). Cooperation comes about as the necessary result from this complexity and the limited knowledge of individuals and organizations. These interactions occur not only in sharing the performance of an activity, as is usually assumed in multi-agent planning (Rosenschein, 1982), but also for initial planning and resolution of conflicts during the activity. Examples of goal-based cooperation include project management, collaborative authoring, and office work. In designing such systems, one is concerned with facilitating group interaction and providing support for individual activities. There are currently two perspectives used as basis for the design of Human Computer Cooperation System. One focuses on problem solving by supporting planning (Lefkowitz & Croft, 1989; Barber, 1983), and the other on communication (Winograd, 1987; Malone et al., 1986). Each of these approaches complements the other, and there
104
Dirk E. Mahling
is a need for an integrated perspective to effectively support complex cooperative tasks such as project management In most cooperative work environments, some of the activities performed by the agents are routine and others are non-routine. The latter require explicit planning before they are performed. The goals and activities of different agents may be interdependent. They may be subgoals of some higher level goal, or the effects of an agent's action may preclude another agent's activity. Supporting communication between agents can help them coordinate this activity appropriately, but it should also be possible for a CSCW system to provide active support in generating and executing complex plans.
Proactive design approach for cooperation Techniques and methods to help design cooperative systems arose as answers to needs of practioners in the field or they grew out of theoretical research. Applications can most frequently be found in the areas of software interfaces to computers, airplane cockpits, or nuclear powerplant control centers. It is not surprising to find new developments in the area of interface design or usability engineering only loosely integrated with existing practices. Few design techniques add ways to achieve proactive use of scientific knowledge, yet every engineering discipline needs to develop methods, which are based upon its underlying sciences. Using scientific knowledge to predict, design, or create is proactive and therefore distinct from the retroactive scientific analysis or explanations of systems and their behavior. To move the design and construction of interactive systems closer to the engineering disciplines, proactivity is necessary. The method starts by mapping the social, cognitive, and functional territory (Mahling, 1990), thereby accounting for the diversity of participating agents and their heterogeneous cooperative settings. This mapping process includes traditional task and goal analysis, ethnographic methods, and other behavioral and analytical techniques. After the mapping survey of users, tasks, communications, and cooperation patterns has reached a stable level, the formation of a model can start. For this purpose, existing models and theories in the scientific body of knowledge can be used to embed, explain, or predict findings. To be relevant for cooperative systems, special attention in this phase should be given to coordination science, the theory of communicative processes (social as well as informational), and, of
Approaching Designfor Integrated CSCW-DAISystems
105
course, social psychology. Examples for the relation between theories and systems are: 9 speech act theory -COORDINATOR (Winograd, 1987) 9 argumentative writing - WHAT (Hashim, 1991) 9 communication acts (Kedzierski, 1982)
Support in system development
environments
9 organization audit and analysis - DEVA (Rein, 1992) Facts and observations that can not be covered in this way may point to additional theoretical research. Eventually a model should be synthesized that integrates data from the mapping process, existing models and theories, which are applicable, and sub models from additional research. Based on this synthesized model, implications can be drawn for how to design or modify the collaboration among human and machine agents. Rapid prototyping in conjunction with user-centered design and user participation is used to build initial versions of a solution for cooperation problems. These solutions are iteratively refined, until operational usability goals are reached (Whiteside et al., 1987). This method attempts to accommodate concerns and ideas expressed in the recent approaches to design. It also tries to capture the core of the newly developed view of system building. Recent approaches to system engineering put a strong emphasis on users as agents in communicative and cooperative settings. This is reflected in the participation of users in conceptual design phases, the ethnographic emphasis of spiraling-in on questions important to users, and the active use of evaluations and resulting redesign. Another trend can be recognized in the formalization of cognitive parameters and in efforts to integrate requirements and specification languages. This hints at a design language, which can be used in all phases of the system building process and which allows one to capture user needs on cognitive and social levels, as well as traditional aspects of requirements and specification languages. A powerful idea which has rarely found realization is the use of knowledge for system design. System designers would be able to take a qualitative leap if they could readily access relevant knowledge in the body of science that is closely related to the design problems at hand. This proactive use of theoretical knowledge would make constructive use of findings, rather than explaining design failures retroactively, thereby enhancing design quality and increasing system stability.
106
Dirk E. Mahling
The design method can be summarized as follows: 1
Requirements a Domain/Task/Ontological Analysis b User/Group Analysis c Communication/Cooperation Analysis
2
Model Formation a Connections to existing Theories and Findings b Selection of the best fitting Alternative c Required Extensions or Adaptations d Synthesis into a coherent (formal) Model
3
System Design and Implementation a (Formally) deriving System Specifications b Optimization: Functional, Architectural, Cognitive, Socio-Cooperative c Rapid Prototyping Usability Testing a Evaluation with Users b Iterative Redesign
The details of the method are discussed in the following subsections.
Requirement analysis To start building a system, software engineering teaches us, a thorough specification and requirement analysis must be performed (Yourdon, 1989). This analysis helps us understand the purpose and the intended functionality of the system. Dealing with knowledge-based systems, this analysis has to extend to the knowledge, or ontological, level to capture underlying meanings and connections that would usually not be modelled in data analysis. In particular three requirements should be defined: tasks, context, entities
Which tasks should the system perform and how should it do that in the context of the overall work paradigm. Which ontological entities are encountered? How should they be represented? How do they relate to the tasks of the system and the purpose of the overall organization? single users, user groups, organizational units, organizations
Which requirements are posed by the cognitive abilities of single users for the interface and task support capabilities of the system? Which types of user
Approaching Designfor Integrated CSCW-DAISystems
107
groups exist? What type of social interaction occurs currently between the individuals in these groups, what interaction occurs among the groups, and how would that be affected or changed by a system? Which parts of an organization are to use the system and how is that going to affect the organizational structure?
cooperation and communication Which communication structures exist currently and how should communication be changed? Which communication media and channels does that affect? How is communication embedded in the organizational context? Which cooperation techniques can be employed? On what types of communication do these cooperation methods rely? A number of more or less formal tools and notations already exist to support requirement analysis activities. Most prominent are conventional tools from the domain of software engineering. Hierarchical data flow diagrams, state transition diagrams, and entity relationship diagrams can be used in the process of task and context requirement analysis (Yourdon, 1989). An important distinction can be drawn between functional modeling and behavioral modeling (Wallace et al., 1987). Basic relations between functions are precedence, dominance, parallelism, and feedback. A task or function preceeds another one when its output is the input to a following task or function. A task dominates another task, when its output is control data for the other task. Parallelism indicates the independence of the two tasks, while feedback occurs when ouput data flows back to a preceeding task. The behavioral perspective of a system is concerned with its dynamic features. It provides a model of the type of activity the system will perform at a certain point in time. The behavioral model is needed since not all temporal aspects are covered by the functional model. Examples are the combination of inputs to generate certain outputs or exceptions that might occur outside the system. Event modeling in state transition diagrams is an approach to issues in behavioral modeling. Most social and psychological methods of data gathering, such as interviews, questionnaires, structured observation, free recall, or form filling are adequate to gather user and organizational requirements. Ethnographic techniques and other tools from anthropology can help to formulate relevant questions. Analysis of cognitive workload and role activity theory are more formal approaches to derive user and group requirements. Organizational requirements can be
108
Dirk E. Mahling
assessed with tools and methods described in Mintzberg's organizational studies (Mintzberg, 1979). Communication and cooperation requirements should be built on the results of the preceeding two steps. Communication can either be analyzed on an operational level using Hoare's language for communicating sequential processes (CSP) (Hoare, 1985) or on a higher level of abstraction using a structuration approach (Lyytinen, 1990). While CSP is a formal language with primitives such as prefix (wait for event then activate task) or disjunction (wait for event I or event 2 and depending on that do either task 1 or task 2), structuration views machines in the cooperation process in a threefold way. Machines can either be seen as communication media, as shared materials for the objects created in the work process, or as tools which help to manipulate materials. Practical and discourse consciousness are distinguished with goal generation, means generation, and evaluation belonging to the discourse and manipulative actions and control actions belong to the practical consciousness. On the coordination side, certain coordination components can be identified (Malone, 1988): 9 goals 9 activities 9 actors 9 interdependencies Goals and activities as well as actors should have been identified in earlier stages of this analysis process. The major task here is to identify and manage the dependencies between tasks and the conflicts between user or group goals. Interdependencies such as prerequisites, shared resources, or simultaneity are generic, while the manufacturability of a machine part or the information sharing about customer visits from various departments is domain specific. The outcome of the requirement analysis stage should be a set of goals and contextual parameters, which should ideally be formalizeable to further guide the design process. The more formal the specifications, the stronger the design implications in later design stages. The design process can be viewed as a search through a search space with the goal being partially defined but the path from the current state to the goal being the problem. While the goals have a guiding function in the further design process, task analysis, coordination models, and user models provide the contextual constraints for selecting the best path through the design problem space.
Approaching Designfor Integrated CSCW-DAI@stems
109
M o d e l formation When the goals and tasks of the users have been formally analyzed, theories in cognitive science, social science, and other relevant fields relating to these goals and tasks should be found and customized. This is a difficult task which today is often neglected because it requires interdisciplinary communication and cross referencing to identify relevant theories. It can be achieved via keyword search or other matching patterns. Formalization and computerized tools to aid in this task may be motivated through developing design and engineering methodologies. If the goal, for instance, is to build an expertise transfer system, recall of knowledge becomes crucial. Previous experiments, models, and theories in cognitive psychology about recall of activities should therefore be found and related to the particular goals at hand. Frequently, existing models or theories do not fit the design problem completely. Though major issues are addressed, certain crucial details might inhibit the immediate use of an established theory. In this case additional research must be completed to either customize or extend the existing model. This research might be theoretical in nature, or involve experiments with people. With these extensions, augmentations, and customizations, a dedicated model can be constructed that allows system designers to obtain operational answers. Formal rigor in the expression of results of the analysis and in the representation of the synthesized model help to capitalize on existing knowledge.
Design and realization The synthesized model, the results from the analyses, and the design goals provide a basis for design implications. While the contextual results from the analyses provide constraint-based boundaries of the design space, the design goal marks a position in the design space that should be reached. The synthesized model can be seen as the means that help the designer to walk in the design space towards the goal. The stronger and more expressive the chosen design language, the more tangible the implications for the initial design can be. Goals and context could, for instance, be expressed in well formed formulae. This design language would allow the use of an inference engine to draw design conclusions, similar to meta-planning. This step in the methodology translates static knowledge into new design. It is an engineering idea that needs to be refined and developed in more detail in the future, as the true power of the method is located here.
110
Dirk E. Mahling
Ideally, these design implications form a coarse, initial draft of the design of the whole system. This initial draft can be refined using more conventional methods. The cognitive parameters can be optimized using quantitive methods of cognitive engineering (Fisher, 1988). Various hardware optimizations and system engineering optimizations and refinements can also be performed at this point. To realize the optimized version of the initial design, rapid prototyping techniques should be used. Rapid prototyping allows the involvement of users to quickly verify secondary design decisions. Rapid prototyping of the interactive human-computer system also allows one to test design alternatives and to alter, without major effort, parts of the system. When a stable implementation of the first design has been found, usability testing and redesign can start (Whiteside et al., 1987).
Process summary of the method Having introduced the components of the method, we can now assemble the major steps, tools, and documents into a design process. Starting with the requirement analysis, tools described above, such as state transition diagrams, structurational analysis, or CSP, are used to generate (formal) requirement specifications. These specifications are the basis for querying the body of scientific and engineering knowledge in search of theories and models that could be relevant to the problem at hand. The requirement specifications also result in a set of operational usability goals, which define at the beginning of the design process what the functional, non-functional, and behavioral goals of the system should be. The query to the body of knowledge results in a set of candidate theories. Now it must be decided if the candidate theories are overlapping or disjunct and how well they fit the scope of the requirements. Identifying areas of overlap permits the computation of goodness of fit parameters and selection of one or a set of theories from the candidates. Still there might be areas where the selected theory is not applicable to the requirements. In that case additional research should be conducted to supplement the selected theory. With this additional research, a synthesized model can be constructed. The synthesized model acts as control and source, matching the needs stated by the requirements on the basis of general design principles. Specific architectures and system design specifications should be generated at this point. On the basis of these specifications, one can run a number of optimization processes, such as quantitative cognitive engineering tools or design
Approaching Designfor Integrated CSCW-DAISystems
111
postprocessors. All the above activities should produce an intial sketch for a system that is now ready for rapid prototyping. Rapid prototyping quickly integrates with usability engineering. Feedback from the users changes the prototype; attainment of usability goals can be forecast. At this stage it is necessary to identify larger deviations from the usability goals and other deficiencies that become apparent in the system. Early recognition of these factors permits starting the iterative design process. Here it becomes necessary to return to previous stages in design method and spiral upwards until the usability goals are met.
Using the method in analysis and design To illustrate the practical use of the method presented in the last section, consider designing an agent and activity model that could accommodate people and knowledge-based machine agents, therefore serving as a generic computational cooperation environment.
HCCS requirements To identify the fairly abstract requirements for such a system it is impossible to draw on highly formal methods such as hierarchical data flow diagrams or CSP. Instead, structuration analysis and high level task analysis for the functional side of the requirements, coordination theory for the cooperative aspects, and Mintzberg's organizational design analysis tools for the people/organizational aspect are used. Following this method, the following non-formal requirements emerge:
Distribution Collaboration among the members of a team takes place in a (partly) asynchronous and distributed manner.
Diversity A team may have a wide variety of members, ranging from simple sensors to complex software systems to humans, which have drastically varying functionalities and capabilities.
Flexibility The cooperation roles of the individual members of a team are not totally predetermined on the basis of a rigid organizational structure; rather they can
Dirk E. Mahling
112
be adopted dynamically during the work process, depending on the technical competence of the collaborative agents and the structure of the collaborative task.
Redundancy The various partners' competences may be overlapping and even competing, leading to increased requirements concerning the modeling of the overall cooperation process.
Stability Teams are able to withstand the loss of overall communication for a while or the total loss of individual members, though they may not function as smoothly or as efficiently.
Selecting a theory for model formation Taking this set of requirements to a library and starting, for instance, a keyword search yields an overwhelming amount of retrievals. A large number of the retrieved items can quickly be disregarded. Still the number of candidates remains fairly high. Current information retrieval systems permit the formulation of fairly complex, boolean queries that can limit the returned set dramatically with a high probability of retrieving relevant items. Other IR systems employ AI-methods or neural nets to retrieve a handlable set of highly relevant items. Using such systems, the following candidate items are presented" 9 speech act theory (Winograd, 1987) 9 enactment theory (Ach, 1905; Vallacher & Wegner, 1985) 9 Diplans (Holt, 1988) 9 process engineering (Curtis et al., 1992) 9 CSCW conceptual framework (Schmidt, 1990) To identify a single candidate or a set of supplementary ones, we must now assess the relevance and extent to which the requirements are covered. One can start by omitting the conceptual framework from consideration because it is directed at analysis, not at synthesis. Diplans is a notation that also carries some analysis features with it. It is not as easy to omit because these graphs can be used as a notation for future cooperative scenarios. Still they can not provide content answers to the requirements. Process engineering seems like a good candidate since the task and coordination requirements can provide some
Approaching Designfor Integrated CSCW-DAI@stems
113
answers. On the human/organization side this candidate becomes weak, as it does for the flexibility requirement. Enactment theory has been applied to study phenomena as diverse as motivation, cognitive workload, and exercise science. The study of speech acts, for example, can be viewed as a very specialized enactment theory. Enactment theory defines an enactment as the building block of human activities. An enactment is a conscious, goal-directed series of operations of a human being, controlled by will, directed towards shaping reality. An enactment contains operations, conducted by a human, which transform states of reality into other states, serving a purpose (Klaus & Buhr, 1972). It has a hierarchical structure and can possibly consist of other actions. Context and opportunity are also addressed. The concept of the actor in enactment theory is given particular consideration, noting the interaction between actor and context. Therefore, enactment theory is chosen as the theoretical basis for the design of our HCCS .'
HCCS design based on enactment theory To start deriving design implications one returns to the requirements. Flexibility and distribution of tasks requires an explicit design of task flow. Going to enactment theory, highly formalized properties of enactment chains can be directly translated into control constructs:
Task Initialization Including exchange of beliefs, commitments to goals, and resolution of goal or belief conflicts.
Actions concerning the planning and scheduling of tasks Including negotiation of contracts, detection of resource decomposition of complex tasks, commitments to subtasks, etc.
violations,
Task Execution Including monitoring, execution feedback, etc.
Evaluation Including effort/result evaluation, indexing of exceptions, etc. An agent 2 engaged in goal-based cooperative work in the above sense is in enactment theory characterized by a set of beliefs that result from the performance of this work. These beliefs are a basis for the coordination of the activities of the agent. The characteristics of an agent derived directly from enactment theory are:
114
Dirk E. Mahling
Wishes:
Unarticulated intentions of an agent that might lead to goals.
Goals:
Desired future states of the contextual world, individual to the agent or shared with others.
Activity Knowledge:
Knowledge about how to achieve domain goals.
Plans:
Current planned domain activities for achieving goals.
Roles:
An agent's responsibilities for a part of a plan of another agent. Organizational structure may be viewed as a set of relatively static roles.
Capabilities:
The potential roles an agent can play.
Priorities:
The relative importance attached to a domain activity, among the agent's multiple ongoing activities.
Preferences:
The choice of a particular course of action, among alternatives.
Expectations:
The expectations an agent has about others' actions, such as expecting a reply to a message, or a report of completion of an activity.
Sharing beliefs is an important aspect of cooperation in enactment theory. An agent may be aware of the plans, roles and capabilities of other agents. Performance of generic activities leads to this sharing of beliefs. For instance, during establishment of commitments for roles in a plan, an agent may communicate a portion of the plan as a context to other agents. It is conservative to assume that beliefs of agents about others are simple, and agents hold views of other's beliefs (probably incorrect) such as those mentioned above. The resulting architecture is a set of machine agents (nodes) for assisting people in goal-based cooperative work. A node extends the problem solving support of conventional human-computer planning systems (Lefkowitz & Croft, 1989) by supporting negotiation, communication and sharing of beliefs in goalbased activity. The architecture of a node is shown in figure . Eventually a cooperative knowledge based planning system emerges that can assist people in performing and coordinating multiple interdependent activities. It uses non-linear, hierarchical planning for generating plans for an agent's goals in domains where the activities are loosely structured and underspecified. In addition it monitors the performance of the planned activities. The planner,
Approaching Designfor Integrated CSCW-DAISystems
115
domain description, and execution monitor modules in figure constitute the machine part of the system. In the distributed architecture, the AI-planner provides the problem solving support for the generic activities of execution, monitoring and planning.
Future work This chapter has presented a preliminary proposal for a design method that is focussed on human computer cooperation systems. It showed how the method could be used to derive a distributed system on an underlying enactment basis. In future, we plan to refine the design method and widen the types of systems that can be generated with it. In particular, we are planning to generate a stable version of the system architecture and start conducting usability studies. This will lead us into the later stages of the design method. We are interested in generating notations and tools that would allow a more comfortable application of the design method. This would entail moving toward a more formal design language which would allow us to specify and verify in a stricter fashion and to automate the derivation of some of the design implications.
116
Dirk E. Mahling
References Ach, N., 1905, Ober die Willenstiitigkeit und das Denken, Vandenhoeck. Barber, G., 1983 'Supporting organizational problem solving with a work station', ACM TOOLS, 1, pp 45-67. Croft, W. B. & L. S. Lefkowitz, 1988, 'Knowledge-based support of cooperative activities', in A. H. Bond & L. Gasser (eds), Readings in Distributed Artificial Intelligence, Morgan Kaufman, pp 599-605. Imagine Consortium, 1990, 'Imagine: Integrated Multi-Agent Interactive Environment', Technical Report, Esprit Imagine, Commission of the European Communities,. Curtis, B., M. Kellner & J. Over, 1992, 'Process modeling', Communications of the ACM, 35: 9. Fisher, D. L., 1988, 'Optimization in cognitive engineering', Lecture Notes for Cognitive Engineering Seminar, IEOR 689, May, Department of Industrial Engineering, University of Massachusetts. Fox, Mark S., 1981, 'An Organizational View of Distributed Systems', IEEE Transactions on Systems, Man and Cybernetics 11, pp 70-80. Hashim, S., 1991, 'WHAT: An argumentative apporach for organizing and documenting research activities', Journal of Organizational Computing, 1: 3, pp 275-302. Haugeneder, H., D. Scheidhauer, & D. Steiner, 'Teamware: Computergestfitzte L6sung komplexer Aufgaben im distribuierten Mensch-Maschine Team', Technical Report KIK 1-89, DFKI (German Research Center for AI). Hoare, C., 1985, Communicating Sequential Processes, Prentice Hall. Holt, A., 1988, 'Diplans: A new language for the study and implentation of coordination', ACM TOOLS 6: 2, pp 109-125. Kedzierski, B., 1982, 'Communication and management support in system development environments,' Proc. CH182, New York NY: ACM. Klaus, G. & M. Buhr, 1972, Philosophisches W6rterbuch, VEB Deutscher Verlag der Wissenschaften. Lefkowitz, L. & W. B. Croft, 1989, 'Planning and execution of task in cooperative work environments', in Proc. IEEE Conference on AI and Applications. Lyytinen, K., 1990, 'Computer supported cooperative work issues and challenges: a structurational approach', Technical Report, Jyvaskyla University, Finland. Mahling, D. E., 1990, A Visual Language for Knowledge Acquisition, Display and Animation by Domain Experts and Novices, PhD thesis, University of Massachusetts. T. Malone, 1988, 'What is coordination theory?' Technical Report, Cambridge, MA: MIT.
Approaching Designfor Integrated CSCW-DAI Systems
117
Malone, T., K. Grant, K. Lai, R. Rao, & D. Rosenblitt, 1986, 'Semistructured messages are surprisingly useful for computer supported coordination',, in Proc. CSCW 86. Mintzberg, H., 1979, The Structure of Organizations, Prentice Hall. Rein, G., 1992, 'Collaboration Technology for Organization Design', HICSS 26, Hawaii. Rosenschein, J., 1882, 'Synchronization of multi-agent plans', in AAA/, pp. 115-119. Schmidt, K., 1990, 'Analysis of cooperative work', Technical Report, Rise National Laboratory, Roskilde, Denmark. Vallacher, R. R. & D. M. Wegner (eds), 1985, A theory of action identification, Hillsdale NJ: Lawrence Erlbaum. Wallace, J., J. Stockenberg, & R. Charette, 1987, A Unified Methodologyfor Developing Systems, New York NY: McGraw Hill. Whiteside, J., J. Benett, & K. Holtblatt, 1987, 'Usability Engineering: Our experience and evolution', in M. Helander (ed), Handbook of Human-Computer Interaction, Amsterdam: North-Holland. Winograd, T., 1987, 'A language/action perspective on the design of cooperative work', HCI, 3:1 pp 3-30. Yourdon, E., 1989, Modern Structured Analysis, Prentice Hall.
Notes In order to create certain links additional psychological research was conducted. It is skipped here to concentrate on the major points in this example. An agent in this model need not be a single individual. An agent can be any group of people, e.g. a department or an organization.