Document Sample Powered By Docstoc
					                                             A Multi-Agent Architecture
                                        for Cooperative Software Engineering

                                      Alf Inge Wang, Reidar Conradi£ and Chunnian LiuÝ

                             Abstract                                           time/location matrix [13] (synchronous/asynchronous and
                                                                                non-distributed/distributed). We may add an extra dimen-
    This paper looks at how Cooperative Software Engineer-                      sion to the CSCW typologies, considering different kinds
ing (CSE) can be supported. We first investigate the process                     of cooperative work in the order of increasing complexity
aspects by presenting a traditional process architecture sup-                   of the process support they need [15]:
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
    Keywords: Computer-Supported Cooperative Work,                                  Lotus Notes [21], Active Mail [12] and MAFIA [16].
Cooperative Software Engineering, Software Process Tech-
nology, Multi-Agent Systems                                                       ¯ Coordinated workflow, such as traditional centralised
                                                                                    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
been focusing on how to make people work together in an                           ¯ Cooperative workflow, such as decentralised soft-
organised and planned way (partly pre-planned). For high-                           ware development and maintenance work conducted in
level processes with little details, it is likely that it is pos-                   distributed organisation or across organisations. Here
sible to make people work in this manner. However, the                              the shared workspace and the cooperation planning are
development of software involves people that cooperate to                           the main extra factors from the process point of view.
solve problems and to do actual work. These kind of pro-                            Example of a system supporting distributed organisa-
cesses are very hard to support by traditional software pro-                        tions and processes is Oz [3].
cess support tools, because the focus will be more at coop-                     By Cooperative Software Engineering (CSE) we mean
erative aspects than pure coordination of work [22]. In this                    large-scale software development and maintenance work
paper we introduce an architecture to provide support for                       which falls into the last two categories in the above list. Be-
cooperative software 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
   Ý Beijing Polytechnic University (BPU), Beijing, P.R. China. Chunnian        tributed, but may also work on different platforms, at dif-
Liu’s work is partly supported by the Natural Science Foundation of China       ferent times, with different process models. A better un-
(NSFC).                                                                         derstanding about CSE processes is needed as well as a full

range tool support of such processes. The research in this                                                         Experience
area will help the software industry to change the work style                                                       Base                 evolution
to take full advantage of WWW, and will enrich the research                                                       doc models                reuse
area of Software Process Technology (SPT) in which so far                   Web server                                            plan
a centralised work style has been often assumed implicitly.                                                                            Repository
                                                                                                                                       Project DB
    Compared with the traditional architecture (as found in          Internet                                   Internet

systems similar to EPOS [22]), an agent-based architecture
is advantageous in terms of simplicity and flexibility, and                                                                              planner
                                                                                 planner                                   client−2
particularly useful in modelling and providing support to             client−1   scheduler                                              process engine
                                                                                 process engine
cooperative activities [6, 5]. In this paper, we try to inte-                                                                       Private
                                                                            Private                                                 Workspace
grate the areas of CSCW and SPT in a multi-agent archi-                     Workspace                      coop. planner            of client−2
                                                                            of client−1
tecture. First we investigate the process aspects of CSE                                           Negotiation / Coordination
                                                                                                  client for Project Manager
by presenting a traditional process architecture supporting
CSE. Then we propose a multi-agent architecture for CSE,
which is an extension and specialisation of the more general                                          Shared Workspace
                                                                                                      (common Lib,
architecture [17] for all CSCW. This architecture will then                                            etc.)
be applied to an industrial CSE scenario.
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
view (see, for example [9, 19, 7, 14]). To see how CSE is            stored and shared. The private workspaces are provided
supported by a traditional architecture, we present the pro-         with tools for planning, scheduling and enaction of the pro-
cess support in such a architecture. This architecture is usu-       cess model. The shared workspace provides support for
ally realized by a Process-sensitive Software Engineering            cooperative planning and negotiation, and for coordination
Environment, a PSEE, with a spectrum of functionalities              through cooperative protocols. The shared workspace is
and associated process tools. The support is needed in three         managed by a project manager. The architecture is web-
main areas; at the Process Modelling template level (defin-           based, and repository and experience base support is pro-
ing process in PML), at the Instance level (adding detail to         vided through a web-server and a CGI-interface to the
process model), and for Enactment and monitoring.                    repositories.
    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.

3 Multi-Agent Architecture for CSE                                        creation and deletion of agoras. In some cases more
                                                                          specific system agents are needed. Monitor agents
The previous section shows how complex a CSE environ-                     track events in workspaces and agoras in order to col-
ment could be. Similar situations exist in other areas such as            lect relevant measurements according to predefined
Distributed Artificial Intelligence, Business Process Man-                 metrics. Repository agents can provide intelligent help
agement, and Electronic Commerce. Nowadays, it is be-                     for searching for information.
lieved that the Multi-Agent Systems (MAS) are a better way
                                                                       ¯ Local agents: To assist in work within local
to model and support these distributed, open-ended systems
                                                                         workspaces. These agents act as personal secretaries
and environments. A MAS is a loosely-coupled network of
                                                                         dealing with local process matters such as production
problem solvers (agents) that work together to solve a given
                                                                         activities as well as to define, plan, and enact process
problem. The main advantages of a MAS are:
  ¯ Decentralisation: being able to break down a complex               ¯ Interaction agents: To help participants in their coop-
    system into a set of decentralised, cooperative subsys-              erative work. Such agents can be viewed as shared pro-
    tems. In addition, many groups of organisations are                  cess agents, and they include four subclasses. Commu-
    inherently distributed.                                              nication agents are used to support a spectrum of more
  ¯ Reuse of previous components/subsystems: That is,                    high-level communication facilities. All information
    building a new and possibly larger system by intercon-               flow, also simple communication, uses agents as the
    nection and interoperation of existing (sub)systems,                 underlying communication mechanism to make the ar-
    even though they are highly heterogeneous. Thus, we                  chitecture clean and simple. Negotiation agents ver-
    do not request a common PML, so different PMLs can                   balise their demands (possibly contradictory) to move
    be used in different subsystems.                                     towards an agreement through the process of joint de-
                                                                         cision making [18]. Coordination agents support, e.g.,
  ¯ Cooperative Work Support: being able to better model                 a project manager issuing a work-order that involves
    and support the spectrum of interactions in coopera-                 a group of developers; or a higher-level manager be-
    tive work, since software agents can act as interactive,             ing called in to mediate between negotiating agents
    autonomous representatives of humans.                                to reach an agreement. Mediation agents are used to
                                                                         help negotiating agents reach an agreement. In do-
  ¯ Flexibility: being able to cope with the characteris-
                                                                         ing so, mediation agents may consult the Experience
    tic features of a distributed environment such as CSE,
                                                                         Base (EB, cf. Section 3.4), act according to company
    namely incomplete specification, constant evolution,
                                                                         policies, or ask a project manager (human) for help to
    and open-endness.
                                                                         make decisions.
In the remainder of the paper we try to model the problem
area CSE as a MAS consisting of four components Agents,              3.2 Workspaces (WS)
Workspaces, Agoras and Repositories.
                                                                      A workspace is a place where human and software agents
3.1 Agents                                                           access shared data (usually files) and tools which can be
                                                                     private or shared by a group of people. In addition, in-
In this paper, an agent is a piece of autonomous software            teraction between users and software agents takes place in
created by and acting on behalf of a user (or some other             workspaces. The simplest form of a workspace can be a
agent). It is set up to achieve a modest goal, with the char-        file-system provided with services to read and write files. A
acteristics of autonomy, interaction, reactivity to environ-         more advanced workspace can provide file versioning, ac-
ment, as well as pro-activeness. The whole process (and              cess to of some repository, awareness services, web support
meta-processes) of CSE is carried out by groups of peo-              etc. BSCW [4] is one example of an advanced web based
ple, using tools, such as production tools, process tools, and       workspace implementation. Agents can access data in the
communication tools. Each participant can create a set of            workspace either directly or indirectly through tools.
software agents to assist him/her in some particular aspects.
There are also some system agents created by default for the         3.3 Agoras
administrative purpose in the architecture. We can perceive
the following types of agents:                                       An agora [17] is a place where software agents meet and in-
                                                                     teract , but can also be a market place where agents “trade”
  ¯ System agents: These cover default agents for the ad-            information and services. Agoras should provide agents
    ministration of the multi-agent architecture, such as            with more intelligent means to facilitate their interaction.

