Jump to content

User:Sair00/myWorkspace

From Wikipedia, the free encyclopedia

Behavior Trees [1][2][3][4] are a formal, graphical modelling language used primarily in systems and software engineering. Behavior trees employ a well defined notation to unambiguously represent the hundreds or even thousands of natural language requirements that are typically used to express the stakeholder needs for a large-scale software-integrated system.

Building a System Out of its Requirements - Dynamic View
Building a System Out of its Requirements - Static View


Overview

[edit]

Behavior Trees - Rationale

[edit]

The amount of detail in the large number of natural language requirements for a large-scale system causes short-term memory overload[1][5] and may create a barrier that prevents anyone from gaining a deep, accurate and holistic understanding of the system needs[6]. Also, because of the use of natural language, there are likely to be many ambiguities, aliases, inconsistencies, redundancies and incompleteness problems associated with the requirements information.[3] This adds further to the uncertainty and complexity. Generally, at best, a few people understand parts of the system or situation well, but no one has other than a superficial understanding of the whole – that is, the detailed integrated behavior of the system.

The Behavior Tree representation, (with the help of the Composition Tree[7] representation that resolves alias and other vocabulary problems with large sets of requirements) allows people to avoid short-term memory overload and produce a deep, accurate, holistic representation of system needs[1] that can be understood by all stakeholders because it strictly uses the vocabulary of the original requirements. Because the Behavior Tree Notation uses a formal semantics, for any given example, it already is, or can be made executable.

Behavior Tree Forms

[edit]

Single and composite or integrated behavior tree forms are both important in the application of behavior trees in systems and software engineering.


Requirement Behavior Trees

Initially, individual requirement behavior trees (RBTs) are used to capture all the fragments of behavior in each individual natural language requirement by a process of rigorous, intent-preserving and vocabulary-preserving translation. The translation process can uncover a range of defects in original natural language requirements.

Set of four Requirements Behavior Trees.

Integrated Behavior Tree

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 (IBT) that provides a single holistic view of the emergent integrated behavior of the system. This enables the building of the integrated behavior of a system out of its requirements.[8] 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 we do this, we see each piece of information in its intended context and we see the pieces of information as a whole and the emergent properties of the whole.

Requirements Integration Process


Having all the requirements converted to behavior trees (RBTs) is similar to having all the pieces for a jigsaw puzzle randomly spread out on a table - until we put all the pieces together we cannot see the emergent picture and whether any pieces are missing or do not fit. Constructing an Integrated Behavior Tree (IBT) allows us to do this.[2][3]


Behavior Engineering Process

[edit]

Representation Used - (critical)

  • BEHAVIOR TREES provide a vehicle for growing a shared understanding of a complex system.
  • The role of the COMPOSITION TREE in the overall process is to provide a vehicle for overcoming the imperfect knowledge associated with the large set of requirements for a system.


Process Used - (critical)


Behavior Engineering - Processes and Representations
Phases of the Behavior Modelling Process

History

[edit]

Behavior Trees and the concepts for their application in systems and software engineering were originally developed by Dromey[3][9][2][10] with first publication of some of the key ideas in 2001[11]. 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 all appeared to share several key properties:

  1. 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
  2. the order in which the pieces were put together was not important – with requirements this aids coping with complexity
  3. when all the members of the set were put together the resulting integrated entity exhibited a set of important emergent properties.

For behavior trees important emergent properties include

  1. the integrated behavior of the system implied by the requirements
  2. the coherent behavior of each component referred to in the requirements.


These genetic parallels, in another context, were originally spelled by Woolfson[12], (A. Woolfson, Living Without Genes, Flamingo, 2000)


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 analyse it into its component parts, is to understand how it came into being – its genesis, its growth … true understanding is always genetic”[13]. 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 specialised area of Artificial Intelligence - robotics research. The present use embraces a much broader rigorous formalization and integration of large sets of behavioural and compositional requirements needed to model large-scale systems.


Since the Behavior Tree Notation was originally conceived a number of people from the DCCS (Dependable Complex Systems Group – a joint University of Queensland, Griffith University research group) have made important contributions to the evolution and refinement of the notation and to the use of Behavior Trees. Members of this group include: David Carrington, Rob Colvin, Geoff Dromey, Lars Grunske, Ian Hayes, Diana Kirk, Peter Lindsay, Toby Myers, Dan Powell, Cameron Smith, Larry Wen, Nisansala Yatapanage, Kirsten Winter, Saad Zafar, Forest Zheng.


