A Multi-Agent Architecture for Cooperative Software Engineering Alf Inge Wang, Reidar Conradi and Chunnian Liuy January 18, 1999
Abstract This paper looks at how Cooperative Software Engineering (CSE) can be supported. We first investigate the process aspects by presenting a traditional process architecture supporting CSE. Then we propose a multi-agent architecture for CSE, which is better in terms of simplicity and flexibility, and particularly useful in modelling and providing support to cooperative activities. We describe an industrial scenario of CSE, and show how to apply the proposed architecture to this scenario. The scenario is based on a software development and maintenance process for a Norwegian software company. This paper will not go into details regarding agents and agent representation (knowledge representation, security, Artificial Intelligence etc). Agents will be used in the architecture described as a high-level representation of autonomous software acting on behalf of the users or other software. The architecture does not necessarily replace existing Software Process Environments, but can be used in addition to one to better support unpredictable activities and activities that are hard to model with traditional process support tools. Keywords: Computer-SupportedCooperative Work (CSCW), Cooperative Software Engineering (CSE), Software Process Technology (SPT), Multi-Agent Systems
1 Introduction Most of the work in the software process community has been focusing on how to make people work together in an organised and planned way (partly pre-planned). For high-level processes, it is likely that it is possible to make people work in this manner. However, the development of software involves people cooperating in order to solve problems and to do actual work. These kind of processes are very hard to support by traditional software process support tools, because the focus will be more at cooperative aspects than pure coordination of work [1]. In this paper we introduce an architecture to provide support for cooperative software engineering. Computer-Supported Cooperative Work (CSCW) is a multidisciplinary research area focusing on effective methods of sharing information (the product aspects) and coordinating activities (the process aspects). CSCW systems are often categorised according to the time/location matrix, making the distinction between synchronous and asynchronous, and between non-distributed and distributed systems [6]. We may add an Dept. of Computer and Information Science, Norwegian University of Science and Technology (NTNU), N-7035 Trondheim, Norway. Phone: +47 73593444, Fax: + 73 594466, Email alfw/
[email protected] y Beijing Polytechnic University (BPU), Beijing, P.R. China
1
extra dimension to the CSCW typologies, considering different kinds of cooperative work in the order of increasing complexity of the process support they need. For example, we can recognise the following different kinds of cooperative work [10]:
Ad-hoc cooperative work such as brainstorming, cooperative-learning, informal-meeting, design work, etc.. Process modelling support is here implemented through awareness triggers.
Predefined/strict workflow, in traditional Office Automation style. There are two sub-categories: single-person working on complex documents, and multi-persons working on one document. In either case, the process models are formal, but rather simple in the sense that there are not many exceptions of the models (strict flow). Examples of such systems can be Lotus Notes [16], Active Mail [25] and MAFIA [5].
Coordinated workflow, such as traditional centralised software maintenance work consisting of checkout, data-processing, check-in, and merge steps. Here the process modelling should include e.g. the workspaces 1 , coordination and monitoring activities. There exist several systems supporting coordinated workflow (although most of these systems are only prototypes), e.g., EPOS [20, 19, 18], MARVEL [8] and APEL [23].
Cooperative workflow, such as decentralised software development and maintenance work conducted in distributed organisation or across organisations. Here the shared workspace the cooperation planning are the main extra factors from the process point of view. Example of a system supporting distributed organisations and processes is Oz [3]. By Cooperative Software Engineering (CSE) we mean large-scale software development and maintenance work which falls into the last two categories in the above list. Because of the rapid spread of World Wide Web as the standard underlying platform for CSCW systems, more and more software companies are moving from the traditional centralised working style to the decentralised one. In the decentralised CSE, communication, negotiation, coordination and collaboration among the various participants are more complicated, because people are not only geographically distributed, but may also work on different platforms, at different times, with different process models. Better understanding about CSE processes is needed as well as a full range tool support of such processes. The research in this area will help the software industry in the moving of work style to take of full advantage of WWW, and will enrich the research area of Software Process Technology (SPT) in which so far a centralised work style has been often assumed implicitly. Compared with the traditional architecture (as found in systems similar to EPOS [1]), the agent-based architecture is better in terms of simplicity and flexibility, and particularly useful in modelling and providing 1 The concept workspace is
used to name the place where humans and agents works with tools and files. Workspaces are discussed
later in section 3.2.
2
support to cooperative activities (communication, negotiation, coordination and collaboration) [2, 4]. In this paper, we try to integrate the areas of CSCW and SPT in a multi-agent architecture. First we investigate the process aspects of CSE by presenting a traditional process architecture supporting CSE. Then we propose a multi-agent architecture for CSE, which is an extension and specialisation (with respect to CSE) of the more general architecture [11] for all CSCW. The proposed architecture can model the information flow as well as the process flow in CSE, and is general enough to support all kinds of CSE. We describe an industrial scenario of CSE, and show how to apply the proposed architecture to this scenario.
2 A Traditional Process Architecture supporting CSE In order to see the strength of the multi-agent architecture proposed in this paper, we first present a traditional process architecture supporting CSE. The architecture is motivated by the process support needed in CSE. We also identify some clear weaknesses of this architecture which can be alleviated by a multi-agent approach (next section). The key issues of CSE are group awareness, concurrency control, communication and coordination within the group, shared information space and the support of a heterogeneous, open environment which integrates existing, single-user applications. All these are related to the software process. Within the SPT community there have been research work tackling each of the issues, but from a slightly different point of view (see, for example [22, 13, 21, 9]). To see how how CSE is supported through a traditional architecture, we will now present the process support in such a architecture. This architecture is usually realized by a Processsensitive Software Engineering Environment, a PSEE, with a spectrum of functionalities and associated process tools. The support needed can be divided into three main parts: 1. Process Modelling, template-level: defining both action flow/events and communication flow/events in a Process Modelling Language (PML). At the template-level, the main activities are Process Elictation, where template models are expressed in informal notations as e.g., IDEF0 [7], evolve and refine template models based on accumulated experiences, and reuse of template models from previous projects. Thus, the template models must be structured, classified and qualified. Tools needed: Subset of the ones in next point. 2. Process Modelling, Planning and Analysis, instance-level: combining template model fragments into complete instance models. Both individual and cooperative processes must be covered. Tools needed: 1) Process model editors/browsers/viewers, to access parts of the process model, considered as a Process Information System. 2) Process planners/schedulers, where activity networks
3
are made operational. 3) Process model analysers, both for static analysis (consistency checking) and dynamic (“dry-runs”) analysis of process models. 4) Model managers, to manage models in different states (template, instance etc.) and places (workspaces, repositories etc.) 3. Process Model Enactment and Monitoring. This involves interaction with software developers, software work tools, and other processes and their interpreters. A vital part of the enacting process is management of product data between persistent project repositories and temporary workspaces, private or shared. Tools needed: 1) Process model interpreters (process engines), that execute a subset of the process model. 2) Workspace-related tools, checking out and -in work products in a suitable workspace format. 3) Process monitors listen to certain events which may trigger predefined actions. 4) Special coordination/negotiation/mediation tools, interpreting mutual cooperating protocols to realize group awareness, or to reduce and solve conflicts occurring in cooperative work. The architecture support described in three parts above, need some underlying components to full-fill the goal as a process support architecture for CSE. These components makes it possible to apply the architecture in a distributed, heterogeneous environment. The underlying Process Support Architecture will have the following components:
A portable platform infrastructure, supporting PSEE-based client tools as described above. A such infrastructure is possible to realise by using web-technology (HTML and CGI-server) or Java (Java applets and Java-server).
An integrated environment for tool operation and communication. Typical environment candidates are CORBA [15] or DCOM [12], offering tools for asynchronous and synchronous communication, e.g. event handlers.
Facilities for distribution of tools and workspaces, allowing heterogeneous process activities in or between different groups or organisations. Typical candidates are again CORBA or DCOM.
A community memory or experience base, to store template process models. This must be coupled to more operational project repositories and workspaces. Figure 1 presents a general PSEE architecture for CSE. The cooperative support is in this architecture provided through a shared workspace where files and parts of the process model are shared. The private workspaces are provided with tools for planning, scheduling and enaction of the process model. The shared workspace provide support for cooperative planning and negotiation and coordination support through cooperative protocols. The shared workspace is managed by a project manager. The architecture shown is web-based, and
4
Web server
Internet
client−1
Inter−Project Experience Base evolution process/ doc models reuse config. plan Persistent CGI−Interface Repository Project DB Internet
client−2
planner scheduler process engine
Private Workspace of client−1
coop. planner Negotiation / Coordination client for Project Manager
planner scheduler process engine
Private Workspace of client−2
Shared Workspace (common Lib, etc.)
local process model
Figure 1: A General Process Architecture Supporting CSE. repository and experience base support is provided through a web-server and a CGI-interface to the repositories. Some problems with such a PSEE/CSE architecture are:
Too centralised: Although workspaces and tools may be distributed, this architecture has too much a flavour of a centralised database surrounded by a fixed number of applications.
Too homogeneous models: The shown architecture tends to assume one common PML. In reality, distributed processes may have different PMLs and associated process tools. Indeed, some tools may have their own, embedded (process) models, i.e. they are agents on their own right. That is, we have to support possibly different PMLs, with a very open-ended interaction between groups of process tools and actors.
Hard to change process tools or process models: Due to the distributed and open setting, we should allow dynamic reconfiguration of process models as well as of process tools. We may conceive specially configured PSEEs for certain cooperative tasks, where the actors bring in their own tools (agents) and models.
A spectrum of process tools may be needed: The classical PSEE architecture offers rather simplistic enactment tools, essentially supporting execution of a local activity network. Given the spectrum of cooperative work (negotiation, coordination, collaboration, communication), many cooperative tools fall outside of this category, e.g. awareness tools based on event handlers, or negotiation tools between two or more actors. 5
As will be seen in the next section, a multi-agent architecture seems more appropriate for a general CSE.
3 Multi-Agent Architecture for CSE The previous section shows how complex a CSE environment could be. Similar situations exist in other areas such as Distributed Artificial Intelligence, Business Process Management, and Electronic Commerce. Nowadays, it is believed that the Multi-Agent Systems (MAS) are a better way to model these decentralised, distributed, open-ended systems and environments. A MAS is a loosely-coupled networks of problem solvers (agent) that work together to solve a given problem. We can mention the main advantages of MAS, both in general and when applied to the CSE, as follows:
Decentralisation: being able to break down a complex system into a set of decentralised, cooperative subsystems. This is beneficial for reasons of delegation and decentralisation. In addition, many organisations are inherently distributed (e.g. drawing from distributed information sources), or are interested in utilising the WWW to enhance the organisation’s competitiveness. Unlike the traditional, centralised architecture, here we may have distributed databases and unbounded numbers of agents, workspaces and agoras 2
Reuse of previous components/subsystems: That is, building a new and possibly larger system by interconnection and interoperation of existing (sub)systems, even though they are highly heterogeneous. Thus, we do not request a common PML, different PMLs can be used in different subsystems. Also, process evolution (changes in the process models and tolls) is easier to manage.
Cooperative Work Support: being able to better model and support the spectrum of interactions in cooperative work. This is a major advantage of the agent-based architecture over the traditional ones, in which the process modelling and enactment have been concentrated in local activities.
Flexibility: being able to cope with the characteristic features of a distributed environment such as Cooperative Software Engineering, namely incomplete specification, evolution, and open-endness.
Simplicity: being able to offer conceptual clarity and simplicity in modelling and design. Software agents can act as interactive, autonomous representatives of humans, thus making it simpler to model human cooperative activities. In the remainder of the paper we try to model CSE as a MAS. In such a Multi-Agent architecture, we have four components – Agents, Workspaces, Repositories, and Agoras – that are described separately in the following subsections. 2 The
term Agora is used to explicitly model the place agent interaction and agent information sharing takes place [11]. A more
detailed description of agora is presented in section 3.3.
6
3.1 Agents In this paper, an agent is a piece of autonomous software created by and acting on behalf of a user (or some other agent). It is set up to achieve a modest goal, with the characteristics of autonomy, interaction, reactivity to environment, as well as pro-activeness. The whole process (and meta-processes) of CSE is carried out by groups of people, using tools, such as work tools, process tools, and communication tools. Each participant can create a set of software agents to assist him/her in some particular aspects. There are also some system agents created by default for the administrative purpose in the architecture. So we can perceive the following different types of agents:
System agents: This covers default agents for the administration of the multi-agent architecture, such as creation and deletion of agoras. Each agora may have several agents registered, and each agent may be registered in several agoras. Thus, the management of the agoras is not the job of any of the participating agent, hence the need of system agents. The system agent functionality described above is a minimum of features the multi-agent architecture needs. In some cases more specific system agents are needed: – Monitoring agents: To monitor events in and status of the workspaces as well as the agoras (see the following subsections) and to collect relevant measurement according predefined metrics. – Repository agents: A repository agent can provide intelligent help both for human and software agents to search for needed information in repositories.
Local agents: To assist in work within local workspaces. These agents act as personal secretaries dealing with local process matters. It should be possible to create local agents for several purposes, but this paper will only present two examples of subclasses of local agents: – Work agents: To assist in normal production activities, such as software development and testing. For example, a programmer could create an agent to manage the editing, (re)compilation and linking of his/her modules in a more intelligent manner than Unix Make. Thus, a work agent models tool integration, rather than a single software tool. – Process agents: To model the facilities and tools of defining, planning, scheduling and enacting process models, both local and shared.
Interaction agents: To help participants in their cooperative work. Such agents can also be viewed as shared process agents. Such agents include: – Communication agents: To support a spectrum of more high-level communication facilities. All information flow, also simple communication, uses agents as the underlying communication
7
mechanism. This gives the system one mechanism for communication which makes the architecture clean and simple. Communication between software agents take place in agoras, while communication between software agents and humans take place in workspaces. The agent can be used as a simple information carrier between users, and further more as a complex software problem solver that interacts with various agents and information sources in order to complete its mission. – Negotiation agents: By definition, negotiation is the process of joint decision making where the negotiating agents verbalise their (possibly contradictory) demands and the move towards an agreement [14]. Many kinds of negotiations occur in a CSE project. For example, two concurrent developers modifying same software modules need to negotiate about how to schedule their work and merge their results. Negotiation agents can help people in this aspect and in similar situations. – Coordination agents: To support, for example, a project manager issuing a work-order that involves a group developers; or a higher-level manager being called in to mediate negotiation agents and reach an agreement; etc. – Mediation agents: In a complex, real-life domain such as CSE, negotiation and coordination are not easy to carry out purely by algorithms. Third part mediation is often necessary. Mediation agents help negotiating agents to reach an agreement. In doing so, mediation agents may consult the Experience Base (EB), cf. Section 3.4, act according to company policies or ask a project manager (human) for help to make decisions. Note that different interaction agents listed above are not on the same level. Coordination agents need some negotiation facility to do coordination, interaction agents need communication facility to interact, and mediation agents are on the highest level.
3.2 Workspaces (WS) A workspace is a place where human and software agents access files and tools. In addition, interaction between users and software agents takes place in workspaces. Workspaces can exist in various forms. The simplest form of a workspace can be a file-system provided with services to read files and write to files. A more advanced workspace can provide configuration management of files, view a subset of information found in a repository support, awareness services, web-support etc. BSCW [17] is one example of an advanced web-based workspace implementation. One important requirement for a workspace is that data is accessible in a format possible for tools and humans to interpret. A workspace can store all kinds of data which incorporate process data as well as process models. Agents can access data in the workspace either directly or indirectly through tools. It is also possible to have 8
private workspaces as well as shared workspaces. More advanced workspaces provide hierarchical levels of workspaces. The sharing of data is not only limited to humans, but are also shared among software agents.
3.3 Agoras An agora is a place where software agents meet and interact , but can also be a market place where agents “trade” information and services. From a software agent’s point of view, the main difference between a workspace and an agora is that in workspace provide support for interaction between agents and humans, while agora only provide support for interaction between software agents. Agoras are built on the underlying communication mechanisms, but provide agents with more intelligent means to facilitate their interaction. The main purpose of the agora is to facilitate cooperative support for applications and agents. We propose the following preliminary functionalities that any agora should support. More complex functions for communication, negotiation, etc. can be built on these basic communication blocks. 1. Inter-Agent Communication: Inter-Agent communication is not simple information-passing, it conveys intentions, goals, beliefs, and other mental states to form the foundation of negotiation and other complex interactions. An agora should make it possible for agents to announce their capabilities and make it possible to get in touch with agents capable of doing specific tasks. In this way, it is possible for agents to use other agents to solve a specific problem. The following services are needed to facilitate inter-agent communication: A:Decline A:Request B:Promise 1
2
B:Assert 3
A:Declare 4
5
B:Counter B:Reject A:Withdraw A:Counter
A:Accept
6 8
B:Renege
7
A:Reject B:Withdraw
A:Withdraw
A:Withdraw
9
Figure 2: An example of speech-act
An agora should provide a predefined set of speech-acts [24] (conversation types), such as proposal, counter-proposal, acceptance, rejection, confirm , deny, inform etc. The various speechacts types will define how agents can interact with each other. In many cases a speech-act is represented as a state transition diagram as the one shown in figure 2. The speech-acts act as shared process model for how agents should interact. Figure 2 shows states of a conversation between two agents A and B. States are shown as circles while transition between one state to 9
another is shown as arcs. The terminal state 5 indicate a successful conversation and the bold lines shows the path of a successful conversation.
An agora should specify the common syntax of the messages transmitted through the agora, so that the recipient can analyse the contents of a message.
An agora should specify the common semantic of agent language. One part of this semantic is defined through speech-acts by defining what transitions from one state to another state of a conversation a message will cause. There is also a need for defining the semantic of the agent language on a general level. This means that all software agents interpret the same words similar.
An agora should specify pragmatics for agents. This means that agents shall not lie to other agents and the agents intentions should be honest. 2. Inter-Agent Negotiation: As we mentioned before, the purpose of negotiation is to reach an agreement. The progress of negotiation depends mainly on the negotiation strategies employed by the negotiating agents, but agoras should provide mechanisms to minimise communication overheads, to help the negotiating agents in minimising their computation efforts. These mechanisms should support protocols based on a common syntax, semantics and pragmatics (as described above) and specify the standard unit of information to be exchanged. For example, the standard unit of message could be package that contains: The communication type, The sender, The list of recipients, The conversation strand, The service-name, The service-content written in the common syntax, and the information model which will be used to understand the semantics of the content. Agoras should adopt a negotiation model suitable to the domain of Cooperative Software Engineering. We have not gone into the details of the model design yet. Conceptually, the model should set the negotiation context (what is being negotiated for and the reason to negotiate over it), as well as a set of negotiation strategies from which the negotiating agent can select the suitable one for its purpose. We think that the above functionalities should be supported by agoras, so that the negotiating agents via an agora can call the proper functionalities (or methods, in terms of the OO paradigm).
3.4 Repositories In our architecture, a repository represents an information server that in the simplest form only provide services for storing and retrieving persistent data. A more advanced repository will provide services for data modelling and agents offering services for searching through data, comparing data, computing data etc. Repositories can be accessed either by tools or by agents.
10
Our architecture allows repositories to exist either locally directly related to a workspace, called local repository, or shared among several workspaces, called distributed repository. Local repositories are mostly accessed directly by tools running in the workspace, while distributed repositories are supported through agora and repository specific agents. Such agents can provide intelligent services for storing and retrieval of data to/from repositories. The most fundamental repository is the production repository storing versioned products. Other repositories may include process models, experiences, user-error-reports etc. The more advanced repository is the community memory across projects which can be realized by an Experience Base (EB). The idea is that for each (previous) project, its project/operative profile is recorded in the EB. All new projects are initiated with a specific own project/operative profile. The project manager uses it as the criteria to search the EB for previously completed projects that are similar to the current project. The best-matching candidate is then selected as the baseline project. With the baseline project as a guidance, the process quality of the new project could be improved in various ways [13], e.g., more accurate resource estimation, foresee problems that have occurred in similar projects, make the process more efficient by analysing similar previous projects etc. An EB will provide organisational learning, making it possible for an organisation to execute projects more efficiently and avoid making the same mistakes many times.
3.5 A OO Description of the Four Components As mentioned, we perceive different types for each of the four components in the architecture. Naturally, we adopt an Object-Oriented (OO) approach to describe them. A class serves as a template, an object is an instance of its class. In the class description, we will primarily use sub-classing and attribute-setting. There is a root class for each of the four components (agent, WS, agora and repository) in our architecture. For example, the root class for agent is GenAgent. Other classes are their subclasses, with the conventional inheritance rules. Figure 3 is the hierarchy of the classes of agents, WSs, repositories and agoras. The figure is a simplified view of the class hierarchy and does not e.g. reflect that WS and agoras have a lot of commonalities. Example notation of the NegoAgent class (Negotiation agent) is shown below: AgentClass NegoAgent : InteractAgent % list of superclasses {ATTRIBUTES: AgentId % agent’s id WSIds % agent works in workspaces (list) AgoraIds % agent is registered in agoras (list) Time % creation time ......... Parameters % control the goal-setting METHODS:
SetGoal() Offer() Enquire() EnterAgora() ExitAgora() .........
% % % % %
to to to to to
set its goal offer something to counterpart ask information register in an agora exit from an agora
11
Root
GenWS
GenAgent
System Agent
Interact Agent
Local Agent
Local
Monitor Agent
WS− Monitor
Reposit. Agent
Agora− Monitor
Plan Agent
Work Agent
GenAgora
GenReposit
Distri− buted
Durable
Temp.
Process Agent
Schedule Agent
Enact Agent
Resour. Alloc
Nego Agent
Coord Agent
Version Control
Merging Policy
Comm. Agent
Mediate Agent
Figure 3: The Class Hierarchy.
Heuristics Utility
% negotiation strategy %
}
For the properties (attributes and methods), simple inheritance rules apply: i.e. properties may be declared (added) locally, but superclass properties are used if they are not redeclared locally. We can similarly write other agent (sub)classes as well as classes of other components.
3.6 The CSE Multi-Agent Architecture Within our architecture, the four components are interconnected and interoperate as follows:
1. Agents are created by people to help them work; or by other agents to perform delegated work; or by default to manage workspaces or agoras. Examples: Work agents are created by software developers; Process agents are created by process engineers; Interaction agents are created by people or working agents when communication via agoras is required; Monitor agents are created by default for each workspace and each agora; and System agents are created by default for each agora. Note that agent creation is a process of instantiation of the corresponding agent classes. That is, agents are created from templates, typically by supplying few parameters. 2. Agents are grouped mainly according to people grouping. In CSE, usually we can perceive various groups of people working as a team. The mechanism we have used to group people and agents is the workspace mechanism. Shared workspaces are used to group teams of human and software agents 12
working together, while private workspaces provide support for one human and possibly several software agents. For people working in a shared workspace it is possible to have both private and shared software agents. The agents created by the team members, together with necessary interaction agents, bookkeeping agents, etc. constitute a agent group. 3. Interaction between agents is via agoras. Some system agents are created by default to manage the agora (creation, deletion, and bookkeeping). 4. Repositories can be shared or local to a group of agents. Shared repositories can be distributed. There are monitoring agents, created by default, to perceive the happenings in workspaces and agoras, collecting relevant data and storing the data into repositories. In this way, the community memory is built. And in decision making, or when some negotiation runs into difficulties, Mediation agents can help by utilising previous experience from some repository. 5. Within a group of agents and their shared workspace, any existing process models are allowed, and the traditional process architecture described in Section 2 can be applied. On the other hand, we can also apply this agent-based architecture recursively to a group of agents. That is, we can split the agent group into several (sub)groups, the shared workspaces into several (sub)workspaces, and make the communication among (sub)groups explicitly via agoras.
Figure 4 shows the four components of the architecture and their interconnection and interoperation. Note that in the figure there are different types of agents and repositories. In Section 5 we will see a concrete architecture when our approach is applied to a CSE scenario. WS1 Agent Group 1 Local Reposi− tory
Global Repository
Local Process Model
Legend
Ag
Local Agent Negotiation Agent Coordination Agent
WS2 Agent Group 2
Monitor Agent Mediate Agent
Local Process Model
WorkSpace
Agora Repository
Figure 4: Multi-Agent Architecture for Cooperative SE
13
4 An industrial scenario 4.1 Introduction This scenario is based on the software development and software maintenance process from a real Norwegian software company, in this paper called AcmeSoft. The company’s products exists on various operating system platforms including Microsoft Windows NT and various UNIX platforms. In this scenario we by software development mean the development of future releases and updates of products, whereas by software maintenance we refer to the correction of defects in released software. Common to these processes are a production and testing process which builds the products for requested platforms and the delivery process which creates the distribution media and ships products. An overview of the main activities in the process described in this scenario is shown is figure 5. The different groups responsible for the activities are listed below the activity name. Maintenance First line support Maintenance group Upd/Rel Plan group
Development Development group
Delivery Deliv/ship group
Production and testing Production/QA group
Figure 5: An overview of the software development and maintenance process
4.2 Development process The development process focuses on work that is directly related to changes of software products and the planning and scheduling of these changes. Three main process steps are important in this process, namely:
1. Release and update planning: Company AcmeSoft is committed to quarterly update releases and one major release per year per product through maintenance agreements with customers. 2. Scheduling (coordination with ongoing maintenance): The development department’s main activity is to develop new software. This activity is frequently interrupted by maintenance tasks. Because of limited resources, the different departments in the company have to negotiate about how much resources should be spent on updating and how much on development of new software. 3. Implementation: functionality Error correction and planned enhancement activities proceed until development team feels that source code development has been completed. Local tests will also be run on the code with required error correction.
14
4.3 Maintenance process The maintenance process is triggered by a maintenance report. There are three different types of related reports: Software Query Reports (SQRs): Error report or desired, Release Problem Reports (RPRs): Internal problem reports, Production orders: Requests from customers for a given product or product revision. The maintenance agreements define a priority system for SQRs and RPRs with five levels from Critical down to may not be implemented scaled from P0 to P5 respectively. Based on this classification, the correction phase of SQRs and RPRs is divided into the five following process steps: 1) Registration (with the development department), 2) Estimation of resources (which developer, amount of time), 3) Sendout (send SQR/RPR to developer), 4) Correction (actual problem fix done by developer), 5) Module testing (by developer).
4.4 Production and testing process This process starts after a freeze in development code, after defect corrections, and when customers request a delivery revision built for a specific platform. The process consists of the three following steps: 1) Production: The concerned modules of the product in question are rebuilt with the corrected release code, 2) Testing: Global system testing, 3) Verification: The test reports is submitted to verification performed by a member of the development team.
4.5 Delivery process The delivery process consists of activities to store products on distribution media and shipping products. This process is initiated when a product release or update is made available, and on customer demand. If the product is available for the requested platform, the delivery process is started right away, otherwise it will start after the platform is produced. The delivery process can be divided into two main activities: 1) Delivery (configuration of the delivery and to copy it to some storage medium) and 2) Shipping (practical task of forwarding the storage medium to the customer).
5 Application of the Architecture to the Scenario Figure 6 shows our multi-agent architecture for the scenario described in the previous section. In this architecture there are six agent groups (workspaces) corresponding to the six groups (First Line Support, Maintenance group, Update/Release Planning group, Development group, Production and QA
15
A1 Defect Report
Customer Report Order
P0: P1: P2: P3: P4:
1) WS First−Support Process
1 week 1 month next update 2a) WS next releaseMaintenance Planning new func.
Process
DB for
Ag1
classification forwarding
B Order for Existing DR
register estimate allocate
Conflict list
EB
Market/ Technology Requirements 2b) WS Update/Release Planning Process C Order for DR with New Platform
Defect Reports
A2
Ag2
D
Work Order
change order
3) WS Development Process
A4.1 Rejection Report
coding corection module test merging update per quater release per year
A3 New DR
5) WS Delivery and Shipping Process
A4.2 Accepted Update / Release
4) WS Production and QA Process Global test verification
Make Executable Copy Forwarding
Figure 6: Scenario of Software Maintenance and Development group, Delivery and Shipping group) of the organisation mentioned in Section 4.2. Each group has their shared workspace. Each group has also its own process model, which may be an existing legacy one, and the process models of different groups can be heterogeneous. Furthermore, some groups may have this new agent-based architecture recursively. That is, an agent group may be spilt into several (sub)groups, the shared workspaces into several (sub)workspaces. In all cases, the inter-(sub)groups communication is modelled explicitly via agoras. In the architecture, we can observe different kinds of interaction agents belonging to various groups. Examples are:
Two negotiation agents, one belonging to the First-Support group, the other to the Maintenance Planning group, communicate via the agora Ag1. Because when the First-Support Office conveys user’s request for a change and the desired deadline for the new revision, the Maintenance Planning Office may or may not authorise the changes (according to their configuration control policy). Even if the planning office agrees to authorise the changes, the deadline may needed to negotiated. In other words, the Defect Priorities (P0–P4) shown in the figure are the result of negotiation, rather than a simple information passing.
Two negotiation agents (one belonging to the Update/Release Planning group, the other to the Maintenance Planning group) communicate via the agora Ag2. See below for detailed discussion. 16
Some coordination agents are observed in between the Maintenance Planning Office (or the Update/Release Planning Office) and the Development Team. This means that the change-order or workorder are given to a group of developers (rather than a singular person). So the Planning Offices need to coordinate the development work (such as work partitioning). The change-order or work-order will actual cause changes to the local process models. In this perspective we can see the coordination of a change order or work order as a process model change.
Other negotiation and/or coordination agents could be observed in the figure, but for simplicity we just show them as simple communication agents. AcmeSoft has a distributed repository used as a EB of the company. The EB holds information about previously completed projects and products and previous updates/releases of the current products, such as: the project profiles, evolution patterns, performance metrics, and process models. The EB can be utilised in various ways, e.g. the Mediator agent can draw previous experiences from the EB in mediating difficult negotiations (see below for a more detailed discussion). This means that we also need Monitor agents to keep track of the happenings in workspaces and agoras to collect and analyse data, and to store them into the EB. The local repository is a database to achieve the user’s defect reports. This is what actually going on in the company AcmeSoft. In fact, better strategy can be perceived. The repository should be distributed to shared repositories, accessible to all the groups, storing user’s reports together with the corresponding changeorders, revisions or updates or releases which corrects the reported defects. Thus, these shared repositories will be a special kind of EB. It is possible to tailor repositories to take care of specific need and populate these repositories with useful agents that are also connected to an agora. Another way of implementing this support is to provide one global repository for all experiences in the company. To get better performance, availability and ownership of repository a global repository is not a good idea. Let’s have a closer look at the agora Ag2. There are various inter-agent activities occurring in or transmitted through it. In the following, we explain in details some of these activities:
1. Negotiation and coordination between the Update/Release Planning Group (URPG) and the Maintenance Planning group (MPG). First, remember that the main task of URPG is to plan the next update (quarterly) and the next release (yearly) of the company’s products. In doing so, URPG should make decisions on issues such as what defects should be fixed and what new functionalities should be included in the next update/release. Naturally, market and technology analysis contributes a lot as the basis of this decision-making, but the feedback from the existing users is also very important. The relevant information is presented in users’ defect reports with the priority P2–P4, which is received, analysed, and stored by MPG. Based on this information, MPG would give requests, suggestions or advice to URPG about the contents of 17
the next update/release. On the other hand, URPG may accept, reject, or negotiate on these proposals. All these inter-agent activities are carried out through the agora M2. Secondly, remember that a same development team is responsible for both maintaining the existing products and developing the new update/release. Suppose that MPG is giving a change order to a person in the Development Team, while URPG is giving a work order to the same person. Here we have a conflict in resource allocation. To solve the conflict, negotiation is necessary. In all cases, the negation- and coordination agents (equipped with negotiation strategies for different kinds of negotiation, e.g. resource negotiation, contract negotiation etc.) carry out the inter-group interaction on behalf of the involved groups. On the other hand, the agora Ag2 should provide InterAgent Communication facilities (the physical communication infrastructure, plus protocols for communication types, syntax and semantics of messages), and Inter-Agent Negotiation facilities to minimise communication overheads, etc. 2. Mediation in the negotiation between URPG and MPG. For instance, in solving the resource allocation conflict, MPG and URPG may not be able to reach an agreement. MPG would like to have person A to fixed up an error in a product for a user B which demands the fixation urgently, because A was the original responsible programmer of the module in question. On the other hand, URPG would like to have A as the chief programmer for a planned update/release. URPG argues that serious delay of the new update/release could result if A is interrupted in his/her current work. The problem is that each of negotiating agents views the issue only from its own angle, based on its local experience. Furthermore, in such a real-life domain, it is hard to think algorithm-based negotiation strategies alone can always solve the problems reasonably. Human intervention by a manager of the company may be necessary. How much human intervention the agent will need is dependent of the definition of the agent. In this way it is possible to tailor the agent for the needs of the company. It should be possible to state for instance that resource negotiation for more than a certain amount of money must be done through human interventions. The mediate agent works on behalf of the higher-level manager, to propose a solution which serves best the overall purposes of the company AcmeSoft. In doing so, the mediate agent may utilise the previous experiences by searching the EB. For example, if a record in the EB shows that user B has been an important customer of the company that last year was angry over delayed bug-fixation and thus considered switching to a similar product of a competing company, the mediate agent may stand by MPG and persuade URPG to consider another developer as the chief programming of the next update/release.
18
6 Conclusions and Future Work In this paper, we have introduced an agent-based architecture to solve Cooperative Software Engineering problems. This architecture consists of four main components, namely Agents, WorkSpaces, Repositories and Agoras. The agents provide a flexible and dynamic approach for giving the users support for cooperating with other users as well as help for doing every-day work. The main advantage of using agents to support this kind of processes is that agents can respond to a changing environment (learn, adopt based on experiences in the ExperienceBase etc.). In software processes, it is widely accepted that the software processes evolve over time. It is thus, important that process support can adopt and cope with these changes. To make agents able to cope with process changes, they will need to learn from prior experiences. In our architecture this is introduced through repositories offering experience functionality as well as agents can learn on their own. Repositories offer knowledge to the agents about company policies and general context information that can make it easier to make decisions about how to interact with other agents etc. The agora has been introduced into our architecture to be able to explicitly model and support the place agents meets and interact. Our architecture also provide support for tailoring agoras for various purposes as e.g., long-term agoras, temporary agoras (dynamically), inter-company agoras, open-internet agoras etc. In a broader sense, agoras make it possible for people do cooperative work beyond local group, company and geographical borders. Agoras will help us to deal with heterogeneous environment consisting of heterogeneous process models and provide a dynamic and flexible way of reconfiguring these models. In this paper, our architecture has been applied on only one specific scenario. We believe, however, that our multi-agent CSE architecture can be applied to support various situations, processes and organisations. One concrete example of usage for this architecture is to support meta-process activities like discovering/planning process models, negotiation about the process model and the real world model and assignment of resources to a process model. These are examples of processes where negotiation and uncertainties are the most dominant properties and where our architecture can give active support. Our architecture’s main contribution is to give process support where traditional SPTs fail in respect to dynamic behaviour and flexible process support. Further work with implementation of prototypes and experiment with industrial scenarios will show if this is the case.
7 Acknowledgement The authors of this paper want to first of all to thank the CAGIS 3 group for encouraging us with ideas and suggestions to our work. We especially want to thank Mihhail Matskin, Sobah Abbas Petersen, Monica Divitini, Heri Ramampiaro for suggestions and discussions regarding the paper and a big thank to Torgeir Dingsøyr and Joar Øyen for reading through and giving comments on the paper. 3 CAGIS is short for Cooperative Agents in Global Information Space. More information about the CAGIS project can be found at: http://www.idi.ntnu.no/˜cagis.
19
References [1] Reidar Conradi Alf Inge Wang, Jens-Otto Larsen and Bjørn Munch. Improving cooperation support in the epos cm system. In The sixth European Workshop in Software Process Technology, Weybridge, London, UK, 16–17 September 1998. [2] Alexandros G. Moukas Anthony Chavez and Pattie Maes. Challenger: A multiagent system for distributed resource allocation. In Proceedings of the International Conference on Autonomous Agents, Marina Del Ray, California, USA, 1997. [3] Israel Ben-Shaul and Gail E. Kaiser. A Paradigm for Decentralized Process Modeling. Kluwer Academic Publishers, Boston/Dordrecht/London, 1st edition, 1995. [4] Anthony Chavez and Pattie Maes. Kasbah: An agent marketplace for buying and selling goods. In Proceedings of the First InternationalConference on the Practical Application of Intelligent Agents and Multi-Agent Technology, London, UK, April 1996. [5] Hans v.Kleist-Retzow Ernst Lutz and Karl Hoernig. MAFIA - An Active Mail-Filter-Agent for an Intelligent Document Processing Support. In S. Gibbs and A.A. Verrijn-Stuart, editors, IFIP, North-Holland, 1990. Elsevier Science Publishers B.V. [6] J. Grudin. Computer-Supported Cooperative Work: History and Focus. In IEEE Computer, number 5 in 27, pages 19–26, 1994. [7] Robert P. Hanrahan. The idef process modeling methodology. CrossTalk - The Journal of Defence Software Engineering, 8(6), June 1995. Software Technology Support Center, http://stsc.hill.af.mil/CrossTalk/1995/jun/IDEF.html. [8] Gail E. Kaiser Israel Ben-Shaul. A paradigm for decentralized process modeling. Kluwer Academic Publishers, Boston/Dordrecht/London, 1995. [9] M.L. Jaccheri. Reusing Software Process Models in
E 3 . In The Tenth International Software Process Workshop, 6, 1996.
[10] C. Liu and R. Conradi. Process View of CSCW. In Proc. of ISFST98, Ocon Technology Application, page 12 p, Bremen, Germany, 15-17 September 1998. International Workshop on Intelligent Agents in Information and Process Management. [11] M. Divitini M. Matskin and S. Petersen. An Architecture for Multi-Agent Support in a Distributed Information Technology Application. In International Workshop on Intelligent Agents in Information and Process Management, page 12 p, Bremen, Germany, 15-17 September 1998. [12] Washington Microsoft Corporation,Redmond. Microsoftdcom: A technical overview. web: http://www.eu.microsoft.com/windows/downloads/bin/nts/DCOMtec.exe, 1996. [13] Alf Inge Wang Minh Nguyen and Reidar Conradi. Total software process model evolution in epos. In Proceesings ICSE’97, Boston, USA, May 1997. [14] H. J. Muller. Negotiation principles. In Foundations of Distributed Artificial Intelligence, pages 211–230. Wiley Interscience, 1996. [15] OMG. Corba components: Join initial submission. ftp: ftp://ftp.omg.org/pub/docs/orbos/97-11-24.pdf, 1997. [16] W.J. Orlikowski. Learning from Notes: Organizational Issues in Groupware Implementation. In Proceedings of the Conference on ComputerSupported Cooperative Work, CSCW’92, pages 362–369, Toronto, Canada, 1992. The Association for Computer Machinery, ACM Press. [17] T. Horstman R. Bentley and J. Trevor. The World Wide Web as enabling technology for CSCW: The case of BSCW. Computer Supported Cooperative Work: The Journal of Collaborative Computing, 7:21, 1997. [18] Chunnian Liu Reidar Conradi and M.Letizia Jaccheri. Process modeling paradigms: An evaluation. Technical report, 7th Int’l Software Process Workshop (ISPW7), Yountville, Ca, USA, 1991. [19] Cristina Mazzi Reidar Conradi, Letizia Jaccheri. Design, use and implementation of spell, a language for software process modeling and evolution. Technical report, European Workshop on Software Process Technology (EWSPT’92), 1992. [20] Jens-Otto Larsen Reidar Conradi, Marianne Hagaseth and Minh Nguyen. Object-oriented and cooperative process modeling in epos. Technical report, PROMOTER Book 1994, ed. Bashard A. Nuseibeh, Imperial College, 1994. [21] Marianne Hagaseth Reidar Conradi and Chunnian Liu. Planning Support for Cooperating Transactions in EPOS. In Proc. CAISE’94, pages 2–13, Utrecht, June 1994. [22] Per H. Westby Reidar Conradi, Espen Osjord and Chunnian Liu. Initial Software Process Management in EPOS. Software Engineering Journal (Special Issue on Software process and its support), 6(5):275–284, September 1991. [23] J. Estublier S. Dami and M. Amiour. APEL: A Graphical Yet Executable Formalism for Process Modeling. In Process Technology edited by E. Nitto and Alfonso Fuggetta, pages 61–96, Politecnico di Milano and CEFRIEL, 1998. Kluwer Academic Publishers. [24] T. Winograd and F.Flores. Understanding Computers and Cognition; A New Foundation for Design. In Ablex, 1986. [25] William Silverman Yaron Goldberg, Marilyn Safran and Ehud Shapiro. Active Mail: A Framework for Integrated Groupware Applications. In D. Coleman, editor, Groupware ’92, pages 222–224. Morgan Kaufmann Publishers, 1992.
20