The main purpose of the agora is to facilitate cooperative                                 agents and the agents intentions should be hon-
support for applications and agents. Below we propose the                                  est.
following preliminary functionalities that any agora should
support.                                                                          2. Inter-Agent Negotiation:
                                                                                     The progress of a negotiation depends mainly on
 1. Inter-Agent Communication:                                                       the negotiation strategies employed by the agents in-
    This is not simple information-passing, it rather con-                           volved, but agoras should provide mechanisms to min-
    veys intentions, goals, beliefs, and other mental states                         imise communication overheads.
    to form the foundation of negotiation and other com-
    plex interactions. An agora should facilitate agents to
                                                                                 3.4 Repositories
    announce their capabilities and to get in touch with
    agents capable of doing specific tasks. The following
    services are needed to facilitate inter-agent communi-                       In our architecture, a repository represents an information
    cation:                                                                      server that in the simplest form only provide services to
                                                                                 store and retrieve persistent data. A more advanced repos-
                                                                                 itory will provide services for data modelling, searching

   1               2
                                                                                 through data, comparing data, computing data etc. Reposi-
                                            B:Renege                             tories can be accessed either by tools or by agents.
       A:Withdraw A:Counter                                                         The most fundamental repository is the production
                              6                7
                                                        A:Withdraw               repository storing versioned products. Other reposito-
                        A:Reject         A:Withdraw
                   8    B:Withdraw                                               ries may include process models, experiences, user-error-
                                               9                                 reports etc. The more advanced repository is the com-
                                                                                 munity memory across projects which can be realized
         Figure 2. An example of speech-act                                      by an Experience Base. Stored information from previ-
                                                                                 ous projects can then be used to create more accurate es-
                                                                                 timates, foresee problems, and improve processes for new
        ¯ An agora should provide a predefined set of                             projects [19].
          speech-acts [23] (conversation types), such as
          proposal, counter-proposal, acceptance, rejec-                         3.5 The CSE Multi-Agent Architecture
          tion, confirm, deny, inform etc. The various
          speech-acts types will define how agents can in-                        Within our architecture, the four CSE components are inter-
          teract with each other. In many cases a speech-                        connected and interoperate as follows:
          act is represented as a state transition diagram as
          the one shown in figure 2. The speech-acts act                           1. Agents are created by people to help them work; by
          as shared process model for how agents should                              other agents to perform delegated work; or by default
          interact. Figure 2 shows states of a conversation                          to manage workspaces or agoras.
          between two agents A and B. States are shown as
                                                                                      Note that agent creation is a process of instantiation of
          circles while transition between one state to an-
                                                                                      the corresponding agent classes based on templates.
          other is shown as arcs. The terminal state 5 indi-
          cate a successful conversation and the bold lines                       2. Agents are grouped mainly according to people
          shows the path of a successful conversation.                               grouping. In CSE, we can usually perceive various
        ¯ An agora should specify a common syntax for                                groups of people working as a team. The mecha-
          messages transmitted through the agora, so that                            nism we have used to group people and agents is by
          the recipient can analyse the contents of a mes-                           workspaces. Shared workspaces are used to group
          sage.                                                                      teams of human and software agents working together,
        ¯ An agora should specify a common semantic of                               while private workspaces provide support for one hu-
          an agent language. One part of this semantic                               man and possibly several software agents.
          is defined through speech-acts, i.e. what state                          3. Interaction between agents is via agoras. Agoras
          transitions of a conversation that a message will                          can be to provide agent interaction between group
          cause. The semantic also ensures that software                             workspaces as well as interaction between private
          agents interpret the same words similarly.                                 workspaces. Some system agents are created by de-
        ¯ An agora should specify pragmatics for agents.                             fault to manage the agora (creation, deletion, and
          This means that agents shall not lie to other                              bookkeeping).

 4. Agents uses repositories. There are monitoring                    the products for requested platforms and the delivery pro-
    agents, to perceive events in workspaces and agoras,              cess which creates the distribution media and ships prod-
    to collect relevant data and to store the data into repos-        ucts. An overview of the main activities in the scenario pro-
    itories. In this way, the community memory is built.              cess is shown is figure 4. Corresponding responsible groups
    And in decision making, or when some negotiation                  are listed below the activity name.
    runs into difficulties, mediation agents can help by util-             The Development process focuses on work that is di-
    ising previous experience from some repository.                   rectly related to changes of software products and the plan-
                                                                      ning and scheduling of these changes. The three main pro-
 5. Within a group of agents and their shared workspace,              cess steps are: 1) Release and update planning, 2) Schedul-
    any existing process models are allowed, and the tradi-           ing, and 3) Implementation.
    tional process architecture described in Section 2 can                The Maintenance process is triggered by a one of the
    be applied. On the other hand, we can also apply                  following maintenance reports; Software Query Reports
    this agent-based architecture recursively to a group of           (SQRs): Error report or desired, Release Problem Reports
    agents.                                                           (RPRs): Internal problem reports, or Production orders:
                                                                      Requests from customers for a given product or product re-
                                         Agent Group 1                    The maintenance agreements define priorities system
                                        Local                         for SQRs and RPRs, with five levels from Critical down
    Global                              Reposi−       Local
    Repository                          tory          Process
                                                                      to May not be implemented named P0 to P5. Based on
                                                      Model           this classification, the correction phase of SQRs and RPRs
                                                                      is divided into the five following process steps: 1) Reg-
                                                  Legend              istration (by the development department), 2) Estimation
                            Agora            Local Agent              of resources (which developer, effort, 3) Sendout (send
                                             Negotiation Agent        SQR/RPR to developer), 4) Correction (actual problem fix
                                             Coordination Agent       done by developer), and 5) Module testing (by developer).
            Agent Group 2                    Monitor Agent                The Production and testing process starts after a freeze
                                             Mediate Agent            in development code or after defect corrections, or when
             Local                           WorkSpace
                                                                      customers request a delivery revision built for a specific
                                                                      platform. The process consists of the three following steps:
                                                                      1) Production, 2) Testing, and 3) Verification
                                                                          The Delivery process consists of activities to store prod-
   Figure 3. Multi-Agent Architecture for Coop-                       ucts on distribution media and to ship products. This pro-
   erative SE                                                         cess is initiated when a product release or update is made
                                                                      available, and on customer demand. The delivery process
                                                                      can be divided into two main activities: 1) Delivery and 2)