Probabilistic Timed Behavior Trees have recently been developed by Colvin, Grunske and Winter so that reliability, performance and other dependability properties can be expressed.[14]


Key Concepts

[edit]

The Behavior Tree Notation

[edit]
Core Elements of the Behavior Tree Notation

A behavior tree is used to formally represent the fragment of behavior in each individual requirement. Behavior for a large-scale system in general, where concurrency is admitted, appears abstractly as a set of communicating sequential processes. The Behavior Tree Notation captures these composed component-states in a simple tree-like form.


Behavior is expressed in terms of components realizing states and components creating and breaking relations. Using the logic and graphic forms of conventions found in programming languages, components can support actions, composition, events, control-flow, data-flow, and threads.[3]


Traceability tags (see Section 1.2 of Behavior Tree Notation[15]) in behavior tree nodes link the formal representation to the corresponding natural language requirement. Behavior trees accurately capture behavior expressed in the natural language representation of functional requirements. Requirements Behavior Trees strictly use the vocabulary of the natural language requirements but employ graphical forms for behavior composition in order to eliminate risk of ambiguity. By doing this they provide a direct and clearly traceable relationship between what is expressed in the natural language representation and its formal specification.[16]


A basis of the notation is that behavior is always associated with some component. Component-states which represent nodes of behavior are composed sequentially or concurrently to construct a behavior tree that represents the behavior expressed in the natural language requirements. A behavior tree with leaf nodes may revert back (symbolized by adding the caret operator ^) to an ancestor node to repeat behavior, or start a new thread (symbolized by two carets ^^).


A Behavior Tree specifies state changes in components, how data and control is passed between components and how threads interact. There are constructs for creating and breaking relations. There are also constructs for setting and testing states of components as well as mechanisms for inter-process communication that include message passing (events), shared variable blocking and synchronization.


For a complete reference to Behavior Tree notation, version 1.0, see: Behavior Tree Notation v1.0 (2007)[15]


Semantics

[edit]

The formal semantics of Behavior Trees is given via a process algebra and its operational semantics.[17] The semantics has been used as the basis for developing simulation, model checking and failure modes and effects analysis.[17][18][19]


Requirements Translation

[edit]

Requirements translation is the vehicle used to cross the informal-formal barrier. Consider the process of translation for requirement R1 below. The first tasks are to identify the components (bold), identify the behaviors (underline) and identify indicators of the order (italics) in which behaviors take place. The corresponding behavior tree can then be constructed.

What is clear from the outcome of this process is that apart from pronouns, definite articles etc, essentially all the words in the sentences that contribute to the behavior they describe have been accounted for and used.

Example Requirement Translation


Requirements Integration

[edit]

Once the set of requirements are formalized as individual requirement behavior trees, two joint properties of systems and requirements need to be exploited in order to proceed with composing the integrated behavior tree:

  1. In general, a fragment of behavior expressed by a requirement always has associated with it a precondition which needs to be satisfied before the behavior can take place (this precondition may or may not be expressed in the requirement).
  2. If the requirement is really part of the system then some other requirement in the set must establish the precondition needed in (1).


For requirements represented as behavior trees this amounts to finding where the root node of one tree occurs in some other behavior tree and integrating the two trees at that node.


The example below illustrates requirements integration for two requirements, R1 and R3. In other words, it shows how these two requirements interact.

Requirements Behavior Tree Integration


Operations on Integrated Behavior Trees

[edit]

Once an integrated behavior tree has been composed, there are a number of important operations that can be performed upon it.

Inspection – Defect Detection and Correction
[edit]

In general, many defects become much more visible when there is an integrated view of the requirements[1] 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[15] 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.[20]

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 the original requirements. This is the clearly defined stopping point for the analysis phase. With other modelling notations and methods (for instance, with UML) it is less clear-cut when modelling can stop.[21] In some cases, parts of a Model Behavior Tree may need to be transformed to make the specification executable. Once an MBT has been made executable it is possible to carry out a number of other dependability checks.

Simulation
[edit]

A Model Behavior Tree can be readily simulated in order to explore the dynamic properties of the system. Both a symbolic tool and a graphics tool have been constructed to support these activities.[22][23]

Model-Checking
[edit]

A translator has been written to convert a Model Behavior Tree into the “Actions Systems” language. This input can then be fed into the SAL Model-checker[24][25] in order to allow checks to be made as to whether certain safety and security properties are satisfied.[26][18]

Failure Mode and Effects Analysis (FMEA)
[edit]

