Dealing with the challenges

© H. Mouratidis

1

Better processes Faster development Light methods

Better models Abstractions Architectures Components

Agile Development

Agent Oriented Software Engineering

Software Engineering Challenge

The challenge Better models

Abstractions Architectures Components

The solutionAgent Oriented Software

Engineering??

2

© H. Mouratidis

Agent Oriented Software Engineering

Agent Oriented Software Engineering (AOSE) introduces an alternative approach in analysing and designing complex distributed computerised systems, according to which a complex computerised system is viewed as a multiagent system in which a collection of autonomous software agents interact with each other in order to satisfy their design objectives

3

© H. Mouratidis

What is an agent?

No standard definition!!!At least two reasons why it is difficult to

define precisely what a software agent is [Nwana, 1996] A term used widely outside the research community A software agent can play many roles (navigate,

search, personal assistants)

4

© H. Mouratidis

Wooldridge & Jennings (Wooldridge, 1995) Definition

A hardware or (more usually) software based computer system that enjoys the following properties: Autonomy

Agents operate without the direct intervention of humans or others, and have some kind of control over their actions and internal state

Social Ability Agents interact with other agents (and possibly humans) via

some kind of agent communication language Reactivity

Agents perceive their environment, (which may be the physical world, such as a user via a graphical user interface, a collection of other agents etc), and respond in a timely fashion to changes that occur in it

Pro-activeness Agents do not simply act in response to their environment, they

are able to exhibit goal directed behaviour by taking the initiative

5

© H. Mouratidis

IBM definition (Franklin, 1996)

Intelligent agents are software entities that carry out some set of operations on behalf of a user or another program with some degree of independence or autonomy, and in doing so, employ some knowledge or representation of the user’s goals or desires

6

© H. Mouratidis

Multiagent Systems

The true power of the agent paradigm is realised from the use of multiagent systems.

Contain more than one agentA task is divided into a set of subtasks and

distributed amongst the different agents of the system

7

© H. Mouratidis

Few Types of agents

Many different ways to classify agents According to tasks they perform

Information gathering Information filtering Personal assistants

According to their properties Intelligent

Demonstrates some kind of intelligence Learning

Changes its behaviour according to previous experience Mobile

Able to transport itself from one machine to another

8

© H. Mouratidis

Agents versus Objects

Objects are inactive most of the time and become active only when another object requires their services. In contrast, a software agent is continually active, sensing its environment and selecting the actions to perform

The object paradigm does not address issues like cooperation, competition, negotiation and so on, which form the foundation for multi-agent systems development

Agents are able to judge their results and modify their behaviour (their internal structure) according to these results and their goals, while objects are not able of doing so

In objects, messages are method invocations while agents define different types of messages and use complex protocols to negotiate

For objects to communicate, “public” methods are used. Any other object has the right to invoke a public method from any object that contains one. In contrast an agent can decide if it will perform an action (method) that belongs to it or not.

9

© H. Mouratidis

Applications of agent technology

Many different applications From military

Military is testing software robots that can identify targets and present them to commanders much more quickly than a human could. The robots use software intelligent agents to sift through troves of images and intelligence data to find viable targets

To health care sector The eSAP project at the university of Sheffield, looked at how

agents can be used to act on behalf of doctors, nurses, patients

To NASA NASA are seriously investigating the possibility of making probes

more autonomous — giving them richer decision making capabilities and responsibilities. DS1 probe tracks its progress, and decides how to deal with unexpected eventualities.

10

© H. Mouratidis

Returning to AOSE

“…a complex computerised system is viewed as a multiagent system, in which a collection of autonomous software agents interact with each other in order to satisfy their objectives”

When designing a multiagent system“View the system as a society, similar to a

human society, consisting of entities that possess characteristics similar to humans such as mobility, intelligence and the capability of communicating” (Mouratidis, 2003)

11

© H. Mouratidis

The arguments for the use of AOSE

Too early to say that AOSE will become widely successful

AOSE will be of benefit for engineering certain complex software systems (Jennings) The effectiveness of agent oriented decompositions in

partitioning the problem space of a complex system The suitability of the key abstractions, such as agents,

interactions, and organisations, in modelling complex systems

The appropriateness of the agent oriented philosophy for dealing with dependencies and the interactions that exist in a complex system

12

© H. Mouratidis

What makes AOSE distinct from other paradigms?

The higher level of abstraction employed in the development of software systems

“The idea of modelling a system in terms of autonomous entities with characteristics similar to humans introduces a close-to-real-life modelling of the system, and therefore makes the development of the software system natural” (Mouratidis, 2004)

13

© H. Mouratidis

AOSE methodologies

Can current methodologies (which are customised to different paradigms -such as OO) be used as agent oriented software engineering methodologies? Current methodologies are based on software

engineering rules and ideas…so they can be used The different characteristics of each paradigm must

be taken into consideration…so they cannot be used! Not a simple answer!!!

14

© H. Mouratidis

Reasons for justify OO methodologies

According to Iglesias (Iglesias, 1999) Similarities between the main two concepts Common usage of object oriented languages (e.g.

JAVA) Familiarity of many software engineers with object

oriented methodologies Both emphasize the importance of interactions

between the entities of the system

15

© H. Mouratidis

Shortcomings of extending OO methodologies

The level of abstraction and the models provided by OO are not adequate to model agent characteristics Autonomous, have intentions

Not adequate set of concepts and mechanisms for complex systems

“… for complex system we find that objects, classes and modules provide an essential yet insufficient means of abstraction” (Booch, 1994)

16

© H. Mouratidis

Shortcomings of OO methodologies

The object model fails to capture the dynamic nature of the interactions between the agents

Fail to capture the social behaviour of agentsFail to model the mental states (goals, tasks,

capabilities) of the agents of the system

So? Can we use them?Agent Oriented methodologies are necessary but

the work on them can adopt, where suitable, existing methods and take advantage of the work done so far

17

© H. Mouratidis

AOSE now

Agent systems development is currently dominated by informal guidelines rather than formal principles and well-defined engineering techniques

Very few formalized techniques exist to support different stages of AOSE

AOSE is still in its infancy

18

© H. Mouratidis

Some AOSE methodologies

GAIA Jennings (Southampton), Wooldridge (Liverpool),

Zambonelli (Modena)

MaSE Scott A. Deloach (Kansas)

Tropos Mylopoulos (Toronto), Giorgini (Trento), Mouratidis

(UEL)

19

© H. Mouratidis

GAIA

One of the first methodologies specifically tailored to the analysis and design of agent-based systems.

It views the requirements phase as separate of the analysis and design phase.

Requirements Statement

Roles Model

Interactions Model

Agent Model

Services Model

Acquaintance Model

Analysis

Design

20

© H. Mouratidis

MaSE

It provides support for generating code using the MaSE code generation tool.

the general components of the system are designed before the system itself is actually defined.

UML diagrams have been modified in order to model notions of agents as well as their cooperative behaviour.

Domain Level

Design

Domain Level

Design

Agent Level Design

Agent Level Design

Component Design

Component Design

System Design

System Design

Start

End21

© H. Mouratidis

Tropos

The most important feature of Tropos is that it aspires to span the overall software development process, from the early requirements to implementation

Uses concepts such as actors, goals, tasks, resources and social dependencies that define obligations from one actor to another

22

© H. Mouratidis

Tropos stages

Early requirements: identify domain stakeholders and model them as social actors who depend on each other. Possible to state the why!

Late requirements: Model the dependencies of the system with other actors (functional and non-functional requirements)

Architectural Design: define the system’s architecture and identify the agents of the system

Detailed Design: Specify agent capabilities and interactionsEarly

Requirements

Early Requirement

s

Late Requirement

s

Late Requirement

s

Architectural Design

Architectural Design

Detailed Design

Detailed Design

Start

End

23

© H. Mouratidis

Pitfalls of agent development (Wooldridge, 2004)

You oversell agent solutions, or fail to understand where agents might be usefully applied Do not understand its limitations

You get religious or dogmatic about agents Many applications still for which conventional

software engineering techniques are more appropriate

You do not know why you want agents Read optimistic reports about the technology and

adopt itYou believe that agents are the silver bullet

Hasn’t proved itself yet!You forget you are developing software

So software engineering good practice should be followed!

24

© H. Mouratidis

Pitfalls of agent development (Wooldridge, 2004)

Your design does not exploit concurrency Do you really need agents?

You see agents everywhere Develop a successful system using agents…then you

only think agents!You have too few agents

Do not recognise the advantages of multi agent systems

You spend all your time implementing infrastructure No widely used software platforms for developing

multiagent systems…spend effort and time for developing them

25

© H. Mouratidis

Agent Computing

“My guess is that agent-based computing will be what object oriented computing was in the 1980s. Everybody will be in favour of it. Every manufacturing will be promoting his products as supporting it. Every manager will pay lip

service to it. Every programmer will practice it (differently). And no one will know just what it

is.” (Jenning, 1999)

26

© H. Mouratidis

References / Reading

“An introduction to Multiagent Systems”, Michael Wooldridge, Willey & Son, 2003

“Software agents”, J. Bradshaw (006.3)“Readings in agents”, M. Hunhs et al. (006.5)Lots of research papers on WebCT!!!!

27

© H. Mouratidis

Software Patterns28

© H. Mouratidis

What is a software pattern?

repeatable solution to a commonly occurring problem in software design

Enable an efficient transfer of experience by documenting common solutions to recurring problems in a specific context.

A three-part rule, which expresses a relation between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain software configuration which allows these forces to resolve themselves (Hillside.net)

29

© H. Mouratidis

A historical view

Christopher Alexander first used it as an architectural concept (1979)

“[A] pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever using it the same way twice.” – (Christopher Alexander)

Nothing to do with software

30

© H. Mouratidis

History of Patterns in Software

Gamma, Helm, Johnson, Vlissides (or the Gang of Four – GoF)

Use the work of Alexander for softwareSeminal Publication (1994)

Design Patterns: Elements of Reusable Object-Oriented Software

31

© H. Mouratidis

Documenting Patterns

Contain information about the problem, the context, the forces, the solution

Pattern Name: Every pattern should have a descriptive and unique name that helps in identifying and referring to it.

(Classification): The pattern should be classified according to a classification. This classification helps in identifying the use of the pattern.

(Intent): This section should describe the goal behind the pattern and the reason for using it. It resembles the problem part of the pattern.

(Also Known As): A pattern could have more than one name. These names should be documented in this section.

Forces: A description of the relevant forces and constraints, and how they interact/conflict with each other and with the intended goals and objectives of the pattern.

32

© H. Mouratidis

Documenting Patterns II

Structure: A graphical representation of the pattern. Class diagrams and Interaction diagrams can be used for this purpose (if OO patterns).

Participants: A listing of the classes and objects used in this pattern and their roles in the design. [ If OO patterns]

(Collaboration): Describes how classes and objects used in the pattern interact with each other.

Consequences: This section describes the results, side effects, and trade offs caused by using this pattern.

Implementation: This section describes the implementation of the pattern, and represents the solution part of the pattern.

(Sample Code): An illustration of how this pattern can be used in a programming language

Known Uses: This section includes examples of real usages of this pattern.

Related Patterns: This section includes any related patterns and it discusses their differences with the presented pattern.

33

© H. Mouratidis

Common Pattern Classification

Concurrency patterns These patterns involve coordinating concurrent

operations and address two primary problems Shared resources Sequence of operations

Architectural patterns Indicate fundamental structural organization schemas

(predefined sub-systems and relations) for information systems.

Creational patterns (OO patterns) Creation of objects

Structural patterns Indicate how relationships between components can be

realised Behavioral patterns

Are used to organize, manage, and combine behavior

34

© H. Mouratidis

Pattern Languages

Patterns are only point solutionsPatterns are often organised in the form of

pattern languagesA pattern language is set of closely related

patterns that guides the developer through the process of designing a system.

Design starts as a “fuzzy cloud” As patterns are applied parts of the system

come into focus / refine the design

35

© H. Mouratidis

Criticisms for Patterns

Duplication of effortStandardize accepted best practices. Why

use the design abstraction and not the code?

Lacks formal foundationsStudy is ad hoc without using any specific

formalisation.Large Pattern cataloguesSimilar Patterns appear with different

names

36

© H. Mouratidis