Content deleted Content added
No edit summary |
Crmccull000 (talk | contribs) m Minor copyediting. Noted that paragraph "Model Based Testing" needs a reference. |
||
Line 20:
* '''Integrated behavior trees (IBT):''' Because a set of requirements imply the integrated behavior of a system, all the individual requirement behavior trees can be composed to construct an integrated behavior tree that provides a single holistic view of the emergent integrated behavior of the system. This enables the construction of the system's integrated behavior from its requirements.<ref name = "winters">Winter, K. 2007. [http://espace.library.uq.edu.au/eserv/UQ:100586/Formalising_behaviour_trees_with_csp.pdf Formalising Behaviour Trees with CSP]</ref> An analogy to help describe this process is the transition from a randomly arranged set of [[jigsaw puzzle]] pieces to putting each of the pieces in its appropriate place. When this happens, each piece of information is placed in its intended context and their collective emergent properties become clear.
Having all the requirements converted to behavior trees (RBT) is similar to having all the pieces for a [[jigsaw puzzle]] randomly spread out on a table – until all the pieces are connected, the emergent picture remains unclear, and it's uncertain whether any pieces are missing
=== Behavior engineering process ===
Critical aspects of behavior engineering representation and process are listed below.
;<nowiki>Representation:</nowiki>
* The composition tree's role in the overall process is to provide a means to overcome the imperfect knowledge associated with the large set of requirements for a system.
;<nowiki>Process:</nowiki>
* Behavior engineering uses behavior trees to control complexity while growing a shared understanding of a complex system.
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 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 represented as behavior trees
* 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 43:
These genetic parallels, in another context, were originally spelled out by Adrian Woolfson.<ref>A. Woolfson, Life Without Genes, Flamingo, 2000, {{ISBN|0-00-255618-9}}</ref>
Further weight for use of the term "genetic" came from eighteenth-century thinker [[Giambattista Vico]], who said, "To understand something, and not merely be able to describe it, or analyze it into its component parts, is to understand how it came into being – its genesis, its growth … true understanding is always genetic".<ref name = "Vico">Berlin, I. The Crooked Timber of Humanity: Chapters in the History of Ideas, Ed., H.Hardy, Princeton University Press, 1998 {{ISBN|0-691-05838-5}}</ref> Despite these legitimate genetic parallels, it was felt that this emphasis led to confusion with the concept of [[genetic algorithms]]. As a result, the term behavior engineering was introduced to describe the processes that exploit behavior trees to construct systems. The term "behavior engineering" has previously been used in a specialized area of [[artificial intelligence]] – robotics research. The present use embraces a much broader, rigorous formalization and the integration of large sets of behavioral and compositional requirements
Since the behavior tree notation was originally conceived, several people from the Dependable Complex Computer-based Systems Group (DCCS – a joint [[University of Queensland]], [[Griffith University]] research group) have made important contributions to the evolution and refinement of the behavior tree notation and usage.<ref>{{Cite web |title=Behavior Engineering World » History of Behavior Engineering |url=https://www.beworld.org/BE/home/history-of-behavior-engineering/ |access-date=2025-05-24 |language=en-US}}</ref>
Probabilistic timed behavior trees have been developed by researches such as
== Key concepts ==
Line 63:
A behavior tree specifies state changes in components, how data and control is passed between components and how [[Threads (computer science)|threads]] interact. There are constructs for creating and breaking relations. There are also constructs for setting and testing [[State (computer science)|states]] of components, as well as mechanisms for [[inter-process communication]] that include [[message passing]] (events), shared variable blocking and [[Synchronization (computer science)|synchronization]].
For a complete reference to behavior tree notation, version 1.0, see
=== Semantics ===
Line 127:
=== Large-scale systems ===
Modeling large-scale systems with large sets of natural-language requirements have always been the major focus for testing behavior trees and the overall behavior engineering process. Conducting these evaluations and trials of the method has involved work with a number of industry partners and government departments in Australia. The systems studied have included a significant number of defense systems, enterprise systems, transportation systems, information systems, health systems and sophisticated control systems with stringent safety requirements. The results of these studies have all been commercial-in-confidence. However, the results of the extensive industry trails<ref name = "raytheonSysResearch" /><ref name = "raytheonAustJoint" /> with [[Raytheon]] Australia are presented below in the Industry Section.
=== Embedded systems ===
Failure of a design to satisfy a system's requirements can result in schedule and cost overruns.<ref>Barker, D. 2000. [https://ieeexplore.ieee.org/document/890177 Requirements modeling technology: a vision for better, faster, and cheaper systems.] Proceedings from VHDL International Users Forum Fall Workshop, 2000. pp. 3–6.</ref> If there are also critical dependability issues, not satisfying system requirements can have life-threatening consequences.<ref>Leveson, N. G. Safeware: System Safety and Computers: [a guide to preventing accidents and losses caused by technology]. Addison-Wesley Publishing Company, 1995. {{ISBN|0-201-11972-2}}</ref> However, in current approaches, ensuring requirements are satisfied is often delayed until late in the development process during a cycle of testing and debugging.<ref>Futrell, R. T., Shafer, D.F., Shafer, L.I. Quality Software Project Management (Software Quality Institute Series). Prentice Hall, 2002 {{ISBN|0-13-091297-2}}</ref> This work describes how the system development approach, behavior engineering, can be used to develop software for [[embedded system]]s.<ref name = "embeddedSys05" /> The result is a [[model-driven development]] approach that can create embedded system software that satisfies its requirements
=== Hardware–software systems ===
Line 147:
=== Model Based Testing ===
[[Model-based testing]] is an approach to software testing that requires testers to create test models from requirements of Software Under Test (SUT). Traditionally, UML state charts, [[Finite-state machine|finite-state machines]], EFSM{{expand acronym|ab|date=April 2025}}, and
# It has the same expressiveness level as UML state charts and EDSLPN.
# It is intuitive to use as a modeling notation due to its graphical nature.
# Each behavior tree node has a requirement tag; this greatly facilitate the creation of a traceability matrix from requirement to test artifact.{{Citation needed|date=May 2025}}
== Scalability and industry applications ==
[[File:Behavior Engineering Support Environment.png|thumb|225px|Screen-shot of behavior engineering support environment tool]]
[[File:Integrated Behavior Tree Larger System.png|thumb|225px|Integrated behavior tree – larger system (more than 1000 requirements)]]
The first industry trials to test the feasibility of the method and refine its capability were conducted in 2002. Over the last three years a number of systematic industry trials on large-scale defense, transportation and enterprise systems have been conducted.<ref name = "raytheonSysResearch" /><ref name="industryTrialsPaper">Powell, D. 2007. [http://www.behaviorengineering.org/docs/ASWEC07_Industry_Powell.pdf Requirements Evaluation Using Behavior Trees – Findings from Industry] {{Webarchive|url=https://web.archive.org/web/20110725061927/http://www.behaviorengineering.org/docs/ASWEC07_Industry_Powell.pdf |date=25 July 2011 }}</ref> This work has established that the method scales to systems with large numbers of requirements but also that it is important to use tool support<ref name = "Integrare07" /><ref name = "RaytheonAswec08" /> in order to efficiently navigate and edit
<!--[[File:Behavior_Engineering_Support_Environment.png|frame|100px|Screen-shot of Behavior Engineering Support Environment Tool]]
[[File: Integrated_Behavior_Tree_Larger_System.png|frame|100px|Integrated behavior tree – larger system (more than 1000 requirements)]] -->
Line 161:
An important part of this work with industry has involved applying the analysis part of the method to six large-scale defense projects for [[Raytheon]] Australia. They see the method as "a key risk mitigation strategy, of use in both solution development and as a means of advising the customer on problems with acquisition documentation".<ref name = "boston08" /><ref>McNicholas, D., (Raytheon Australia), 2007. [http://www.behaviorengineering.org/images/publications/dromey2/be-industry-benefits.doc Behavior Engineering Industry Benefits]{{Dead link|date=November 2018 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> An outcome of these industry trials has been the joint development<ref name="raytheonAustJoint">Raytheon Australia, 2008. [http://www.raytheon.com.au/Files/Behavior%20Trees.pdf Understanding grows on Behavior Trees] {{Webarchive|url=https://web.archive.org/web/20090915050633/http://www.raytheon.com.au/Files/Behavior%20Trees.pdf |date=15 September 2009 }}</ref> with Raytheon Australia of an industry-strength tool to support the analysis, editing and display of large integrated sets of requirements.<ref name="RaytheonAswec08">Phillips, V., (Raytheon Australia), [http://www.behaviorengineering.org/images/publications/dromey2/bese_master_v2.ppt "Implementing a Behavior Tree Analysis Tool Using Eclipse Development Frameworks"]{{Dead link|date=November 2018 |bot=InternetArchiveBot |fix-attempted=yes }}, Australian Software Engineering Conference (ASWEC’08), Perth, March 2008</ref> More extensive details of industry findings can be found on the Behavior Engineering website.<ref name = "BEWebsite">Behavior Engineering. [http://www.behaviorengineering.org/ Behavior Engineering website] {{Webarchive|url=https://web.archive.org/web/20090301170621/http://www.behaviorengineering.org/ |date=1 March 2009 }}</ref>
Dr. Terry Stevenson (chief technical officer, Raytheon Australia)
<ref>For further details see:
| |||