Development of an Intelligent Agent-Based GQM Software ...

Proceedings of ATS 2003

188

Development of an Intelligent Agent-Based GQM Software Measurement System Tong Chen, Behrouz Homayoun Far, Yingxu Wang Department of Electrical and Computer Engineering University of Calgary 2500 University Drive, NW, Calgary, Alberta, Canada T2N 1N4 Email: {chento, far, [email protected]}

Abstract Software measurement plays a key role in quantitative software engineering. Effective implementation of a measurement system to map collected data to business goals in a software organization is a prime problem. Goal-Question-Metrics (GQM) measurement provides the guidelines. A number of techniques to implement the GQM process have already been proposed. Nevertheless, the GQM process is complex, knowledge-intensive, iterative and therefore expensive. A tool to automate the process will be quite helpful. This paper introduces a multi-agent system called ISMS, which is designed for providing intelligent aid for software measurement based on GQM technique. The objective of developing this intelligent system is to automate the GQM process by building an agentbased system that accepts at its input a user’s business goal, asks questions interactively and after a few iterations produces a software measurement plan at its output. This multiagent system is composed of two clusters of agents, client-side assistant agents and server-side cooperative agents. The client-side agents work as intelligent front-end for the users and the server-side agents work cooperatively to realize various roles necessary to implement the GQM process.

Key words: Software measurement, GQM, goal-driven process, multi-agent system.

1. Introduction Software measurement plays an important role in quantitative software engineering. As a mapping from a set of entities in the software engineering world to a set of entities in the mathematical world, software measurement provides technique and methodology to measure software for achieving predefined technical or business goals, help us understand and improve the development and maintenance process, allow us to control the projects, and encourage us to improve the development process and product [1, 3, 7]. Nevertheless, there exist some drawbacks in software measurement practice. How to implement measurement effectively in a software organization is a prime practitioners’ concern. It is important to be aware that measurement is means, but not goal. It is


189

unmeaningful that just measure for measurement. Software measurement would be useful only when it services for some particular goals and matches them. For measurement to be cost effective, it must be designed and targeted to support the business goals of the organization. The Goal-Question-Metrics (GQM) method is based on the assumption that measurement is always carried out towards an explicitly stated purpose: a measurement Goal. GQM model is a three levels hierarchical structure: the top is a conceptual level, some goals (G) are defined in this level; the middle level is an operational level, in which the goals are refined into several questions (Q); and the bottom is a quantitative level, which provides a set of data or metrics (M) associated with the questions. It is obvious that GQM method is quite useful in a goal-driven business environment. The original GQM is more or less a paradigm with no explicitly defined process. There are a number of GQM process models suggested, such as the Planning - Definition - Data Collection - Interpretation model [12] and the Goal-Driven measurement process model [7]. This process model maintains traceability from measures back to the goals and focuses on gathering information, which can help us achieve business goals. The goaldriven measurement is a 10-step-process, which starts by identifying business goals and terminates by providing a plan for implementing the measures. This goal-driven process is concise and comprehensive, but unfortunately, it is also too exhaustive and expensive process. Even for metrics specialists, it is a difficult and time-consuming process [6]. According to 2003 worldwide IT benchmark report, there are only less than 4% staff working in software measurement position in software organizations and few measurement effort in whole development life cycle. Therefore one can image that in spite of being useful, the goal-driven measurement approach cannot be readily applied in a real software engineering practice. Therefore, it is necessary to develop an intelligent aid system to help measurement engineers and software organizations improve their measures for achieving business goals following the goal-driven software measurement process. The objective is to automate the goal-driven measurement tasks by building a system that accepts at its input a user’s business goal, asks questions interactively and after a few iterations produces a software measurement plan at its output. This system is designed as an intelligent GQM front end for the Software Engineering Measurement Expert System (SEMEST) [13], which is a web-based expert system for software measurement and analysis.

2. ISMS System 2.1 System overview

The proposed Intelligent Software Measurement System (ISMS) is designed as a multiagent system (MAS) composed of two clusters of agents: client-side assistant agents and server-side cooperative agents. The client-side agents work as intelligent front-end for the users and the server-side agents work cooperatively to realize various roles necessary to implement the GQM process (see Figure 1).

190


