Docstoc

Pitfalls

Document Sample
Pitfalls Powered By Docstoc
					Pitfalls of Agent
Projects


Borrowed from Nick Jennings
University of Southampton, UK
Pragmatics of Agent-Oriented
Developments
   Lots of (single and multi-) agent projects
    • But pragmatics of agent-oriented development
      received little attention.
   Here identify number of key pitfalls.
    •   political;
    •   management;              Jennings and
    •   conceptual;              Wooldridge
    •   analysis and design;
    •   micro (agent) level;
    •   macro (society) level;
Political Pitfalls


    You Oversell Agents
     Agents are not magic
         • If you can’t do it with ordinary software, probably
           can’t do it with agents.
         • No evidence that any system developed using agent
           technology could not have been built using non-agent
           techniques.
     Agents may make it easier to solve certain
      classes of problem
         • but they do not make the impossible possible.
     Agents are not AI by a back door.
         • Agents have not solved all the problems that have
           dogged AI since its inception
Political Pitfalls


 Get Dogmatic about Agents
      Agents used in wide range of applications, but
       they are not a universal solution.
          • For many applications, conventional software
            paradigms (e.g., OO) are more appropriate.
          • Given a problem for which an agent and a non-agent
            approach appear equally good, prefer non-agent
            solution!
      Other form of dogma
          • believing in your agent definition
          • and shoe-horning solution to fit this
Management Pitfalls


 Don’t Know Why You Want Agents
    Agents = new technology = lots of hype!
        “Agents will generate US$2.6 billion in revenue by the year 2000”
    Managerial reaction: “we can get 10% of that”
    Managers propose agent projects without having clear
     idea idea about what “having agents” will buy them.
    No business plan for the project:
       • pure research?       technology vendor?      solutions vendor?
    Often, projects appear to be going well. (“We have
     agents!”) But no vision about where to go with them.
       • understand your reasons for attempting agent
         development project, and what you expect to gain from it
Management Pitfalls

 Want Generic Solutions to 1-Off
 Problems
    Devising a “generic” architecture/testbed,
     when really need a bespoke system.
       • Re-use is difficult to attain unless development
         is undertaken for a close knit range of
         problems with similar characteristics.
    General solutions are more difficult and
     more costly to develop
       • often need extensive tailoring to target
         application
Conceptual Pitfalls


 Believe Agents = Silver Bullet
     Holy grail of software engineering is a “silver bullet”:
        • order of magnitude improvement in software development.
     Many technologies promoted as silver bullet:
        •   COBOL
        •   automatic programming
        •   expert systems
        •   graphical programming
     Agent technology is not a silver bullet.
        • Good reasons to believe that agents are a useful way of tackling
          some problems.
        • But these arguments largely untested in practice.
Conceptual Pitfalls


 Forget Agents are Software
     Agent system development is essentially experimentation
        • No tried and trusted techniques (at present)
     Encourages developers to forget developing software
        • Project plans focus on the agenty bits.
        • Mundane software engineering (requirements analysis,
          specification, design, verification, testing) is forgotten.
     Result a foregone conclusion:
        • project flounders, not because agent problems, but because
          basic software engineering ignored.
        • any principled software development technique is better
          than none.
Conceptual Pitfalls

 Forget Agents are Multi-Threaded
 Software
      Multi-threaded software: one of most complex
       classes of computer system to design and
       implement.
         • Significant background experience in distributed and
           concurrent computing areas
      Multi-agent system tend to be multi-threaded
         • both within and between agents
         • need to recognise and plan for things such as:
               synchronisation
               mutual exclusion for shared resources
               deadlock
Analysis and Design Pitfalls


 Don’t Ignore Related Technology
     Percentage of system that is agent-specific is
      comparatively small.
            “intelligent agents are 99% computer science and 1% AI”
                                                                 (Etzioni,96)

     Important conventional technologies and
      techniques are exploited wherever possible.
        • Don’t reinvent the wheel.
             CORBA
             Database technology
             Expert system shells
Analysis and Design Pitfalls


    Don’t Exploit Concurrency

     One of most obvious features of a poor
      multi-agent design is that amount of
      concurrent problem solving is small.
        • Serial processing in distributed system
        • Only ever a single thread of control:
             concurrency, one of the most important potential
              advantages of multi-agent solutions not exploited.
Analysis and Design Pitfalls


    You ignore legacy
     When building systems using new technology,
      often an assumption that it is necessary to start
      from a “blank slate”.
        • However in many cases, most important components
          of a software system will be legacy:
             functionally essential, but technologically obsolete software
              components, which cannot readily be rebuilt.
     When proposing a new software solution,
      essential to work with such components.
        • They need to be incorporated into an agent layer.
