Content deleted Content added
Ryan-907316 (talk | contribs) m Some minor changes, added some citations and responded to comments here and there |
|||
| (6 intermediate revisions by 5 users not shown) | |||
Line 1:
{{Short description|Structured visual modeling technique}}
{{about|behavior trees for requirement handling|another use|Behavior tree (artificial intelligence, robotics and control)}}
{{Use dmy dates|date=May 2025}}{{Use American English|date=May 2025}}
Line 5 ⟶ 6:
[[File:Static Integrated View.jpg|thumb|320px|Building a system out of its requirements – static view]]
A '''behavior tree''' is a structured visual [[modeling]] technique used in [[systems engineering]] and [[software engineering]] to represent system behavior. It utilizes a hierarchical tree diagram composed of [[node (computer science)|nodes]] and connectors to illustrate control flow and system actions. By replacing ambiguous [[natural language]] descriptions with standardized visual elements—such as boxes, arrows, and standard symbols—behavior trees improve clarity, reduce misinterpretation, and enhance understanding of complex systems.<ref>{{Cite
== Overview ==
Line 34 ⟶ 35:
== 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> The first publication of some of the key
* 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.
Line 93 ⟶ 94:
In general, many defects become much more visible when there is an integrated view of the requirements<ref name = "dromey07EngLgeScale"/> and each requirement has been placed in the behavior context where it needs to execute. For example, it is much easier to tell whether a set of conditions or events emanating from a node is complete and consistent. The traceability tags<ref name = "BTNotation" /> also make it easy to refer back to the original natural-language requirements. There is also the potential to automate a number of defect and consistency checks on an integrated behavior tree.<ref name = "buildEnv04">Smith, C., Winter, K., Hayes, I., Dromey, R.G., Lindsay, P., Carrington, D.: [https://ieeexplore.ieee.org/document/1342775 An Environment for Building a System Out of Its Requirements], 19th IEEE International Conference on Automated Software Engineering, Linz, Austria, Sept. (2004).</ref>
When all defects have been corrected and the IBT is logically consistent and complete, it becomes a model behavior tree (MBT), which serves as a [[formal specification]] for the system's behavior that has been constructed out of the original requirements. This is the clearly defined stopping point for the analysis phase. With other [[Modeling languages|modeling notations]] and methods (i.e. [[Unified Modeling Language|UML]]), it is less clear-cut when
==== Simulation ====
Line 124 ⟶ 125:
Several BREs can be linked together to form complex systems using a system-of-systems construct and the Behavior Engineering Component Integration Environment (BECIE). BECIE is also used to monitor and control the behavior tree models being executed within a BRE, similar to [[SCADA|supervisory control and data acquisition (SCADA)]] systems used in industrial process control.
Executable behavior trees have been developed for case studies<ref name="shuttle04">Dromey, R.G. [http://www.behaviorengineering.org/publications/dromey/Dromey-SCESM-2004N.pdf Using Behavior Trees to Model the Autonomous Shuttle System] {{Webarchive|url=https://web.archive.org/web/20110725054354/http://www.behaviorengineering.org/publications/dromey/Dromey-SCESM-2004N.pdf |date=25 July 2011 }}, 3rd International Workshop on Scenarios and State Machines: Models, Algorithms, and Tools (SCESM04) ICSE Workshop W5S, Edinburgh, 25 May 2004</ref> including automated train protection, <ref name = "integratingSoftHard08" /> mobile robots with a dynamic object following, an ambulatory infusion pump,<ref name = "integratingSafety05" />
== Applications ==
Line 180 ⟶ 181:
* They can be understood by [[Stakeholder (corporate)|stakeholders]] without the need for [[formal methods]] training. By strictly retaining the vocabulary of the original requirements, this eases the burden of understanding.
* They have a [[Semantics of programming languages|formal semantics]],<ref name = "colvinHayesNotation" /> they support [[Concurrency (computer science)|concurrency]], they are [[executable]], and they can be [[simulated]], [[Model checking|model checked]], and used to undertake [[failure mode and effects analysis]].<ref name = "automatedFailEffect05" />
* They can be used equally well to model human processes, to analyze contracts,<ref name = "contracts02">Milosevic, Z., Dromey, R.G. [https://ieeexplore.ieee.org/document/1137692 On Expressing and Monitoring Behavior in Contracts], EDOC 2002, Proceedings, 6th International Enterprise Distributed Object Computing Conference, Lausanne, Switzerland, Sept. 2002, pp. 3-14.</ref> to represent forensic information, to represent biological systems, and many other applications. In each case, they deliver the same benefits in terms of managing complexity and seeing things as a whole. They can also be used for [[Safety-critical system|safety critical systems]],<ref name = "integratingSafety05" /> [[embedded system]]s,<ref name = "embeddedSys05" />
== Disadvantages ==
Line 204 ⟶ 205:
[[Category:Enterprise modelling]]
[[Category:Modeling languages]]
[[Category:Software engineering]]
| |||