Figure 3. ISMS system architecture

The client-side is composed of a Personal Assistant (PA) agent which is a light weight agent, which accepts user’s business goal(s) and other related information in the interface. The PA receives the input and generates a query to be sent to the server-side cluster with the GQM expertise. The server-side agents, collectively called Expert Assistant (EA), work cooperatively to process the query and raise some relevant questions according to the business goals and communicate them back to the PA and the user. After a few iterations, the system achieves the function that maps business goals into a set of measurement goals through matching and processing the goals and user’s answers. After


191

the measurement goals are finalized, the EA will produce a complete software measurement plan which includes objective, description, implementation and sustained operation of measurement. This system finds a way to revise and update the plan as the project or organization goals change easily [1]. It can give users some expert suggestion, and provide guidelines automatically to help find and define effective measurement to support their business goals. 2.2 Requirements y The ISMS is composed of PA and EA agents, which are distributed in client-side and server-side. y The ISMS shall provide aids for types of business goals, which are dropped into different aspects such as purpose, perspective and environment. y The ISMS shall deal with a large number of PAs synchronously. y The ISMS shall help PAs to formulate their original business goals by asking for some information and providing some suggestions. y The ISMS shall help PAs to obtain measurement plans followed the goal-driven process step by step. y The ISMS shall provide a complete and formatted measurement plan.

3. System Analysis and Design 3.1 System analysis

Following GAIA methodology for multi-agent system (MAS) design, two analysis model can be constructed, roles model and interaction model [4]. In the roles model, the following 12 roles can be defined: • Personal Assistant Role • Message Exchanger Role • Goal Identifier Role • Question Identifier Role • Entity Identifier Role • Subgoal Identifier Role • Measurement Formulizer Role • Indicators Identifier Role • Data collection Identifier Role • Metrics Definer Role • Measurement Action Identifier Role • Measurement Plan Maker Role The interaction model defines the dependencies and the relationships between various roles in a multi-agent organization. This model can be partly represented by MAS architecture; on the other hand, it also includes a set of protocol definitions, which will be provided in the section of Inter-Agent communication.

192


3.2 System design

In the design stage, three models are generated: the agent model, the service model, and the acquaintance model [4]. The agent model identifies the agent types that will make up the system. Roles are mapped into agents, and each agent may therefore take one or more roles. For ISMS, oneto-one mapping is feasible. The main reason for one-to-one mapping is that the output of each step must be forwarded to the user for verification and by combining the roles, the verification may be lost. The agent model is shown below in Table 1. Table 1. Agent model

Role Personal Assistant Message Exchanger Goal Identifier Question Identifier Entity Identifier Subgoal Identifier Measurement Formulizer Indicators Identifier Data collection Identifier Metrics Definer Measurement Action Identifier Measurement Plan Maker

Agent Personal Assistant Agent Message Exchanger Agent Goal Identifier Agent Question Identifier Agent Entity Identifier Agent Subgoal Identifier Agent Measurement Formulizer Agent Indicators Identifier Agent Data collection Identifier Agent Metrics Definer Agent Measurement Action Identifier Agent Measurement Plan Maker Agent

The aim of the service model is to identify the services associated with each agent role. Since the one-to-one mapping fashion between the agent types and the roles is adopted, the services of each agent type are equivalent to the responsibilities identified for the corresponding role. The agent acquaintance model identifies the communication pathways among agents and the procedures for the whole system. The sequence diagram shown in Figure 2 depicts the interaction flow on ISMS. 3.3 ISMS architecture

As shown in Figure 1, a message exchange agent in EA communicates with PAs via Internet or intranet. In server side, EA is composed of two layers and a knowledgebase (KB). The top layer is a concrete layer achieved by cooperation of a group of agents, which can accomplish different steps of goal-driven measurement process [7]. These agents work together by a pipeline style, by which they work in a single direction workflow, the output of previous agent is the input of next one, and next agent can return some feedback to previous one. When these agents want to communicate with PAs, firstly they transfer information to the message exchange agent, by which they can

193


connect with PAs. The bottom layer is a logical layer whose responsibility is providing reasoning mechanism for the implementation layer. Personal Assistant Agent

Message Exchanger Agent

Goal Identif ier Agent

