Lecture 9: Agents as a novel Software Engineering paradigm · evolution of software engineering...

University of Jyv äskyl ä

Design of Agent-Based Systems (TIES433), Autumn 2008

Artem Katasonov

University of Jyväskylä

Lecture 9: Agents as a novel Software Engineering paradigm


2

Previously on…

Environment

sensor

inputaction outputAgent

g reactiveg autonomousg goal-orientedg temporally continuousg communicativeg learningg mobileg flexibleg character

Kno

wle

dge

Bel

iefs

Pla

ns

Desires

Goals

Intentions


3

Previously on… (2)

ArtificialIntelligenceArtificial

IntelligenceStructured

ProgrammingStructured

ProgrammingClient ServerArchitecturesClient ServerArchitectures

Distributed AIDistributed AI Peer to PeerArchitecturesPeer to Peer

Architectures

OOProgramming

OOProgramming

AgentTechnology

AgentTechnology

CommunicationPhilosophy

CommunicationPhilosophy

SocialSciencesSocial

SciencesSpeech

ActsSpeech

Acts


4

Agent-Oriented Software Engineering (AOSE)

g From the implementation point of view, agents are a next step in the evolution of software engineering approaches and programming languages.

g It is a step following the trend towards increasing degrees of localization and encapsulation in the basic building blocks of the programming models

– Structures (e.g., in C) – localizing data

– Objects (e.g., in C++ and Java) – localizing, in addition, code, i.e. an entity’s behavior

– Agents – localizing, in addition, the purpose of existence, the thread of control and action selection.

g An agent is a programming entity that is autonomous in run-time, does not need to be directly controlled.


5

AOSE (2)

g Any stand-alone software system can be seen as an agent.

g But, if we apply AOSE, not only the system as a whole, but also its components are autonomous, i.e. agents.

g In short, AOSE is not really about how to develop an agent, but rather about how to design (decompose) a software system as a collection of autonomous entities that communicate and coordinate among themselves rather than directly invoke services of each other.

g OK, AOSE is obviously an evolutionary step. But is it a step to the correct direction or maybe just a step to a dead end? So, why AOSE?


6

Model of a system engineering

Environment

Machine

Environment phenomena:

a. true regardless of the machine

(Domain analysis, Business Rules)

Machine phenomena

(Design)

Shared phenomena, interface

(Inner requirements)

Environment phenomena:

b. effect of the machine

(Outer requirements)

(Requirements)


7

Domain-machine boundary

g The problem of crossing the boundary from the domain (problem) world to the machine (solution) world is widely recognized as a major issue in software and systems engineering.

Stakeholders’ expectations

Implementation

Requirements

DesignDesign-based testing (unit and integration)

Requirements-based testing (system scope)

Satisfaction-based testing (alpha, beta, acceptance, compliance). Use.

Design validation

Requirements validation

Conflicting expectations

Domain-machine boundary


8

Boundary objects

g Boundary object – any artifact shared and understood between two or more people inhabiting different social worlds.

– Plastic enough to adapt to each of those social worlds.

– Structured enough to have repeatable function and meaning within each world.

g Examples:

– Medical patient records

– Building floor-plans

g The object-oriented approach has its conceptual basis determined by the underlying machine architecture, i.e. it is founded on implementation-level ontological primitives such as object, method, invocation, etc.

g Therefore, the OO design (e.g. UML diagrams) is not really a domain-machine boundary object. That is the basic reason why something like requirements specification is needed.


9

Agent-oriented analysis

g The notion of an agent is appropriate as a basis for the analysis of the problem to be solved by the system developed.

– Many processes in the world can be conceptualized using an agent metaphor; the result of such a conceptualization is either a single agent (or cognitive) description or a multi-agent (or social) description.

g The early stages of software development are necessarily based on intentional concepts such as stakeholders, their goals, etc.

g Nicholas Jennings argued that:– agent-oriented decompositions (according to the purpose of elements) are an

effective way of partitioning the problem space of a complex system,

– the key abstractions of the agent-oriented mindset are a natural means of modeling complex systems,

– the agent-oriented philosophy for modeling and managing organizational relationships is appropriate for dealing with the dependencies and interactions that exist in complex systems.