Model-checking has often been applied to system models to check that hazardous states cannot be reached during normal operation of the system.[27] It is possible to combine model-checking with behavior trees to provide automated support for failure mode and effects analysis (FMEA).[18] The advantage of using Behavior Trees for this purpose is that they allow the formal method aspects of the approach to be hidden from non-expert users.

Requirements Change
[edit]

The ideal that is sought when responding to a change in the functional requirements for a system is that it can be quickly determined:

  1. where to make the change,
  2. how the change affects the architecture of the existing system,
  3. which components of the system are affected by the change, and
  4. what behavioral changes will need to be made to the components (and their interfaces) that are affected by the change of requirements.[4]

Because a system is likely to undergo many sets of changes over its service time, there is also a need to record, manage and optimize the system’s evolution driven by the change sequence.

A traceability model, which uses behavior trees as a formal notation to represent functional requirements, reveals change impacts on different types of design constructs (documents) caused by the changes of the requirements.[28] The model introduces the concept of evolutionary design documents that record the change history of the designs. From these documents, any version of a design document as well as the difference between any two versions can be retrieved. An important advantage of this model is that the major part of the procedure to generate these evolutionary design documents can be supported by automated tools.[20]

Code Generation and Execution
[edit]

The Behavior Tree representation of the integrated behavior of the system affords several important advantages as an executable model. It clearly separates the tasks of component integration from the task of individual component implementation. The integrated behavior of the system that emerges from integrating the requirements can be used as a foundation to create a design by applying design decisions. The result is a Design Behavior Tree (DBT)[3]: an executable multithreaded component integration specification that has been built out of the original requirements.

Behavior Tree models are executed in a virtual machine called the Behavior Run-time Environment (BRE). The BRE links together components using middleware[29], allowing components to be independent programs written in one of several languages that can be executed in a distributed environment. The BRE also contains an expression parser that automatically performs simple operations to minimize the amount of code required to be manually implemented in the component.

The implementation of components is supported by views that are automatically extractable from the DBT. These views provide the component behavior trees (CBTs) of individual components together with the interfaces of individual components. This information, together with the information in the integrated composition tree (ICT) captured about each individual component, provides the information that is needed to implement each individual component.

Several BRE’s 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 supervisory control and data acquisition (SCADA) systems used in industrial process control.

Executable Behavior Trees have been developed for case studies[21] including automated train protection[30], mobile robots with dynamic object following, an ambulatory infusion pump[19] and traffic light management systems. A version of the BRE suited for embedded systems (eBRE) is also available that has reduced functionality to tailor it to small-footprint microcontrollers.


Applications

[edit]

Behavior Tree modelling can and has been applied to a diverse range of applications over a number of years. Some of the main application areas are described below.


Large-Scale Systems

[edit]

Modelling large-scale systems with large sets of natural language requirements has always been the major focus for trialling 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 defence 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[5][6] with Raytheon Australia are presented below in the Industry Section. What all this work has consistently shown is that by translating requirements and creating dynamic and static integrated views of requirements a very significant number major defects are discovered early, over and above the defects that are found by current industry best-practice.[31][32]

Embedded Systems

[edit]

Failure of a design to satisfy a system’s requirements can result in schedule and cost overruns.[33] If there are also critical dependability issues, not satisfying system requirements can have life threatening consequences.[34] However in current approaches, ensuring requirements are satisfied is often delayed until late in the development process during a cycle of testing and debugging.[35] This work describes how the system development approach, Behavior Engineering, can be used to develop software for embedded systems.[26] The result is a model-driven development approach that can create embedded system software that satisfies its requirements, as a result of applying the development process.

Hardware-Software Systems

[edit]

Many large-scale systems consist of a mixture of co-dependent software and hardware. The different nature of software and hardware means they are often modelled separately using different approaches. This can subsequently lead to integration problems due to incompatible assumptions about hardware/software interactions.[30] These problems can be overcome by integrating Behavior Trees with the Modelica, mathematical modelling approach.[30] The environment and hardware components are modelled using Modelica and integrated with an executable software model that uses Behavior Trees.

Role-Based Access Control

[edit]

To ensure correct implementation of complex access control requirements, it is important that the validated and verified requirements are effectively integrated with the rest of the system.[36] It is also important that the system can be validated and verified early in the development process. An integrated, role-based access control model has been developed.[37] The model is based on the graphical Behavior Tree notation, and can be validated by simulation, as well as verified using a model checker. Using this model, access control requirements can be integrated with the rest of the system from the outset, because: a single notation is used to express both access control and functional requirements; a systematic and incremental approach to constructing a formal Behavior Tree specification can be adopted; and the specification can be simulated and model checked. The effectiveness of the model has been evaluated using a case study with distributed access control requirements.[36]