Question Subgoal Identif ier Agent Identif ier Agent

Measurement Entity Identif ier Formulizer Agent Agent

Indicators Data Collection Metrics Def iner Measurement Action Identif ier Agent Identif ier Agent Agent Identif ier Agent

Measurement Plan Maker Agent

Feedback

Feedback

Feedback

Feedback

Feedback

Feedback

Feedback

Feedback

Feedback

Figure 4. Interaction diagram of ISMS agents


194

3.4 Inter-agent communication

In order to cooperate, the EA agents must use the techniques and protocols through which they can efficiently communicate [2]. Inter-agent communication is comprised of communication language, Interaction protocol, and transport protocol. Foundation for Intelligent Physical Agents (FIPA) [5] is established to promote the development of specifications of generic agent technologies that maximize interoperability within and across agent-based applications. FIPA-ACL (Agent Communication Language) is a part of FIPA specification [SC00061]. In ISMS, every agent can create messages using FIPA ACL. The content of the message is expressed in a content language, and FIPA SL [SC00008] content language is adopted in ISMS. The communication acts in this system are defined followed FIPA Communication Acts (CAs) [SC00037]. XML is the language of choice for better organizing our structured information and resources in the networked age. It allows documents to be defined, created, stored and retrieved hierarchically. Therefore, XML is used to wrap the FIPA-ACL messages to make their creation, distribution and management more conveniently and more efficiently [8]. All the agents have a XML parser that extracts the ACL messages from the XML for pre-processing messages and a wrapper to convert the ACL messages to XML before transmission. All ACL message in ISMS conforms to FIPA ACL Message Representation in XML [SC00071]. Interaction protocol refers to the high level strategy pursued by software agent that governs its interaction with other agents. An Interaction Protocol (IP) with respect to MAS is a defined course of action used to direct the negotiation of agents negotiates over one or more resources. FIPA provides a series of interaction protocols, whose specification identifies pre-agreed message exchange protocols for ACL messages. Some protocols of FIPA IP are adopted in ISMS design. In MAS, every agent should have agent name, may have agent attributes, and has an agent locator. The agent locator lists the transport descriptions for that agent. Each transport description correlates to a particular form of message transport, such as IIOP, SMTP or HTTP. In ISMS design, FIPA Agent Message Transport Protocol (MTP) for HTTP [SC00084] is the transport protocol being used [5]. 3.5 Agent internal architecture

The internal architecture of the PA is depicted in Figure 3, which includes: y GUI (Graphic User Interface) is used for exchanging information and conversation between user and system. y Interpreter parses and interprets the incoming and outgoing messages. y XML Processor calls appropriate function to run a process and produces an XML document as output.

195


The internal architecture of the Message Exchanger Agent is depicted in Figure 4, which includes: y Message Service Port (MSP) provides transport description and chooses transport mode for ever incoming and outgoing message between PAs and EA. y Interpreter parses and interprets the incoming and outgoing messages. y XML Processor calls appropriate function to run a process and produces an XML document as output. The internal architecture of the 10 process agent is depicted in Figure 5, which includes: y Transport Port is a communication module that receives all incoming messages and sends all outgoing messages. y Interpreter parses and interprets the incoming and outgoing messages. y Reasoning engine implements the task assigned to the particular agent. y XML Processor calls appropriate function to run a process and produces an XML document as output.

User

PAs & EA

EA

GUI

Message Service Port

Transport Port

Interpreter

Interpreter

Interpreter

XML Processor

XML Processor

Reasoning Engine

XML Processor

Fig.3 Internal architecture of PAs

Fig.4 Internal architecture of Message Exchanger Agent

Fig.5 Internal architecture of EA process agents

4. Intelligent Processing 4.1 Knowledge representation

Data is defined as a sequence of quantified or quantifiable symbols. Information is about taking data and putting it into a meaningful pattern. Knowledge is the ability to use that


196

information. How to make software systems aware of something and how to store knowledge in computers are the core problems around knowledge representation [11]. There are various kinds of knowledge representation types such as declarative, procedural and relational. In ISMS, the knowledge is represented in the form of procedural (typically, if … then rules and frames with methods to execute) and relational (record of information about an item, with each record containing a set of fields defining attributes and values). The procedural knowledge is stored in a local knowledge-base for each EA agent and a global knowledge-base for the whole system (See Figure 1). The global knowledge-base is refined and updated by individual agents. The relational knowledge is stored in a relational database system. 4.2 Reasoning mechanism

