Behavior tree: Difference between revisions

Revision as of 05:30, 10 June 2025

Revision as of 13:43, 10 June 2025

Line 8:

== Overview ==

The extensive amount of detail involved in describing the numerous requirements for a large-scale system using natural language can lead to [[short-term memory]] overload,<ref name="dromey07EngLgeScale">Dromey, R.G. 2007. [http://www.beworld.org/BE/resource/presentation/Eng-LargeScale-Systems.pdf Principles for Engineering Large-Scale Software-Intensive Systems]</ref><ref name="raytheonSysResearch">Boston, J. 2008. [http://www.raytheon.com.au/Default.aspx?x=501 Raytheon Australia supports pioneering systems research] {{webarchive|url=https://web.archive.org/web/20090915050723/http://www.raytheon.com.au/Default.aspx?x=501|date=15 September 2009}}</ref> hindering a comprehensive understanding of the system's needs.<ref name="raytheonAustJoint" /> [[Natural language]] often introduces ambiguities, aliases, inconsistencies, redundancies, and incomplete information to concepts.<ref name = "dromey03K1-Dromey"/> This creates uncertainty and over complicatesovercomplicates systems.

The behavior tree representation attempts to eliminate uncertainty by limiting vocabulary to the original requirements. Large requirement sets may require the help of a composition tree<ref name = "compositionTree">Behavior Engineering. [http://www.behaviorengineering.org/index.php?option=com_content&task=view&id=24&Itemid=34 Composition Trees] {{Webarchive|url=https://web.archive.org/web/20090302063932/http://www.behaviorengineering.org/index.php?option=com_content&task=view&id=24&Itemid=34 |date=2 March 2009 }}</ref> representation that resolves aliases and other vocabulary problems in a prior step. The aim is to produce a deep, accurate, and holistic representation of system needs<ref name = "dromey07EngLgeScale"/> that can be understood by all readers (often [[Project stakeholder|stakeholders]]). Since the behavior tree notation uses [[Semantics of programming languages|formal semantics]], it can beserve anas input for further processing, such as making an [[executable]] for a given set of requirements.

=== Behavior tree forms ===

Line 31:

== History ==

Behavior trees and the concepts for their application in [[systems engineering|systems]] and [[software engineering]] were originally developed by Geoff Dromey<ref name="dromey06FormalizingTrans">R.G.Dromey, [http://www.behaviorengineering.org/publications/dromey/Dromey-Chapter-Final-20051.pdf "Formalizing the Transition from Requirements to Design"] {{Webarchive|url=https://web.archive.org/web/20110725053952/http://www.behaviorengineering.org/publications/dromey/Dromey-Chapter-Final-20051.pdf |date=25 July 2011 }}, in "Mathematical Frameworks for Component Software – Models for Analysis and Synthesis", Jifeng He, and Zhiming Liu (Eds.), World Scientific Series on Component-Based Development, pp. 156–187, (Invited Chapter) (2006)</ref><ref name="dromey03K1-Dromey">R.G.Dromey, [http://www.behaviorengineering.org/publications/dromey/K1-Dromey.pdf From Requirements to Design: Formalizing the Key Steps] {{Webarchive|url=https://web.archive.org/web/20110725054005/http://www.behaviorengineering.org/publications/dromey/K1-Dromey.pdf |date=25 July 2011 }}, (Invited Keynote Address), SEFM-2003, IEEE International Conference on Software Engineering and Formal Methods, Brisbane, Sept. 2003, pp. 2–11.</ref><ref>R.L.Glass, [http://www.behaviorengineering.org/publications/Bob-Glass-GSE-CACM.pdf "Is This a Revolutionary Idea or Not"] {{Webarchive|url=https://web.archive.org/web/20110725054100/http://www.behaviorengineering.org/publications/Bob-Glass-GSE-CACM.pdf |date=25 July 2011 }}, Communications of the ACM, Vol. 47(11), pp. 23–25, Nov. 2004.</ref><ref>R.G.Dromey, [http://www.behaviorengineering.org/publications/dromey/Dromey.pdf "Climbing Over the ‘No Silver Bullet’ Brick Wall"] {{Webarchive|url=https://web.archive.org/web/20110725054117/http://www.behaviorengineering.org/publications/dromey/Dromey.pdf |date=25 July 2011 }}, IEEE Software, Vol. 23, No. 2, pp. 118–120, (March 2006)</ref> with the first publication of some of the key ideas in 2001.<ref>R.G.Dromey, Genetic Software Engineering – Simplifying Design Using Requirements Integration, IEEE Working Conference on Complex and Dynamic Systems Architecture, Brisbane, Dec 2001.</ref> Early publications on this work used the terms "genetic software engineering" and "genetic design" to describe the application of behavior trees. The reason for originally using the word "genetic" was because sets of genes, sets of jigsaw puzzle pieces, and sets of requirements, when represented as behavior trees, all appearedappear to share several key properties:

* They contained enough information as a set to allow them to be composed – with behavior trees, this allows a system to be built out of its requirements.