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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend