13-02-2010, 03:59 PM
AGENT ORIENTED PROGRAMMING.doc (Size: 184.5 KB / Downloads: 58)
ABSTRACT
Agent-Oriented Software Engineering is the one of the most recent contributions to the field of Software Engineering. It has several benefits compared to existing development approaches, in particular the ability to let agents represent high-level abstractions of active entities in a software system. This paper gives an overview of recent research and industrial applications of both general high-level methodologies and on more specific design methodologies for industry-strength software engineering.
We know that people/systems depend on other people/systems to accomplish tasks or goals, people/systems make commitments to provide a task or meet a goal people/systems have strategies to ensure their goals are accomplished. Agent-oriented approaches model people and systems as agents.
Agent oriented programming is an emerging programming paradigm with roots in the domain of artificial intelligence. This paradigm is often described to as the natural successor to object oriented paradigm. Highly suited to applications which are embedded in complex dynamic environments, it is based on human concepts such as belief, goals and plans. This allows a natural specification of sophisticated software systems in terms that are similar to human understanding, allowing programmers to concentrate on the critical properties of the application rather than getting absorbed in the intricacies of complicated environment.
INTRODUCTION
We need open architectures that continuously change and evolve to accommodate new components and meet new requirements. More and more software must operate on different platforms, without recompilation and with minimal assumptions about its operating systems and users. It must be robust, autonomous and proactive. These circumstances motivated the development of Agent Oriented Programming.
" The objective of Agent Oriented (AO) Technology is to build systems applicable to real world that can observe and act on changes in the environment. Such systems must be able to behave rationally and autonomously in completion of their designated tasks. AO technology is an approach for building complex real time distributed applications. This technology is built on belief that a computer system must be designed to exhibit rational goal directed behaviour similar to that of a human being. AO technology achieves this by building entities called agents which are purposeful reactive and communication based and sometimes team oriented.
There are different programming methods. Object Oriented Programming is the successor of Structured programming. Agent oriented programming can be seen as an improvement and extension of object oriented programming. Since the word "Programming" is attached it means that both concepts are close to the programming language and implementation level. The term "Agent-Oriented Programming" was introduced by Shoham. So this AOP is a fairly new programming paradigm that supports societal view of computation. In AOP objects known as agents interact to achieve individual goals. Agents can be autonomous entities, deciding their next step without the interference of a user, or they can be controllable, serving as mediatory between user and another agent. In AOP programming is performed at abstract level. Agent-Oriented Software Engineering is being described as a new paradigm for the research field of Software Engineering. But in order to become a new paradigm for the software industry, robust and easy-to-use methodologies and tools have to be developed. The term AOP was suggested by Shoham.
ESSENTIALS OF AN AOP
Shoham suggests that AOP system needs each of three elements to be
complete
1. A formal language with clear syntax for describing the mental state. This would likely include structure for stating beliefs, passing messages etc.
2. A programming language in which to define agents. The semantics of this language should be closely related to formal language.
3. A method for converting neutral applications into agents. This kind of tool will allow an agent to communicate with a non-agent.
AGENT
Before we go in detail into the programming side of AOP lets have a look into what the agent concept is? Agent is a software process that meets the conventions of OAA (Open Agent Architecture) society. An agent is an abstraction that enables to model a system more easily. With this paradigm, a complex system can be modeled as a set of entities, the "agents". Agent satisfies this requirement by registering the services it can provide in an acceptable form by being able to speak the Inter agent Communication language (IACL), and by sharing the functionality common to all OAA Agent such as the ability to install triggers, manage data in certain ways etc. An agent according to Shoham is "an entity whose state is viewed as consisting of mental components such as beliefs, capabilities, choices and commitments". This definition is cryptic at best and useless at worst. In agent Oriented programming there is no single agreed definition of entities that are dealt with it.
Generally agent is hardware or (more usually) software based computer system with the following properties
* Autonomy ;: Some degree of control over its own action ("self activation").
*Social-ability: The ability to interact with other agents through some kind of agent-communication language.
*Reactivity : The ability to understand the environment and respond regularly
to changes that occur in it. Environment is usually thought to be physical, unpredictable, and containing other agents
*Pro-activeness: An agent is pro-active because it acts according to a goal
EXAMPLES OF AGENTS
So we can say that an agent is an intelligent agent; i.e. it is a piece of autonomous software. Is mere any special meaning in words intelligent and agent? An agent shows intelligent behavior, which is the ability to select actions based on knowledge. The word agent means one who is authorized to act for or in place of another.
Examples of software agents
1. The animated paper clip in Microsoft office.
2. Computer viruses (example of destructive agent)
3. Artificial players or actors in computer games and simulation.
4. Web spiders: - Collect data to build indexes to use by a software engine.
So the agent needs to have Belief : This represents the agent's current knowledge about the world, including information about the current state of the environment inferred from perception devices and messages from other agents, as well as internal information. Desire : This represents a state, which the agent is trying to achieve, such as safe landing of all planes currently circling the airport, or the achievement of a certain financial return on the stock market
Intention : This is the chosen means to achieve the agent's desires and is generally implemented as plans. Plan may be thought of as procedures that come with preconditions and intended outcomes. y
Plan : The means of achieving desires with the options available to the agents.
In agent systems the agent not only needs to know what has to be achieved, but also needs to be able to take appropriate action in order to ensure that the desired state of the world is achieved .So an agent system requires not just adductive reasoning, but also a suitable notion of agent.
AGENT CLASSIFICATIONS
Now we may go to the different types of agents. The presence and absence of the above mentioned attributes is the basis of classification. There is weak and strong notion of agency. Agent theories depend on these two notions of agency. In the weak notion of agency, agents have their own will (autonomy), they are able to interact with each other (social ability), they respond to stimulus (reactivity) and they take initiative (pro-activity). Weak notion requires onfy a white box on agents. It defines agents only in terms of observable properties. In strong notion of agency weak notion of agency is preserved, in addition agents can move around (mobility), they are truthful (veracity), they do what they are told to do (benevolence) and they will perform in an optimal manner to achieve goals (rationality), i.e. in strong notion of agency agent is modeled in terms of mental concepts. These mental concepts should have an implicit representation within the implementation of agents. This strong notion forces a white box on agents. . Ascribing mental qualities is a means of understanding and of communication between humans, i.e. it is a purely conceptual tool that serves the purpose of expressing existing knowledge about a particular program or its current state.
IDEA OF MENTAL CONCEPTS
The reasons for we still want to use mental categories to talk and reason about the program
(1) The programs state at a particular point in time is usually not directly observable. Therefore, the observable information is better expressed in mental categories.
(2) A complete simulation may be too slow, but a prediction about the behavior on the basis of the ascribed mental qualities may be feasible. Ascribing mental qualities can lead to more general hypothesis about the programs behavior than a finite number of simulations.
(3) The mental categories (e.g. goals) that are ascribed are likely to correspond to the programmers intentions when designing the program Thus, the program can be understood and changed more easily. The structure of the program is more easily accessible then in the source code form.
DESCRIBING MENTAL STATES
Here clearly define some of the psychological terms we have been using and lay out the semantics behind the coming languages. Some of the terms we need to solidify are decisions, which are partially determined by beliefs, That in turn relate to the state of the world and the capabilities of the agent. The Agent-0 based languages adopt a specific form of decisions that remove some functionality but simplify the problem of language definition. Rather than have an agent decide to perform an action as some function of its beliefs and the state of the world, Shoham introduces the notion of commitments and defines a decision to be a commitment to one self to perform an action. The task of the language designer is now simplified in a number of ways:
« No new mechanism need be introduced to perform action selection. With commitments, the agent can assume that it magically attains some obligations represented as beliefs that it will perform an action. For example, the Moon-Rover might posses a belief that it will turn left at time t. The actual language specification must have a mechanism for deciding when to adopt these commitments; this is in some sense an action selection mechanism.
¢ Designing a large system becomes a challenge. With a dynamic action-selection mechanism, decisions can be made according to some (possibly) pre-specified rules. With a commitment system, the rules must be specified when the program is created and must cover a tremendous amount of possible scenarios. The three key categories of Shoham's formal language are :
Belief
Sentences in the formal language are point-based time statements; they describe the state of something in the world at a particular point in time. For example,
turn (me, left) t
would mean that I will turn / have turned left at time t. Note that this is not only a statement but an action. This introduces the limitation that actions are viewed as "instantaneous".
To express that I currently believe that I will turn left at time t, we would
write: . B*now*me turn (me, left) t.
With this formalism, it is possible to express ideas such as existential belief.
Obligation (Commitment) and Decision
An obligation is introduced as the belief that one agent will create the truth of statement (for another agent) at a point in time. In other words,
OBL'me.you turn (me, left)1+1
means that at time t, I am obligated to you to turn left at time t+1. Note that the statement needs not be an action; I could have just as easily entered into the following commitment:
OBL!ž,e, you on_ pedestal (you)1+1
which means that I am obligated to, somehow, make it true that you are on a pedestal at time t+1. Again, a decision is simply expressed as an obligation to oneself.
Capability
An agent is said to be capable of a statement if it has the ability to see that that statement hold at the specified time. For example,
CAN wme on_pedestal (you)1
means that I am currently capable of seeing to it that you are on a pedestal at time t. Note that this does not assure that, when the time comes, 1 am still capable of this.
There are four key properties that should hold in any reasonable agent language †they are required for reasonable performance of the programs written in the language. They are:
Internal Consistency
Any agent written in the language should have consistent beliefs and desires. For example, to believe x and believe not(x) simultaneously would violate this constraint. A mechanism is needed for arbitration should these situations arise.
Good Faith
An agent should not commit to a statement unless it believes it is capable of the statement.
Introspection
Agents must be aware of their obligations: OBL '^statement -> B'a OBL ^statement not(OBL '^statement) -> B'a not(OBL '^statement) Persistence of Mental State
AOP requires that beliefs and obligations should persist by default. In other words, what an agent believes at time t it should believe at time t+1 unless some external force has affected its perspective.
Finally, capabilities are assumed to be fairly consistent; this is the result of fairly dependent action-selection and the awkward definition of decisions. If the things that agents were capable of fluctuated wildly, its entering into commitments would be meaningless. It would not be capable of fulfilling its commitments.
LANGUAGES
We need to have a brief look into the agent oriented languages Lets look into the agent-0 language. Agent-0
This is one of the languages that can be used for agent oriented Programming.Agent-O, like all of its counterparts surveyed here, follows a simple control loop when executing a program. At each time step
1) Gather incoming messages and update the mental state accordingly
2) Execute commitments (using capabilities)
The cycle of control of an Agent-0 program is shown in Figure 1. Observe that, while it might aid the author to think of an Agent-0 program as a logic program, it is not one. Nothing like proposition matching is involved; simply straight¬forward command execution.
Control
††Data Flow
†outgoing messages
A program in Agent-0 is made up of rules for entering commitment, rules for executing capabilities and a set of initial beliefs. In Agent-0, commitments can be made only to execute primitive actions; any activity that would require planning must be committed to as the anticipated elements of its plan. Statements
Statements of fact are the foundation of the concept of AOP. Facts in Agent-0, for reasons of implementation complexity, are simple atomic sentences; no conjunction or disjunction operators are included. Unconditional Action Statements
Agents can engage in any of two classes of actions: private and communicative. Private actions are handled by a separate entity (something other than the AOP interpreter) when they are encountered. No mechanism is in place in Agent-0 for private actions to do anything but notify the user that they are to be executed. Conditional Action Statements
Conditional actions are actions that are initiated only if some keys of the mental state hold. Variables
Agent-0 has limited support for variables. Existentially qualified variables (?x) and universally qualified variables (?!x) are supported. The scope of a bound variable is the entire formula in which they are instantiated. Commitment Rules
As was stated earlier, an Agent-0 program is basically a collection of commitment rules. The agent simply reacts to its environment; bases its actions on what are called message and mental conditions. Mental conditions were discussed earlier. A message condition is matched if the agent just received a message of the specified type. Capabilities
Capabilities are stored in a database as (private-action mntlcond) pairs. The mental conditions allow the system to dispose of commitments to execute capabilities that would not behave properly due to a change in the state of the world. What should be done in this case is not immediately clear; Agent-0 simply discards any commitments that cannot be executed without even notifying the agent responsible for requesting the action take place.
PL AC A
One of the more restrictive limitations of Agent-0 is plan-directedness. No commitments to anything but primitive actions can be realized as the agent has no mechanism for developing goals. Some of the more bothersome results of this are:
¢ The agent making the request must know the primitive actions of the intended recipient. This means that, for example, a customer agent and a sales agent would have to know everything about one-another to engage in successful dialogue. This is impractical at best.
¢ The requesting agent must develop the plan to achieve its goal, making the plan quite rigid. Upon executing the plan, the other agent cannot know whether or not it was successful as it was not made aware of the desired result.
PLACA attempts to resolve these problems by adding two mechanisms to the agent's state: a (consistent) list of intentions and a list of (consistent) plans. Intentions are adopted much the way that commitments are; the command (ADOPT (INTEND x)) means that the agent will add the intention to do x to its list. Plans are then created by an external plan generator to meet these intentions. While this may seem to be pushing the problem elsewhere, it gives the system the ability dynamically alter plans that are not succeeding. The structure of an external plan generator is not specified.
Agent-K
Agent-K is an attempt to standardize the message passing functionality in Agent-0. It combines the syntax of Agent-0 (it does not currently support the planning mechanisms of PLACA) with the format of KQML to ensure that messages written in other languages can be handled.
KQML (Knowledge Query & Manipulation Language) is a standard for specifying queries of expert system databases. The developers of Agent-K see Agent-0 as a useful way to manipulate the data in large data bases and incorporated syntax for doing so. The primary problem: KQML currently supports over 20 messaging types.
COMPARISON OF OOP AND AOP
An early computational theory that was meant as the foundation of a "natural" way of programming is declarative programming but it has been demonstrated by empirical investigations in cognitive psychology that this claim does not necessarily hold true.
(l)Agent-oriented programming (AOP) can be seen as an extension of object-oriented programming (OOP), OOP on the other hand can be seen as a successor of structured programming.
(2)In OOP the main entity is the object. An object is a logical combination of data structures and their corresponding methods (functions). An object can be anything ranging from a concrete entity from the real world to a conceptual entity that only exists in the designers head. Each object within the system is associated with a particular class that determines the objects basic properties. Classes can be linked with each other in several ways. Probably the best known relation between two classes is inheritance that models a conceptual extension of a common base specification. During their lifetime, objects communicate by sending messages to each other. These messages can be used to request services from the receiving object such as to provide internal information or to change the current state.
(3) Objects are successfully being used as abstractions for passive entities (e.g. a house) in the real-world, and agents are regarded as a possible successor of objects since they can improve the abstractions of active entities.
(4)Agents are similar to objects, but they also support structures for representing mental components, i.e. beliefs and commitments. (5)ln addition, agents support high-level interaction (using agent-communication languages) between agents based on the "speech act" theory as opposed to ad-hoc messages frequently used between objects, examples of such language is KQML.
(6)The property of autonomy of an agent is a major difference between the two paradigms. An object is passive by nature and is activated on reception of a message (typically reception of an invocation of one of its methods). It does not encapsulate any capacity of choice of actions. The agent, as for it, has a role to play within the system, which justifies that it can be brought to carryout actions for it, even if it is already in direct relation with other agents. It is always active. This amount by the henceforth famous sentence: "The objects do it for free; the agents do it because they want to".
Thus the traditional view of an object is the one of a passive entity that acts only on demand. However, this idea of passivity of the object is called into question with the introduction of the active object concept. Therefore the question arises: "is an active object an agent?". It is true that the concepts get closer, if one disregards pro-activeness and interpretation of the characteristics of autonomy, social ability and reactivity.
(7)Another important difference between AOP and OOP is that objects are controlled from the outside (white box control), as opposed to agents that have autonomous behavior which can't be directly controllable from the outside (black box control). In other words, agents have the right to say "no".
In summary, the collection of object-oriented concepts is clear and manageable in size and does not vary greatly in different object-oriented approaches. In the agent-oriented universe, on the other hand, we are faced with the first serious problem as there is no single agreed definition of the entities that are dealt with. Earlier we have mentioned about the various notions of agency.
(8)An object is a logical combination of data structures and their corresponding methods (functions). Moreover agents support high level interaction between agents based on speech act theory as opposed to ad-hoc messages frequently used between objects. (9)The main point is that OOP has nothing to say about who has access to the methods of an object apart from in terms of setting a global private/public distinction. In AO programming the designer should be forced to think in terms of a messaging interface between agents, such that any accessing of a method subject to security constraints. An AO language would try to pressure developers into providing higher level interfaces, and thus move the locus of control away from the method being accessed, and towards making the entity a self contained entity that checks who is making the request before acting upon it. This whole approach is supposed to be suited to environments where lots of different people from different organizations have built the components, rather than where one might have lots of different objects built by a group of people that we assume is trying to co-operate. These concepts correspond to the agent-oriented world by replacing class with role, state variable with belief/knowledge and method with message. Thus a role definition describes the agent's capabilities, the data that is needed to produce the desired results and the requests that trigger a particular service.
Besides this fundamental relation, there are many other conceptual similarities between object-orientation and agent orientation that can be mapped onto each other.
In an agent-oriented runtime system, things are distinctly more complicated although similar in their general structure. The basic entities are the agents that are implemented by their agent architecture. However, agent architectures are far more complex then the object architecture, especially because of the dynamic aspects that must be dealt with. Because of the richness of the agent-oriented world, there exist a large number of different agent architectures. Due to the vast number of approaches, it is impossible to identify the best or most general architecture. In each iteration, the agent perceives the state of its environment, integrates the perception in its knowledge base that is used to derive the next action which is then executed. This generic cycle is a useful abstraction as it provides a blackbox view on the agent architecture and encapsulates specific aspects.
So we can reach the following conclusions about difference between AOP And OOP that The name agent oriented programming was chosen to stress the view of an entity that sends the processes messages this is the name agent-oriented programming was chosen to stress the view of an agent as an entity that sends and processes messages.
An agent differs from the objects that we know from C++ or Java in a number of significant ways:
¢ The fields of an agent are restricted. The state of an agent is described in terms of beliefs, capabilities, and decisions. These ideas are built into the syntax of the language.
¢ Each message is also defined in terms of mental activities. An agent may engage another (or itself) with messaging activities from a restricted class of categories. In Shoham's formalism, the categories of messages are taken from speech-act theory; they are: informing, requesting, offering, accepting, rejecting, competing, and assisting. It will not benefit the researcher to think of agents in the framework of OOP. While an agent may be an object in the strictest sense, many ideas considered fundamental to the theory of objects are missing from AOP. So in Sohem's words
"AOP can be viewed as a specialization of object-oriented programming." - Shoham
Since this is a new and rapidly growing filed, there is a danger that researchers become overly optimistic regarding the abilities of agent-oriented software engineering. Wooldridge and Jennings discuss the potential pitfalls of agent-oriented software engineering. They have classified pitfalls in five groups: political conceptual, analysis and design, agent-level, and society-level pitfalls. Political pitfalls can occur if the concept of agents is oversold or sought applied as a universal solution. Conceptual pitfalls may occur if the developer forgets that agents are software, in fact multithreaded software. Analysis and design pitfalls may occur if the developer ignores related technology, e.g. other software engineering methodologies. Agent-level pitfalls may occur if the developer tries to use too much or too little artificial intelligence in the agent-system. And finally, society-level pitfalls can occur if Ihe developer sees agents everywhere or applies too few agents in the agent-system.
In order to agentify an information system, its schema has to be partitioned: in addition to the tables representing the current state of affairs that form its belief, special tables are needed for representing its memory (about past events & actions) and its commitments and claims. For querying the perception state by processing incoming messages a built-in data structure (such as an event queue) has to be added. Finally, the reaction patterns representing the reactive & communicative behaviors of the information system have to be specified, by means of reaction rules. Depending on a triggering event type & possible on a mental condition (involving beliefs, memory, commitments and claims), a reaction pattern specifies an action & an associated mental effect mat may lead to updates of belief, commitment & claim tables.
Information Systems & Agent-Based Software Technologies Extended IS functionality, such as adaptive user interfaces or cooperation support services, may be realized by means of agent-based software technologies. The extension of traditional information systems by a whole set of new agent-based functions for supporting interoperation, group collaboration & change management is the main concern of the cooperative information systems.
METHODOLOGIES
Several approaches to agent-oriented software engineering have been developed, ranging from structured, informal methodologies, to formal ones, as described in a recent overview and in most of them focusing basically on architectural design. We propose a software development methodology, called Tropos, which will allow us to exploit all the flexibility provided by agent oriented programming. In a nutshell, the three key features of Tropos are the following: 1.
The notion of agent and all the related mentalistic notions are used in all phases of software development, from the first phases of early analysis down to the actual implementation. A crucial role is given to the earlier analysis of requirements that precedes prescriptive requirements specification. We consider therefore much earlier phases with respect to standard object oriented methodologies as, for instance, those based on the Unified Modeling Language (UML), where use case analysis is proposed as an early activity, followed by architectural design.
2.
The methodology rests on the idea of building a model of the system-to be that is incrementally refined and extended from a conceptual level to executable artifacts. This process adopts a transformational approach: a set of transformation operators which allow the engineer to progressively detail the higher level notions introduced in the earlier phases are proposed. It must be noticed that, contrarily to what happens in most other approaches, e.g., UML based methodologies, there is no change of graphical notation from one step to the next (e.g., from use cases to class diagrams). The refinement process is performed in a more uniform way.
The following section will give an overview of the Tropos methodology.
The Tropos Methodology
The Tropos methodology is intended to support all the analysis and design activities from the very early phases of requirements engineering down to implementation, and organizes them into five main development phases: early requirement analysis, late requirements analysis, architectural design, detailed design and impiementation2.The Tropos modeling language offers actors, goals, and actor dependencies as primitive concepts for modeling an application during early requirements analysis
Early Requirements
The main objective of the early requirement analysis in Tropos is the understanding of a problem by studying an existing organizational setting. During this phase, the requirement engineer models the stakeholders as actors and analyzes their intentions that are modeled as goals which, through a goal-oriented analysis, are then decomposed into finer goals that eventually can support evaluation of alternatives.
Goal analysis can be concluded by identifying plans that, if performed by the actor, allow for goal achievement. The analysis can also lead to the identification of further dependencies with other actors. When necessary, we distinguish between hard and soft goals, the latter lacking a clear-cut definition and/or criteria for deciding whether they are satisfied ornot. Soft goals are amenable to a more qualitative kind of analysis that, when moving to later phases concerning the system definition, may lead to the identification of non-functional requirements.
Late Requirements
The late requirement analysis aims at specifying the system-to-be within its operating environment, along with relevant functions and qualities. The system is represented as an actor which has a number of dependencies with the actors already described during the early requirements phase. These dependencies define all functional and nonfunctional requirements for the system to be.
Implementation
The implementation activity follows step by step the detailed design specification, according to the established mapping between the implementation platform constructs and the detailed design notions. In our case-study, the JACK Intelligent Agents platform has been chosen for implementation. JACK is a BDI agent-oriented development environment built on top and fully integrated with Java, where agents are autonomous software components that have explicit goals (desires) to achieve or events to handle. Agents are programmed with a set of plans in order to make them capable of achieving goals.
JACK
JACK is an environment for building, running and integrating commercial-grade multi-agent systems using a component-based approach. JACK is based upon the company's Research and Development work on software agent technologies.
The JACK Agent Language is a programming language that extends Java with agent-oriented concepts, such as:
¢ Agents
¢ Capabilities
¢ Events
¢ Plans
¢ Agent Knowledge Bases( Data Bases )
¢ Resource and Concurrency management
JACK provides the tools required to develop autonomous software systems that are both goal-directed and reactive. Commercially deployed worldwide, JACK-based systems are built from distributed reasoning entities that cooperate to achieve their goals.
AGENTS IN THE REAL WORLD
The agent-oriented approach is increasingly being applied in industrial applications, but it is far from as widespread as the object-oriented approach. This section describes where and how agents have been applied with success in the manufacturing industry. Parunak defines agenthood, taxonomy and a maturity metric in an industrial context. His purpose is to improve the understanding and utilization of agent-oriented software engineering in industry. Agenthood, i.e. agent-oriented programming, is explained as an iterative improvement of the industry-strength methodology of object-oriented programming.
The taxonomy classifies agent systems as belonging to one of the following environments: digital (i.e. software and digital hardware), social (involving human users) or electromechanical (non-digital hardware, e.g. a motor). Thereafter the taxonomy classifies agents according to the interface they support. Interface types are similar to the environments: digital (e.g. communication protocols), social (e.g. user interfaces) and electromechanical (e.g. motor control interfaces). Few business users, as opposed to researchers, are early adapters of new and immature technology; as a result of this a maturity metric of agent-based systems is developed to be able to measure the level of agent technology and systems. The maturity metric has six degrees ranging from modeled applications to products.
Modeled applications, the least mature, are theoretical applications in the form of architectural descriptions or analyses. The metric continues with emulated applications that are relatively immature due to the fact that they are simulations in a lab environment.
Prototype applications represent the next maturity degree, they run in a non-commercial environment but on real hardware.
Pilot applications are relatively mature applications, however they are not expected to be completely bug-free, and after a certain period they usually become more mature and become production applications.
A production application is being applied in several businesses, but they require support for installation and maintenance. The most mature applications are products, they are usually shrink-wrapped and sold over desk, and they can usually be installed and maintained by the non-expert user.
Agents in Industry
Parunak presents a review of industrial agent applications. Application areas considered are: manufacturing scheduling, control, collaboration and agent simulation. Thereafter tools, methodologies, insights and problems for development of agent systems are presented and discussed. Manufacturing scheduling is the ordering and timing of processes in a production facility. The purpose is to optimize the production by maximizing the number of units produced per time slot and keep good quality of the product, and minimize the resource requirements per unit and the risk of failures. Processes and machinery has to be controlled in order to operate as scheduled. The control can range from simple regulation of the power level for a piece of machinery to advanced real-time cybernetic control of processes. For many industries, human collaboration is needed to solve complex problems, e.g. in a design process engineers and designers have to collaborate in order to guarantee that products are pleasant to look in addition to being safe. In industries such as electronics production, there are tremendous setup costs for production facilities; consequently there is a need for cost-efficient simulation of the manufacturing processes.
Agents can exist in a structure as complex as a global internet or one as simple as a module of a common program. Agents can be autonomous entities, deciding their next step without the interference of a user, or they can be controllable, serving as a mediator between the user and another agent.
Now, consider a mobile phone device able to use different protocols to up link the cellular network, such us UMTS as well WiFi. Suppose it has to place a call outdoor where the UMTS signal is good, but suppose a weaker WiFi signal is present and becomes stronger in the time.
These are reasonable, and possibly useful, ascriptions of "mental" attributes. Indeed, it might be useful to produce code with this perspective in mind. This is the reasoning behind agent-oriented programming.
TYPICAL APPLICATIONS OF AGENT PROGRAMMING
Mobility:
Mobile computing exhibits an inherently transient nature i.e. host locations constantly change. Transactions span many nodes and are short lived. The ability of agents to carry code and data across network nodes underlines their suitability to a transient environment. Concurrent problem solving:
Agents provide a clear, natural paradigm for performing tasks, which may have several concurrent aspects. Autonomous security model: Each agent is assigned a privilege level. The agent is only granted as much privilege as it needs. Agent may also transfer user or system privileges. Proxy Handling:
Agents can behave simultaneously as server proxies or client proxies at any node. Server proxies emulate the functionality or presence of a server while client proxies emulate the same for client. Communication traffic routing:
Determining the optimum network path for network communication has always as been near impossible task as no model of the existing network traffic can take into account the variable nature of the data traffic. An autonomous agent can be programmed to take into account the variable nature of such traffic and can dynamically optimize the
network path of such large networks. Information scouts:
Intelligent agents can be used for collecting data. The information scouting agents go through the network, communicating with the user and other agents for achieving their goals. Air traffic control:
This is a very demanding task, getting all circling planes to land safely. An agent can be designed to do the task efficiently, taking care of the weather conditions and other factors. Other examples of agent are KidSim agent, IBM agent etc.
CHALLENGING ISSUES
It is rather clear that AOP has a long way to go before it exists in any complete sense. Some of the more challenging issues facing the concept are:
Mental Category Theory:
A complete mental theory is the Grail of Artificial Intelligence and a precise formal language that describes one is not on the horizon. There are, however, concepts for which we have a fair understanding but no formal syntax. Before a language exists that is truly as expressive and powerful as AOP promises, a better job must be done with the formal theory. Security:
Security has been a non-issue with AOP researchers to date. As the languages are not yet expressive enough to detail any widely useful concepts, perhaps this is understandable. The problem will eventually arise, however, of dealing with insecure data networks, mischievous agents, and breakdowns. The problems here are slightly different than they are with typical communications protocols since agents are supposed to deal with the unknown in a "constructive" manner rather than tune them out.
Consistency:
None of the languages reviewed were expressive enough to permit the user to determine rules for consistency in beliefs and activities. The Agent-0 method of merely discarding the old beliefs and adopting the new is exceptionally dangerous in a general arena. As there is no answer that is likely to suit every situation, it is clear that the programmer must be given a way to determine what incoming information should be believed and what information should be rejected. As this is likely to be a large problem, the syntax should be as concise and simple as possible. Rigidity in Planning:
Rigid plans come from the assumption that every step of the plan must be made at the time it is consumed rather than as time progresses (the way humans do things).
CONCLUSION
There are set of concepts and methodologies which can support this paradigm. Agent-Oriented software development is an up-and coming paradigm because of an ever-growing demand for customizable, robust and open software systems that truly meet the needs and intentions of stakeholders. This is a long-term project, and much remains to be done.
FUTURE SCOPE
-
The future scope of Agent Oriented Programming is concern with the mental category theory, security, consistency, rigidity in planning etc. Several approaches are developing, ranging from structured, informal methodologies, to formal ones and most of them focusing basically on architectural design.
BIBLIOGRAPHY
1. www.axtecindia.com
2. Agent-oriented programming. - Y. Shoham.
www.wikipedia.org
CONTENTS
Page No:
¢ INTRODUCTION 1
¢ ESSENTIALS OF AN AOP 2
¢ AGENT 2
o EXAMPLES OF AGENT 3
¢ AGENT CLASSIFICATIONS 4
o IDEA OF MENTAL CONCEPTS 4
o DESCRIBING MENTAL STATES 5
¢ LANGUAGES 8
¢ COMPARISON OF OOP AND AOP 11
¢ METHODOLOGIES 15
o TROPOS METHODOLOGY 16
o EARLY REQUIREMENTS 16
o LATE REQUIREMENTS 16
¢ AGENTS IN THE REAL WORLD 18
o AGENTS IN THE INDUSTRY 19
¢ TYPICAL APPLICATION OF AGENT PROGRAMMING 20
¢ CHALLENGING ISSUES 21
¢ CONCLUSION 22
¢ FUTURE SCOPE 23
¢ BIBLIOGRAPHY 24