AOSE

1
AOSE

• Advanced Software Engineering
• University College Dublin
• December 2007
• Dr Rem Collier

2
AOSE

• Test-Driven Development

3
Test-Driven Implementation
4
Test-Driven Implementation
5
Test-Driven Implementation
6
Test-Driven Implementation
7
AFAPL Test Suite

• Suite of AFAPL components that support the
  creation of test agents.
• TestSuitePlatformService Platform Service for
  visualising test results.
• TestAgent AFAPL agent program that provides the
  basis for all test agents.
• addTest, passTest, failTest actuators required
  for the platform service.
• The AFAPL Test Suite is used primarily to test
  the correctness of interaction-oriented
  behaviours.
• However, it is possible to implement application
  agents that are linked to a test suite and whose
  internal behaviour is evaluated via that test
  suite

8
TestAgent Agent

• IMPORT com.agentfactory.core.agent.BasicAgent
• ACTION addTest(?suite, ?identifier)
• PRECONDITION BELIEF(true)
• POSTCONDITION BELIEF(true)
• CLASS actuator.AddTest
• ACTION passTest(?suite, ?identifier)
• PRECONDITION BELIEF(true)
• POSTCONDITION BELIEF(true)
• CLASS actuator.PassTest
• ACTION failTest(?suite, ?identifier)
• PRECONDITION BELIEF(true)
• POSTCONDITION BELIEF(true)
• CLASS actuator.FailTest
• // Test Suite Configuration Commitment

9
Using Test Suite

• Include the service in the platform configuration
  file.
• SERVICE testSuite service.TestSuitePlatformServic
  e
• Create a test agent that IMPORTs the TestAgent
  program, sets up a link to the test suite, and
  creates the various tests
• IMPORT agent.TestAgent
• BELIEF(testSuite(testSuite))
• BELIEF(test(testSuite, receiveRequest))
• Add some commitment rules to the test agent that
  implement the basic tests
• BELIEF(fipaMessage(request, sender(?name,
  ?addr), ping)) gt
• COMMIT(?self, ?now, BELIEF(true),
• PAR(inform(agentID(?name, ?addr), pong),
• passTest(testSuite, receiveRequest)))

10
Using Test Suite

• The actual agents that we create are viewed as
  mirror images of the agents we wish to test.
• Typically, each test agent is given the same name
  as the agent it is replacing, but prefixed by
  test.
• E.g. an agent, called Sender, that sends a
  message to an agent called Receiver would have
  a Test Agent called testReceiver.

Request
Sender
Receiver
Response
Request
Sender
testReceiver
Response
11
Example HOTAIR Indexing
DataGatherer
DataAnalyser
DataAnalyser
Indexer
inform, document(?docID)
inform, document(?docID)
Deliver Document (A)
Deliver Document (B)
12
Example HOTAIR Indexing
testDataGatherer
testDataAnalyser
testDataAnalyser
testIndexer
inform, document(?docID)
inform, document(?docID)
Deliver Document (A)
Deliver Document (B)
13
Example HOTAIR Indexing
testDataGatherer
testDataAnalyser
testDataAnalyser
testIndexer
inform, document(?docID)
inform, document(?docID)
DataGatherer
testDataAnalyser
DataAnalyser
testIndexer
inform, document(?docID)
inform, document(?docID)
testDataGatherer
DataAnalyser
testDataAnalyser
Indexer
inform, document(?docID)
inform, document(?docID)
Deliver Document (A)
Deliver Document (B)
14
Example HOTAIR Indexing
testDataGatherer
testDataAnalyser
testDataAnalyser
testIndexer
inform, document(?docID)
inform, document(?docID)
DataGatherer
testDataAnalyser
DataAnalyser
testIndexer
inform, document(?docID)
inform, document(?docID)
testDataGatherer
DataAnalyser
testDataAnalyser
Indexer
inform, document(?docID)
inform, document(?docID)
DataGatherer
DataAnalyser
DataAnalyser
Indexer
inform, document(?docID)
inform, document(?docID)
Deliver Document (A)
Deliver Document (B)
15
Example testDataGatherer

• IMPORT agent.TestAgent
• BELIEF(testSuite(testSuite))
• BELIEF(test(testSuite, sendDocumentID))
• COMMIT(?self, ?now, BELIEF(true),
• SEQ(AWAIT(BELIEF(testSuiteSetupCompleted)),
• FOREACH(BELIEF(dataAnalyser(?name,
  ?addr)),
• ATTEMPT(inform(agentID(?name,
  ?addr), documentID(0)),
• passTest(testSuite,
  sendDocumentID),
• failTest(testSuite,
  sendDocumentID)))))

16
Example testIndexer

• IMPORT agent.TestAgent
• BELIEF(testSuite(testSuite))
• BELIEF(test(testSuite, receiveDocumentID))
• BELIEF(fipaMessage(inform, sender(?name, ?addr),
  document(0))) gt
• COMMIT(?self, ?now, BELIEF(true),
• passTest(testSuite, receiveDocumentID))
• IMPORT agent.TestAgent
• BELIEF(testSuite(testSuite))
• BELIEF(test(testSuite, recieveDocumentID))
• BELIEF(fipaMessage(inform, sender(?name, ?addr),
  document(?id))) gt
• COMMIT(?self, ?now, BELIEF(true),
• passTest(testSuite, receiveDocumentID))

17
Example testDataAnalyser

• IMPORT agent.TestAgent
• BELIEF(testSuite(testSuite))
• BELIEF(test(testSuite, receiveDocumentID))
• BELIEF(test(testSuite, sendDocumentID))
• BELIEF(fipaMessage(inform, sender(?name, ?addr),
  document(?id))) gt
• COMMIT(?self, ?now, BELIEF(true),
• passTest(testSuite, receiveDocumentID))
• COMMIT(?self, ?now, BELIEF(true),
• SEQ(AWAIT(BELIEF(testSuiteSetupCompleted)),
• FOREACH(BELIEF(indexer(?name, ?addr)),
• ATTEMPT(inform(agentID(?name,
  ?addr), documentID(0)),
• passTest(testSuite,
  sendDocumentID),
• failTest(testSuite,
  sendDocumentID)))))

18
Example test.aps

• CREATE_AGENT testDataGatherer testDataGatherer.ag
  ent
• CREATE_AGENT testDataAnalyser testDataAnalyser.ag
  ent
• CREATE_AGENT testIndexer testIndexer.agent
• // Link testDG to testDA
• ADD_BELIEF testDataGatherer ALWAYS(BELIEF(dataAna
  lyser(testDataAnalyser, addresses(localtest.ucd.i
  e))))
• // Link testDA to testInd
• ADD_BELIEF testDataAnalyser ALWAYS(BELIEF(indexer
  (testIndexer, addresses(localtest.ucd.ie))))

19
Example Step 1 Test Suite
20
Example Step 1 Test Suite
21
So, what happened?

• Recap testDataAnalyser
• BELIEF(fipaMessage(inform, sender(?name, ?addr),
  document(?id))) gt
• COMMIT(?self, ?now, BELIEF(true),
• passTest(testSuite, receiveDocumentID))
• COMMIT(?self, ?now, BELIEF(true),
• SEQ(AWAIT(BELIEF(testSuiteSetupCompleted)),
• FOREACH(BELIEF(indexer(?name, ?addr)),
• ATTEMPT(inform(agentID(?name,
  ?addr), documentID(0)),
• passTest(testSuite,
  sendDocumentID),
• failTest(testSuite,
  sendDocumentID)))))

22
Second Go
23
Implementing the Application Agents

• Take the test agents and use them as templates
  for the creation of the application agents.
• Normally, this involves the renaming of the file
  minus test and the removal of all test code.
• A separate test suite, named implementation
  should be created for these agents.
• New tests should be added as the internal
  implementation of the agent proceeds.
• The agent program should be expanded as necessary
  to implement the functionality necessary to pass
  the tests.
• In cases where existing tests are no longer
  sufficient, additional tests should be defined
  within the corresponding test agent.
• Once the application agent implementation phase
  begins, a new implementation.aps deployment
  file should be used.
• This file matches application agents against the
  relevant test agents.

24
Example DataGatherer

• IMPORT agent.TestAgent
• LOAD_MODULE collection module.Collection
• PERCEPTOR perceptor.NextDocument
• BELIEF(testSuite(testSuite))
• BELIEF(test(testSuite, sendDocumentID))
• BELIEF(test(testSuite, nextDocumentID))
• BELIEF(testSuiteSetupCompleted) gt
• COMMIT(?self, ?now, BELIEF(true),
• passTest(testSuite, setupCollection))
• BELIEF(nextDocument(?id)) gt
• COMMIT(?self, ?now, BELIEF(true),
• passTest(testSuite, nextDocumentID))
• BELIEF(nextDocument(?id))
• BELIEF(dataAnalyser(?name,?addr)) gt

• ACTION setupCollection
• PRECONDITION BELIEF(true)
• POSTCONDITION BELIEF(true)
• CLASS actuator.SetupCollection

25
Example implementation.aps

• // test agents
• CREATE_AGENT testDataGatherer testDataGatherer.ag
  ent
• CREATE_AGENT testDataAnalyser testDataAnalyser.ag
  ent
• CREATE_AGENT testIndexer testIndexer.agent
• // application agents
• CREATE_AGENT dataGatherer DataGatherer.agent
• CREATE_AGENT dataAnalyser DataAnalyser.agent
• CREATE_AGENT indexer Indexer.agent
• // Link DG to testDA
• ADD_BELIEF dataGatherer ALWAYS(BELIEF(dataAnalyse
  r(tesDataAnalyser, addresses(localimplement.ucd.i
  e))))
• // Link testDG to DA
• ADD_BELIEF testDataGatherer ALWAYS(BELIEF(dataAna
  lyser(dataAnalyser, addresses(localimplement.ucd.
  ie))))
• // Link DA to testInd
• ADD_BELIEF dataAnalyser ALWAYS(BELIEF(indexer(tes
  tIndexer, addresses(localimplement.ucd.ie))))

26
Integrating the Application

• Integration is the final step of the
  implementation process.
• For this step
• A new deployment file, called integration.aps,
  is created.
• This file associates application agents directly
  with one another.
• The integrated agent community is tested via the
  implementation test suite.
• Failure of tests or the incorrect functioning of
  the application is evaluated and any necessary
  re-factoring is carried out.

27
Example integrate.aps

• // application agents
• CREATE_AGENT dataGatherer DataGatherer.agent
• CREATE_AGENT dataAnalyser DataAnalyser.agent
• CREATE_AGENT indexer Indexer.agent
• // Link DG to testDA
• ADD_BELIEF dataGatherer ALWAYS(BELIEF(dataAnalyse
  r(dataAnalyser, addresses(localintegrate.ucd.ie))
  ))
• // Link DA to testInd
• ADD_BELIEF dataAnalyser ALWAYS(BELIEF(indexer(ind
  exer, addresses(localintegrate.ucd.ie))))

28
AOSE Case Study

• ACCESS

29
Outline of Presentation

• Motivations
• Architecture
• Agent Factory
• ACCESS Management Agents
• Service Provider Contract
• ACCESS Compliant Services
• Bus Catcher
• Sos Hotel Finder
• Meeting Service
• Conclusions

30
Motivations

• Context sensitive services are generally
  developed in an ad-hoc once off fashion.
• Many systems share a common core of functionality
• Need for an open architecture that realises this
  common core
• Such an architecture will facilitate the rapid
  prototyping of context sensitive services

31
Related Research

• Agents2Go University of Maryland (Ratsimore et
  al, 2001)
• Agora HP Research Lab (Fonseca et al, 1999)
• Impulse MIT Media Lab (Youll et al, 2000)
• MB Framework Monash University (Mihailescu et
  al, 2001)
• EasiShop - University College Dublin (UCD)
  (Keegan and OHare, 2002)

32
Related Research
33
ACCESS Objectives

• ACCESS seeks to provide
• an open extensible architecture for the rapid
  prototyping and deployment of context sensitive
  services
• strong support for generic profiling
• enable the intelligent prediction of user service
  needs
• support for a scalable multi-user environment

34
ACCESS Technologies

• Personal Digital Assistants (PDAs)
• HP iPAQ H5450
• Bluetooth Enabled
• Localisation Technology including Global
  Positioning Systems (GPS)
• Navman GPS receiver
• Communication over Wireless Networks
• Nokia 6310 Mobile phone / Bluetooth Enabled

35
ACCESS Architecture
Deployment
Development
Agent Factory Development Environment
Agent Factory Run-Time Environment
36
ACCESS Architecture
Deployment
Development
ACCESS Toolbox
ACCESS Management Agents
Agent Factory Development Environment
Agent Factory Run-Time Environment
37
ACCESS Management Agents

• Built using the pre-existing Agent
  Factoryframework
• Provide the generic reusable functionality of the
  system
• Support the application specific ACCESS-compliant
  services

38
ACCESS Management Agents
Agent Platform
Agent Platform
The ACCESS Client
The ACCESS Gateway
39
User Profiling
Agent Platform
Agent Platform
The ACCESS Client
The ACCESS Gateway

• Explicit and Implicit Profiling
• Explicit Gender, Age etc.
• Implicit Services used, Locations visited etc.

40
Context Management
Agent Platform
Agent Platform
The ACCESS Client
The ACCESS Gateway
41
Content Delivery
Agent Platform
Agent Platform
The ACCESS Client
The ACCESS Gateway

• Manages ACCESS Viewer
• Monitors user activity
• Controls display of service panels
• Customises content to the device

42
Location Sensing
Agent Platform
Agent Platform
The ACCESS Client
The ACCESS Gateway

• Monitors users position through GPS
• Sends periodic updates to Context Agent
• After a specified time interval
• After user moves by a specified distance

43
Map Generation
Agent Platform
Agent Platform
The ACCESS Client
The ACCESS Gateway
44
Service Brokerage
Agent Platform
Agent Platform
The ACCESS Client
The ACCESS Gateway

• Provides push advertisement of services
• Interrogates profiling agent to personalise the
  service list
• Filters service list based on users position

45
ACCESS Architecture
Deployment
Development
ACCESS Toolbox
ACCESS Management Agents
Agent Factory Development Environment
Agent Factory Run-Time Environment
46
Service Provider Contract

• Built on top of the ACCESS Management Layer
• Describes minimum requirements for ACCESS
  compliance
• Prefabricated roles

47
Contract Roles

• Service Manager Role
• Registers Service with ACCESS
• Delegates to Service Deliver Agent
• Advertises Service
• Service Delivery Role
• Performs task on behalf of the user within the
  service
• Responsible for delivering service specific
  content to the DACDA

48
Current ACCESS Services

• BusCatcher
• Bus Timetabling and Recommendation Service
• Sos
• Location Aware Hotel Finder Service
• Supports Personalised Hotel Bookings Hotel
  Location Information
• Meeting Service
• Make and manage your appointments on the go

49
Current ACCESS Services

• BusCatcher
• Bus Timetabling and Recommendation Service
• Sos
• Location Aware Hotel Finder Service
• Supports Personalised Hotel Bookings Hotel
  Location Information
• Meeting Service
• Make and manage your appointments on the go

50
Bus Catcher Service

• ACCESS Compliant Service
• Real time timetable information
• Plots user and bus locations
• Fare calculation
• Display of major tourist attractions

51
Motivations for Bus Catcher

• Timetables are static
• Buses frequently delayed
• User is left waiting in bad weather
• Or misses the bus by seconds
• Source of dynamic information needed

52
Bus Catcher Architecture
Resources
Service
53
Bus Catcher Contract Agents

• Bus Catcher Service Manager
• Registers Service with ACCESS Architecture
• Delegates each user to a Service Delivery Agent
• Bus Catcher Service Delivery Agent
• Responsible for communicating with DACDA
• Collaborates with other Bus Catcher Service
  Agents
• Represents the user in the Service

54
Bus Catcher Architecture
Resources
Service
55
Bus Catcher Screenshots
56
Current ACCESS Services

• BusCatcher
• Bus Timetabling and Recommendation Service
• Sos
• Location Aware Hotel Finder Service
• Supports Personalised Hotel Bookings Hotel
  Location Information
• Meeting Service
• Make and manage your appointments on the go

57
What is Sos?

• A location aware and context sensitive hotel
  finding service for mobile citizens.
• Aid travelers in finding accommodation at their
  chosen destination.
• The User context combines
• Location
• User Preferences
• Hotel Availability
• Agenda (maybe)

58
Sos and ACCESS

• Sos builds upon the ACCESS architecture
• User interaction via the ACCESS Viewer
• User location identified via ACCESS location
  service
• Context Management service used to trigger Sos
  Service
• Custom user-centric maps delivered via the ACCESS
  map service plus a Sos overlay
• Integration with ACCESS via adherence to the
  Service Provide Contract

59
Sos ACCESS
60
Sos Demo
61
Current ACCESS Services

• BusCatcher
• Bus Timetabling and Recommendation Service
• Sos
• Location Aware Hotel Finder Service
• Supports Personalised Hotel Bookings Hotel
  Location Information
• Meeting Service
• Make and manage your appointments on the go

62
Meeting Service Demo
63
Conclusions

• What did we do?
• Developed a generic architecture for context
  sensitive services
• Why did we do it?
• To enable the rapid prototyping of such services
• How did we do it?
• Agent Factory ACCESS Management Agents
  Service Provider Contract

64
AOSE Case Studies

• Social Robotics

65
Introduction

• Social Robot Architecture

66
Basic Behaviours

• Obstacle Avoidance

• Ball Following

67
Social Behaviour

• The Robot Waltz

68
The Virtual Robotic Workbench
69
The Virtual Robotic Workbench
70
Towards Mixed Reality Systems
71
AOSE

• Concluding Remarks

72
Summary

• Agent-Oriented Software Engineering can enhance
  our ability to model, design and build complex
  distributed systems.
• It achieves this by viewing such systems as
  consisting of a community of agent entities that
• Are inherently decentralised
• Have localised perspectives on the underlying
  environment.
• Can effect that environment.
• Further, they
• Exist within the context of some organisational
  structure.
• Interact in order to realise global system goals.

73
Summary

• To support this, Agent Oriented Software
  Engineering researchers have delivered
• A rich set of concepts for modeling systems.
• A range of tools for building agent-based systems
• Architectures
• Toolkits
• Programming Languages
• Numerous Software Engineering Methodologies for
  analysing and designing agent-based solutions.
• An increasing number of demonstrators that
  showcase how agents may be applied to diverse
  application domains.

74
Recap Assignment 1

• Organise yourselves into teams of 4.
• Objective Compare Agent Factory against the
  following agent development tools
• JADE, FIPA-OS, JACK, (3APL or JASON)
• Approach
• Learn the tool implement the chat system you did
  in the class compare your experiences (try to
  think what will happen as you build larger
  systems).
• Deliverable
• 10 Page document covering toolkit overviews,
  implementation approaches, and comparison /
  discussion.
• Deadline March 1st

75
Recap Assignment 2

• Organise yourselves into teams of 2.
• Objective Implement a multi-agent system using
  Agent Factory.
• Approach
• Spec out a proposed system choose a methodology
  implement a prototype of the proposed system
  review your experiences
• Deliverables
• Brief Specification (please submit for feedback
  by 21st January)
• Working prototype of system
• Report that combines the specification choice of
  design methodology design details and
  discussion of experiences.
• Deadline March 1st