Figure 3 shows the four components of the CSE architec-               Shipping.
ture and their interconnection and interoperation. Note that
the figure shows different types of agents and repositories.                  Maintenance                      Development
                                                                             First line support               Development group
In section 5 we will see a concrete architecture when our                    Maintenance group
                                                                             Upd/Rel Plan group
approach is applied to a CSE scenario.

                                                                             Delivery                         Production and
4 An industrial scenario                                                       Deliv/ship group               testing
                                                                                                             Production/QA group

This scenario is based on the software development and
software maintenance process from a real Norwegian soft-
                                                                                     Figure 4. Scenario process
ware company, in this paper called AcmeSoft. The com-
pany’s products exist on various operating system plat-
forms, including Microsoft Windows NT and various UNIX
platforms. In this scenario we by software development                5 Application of the Architecture to the Sce-
mean the development of future releases and updates of                  nario
products, whereas by software maintenance we refer to the
correction of defects in released software. Common to these           Figure 5 shows our multi-agent architecture for the scenario
processes are a production and testing process which builds           described in the previous section. In this architecture there

are six agent groups (workspaces) corresponding to the                                                    (P0–P4) shown in figure 5 are the result of negotiation,
six groups First Line Support, Maintenance Process group                                                  rather than a simple information passing.
(MPG), Update/Release Planning group (URPG), Develop-
ment group, Production and QA group, and Delivery and                                                  ¯ Two negotiation agents (one belonging to the URPG,
Shipping group.                                                                                          the other to the MPG) communicate via the agora Ag2.
                                                                                                         See below for detailed discussion.
       Customer                            Defect Report                                               ¯ Some coordination agents are observed in between
       Report                               P0: 1 week
       Order                                P1: 1 month
                                            P2: next update
                                                                                                         the MPG (or the URPG) and the Development Team.
                 1) WS                                              2a) WS
           First−Support Process            P3: next release Maintenance Planning Process
                                            P4: new func.
                                                                                                         This means that the change-order are given to a group
                                                                DB for
                  classification                Ag1             Defect            register
                                                                                                         of developers. So the MPG needs to coordinate the de-
                  forwarding                                                      estimate
                                                                                                         velopment work . The change-order will actual cause
                                                                                                         changes to the local process models. In this perspec-
           Order for                   Conflict list                                                     tive we can see the coordination of a change order as a
           Existing DR
                                                                                                         process model change.
                                              Ag2          order
                                                                                                       ¯ Other negotiation and/or coordination agents could be
                                                                        3) WS
                 2b) WS                D                        Development Process
                                                                                         Report          observed in the figure, but for simplicity we just show
       Update/Release Planning Process Work
                                       Order                               coding
                                                                                                         them as simple communication agents.
                                                                           module test