The reasoning engine for the EA agents is composed of a number of reasoning modules each tailored to a certain type of reasoning, such as forward or backward chaining module to work with if … then rules and Dempster-Shafer module to combine the evidences. The reasoning modules are selected from a library of reusable and adaptive reasoning components (COTS) built to serve as the infrastructure for MAS system design [14]. 4.3 Learning mechanism

An important character of agent-based system is learning. Being able to adapt to changes in the environment or to get better at tasks through experience becomes a significant differentiator for any software system [11]. A learning agent can recognize situation it has been in before and improve its performance based on prior experience. There are a series of learning algorithm such as rote learning, weight adjustment, induction, and clustering. In ISMS, based on inputs of customers and outputs of system, system adaptation and learning will be achieved by rote and weight adjustment technique, which can help system extend knowledge in its depository.

5. Conclusions This paper has presented an intelligent front-end to implement and automate the GQM process. The ISMS has been designed to provide multiple users with software measurement services via the Internet. Refining software engineering goals to quantitative measurements has been enabled by the system. So far, the ISMS system analysis and design tasks are accomplished. The knowledge representation, reasoning mechanism, and learning technique are being implemented. Integration of the ISMS with the SEMEST will be the next phase.

References [1] Fenton, N.E, Pfleeger, S.L. (1998), “Software Metrics: A rigorous and Practical Approach” (2nd Edition), PWS Pub Co., ISBN: 0-534-95425-1.


197

[2] Pfleeger, S.L., Pierre, S., Hoang, H.H., “Modeling a Multi-Agent System for Retrieving Information from Distributed Sources”, Journal of Computing and Information Technology – CIT 11, 2003, 1, 1-13, pp. 15-39. [3] Huhns, M.N., Singh, M.P. (1997), “Reading in Agents”, Morgan Kaumann Pub Co., ISBN: 1-55860-495-2. [4] Wooldridge, M., Jennings, N.R., Kinny, D. (2000), “The Gaia Methodology for Agent-Oriented Analysis and Design”, Autonomous Agent and Multi-Agent System, 3, 2000, pp. 285-312. [5] The Foundation for Intelligent Physical Agents FIPA: www.fipa.org. [6] Lavazza, L. et al. (2000), “Providing Automated Support for the GQM Measurement Process”, IEEE Software, May/June 2000, pp. 56-62. [7] Park, R.E., Goethert, W.B., Florac, W.A. (1996), “Goal-Driven Software Measurement ―A Guidebook”, Handbook CMU/SEI-96-HB-002. [8] Representation of KIF & FIPA-ACL in XML: http://www.cs.umbc.edu/~mjin/xml. [9] Briand, L.C., Morasca, S., Basili, V.R. (2002), “An Operational Process for GoalDriven Definition of Measures”, IEEE Transaction on Software Engineering, Vol. 28, No. 12, December 2002, pp. 1106-1125. [10] McLaughlin, B. (2001), “Java & XML” (2nd Edition), O’REILLY Pub Co., ISBN: 0-596-00197-5. [11] Bigus, J.P., Bigus, J. (2001), “Constructing Intelligent Agents Using Java” (2nd Edition), Wiley Pub Co., ISBN: 0-471-39601-X. [12] Solingen R. and Berghout E. (1999), “The Goal/Question/Metric Method: a practical guide for quality improvement of software development,” McGraw-Hill. [13] He, Q., Wang, Y., Far, B.H. and Zhang, S. (2003), “A Web-Based Software Measurement Expert System,” Proceedings of the 2003 Canadian Conference on Electrical and Computer Engineering (CCECE’03), IEEE CS Press, Montreal, Canada, pp.17.3.1-4. [14] Wei Wu, Far, B.H., and Ekaette, E., “Software Agent’s Uncertainty Management Framework in Multi-Agent System,” Proceedings of the ATS 2003 Conference (this volume).

Development of an Intelligent Agent-Based GQM Software ...

Development of an Intelligent Agent-Based GQM Software ...

Suggest Documents