lecture 10
play

LECTURE 10: We now consider pragmatics of AO software Methodologies - PDF document

Pitfalls of Agent Development Lots of (single and multi-) agent projectsbut agent- oriented development received little attention LECTURE 10: We now consider pragmatics of AO software Methodologies projects Identifies key pitfalls


  1. Pitfalls of Agent Development � Lots of (single and multi-) agent projects…but agent- oriented development received little attention LECTURE 10: � We now consider pragmatics of AO software Methodologies projects � Identifies key pitfalls � Seven categories: � political � management An Introduction to MultiAgent Systems � conceptual http://www.csc.liv.ac.uk/~mjw/pubs/imas � analysis and design � micro (agent) level � macro (society) level � implementation 10-1 10-2 You Oversell Agents You Get Religious � Agents are not magic! � Agents have been used in a wide range of applications, but they are not a universal solution � If you can’t do it with ordinary software, you probably can’t do it with agents � For many applications, conventional software paradigms (e.g., OO) are more appropriate � No evidence that any system developed using agent technology could not have been built just as easily � Given a problem for which an agent and a non- using non-agent techniques agent approach appear equally good, prefer non- agent solution! � Agents may make it easier to solve certain classes of problems…but they do not make the impossible � In summary: danger of believing that agents are the possible right solution to every problem � Agents are not AI by a back door � Other form of dogma: believing in your agent definition � Don’t equate agents and AI 10-3 10-4 Don’t Know Why You Want Agents Don’t Know Why You Want Agents � Agents = new technology = lots of hype! “Agents will generate US$2.6 billion in revenue by the � Often, projects appear to be going well. (“We year 2000” have agents!”) But no vision about where to � Managerial reaction: go with them. “We can get 10% of that” � The lesson: understand your reasons for � Managers often propose agent projects without having attempting an agent development project, clear idea about what “having agents” will buy them and what you expect to gain from it. � No business plan for the project: � pure research? � technology vendor? � solutions vendor? � … 10-5 10-6 1

  2. Don’t Know What Agents Are Good For Generic Solutions to 1-Off Problems � Having developed some agent technology, � The “yet another agent testbed” syndrome you search for an application to use them � Devising an architecture or testbed that � Putting the cart before the horse! supposedly enables a range agent systems to be built, when you really need a one-off system � Leads to mismatches/dissatisfaction � Re-use is difficult to attain unless development is � The lesson: be sure you understand how and undertaken for a close knit range of problems where your new technology may be most with similar characteristics usefully applied. Do not attempt to apply it to arbitrary � General solutions are more difficult and more problems & resist temptation to apply it to costly to develop, often need tailoring to different every problem. applications. 10-7 10-8 Confuse Prototypes with Systems Believe Agents = Silver Bullet � Holy grail of software engineering is a “silver bullet”: an order of magnitude improvement in software � Prototypes are easy (particularly with nice development GUI builders!) � Technologies promoted as the silver bullet: � Field tested production systems are hard � COBOL :-) � automatic programming � Process of scaling up from single-machine � expert systems multi-threaded Java app to multi-user � graphical programming system much harder than it appears � formal methods (!) � Agent technology is not a silver bullet � Good reasons to believe that agents are useful way of tackling some problems � But these arguments largely untested in practice 10-9 10-10 Believe Agents = Silver Bullet Confuse Buzzwords & Concepts � The idea of an agent is extremely intuitive � Encourages developers to believe that they � Useful developments in software engineering: understand concepts when they do not abstractions (The AI & party syndrome: everyone has an opinion. � Agents are another abstraction However uninformed.) � Good example: the belief-desire-intention (BDI) model � theory of human practical reasoning (Bratman et al.) � agent architectures (PRS, dMARS, . . . ) � serious applications (NASA, . . . ) � logic of practical reasoning (Rao & Georgeff) � Label “BDI” now been applied to WWW pages/perl scripts 10-11 10-12 2

  3. Confuse Buzzwords & Concepts Forget it’s Software � Developing any agent system is essentially experimentation. No tried and trusted techniques � “Our system is a BDI system”…implication � This encourages developers to forget they are that this is like being a computer with 64MB developing software ! memory: a quantifiable property, with � Project plans focus on the agenty bits measurable associated benefits. � 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 � Frequent justification: software engineering for agent systems is non-existent 10-13 10-14 Forget it’s Software Forget it’s distributed � Distributed systems = one of the most complex classes of computer system to � But almost any principled software design and implement development technique is better than none. � Multi-agent systems tend to be distributed! � Problems of distribution do not go away, just because a system is agent-based � Typical multi-agent system will be more complex than a typical distributed system � Recognize distributed systems problems � Make use of DS expertise 10-15 10-16 Don’t Exploit Related Technology Don’t exploit concurrency � In any agent system, percentage of the system that � Many ways of cutting up any problem. is agent-specific is comparatively small Examples: decompose along functional, organizational, physical, or resource related lines. � The raisin bread model of Winston � One of the most obvious features of a poor multi- � Therefore important that conventional technologies agent design is that the amount of concurrent and techniques are exploited wherever possible problem solving is comparatively small or even in � Don’t reinvent the wheel. (Yet another extreme cases non-existent communication framework.) � Serial processing in distributed system! � Exploitation of related technology: � Only ever a single thread of control: concurrency, one of the most important potential advantages of � speeds up development multi-agent solutions not exploited � avoids re-inventing wheel � If you don’t exploit concurrency, why have an agent � focusses effort on agent component solution? � Example: CORBA 10-17 10-18 3

  4. Want Your Own Architecture Think Your Architecture is Generic � Agent architectures: designs for building agents � If you do develop an architecture, resist temptation to believe it is generic � Many agent architectures have been proposed over � Leads one to apply an architecture to problem for the years which it is patently unsuited � Great temptation to imagine you need your own � Different architectures good for different problems � Driving forces behind this belief: � Any architecture that is truly generic is by definition � “not designed here” mindset not an architecture… � intellectual property � If you have developed an architecture that has � Problems: successfully been applied to some particular � architecture development takes years problem, understand why it succeeded with that � no clear payback particular problem � Only apply the architecture to problems with similar � Recommendation: buy one, take one off the shelf, or characteristics do without 10-19 10-20 Use Too Much AI Not Enough AI � Temptation to focus on the agent-specific aspects of � Don’t call your on-off switch an agent! the application � Be realistic: it is becoming common to find everyday � Result: an agent framework too overburdened with distributed systems referred to as multi-agent experimental AI techniques to be usable systems � Fuelled by “feature envy”, where one reads about � Another common example: referring to WWW pages agents that have the ability to learn, plan, talk, sing, that have any behind the scenes processing as dance… “agents” � Resist the temptation to believe such features are essential in your agent system � Problems: � The lesson: build agents with a minimum of AI; as � lead to the term “agent” losing any meaning success is obtained with such systems, � raises expectations of software recipients progressively evolve them into richer systems � leads to cynicism on the part of software developers � What Etzioni calls “useful first” strategy 10-21 10-22 See agents everywhere Too Many Agents � Agents don’t have to be complex to generate � “Pure” A-O system = everything is an agent! complex behavior Agents for addition, subtraction,… � Large number of agents: � Naively viewing everything as an agent is � emergent functionality inappropriate � chaotic behavior � Choose the right grain size � Lessons: � More than 10 agents = big system � keep interactions to a minimum � keep protocols simple 10-23 10-24 4

Recommend


More recommend