Biological Systems

[edit]

Because Behavior Trees describe complex behaviour, they can be used for describing a range of systems not limited to those that are computer-based.[38] In a biological context, BTs can be used to piece together a procedural interpretation of biological functions described in research papers, treating the papers as the requirements documents as described above. This can help to construct a more concrete description of the process than is possible from reading only, and can also be used as the basis for comparing competing theories in alternative papers. In ongoing research, the Behavior Trees notation is being used to develop models of the brain function in rats under fear conditioning.


Scalability and Industry Applications

[edit]

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 defence, transportation and enterprise systems have been conducted.[31][5] 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[22][39] in order to efficiently navigate and edit such large integrated views of graphical data. Several main results have come out of this work with industry. On average, over a number of projects, 130 confirmed major defects per 1000 requirements have consistently been found after normal reviews and corrections have been made.[31] With less mature requirements sets much higher defect rates have been observed.

Screen-shot of Behavior Engineering Support Environment Tool
Integrated Behavior Tree - Larger System (more than 1000 requirements)



Raytheon Australia Supports Pioneering Systems Research

An important part of this work with industry has involved applying the analysis part of the method to six large-scale defence 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”.[40][32] An outcome of these industry trials has been the joint development[6] with Raytheon Australia of an industry-strength tool to support the analysis, editing and display of large integrated sets of requirements.[39] More extensive details of industry findings can be found on the Behavior Engineering website[41].


Dr Terry Stevenson (Chief Technical Officer, Raytheon Australia) and Mr. Jim Boston (Senior Project Manager Raytheon Australia), Mr. Adrian Pitman from the Australian Defence Materiel Organization, Dr Kelvin Ross (CEO, K.J.Ross & Associates) and Christine Cornish (Bush & Cornish) have provided the special opportunities needed to support this research and to conduct the industry trials[31][5] and live project work. This work has been supported by the Australian Research Council – ARC Centre for Complex Systems and funds received from industry.


For further details see:


Benefits/Advantages

[edit]

As a behavior modelling representation, Behavior Trees have a number of significant benefits and advantages:


Criticisms/Disadvantages

[edit]
  • For small textbook level examples, their tree-like nature means that the graphic models produced are sometimes not as compact as Statechart or State Machine behavior specifications.
  • The process of requirements translation is very demanding. It is not possible to spend more than three or four hours in a day doing translation even with good tool support.
  • Tool support is needed to navigate the very large integrated behavior trees for systems that have hundreds or thousands of requirements.
  • For group walkthroughs of very large systems good display facilities are needed.
  • There is a need to provide additional sophisticated tool support to fully exploit integrated behavior tree models.


See Also

[edit]


References

