Testing in Prometheus Methodology – Plan Oriented Approach

(1)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459,ISO 9001:2008 Certified Journal, Volume 3, Issue 1, January 2013)

657

Testing in Prometheus Methodology – Plan Oriented Approach

N.Sivakumar

1

, K.Vivekanandan

2

, M.Kanimozhi

3

Department of Computer Science and Engineering, Pondicherry Engineering College, Puducherry, INDIA Abstract— Agent Orientation is emerging as a dominant

research area and also prevails as a new paradigm for constructing complex distributed system. Agents provide designers/developers with a way of structuring applications around autonomous, communicative elements. Thus, Agent Oriented Software Engineering (AOSE) is concerned with the use of agents in the development of complex distributed systems, especially in open and dynamic environments. Several AOSE methodologies were developed for specifying and designing agent system. Prometheus is a practical AOSE methodology that aims to provide everything that is needed to specify and design agent systems. Existing AOSE methodologies including Prometheus doesn’t provide enough support for testing and that becomes one of the most fundamental obstacles to large-scale take-up of agent technology in industrial practice. This paper aims at evaluating the lifecycle coverage of Prometheus and also explores the scope for testing the system that has been analyzed and designed using Prometheus.

Keywords—Software Agents, Agent Oriented Software Engineering Methodology, Plan Oriented Testing.

I. INTRODUCTION

A software agent is simply another kind of software abstraction [1]. An object is a high-level abstraction that describes methods and attributes of a software component. An agent, however, is an extremely high level software abstraction which provides a convenient and powerful way to describe a complex software entity. Rather than being defined in terms of methods and attributes, an agent is defined in terms of its behavior. There is a minimum set of common features that typify a software agent [4]. A software agent is autonomous; the agent is capable of operating as a standalone process and performing actions without user intervention. A software agent is communicative; it communicates with the user, other software agents, or other software processes. A software agent is perceptive; it is able to perceive and respond to changes in its environment.

Agents provide a new way of managing complexity because they provide a new way of describing a complex system or process. Agents are well-suited for use in applications that involve distributed computation or communication between components [4].

(2)

International Journal of Emerging Technology and Advanced Engineering

658 II. PROMETHEUS BACKGROUND

A key issue in getting the agent technology into the mainstream of software development is the development of appropriate methodologies for agent oriented software [14]. Prometheus is a general purpose methodology for

designing agents and developing multi-agent systems [6]. It differs from existing methodologies in such a way that it

focuses on the development of intelligence. It supports

software engineering activities from requirements speciﬁcation to detailed design and implementation. The goal in developing Prometheus is to have a process with defined deliverables [8], which can be taught to industry practitioners and undergraduate students who do not have a background in agents, and which they can use to develop intelligent agent systems.It is intended to be able to support the design of BDI systems [13].

The Prometheus methodology consists of three phases

 System Specification

This phase focuses on identifying the basic functionalities of the system, along with inputs (percepts), outputs (actions) and any important shared data sources.

The system‘s interface to its environment is described in terms of actions, percepts, and external data.

 Architectural design

This phase uses the outputs from the previous phase to determine which agents the system will contain and how they will interact. The system‘s overall structure is captured in a system overview diagram and use case scenarios are developed into interaction protocols.

 Detailed design

This phase looks at the internals of each agent and how it will accomplish its tasks within the overall system.

Process diagrams are used as a stepping stone between interaction protocols and plans.

A. System Specification.

System specification defines the requirements of the system in terms of

 The goals of the system

 Use case scenarios

 Functionalities

 The interface of the system to its environment,

defined in terms of actions and percepts.

1) System goals.

The goals of the system are a natural starting point for developing use case scenarios. The process for capturing

the goals of the system beginsby capturing an initial set of

goals from the high-level system description [9]. These initial goals are then developed into a more complete set of goals by considering each goal and asking how that goal could be achieved thus identifying additional sub goals. This identification of sub goals continues until further sub goals cannot be identified. Goals are represented using Goal diagram.

2) Functionalities.

The functionality is a coherent chunk of behavior

provided by the system. When functionality is being defined it is also important to define information required

by it which is specified using functionality descriptor. The

functionality descriptor contains a name, a short natural language description, a list of actions, a list of relevant percepts, data used, a brief description of interactions with other functionalities and triggers.

