a multi agent architecture for cooperative software
play

A Multi-Agent Architecture for Cooperative Software Engineering and - PDF document

A Multi-Agent Architecture for Cooperative Software Engineering and Chunnian Liu Alf Inge Wang, Reidar Conradi time/location matrix [13] (synchronous/asynchronous and Abstract non-distributed/distributed). We


  1. ✄ ✁ ☎ ☎ ☎ ☎ A Multi-Agent Architecture for Cooperative Software Engineering � and Chunnian Liu Alf Inge Wang, Reidar Conradi time/location matrix [13] (synchronous/asynchronous and Abstract non-distributed/distributed). We may add an extra dimen- sion to the CSCW typologies, considering different kinds of This paper looks at how Cooperative Software Engineer- cooperative work in the order of increasing complexity of ing (CSE) can be supported. We first investigate the process the process support they need [15]: aspects by presenting a traditional process architecture sup- porting CSE. Then we propose a multi-agent architecture Ad-hoc cooperative work such as brainstorming, co- for CSE, which is better in terms of simplicity and flexibility, operative learning, informal meetings, design work, and particularly useful in modelling and providing support etc. . Process modelling support here is implemented to cooperative activities. We describe an industrial scenario through awareness triggers. of CSE, and show how to apply the proposed architecture to this scenario. The scenario is based on a software devel- Predefined/strict workflow , in traditional Office opment and maintenance process for a Norwegian software Automation style represented by simple docu- company. ment/process flow. Examples of such systems can be Computer-Supported Cooperative Work, Lotus Notes [21], Active Mail [12] and MAFIA [16]. Keywords: Cooperative Software Engineering, Software Process Tech- Coordinated workflow , such as traditional centralised nology, Multi-Agent Systems software maintenance work consisting of check-out, data-processing, check-in, and merge steps. There ex- ist several systems supporting coordinated workflow 1 Introduction (mostly prototypes), e.g., EPOS [8], MARVEL [2] and APEL [11]. Most of the work in the software process community has Cooperative workflow , such as decentralisedsoftware been focusing on how to make people work together in an development and maintenance work conducted in dis- organised and planned way (partly pre-planned). For high- tributed organisation or across organisations. Here the level processes with little details, it is likely that it is possible shared workspace and the cooperation planning are the to make people work in this manner. However, the devel- main extra factors from the process point of view. Ex- opment of software involves people that cooperate to solve ample of a system supporting distributed organisations problems and to do actual work. These kind of processes are and processes is Oz [3]. very hard to support by traditional software process support tools, because the focus will be more at cooperative aspects By Cooperative Software Engineering (CSE) we mean than pure coordination of work [22]. In this paper we intro- large-scale software development and maintenance work duce an architecture to provide support for cooperative soft- which falls into the last two categories in the above list. Be- ware engineering. cause of the rapid spread of World Wide Web as the stan- Computer-Supported Cooperative Work (CSCW) is dard underlying platform for CSCW systems, more soft- a multidisciplinary research area focusing on effective ware companies are moving from the traditional centralised methods of sharing information and coordinating activi- working style to the decentralised one. In the decentralised ties. CSCW systems are often categorised according to the CSE, communication, negotiation, coordination and col- ✂ Dept. of Computer and Information Science, Norwegian University laboration among the various participants are more com- of Science and Technology (NTNU), N-7035 Trondheim, Norway. Phone: plicated, because people are not only geographically dis- +47 73593444, Fax: + 47 73594466, Email alfw/conradi@idi.ntnu.no tributed, but may also work on different platforms, at dif- Beijing Polytechnic University (BPU), Beijing, P.R. China. Chunnian ferent times, with different process models. A better un- Liu’s work is partly supported by the Natural Science Foundation of China derstanding about CSE processes is needed as well as a full (NSFC). 1

  2. ✆ ✝ ✆ range tool support of such processes. The research in this Inter−Project Experience area will help the software industry to change the work style Base evolution process/ to take full advantage of WWW, and will enrich the research doc models reuse area of Software Process Technology (SPT) in which so far config. Web server plan Persistent a centralised work style has been often assumed implicitly. CGI−Interface Repository Compared with the traditional architecture (as found in Project DB Internet Internet systems similar to EPOS [22]), an agent-based architecture is advantageous in terms of simplicity and flexibility, and planner client−2 particularly useful in modelling and providingsupport to co- planner scheduler client−1 scheduler process engine operative activities [6, 5]. In this paper, we try to integrate process engine Private the areas of CSCW and SPT in a multi-agent architecture. Workspace Private of client−2 Workspace coop. planner First we investigate the process aspects of CSE by present- of client−1 Negotiation / Coordination ing a traditional process architecture supporting CSE. Then client for Project Manager we propose a multi-agent architecture for CSE, which is an extension and specialisation of the more general architecture Shared Workspace [17] for all CSCW. This architecture will then be applied to (common Lib, etc.) an industrial CSE scenario. local process model 2 A Traditional Process Architecture sup- porting CSE The key issues of CSE are group awareness, concurrency control, communication and coordination within the group, Figure 1. A General Process Architecture shared information space and the support of a heteroge- Supporting CSE. neous, open environment which integrates existing, single- user applications. All these are related to the software pro- cess. Within the SPT community there have been research on each of the issues, but from a slightly different point of stored and shared. The private workspaces are provided view (see, for example [9, 19, 7, 14]). To see how CSE is with tools for planning, scheduling and enaction of the supported by a traditional architecture, we present the pro- process model. The shared workspace provides support for cess support in such a architecture. This architecture is usu- cooperative planning and negotiation, and for coordination ally realized by a Process-sensitive Software Engineering through cooperative protocols. The shared workspace Environment, a PSEE , with a spectrum of functionalities is managed by a project manager. The architecture is and associated process tools . The support is needed in three web-based, and repository and experience base support is main areas; at the Process Modelling template level (defin- provided through a web-server and a CGI-interface to the ing process in PML), at the Instance level (adding detail to repositories. process model), and for Enactment and monitoring. To full fill the goal as a process support architecture for There are, however, several problems with such a CSE, some underlying components are needed. These com- PSEE/CSE architecture. First , it is too centralised and has ponents makes it possible to apply the architecture in a dis- too much flavour of a centralised database surrounded by tributed, heterogeneous environment. First , a portable plat- a fixed number of applications. Second , too homogeneous form infrastructure for PSEE-based client tools are needed models are used assuming one common PML. This means (candidates are HTML/CGI and Java). Second , the archi- that one PML must be used by all involved partners, al- tecture must offer an integrated environment for tool oper- though this is no necessarily the best solution. Third , it ation and communication (candidates are CORBA [20] or is hard to change process tools and models. Due to the DCOM [10]). Third , we need facilities for distribution of distributed and open setting, we should allow dynamic re- tools and workspaces (candidates are CORBA or DCOM). configuration of process models, as well as for process Fourth , we need a community memory or experience base tools. Forth , a open-ended spectrum of process tools may to store template process models (a candidate is Experience be needed to offer better support for cooperative work, than Factory[1]). what classical PSEE architecture can offer. Figure 1 presents a general PSEE architecture for CSE. Its cooperative support is provided through a shared As will be seen in the next section, a multi-agent archi- workspace where files and parts of the process model are tecture seems more appropriate for a general CSE.

Recommend


More recommend