[edit]
  1. ^ a b c d Dromey, R.G. 2007. Principles for Engineering Large-Scale Software-Intensive Systems
  2. ^ a b c R.G.Dromey, “Formalizing the Transition from Requirements to Design”, 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)
  3. ^ a b c d e f R.G.Dromey, From Requirements to Design: Formalizing the Key Steps, (Invited Keynote Address), SEFM-2003, IEEE International Conference on Software Engineering and Formal Methods, Brisbane, Sept. 2003, pp. 2-11.
  4. ^ a b Wen, L., Dromey, R.G. 2007. From Requirements Change to Design Change: A Formal Path
  5. ^ a b c d Boston, J. 2008. Raytheon Australia supports pioneering systems research
  6. ^ a b c Raytheon Australia, 2008. Understanding grows on Behavior Trees
  7. ^ Behavior Engineering. Composition Trees
  8. ^ Winter, K. 2007. Formalising Behaviour Trees with CSP
  9. ^ R.L.Glass, “Is This a Revolutionary Idea or Not”, Communications of the ACM, Vol. 47(11), pp. 23-25, Nov. 2004.
  10. ^ R.G.Dromey, “Climbing Over the ‘No Silver Bullet’ Brick Wall”, IEEE Software, Vol. 23, No. 2, pp.118-120, (March 2006)
  11. ^ R.G.Dromey, Genetic Software Engineering - Simplifying Design Using Requirements Integration, IEEE Working Conference on Complex and Dynamic Systems Architecture, Brisbane, Dec 2001.
  12. ^ A. Woolfson, Living Without Genes, Flamingo, 2000, ISBN 0002556189
  13. ^ Berlin, I. The Crooked Timber of Humanity: Chapters in the History of Ideas, Ed., H.Hardy, Princeton University Press, 1998 ISBN 0691058385
  14. ^ Colvin, R., Grunske, L., Winter, K. 2007 Probabilistic Timed Behavior Trees
  15. ^ a b c d Behavior Tree Group, ARC Center for Complex Systems, 2007.Behavior Tree Notation v1.0 (2007)
  16. ^ Dromey, R.G. "Genetic Design: Amplifying Our Ability to Deal With Requirements Complexity", in S.Leue, and T.J. Systra, Scenarios, Lecture Notes in Computer Science, LNCS 3466, pp. 95 - 108, 2005.
  17. ^ a b c Colvin, R., Hayes, I.J. 2006 A Semantics for Behavior Trees
  18. ^ a b c d L.Grunske, P.Lindsay, N.Yatapanage, K.Winter, An Automated Failure Mode and Effect Analysis Based on High-Level Design Specification with Behavior Trees, Fifth International Conference on Integrated Formal Methods (IFM-2005), Eindoven, The Netherlands, 2005.
  19. ^ a b c Zafar, S. and Dromey, R. G., (2005), Integrating Safety and Security Requirements into Design of an Embedded System. Asia-Pacific Software Engineering Conference 2005, 15th-17th December, Taipei, Taiwan. IEEE Computer Society Press. pp629-636.
  20. ^ a b Smith, C., Winter, K., Hayes, I., Dromey, R.G., Lindsay, P., Carrington, D.: An Environment for Building a System Out of Its Requirements, 19th IEEE International Conference on Automated Software Engineering, Linz, Austria, Sept. (2004).
  21. ^ a b Dromey, R.G. Using Behavior Trees to Model the Autonomous Shuttle System, 3rd International Workshop on Scenarios and State Machines: Models, Algorithms, and Tools (SCESM04) ICSE Workshop W5S, Edinburgh, May 25th, 2004
  22. ^ a b c L.Wen, R.Colvin, K.Lin, J.Seagrott, N.Yatapanage, R.G.Dromey, 2007, “Integrare, a Collaborative Environment for Behavior-Oriented Design”, in Proceedings of the Fourth International Conference on Cooperative Design, Visualization and Engineering, LNCS 4674, pp. 122-131, 2007
  23. ^ C. Sun, S. Xia, D. Sun, D. Chen. H.F. Shen, W. Cai: "Transparent adaptation of single-user applications for multi-user real-time collaboration", ACM Transactions on Computer-Human Interaction, Vol. 13, No.4, December 2006, pp.531-582.
  24. ^ Bensalem, S., Ganesh, V., Lakhnech, Y., Muñoz, C., Owre, et al.: “An Overview of SAL”, Fifth NASA Langley Formal Methods Workshop (LFM 2000), 2000, pp.187-196.
  25. ^ Rushby, J. Automated Formal Methods 2006 AFM-2006, Automated Formal Methods 2006, Seattle, August 2006, pp. 6-7.
  26. ^ a b c Zafar, S. and Dromey, R. G., 2005. Managing Complexity in Modelling Embedded Systems. Systems Engineering/Test and Evaluation Conference 2005, 7th-9th November, Brisbane, Australia
  27. ^ Grunske, L., Colvin, R., Winter, K. Probabilistic Model-Checking Support for FMEA Quantitative Evaluation of Systems. QEST 2007. Fourth International Conference on the Quantitative Evaluation of Systems, 17-19 Sept. 2007 pp. 119 - 128
  28. ^ Wen, L., Dromey, R.G. 2005. Architecture Normalization for Component-Based Systems Proceedings of the 2nd International Workshop on Formal Aspects of Component Software FACS'05, pp. 247-261.
  29. ^ RTI Inc. 2007 “Meeting Real-Time Requirements in Integrated Defense Systems”, RTI White Paper.
  30. ^ a b c Myers, T., Fritzson, P., Dromey, R.G. 2008. Seamlessly Integrating Software & Hardware Modelling for Large-Scale Systems. 2nd International Workshop on Equation-Based Object-Oriented Languages and Tools (EOOLT 2008), Cyprus, July 2008. pp. 5 - 15.
  31. ^ a b c d e f Powell, D. 2007. Requirements Evaluation Using Behavior Trees - Findings from Industry
  32. ^ a b c Boston, J., (Raytheon Australia), Behavior Trees - How they improve Engineering Behaviour?, 6th Annual Software and Systems Engineering Process Group Conference (SEPG 2008), Melbourne, Aug. 2008.
  33. ^ Barker, D. 2000. Requirements modeling technology: a vision for better, faster, and cheaper systems. Proceedings from VHDL International Users Forum Fall Workshop, 2000. pp. 3 - 6.
  34. ^ Leveson, N. G. Safeware: System Safety and Computers: [a guide to preventing accidents and losses caused by technology]. Addison-Wesley Publishing Company, 1995. ISBN 0201119722
  35. ^ Futrell, R. T., Shafer, D.F., Shafer, L.I. Quality Software Project Management (Software Quality Institute Series). Prentice Hall, 2002 ISBN 0130912972
  36. ^ a b Zafar, S. Colvin, R., Winter, K., Yatapanage, N., Dromey, R.G. Early Validation and Verification of a Distributed Role-Based Access Control Model. 14th Asia-Pacific Software Engineering Conference, Nagoya, Japan, December 2008. pp. 430 - 437.
  37. ^ a b Zafar,S., K.Winter, R.Colvin, R.G.Dromey, "Verification of an Integrated Role-Based Access Control Model", 1st International Workshop - Asian Working Conference on Verified Software (AWCVS'06), pp 230-240, Macao, Oct. 2006.
  38. ^ a b Milosevic, Z., Dromey, R.G. On Expressing and Monitoring Behavior in Contracts, EDOC 2002, Proceedings, 6th International Enterprise Distributed Object Computing Conference, Lausanne, Switzerland, Sept. 2002, pp. 3-14.
  39. ^ a b Phillips, V., (Raytheon Australia), "Implementing a Behavior Tree Analysis Tool Using Eclipse Development Frameworks", Australian Software Engineering Conference (ASWEC’08), Perth, March 2008
  40. ^ McNicholas, D., (Raytheon Australia), 2007. Behavior Engineering Industry Benefits
  41. ^ Behavior Engineering. Behavior Engineering website
  42. ^ Lin, K., Chen, D., Sun, C., Dromey, R.G., A Constraint Maintenance Strategy and Applications in real-time Collaborative Environments, 2nd International Conference on Cooperative Design, Visualization and Engineering (CDVE2005), 2005.
  43. ^ Lin, K., Chen, D., Dromey, R.G., Sun, CZ.: Multi-way Dataflow Constraint Propagation in Real-time Collaborative Systems, IEEE, The 2nd International Conference on Collaborative Computing: Networking, Applications and Worksharing (CollaborateCom 2006), Atlanta, Georgia, USA, Nov, 2006.
  44. ^ Grunske, L., Winter, K., Colvin, R., "Timed Behavior Trees and their application to verifying real-time systems", Proceedings of 18th Australian Conference on Software Engineering (AEWEC 2007), April 2007, accepted for publication.


Further Reading

[edit]

Raytheon Australia - Behavior Trees Joint Development


General Overview

[edit]

Dromey, R.G. 2008. "Engineering Large-Scale Systems - Mitigating the Pivitol Risks".

Dromey, R.G. 2008. Taming Complexity

Dromey, R.G. 2007. Principles for Engineering Large-Scale Software-Intensive Systems

Dromey, R.G. 2006. Formalizing the Transition from Requirements to Design

Dromey, R.G. 2003. From Requirements to Design: Formalizing the Key Steps

Wen, L., Dromey, R.G. 2007. From Requirements Change to Design Change: A Formal Path

Behavior Tree Group, ARC Center for Complex Systems, 2007. Behavior Tree Notation v1.0 (2007)


Journal Articles

[edit]

Glass, R. L. Is this a revolutionary idea or not?, November 2004, Communications of the ACM, Vol 47, No 11, pp. 23-25.

Dromey, R.G. and Powell, D. Early Requirements Defect Detection, TickIT Journal, 4Q05, pp. 3 - 13, 2005.

Dromey, R.G. "Genetic Design: Amplifying Our Ability to Deal With Requirements Complexity", in S.Leue, and T.J. Systra, Scenarios, Lecture Notes in Computer Science, LNCS 3466, pp. 95 - 108, 2005.

Dromey, R.G. "Climbing Over the 'No Silver Bullet' Brick Wall", IEEE Software, Vol. 23, No. 2, pp.118-120, (March 2006)

Wen, L., Dromey, R.G., "Architecture Normalization for Component-based Systems", in Electronic Notes in Theoretical Computer Science, vol.160, pp. 335-348.

Colvin, R., Grunske, L. and Winter. K., "Timed Behavior Trees for Failure Mode and Effects Analysis of Time-Critical Systems", in Journal of Systems and Software, Elsevier, accepted for publication 03/2008.

Grunske, L., Winter, K., Yatapanage, N., Defining the abstract syntax of visual languages with advance graph grammars - A case study based on behavior trees, in Journal of Visual Languages and Computing, Volume 19/3, pp 343-379, Elsevier, 2008.


Book Chapters

[edit]

Dromey, R.G. "Genetic Design: Amplifying Our Ability to Deal With Requirements Complexity", in S.Leue, and T.J. Systra, Scenarios, Lecture Notes in Computer Science, LNCS 3466, pp. 95 – 108, 2005.

Dromey, R. G. "Formalizing the Transition from Requirements to Design", 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)

Dromey, R.G. "Making Real Progress With the Requirements Defect Problem", in Duggan, E., Reichgelt, H. (Eds) Measuring Quality Requirements in Information Systems, Ideas Group Inc., pp. 87-108 (2006). (Invited Chapter).


Conferences

[edit]

Dromey, R.G. Genetic Software Engineering - Simplifying Design Using Requirements Integration, IEEE Working Conference on Complex and Dynamic Systems Architecture, Brisbane, Dec. 2001. Slide Presentation.

Milosevic, Z., Dromey, R.G. On Expressing and Monitoring Behavior in Contracts, EDOC 2002, Proceedings, 6th International Enterprise Distributed Object Computing Conference, Lausanne, Switzerland, Sept. 2002, pp. 3-14.

Dromey, R.G. Architecture as an Emergent Property of Requirements Integration, ICSE-2003, Software Requirements to Architecture Workshop - STRAW' 03, Portland, USA, May 2003.

Dromey, R.G. From Requirements to Design: Formalizing the Key Steps, (Invited Keynote Address), SEFM-2003, IEEE International Conference on Software Engineering and Formal Methods, Brisbane, Sept. 2003, pp. 2-11. Slide Presentation

Dromey, R.G. Managing Complexity in the Design and Analysis of Large Systems, (Invited Presentation), SETE 2003, Systems Engineering/Test and Evaluation Conference, Canberra, Sept. 2003.

Dromey, R.G. Using Behaviour Trees to Design Large Systems by Requirements Integration, Dagstuhl Invited Seminar 03371: Scenarios, Models, Algorithms and Tools, Wadern, Germany, Sept. 2003.

Dromey, R.G. Using Behavior Trees to Model the Autonomous Shuttle System, 3rd International Workshop on Scenarios and State Machines: Models, Algorithms, and Tools (SCESM04) ICSE Workshop W5S, Edinburgh, May 2004

Lin, K. Chen, D., Sun, C., Dromey, R.G. Tree Structure Maintenance in a Collaborative Genetic Software Engineering System, in Proceedings of the Sixth International Workshop on Collaborative Editing Systems, November 2004

Smith, C., Winter, K., Hayes, I., Dromey, R.G., Lindsay, P., Carrington, D.: An Environment for Building a System Out of Its Requirements, 19th IEEE International Conference on Automated Software Engineering, Linz, Austria, Sept. 2004.

Wen, L., Dromey, R.G: From Requirements Change to Design Change: A Formal Path, SEFM 2004, IEEE International Conference on Software Engineering and Formal Methods, Eds., J.R. Cuellar, Z. Liu, Beijing, Sept. 2004, pp. 104-113. - ( Selected as one of Best Papers)

Winter, K., "Formalising behaviour trees with CSP", Proc. of 4th International Conference on Integrated Formal Methods (IFM 2004), Eds., E. Boiten, J. Derrick, G. Smith, April 2004; Lecture Notes in Computer Science, Vol. 2999, 148-167.

Dromey, R. G., A System Architecture for Controlling Complexity, SETE-2005, Systems Engineering/Test and Evaluation Conference, Brisbane, Australia, 2005.

Dromey, R. G., System Composition: Constructive Support for the Analysis and Design of Large Systems, SETE-2005, Systems Engineering/Test and Evaluation Conference, Brisbane, Australia, 2005.

Gonzalez-Perez, C.A., Henderson-Sellers, B., Dromey, R.G: A Metamodel for the Behavior Trees Modelling Technique, ICITA 2005, 3rd International Conference on Information Technology and Applications, Sydney, July 4-7, 2005.

Grunske, L., Lindsay, P., Yatapanage, N., Winter, K., "An Automated Failure Mode and Effect Analysis based on High-Level Design Specification with Behavior Trees", Proceedings of International Conference on Integrated Formal Methods (IFM 2005), Edited by Atkinson, C., Bunse, C., Gross, H., Peper, C., 2005; Lecture Notes in Computer Science, Vol. 3771, 129-149.