3) Use Case Scenarios.

Use case scenarios are detailed description of one

particular sequence of events associated with achieving a

particular goal or with responding to a particular event.

Scenarios are described using a name, description, and a triggering event.

4) System Interface: Actions and Percepts.

(3)

International Journal of Emerging Technology and Advanced Engineering

[image:3.612.89.518.145.429.2]

659

Figure 1 Prometheus Methodology

B. Architectural Design.

The major focus in architectural design is to find out the agent types in the system [6]. Once agent types are decided, identify which agents react to which percepts or environmental events, as well as which agents perform particular actions on the external environment. Architectural design phase focuses on.

 Deciding on the agent types in the system-agent types

is identified and functionalities are assigned to it. These are explored using Data Coupling diagram and Agent Acquaintance diagram [5].

 Describing the interactions between agents- the

timing of communication is depicted in the Interaction diagram and Interaction protocol [5] which shows message passing and sequence of messages between agents.



Designing the overall system structure-different

messages that are sent between agents is specified in system overview diagram [5]. The system overview diagram shows the pathways of communication but not the timing of communication.

C. Detailed Design.

In thedetail designphase, the internals of each agent and how it will accomplish its task within the overall system are addressed. It focuses on deﬁning capabilities, internal events, plans and detailed data structure for each agent type.

Detailed design phase consists of:

 Developing the internals of agents, in terms of

capabilities is done using Agent Overview diagram and Capability Descriptors. The former shows

interactions between capabilities within an agent, rather than between agents within a system [7] while the latter contains information such as which events are generated and which events are received.

 Developing the details of capabilities in terms of other

capabilities as wellas in terms of events, plans, and

data. This is done using capability overviewdiagrams

and various descriptors such as individual plan

descriptors, event descriptors and data descriptors. Scenarios System goals Initial Functionality Descriptors Actions, percepts Interaction diagrams Agent acquaintance Data coupling

Messages Shared data

Protocols System

Overview

Process Agent

overview Capability overview Event descriptors Data

descriptors Plan descriptors Agent descriptors

(4)

International Journal of Emerging Technology and Advanced Engineering

660 III. EVALUATING THE LIFECYCLE COVERAGE OF

PROMETHEUS

The set of guidelines for covering the whole lifecycle of system development is called a methodology. The elements of software development that are dealt within the methodology are specified by Lifecycle coverage. These elements are possessed by all methodologies that are useful in several stages of the development lifecycle such as requirement gathering, analysis, design, implementation, and testing. In order to evaluate methodology, lifecycle coverage is an important criterion because a detailed description of the activities included in the development lifecycle would enhance the appropriate use of a methodology and increase its acceptability as a well-formed engineering approach.

Software testing is an important activity in software development in order to ensure the correctness of software. However, testing is often disregarded in most agent oriented methodologies because it mainly focuses on analysis and design activities and considered that implementation and testing issues can be performed using traditional techniques. The same way, Prometheus methodology also covers only analysis and design stage within the development lifecycle. When it comes to implementation, JDE (JACK Development Environment) and PDT (Prometheus Design Tool) tools are used. PDT provides an option to the developer to automatically generate JACK skeleton java code. The testing stage is not at all covered by Prometheus. Because multi-agent systems implementation has some features that make it distinctive from traditional software. Since agent has some peculiar properties like autonomy, reactiveness, pro-activeness and social ability, it is not possible to test agent oriented systems using OO testing because objects communicate by method invocation whereas agents communicate by means of message passing. So unique testing strategies should be developed in order to test the agent oriented methodologies (Prometheus) [7] since agents possess peculiar properties like reactivity, autonomous, proactivity, responsiveness, collaborative, etc.which are not possessed by objects.

IV. PROPOSED WORK.

Prometheus methodology can be termed as a Plan-Oriented (PO) methodology as plan is used as the main abstraction of MAS analysis and design. In order to incorporate testing phase in Prometheus methodology, plan-oriented testing technique will be more appropriate. The main objective of this paper is to explore the scope for testing phase in Prometheus methodology using mental attribute named plan.

A. Plan Oriented Testing

The design of each agent is, usually, in terms of capabilities. Capabilities are a structuring mechanism akin to modules. A capability can contain plans, data, and events. It can also contain other capabilities allowing for a hierarchical structure. In Prometheus, an agent type is formed by combining one or more functionalities. When considering a grouping of functionalities, if two functionalities are clearly related, then it might make sense to group them together in the same agent type. Eventually the design of how each agent achieves its goals is expressed in terms of plans, events, and data. Thus the final part of detailed design phase develops data, events, and plans. Developing the internal structure of an agent is done

using a refinement process that begins with the interface of

the agent: the data that it reads and writes, the incoming and outgoing messages, the percepts it receives, and actions it performs. Then, for each part of the agent‘s interface, we consider to what capability or plan it connects. In addition to connecting the interface of the agent to internal plans and/or capabilities, additional internal messages and data

are introduced as needed. There is a concept of an event

which triggers selection of one of some number of identified plans, depending on the situation. If one of these plans is actually never used, then this is likely to indicate an error. The concepts of event and plan, and the relationships between them are part of typical agent designs, and can thus be used for model based testing of agent systems. A plan in its simplest form consists of a

triggering event, a context condition, which determines the applicabilityof the plan with respect to the agent‘s beliefs about the current state of the world, and a plan body which outlines a sequence of steps that are the basic elements to achieve an agent‘s goal which can be defined as an abstract description of an agent‘s expected function. Plan can be identified in the system using a Goal oriented approach. Thus the basic units of testing are the plans and the events. An agent may consist of plans, eventsand belief-sets, some of which may be encapsulated into capabilities. Percepts and messages are treated as events in agent development systems. Percepts and incoming messages are inputs to the agent, while actions and outgoing messages are outputs from the agent. Plans are triggered by events. An event may be handled by more than one plan, and plans may generate events that trigger other plans either in sequence or in parallel and so on. The order in which the plans should be tested can also be due to the dependencies in the plan structure. For example, in Figure 2 the success of plan

(5)

International Journal of Emerging Technology and Advanced Engineering

661 For example, there is a cyclic dependency between plans

[image:5.612.83.215.201.300.2]

P0, P2 and P1. In this special case we cannot test each plan individually as they are dependent on each other. Hence, such plans are considered as a single unit which we shall term cyclic plans.

Figure 2.Plan dependencies

For events, the information should be identified that is to be carried by the event. For example, a request to schedule a meeting would include information on who should attend the meeting, the priority of the meeting and perhaps what date is desired. For each plan we identify its trigger (what event causes the plan to run) and the plan‘s context condition and then develop the plan‘s body. The plan‘s context condition specifies the situations in which it is appropriate to use the plan. The plan‘s body describes how the plan operates and is often a sequence of steps which include sub goals. An event can trigger multiple plans. For a given event, if there always be at least one plan that is handled and also applicable, then we say that the event is covered. This is important because an uncovered event will fail to be handled. Where there is a plan with a context condition that is always true, then the event is trivially covered. In other situations, coverage can be checked by considering the context conditions of the set of a plan that handles the event type in question. If a given event might have more than one applicable plan, then there is overlap.

In order to achieve a system goal, Multi-agent system (MAS) is composed of more than one agent that works in a coordinated way. Every agents involved in the MAS in turn will have its own individual goal, sometimes more than one goal too.

Goals can be transformed into plan in a one-to-one or one-to-many mapping (i.e.) each goal is mapped to a plan or each goal can be mapped to more than one plan. In an exceptional scenario, more than one similar goal can also be mapped to a single plan.

V. CASE STUDY:MEETING SCHEDULER SYSTEM

In order to quickly understand the Prometheus methodology, let us consider meeting scheduler system as a running example. The description of the system is as follows,

―The calendar system supports the scheduling, rescheduling, and cancellation of meetings involving users. When a meeting is requested with certain users the system attempts to find a suitable time. Finding such a time may fail, or may require that existing meetings are moved automatically, or may create a double booking for certain users that must be manually resolved. Each user has his or her own application instance with which he or she interacts. These applications can contain multiple agents that interact with the applications of other users to coordinate and schedule meetings. In scheduling meetings, some users may be essential to the meeting and others may not be essential. If an essential user pulls out of a meeting after it is set, then the meeting needs to be rescheduled. Setting or rescheduling meetings may be impossible without changing existing meetings. When doing this, care should be taken to avoid creating a ―cascade‖ where, in order to schedule meeting A, meeting B is moved, which creates a clash with meeting C, which is moved creating a clash with D, and so on. Some possibilities for dealing with this situation include:

(a) Assigning priorities to meetings

(b) Using the heuristic that when a clash is created, only a meeting with fewer users will be moved.

The system should allow users to nominate when they are available and should also allow for certain constraints to be specified, such as only scheduling a maximum of 4 hours of meetings on a certain or, more generally, only scheduling N hours of meetings in a certain time period.‖ Now let us discuss the analysis and design framework for Prometheus methodology.

Figure 3.Event trigger

P0

P3

P2

P1

Select meeting

venue

Decide a

Date

Number of

persons

attending

(6)

International Journal of Emerging Technology and Advanced Engineering

662

System Specification

System Goals

The initial goals are then developed into a more complete set of goals by considering each goal and asking

how that goal could be achieved which identifies additional

sub goals. The revised set of goals and sub goals are as follows,

 manage meetings

 (re)schedule meetings

 find meeting time

propose time meeting user

preferences



negotiate with other users

 cancel meeting

 determine essential participants



update essential participants

 manage user availability

 update available times



update preferences

 track contacts

 update contact

 add contact



retrieve contact details

 communicate with other users



interact with user

 remind user of meeting

 learn user preferences

Functionalities

The functionalities for meeting scheduler system: Meeting Manager-Manages meeting information Meeting Scheduler-Schedules meeting subject

Negotiator- Negotiates with other users to determine meeting times.

Contact Manager -managing contact

Contact Notify- communicating with other users. User Interaction -Interacts with the user

User Notify- Reminds user of events.

User Information Manager-Manages information about the user.

Use Case Scenarios

Use case scenarios (sometimes abbreviated to

―scenarios‖) are a detailed description of one particular example sequence of events associated with achieving a particular goal or with responding to a particular event. Scenarios are described using a name, description, and a triggering event.

(7)

International Journal of Emerging Technology and Advanced Engineering

[image:7.612.128.483.138.401.2]

663

Figure 4 Goal Diagram

System Interface: Actions and Percepts

In the case study, the system interacts with the user (and with other users) and so the percepts correspond to different requests from the user. Actions correspond to sending information back to the user (or other users) and reminding users of meetings.

Architectural Design

The architectural design mainly focus on deciding agent types in the system, describing interactions between agent and designing overall system structure. The different types of agent for meeting scheduler system is as follows,

User Interface- Combining the functionalities of User Interaction and User Notify.

Contact Tracker- Combining the functionalities of Contact Manager and Contact Notify.

Meetings agent- Combining the functionalities of Meeting Scheduler, Meeting Manager, Negotiator, and Contact Notify.

User Manager- Combining the User Monitor and User Information Manager functionalities.

One technique that is used to systematically examine the properties which lead to coupling is the data coupling diagram (Figure 5) which consists of the functionalities and all identified data.

Once the agent types are identified for the system, communication pathways between them have to be

specified which is done using Agent acquaintance diagram

(Figure 6). Agent acquaintance diagram depicts

(8)

International Journal of Emerging Technology and Advanced Engineering

[image:8.612.130.481.141.324.2]

664

Figure 5.Data coupling diagram

Overall System Structure

The system overview diagram (Figure 7) ties together the agents, events and shared data objects. It depicts the four agent types identified and also shows the messages between them, percepts received by the User Interface agent and data read and written.

Detailed Design

An agent overview diagram (Figure 8) is quite similar to the system overview diagram, but it shows interactions

(9)

International Journal of Emerging Technology and Advanced Engineering

[image:9.612.76.540.143.476.2]

665

(10)

International Journal of Emerging Technology and Advanced Engineering

[image:10.612.86.531.150.429.2]

666

Figure 8.Agent Overview Diagram

The final part of design develops data, events and plans. For events, we identify the information that is carried by the event. Plans are described using a descriptor, which also prompts the designer to consider whether the plan can fail and, if so, whether the failure will be detected, as well

as what should be done to clean up upon failure. Now we

understood how the meeting scheduler system is analyzed and designed using Prometheus methodology. When it comes to implementation part, certain tools like PDT (The Prometheus Design Tool) and JACK are used. But testing phase is not given prior importance because the developers thought of mapping agent oriented concepts into OO constructs which is not structured and efficient strategy. So in order to make a methodology to be completely perfect some specialized agent oriented testing techniques should be developed. Thus in order to incorporate testing phase for the system developed using Prometheus methodology, the mental attribute plan can be used such that the overall system can be tested efficiently.

