2005 ACM Symposium on Applied Computing
Applying Agent Technology to Software Process Modeling and Process-Centered Software Engineering Environment Xinpei Zhao
Keith Chan
Mingshu Li
Internet Software Technology Lab Institute of Software, Chinese Academy of Sciences, Beijing, P.R.China. 100080 86-10-82620803
Department of Computing The Hong Kong Polytechnic University, Hung Hom, Kowloon, Hong Kong 852-27667265
Internet Software Technology Lab Institute of Software, Chinese Academy of Sciences, Beijing, P.R.China. 100080 86-10-62635241
[email protected]
[email protected]
[email protected]
ABSTRACT
never really been realized on a significant scale.
The software processes can be analyzed, designed, and maintained as if it is a piece of software. This view enables the application of software engineering technologies to software process modeling (SPM) and process-centered software engineering environment (PSEE). One reason for the relatively few applications of SPMs and PSEEs technologies in the software industry is that traditional software engineering technologies applied to the SPMs and PSEEs are not suitable for modeling software processes which are human-centered. This paper proposes an approach for applying agent technology, which has been accepted as a novel software engineering paradigm, to SPM and PSEE. In this approach, software processes are viewed as the collaboration of a group of process agents that know how to manage the software development activities and can act in the way software developers go about planning, enacting and reflecting on their work. An agent-based PSEE for enacting software processes under the proposed approach is also given in this paper.
According to Osterweil [3], software processes can be analyzed, designed, and maintained as if it is a piece of software. This view enables the application of software engineering technologies to SPMs and PSEEs. One reason for the relatively few applications of SPMs and PSEEs technologies in the software industry is that traditional software engineering technologies applied to the SPMs and PSEEs are not suitable for modeling software processes [4, 5]. The emphasis of most existing software process modeling languages (PMLs) and PSEEs has been on describing process models as normative models containing pre-defined activity sequences that are enforced automatically. But since software processes are human-centered requiring interaction and cooperation, some degrees of flexibility are required to facilitate creativity as well as the management of changing requirements, technologies, or work environment. In recent years, agent-based computing has been increasingly accepted as a software engineering paradigm [6]. Agent-based computing promotes design and development of software in terms of autonomous software entities called agents that can achieve their goals flexibly by interacting with one another in high-level protocols and languages. These features are useful for the modeling of software processes in a few ways: i) the autonomy of the agents reflects the intrinsically decentralized nature of software development [7]; ii) the flexible ways in which agents operate and interact with each other and with the environment make modeling of its behavior in dynamic and unpredictable environment easier; iii) the concept of agency provides for a unified view of successful AI research and it enables software agents to act in the way human beings go about planning, enacting and reflecting on their work. Given these unique features, we propose in this paper an approach for applying agent technologies to SPMs and PSEEs. Based on it, software processes are viewed as the collaboration of a group of process agents that know how to manage the software development activities. An agent-based PSEE for enacting software processes under the proposed approach is also given in this paper.
Keywords Software process technology, software process modeling, processcentered software engineering environment, agent.
1. INTRODUCTION In response to the increasing size and complexity of software projects, software developers and companies have paid more attention to software process management and improvement. According to the famous CMM model [1], if a software company wants to improve its capability and reach maturity level 3-5, its software process must be defined, managed and finally optimized. Software process modeling (SPM) and process-centered software engineering environment (PSEE) provide tools for software companies to design, specify, enact, analyze and evolve their software process. Although many modeling approaches and PSEEs have been proposed since 1990’s [2], they have not been widely adopted commercially. The anticipated benefits have
2. RELATED WORK
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’05, March 13-17, 2005, Santa Fe, New Mexico, USA. Copyright 2005 ACM 1-58113-964-0/05/0003…$5.00.
Although applying agent technology to SPMs and PSEEs has not been widely used for software processes, such attempts have become increasingly popular in the area of workflow management, which is concerned with the modeling and automation of business processes [8-11]. Such attempts have been made under either the agent-enhanced approaches or the agent-based approaches.
1529
Agent-enhanced approaches concentrate on applying agent techniques to an existing process model, e.g. [8, 9]. The formalism used for modeling business processes remains traditional. However, management issues such as instantiation and cooperation are implemented by software agents. Agent-enhanced approaches concentrate mostly on supporting the cooperation between different workflow systems and have little concern over handling process changes.
techniques that are used to specify the process agents. The software process ontology in this layer provides the basic concepts (such as the document, activity and resource) as well as the meta-language that is used to describe the knowledge relevant to software development. Based on the software process ontology, a modeling language is developed to provide a formal notational system for specifying the process agents that are involved in the software development.
Agent-based approaches view business processes as a group of software agents and attempt to create an agent-based workflow model in order to implement service integration and distributed task arrangement. In [10], Zeng proposed an agent-based workflow management system, which utilizes three types of agents: (i) process agents which implement task arrangement and distributed cooperation; (ii) service agents which enable task implementation; and (iii) monitor agents which track task performance. Through collaboration of these different types of agents, Zeng’s system can implement dynamic workflow control and service integration in a distributed manner. In [11], Guo proposed an agent-based virtual enterprise model. Besides activity agents which control task arrangement, Guo introduces resources agents to control resource assignment. The collaboration of the activity agents and resource agents allows distributed control over an entire business process execution of a virtual enterprise. These approaches provide a pure agent-based solution, in the sense that they are implemented using software agents only. It brings with them adaptive features as well as process collaboration supports. The major problem of existing agent-based approaches is that they concentrate only on modeling general business processes. Since our concern is with applying agent technology to a specific domain, i.e., software process modeling, many issues, such as role assignment, scheduling and rescheduling, and budgeting, etc., need to be further considered.
Process Enactment: This layer is concerned with techniques that enable transformation from a software process model to its software process instances given within a certain software process environment. The kernel of this layer is an agent-based PSEE system. In this system, a software process model can be loaded and its process agents can be automatically instantiated. The process agent instances can cooperate with each other and generate software process instances to achieve certain given goals under some constraints. When the process environment changes, the process agents can automatically modify a software process to adapt to new conditions. Process Application: Through providing user interfaces, software engineers can interact with the PSEE system, perform and submit assigned tasks, manage workspaces, and track process performance. In the following sections we will introduce techniques that support these three layers.
4. PROCESS MODELING In our approach, a software process model is described as a set of process agent specifications, which we call process agent profiles. Figure 2 shows the elements that make up such a profile. Process Agent Profile consists of
3. THE ASPM FRAMEWORK
Process Artifact Specification
For an overview of our agent-based approach, we propose an ASPM framework (see figure 1). The ASPM framework consists of three layers:
may refer to
Process Application Declaration consists of
Process Participant Specification may refer to
Organisational Model
Client Client
Client
Figure 2. The elements of a process agent profile.
Process Enactment
Process Modeling
Process Activity Specificaion
may refer to
may refer to
Process Application
Agent instance
may refer Process Knowledge be bound to to Specificaion
Process Knowledge Specification (PKS): The PKS describes the actions a process agent can perform. It refers to a set of step specifications. A step is specified using the following elements: (i) a name which is a unique character string that identifies the step, (ii) a description which is a literal description of the step, (iii) a specification which define the input and output of the step, (iv) a set of triggers which describe the events that can invoke this step, (v) a set of preconditions which are premises that must be true before the step may be carried out, (vi) a set of invariants which are conditions that must be true throughout the lifecycle of an instance of this step, e.g. an invariant of a design-review step is the reviewed design document which must remain unchanged, (vii) a set of postconditions which are conditions that must be true when the step is completed, and (viii) a set of actions which are execution instructions (normally non-sequential) that declaratively describe operations to be carried out in order to
Agent-based PSEE
Agent-based software process model Process agent specifiation
Modeling language
Basic concept
Meta-language
Software process ontology
Figure 1. The ASPM framework. Process Modeling: In our approach, software process is modeled as a group of autonomous and collaborative agents, which represent organizational entities that actually perform software development, e.g. specific engineers, development teams and software organizations. The process modeling layer contains
1530
complete this step. Preconditions, invariants, and post-conditions are described as modal logic expressions [12].
Site 1
Process Server agent
Process Activity Specification (PAS): In our approach, step and activity are regarded as different concepts. A process step is a knowledge level abstraction of how the process agent controls its actions, while the activity describes the actual actions a process agent can perform. PAS can be viewed as a template for instantiating a process activity. It contains detailed information for implementing a process activity such as resources required, instructions, documents, priority, and access restrictions etc.
Site 2
Process Server agent
agent
agent agent
agent
A ccess broker local access
C lient
C lient
agent
A ccess broker rem ote access
C lient
C lient
C lient
Figure 4. Decentralized architecture of the ISPMS.
Process Participant Specification (PPS): A process agent is typically a representative of certain organizational entity. PPS specifies the organizational entities the process agent represents. It can also have a reference to an external organizational model, which describes the organizational relations between the process agents.
In the ISPMS architecture, there is a process server residing in every development site where support for the execution and communication of process agent instances are provided. Process agent instantiation: Each process agent instance is implemented as a thread. The process agent instance is characterized by its profile. For every process agent instance, it has a knowledge base to store the information extracted from the profile.
Process Artifacts Specification (PATS): Artifacts are software products (e.g. design document, source codes and test cases), which are used by the process agent. PATS defines the process artifacts as object and thus specifies attributes of and the interrelationships among the artifacts.
Communication support: The process server provides APIs for the process agent instances to enable reliable communications. These APIs hide the implementation details of communication issues such as agent finding and locating, message routing and communication security, etc. Supported by the process server, process agent instance can communicate with each other as if they reside in a virtual organization.
Process Application Declaration (PAD): Software tools and services are used by the process agents to facilitate their work. PAD specifies the interfaces that are used to invoke these tools and services. In order to support the building of the process agent profiles, we developed a language called ISPML (Intelligent Software Process Modeling Language), which is based on the Extendible Markup Language (XML) [13]. Conforming to the structure of process agent profile, a process agent description consists of several XML documents, each of which defines an agent profile element. Figure 3 shows a segment of a PKS document. It describes the process knowledge of a process agent which can carry out design activities for web pages.
Work space management: Every process agent instance has a private work space to store process artifacts it uses or produces. These work spaces are managed by the process server. In ISPMS, we integrate a CVS with each process server. Each work space is implemented as a specific working directory of the CVS. Process server provides APIs for the process agent instance in initializing and accessing the CVS working directory
5.1 Process Agent Instance
Assigned schema
In the ISPMS, all the process agent instances share a common architecture, as shown in figure 5.
Design a web page according to a given customer requirement Make use case according to a given customer requirement MAKE_USECASE(cr:CUSTOMER_REQUIREMENT)->(uc: USECASE) recieve(CUSTOMER_REQUIREMENT) CustomerRequirement(cr) !Changed(uc) UseCase(uc) Discuss requirement specification with customer. Make usecase. ... Step definition
User Interface application invocation
output
new process knowledge Knowledge Base
Reasoning Engine perceptions
Work Space
Application Server Process Application
invoke
reasoning result
Enactment Engine
Perception Generator Resources
Figure 3. A PKS segment. The syntax of the ISPML is defined as XML schemas [14]. Supported by XML editors which have schema facilities, e.g., Altova XMLSPY®, the XML schemas can be used to perform syntax checking and to accelerate the creation of the process agent profiles. For a complete ISPML definition and a description of relevant XML schemas the reader is referred to [15].
Process Activity
Underlying Communication Service
Figure 5. The architecture of a process agent. Basic components of a process agent instance include a perception generator, a reasoning engine, an enactment engine and an application server. When a process agent has been initiated, it begins to monitor the environment and voluntarily generate perceptions using its perception generator. Based on these perceptions and its process knowledge, a process agent can decide which action is to be carried out by performing two types of reasoning: bottom-up reasoning and top-down reasoning. Bottomup reasoning is reasoning from the current conditions to the goals. By performing bottom-up reasoning, a process agent instance can
5. PROCESS ENACTMENT Using the ISPML, a user can model the software process in terms of a set of process agent profiles. The process models can be enacted through an agent-based PSEE named ISPMS (Intelligent Software Process Management System). The ISPMS is constructed using a decentralized architecture, see figure 4.
1531
agent, which believes it can achieve this goal, joins the Net first. This process agent may generate a local plan and identify some of the steps of its process that need cooperation with others. This process agent then calls for help by announcing new goals. The process agents that decide to participate in achieving these new goals will bid for the goals. The process agent who announces the goals will then choose appropriate bidding process agents and add them as its underlings. These underlings may also decompose their tasks and generate sub-goals to invite other process agent to join the management net. The Management Net is thus formed recursively.
determine whether a step is executable under current conditions (figure 6). public StepSet bottomupReasoning(String[] es, String[] goals) throws ReasoningEngineException { if (es implies goals) { return null }; StepSet executableSteps = new StepSet(); for (each step s in the knowledge base) { if (es implies step.preconditions) { executableSteps.add(s); } } if (executableSteps.isEmpty()) { throw new ReasoningEngineException("No step can be executed"); } else { return executableSteps; } }
Manager Agent
Figure 6. The bottom-up reasoning.
local plan
Management Net
Top-down reasoning is used to implement proactive behaviors of a process agent instance, e.g. planning. Through top-down reasoning, a process agent instance add to its plan a set of steps whose post-conditions fulfill the requirement of the goal and then plan for the preconditions of that set of steps as new goals (figure 7). Top-down and bottom-up reasoning are implemented by the reasoning engine.
announce Sub-goal
announce manage
Sub-goal
manage
achieved by
achieved by
Underling Agent
public StepSet topdownReasoning(String[] goals, String[] es) throws ReasoningEngineException{ if (es implies goals) {return null;} StepSet plannedSteps = new StepSet(); for(each step set sts in P(steps) ) { //P(steps) is the power set of the steps in knowledge base if (postconditions(sts) implies goals) { plannedSteps.addStepSet(sts);} } if (plannedSteps.isEmpty()) { throw new ReasoningEngineException("Goals cannot be achieved"); } else {return plannedSteps;} }
Underling Agent
Figure 8. The management net. After the Management Net has been established, process execution begins. The execution of a process is guided by this organization of process agents and the plan that is developed at the planning phase. During execution, the manager agents will track their underlings and control changes. Process artifacts are gathered and assembled by the manager agents and then passed upwards in the agent hierarchy.
Figure 7. The top-down reasoning.
The topology of the Management Net is dynamic. It may change if the decisions of the process agent change. For example, a manager agent may change its plan if its goals change, and may consequently withdraw or change the sub-goals it has posted. These changes may cause the changes in the Management Net.
Decision processes based on bottom-up reasoning and top-down reasoning are performed at the knowledge level, i.e. based on steps. These steps can be further implemented through binding with activity templates that are described by the PAS. When an activity is bound to a step, resources required by that activity are also assigned. The decision processes are carried out by the enactment engine of the process agent instance. The enactment engine acts as the brain of a process agent. It controls the behavior of a process agent such as decision-making, planning, tracking, changing, performance measurement and ability improvement.
Cooperation of the process agents is implemented by the Management Net Protocol which has its root in the well-known Contract Net Protocol (CNP) [16]. In order to support software process cooperation, we extend the traditional CNP to support distributed task arrangement, process tracking, process changing, process measurement, and process improvement.
The specification of an activity may include descriptions of tools that should be invoked by this activity. In this case, the process agent instance may find in its knowledge base the relevant PAD and uses the PAD as interface in invoking the described tools. Tool invocation is implemented by the application server.
6. PROCESS APPLICATION In the ISPMS, when a development goal is assigned, the process agent instances may automatically form a management net and generate a collaborative plan for achieving that goal. By planning, tasks are assigned to the relevant process agent instances. Users can access his/her relevant process agent instance, fetch the assigned tasks, check in or check out process artifacts from the workspace of that process agent instance, and thus complete the assigned tasks. Process agent instance may track the process through checking the performance of the submitted task and its workspace. If the performance deviates from the plan, the process agent instance may make changes to the current process so as to ensure the development goal can still be achieved.
5.2 Process Agent Cooperation To enable cooperation, an organization called a Management Net is formed for the process agents. The topology of the Management Net is represented by a directed acyclic graph (DAG). Each node of the DAG represents a process agent. The directed arcs represent the management relationship: a process agent (the underling agent) linked to the head of the arc is managed by another process agent (the manager agent) linked to the tail of the arc, see figure 8. The Management Net is established when goals are assigned to the process agents and then disassembled when the goals have been achieved. At the beginning, process agents are scattered in the process servers. When a goal is assigned, a particular process
The ISPMS provides client for the users to access the process agent instance. Figure 9 shows the GUI of the ISPMS client.
1532
The list of process agents which are residing in the process environment and are consisting of the management net
The agent panel is used to visualize and control the existing process agent and the management net.
8. REFERENCES
This view shows the announced goals
[1] Paulk, M. C., Curtis, B., Chrissis, M. B., and Weber, C. V., Capability Maturity ModelSM for Software, Ver1.1, Technical Report CMU/SEI-93-TR-024, SEI CMU, 1993. [2] Barthelmess, P., Collaboration and Coordination in ProcessCentered Software Development Environments: A Review of the Literature, Information and Software Technology, 45(13), 2003, 911-928.
This view shows the perceptions of a selected process agent
This view shows the project plan and Task list of the the tracking information of a selected selected agent process agent by means of gantt chart.
[3] Osterweil, L. J., Software Processes are Software Too. In Proc. of ICSE’87, ACM Press, 1987, 2-13. [4] Conradi, R., Fugetta, A., and Jaccheri, M. L., Six Theses on Software Process Research. In: Proceedings of EWSPT98, Springer Verlag, LNCS 1487, 1998, 100–104.
This view shows runtime status and messages of a selected process agent This view shows the process instance of a selected agent.
[5] Cugola, G., and Ghezzi, C., Software Processes: A Retrospective and A Path to the Future, Software Process: Improvement and Practice, 4(3), 1998, 101–123.
Figure 9. the GUI of the ISPMS client. Using the ISPMS client, user should first complete a login operation. Through this operation the ISPMS client generates a user profile and registered it to the access broker. User profile is used for authority control. The authorized user can access and operate on the workspace of a process agent instance or complete and submit relevant tasks, see figure 10. General descriptions of the selected task
[6] Zambonelli, F., and Omicini, A., Challenges and Research Directions in Agent-Oriented Software Engineering, In: Autonomous Agents and Multi-Agent Systems, 9(3), 2004, 253-283. [7] Ben-Shaul, I., and Kaiser, G., A Paradigm for Decentralized Process Modeling and Its Realization in the Oz Environment, In: Proc. of ICSE’94, ACM Press, 1994, 179-188.
For each assigned task, the authorized user can use the ISPMS client to view the task descriptions and complete the task by submitting execution information and required products.
[8] Shepherdson, J. W., Thompson, S. G., and Odgers, B. R., Cross Organizational Workflow Coordination by Software Agents. In Proceedings of WACC’99, 1999. [9] Wang, A. I., A Process Centered Environment for Cooperative Software Engineering, In Proc.of SEKE’02, ACM Press, 2002, 457-468. [10] Zeng, L., Ngu, A., and Benatallah, B., An Agent-Based Approach for Supporting Cross-Enterprise Workflows, In: Proc .of Australiasian Database Conference, Gold Coast, Queensland, Australia, 2001, 123-130.
Expandable sections to specify the detail of a task
User can press this submit button to submit task execution information to the process agent
[11] Gou, H., Huang, B., Liu, W., Li, Y., and Ren, S., AgentBased Virtual Enterprise Modeling and Operation Control, In Proc. of IEEE International Conference on Systems, Man, and Cybernetics, IEEE Press 2001,1053-1057.
User can specify the real performance of the task by entering execution information in these editable field and submit it to the process agent.
[12] Chellas, B. F., Modal Logic. An Introduction Cambridge University Press, New York, 1980.
Figure 10. View and submit tasks using the ISPMS client.
7. CONCLUSION This paper proposes an approach for applying agent technology to software process modeling and PSEE. In this approach, the software processes are viewed as the collaboration of a group of process agents, which have knowledge of how to manage the software development activities. For enacting the software process models, we develop an agent-based PSEE – the ISPMS. By enacting the agent-based software process model, the ISPMS can automatically generate plans adaptive to the environment and goals, inform users what should be done, track the performance of the process, and make changes to the process when deviation is detected. ISPMS has been implemented and used in some real software projects. Users agreed that the ISPMS helps in increasing the efficiency and effectiveness of project management. Because of the limitation of the paper length, experience of using ISPMS is provided separately in [17].
1533
[13] W3C, Extensible Markup Language (XML) version 1.1, http://www.w3.org/TR/2004/REC-xml11-20040204/, 2004. [14] W3C, XML Schema http://www.w3.org/TR/xmlschema-0/, 2001. [15] Zhao, X., The Intelligent Software Process Management System: Intelligent Software Process Modeling Language Definition ver1.1, Technical Report (TR03-11), The Hong Kong Polytechnic University, Hong Kong, 2004. [16] Smith, R. G., The Contract-Net Protocol: High-Level Communication and Control in a Distributed Problem Solver, IEEE Trans. Computers, C-29, 12, 1980, 1104-1113. [17] Zhao, X., Modeling Modeling Software Process as Adaptive and Collaborative Agents, Technical Report (TR03-12), The Hong Kong Polytechnic University, Hong Kong, 2004.
