Software Agent Measurement and Self-Measuring Agent-Based Systems Reiner R. Dumke, Reinhard Koeppe, Cornelius Wille University of Magdeburg, Faculty of Computer Science, Postfach 4120, D-39016 Magdeburg, Germany Tel.: +49-391-67-18664, Fax: +49-391-67-12810, Email: {dumke,koeppe,wille}@ivs.cs.uni-magdeburg.de
http://ivs.cs.uni-magdeburg.de/sw-eng/us/
Contents 1 Introduction .............................................................................................. 2 2 Software Agents and Agent-Based Systems ........................................... 3 2.1 Principles and Techniques of Software Agents .......................................................... 3 2.2 Architectures of Agent-Based Systems ........................................................................18 2.3 Examples of Software Agents Systems in the WWW ................................................ 23
3 Software Measurement, Evaluation and Controlling ............................ 25 3.1 The Software Measurement and Evaluation Framework .......................................... 25 3.1.1 Measurement Choice ..............................................................................................26 3.1.2 Measurement Adjustment ...................................................................................... 27 3.1.3 Measurement Migration ......................................................................................... 28 3.1.4 Measurement Efficiency ......................................................................................... 29 3.2 Related Work in Measurement of Software Agents and Agent-Based Systems ....... 30
4 Measurement of Agent-Based Systems .................................................. 32 4.1 Measurement Choice and Empirical Criteria ............................................................. 32 4.2 Measurement Areas of Adjusted Metrics ................................................................... 36 4.3 Kinds of Measurement Migration in Agent-Based Systems ...................................... 39 4.4 Tool Support and Measurement Integration .............................................................. 38
5 Software Aglets as Self-Measuring Agent-Based System ...................... 40 5.1 Main Characteristics of the Aglets Technology .......................................................... 40 5.2 Measuring Aspects ......................................................................................................41 5.3 Examples of Measurement Implementation ................................................................41
References ....................................................................................................44 1
1 Introduction Software Agents is provide new means to implement flexible and intelligent communication systems with an autonomous aspect of sensoring, understanding, negotiation, decision, and action. But in introducing new techniques or technologies, the main aspects of investigation are addressed to their functionality in the new application area and are based on the experimentation with new paradigms (tools, languages, middleware and architectures). Like in the object-oriented software development, which will be understood just now based on more and more quantified experience, in the area of software agents we can only see some special remarks about complexity or efficiency (“Thus it is already a good bet that the software engineering of tomorrow will be ‘agent-oriented’, just as that of today is beginning to be ‘object-oriented’.” [Ferber 99, p. 8]). The shifting from an object to an agent is shown in a simplified manner in Figure 1. Agent memories, knowledge, skill, character Object/Class memories
features, adaptation, negotiation, learning, action, cooperation
features
Figure 1: Main characteristics of an object/class and an agent Obviously, we can establish a more complex structure or architecture of such agent-based systems. Moreover: • • • •
How can we use some experience in software measurement and evaluation of the objectoriented software development? Which kinds and contents are the new measurement aspects for agent-based systems? Which characteristics of software agents are measurable and which of them are necessary to measure? How can we install measurement aspects in agent-based systems to control the efficiency of software agents?
A lot of questions and problems exist in the development of agent-based systems and there are not enough satisfying answers now. [Jennings 98, p. 19] writes: “There is little in the way of production-quality software support for building agent applications, and still less general understanding of the issues that need to be addressed when building such systems. Worse, most of today’s agent systems are build from scratch, using bespoke tools and techniques, which cannot easily be applied to other types of systems. This is particularly worrying because a lot of infrastructure is required before the main components of an agent system can be built. At the moment, most developers rebuild this infrastructure from scratch in every new case; this process is clearly not sustainable.” This paper will give a first idea of possible aspects in software measurement of agent-based systems and will try to define measurement-based solutions. Currently, software agents are a new technique without detailed quantified knowledge about the technology. 2
2 Software Agents and Agent-Based Systems 2.1 Principles and Techniques of Software Agents In the field of software agents, we have to consider a sharp increase of knowledge and applications. We try to give a minimal description of the area of software agents that is required to explain and to define the measurement aspects. We are agree with the definition of software agents by [Maes 94]: “Autonomous agents are computational systems that inhabit some complex dynamic environment, sense and act autonomously in this environment, and by doing so realize a set of goals or tasks for which they are designed.”. This definition considers the important aspect of software agents and their environment which is necessary for any (autonomous) action. The general types of these interactions with the environment are shown in the Figure 2.
External Environment factors
AGENT
Outgoing messages (to human, agent or other controller)
Inference Engine Incoming messages from other agents
Internal World State
Actions on the environment
Figure 2: Agents interactions with the environment [Hayzelden 99, p. 10] Software agents can be applied to solve new types of problems such as [Jennings 98. p. 6/7] •
dynamic open systems: the structure of the system itself is capable of changing dynamically and its components are not known in advance, can change over time, and may be highly heterogeneous,
•
complex systems: agents represent a powerful tool for making systems modular which is one kind of the possibility to create and implement such systems,
•
ubiquity: agents should be autonomous, proactive, responsive, and adaptive to solve basic problems in cooperation with the user.
But, we can note that the very nature of the agent-based paradigm leads to a number of problems such as [Jennings 98, p. 10] •
no overall system controller which keep global constraints and avoid livelocks and deadlocks,
•
no global perspective related to the whole system or to the complete global knowledge,
•
trust and delegation of agents seeking guidance during the time that work on their behalf.
3
A general taxonomy of agents is given in the Figure 3 which can be found in most of the books about software agents. Autonomous agents
Biological agents
Robotic agents
Software agents
Task specific agents
Computational agents
Artificial life agents
Entertainment agents
Viruses
Figure 3: Taxonomy of autonomous agents An agent can have more aspects of the behavior which are described in the Table 1 by [Hayzelden 99].
Property Social ability
Autonomy
Reactivity Adaptability
Agent Granularity Degrees
Learning
Pro-activity
Description A software agent is able to use communication as a basis to signal interest or information to either homogeneous or heterogeneous agents that constitute a part of its environment. The agent may work toward a single global goal or separate individual goals. Agents should operate without the intervention of external elements (other agents or humans). They have some kind of control over their actions and internal states. Agents perceive their environment and respond in a timely fashion to changes that may occur. Agents are characterized by their flexibility, adaptation, and facility to set up their own goals based on their implicit purpose (interests). One of the major characteristics of agents is their ability to acquire and process information about the situation, both spatially and temporally. Agents may have degrees of complexity; Most simple agents are characterized by the lack of intelligence regarding their behavior. These agents are called reactive. More complex agents are called cognitive or intelligent agents. They are characterized by their ability to know their environment, to act on themselves and on the environment; their observed behavior is a consequence of their perception, knowledge, and interactions. Either the agency itself may perform some learning ability (as a society) or each individual agent may be embedded with a learning algorithm (e.g. a Neural Network or their re-enforcement algorithm). Learning often allows the agent to alter its future action sequences and behavior such that future mistakes can be alleviated. Learning is often a factor that provides an agent’s ability to demonstrate adaptive behavior. Agents should exhibit goal directed behavior such that their performed actions cause beneficial changes to the environment. This capability often requires the agent to anticipate future situations (e.g. using prediction) rather than just simply responding to changes within their environment.
Table 1: Properties of software agents by [Hayzelden 99, p.5/6]
4
On the other hand, we can combine the agents characteristics to define special kinds of software agents and agent communities (see Figure 4 adapted from [Darbyshire 00]). Autonomy pro-active reactive
passive preference
reasoning
learning Intelligence
with humans with agents Social ability
Figure 4: 3D model of agents characteristics In order to define all aspects of the behavior of an agent based on the 3D characteristics, we will cite the definition of [Ferber 99, p. 9] of general (software) agents: “An agent is a physical or virtual entity (a) which is capable of acting in an environment, (b) which can communicate directly with other agents, (c) which is driven by a set of tendencies (in the form of individual objectives or of a satisfaction/survival function which it tries to optimise), (d) which possesses resources of its own, (e) which is capable of perceiving its environment (but to a limited extent), (f) which has only a partial representation of this environment (and perhaps none at all), (g) which possesses skills and can offer services, (h) which may be able to reproduce itself, (i) whose behavior tends towards satisfying its objectives, taking account of the resources and skills available to it and depending on its perception, its representations and the communications it receives.” This definition leads to the following examples of general empirical characteristics of a software agent: Empirical characteristics of a software agents: (a) (b) (c) (d) (e) (f) (g) (h) (i)
the quality of the capability of acting in an environment, the level of communication with other agents, the quantities of the driven aspects by a set of tendencies, the characteristics of possessed resources, the kind of capability of perceiving its environment, the characteristics of the agent-based partial representation of this environment, the quality of the possessed skills and offered services, the level of the ability to reproduce itself, the kind of the behavior towards satisfying its objectives, taking account of the resources. 5
Software agents are substantially build by communication and we can further detail the agents definition above as [Ferber 99, p. 12] “By comparison with the general definition of an agent given above, a purely communicating agent (or software agent) is defined as a computing entity which (a) is in an open computing system (assembly of applications, networks and heterogeneous systems), (b) can communicate with other agents, (c) is driven by a set of its own objectives, (d) possesses resources of its own, (f) has only a partial representation of other agents, (g) possesses skill (services) which it can offer to other agents, (i) has behavior tending towards attaining its objectives, taking into account the resources and skills available to it and depending on its representations and on the communications it receives.” In order to measure or to evaluate this kind of agents, we can modifyed the empirical characteristics which we have defined above. Software agents can build communities in a special domain area. Such systems are defined by [Ferber 99, p. 11] as multi-agent systems: “The term 'multi-agent systems' (or MAS) is applied to a system comprising the following elements: (1) An environment, E, that is, a space which generally has a volume. (2) A set of objects, O. These objects are situated, that is to say, it is possible at a given moment to associate any object with a position in E. These objects are passive, that is, they can be perceived, created, destroyed and modified by the agents. (3) An assembly of agents, A, which are specific objects (A ⊆ O), representing the active entities of the system. (4) An assembly of relations, R, which link objects (and thus agents) to each other. (5) An assembly of operations, Op, making it possible for the agents of A to perceive, produce, consume, transform and manipulate objects from O. (6) Operators with the task of representing the application of these operations and the reaction of the world to this attempt at modifications, which we shall call the laws of the universe.” Hence, we can defined some of essential empirical aspects for the evaluation of multi-agent systems. Empirical characteristics of a multi-agent system: (1) the volume and structure of an agent environment E, (2) the position in E of the objects O which are active. The status perceived, created, destroyed and modified of the objects which are passive, (3) the level of the assembly of agents, A, which are specific objects, representing the active entities of the system, (4) the intensity of the relations, R, which link objects (and thus agents) to each other, (5) the performance of the operations, Op, making it possible for the agents of A to perceive, produce, consume, transform and manipulate objects from O, (6) the complexity of the operators with the task of representing the application of these operations and the reaction of the world to this attempt at modifications, which we shall call the laws of the universe.
6
On the other hand, some of the experience of multi-agents systems by [Hayzelden 99] are defined as benefits of the MAS as: • • • •
• • •
“to address problems that are too large for a centralized single agent, for example because of resource limitations or for robustness concerns (the ability to recover from fault conditions or unexpected events); to enable the reduction of processing costs - it is less expensive (in hardware terms) to use a large number of inexpensive processors than a single processor with equivalent processing power; to allow for the interconnecting and interoperation of multiple existing legacy systems, e.g. expert systems, decision support systems, legacy network protocols; to improve scalability - the organizational structure of the agents can dynamically change to reflect the dynamic environment - i.e. as the network grows in size the agent organization can re-structure by agents altering their roles, beliefs and actions that they perform; to provide solutions to inherently distributed problems, for example, telecommunications control, air traffic control and workflow management; to provide solutions which draw from distributed information sources; and to provide solutions where the expertise is distributed;”
Some kinds of an agent communication language (ACL) [Singh 98] are the main aspect in the interaction between software agents. We can establish the general situation in shifting from the interactions between objects and between agents which is intimated in Figure 5.
agent 1 object 1
agent 2
object 2 messages
interaction based on a communication language
Figure 5: Kinds of interaction between objects and between agents Kinds of agent interactions for a successful or conflicting situation are described in [Ferber 99, p. 66] and is shown in the following Table 2.
Category Situation
Goals Resources Skills
Indifference IndepenSimple dence collaboration compatible sufficient sufficient
compatible sufficient insufficient
Obstruction
Cooperation Coordinated collaboration
compatible insufficient sufficient
compatible insufficient insufficient
Pure individual competition incompatible sufficient sufficient
Pure collective competition incompatible sufficient insufficient
Antagonism Individual conflicts over resources incompatible insufficient sufficient
Collective conflicts over resources incompatible insufficient insufficient
Table 2: Situations in agents interaction A general empirical estimation of the success of agents interaction is described in [Ferber 99, p. 61] as: “We shall consider an interaction situation as being an assembly of behaviors resulting from the grouping of agents which have to act in order to attain their objectives, with attention being paid to the more or less limited resources which are available to them and to their individual skills.” 7
A detailed definition of a successful agent interaction is defined by [Ferber 99, p. 62] as: “The goal of an agent, A, is incompatible with that of another agent, B, if agents A and B have, as their respective goals to be achieved, the states described by p and q respectively, and if p ⇒ ¬ q, that satisfies is: (goal (A, p)) ⇒ ¬ satisfies (goal (B, q)).” The cooperation can be the largest context of interaction. In the literature we find the usual definition of cooperation as Cooperation = collaboration + coordination of actions + resolution of conflicts . Indicators of a cooperative activity by Bourdon in [Ferber 99, p. 71/72] are:
Empirical aspects of agent cooperation: (1) “the coordination of actions, which concerns the adjustment of the direction of agents’ actions in time and space; (2) the degree of parallelism, which depends on the distribution of tasks and their concurrent execution; (3) the sharing of resources, which concerns the use of resources and skills; (4) the robustness of the system, which concerns the system’s aptitude for making up for any failure by an agent; (5) the non-redundancy of actions, which characterises the low rate of redundant activities; (6) the non-persistence of conflicts, which testifies to the small number of blocking situations.”
An explicit definition of agent cooperation is given by [Ferber 99, p. 72] as: “We shall say that several agents are cooperating, or that they are in a cooperation situation, if one of the following two conditions is verified: (1) The addition of a new agent makes it possible to increase the performance levels of the group differentially. (2) The action of the agents serves to avoid or to solve potential or actual conflicts.” Reasons for cooperating are described by [Hayzelden 99]: “There has been a considerable amount of work on distributed planning, scheduling, resource allocation and control problems for co-operative agents. The principle reasons for the distribution of such tasks include: • the desire to reduce communication costs associated with a central problem solver; • the desire to improve performance through parallelism; • the desire to gain reactivity through not needing to consult a central agency; and; • the desire to improve robustness through lack of dependence on a single computational node.” The system of cooperating agents can be build as agent organisations. We cite the definition of [Ferber 99, p. 88]: “An organisation can be defined as an arrangement of relationships between components or individuals which produces a unit, or system, endowed with qualities not apprehended at the level of the components or individuals. The organisation links, in an interrelational manner, diverse elements or events or individuals, which thenceforth become the components of a whole. It ensures a relatively high degree of interdependence and
8
reliability, thus providing the system with the possibility of lasting for a certain length of time, despite chance disruptions.” Problems and indicators of the coordination in agent-based organisation are described in Figure 6 [Ferber 99, p. 83].
Survival
Inprovement in performances and reliability
Grouping and multiplication
Specialisation
produces
produces
Avoidance and reduction of conflicts
Problems of access and actions
Problems of task distribution
solves
solves solves
solves
Arbitration negotiations, hierarchisation
Techniques of coordination of actions
Techniques of task allocation
produces serves to
serves to
Communications implements
implements implements
Internal architecture of agents
Organisation of society
Figure 6: Characteristics of coordination in agent-based organisations
9
The schematic representation of the different functions of an organisation is shown in Figure 7.
Cognitive function
Vegetative function
Coordination function
Productive function
Representational function
Interface function
Figure 7: Types of functions of an organisation
The representational function comprise the generality of functions for modelling the environment and other organisations, as well as the memorisation of any events which may have affected the organisation. The role associated with the representational function is that of archivist. The organisational function relates to everything concerning the management of the activity of an organisation, and in particular to the planning, allocation and following up of tasks, the coordination of actions and the management of obligations. A large number of roles are associated with this function, in particular those of customer, mediator, planner and coordinator. The conative function refers to the sources, limits and selection of the activities of organisations and is divided into three sub-functions: the motivational function, the external function and the decision function. One of an associated role of this function is the decisionmaker. The interaction function serves to create the link between an organisation and that which surrounds. The roles associated with this function are those of interface (observer, executive and communicator). The productive or operative function concerns the primitive activities which have to be brought into play to solve a problem or carry out a piece of work. The vegetative or preservative function deals with the preservation of both structure and agents, with the acquisition and maintenance of resources, and with the tasks carried out to maintain and reproduce the organisation.
10
In the interaction between organisations, [Ferber 99, p. 96] defined five types of dimensions: (1) The physical dimension (φ) deals with implementation, the architecture of the organisation and its personal resources. (2) The social dimension (σ) concerns the place and thus the role of an organisation in a higher-level organisation. (3) The relational dimension (α) is concerned with interactions, with the exchanges wich an organisation may have with other organisations on the same level, and with its communications and their coordination. (4) The environmental dimension (χ) is linked to an organisation’s capacities to act, perceive and reason in relation to the surrounding world. (5) The personal dimension, or dimension of the self (ω) represents everything which relates to the essence of the organisation. Figure 8 is gives a simplified presentation of these dimension analysis of agent organisations. Social
Relational
σ α
χ
Self ω
Environmental
φ Physical
Figure 8: Aspects of analysing of organisations The following two tables describe the different types of aspects in a typical reactive organisation and in a typical purely communicative organisation [Ferber 99, p. 105]. Function / Analysis grid Representational Organisational Conative Interactional Productive Preservative
physical
social
relational
environmental
personal (self)
Absence Presence Presence Presence Presence Presence
Absence Absence Absence Absence Absence Absence
Absence Absence Absence Absence Absence Absence
Absence Presence Presence Presence Presence Presence
Absence Absence Optional Absence Absence Absence
Table 3: Characteristics of typical reactive organisations Function / Analysis grid Representational Organisational Conative Interactional Productive Preservative
physical
social
relational
environmental
personal (self)
Presence Presence Presence Presence Presence Absence
Presence Optional Optional Absence Optional Absence
Absence Presence Presence Presence Optional Absence
Absence Absence Absence Absence Optional Absence
Presence Optional Absence Absence Absence Absence
Table 4: Characteristics of typical communication organisations 11
In this context, we can establish seven types of agents relationships shown in Table 5 by [Ferber 99, p. 111]. Relationships Acquaintance Communicational Subordination Operative Informational Conflictual Competitive
Static Master/slave Dependency between tasks Dependency between knowledge -
Dynamic Service demand/request Obligation to do Validation obligation -
Table 5: Organisational relationships On the other hand, software agents behavior is based on three main types of agent coupling such as [Ferber 99, p. 113]: 1. Fixed coupling: each component has a role or perhaps several roles from which it does not shift, 2. Variable coupling: the relationships between agents can evolve, but within a framework of very specific mechanism, 3. Evolutionary coupling: this kind of coupling characterises a variable organisation structure where the agents can evolve as a function of performance etc.
The formal description of an agent semantics in an organisation is defined by following relations by [Ferber 99, p. 115/116]: •
Degree of specialisation HaP: an agent a for a problem P indicates the agent’s skill rating in relation to the number of skills necessary to solve a problem: HaP = (card(CP) – card(CaP)) / (card(CP) – 1) where CP is the set of skills required to carry out a piece of work and Ca is the set of the agent skills;
•
Degree of redundancy: this degree characterises the number of agents possessing the same skills which is defined by Ferber as Rc = (Pc – 1) / (card(C) – 1) where Pc is use to refer the number of agents with the skill c (Pc.= card({a | c ∈ Ca}) ).
Relating on this characterisation of agents facilities and skills, we can divide agents organisation in non-redundant vs. redundant and specialised vs. generalist forms.
The description of agents organisations above leads us to a general presentation of their main empirical characteristics. 12
Empirical characteristics of agent-based organisations: •
The characteristics of the functions of agents in the organisation (representational, organisational, conative, interaction, operative and preservative),
•
The quality aspects of analysis dimensions of software agents (physical, social, relational, environmental and personal) in the organisation,
•
The complexity of the agents coupling (fixed, variable and evolutionary),
•
The effectiveness of agents organisation addressed to their redundancy and specialisation.
The following description is dedicated to the action and behavior of software agents. The action of agents can be modelled in the following six kinds by [Ferber 99, p. 148]: 1. Action as transformation of a global state: this approach is based on the classical AI planning theory. The general description of this state-based action can defined as
σ1 = Exec(A, L1 , L2), σ2) where are A the agent, σ1 and σ2 the different states (old and new) and L1 and L2 the different agent locations (old and new). The transformation itself was described by stripslike operators which are based on the description of the direction related to the dimensions. 2. Action as response to influences: An agent is actually making a gesture or influences. The result of these gestures are obtained by application of the laws of the universe. The latter are the response of the environment, which acts by combining all the influences it receives from agents, and then deducing from them a new global state in conformity with its own particular nature. Action and reaction can be defined generally on the base of the influences Γ and the states Σ as Exec: Op × Σ → Γ, especially Exec(op,σ) = γ 3. Action as computing processes: Methods of this kind of action description are finite-state automata, register automata, petri nets, and other forms of algorithm descriptions. 4. Action as local modification: In local models, action is considered as being a local modification which is propagated along a net of automata. The cellular automata is a kind of this description. 5. Action as physical displacement: Models relating to this kind of action definition are (physical) space description, and potential field presentations. 6. Action as command: This description form is based on control theory and cybernetics which apply a particular command theory. 13
The general operation/action of agents can be characterised as [Ferber 99, p. 190]: “Agents entities capable of taking account of what surrounds them, which, for purely situated agents, translates into the capacity to perceive the environment and to act by executing actions which tend to modify the state of the multi-agent system, after having deliberated on what should be done. So we say that an agent is made up of three parts: perception, deliberation, and execution.” “Tropistic agents are agents which act in a totally reflex manner in relation to the states of the world. We thus assume that the agents have no goals, and even no internal states.” The main functionality of these agents can be defined as Reflexa = Pa → Op Percepta = Σ → Op Behavea = Σ → Op where Pa represents the set of percepts associated with an agent a. Hysteretic agents are based of the idea of memorising a piece of information and thus they can acting on the basis not only of perceptions but also of past experience. A formal description of this kind of agents is based on Reflexa = Pa × Sa → Op Mema : Pa × Sa → Sa Decisiona : Pa × Sa → Pa Percepta = Σ × Sa → Op Behavea = Σ × Sa → Γ × Sa where Sa is the set of the internal states of an agent a. The SDL diagram can be used as an appropriate modelling technique for multi-agent systems components of input and output. The following Figure 9 describes the general architecture of multi-agent systems by [Ferber 99, p. 211].
Agent A1
Message routing unit Agent A2
. . .
Agent An
Figure 9: Architecture of communicating multi-agent systems 14
As another example of these behavior description, we will give a short overview about the characteristics of formal specification of software agents. [Sewell 99] describes a two-level architecture of mobile agents based on the π-Calculus. The main definitions are •
the agent creation:
•
the agent migration: migrate to s → P .
agent a = P in Q ,
An example of agent behavior is given in following without any comments. agent b = new d in iflocal
c ! d → 0 else 0 in c ? x → x! The possibility of evaluation can be realised in such languages through attributing or parsing. The general characteristics of the agent action and behavior leads us to the following general empirical aspects of this kind of agent analysis.
Empirical characteristics of the action and the behavior of agents: •
The action characteristics of performance, complexity and quality based of the different types of forms of agent actions (transformation, influences, processes, modifications, displacement and command.
•
The general types of agents with or without memory and knowledge (tropistic agents and hysteretic agents).
The next consideration is directed on the states of the (artificial) minds of software agents. This view is related to the mental states and intentionality of software agents. Mental states are based on the cognition concept which consider several types of cognition as interactional, representational, conative, organisational and other cognitions. [Ferber 99, p. 225] describe three general types of modelling of the intentionality of agents: •
The interactional system: This kind of modelling is addressed to the actions such us active and passive perceptions and defines the elementary and complex features.
•
The representational system: This kind of modelling considers the representation, the beliefs and the knowledge of agent-based systems. The types of beliefs can also be divided in the organisational grids of analysis as environmental (χ), social (σ), relational (α) and personal (ω).
•
The conative system: This model determines the action that the agent should undertake, on the basis of the data and knowledge available to it, in order to maintain a function, while preserving its structural integrity and its actions in such a way that the organisation of which it forms part also preserve its structural integrity. 15
On the other hand, the source of actions are motivations. Relating to the dimensions of organisations, we can distinguish between personal, environmental, social and representational kinds of motivations. As a special case, we can establish the commitment as a solution of relational and social motivations under special constraints. Another aspect of motivation is the intention which is defined by [Ferber 99, p. 298] as: “We say that an agent x has the intention of carrying out an action a which we denote as intention(x,a) if x has as its goal that a proposition P about a state of the world should be true (denoted goal(x,P) ) and that the following conditions should be satisfied: (3) x believes that P forms part of the consequences of a; (4) x believes that P is not currently true; (5) x believes that it is capable of doing a; (6) x believes that a will be possible, and thus that P can be satisfied.”
Finally, we define some empirical characteristics related to the mental state and the minds of software agents as follows.
Empirical characteristics of the agents minds: •
The structure and the complexity of the current multi-agent system (interactional, representational and conative).
•
The intensity of the motivation of the different kinds of software agents .
•
The appropriateness of the commitments of agents related to the general system intention.
•
The relationship of the software agent intention to each other.
“Communication is expressed as a form of interaction in which the dynamic relationship between agents is expressed through the intermediary of mediators, signals, which, once interpreted, will affect these agents.” [Ferber 99, p. 307]
Intentions of communications are information and conversation and can be expressed by the communication medium based on messages, communication languages and conversation languages, such as KQML.
In order to explain the empirical aspects, we will cite the argumentation of Hayzelden et. al.
16
Empirical aspects of agents communication: Empirical goals for agent communication are reasoning by [Hayzelden 99] as: “Communication can occur via dynamic mechanisms such as shared memory, IPC facilities or via static mechanisms such as file system locks. There are three main categories of agent based communication. No Communication or Primitive Communication, Proprietary Agent Communication Languages (ACLs) and Standardized ACLs. There is of course more specific sub-categories for agent communication mechanisms, e.g. plan passing and stigmergy. Communication enables agents in a multi-agent environment to exchange information (e.g. to allow an agent to inform another agent about its current beliefs, amount of resources available, additional information about its environment, etc.) on the basis of which they originate their action sequences and co-operate with each other. Software agents generally communicate with other agents in order to work more flexibly. In order to achieve coordination, the agents might have to negotiate, however, they must certainly interact and exchange information. Most ACLs derive their inspiration from speech act theory, which was developed by linguists in an attempt to understand how humans use language in every day situations, to achieve everyday tasks, such as requests, orders, promises, etc. In multi-agent systems, the possible solutions to the communication problem range from those involving no communication (e.g. Appleby and Steward's BT mobile agent work), those involving ad hoc ACLs to those involving standard ACLs.”
The communication between agents is mostly embedded in common intentions such as collaboration or cooperation. These activities between agents require a general goal to produce some of the expected results. The main technology to keep this collaboration is called distribute allocation of tasks. Coordination and collaboration needs basic principles of management, such as coordination. The empirical reasons for agents coordination are defined by [Hayzelden 99] as: “There are several reasons why multiple agents need to be co-ordinated: • Firstly to prevent chaos. In general no agent possesses a global view of the entire agency to which it belongs, as this is simply not feasible in any community of reasonable complexity. Consequently, agents only have local views, goals and knowledge which, may interfere with, rather than support other agent’s actions. • Secondly, to meet global constraints: Agents performing network management may have to respond to certain failures within seconds and others within hours. Coordinating agent behavior is therefore essential to meet such global constraints. • Agents in a MAS possess different capabilities and expertise: Therefore, agents need to be co-ordinated in just the same way that different specialists need to coordinate their capabilities. • Agent’s actions are frequently interdependent and hence an agent may need to wait on another agent to complete ist task before executing ist own. These mutually dependent activities need to be co-ordinated.”
17
The four main kinds of coordination by [Ferber 99, p. 409] are: 1. the coordination by synchronisation, 2. the coordination by planning, 3. the coordination by reaction, 4. the coordination by regulation. Based on this short remarks, we define some empirical characteristics of agent cooperation and collaboration.
Empirical aspects of agents coordination and collaboration: •
The level and intensity of communication between software agents.
•
The kind and the quality of coordination between interacting agents.
•
The intention of collaboration as the basis of the evaluation of agents efficiency.
•
The volume and the efficiency of the cooperation.
•
The increasing of the agent facilities and knowledge during the collaboration.
2.2 Architectures of Agent-Based Systems In order to investigate the software agents quality, we must consider the different kinds of agent-based system architecture. These kinds of architectures lead us to the quantity characteristics of agent systems and give us the possibility of agents and systems evaluation based on real system parameters such as system structure, complexity and coupling. Kinds of agent architectures are described by [Hayzelden 99] as: “Reactive agent architecture: Agents based on this type of architecture generally do not have an internal representation of the environment. Nevertheless, many agents that are classified as reactive agents do have some limited representation of the world. This representation is often constrained to a set of condition-action rules, where the agent performs the associated action when inputs trigger a rule. Generally Reactive agents can generate changes to the world (via their actions) more rapidly than agents based on the architectures described below, because they use little reasoning and hence processing resource.
18
Deliberative agent architecture: An agent that conform to this architecture generally has a richer internal representation of its operational environment. This can be said to constitute its ’mental state’. The internal representation is successively modified to decide what planned actions will alter the environment towards or into the goal state. The extra knowledge that is intrinsic to this architecture can lead to an implemented agent’s behavior being more flexible than that of a purely reactive agent type. Therefore, deliberative agents tend to correct contingencies more successfully. One well known model that can be regarded as an instantiation of the deliberative architecture is the Belief, Desire, Intention (BDI) model. Hybrid agent architecture: This architecture is a coupling of the two above architecture. It therefore integrates a rapid response mechanism with the pro-active behavior enabled by planning. A good example of a hybrid agent architecture is given in and also the INTERRAP architecture.” Types of agents architectures are described by [Ferber 99, p. 127] in following Table 6. This table includes more details about the component structure. Type of architecture Horizontal modular Blackboard
Approach Horizontal functional Functional Vertical functional Vertical functional Functional
Subsumption Competitive tasks Production rules Classifiers
Vertical functional Vertical functional Vertical functional Object/ functional
Connectionist Dynamic system Multi-agent
Type of component Module
Subordination structure Hierarchical
Task
Hierarchical (Meta) Hierarchical
Primitive task Task + primitive actions Rule Rule
Hierarchical (Competition) Hierarchical (Meta) Hierarchical
Formal neuron
Egalitarian
Stimulicommand Agent
Egalitarian Egalitarian
Coupling structure Fixed (but progressive) Variable
Constitution
Fixed
Predefined
Variable
Predefined
Variable
Predefined
Evolutionary
Predefined
Fixed (by weight) Fixed (but progressive) Variable
Predefined
Predefined Predefined
Emergent Emergent
Table 6: Main agent architectures by Ferber The multi-agent system architecture is based on the concrete requirements of their implementation. An example of an Agent Service Layer (ASL) by [Evans 99] is shown in Figure 10 without any comments. C++
Sicstus Prolog
CLIPS
Java
KQML ASL
JASL
Orbix
OrbixWeb
TCP/IP
Figure 10: ASL architecture description 19
Jess
A simple description of the main components of an agent-based system by [Nwana 98] is shown in Figure 11. cooperate
learning
collaborative agents
smart agents
interface agents
autonomous software system
Figure 11: A part view of an agent typology We will show in Figure 12 another architecture defined by [Busuioc 99] which is addressed to the management of telecommunication systems. portable PC
mobile phone
PDA
customer agent
service agent
service agent
service supplier agents
service supplier agents
Network domain Cell agent fixed network agent (FNA) FNA FNA
FNA Agent Platform
Figure 12: The agent platform architecture by Busuioc The kinds of agents architecture should be the source for deriving model parameters and aspects for agent systems evaluations. Therefore, we will establish some of the empirical evaluations in the literature which we will intimate in some following citations. Reasons for agent mobility by [Hayzelden 99]: “Mobile agent technology was originally concerned with the ability to move executable code from one computer to another. The main benefit from adopting this approach was that available computational resources on another computer could be utilized when resources on the original computer became scarce. Even though the principles are quite intuitive, the actual implementation led to many unforeseen problems such as, maintaining the location of the software code in the network system, enforcing integrity and the more complex considerations of ensuring security and how to convert executable code to a generic platform independent format. Some of these points were considered relatively early in the evolution of the mobile agent history and before long, some 20
interesting capabilities were realized. Researchers became more interested in dealing with the idea of moving so called ’intelligence’ from one place of execution to the next. ... Aglet technology (IBM Japan), has re-opened the interest in mobile agent technologies and provides a Java implemented autonomous mobile software agent technology. Aglets extend the model of network-mobile code by allowing the class files to maintain state when migrating from node to node. Aglets still rely on the presence of a Java Virtual Machine to execute their state and actions, so that security breeches are limited.”
Empirical aspects of the software agent technology by [Hayzelden 99]: “There are a number of obstacles in the way of the wider take-up of agent technology. Chief among these are the following: • Lack of interoperation standards: We noted at several points throughout this article that work is underway to develop communication standards for agent systems - the FIPA initiative is probably the best known of these. Such standards will be essential if agent technology is to achieve its full potential. At the time of writing, however, there are several other essentially competing standards for agent communication under development, including the Knowledge Query and Manipulation Language (KQML), as well as the ongoing Object Management Group (OMG) effort to standardize on distributed object technology, and the WorldWide Web consortium's Extensible Markup Language (XML). Experience (in particular, the OSI experience) suggests that interoperation standards in information technology cannot be dictated - they tend to emerge and are dictated largely by the marketplace. It therefore remains to be seen what impact agent interoperation standards such as FIPA will have, and whether they will indeed lead to a greater take-up of agent technology. • Lack of methodologies for agent-based development: Developing any distributed system is difficult - such systems are amongst the most complex general class of software systems to design and implement. Multi-agent systems add to the inherent complexity of distributed systems by having heterogeneous, autonomous components, potentially designed and implemented by many different individuals and organizations. As a result, the multi-agent systems tend to exhibit unpredictable non-linear behavior, which can be very hard to understand. In order to master this complexity, methodologies are required for agent systems that enable a designer to model and understand multi-agent behavior. • Lack of understanding of the fit between system and problem: Agents have been deployed in many application domains, with very different properties. One of the most important tasks facing the agent research community is to achieve a better understanding of the characteristics of an application domain that imply an agent-based solution is appropriate. Too often, agents are applied to a particular problem without good reason.” “In our view, the technical aspects of mobile agents are not the only aspects requiring close attention. The real challenges lie in complementary concepts for the (self-) control of populations of mobile agents, such as multiagent systems, able to provide solutions for application areas characterized by inherently decentralized information. Coping with all of these challenges will provide the raison d’rtre and fulfill the promise of mobile agent technology.” [Schoder 00] 21
Empirical aspects of agents in telecommunication systems by [Hayzelden 99]: “Although allocation of resources is a major factor to consider when applying agents to telecommunications there are many others, including: • What communication does the agent have with other agents - try to minimize inter-agent communication so that action resolution is reached more rapidly. • Where should the agent(s) be located (the agent location granularity)? One agent per node, one per physical link, one to represent each connection? • Should the agents be stationary or mobile? • What view of the network does the agent have (the agent control granularity)? Is it beneficial to have the agent aware of other indirectly related events occurring in the agents locality. • What degree of dependency should there be between the agents in the system? If an agent 'dies', is the system still robust?” Trends and experiences in the agents applications in telecommunication by [Hayzelden 99] are: “Some of the reasons why the use of agent technology has not been a major factor in the development and implementation of current communications systems is due the lack of a suitable infrastructure to support autonomous agent based control. Of course, this situation is changing with the platform of choice increasing in size and popularity day by day, i.e., the Internet. However, other concerns have also prevented the introduction and adoption of agent technology. Distributed problem solving and AI techniques to support negotiation, distributed resource allocation and mobile agents are still in relatively early stages of development, and are not a proven technology. As an example, a spokesman from BT pointed out that in general, network operators are wary about the capabilities of having self-replicating mobile agents roaming their public communications network, Robin Smith states "this behavior closely mirrors that of a computer virus. And it would only take a slight change in the software to turn a helpful agent into a vengeful virus..... But is this [the use of mobile agents] going too far? Mobile agents makes everyone nervous, mainly because of their ability to act like viruses ...in fact, many telecommunications carriers are cautious about the whole idea of using agents because their ability to produce stable networks has not been proven". Smith continues with statements expressing the importance of further research into mobile agent security issues.”
Finally, we can establish in the area of software agents new dynamic architectures, new complex components, new distributed design technologies, but also new problems!
22
2.3 Examples of Software Agents Systems in the WWW We will give a presentation about some of the plenty of Web sites related to software agents divided in general information, systems and projects.
URLs to general information about software agents: • • • • • • • • • •
http://www.cs.bham.ac.uk/~amw/agents/index.html http://cui.unige.ch/tios/msgr/agents/overview.html http://www.sics.se/ps/abc/survey.html http://www.compinfo.co.uk/tpagnt.htm http://www.informatik.th-darmstadt.de/~fuenf/work/agenten/agenten.html http://www.ai.iit.nrc.ca/subjects/Agents.html http://www.cs.wpi.edu/Research/airg/Agents-hotlist.html http://www.Agent-Link.org http://www.csee.embc.edu/aw/ http://ivs.cs.uni-magdeburg.de/~dumke/STV/ST3-06.html
URLs about agents implementation languages: • • • • • • •
Telescript: http://www.genmagic.com/Telescript/Whitepaper/wp4/whitepaper-4.html KQML: http://www.cs.umbc.edu/kqml/papers/ Safe-Tcl: http://www.smli.com/research.tct Agent-Tcl: http://www.cs.dartmouth.edu/~agent/agenttcl.htm Python: http://www.python.org/ Obliq: http://www.research.digital.com/SRC/personal/Luca_Cardelli/Obliq/Obliq.html Scheme-48: http://photo.net/~jar/s48.html
URLs about agent-based system development: • • • • • •
IBM Aglets: http://www.trl.ibm.co.jp/aglets/ Voyager: http://www.pts.com/voyager.cfm Java-to-go: http://ptolemy.eecs.berkeley.edu/~wli/group/java2go/java-to-go.html WinWin model: http://sunset.usc.edu/WinWin/winwin.html SE: http://www.cs.vu.nl/~treur/SIG.meth0.html SIM-Agent: ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/
23
URLs about agent-based systems: • • • • • • • • • • • • • •
Telescript-based definition of personell shares portfolios: http://www.genmagic.com/ Retrievel agents: http://www.verity.com/ Meta browser: http://www.metacrawler.com/, http://meta.rrzn.uni-hannover.de News watcher: http://www.backweb.com/, http://www.pointcast.com/ Assistant systems: http://lieber.www.media.mit.edu/people/lieberary/letizia/letizia.mov Cooperation systems: http://www.firefly.com E-Commerce: http.//www.shopfido.com/, http://www.jango.com, http://b5www.berkom.de/ ABROSE/ CyberAgent: http://www.ftp.com/cyberagents/ PYTHIA: http://www.cs.purdue.edu/research/cse/pythia/ Tele-MACS: http://www.agentcom.org/agentcom/ AgentCAC (control for ATM network): http://www.elec.qmw.ac.uk/dai/projects/ agentCAC/ BT Mobile agents for routing: http://www.labs.bt.com/library/papers/ HP ’Ants based routing: http://www-uk.hpl.hp.com/ HP Market based control: http://www.hpl.hp.com/techreports/98/
URLs about projects relating to software agents: • • • • • • •
WebCrawler: http://info.webcrawler.com/mak/projects/robots/robots.html Stanford University: http://logic.stanford.edu/ University of Kaiserslautern: http://www.uni-kl.de/AG-Nehmer/Ara/ Tacoma (Norway/U.S.A.): http://www.cs.uit.no/DOS/Tacoma/ University of Potsdam: http://samuel.cs.uni-potsdam.de/soft/taxt/home.html#mission DFG, Germany: http://www.wirtschaft.tu-ilmenau.de/wi/wi2/ECAT2000-AOSM/ MIT Media Lab: http://agents.www.media.mit.edu/groups/agents/
URLs about software agent related conferences: • • •
Agents 2000: http://www.iiia.csic.es/agents2000/ Canadian workshop: http://www.acs.ucalgary.ca/~wshen/workshop1.htm Overview: http://www.csee.embc.edu/aw/Conferences_and_workshops/index.shtml
24
3 Software Measurement, Evaluation and Controlling 3.1 The Software Measurement and Evaluation Framework The following measurement and evaluation framework addressed to the software product, process and resources was developed at the University of Magdeburg [Dumke 99]. The measurement framework is embedded in some aspects of strategy in the IT area in enterprises and societies which is shown in the following Figure 13.
society enterprise IT area CAME strategy CAME framework CAME tools
Figure 13: Main areas relating to the software measurement and evaluation framework We will describe shortly some essential aspects of this framework and the characteristics of the framework environments. The CAME strategy stands for • Community: the necessity of a group or a team that is motivated and has the knowledge of software measurement to install software metrics. In general, the members of these groups are organised in metrics communities such as our German Interest Group on Software Metrics. • Acceptance: the agreement of the (top) management to install a metrics program in the (IT) business area. This aspects is strong connected with the knowledge about required budgets and personnel resources. • Motivation: the production of measurement and evaluation results in a first metrics application which demonstrates the convincing benefits of the metrics application. This very important aspect can be achieved by the application of essential results in the (world-wide) practice which are easy to understand and should motivate the management. One of the problem of this aspect is the fact that the management wants to obtain one single (quality) number as a summary of all measured characteristics. 25
• Engagement: the acceptance of spending effort to implement the software measurement as a permanent metrics system (with continued measurement, different statistical analysis, metrics set updates etc.). This aspect include also the requirement to dedicate personnel resources such as measurement teams etc. The CAME framework itself consists of the following four phases: • Choice: the selection of metrics based on a special or general measurement view on the kind of measurement and the related measurement goals -- as measurement objects, • Adjustment: the measurement characteristics of the metrics for the specific application field – as attributes of the measurement objects, • Migration: the semantic relations between the metrics along the whole life cycle and along the system architecture – as services of the measurement objects, • Efficiency: the automation level as construction of a tool-based measurement – as implementation of the measurement objects. The phases of this framework will be explained in the following sections including the role of the CAME tools.
3.1.1 Measurement Choice The use of metrics involves the following two essential questions: •
“What is necessary to measure?”
•
“What is possible to measure?”.
Obviously, we only want to measure, what is necessary. But, in most software engineering areas, this aspect is unknown (especially for modern software development paradigms or methodologies such as software agents and multi-agent systems). The first framework step includes the choice of the software metrics and measures from the general software metrics tree which is based on the SQA literature and IEEE or ISO standards and is described in Figure 13. In a first simplification, we consider the general quality aspect as the only empirical criterion. The choice of software metrics or software measures decides about the areas of controlling and the areas out of controlling. Moreover, our framework starts with the investigation of the chosen metrics and assumes an underlying choice method such as •
the general measurement goal planning by [Basili 86] (see also [Wohlin 00]) which consider the different measurement goals as understanding of systems, assessment, proof of hypothesis, understanding of metrics etc.,
•
the goal question metrics (GQM) paradigm [Solingen 99] which is directed on the improvement of a special aspect or component of the software system related to a special goal. 26
Note, both sides in the following Figure 14 should be developed to a standard or should require some kinds of standard definitions.
SOFTWARE METRICS software development component
Product metrics • architecture metrics - component metrics - configuration metrics - data base metrics • run-time metrics - task metrics - data handling metrics - human interface metrics • documentation metrics - manual metrics - development metrics - marketing metrics Process metrics • management metrics - project metrics . - configuration metrics - SQA metrics • life cycle metrics - phases metrics - milestone metrics - workflow metrics • CASE metrics - method metrics - paradigm metrics - tool metrics Resources metrics • personnel metrics - skill metrics - communication metrics - productivity metrics • software metrics - paradigm metrics - performance metrics - replacement metrics • hardware metrics - reliability metrics - performance metrics - availability metrics
measurement view model
model
size structure complexity • • • • • •
empirical criteria
model examples: IEC 300-2 ISO 9126
• • • • • • • • •
IEEE 829
• • • • • • • • •
• • • • • • • • •
McCall ISO 9294
CMM appropriate models
• • • • • • • • •
mapping by thresholds or units
IEEE 730 ISO 12207
quality aspect
ISO 9000
• • • • • • • • •
IEEE 982 ISO 14471
IEEE 1045 • • • • • • • • •
ISO 14598 ISO 9000
• • • • • • • • •
ISO 14756
• • • • • • • • •
IEC 1069
Figure 14: A general software metrics tree The measurement choice step defines the static characteristics of the software measurement process.
3.1.2 Measurement Adjustment The adjustment is related to the experience (expressed in values) of the measured attributes for the evaluation. The adjustment includes the metrics validation and the determination of the metrics algorithm based on the measurement theory. The steps in the measurement adjustment are 27
• the determination of the scale type and (if possible) the unit, • the determination of the favourable values (as thresholds) for the evaluation of the measurement component, e. g. by ∗ discussion or brainstorming in the development or quality team, ∗ analysing and use the examples in the literature, ∗ use of the thresholds of the metrics tools, ∗ taking the results of appropriate case studies, • the tuning of the thresholds as ∗ approximation during the software development from other project components, ∗ application of a metrics tool for a chosen software product that was classified as a ‘good qualitative’ example, • the calibration of the scale (as transformation of the numerical scale part to the empirical) depends on the improvement of the knowledge in the problem domain. Mainly, we consider in the adjustment step the metrics characteristics addressed to the qualitative evaluation (nominal and ordinal scale types) or to the quantitative evaluation (interval or ratio scale types).
3.1.3 Measurement Migration The migration step is addressed to the dynamic aspects of the measurement framework or metrics program. This means that we must install a metrics-based network over the software product, process, and resources components as a measurement process. We ‘migrate’ the idea of metrication to all of the components of the software development and maintenance. Some examples of these kinds of connections for software products are • metrics tracing along the software life cycle, e. g. #notions (problem definition) → #classes (specification) → #new-defined-classes (design) → #implemented-classes (implementation), • metrics refinement along the software life cycle, e. g. informal description of a specified service (text metrics) → PDL description of a service (design metrics) → Java form of a service (code metrics), • metrics granularity related to the architecture, e. g. in an object-oriented development as the system, the class and the method. These characteristics are also given for the process and resources area. Note, that the most existing software measurement approaches or frameworks do not include this step. 28
On the other hand, the metrics set will be expanded by adding the metrics necessary to control all product architecture components, process phases and resource versions. Observing the software metrics as class hierarchy, we can understand the measurement migration as the definition and design of the metrics behavior. Hence, the migration step of the software measurement and evaluation framework determines the measurement areas of understanding, assessing and controlling.
3.1.4 Measurement Efficiency This step includes the instrumentation or the automation of the measurement process by tools. It requires to analyse the algorithmic character of the software metrics and the possibility of the integration of tool-based ‘control cycles’ in the software development or maintenance process. We will call the metrics tools as CAME (Computer Assisted software Measurement and Evaluation) tools [Dumke 96]. In most cases, it is necessary to combine different metrics tools and techniques related to the measurement phases. Technique for the tool-based software measurement are the consideration of attributing, extension, coupling and are addressed to the presentation model (as language, as parameterised component or verbal description). On the other hand, we are also required to integrate such tools related to the software development phases. A special tool descriptions are given in the SMLab URL at http://ivs.cs.uni-magdeburg.de/sw-eng/us/. This CAME tool application also requires a metrics database with a lot of different forms of measurement values and used aspects. The metrics database is the repository of a concrete enterprise-based software measurement and supports the statistical analysis, assessments and controlling information for the managed software development components such as projects, products and resources. The following Table 7 consider the different kinds of database supports for the essential methods of software measurement and evaluation. Measurement and evaluation method Trend analysis Expertise Evaluation
Characteristics of the Metrics Data Collections in general there are not explicit data, mainly formulabased assumptions more general evaluations based on statistical analysis of intuitive assumed metrics data statistical abstraction without any relations to metrics data
Certified assessment
metrics data based evaluations
Periodic assessment
metrics database where are stored empirical data for periodic evaluations metrics database where are stored empirical data for continued evaluations metrics database including delivered measurement data
Continued assessment Empirical-based Estimation Model-based measurement Direct measurement
metrics database where is necessary to apply empirical evaluations for data exploration metrics database with empirical contents implicitly
Table 7: Measurement methods and their kinds of metrics data collections 29
3.2 Related Work in Measurement of Software Agent and Agent-Based Systems We will consider some of the examples about agents measurement in the literature in following. In a first description, we will consider the general experience by [Wooldridge 99] as •
Political pitfalls: “Agents are a powerful, natural metaphor for conceptualizing, designing, and implementing many complex, distributed applications. Some tasks, however, are simply beyond the scope of automation. Indeed, many of the systems that have been built using agent technology could likely have been built just as easily with nonagent techniques. . . . Another form of dogma associated with agents relates to their definition. Most agent developers have their own opinion on exactly what constitutes an agent – and no two developers appear to share exactly the same opinion.”
•
Management pitfalls: Managers “don’t know why you want agents”. . . . “Another common pitfall is devising an architecture or testbed that supposedly enables a whole range of potential systems to be built when what is actually required is a bespoke design to tackle a single application.”
•
Conceptual pitfalls: The developers “believe in silver bullets”, . . . “forgot that agents are software”, and “forgot that agents are multithreaded software.”
•
Analysis and design pitfalls: The designer “ignore related technologies”, . . .their “design doesn’t exploit concurrency”, and it was “ignore legacy”.
•
Agent-level pitfalls: “You want your own agent architecture. . . . Your agents use too much AI” or “Your agents use no AI”.
•
Society-level pitfalls: Typical extreme views are: “You see agents everywhere” or “You have too few agents.” This can leads to “obsessing on infrastructure” and a lack system structure where the “agents interact too freely.”
On the other hand, we will use for the description of agent measurement approaches our metrics tree for classification of these measurement intentions.
Product measurement and evaluation: •
Performance evaluation: [Evans 99] defines some formula to estimate the response time, the time of delay for the notify, delete, create and commit of software agents.
•
Size estimation: [Evans 99] executes the total number of links within a network and within special region boundaries.
30
Process measurement and evaluation: •
Behavior simulation: The MECCA system [Gerber 99] implementes a component to simulate the agents scenarios and interactions.
•
Modelling of agent-based systems: [Falchuk 98] describes twenty icons for the different types of software agents and six types for the kinds of interactions for a better usability of the agent-based system modelling.
•
ACL evaluation: [Singh 98] defines some criteria to evaluate agent communication languages for an appropriate use.
•
Reasonableness of agent deriving: [Joshi 98] defines a measure for the reasonableness to automatically generate exemplars to learn the mapping from a problem to an agent.
Resources measurement and evaluation: •
Middleware evaluation: [Poslad 99] describes a (nominal) evaluation of the middleware aspects in agent-based systems.
•
Vendor evaluation: [Guilfoyle 98] gives an overview about the CASE level of vendors of the agent technology.
•
Paradigm evaluation: [Wong 99] motivates for mobile agent implementation with Java.
In the following section, we will define a sounded software metrics set in order to measure and evaluate the product, process and resources characteristics. Therefore, we must consider the models of agent-based systems relating to their empirical aspects and intentions.
31
4 Measurement of Agent-Based Systems 4.1 Measurement Choice and Empirical Criteria In order to apply software measurement in agent-based software systems, we will start with two first intentions:
1. The measurement and evaluation of the software agents and the agent-based systems,
2. The creation of measurement involved agent-based systems to observe or control such kinds of software systems.
The first approach includes the software metrics related to the used implementation language, tools and methods on the measurement side. The main empirical aspects are given in the second section in this paper which are related to the different (new) characteristics of software agents and agent-based systems.
The second approach would be the full realisation of the migration step of our measurement framework. The metrics or measurement points are implemented in the agents or agents environment and can help to analyse or control such systems.
Mainly, we can apply most of the object-oriented software metrics for code (product) evaluation and in a special manner for process evaluation also. For the extended aspects of software agents related to the objects, we must define new kinds of metrics which are addressed to distributed and semantic aspects of software agents. Because of the “classical” system platform for implementing agent-based systems currently, we can also use “classical” metrics and kinds of measurement to evaluate the resources of software agent-based systems.
Hence, we define in verbal form the following set of metrics considering our general metrics tree in Figure 14 which consider the differences between an agent and a multi-agent system. On the other hand, we should involve all the general aspects of kinds of software agents and their facilities, interactions and intentions. Note, that the metrics-based analysis of the agent behaviour is one of the new and extended areas in software measurement of agent-based systems. The metrics set is described in the following Table 8.
32
Product Metrics Software Agents
Agent-based Systems
Agent design level:
System design level:
½
½
½
½ ½
Software agent size: the size considers both aspects of an agent: the functional size and the physical size of a software agent Software agent component structure: the structure depends on the kind of the agent (intelligent, reactive, deliberative etc.), the agent interface is related to the kind of agent coupling (as fixed, variable or evolutionary)
½
Software agent complexity: the complexity is divided in the computational and psychological complexity and should be measured on both concrete aspects
½
Software agent functionality: this aspect considers the appropriateness of the agent compared to the requirements
½
Agent system size: the measured system size includes the potential number of (active) agents and their contents; on the other hand, the size is related to the environment Agent system component structure: this metric includes agent hierarchies vs. egalitarian, the degree of parallelism, the kinds of organisational functions (representational, organisational, conative, interactional, productive, preservative) Agent system complexity: one of this measured aspects leads to the degree of the organisational dimensions (social, relational, physical, environmental, personal) Agent system functionality: this metric considers the realisation of all of the functional system requirements
Agent description level:
System description level:
½
½
½ ½
Software agent development description level: it considers the completeness of the development documentation (including tests and change supports) Software agent application description level: the metric includes the quality (readability, completeness, online support etc.) of the user documentation Software agent publication description level: this metric considers the public relations for using the software agent and involves the system description
½ ½
Agent system development description level: this metric considers the integration of the agent concepts and dynamics and their sufficient documentation Agent system application description level: it considers the user documentation of all aspects of the system applications related to the different user categories Agent system publication description level: publication metrics evaluate the user acceptance and marketing aspects of the agent-based system application
Agent working level: System working level: ½ Software agent communication level: consi- ½ Agent system communication level: as number of dering of the size of communication and the ACLs between the different kinds of software level of the conversation required to sustain the agents and their different roles and actions activities ½ Software agent interaction level: this metric is ½ Agent system interaction level: it considers the related to the agent context and environment average types of interactions relating to the agents and their different kinds of actions (as and their roles in the environment of the agenttransformation, reflecting, executing, modificabased system tion, commands, perception, deliberation) ½ Agent system knowledge level: it measures the ½ Software agent learning level: this metric results of agent learning for agent-based system evaluates the skills, intentions and actions of (based on the different kinds of agents (as extending the agent facilities itself tropistic and hysteretic agents))
½
Software agent adaptation level: the adaptation metric considers facilities of agent changing in order to react on new conditions in the environment
½
33
Agent system lifeness level: this metric is based on the agent adaptation which keeps the adaptation level of the whole agent-based system
½
½ ½ ½ ½ ½ ½
Software agent negotiation level: the measuring is directed on the evaluation of the facilities like the agent intentions, conflict resolution, and realised commitments for successful negotiations Software agent collaboration level: this metric is oriented to the agent facility to work together with other agents Software agent coordination level: the agent facility of managing any one agent tasks is considered Software agent cooperation level: this metrics consider the volume and efficiency of an agent relating to a common task Software agent self-reproduction level: the number of destroyed agents related to repaired agents is counted Software agent performance level: this metrics consider the task related performance of an agent Software agent specialisation level: the metric consider the degree of specialisation and the degree of redundancy of an agent
½
½ ½ ½ ½ ½ ½
Agent system conflict management level: the system success is based on the agent negotiation and consider the relations between the different kinds of a fair play in the realisation of the system tasks Agent system community level: it considers the level of different agent communities based on the agent collaboration Agent system management level: this system metric is based on the agent coordination level related to the whole agent system structure Agent system application level: this metric is related to the application area and the different agent roles in their cooperation Agent system stability level: the stability measure is based on the agent self-reproduction Agent system performance level: the handling with object to realise special tasks through the different agents is considered Agent system organisation level: the different agents roles (as archivist, customer, mediator, planner, decision-maker, observer, communicator) are considered
Process Metrics Software Agents
Agent-based Systems
Agent development life cycle:
System development life cycle:
½
½
½ ½
Software agent phases level: the metrics characteristics (size, structure, complexity) in the different development phases is considered Software agent milestones level: this metric defines the phase level to a special date of control Agent requirements workflow level: this metric considers the part of the implemented requirements during the development phases
½ ½
Agent system phases level: this evaluation consider the system metrics of size, structure and complexity during the system development Agent system milestones level: the realisation of a sufficient phase level at a special control date is considered System requirements workflow level: the requirements implementation during the development phases in the whole system is considered
Agent development method level:
System development method level:
½
½
½ ½
Software agent methodology level: the level of the used development method is quantified Software agent paradigm level: this metric evaluates the appropriateness of the chosen development paradigm
½
Software agent CASE level: this metric quantifies the tool support for the agent implementation
½
34
Agent system methodology level: this metric includes the development method level for the whole agent-based system Agent system paradigm level: the paradigm appropriateness for the system development is considered Agent system CASE level: the tool support for system development to evaluate the CASE level is considered
Agent development management level:
System development management level:
½
½
½ ½
Agent project management level: this set of metrics considers the management level of the development risks and methods Agent configuration management level: it considers the successfulness of the version control related to an agent Agent quality management level: this set of metrics considers the quality assurance techniques related to an agent
½ ½
System project management level the management level of the development risks and methods of the system is considered System configuration management level: this metrics includes the evaluation of the system configurations involving the dynamic aspects System quality management level: the quality assurance techniques related to whole agent-based system is considered
Resources Metrics Software Agents
Agent-based Systems
Agent developer level:
System developer level:
½
½
½ ½
Agent developer skill level: this evaluation is related to the skills to develop and implement an software agent Agent developer communication level: the ability of the developer to improve his work by collaboration and cooperation is considered Agent developer productivity level: this metric evaluates the quantity of work
½ ½
System developer skill level: this metric is based on the agent developer skills and is extended by the (dynamic) system characteristics System developer communication level: this set of metrics considers the ability of the developer(s) to improve his work by collaboration and cooperation System developer productivity level: the quantity of work is considered
Agent software resources level:
System software resources level:
½
½
½ ½
Agent software paradigm level: this metric evaluates the appropriateness of the chosen software basis and used software components for the implementation of an software agent Agent software performance level: this metric is addressed to the software components and their effectiveness Agent software replacement level: this metric considers the effort of adaptation to the different versions of the basic software
½
System software paradigm level: the appropriateness of the chosen software basis and used COTS for the implementation of the agentbased system is evaluated System software performance level: this metric consider the evaluation of the efficiency of the involved software basis and the used (external) components
½
Agent hardware resources level:
System software replacement level: the adaptation to the different versions of the kinds of basic software is considered System hardware resources level:
½
½
½ ½
Agent hardware reliability level: this metrics considers the reliability of the types of hardware required for running the software agent Agent hardware performance level: this set of metrics considers the platforms used for an agent Agent hardware availability level: the average availability of the different platforms used from an (mobile) agent is considered
½ ½
System hardware reliability level: the reliability of the kinds of hardware for running the agentbased system is considered System hardware performance level: this set of metrics considers the used platforms for an agentbased system System hardware availability level: the average availability of the different platforms used from the agent-based system is considered
Table 8: Verbal description of the metrics for agent-based systems 35
4.2 Measurement Areas of Adjusted Metrics The characteristics of the chosen metrics are depended of the empirical criteria. We can establish mainly ordinal scaled metrics in the object-oriented system development. In order to improve the measurement as a quantified evaluation, we must realise special experiments to keep some ratio scaled characteristics in a concrete kind of agent-based system implementation. On the other hand, the number of available metrics threshold values is low now and requires more analysis and investigations. Therefore, we describe the empirical criteria at first in a general manner in the following Table 9. Empirical Criteria of the Product Metrics Software Agents
Agent-based Systems
Agent design level:
System design level:
½
½
½ ½ ½
Software agent size: a large agent size can cause a low performance and mobility Software agent component structure: the structure does affect the changeability
½
Software agent complexity: a high computational complexity leads to a weak performance
½
Software agent functionality: a high functionality can injure the chosen object-oriented implementation paradigm
½
Agent system size: a small agent system size can reduce the application area Agent system component structure: the system structure relates to the performance and the system changeability Agent system complexity: this aspect influences the system applicability Agent system functionality: the distribution of the functionality in the system components decide about their flexibility
Agent description level:
System description level:
½
½
½ ½
Software agent development description level: the description level determines the maintainability of an agent Software agent application description level: this evaluation considers the usability of an software agent Software agent publication description level: a high publication level supports the spreading of the agent use
½ ½
Agent system development description level: the system description affects of system maintenance Agent system application description level: a good application description is a precondition for an efficient use of the whole system Agent system publication description level: a good system publication supports the spreading especially in the educational area
Agent working level:
System working level:
½
½
½ ½
Software agent communication level: a high communication intensity can affect a flexible application Software agent interaction level: this aspects expresses the activity of an agent Software agent learning level: this level is based on the type of agent and his roles in the system
½ ½
36
Agent system communication level: this level characterises the intensity of the conversations and is describing the agent collaboration Agent system interaction level: many interactions are based on a high cooperation Agent system knowledge level: this aspect determines the knowledge-based foundation of the agent-based system
½ ½ ½ ½ ½ ½ ½ ½
Software agent adaptation level: the facility of adaptation determines the stability of the agent implementation Software agent negotiation level: this level determines the success of an agent activity relating to common tasks Software agent collaboration level: a high collaboration of an agent classify his roles in the given tasks Software agent coordination level: a high level determines the role of the agent in an administration hierarchy Software agent cooperation level: this level determines the effectiveness of common tasks realisation Software agent self-reproduction level: this level determines the stability of an software agent itself Software agent performance level: a high agent performance is related to all kinds of agent activities Software agent specialisation level: a high specialisation can lead to a high performance
½ ½ ½ ½ ½ ½ ½ ½
Agent system lifeness level: this aspects is based on the adaptability of the agents and characterises the system maintenance effort Agent system conflict management level: a high conflict management level leads to a high system stability Agent system community level: a high community level is caused on collaboration for different classes of system application Agent system management level: a high management level expresses a good agent organisation level Agent system application level: a high application level is caused in an effective taskoriented agent cooperation Agent system stability level: a high stability level includes the agent self-reproduction and other system error handling facilities Agent system performance level: this level includes the agent performance and the performance of the environment Agent system organisation level: this level leads to an efficient distribution of the agent roles and their administration
Empirical Criteria of the Process Metrics Software Agents
Agent-based Systems
Agent development life cycle:
System development life cycle:
½
½
½ ½
Software agent phases level: a high phase level is expressed by a high level of verification
Software agent milestones level: this level expresses the correct timing of the agent development Agent requirements workflow level: this level is caused by the timely realisation of the requirements for the agent implementation
½ ½
Agent system phases level: this level is caused by the appropriate development results for an efficient system realisation Agent system milestones level: this level is related to all development aspects in the planning time of their realisation System requirements workflow level: a high workflow level evaluates the appropriateness of the realised system requirements
Agent development method level:
System development method level:
½
½
½ ½
Software agent methodology level: this level means that the development method should be adequate to the kind of agent implementation Software agent paradigm level: a high paradigm level is caused by an appropriate choice of the implementation technique Software agent CASE level: this level expressed the tool-support during the agent development
½ ½
37
Agent system methodology level: a high methodology level expresses the use of appropriate development techniques Agent system paradigm level: this level determines the appropriateness of the chosen techniques for the system implementation Agent system CASE level: this level includes the set of different tools in order to support the system development
Agent development management level:
System development management level:
½
½
½ ½
Agent project management level: a high management level is involved in the system project management Agent configuration management level: this level expressed the quality of version control for the software agent Agent quality management level: this level expresses the used quality assurance techniques related to the agent development
½ ½
System project management level: this level describes the timing and the appropriate use of resources for the system development System configuration management level: this level is caused by a version control for all parts of the agent-based system System quality management level: this level includes the different quality assurance techniques
Empirical Criteria of the Resources Metrics Software Agents
Agent-based Systems
Agent developer level:
System developer level:
½
½
½ ½
Agent developer skill level: a high skill level expresses a good developer specialisation for agent implementation Agent developer communication level: the communication is an indicator for an efficient resolving of any questions Agent developer productivity level: a high productivity includes the functionality and the quality of the software agent
½ ½
System developer skill level: this level includes different kinds of knowledge to develop the different components of the agent-based system System developer communication level: a high communication level is based on the successful participate design techniques System developer productivity level: this level is related to the development of the different system components
Agent software resources level:
System software resources level:
½
½
½ ½
Agent software paradigm level: this level keeps the appropriateness of the chosen paradigm Agent software performance level: this level is a precondition for the agent performance itself and is related to the used system software Agent software replacement level: a high replacement level keeps a good level of agent maintenance and migration
½ ½
System software paradigm level: this level is divided for the different system components System software performance level: a high performance level of the used COTS determines the system performance System software replacement level: this level is divided in the evaluation of the different components of the agent-based system
Agent hardware resources level:
System hardware resources level:
½
½
½ ½
Agent hardware reliability level: this level includes the different platforms which will be used by a mobile agent Agent hardware performance level: this level considers also the potential types of platforms Agent hardware availability level: a high availability level is a precondition for the mobility of an agent
½ ½
System hardware reliability level: this level includes all platforms of the implemented environment of the agent-based system System hardware performance level: this level is a basis for the efficiency of the agent-based system System hardware availability level: this level expresses the stability of the system use
Table 9: Empirical criteria of the metrics for agent-based systems
38
4.3 Kinds of Measurement Migration in Agent-Based Systems The migration step connects the measurement and evaluation points to a whole measurement and evaluation system. In order to realise a product evaluation of agent-based systems, we should make the following steps:
1. The refinement of the agent metrics and the design of their implementation, 2. The definition or scaling of the agent-based systems metrics and the design of their implementation. 3. The definition of the different parts of assessments or controlling.
The migration step can require a reconsideration of the new defined (refined) metrics. In such a way, we obtain a concept of the agent-based system evaluation. Because of dependence of the concrete implementation paradigm, we will not consider this aspect in this paper.
4.4 Tool Support and Measurement Integration This step includes the implementation of the derived metrics and their exploration concept and is divided in:
1. The changing or extension of the agents and their environment for implementation of the software metrics. This aspects includes the essential problem of the measurement overhead. 2. The application or modification of measurement tools or components for the implementation of the measurement and evaluation facilities.
Realising the four framework steps, we have installed the measurement and evaluation of software agents and agent-based systems for a special kind of resources, applications and implementation.
39
5 Software Aglets as Self-Measuring Agent-Based System Software Aglets are a special kind of software agents based on the Java implementation. The term “aglet” is derived from a combination of the notions agent and (Java) applets [Lange 98]. Aglets can be implemented by the IBM’s Aglets Software Development Kit (ASDK) which is based on the main component – the Tahiti Aglet server. In order to implement mobile agents, the aglets have the following fundamental operations: •
Creation: The creation of an aglet takes place in an context.
•
Cloning: The cloning of an aglet produces an almost identical copy of the original aglet in the same context.
•
Dispatching: Dispatching an aglet from one context to another will remove it from its durrent context and insert it into the destination context.
•
Retraction: The retraction of an aglet will pull (remove) it from its current context and insert it into the context from which the retraction was requested.
•
Activation and deactivation: The deactivation of an aglet is the ability to temporarily halt its execution.
•
Disposal: The disposal of an aglet will halt its current execution and remove it from its current context.
An overview about the interactions of these aglet functions is given in the following Figure 15. Context A clone
Context B dispatch
Aglet
retract
dispose Aglet
create
secondary storage
Class
Figure 15: The aglet life-cycle model
In the following, we will detail some aspects of agent measurement and show these aspects in a simple example of metrics application. 40
5.2 Measuring Aspects Aglets are mobile agents. Therefore, we can apply measurement and evaluation of their behavior in an agent-based system. In our example, we will consider a simple analysis of the routing or travelling of a special aglet in a LAN environment. The forms of agent measurement which are implemented are
½ ½ ½
the controlling of the active software agents in a special place by a measurement agent itself by counting their current lines of codes (LOC), the pursuing of the agent travelling of the different places in the agent-based system environment by a navigation agent, the observing of the agent places by a visitor agent which displays some local information in a nominal manner,
In the next section we will describe some of the screens in acting these three examples of the agent measurement.
5.3 Examples of Measurement Implementation The first screen shot in Figure 16 shows the creation of the measurement aglet as an aglet which perform the LOC of the java classes.
Figure 16: The creation of the measurement aglet
In the next figure shows the measurement results by counting the LOC of the different classes in the different agent places (apollo, poseidon, anubis).
41
Figure 17: The measured results of the measurement aglet The next screen shot in Figure 18 shows the background information about the possible agent places or ‘cities’ for the travelling of a navigation aglet.
Figure 18: The information basis of the navigation aglet 42
The next figure presents the order of the visited places in the local network by the navigation aglet.
Figure 19: Protocol of the navigation aglet after the travelling Finally, we will show some of the extended knowledge by storage of the host information in the visitor aglet which are presented from two of the hosts in Figure 20.
Figure 20: Travel report of the aglet from the visited hosts This example only intimate the intentions of measurement of agent-based systems and is directed on the agent behavior evaluation.
43
References [Basili 86] Basili, V. R. et al.: Experimentation in Software Engineering. IEEE Transactions on Software Engineering, 12(1986)7, pp. 733-743 [Brenner 98] Brenner, W. et al.: Intelligente Softwareagenten – Grundlagen und Anwendungen. Springer Publ., 1998 [Busuioc 99] Busuioc, M. N.: Distributed Intelligent Agents – A solution for the Management of Complex Telecommunications Services. In [Hayzelden 99, pp. 112-129] [Darbyshire 00] Darbyshire, P.; Lowry, G.: An Overview of Agent Technology and its Application to Subject Management. Proc. of the IRMA International Conference, Anchorage, Alaska, May 21-24, 2000, pp. 509-512 [Dumke 99] Dumke, R.R.: A Framework for Software Measurement Evaluation. Proc. of the International Workshop on Software Measurement (IWSM99), Lac Superieur, Quebec, Canada, September 8-10, 1999, pp. 24-37 [Dumke 96] Dumke, R.; Foltin, E.; Koeppe, R.; Winkler, A.: Softwarequalität durch Meßtools. Vieweg Publ., 1996 [Evans 99] Evans, R. et al.: A Multi-Agent System Architecture for Scalable Management of High Performance Networks: Applying Arms Length Autonomy. In [Hayzelden 99, pp. 86-111] [Falchuk 98] Falchuk, B.; Karmouch, A.: Visual Modeling for Agent-Based Applications. IEEE Computer, December 1998, pp. 31-38 [Ferber 99] Ferber, J.: Multi-Agent Systems – An Introduction to Distributed Artificial Intelligence. Addison Wesley Publ., 1999 [Gerber 99] Gerber, C. et al.: Resource Adaptation for a Scalable Agent Society in the MoTiV-PTA Domain. In [Hayzelden 99, pp. 183-206] [Guilfoyle 98] Guilfoyle, C.: Vendors of Intelligent Agent Technologies: A Market Overview. In [Jennings 98, pp. 91-104] [Hayzelden 99] Hayzelden, A.L.G.; Bigham, J.: Software Agents for Future Communication Systems. Springer Publ., 1999 [Jennings 98] Jennings, N. R.; Wooldridge, M. J.: Agent Technology – Foundation, Applications, and Markets. Springer Publ., 1998 [Joshi 98] Joshi, A.; et al.: Multiagent system support of networked scientific computing. Internet Computing, May/June 1998, pp. 69-83 [Lange 98] Lange, D. B.; Oshima, M.: Programming and Developing Java Mobile Agents with Aglets. AddisonWesley Publ., 1998 [Maes 94] Maes, P.: Agents that Reduce Work and Information Overload. CACM, 37/1994)7, pp. 84-86 [Nwana 98] Nwana, H. S.; Ndumu, D. T.: A Brief Introduction to Software Agent Technology. In: [Jennings 98], pp. 29-47 [Poslad 99] Poslad, S. et al.: Agent-Oriented Middleware for Integrating Customer Network Services. In [Hayzelden 99, pp. 221-246] [Schoder 00] Schoder, D.; Eymann, T.: The Real Challenges of Mobile Agents. Comm. Of the ACM, 43(2000)6, pp. 111-112 [Sewell 99] Sewell, P. et al.: Location-Independent Communication for Mobile Agents: A Two-Level Architecture. In: Bal/Cardelli: Internet Programming Languages. LNCS 1686, Springer Publ., 1999, pp. 1-31 [Singh 98] Singh, M. P.: Agent Communication Languages: Rethinking the Principles. IEEE Computer, , Dec. 1998, pp. 40-47 [Solingen 99] Solingen, v. R.; Berghout, E.: The Goal/Question/Metric Method. McGraw Hill Publ., 1999 [Wohlin 00] Wohlin, C. et al.: Experimentation in Software Engineering: An Introduction. Kluwer Academic Publ., 2000 [Wong 99] Wong, D.: et al.: Java-Based Mobile Agents. CACM, 42(1999)3, pp. 92-105 [Wooldridge 99] Wooldridge, M. J.; Jennings, N. R.: Software Engineering with Agents: Pitfalls and Pratfalls. Internet Computing, May/June 1999, pp. 20-27
44