N.R. Jennings. An agent-based approach for building complex software systems. Communications of the ACM, 44(4):35–41, 2001.


10

So why AOSE?

g Most powerful abstractions are those that minimize the semantic distance between the units of analysis that are intuitively used to conceptualize the problem and the constructs present in the solution paradigm (Jennings, 2000).

– Crossing boundary is easier and thus less error-prone.

– Process is more transparent to stakeholders, boundary is further from start.

g A possibility to have the same concept, i.e. agent, as the central one in both the problem analysis and the solution design and implementation can make it much easier to design a good solution and to handle complexity.

g In a sense, agent-oriented approach postpones the transition from the domain concepts to the machine concepts until the stage of the design and implementation of individual agents (given that those are still to be implemented in an object-oriented programming language).

N.R. Jennings. On agent-based software engineering. Artificial Intelligence, 117(2):277–296, 2000.


11

AOSE vs. OOSE

Problem

Solution

OOSE:

Stakeholders, their goals, knowledge, intentions, collaboration, etc.

Components, objects, their services, uses, dependencies, etc

Problem

Solution

AOSE:

Stakeholders, their goals, knowledge, intentions, collaboration, etc.

Agents, their goals, beliefs, intentions, communication, etc.


12

Pushing boundary further


Implementation

Requirements

Design


APL Implementation

OO PL implementation

Requirements

Design

g Agent-oriented design becomes a boundary object.

g Utilizing an Agent Programming Language (APL) may make even the high-level implementation a boundary object.


13

Agent Programming Languages

g Examples:– AgentSpeak(L)– 3APL– AFAPL from AgentFactory framework– Semantic Agent Programming Language (S-APL)

g All of those are declarative languages and based on the first-order logic of n-ary predicates (Prolog-like).

g For example, in AFAPL (similarly in S-APL):– An AFAPL agent program consists of declarations of the beliefs and goals of that

agent and declaration of a set of rules, including belief rules (generating new beliefs based on existing ones), reactive rules (invoking some actions immediately), and commitment rules (adopting a commitment to invoke an action).

– Perceptors (perceiving environment and generating new beliefs) and actuators (implementing the actions to be invoked) are then pieces of external code, in Java.


14

Agent Programming Languages (2)

g AFAPL examples:

PERCEPTOR perceptor.BallPerceptor;

BELIEF(seesBall) => COMMIT(?self, ?now, BELIEF(seesBall), moveTo(ball));

BELIEF(newTag(?tagID)) => COMMIT(?self, ?now, BELIEF(true), checkTag(?tagID));

g Advantage of an APL is that the transition from the domain concepts to the machine concepts is postponed even further, until the implementation of particular perceptors and actuators.


15

Agent Platforms

g Development of a software system with AOSE usually involves utilization of an agent middleware platform.

g Agents do not embed the code needed for e.g. communication with others, but do it through the platform.

g Hybrid P2P is normally assumed, so the platform has to provide discovery mechanisms.

JADE architecture


16

Agent Platforms (2)

g Services to be provided by an agent platform, according to FIPA:


17

AOSE and Requirements engineering

g (An above slide) The OO design (e.g. UML diagrams) is not really a domain-machine boundary object. That is the basic reason why something like requirements specification is needed.

g (An above slide) Agent-oriented design becomes a boundary object. Utilizing an Agent Programming Language (APL) may make even the high-level implementation a boundary object.

g Does this mean that AOSE may remove the need for thorough analysis and explicit documentation of requirements?

g Hardly. But it may facilitate some aspects.


18

Stakeholders’ conflicts

Stakeholderexpectations


Stakeholder expectations

Negotiation

Design

Implementation

g Normally, it is assumed that during the requirements development stage, the stakeholders of the system must negotiate and reach an agreement on how the system shall work.

g For complex systems, may be very difficult.

g The nature of the conflict can be political. In this case, finding a global solution is often just impossible.


19

A thought: AOSE and stakeholders’ conflicts

Stakeholderexpectations


Stakeholder expectations

Partial Design

Implementation

g Resolution of the conflict can be moved to run-time.

g Resolving the conflict on instance-per-instance basis can be much simpler than finding a global solution that would cover all the instances.

Partial Design

Implementation

Negotiation


20

Drawback of AOSE

g AOSE is supposed to facilitate the design of complex systems.

g Although the flexibility of agent interactions has many advantages when it comes to engineering complex systems, the downside is that it leads to unpredictability in the run time system; as agents are autonomous, the patterns and the effects of their interactions are uncertain.

g It is common in specific systems and applications to circumvent these difficulties, i.e. to reduce the system’s unpredictability,

– By using interaction protocols whose properties can be formally analyzed

– By adopting rigid and preset organizational structures,

– By limiting the nature and the scope of the agent interplay.

g These restrictions also limit the power of the agent-based approach; thus, in order to realize its full potential some longer term solutions are required.

N.R. Jennings. On agent-based software engineering. Artificial Intelligence, 117(2):277–296, 2000.


21

Major directions towards solution

1. Social level characterization of agent systemsg The need for a better understanding of the impact of sociality and

organizational context on an individual’s behavior and of the symbiotic link between the behavior of the individual agents and that of the overall system.

g Modeling behavior of an agent as being defined by the roles the agent plays in one or several organizations.

2. Ontological approaches to inter-agent coordinati ong To enable agents to communicate their intentions with respect to future

activities, and reason about them in real time.

g To enable individual agents to represent and reason about the actions, plans, and knowledge of other agents to coordinate with them.


22

Ontological coordination problemTwo robots meet on Mars. If there is a need

for cooperation or at least coordination:

g Assume both follow FIPA ACL: can exchange messages, understand INFORM, REQUEST, REJECT, etc.

g Assume both follow BDI architecture: share meaning of “I intend”, “My goal is”

g Both designed for Mars – hopefully have similar domain ontology concepts: “surface”, “rock” – but mapping between concept labels already requires use of standard semantic technologies (RDF, OWL).

g Assume US robot has a “jet pack” and thus can “fly”, while EU robot has no idea about possibility of moving in third dimension.

g How US robot can communicate its movement intentions, so that two can coordinate?


23

5 ontologiesExtOnt(AExtOnt(A)) -- properties of the properties of the

external worldexternal worldMentOnt(AMentOnt(A)) -- internal mental internal mental

properties of the agentproperties of the agentBodyOnt(ABodyOnt(A)) -- properties of the properties of the

agent's (physical) bodyagent's (physical) bodyInOnt(AInOnt(A))

-- properties of the sensory inputproperties of the sensory input-- properties of the properties of the communication inputcommunication input

OutOnt(AOutOnt(A))-- properties of the action outputproperties of the action output-- properties of the properties of the communication outputcommunication output

Domain ontologyDomain ontology

E.g. BDI modelE.g. BDI model

Available sensors Available sensors and actuatorsand actuators

Sensing vocabularySensing vocabulary

E.g. E.g. FIPAFIPA’’ss ACLACL

Acting vocabularyActing vocabulary

E.g. E.g. FIPAFIPA’’ss ACLACL

Are notreally

treated

Need to be able to semantically describe not only the domain, but the agents themselves!


24

Lecture 9: Main points

g Agent-oriented approach facilitates the design of complex systems, because it gives a possibility to have the same concept, i.e. agent, as the central one in both the problem analysis and the solution design and implementation.

g Development of a software system with AOSE usually involves utilization of an agent middleware platform, and may be done (but not necessarily) with involvement of a high-level Agent Programming Language.

g The major drawback of agent-oriented approach is lower predictability of system’s run-time operation.

g Emergence of a solution that would allow flexible yet predictable operation of agent systems seems to be a prerequisite for wide-scale adoption of AOSE.

g Major directions for search of such a solution are social-level characterization of agent systems (more or less studied) and ontological approaches to inter-agent coordination (not yet studied much).


25

Following next:

g FIPA (IEEE) standard architecture

g Overview and comparison of existing platforms:

– JADE

– Cougaar

– AgentFactory

– 3APL

– Jason (AgentSpeak APL)

– UBIWARE Platform (S-APL)

Lecture 9: Agents as a novel Software Engineering paradigm · evolution of software engineering...

Documents

Transcript of Lecture 9: Agents as a novel Software Engineering paradigm · evolution of software engineering...