Order                                                                      merging
for              update per quater
                 release per year
                                                                                                         AcmeSoft has a distributed repository used as an EB
with                                                                                                 of the company. The EB holds information about previ-
New                                                                           A3
Platform                                                                     New DR                  ously completed projects and products and about previous
                       5) WS                    Accepted             4) WS                           updates/releases of the current products. Typical data are:
                                                Update /    Production and QA Process
            Delivery and Shipping Process       Release
                                                                        Global test
                                                                                                     the project profiles, evolution patterns, performance met-
                         Make Executable                              verification                   rics, and process models.
                         Forwarding                                                                      Let’s have a closer look at the agora Ag2. There are vari-
                                                                                                     ous inter-agent activities occurring in or transmitted through
                                                                                                     it. In the following, we explain some of these activities:
    Figure 5. Scenario of Software Maintenance                                                        1. Negotiation and coordination between the URPG
    and Development                                                                                      and the MPG.
                                                                                                          First, remember that the main task of the URPG is to
   Each group has their shared workspace. Each group                                                      plan the next update and the next release of a com-
                                                                                                          pany’s products. In doing so, the URPG should make
has also its own process model, which may be an existing
legacy one. The process models of different groups can be                                                 decisions on issues such as what defects should be
                                                                                                          fixed and what new functionalities should be included
heterogeneous. Furthermore, some groups may have this
new agent-based architecture recursively. That is, an agent                                               in the next update/release. What to include is based
group may be spilt into several (sub)groups, and the shared                                               on market analysis and feedback from users (priori-
                                                                                                          tised defect reports). Naturally, market and technology
workspaces into several (sub)workspaces. In all cases, the
inter-(sub)group communication is modelled explicitly via                                                 analysis contributes to this decision-making. The rel-
agoras. In the architecture, we can observe different kinds                                               evant information is presented in users’ defect reports
                                                                                                          with the priority P2–P4, which is received, analysed,