Lin, K., Chen, D., Sun, C., Dromey, R.G., Maintaining Constraints in Collaborative Graphic Systems: the CoGSE Approach, 9th European Conference on Computer-Supported Cooperative Work (ECSCW'05), 2005.

Lin, K., Chen, D., Sun, C., Dromey, R.G., A Constraint Maintenance Strategy and Applications in real-time Collaborative Environments, 2nd International Conference on Cooperative Design, Visualization and Engineering (CDVE2005), 2005.

Lin, K., Chen, D., Dromey, R.G., Sun, C., Maintaining Multi-way Constraints in Collaborative Systems, 1st International Conference on Collaborative Computing: Networking, Applications and Work-sharing (CollaborateCom 2005), 2005.

Wen, L., Dromey, G, "Architecture Normalization for Component-Based Systems", Proceedings of the 2nd International Workshop on Formal Aspects of Component Software (FACS'05), 2005, pp247-261. Slide Presentation

Zafar, S. and Dromey, R. G., Integrating Safety and Security Requirements into Design of an Embedded System. Asia-Pacific Software Engineering Conference 2005, 15th-17th December, Taipei, Taiwan, 2005. IEEE Computer Society Press. pp629-636. Slide Presentation

Zafar, S. and Dromey, R. G., Managing Complexity in Modelling Embedded Systems. Systems Engineering/Test and Evaluation Conference 2005, 7th-9th November, Brisbane, Australia, 2005. Slide Presentation

Dromey, R.G. "Scaleable Formalization of Imperfect Knowledge", 1st International Workshop - Asian Working Conference on Verified Software (AWCVS'06), pp 21-33, Macao, Oct. 2006.

Dromey, R.G. "Guiding Principles for Engineering Quality Software", Invited Keynote Addrress, 2nd Malaysian Software Engineering Conference, MySEC'06, Kuala Lumpur, Malaysia, Dec. 2006.

Lin, K., Chen, D., Dromey, R.G., Sun, CZ.: Multi-way Dataflow Constraint Propagation in Real-time Collaborative Systems, IEEE, The 2nd International Conference on Collaborative Computing: Networking, Applications and Worksharing (CollaborateCom 2006), Atlanta, Georgia, USA, Nov. 2006.

Sithirasenan,E., Zafar,S., and Muthukkumarasamy, V. "Formal Verification of the IEEE 802.11i WLAN Security Protocol", presented at Australian Software Engineering Conference (ASWEC '06), Sydney, Australia, 2006.

Zafar,S., K.Winter, R.Colvin, R.G.Dromey, "Verification of an Integrated Role-Based Access Control Model", 1st International Workshop - Asian Working Conference on Verified Software (AWCVS'06), pp 230-240, Macao, Oct. 2006.

Colvin, R., Grunske, L., Winter, K. Probabilistic Timed Behavior Trees, In J. Davies and J. Gibbons, editors, Proc. of 6th Int. Conf. on Integrated Formal Methods (IFM 2007), Lecture Notes in Computer Science, vol 4591, pp 156-175, Springer-Verlag, 2007.

Colvin, R., Hayes, I.J. A Semantics for Behavior Trees. Feb. 2007.

Grunske, L., Winter, K., Colvin, R., "Timed Behavior Trees and their application to verifying real-time systems", Proceedings of 18th Australian Conference on Software Engineering (AEWEC 2007), April 2007, accepted for publication.

Myers, T., Fritzson, P., Dromey, R.G. Seamlessly Integrating Software & Hardware Modelling for Large-Scale Systems, 2nd International Workshop on Equation-Based Object-Oriented Languages and Tools, (EOOLT 2008), Paphos, Cyprus, July 2008. Slide Presentation

Larsen, M. The Use of Behavior Engineering for Early Test Estimates, Software & Systems Quality Conferences, National Convention Centre Canberra, Australia, October 2008.

Phillips, V., (Raytheon Australia), "Implementing a Behavior Tree Analysis Tool Using Eclipse Development Frameworks", Australian Software Engineering Conference (ASWEC’08), Perth, March 2008.

Boston, J., (Raytheon Australia), Behavior Trees - How they improve Engineering Behaviour?, 6th Annual Software and Systems Engineering Process Group Conference (SEPG 2008), Melbourne, Aug. 2008.

[edit]

Behavior Engineering

Raytheon Australia supports pioneering systems research

ARC Centre for Complex Systems - ACCS Program: Dependable Computer-Based Systems

Australian Research Council - Outcomes: Taming Complexity