Let us take a look at an agent in the meeting scheduler system namely User Interface Agent, whose main functionalities are User Interaction and User Notify.

The events associated with those functionalities are user interaction and reminding users of events respectively. When these events are executed certain plans are triggered. When these triggered plans are tested effectively then the corresponding event is achieved. When these events work perfectly then the corresponding functionality is achieved. When all the functionalities are working in the expected manner then the particular agent is working well. Thus if all the agents present in the system is tested in this manner starting from the plan, then the Meeting Scheduler system is functioning properly.

(11)

International Journal of Emerging Technology and Advanced Engineering

667 VI. CONCLUSION

Prometheus methodology mainly focuses upon analysis, design and implementation of agent based system whereas testing is not given a major significance. Software developers thought of mapping agent-oriented abstractions into OO constructs which is not a structured and efficient technique. Any methodology is said to be complete only when it covers entire software development life cycle (Analysis, Design, Implementation, and Testing). Thus in order to make Prometheus as a full-fledged and complete methodology, testing can be incorporated into the methodology by extending the scope and support of the agent‘s mental attribute (i.e. plan) giving rise to Plan-Oriented testing.

REFERENCES

[1 ] Lin Padgham and Michael Winikoff. Prometheus: A Methodology for Developing Intelligent Agents. In proceedings of the Third International Workshop on Agent Oriented Software.

[2 ] Engineering, at AAMAS'02.Khanh Hoa Dam and Michael Winikoff.RMIT University, Melbourne, Australia. Comparing Agent-Oriented Methodologies. P. Giorgini et al. (Eds.): AOIS 2003, LNAI 3030, pp. 78–93, 2004.Springer-Verlag Berlin Heidelberg 2004.

[3 ] Lin Padgham and Michael Winikoff.RMIT University, Melbourne, Australia. ‗The Prometheus Methodology‘, April 2004.

[4 ] Lin Padgham and Michael Winikoff, ‗Prometheus: A Pragmatic Methodology for Engineering Intelligent Agents‘. In proceedings of the workshop on Agent-oriented methodologies at OOPSLA 2002. November 4, 2002, Seattle.

[5 ] Radovan Cervenka. ‗Modeling Notation Source-Prometheus‘. Version: 03-04-02.

[6 ] Henderson-Sellers.B, Giorgini, P. (eds.):‖Agent-Oriented Methodologies‖, Idea Group Inc. (2005).

[7 ] Lin Padgham, John Thangarajah and Michael Winikoff. RMIT University, Melbourne, Australia. ‗Prometheus Design Tool‘. In proceedings of the Twenty-Third AAAI Conference on Artificial Intelligence (2008).

[8 ] Lin Padgham, John Thangarajah, and Michael Winikoff, School of

Computer Science, RMIT University, Melbourne, Vic 3000, and Australia. ‗The Prometheus Design Tool – A Conference Management System Case Study‘. M. Luck and L. Padgham (Eds.): AOSE 2007, LNCS 4951, pp. 197–211, 2008.c_Springer-Verlag Berlin Heidelberg 2008.

[9 ] Lin Padgham, Michael Winikoff, David Poutakidis School of Computer Science and Information Technology RMIT University, Melbourne, Australia. ‗Adding Debugging Support to the Prometheus Methodology‘.

[10 ]Eric Yu and Luiz Marcio Cysneiros, Faculty of Information

Studies, Department of Computer Science, University of Toronto. ‘Agent-Oriented Methodologies – Towards a Challenge Exemplar‘. [11 ]Thomas Juan Leon Sterling Michael Winikoff, Department of

Computer Science and Software Engineering, the University of Melbourne, Australia.‘ Assembling Agent Oriented Software Engineering Methodologies from Features‘.

[12 ]Ambra Molesini, Enrico Denti and Andrea Omicini. ‗From AOSE Methodologies to MAS Infrastructures: The SODA Case Study‘. [13 ]David Kinny, Michael Georgeff, and Anand Rao. ‗A methodology

and modelling technique for systems of BDI agents‘. In Seventh European Workshop on Modelling Autonomous Agents in a MultiAgent World, 1996.