of interaction agents belonging to various groups. Exam-
ples are:                                                                                                 and stored by the MPG. Based on this information, the
                                                                                                          MPG would give requests, suggestions or advice to the
    ¯ Two negotiation agents, one belonging to the First-                                                 URPG about the contents of the next update/release.
      Support group, the other to the MPG, communicate                                                    On the other hand, the URPG may accept, reject, or
      via the agora Ag1. Because when the First-Support                                                   negotiate these proposals. All these inter-agent activi-
      Office conveys a user request for a change and the                                                   ties are carried out through the agora M2.
      desired deadline for the new revision, the MPG may                                                  Secondly, remember that the same development team
      or may not authorise the changes (according to their                                                is responsible both for maintaining existing products
      configuration control policy). Even if the planning of-                                              and for developing new updates/releases. Here we
      fice agrees to authorise the changes, a deadline need                                                have a conflict in resource allocation, and negotiation
      to be negotiated. In other words, the Defect Priorities                                             is necessary.

 2. Mediation in the negotiation between the URPG and                real-world model and assignment of resources to a instanti-
    the MPG.                                                         ated process model. Our architecture’s main contribution is
     As indicated, in solving a resource allocation conflict,         to give process support where traditional SPTs often fail in
     the MPG and the URPG may not by them selves be                  respect changing environment and unexpected events. Fur-
     able to reach an agreement. E.g., the MPG would like            ther work with describe formalities, implementation of pro-
     to “lend” programmer A to fix an error in a product              totypes, and experiment with more industrial scenarios will
     for user B that demands an immediate reaction. On               show if this is the case. Another outcome of our research
     the other hand, the URPG would like to have A as                will be to identify disadvantages of MAS.
     the chief programmer the full next year for a planned
     update/release. The problem is that each negotiating            7 Acknowledgement
     agent views the issue only from its own angle, based
     on local experience. Furthermore, in such a real-life           The authors of this paper want to first of all to thank Mih-
     domain, it is hard to evidence that algorithm-based ne-         hail Matskin, Sobah Abbas Petersen, Monica Divitini, Heri
     gotiation strategies alone can solve such problems rea-         Ramampiaro for suggestions and discussions regarding the
     sonably. Human intervention by a manager of the com-            paper and a big thank to Torgeir Dingsøyr and Joar Øyen for
     pany may be necessary. How much human interven-                 reading through and giving useful comments on this paper.
     tion the agent will need, depends of the definition of
     the agent. In this way it is possible to tailor the agent
     to the needs of the company. It should be possible to
     state, e.g., that resource negotiation for more than a
                                                                      [1] Victor R. Basili, G. Caldiera, Frank McGarry, R. Pa-
     certain amount of money must be done through human
                                                                          jerski, G. Page, and S. Waligora. The Software Engi-
     interventions. The mediation agent works on behalf of
                                                                          neering Laboratory – an Operational Software Experi-
     the higher-level manager, in order to propose an over-
                                                                          ence Factory. In Proc. 14th Int’l Conference on Soft-
     all beneficial solution. In doing so, the mediation agent
                                                                          ware Engineering, Melbourne, Australia, pages 370–
     may utilise previous experiences by searching the EB.
                                                                          381, May 1992.
     For example, if the EB shows that user B has been an
     “important” customer in the past, the mediation agent            [2] Israel Ben-Shaul and Gail E. Kaiser. A paradigm for
     may stand by the MPG and persuade the URPG to con-                   decentralized process modeling. Kluwer Academic
     sider another choice as chief programmer.                            Publishers, Boston/Dordrecht/London, 1995.
                                                                      [3] Israel Ben-Shaul and Gail E. Kaiser. A Paradigm
6 Conclusions and Future Work
                                                                          for Decentralized Process Modeling. Kluwer Aca-
                                                                          demic Publishers, Boston/Dordrecht/London, 1st edi-
In this paper we have introduced an agent-based architec-
                                                                          tion, 1995.
ture to solve CSE problems. This architecture consists of
four main components: Agents, Workspaces, Agoras and                  [4] R. Bentley, T. Horstman, and J. Trevor. The World
Repositories Agents provide flexible and dynamic support                   Wide Web as enabling technology for CSCW: The
to cooperating users, as well as help for doing every-day                 case of BSCW. Computer Supported Cooperative
work. Agents can easily respond to a changing environ-                    Work: The Journal of Collaborative Computing, 7:21,
ment (learn, adopt based on experiences in the Experience-                1997.
Base etc.). It is widely accepted that real software processes
evolve over time, so our process support must adopt and               [5] Anthony Chavez and Pattie Maes. Kasbah: An Agent
cope with such changes. To enable agents to cope with pro-                Marketplace for Buying and Selling Goods. In Pro-
cess changes, they will need to learn from prior experiences.             ceedings of the First International Conference on the
In our architecture this is introduced through repositories               Practical Application of Intelligent Agents and Multi-
(ExperienceBases) as well as agents can learn on their own.               Agent Technology, London, UK, April 1996.
Agoras and workspaces are introduced to support agent in-             [6] Anthony Chavez, Alexandros G. Moukas, and Pattie
teraction and grouping of agents, respectively.                           Maes. Challenger: A Multiagent System for Dis-
   Our architecture has been applied on one specific sce-                  tributed Resource Allocation. In Proceedings of the