Agent Level Pitfalls


    Want Your Own Architecture
      Architecture: design for building agents.
         • Many have been proposed over the years.
      Great temptation to imagine you need your own
         • “not designed here” mindset;
         • intellectual property.
      Problems:
         • architecture development takes years;
         • no clear payback.
      Recommendation: buy one, take one off the
       shelf, or do without.
Agent Level Pitfalls


    Use Too Much AI
     Temptation to focus on “intelligent” aspects of
      the application.
        • an agent framework too overburdened with
          experimental AI techniques to be usable.
        • fuelled by “feature envy”
     Resist temptation to believe such features are
      essential in your system:
        • build agents with a minimum of AI;
        • success is obtained with such systems, progressively
          evolve them into richer systems.
Micro (Agent) Level Pitfalls


    No AI
     Don’t call your on-off switch an agent!
     Be realistic:
        • find everyday distributed systems referred to as
          multi-agent systems.
        • Web pages with any behind the scenes processing
          as “agents”.
     Problems:
        • lead to the term “agent” losing any meaning
        • raises expectations of software recipients
        • leads to cynicism on the part of software
          developers.
Macro (Society) Level Pitfalls


    See Agents Everywhere
     “Pure” A-O system = everything is an
      agent!
        • agents for addition, subtraction,…
     Naively viewing everything as an agent is
      inappropriate.
        • choose the right grain size.
        • more than 10 agents = big system.
Macro (Society) Level Pitfalls


    Too Few Agents

      While some designers imagine a separate
       agent for every possible task.
         • Others don’t recognise value of a multi-agent
           approach at all.
         • Create system with very small number of
           agents doing all the work
              fails software engineering test of coherence.
              result is like OO program with 1 class.
Macro (Society) Level Pitfalls


    Implementing Infrastructure

     Presently, no widely-used software
      platforms for developing agents
        • Such platforms provide basic infrastructure
          required to create a multi-agent system.
        • The result: everyone builds their own.
             By the time this is developed, project resources
              gone!
             No effort devoted to agent-specifics.
Macro (Society) Level Pitfalls


    Agents Interact too Freely
      Numerous systems interacting with one
       another can generate behaviour more
       complex than sum of parts
         • good: exploit this emergent functionality to
           provide simple, robust cooperative behaviour
         • bad: emergent behaviour akin to chaos
              restrict way agents interact
              simplest possible protocol for achieving set
               objective
Macro (Society) Level Pitfalls


    System Lacks Structure
     Common misconception is that agent systems
      require no real structuring
        • throw together agents and see what happens!
     While this may be true in some cases,
        • in majority of situations, considerable amount of
          system-level engineering takes place
        • especially for large scale systems or where need
          some commonality of purpose
        • structure helps:
             reduce system’s complexity
             increase efficiency
             more accurately model problem at hand
Conclusions
 Agent technology is immature and largely
  untested.
  • Agent system developers often fall into the
    same traps.
  • Described what we perceive to be most
    common and most serious of these pitfalls.
  • Thereby shift attention to pragmatics of agent
    system engineering.
Further Reading
    N. R. Jennings, P. Faratin, A. R. Lomuscio, S. Parsons, C. Sierra and M.
     Wooldridge (2001) “Automated negotiation: prospects, methods and
     challenges” Int. J. of Group Decision and Negotiation 10 (2).
    F. Zambonelli, N. R. Jennings, and M. Wooldridge (2001) "Organisational rules
     as an abstraction for the analysis and design of multi-agent systems" Int J. of
     Software Engineering and Knowledge Engineering.
    N. R. Jennings, P. Faratin, T. J. Norman, P. O'Brien and B. Odgers (2000)
     “Autonomous agents for business process management” Int. Journal of
     Applied Artificial Intelligence 14 (2) 145-189.
    N. R. Jennings, P. Faratin, T. J. Norman, P. O'Brien, B. Odgers and J. L. Alty
     (2000) “Implementing a business process management system using ADEPT:
     A Real-World Case Study” Int. Journal of Applied AI 14 (5) 421-465.
    N. Vulkan and N. R. Jennings (2000) “Efficient mechanisms for the supply of
     services in multi-agent environments” Int Journal of Decision Support Systems
     28(1-2) 5-19.
    M. Wooldridge, N. R. Jennings, and D. Kinny (2000) “The Gaia methodology
     for agent-oriented analysis and design” Journal of Autonomous Agents and
     Multi-Agent Systems 3 (3) 285-312.
    M. J. Wooldridge and N. R. Jennings, (1999) “Software engineering with
     agents: pitfalls and pratfalls” IEEE Internet Computing 3 (3) 20-27.

				
DOCUMENT INFO