nario. We believe, however, that our multi-agent CSE                      International Conference on Autonomous Agents, Ma-
architecture is applicable on various situations, processes               rina Del Ray, California, USA, 1997.
and organisations. One concrete example is to support
meta-process activities, such as discovering/planning pro-            [7] Reidar Conradi, Marianne Hagaseth, and Chunnian
cess models, negotiation about the process model and the                  Liu. Planning Support for Cooperating Transactions

     in EPOS. Information Systems, 20(4):317–326, June                 Workshop on Intelligent Agents in Information and
     1995.                                                             Process Management, page 12, Bremen, Germany, 15-
                                                                       17 September 1998.
 [8] Reidar Conradi, M.Letizia Jaccheri, and Cristina
     Mazzi. Design, Use and Implementation of SPELL,              [18] H. J. Muller. Negotiation Principles. In Foundations
     a language for Software Process Modeling and Evolu-               of Distributed Artificial Intelligence, pages 211–230.
     tion. In Proc. Second European Workshop on Soft-                  Wiley Interscience, 1996.
     ware Process Technology (EWSPT’92), Trondheim,
     Norway., pages 196–214, 1992.                                [19] Minh Nguyen, Alf Inge Wang, and Reidar Conradi.
                                                                       Total Software Process Model Evolution in EPOS. In
 [9] Reidar Conradi, Espen Osjord, Per H. Westby, and                  Proceesings ICSE’97, Boston, USA, May 1997.
     Chunnian Liu. Initial Software Process Management
     in EPOS. Software Engineering Journal (Special Issue         [20] OMG. CORBA Components: Join Initial Submis-
     on Software process and its support), 6(5):275–284,               sion. ftp: ftp://ftp.omg.org/pub/docs/orbos/97-11-
     September 1991.                                                   24.pdf, 1997.

[10] Microsoft Corporation, Redmond, and Wash-                    [21] W.J. Orlikowski.      Learning from Notes: Or-
     ington.     Microsoft DCOM: A Technical                           ganizational Issues in Groupware Implementation.
     Overview.   web: http://www.eu.microsoft.com/                     In Proceedings of the Conference on Computer-
     windows/downloads/bin/nts/DCOMtec.exe, 1996.                      Supported Cooperative Work, CSCW’92, pages 362–
                                                                       369, Toronto, Canada, 1992. The Association for
[11] S. Dami, J. Estublier, and M. Amiour. APEL:                       Computer Machinery, ACM Press.
     A Graphical Yet Executable Formalism for Process
     Modeling. In Process Technology edited by E. Nitto           [22] Alf Inge Wang, Jens-Otto Larsen, Reidar Conradi,
     and Alfonso Fuggetta, pages 61–96, Politecnico di                 and Bjørn Munch. Improving Cooperation Support
     Milano and CEFRIEL, 1998. Kluwer Academic Pub-                    in the EPOS CM System. In Volker Gruhn, editor,
     lishers.                                                          Proc. EWSPT’98, London, 18-19. Sept. 1998, page 17,
                                                                       September 1998.
[12] Yaron Goldberg, Marilyn Safran, William Silverman,
     and Ehud Shapiro. Active Mail: A Framework for               [23] T. Winograd and F.Flores. Understanding Comput-
     Integrated Groupware Applications. In D. Coleman,                 ers and Cognition; A New Foundation for Design. In
     editor, Groupware ’92, pages 222–224. Morgan Kauf-                Ablex, 1986.
     mann Publishers, 1992.
[13] J. Grudin. Computer-Supported Cooperative Work:
     History and Focus. In IEEE Computer, number 5 in
     27, pages 19–26, 1994.
[14] M.Letizia Jaccheri. Reusing Software Process Models
     in ¿ . In The Tenth International Software Process
     Workshop, 6, 1996.
[15] C. Liu and R. Conradi. Process View of CSCW.
     In Proc. of ISFST98, Ocon Technology Application,
     page 12, Bremen, Germany, 15-17 September 1998.
     International Workshop on Intelligent Agents in Infor-
     mation and Process Management.
[16] Ernst Lutz, Hans v.Kleist Retzow, and Karl Hoernig.
     MAFIA - An Active Mail-Filter-Agent for an Intel-
     ligent Document Processing Support. In S. Gibbs
     and A.A. Verrijn-Stuart, editors, IFIP, North-Holland,
     1990. Elsevier Science Publishers B.V.
[17] M. Matskin, M. Divitini, and S. Petersen. An Archi-
     tecture for Multi-Agent Support in a Distributed In-
     formation Technology Application. In International


Shared By: