Дерево поведения - Behavior tree

Эта статья посвящена деревьям поведения для обработки требований. Деревья поведения в AI, играх, управлении и робототехнике см. Дерево поведения (искусственный интеллект, робототехника и управление).

Построение системы исходя из ее требований - динамическое представление
Построение системы исходя из ее требований - статическое представление

Деревья поведения являются формальным графическим язык моделирования используется в основном в системы и программная инженерия. В деревьях поведения используются четко определенные обозначения, чтобы однозначно представлять сотни или даже тысячи естественный язык требования, которые обычно используются для выражения акционер потребности в крупномасштабной программно-интегрированной системе.[1][2][3][4]

Обзор

Количество деталей в большом количестве естественный язык требования для крупномасштабной системы вызывают кратковременную перегрузку памяти[1][5] и может создать барьер, который мешает кому-либо получить глубокое, точное и целостное понимание потребностей системы.[6] Кроме того, из-за использования естественный язык, вероятно, будет много двусмысленностей, псевдонимов, несоответствий, дублирования и проблем неполноты, связанных с информацией о требованиях.[3] Это добавляет неопределенности и сложности. Как правило, в лучшем случае несколько человек хорошо понимают части системы или ситуации, но никто не имеет другого, кроме поверхностного понимания целого, то есть подробного интегрированного поведения системы.

Представление дерева поведения, (с помощью дерева композиции[7] представление, которое решает проблемы с псевдонимами и другие словарные проблемы с большим набором требований) позволяет людям избежать кратковременной перегрузки памяти и обеспечить глубокое, точное, целостное представление потребностей системы[1] это могут понять все заинтересованные стороны потому что он строго использует словарь исходных требований. Поскольку в нотации дерева поведения используется формальная семантика, для любого данного примера это уже есть или может быть сделано исполняемый файл.

Формы дерева поведения

Набор из четырех деревьев поведения требований
Процесс интеграции требований

Единичные и составные или интегрированные формы дерева поведения важны для применения деревьев поведения в системы и программная инженерия.

  • Деревья поведения требований: Первоначально деревья поведения индивидуальных требований (RBT) используются для захвата всех фрагментов поведения в каждом отдельном требовании естественного языка посредством процесса строгого, сохраняющего намерение и словарный запас перевода. Процесс перевода может выявить ряд недостатков в требованиях к естественному языку оригинала.
  • Интегрированные деревья поведения: поскольку набор требований подразумевает интегрированное поведение системы, все отдельные деревья поведения требований могут быть составлены для построения интегрированного дерева поведения (IBT), которое обеспечивает единое целостное представление о возникающем интегрированном поведении системы. Это позволяет построить интегрированное поведение системы. снаружи его требования.[8] Аналогия, помогающая описать этот процесс, - это переход от случайного набора кусочков головоломки к размещению каждой из частей на своем месте. Когда мы делаем это, мы видим каждую часть информации в ее предполагаемом контексте, и мы видим части информации в целом и возникающие свойства целого.

Преобразование всех требований в деревья поведения (RBT) аналогично тому, как если бы все части мозаики были распределены случайным образом на столе - пока мы не сложим все части вместе, мы не сможем увидеть возникающую картину, а также увидеть, отсутствуют ли какие-либо части или нет. не подходит. Построение интегрированного дерева поведения (IBT) позволяет нам это сделать.[2][3]

Процесс разработки поведения

Используемое представление - (критическое)
  • ДЕРЕВЬЯ ПОВЕДЕНИЯ предоставляют средство для развития общего понимания сложная система.
  • Роль СОСТАВНОГО ДЕРЕВА в общем процессе состоит в том, чтобы предоставить средство для преодоления несовершенных знаний, связанных с большим набором требований к системе.
Используемый процесс - (критично)
  • BEHAVIOR ENGINEERING использует деревья поведения для управления сложностью, одновременно развивая общее понимание сложной системы.
  • Это общее, целостное понимание сложной системы, поскольку она объединяет требования, показывает эмерджентное поведение системы, подразумеваемой требованиями.
Этапы процесса моделирования поведения

История

Деревья поведения и концепции их применения в системы и программная инженерия изначально были разработаны Dromey[2][3][9][10] с первой публикацией некоторых ключевых идей в 2001 году.[11] В ранних публикациях по этой работе для описания применения деревьев поведения использовались термины «генная программная инженерия» и «генетический дизайн». Причина первоначального использования слова генетический заключалась в том, что наборы генов, наборы частей головоломки и наборы требований, представленные в виде деревьев поведения, по-видимому, имели несколько общих свойств:

  • они содержат достаточно информации в виде набора, чтобы их можно было составить - с деревьями поведения это позволяет построить систему исходя из ее требований.
  • порядок, в котором были собраны детали, не имел значения - с учетом требований это помогает справиться со сложностью
  • когда все элементы набора были собраны вместе, полученная интегрированная сущность показала набор важных эмерджентные свойства.

Для деревьев поведения важные эмерджентные свойства включают:

  • интегрированное поведение системы, подразумеваемое требованиями
  • согласованное поведение каждого компонента, указанного в требованиях.

Эти генетические параллели в другом контексте были первоначально сформулированы Вулфсоном:[12] (А. Вулфсон, Жизнь без генов, Фламинго, 2000)

Дополнительное значение для использования термина генетический пришел от мыслителя восемнадцатого века. Джамбаттиста Вико, который сказал: «Понять что-то, а не просто уметь описать или проанализировать его на составные части, значит понять, как оно возникло - его происхождение, его рост… истинное понимание всегда генетически».[13] Несмотря на эти законные генетические параллели, было сочтено, что этот акцент привел к путанице с концепцией генетические алгоритмы. В результате срок инженерия поведения был введен для описания процессов, использующих деревья поведения для построения систем. Термин «инженерия поведения» ранее использовался в специализированной области искусственного интеллекта - исследованиях робототехники. Настоящее использование охватывает гораздо более широкую строгую формализацию и интеграцию больших наборов поведенческих и композиционных требований, необходимых для моделирования крупномасштабных систем.

Поскольку нотация дерева поведения была первоначально задумана несколькими людьми из DCCS (Dependable Complex Computer-based Systems Group - совместная Университет Квинсленда, Университет Гриффита исследовательская группа) внесли важный вклад в развитие и уточнение нотации, а также в использование деревьев поведения. В эту группу входят: Дэвид Кэррингтон, Роб Колвин, Джефф Дроми, Ларс Грунске, Ян Хейз, Диана Кирк, Питер Линдси, Тоби Майерс, Дэн Пауэлл, Джон Сигрот, Кэмерон Смит, Ларри Вен, Нисансала Ятапанаге, Кирстен Винтер, Саад Зафар. , Лес Чжэн.

Вероятностные временные деревья поведения были недавно разработаны Колвином, Грунске и Винтером, чтобы можно было выразить надежность, производительность и другие характеристики надежности.[14]

Ключевые идеи

Обозначение дерева поведения

Основные элементы нотации дерева поведения

Дерево поведения используется для формального представления фрагмент поведения в каждом индивидуальном требовании. Поведение для крупномасштабной системы в целом, где параллелизм допускается, абстрактно выступает как набор связь последовательных процессов. Обозначение дерева поведения фиксирует эти составные состояния компонентов в простой древовидной форме.

Поведение выражается в терминах компонентов, реализующих состояния, и компонентов, создающих и разрушающих отношения. Используя логические и графические формы соглашений, найденных в языки программирования, компоненты могут поддерживать действия, состав, события, поток управления, поток данных и потоки.[3]

Теги прослеживаемости (см. Раздел 1.2 нотации дерева поведения[15]) в узлах дерева поведения связывают формальное представление с соответствующими естественный язык требование. Деревья поведения точно отражают поведение, выраженное в естественном языке функциональных требований. Деревья поведения требований строго используют словарь требований естественного языка, но используют графические формы для композиции поведения, чтобы исключить риск двусмысленности. Делая это, они обеспечивают прямую и четко прослеживаемую связь между тем, что выражается в представлении естественного языка, и его формальная спецификация.[16]

В основе обозначения лежит то, что поведение всегда связано с каким-либо компонентом. Состояния компонентов, которые представляют узлы поведения, составляются последовательно или одновременно для построения дерева поведения, которое представляет поведение, выраженное в требованиях естественного языка. Дерево поведения с конечными узлами может возвращаться (обозначено добавлением символа каретка оператор ^) к родительскому узлу, чтобы повторить поведение или запустить новый поток (обозначенный двумя символами курсора ^^).

Дерево поведения определяет изменения состояния компонентов, то, как данные и управление передаются между компонентами и как потоки взаимодействовать. Есть конструкции для создания и разрыва отношений. Также есть конструкции для настройки и тестирования состояния компонентов, а также механизмов для межпроцессного взаимодействия которые включают передача сообщений (события), блокировка общих переменных и синхронизация.

Полную ссылку на нотацию дерева поведения версии 1.0 см .: Нотация дерева поведения v1.0 (2007)[15]

Семантика

В формальная семантика деревьев поведения задается через алгебра процессов и это операционная семантика.[17] Семантика была использована как основа для разработки симуляция, проверка модели и анализ режимов и последствий отказов.[17][18][19]

Перевод требований

Пример перевода требований
Интеграция дерева поведения требований

Перевод требований - это средство преодоления неформально-формального барьера. Рассмотрим процесс перевода требования R1 ниже. Первыми задачами являются идентификация компонентов (смелый), определите поведение (подчеркивать) и определить показатели заказа (курсив), в котором имеет место поведение. Затем можно построить соответствующее дерево поведения.

Что ясно из результата этого процесса, так это то, что кроме местоимений, определенных артиклей и т. Д., По существу, все слова в предложениях, которые способствуют описываемому ими поведению, были учтены и использованы.

Интеграция требований

После того, как набор требований формализован в виде отдельных деревьев поведения требований, необходимо использовать два общих свойства систем и требований, чтобы продолжить составление интегрированного дерева поведения:

  • В общем, фрагмент поведения, выраженный требованием, всегда связан с предварительным условием, которое должно быть выполнено до того, как поведение может иметь место (это предварительное условие может быть выражено или не выражено в требовании).
  • Если требование действительно является частью системы, то какое-то другое требование в наборе должно устанавливать предварительное условие, необходимое в (1).
Для требований, представленных в виде деревьев поведения, это означает нахождение корневого узла одного дерева в другом дереве поведения и объединение двух деревьев в этом узле.

Пример ниже иллюстрирует интеграцию требований для двух требований, R1 и R3. Другими словами, он показывает, как взаимодействуют эти два требования.

Операции над интегрированными деревьями поведения

После того, как интегрированное дерево поведения составлено, с ним можно выполнять ряд важных операций.

Осмотр: обнаружение и исправление дефектов

В целом, многие дефекты становятся более заметными, когда есть комплексное представление о требованиях.[1] и каждое требование помещено в контекст поведения, где оно должно выполняться. Например, гораздо легче определить, является ли набор условий или событий, исходящих от узла, полным и согласованным. Теги прослеживаемости[15] также упрощают возврат к исходным требованиям к естественному языку. Также существует возможность автоматизировать ряд проверок дефектов и согласованности интегрированного дерева поведения.[20]

Когда все дефекты были исправлены и IBT логически согласован и завершен, он становится деревом поведения модели (MBT), которое служит формальная спецификация для поведения системы, которая была построена на основе исходных требований. Это четко определенная точка остановки для фазы анализа. С другим обозначения моделирования и методы (например, с UML ) он становится менее четким, когда моделирование можно прекратить.[21] В некоторых случаях может потребоваться преобразование частей дерева поведения модели, чтобы сделать спецификацию исполняемый файл. После того, как MBT стал исполняемым, можно выполнить ряд других проверок надежности.

Моделирование

Дерево поведения модели можно легко смоделировать для исследования динамических свойств системы. Для поддержки этих действий были созданы как символический инструмент, так и графический инструмент.[22][23]

Проверка модели

Был написан переводчик для преобразования дерева моделей поведения на язык «систем действий». Эти данные затем можно передать в программу проверки моделей SAL.[24][25] для того, чтобы можно было проводить проверки на соответствие определенным свойствам безопасности.[18][26]

Анализ видов и последствий отказов (FMEA)

Проверка модели часто применяется к системным моделям для проверки того, что опасные состояния не могут быть достигнуты во время нормальной работы системы.[27] Можно объединить проверку модели с деревьями поведения для обеспечения автоматической поддержки анализ режимов и последствий отказов (FMEA).[18] Преимущество использования деревьев поведения для этой цели заключается в том, что они позволяют формальный метод аспекты подхода должны быть скрыты от неспециалистов.

Требования меняются

Идеал, к которому стремятся, реагируя на изменение функциональные требования для системы заключается в том, что ее можно быстро определить:

  • где внести изменения,
  • как изменение влияет на архитектуру существующей системы,
  • какие компоненты системы затронуты изменением, и
  • какие поведенческие изменения необходимо внести в компоненты (и их интерфейсы), на которые повлияло изменение требований.[4]

Поскольку система, вероятно, претерпит множество наборов изменений за время своего обслуживания, также существует потребность в регистрации, управлении и оптимизации развития системы, обусловленной последовательностью изменений.

Модель прослеживаемости, которая использует деревья поведения как формальную нотацию для представления функциональных требований, выявляет влияние изменений на различные типы проектных конструкций (документов), вызванное изменениями требований.[28] Модель вводит концепцию эволюционных проектных документов, которые фиксируют историю изменений дизайна. Из этих документов можно получить любую версию проектного документа, а также разницу между любыми двумя версиями. Важным преимуществом этой модели является то, что большая часть процедуры создания этих эволюционных проектных документов может поддерживаться автоматизированными инструментами.[20]

Генерация и исполнение кода

Древовидное представление интегрированного поведения системы дает несколько важных преимуществ в качестве исполняемой модели. Он четко разделяет задачи интеграция компонентов от задачи индивидуального реализация компонента. Интегрированное поведение системы, возникающее в результате интеграции требований, может использоваться в качестве основы для создания проекта путем применения проектных решений. Результатом является дерево поведения дизайна (DBT):[3] исполняемая спецификация интеграции многопоточных компонентов, которая была построена на основе исходных требований.

Модели дерева поведения выполняются на виртуальной машине, которая называется средой выполнения поведения (BRE). BRE связывает вместе составные части используя промежуточное ПО,[29] позволяя компонентам быть независимыми программами, написанными на одном из нескольких языков, которые могут выполняться на распределенная среда. BRE также содержит выражение парсер который автоматически выполняет простые операции, чтобы минимизировать объем кода, который необходимо вручную реализовать в компоненте.

В выполнение компонентов поддерживается представлениями, которые автоматически извлекаются из DBT. Эти представления предоставляют деревья поведения компонентов (CBT) отдельных компонентов вместе с интерфейсами отдельных компонентов. Эта информация вместе с информацией в интегрированном дереве композиции (ICT), собранной о каждом отдельном компоненте, предоставляет информацию, необходимую для реализации каждого отдельного компонента.

Несколько BRE могут быть связаны вместе, чтобы сформировать сложные системы, используя конструкцию системы систем и среду интеграции компонентов проектирования поведения (BECIE). BECIE также используется для мониторинга и управления моделями дерева поведения, выполняемыми в BRE, аналогично диспетчерский контроль и сбор данных (SCADA) системы, используемые в управлении производственными процессами.

Для тематических исследований были разработаны исполняемые деревья поведения.[21] включая автоматическую охрану поездов,[30] мобильные роботы с динамическим сопровождением объекта, амбулаторный инфузионный насос[19] и системы управления светофорами. Также доступна версия BRE, подходящая для встраиваемых систем (eBRE), которая имеет ограниченные функциональные возможности, чтобы приспособить ее к микроконтроллерам с малой занимаемой площадью.

Приложения

Моделирование дерева поведения может применяться и применялось в различных приложениях на протяжении ряда лет. Некоторые из основных областей применения описаны ниже.

Крупномасштабные системы

Моделирование крупномасштабных систем с большим набором требований естественного языка всегда было основным направлением тестирования деревьев поведения и всего процесса разработки поведения. Для проведения этих оценок и испытаний метода потребовалась работа с рядом отраслевых партнеров и государственных ведомств в Австралии. Изученные системы включают значительное количество систем защиты, корпоративных систем, транспортных систем, информационных систем, систем здравоохранения и сложных систем управления со строгими требованиями безопасности. Все результаты этих исследований коммерчески конфиденциальны. Однако результаты обширной индустрии[5][6] с Raytheon Австралия представлена ​​ниже в разделе «Промышленность». Вся эта работа неизменно показывала, что путем преобразования требований и создания динамических и статических интегрированных представлений требований на ранней стадии обнаруживается очень значительное количество серьезных дефектов, помимо дефектов, которые обнаруживаются с помощью передовой отраслевой опыт.[31][32]

Встроенные системы

Несоответствие проекта требованиям системы может привести к перерасходу графика и затрат.[33] Если есть также критические проблемы надежности, невыполнение требований системы может иметь опасные для жизни последствия.[34] Однако в современных подходах обеспечение выполнения требований часто откладывается до конца процесса разработки во время цикла тестирования и отладки.[35] В этой работе описывается, как подход к разработке системы, поведенческая инженерия, может быть использован для разработки программного обеспечения для встроенные системы.[26] В результате модельно-ориентированная разработка подход, который может создать встроенное системное программное обеспечение, удовлетворяющее его требованиям, в результате применения процесса разработки.

Аппаратно-программные комплексы

Многие крупномасштабные системы состоят из взаимосвязанного программного и аппаратного обеспечения. Различная природа программного и аппаратного обеспечения означает, что они часто моделируются отдельно с использованием разных подходов. Впоследствии это может привести к проблемам интеграции из-за несовместимых предположений о взаимодействии аппаратного и программного обеспечения.[30] Эти проблемы могут быть преодолены путем интеграции деревьев поведения с Modelica, математическое моделирование подход.[30] Компоненты среды и оборудования моделируются с помощью Modelica и интегрируются с исполняемой программной моделью, использующей деревья поведения.

Контроль доступа на основе ролей

Для правильного выполнения сложных контроль доступа Требования, важно, чтобы утвержденные и проверенные требования были эффективно интегрированы с остальной частью системы.[36] Также важно, чтобы система могла быть валидирована и проверена на раннем этапе процесса разработки. Разработана интегрированная модель управления доступом на основе ролей.[37] Модель основана на нотации графического дерева поведения и может быть проверена с помощью симуляция, а также проверено с помощью модель проверки. Используя эту модель, требования к контролю доступа могут быть интегрированы с остальной частью системы с самого начала, потому что: одна нотация используется для выражения как контроля доступа, так и функциональные требования; может быть принят систематический и поэтапный подход к построению формальной спецификации дерева поведения; и спецификацию можно смоделировать и проверить модель. Эффективность модели была оценена с использованием тематического исследования с требованиями распределенного контроля доступа.[36]

Биологические системы

Поскольку деревья поведения описывают сложное поведение, их можно использовать для описания ряда систем, не ограничиваясь только компьютерными.[38] В биологическом контексте BT могут использоваться для составления процедурной интерпретации биологических функций, описанных в исследовательских документах, рассматривая документы как документы с требованиями, как описано выше. Это может помочь построить более конкретное описание процесса, чем это возможно только при чтении, а также может быть использовано в качестве основы для сравнения конкурирующих теорий в альтернативных статьях. В текущих исследованиях нотация дерева поведения используется для разработки моделей функции мозга у крыс в условиях условный страх.

Моделирование игрового ИИ

Основная статья: Дерево поведения (искусственный интеллект, робототехника и управление)

Хотя BT стали популярными для моделирования искусственный интеллект в компьютерных играх, таких как Halo[39] и Спора,[40] эти типы деревьев сильно отличаются от описанных на этой странице и ближе к сочетанию иерархических конечные автоматы или же деревья решений. Моделирование футболистов также было успешным применением BT.[41][42]

Тестирование на основе модели

[43] - это подход к тестированию программного обеспечения, при котором тестировщики должны создавать тестовые модели на основе требований тестируемого программного обеспечения (SUT). Традиционно в качестве языка моделирования используются диаграммы состояний UML, конечные автоматы, EFSM и блок-схемы. Недавно появился интересный подход, в котором в качестве языка моделирования используется Event-Driven Swim Lane Petri Net (EDSLPN). Нотацию дерева поведения следует также рассматривать как хорошую нотацию моделирования для MBT, и у нее есть несколько преимуществ среди других нотаций:

  1. Он имеет тот же уровень выразительности, что и диаграммы состояний UML и EDSLPN.
  2. Его интуитивно понятно использовать в качестве обозначения моделирования из-за его графической природы.
  3. Каждый узел дерева поведения имеет тег требований, что делает создание матрицы прослеживаемости от требования до тестового артефакта простым делом.

Такая попытка здесь была сделана.[44] MBTester состоит из разработчика моделей и механизма генерации тестовых примеров. Владельцы бизнеса или тестировщики переводят свои требования в деревья поведения с помощью средства моделирования, а затем (необязательно) интегрируют несколько связанных деревьев поведения в составное. Дерево поведения может быть загружено в серверную часть для автоматического создания тестовых примеров, тестовых сценариев и тестовых данных.

Масштабируемость и отраслевые приложения

Снимок экрана инструмента среды поддержки инженерного поведения
Интегрированное дерево поведения - большая система (более 1000 требований)

Первые промышленные испытания для проверки осуществимости метода и уточнения его возможностей были проведены в 2002 году. За последние три года был проведен ряд систематических отраслевых испытаний крупномасштабных оборонных, транспортных и корпоративных систем.[5][31] В ходе этой работы было установлено, что метод масштабируется для систем с большим количеством требований, но также важно использовать поддержку инструментов.[22][45] для эффективной навигации и редактирования таких больших интегрированных представлений графических данных. Эта работа с промышленностью принесла несколько основных результатов. В среднем по ряду проектов 130 подтвержденных основных дефектов на 1000 требований последовательно выявлялись после обычных проверок и исправлений.[31] При менее зрелых наборах требований наблюдается гораздо более высокий процент брака.

Важной частью этой работы с промышленностью было применение аналитической части метода к шести крупномасштабным оборонным проектам. Raytheon Австралия. Они видят в этом методе «ключевую стратегию снижения риска, которую можно использовать как при разработке решений, так и как средство информирования клиента о проблемах с документацией по приобретению».[32][46] Результатом этих промышленных испытаний стала совместная разработка[6] совместно с Raytheon Australia - мощного отраслевого инструмента для поддержки анализа, редактирования и отображения больших интегрированных наборов требований.[45] Более подробную информацию об отраслевых исследованиях можно найти на веб-сайте Behavior Engineering.[47]

Д-р Терри Стивенсон (главный технический директор, Raytheon Австралия) и г-н Джим Бостон (старший менеджер проекта Raytheon Австралия), г-н Адриан Питман из Австралийская организация материально-технического снабжения, Д-р Келвин Росс (генеральный директор, K.J. Ross & Associates) и Кристин Корниш (Bushell & Cornish) предоставили особые возможности, необходимые для поддержки этого исследования и проведения отраслевых испытаний.[5][31] и живая проектная работа. Работа поддержана Австралийский исследовательский совет – Центр сложных систем ARC и средства, полученные от промышленности.[нужна цитата ]

[48]

Преимущества, преимущества

В качестве представления моделирования поведения деревья поведения обладают рядом существенных преимуществ и преимуществ:

Критика, недостатки

  • Для небольших примеров уровня учебника их древовидная природа означает, что производимые графические модели иногда не так компактны, как диаграмма состояний или же Государственный аппарат характеристики поведения.
  • Поддержка инструментов необходима для навигации по очень большим интегрированным деревьям поведения для систем, которые имеют сотни или тысячи требований.
  • Для групповых прогонов очень больших систем необходимы хорошие средства отображения.
  • Существует потребность в предоставлении дополнительных сложных инструментов для полноценного использования интегрированных моделей дерева поведения.

Смотрите также

Рекомендации

  1. ^ а б c d Дроми, Р. 2007 г. Принципы разработки крупномасштабных программно-интенсивных систем
  2. ^ а б c Р. Г. Дроми, «Формализация перехода от требований к дизайну» В архиве 25 июля 2011 г. Wayback Machine, в «Математические основы для компонентного программного обеспечения - модели для анализа и синтеза», Цзифэн Хэ и Чжиминг Лю (редакторы), Мировая научная серия по разработке на основе компонентов, стр. 156–187, (Приглашенная глава) (2006)
  3. ^ а б c d е ж Р. Г. Дроми, От требований к дизайну: формализация ключевых шагов В архиве 25 июля 2011 г. Wayback Machine, (Приглашенный основной доклад), SEFM-2003, Международная конференция IEEE по разработке программного обеспечения и формальным методам, Брисбен, сентябрь 2003 г., стр. 2–11.
  4. ^ а б Вен, Л., Дроми, Р. 2007 г. От изменения требований к изменению дизайна: формальный путь[постоянная мертвая ссылка ]
  5. ^ а б c d Бостон, Дж. 2008. Raytheon Australia поддерживает новаторские системные исследования В архиве 15 сентября 2009 г. Wayback Machine
  6. ^ а б c Raytheon Australia, 2008 г. Понимание растет на деревьях поведения В архиве 15 сентября 2009 г. Wayback Machine
  7. ^ Поведенческая инженерия. Композиция Деревья В архиве 2 марта 2009 г. Wayback Machine
  8. ^ Зима, К. 2007. Формализация деревьев поведения с помощью CSP
  9. ^ Р. Л. Стекло, «Революционная это идея или нет» В архиве 25 июля 2011 г. Wayback Machine, Сообщения ACM, Vol. 47 (11), стр. 23–25, ноябрь 2004 г.
  10. ^ Р. Г. Дроми, "Восхождение через кирпичную стену" без серебряной пули " В архиве 25 июля 2011 г. Wayback Machine, Программное обеспечение IEEE, Vol. 23, № 2, стр. 118–120 (март 2006 г.)
  11. ^ Р. Г. Дроми, Генетическая программная инженерия - упрощение дизайна с использованием интеграции требований, Рабочая конференция IEEE по архитектуре сложных и динамических систем, Брисбен, декабрь 2001 г.
  12. ^ А. Вулфсон, Жизнь без генов, Фламинго, 2000, ISBN  0-00-255618-9
  13. ^ Берлин, I. Кривое дерево человечества: главы истории идей, под ред. Х. Харди, Princeton University Press, 1998. ISBN  0-691-05838-5
  14. ^ Колвин Р., Грюнске Л., Винтер К. 2007 г. Вероятностные временные деревья поведения В архиве 25 июля 2011 г. Wayback Machine
  15. ^ а б c d Группа дерева поведения, Центр сложных систем ARC, 2007.Обозначение дерева поведения v1.0 (2007)
  16. ^ Дромей, Р. «Генетический дизайн: повышение нашей способности справляться со сложностью требований» В архиве 25 июля 2011 г. Wayback Machine, в S.Leue и T.J. Систра, Сценарии, Конспект лекций по информатике, LNCS 3466, стр. 95–108, 2005.
  17. ^ а б c Колвин, Р., Хейс, И.Дж. 2006 г. Семантика деревьев поведения
  18. ^ а б c d Л.Грунске, П.Линдси, Н.Ятапанаге, К. Винтер, Автоматический анализ видов отказов и последствий на основе проектной спецификации высокого уровня с деревьями поведения, Пятая международная конференция по интегрированным формальным методам (IFM-2005), Эйндовен, Нидерланды, 2005.
  19. ^ а б c Зафар С. и Дромей Р. Г. (2005 г.), Интеграция требований безопасности и защиты в дизайн встроенной системы. В архиве 25 июля 2011 г. Wayback Machine Азиатско-Тихоокеанская конференция по разработке программного обеспечения 2005 г., 15–17 декабря, Тайбэй, Тайвань. Издательство IEEE Computer Society Press. С. 629–636.
  20. ^ а б Смит, К., Винтер, К., Хейс, И., Дроми, Р., Линдси, П., Кэррингтон, Д .: Среда для построения системы исходя из ее требований, 19-я Международная конференция IEEE по автоматизированной разработке программного обеспечения, Линц, Австрия, сентябрь (2004 г.).
  21. ^ а б Дроми, Р. Использование деревьев поведения для моделирования автономной системы челнока В архиве 25 июля 2011 г. Wayback Machine, 3-й международный семинар по сценариям и конечным машинам: модели, алгоритмы и инструменты (SCESM04) ICSE Workshop W5S, Эдинбург, 25 мая 2004 г.
  22. ^ а б c Л. Вен, Р. Колвин, К. Лин, Дж. Сигрот, Н. Ятапанедж, Р. Г. Дроми, 2007, «Integrare, среда для совместной работы в области дизайна, ориентированного на поведение», in Proceedings of the Fourth International Conference on Cooperative Design, Visualization and Engineering, LNCS 4674, pp. 122–131, 2007
  23. ^ К. Сунь, С. Ся, Д. Сунь, Д. Чен. Х.Ф. Шен, В. Цай: «Прозрачная адаптация однопользовательских приложений для многопользовательской совместной работы в реальном времени», Транзакции ACM о взаимодействии компьютера и человека, Том. 13, №4, декабрь 2006 г., стр. 531–582.
  24. ^ Бенсалем, С., Ганеш, В., Лакнек, Ю., Муньос, К., Оур и др.: «Обзор SAL», Пятый семинар НАСА по формальным методам Лэнгли (LFM 2000), 2000, стр. 187– 196.
  25. ^ Рашби, Дж. Автоматизированные формальные методы 2006 AFM-2006, Автоматизированные формальные методы 2006, Сиэтл, август 2006 г., стр. 6–7.
  26. ^ а б c Зафар С. и Дромей Р. Г., 2005. Управление сложностью моделирования встроенных систем. В архиве 25 июля 2011 г. Wayback Machine Конференция по системному проектированию / тестированию и оценке 2005 г., 7–9 ноября, Брисбен, Австралия
  27. ^ Грюнске, Л., Колвин, Р., Винтер, К. Поддержка вероятностной проверки моделей для количественной оценки систем методом FMEA. QEST 2007. Четвертая Международная конференция по количественной оценке систем, 17-19 сентября 2007 г., стр. 119–128.
  28. ^ Вен, Л., Дроми, Р. 2005 г. Нормализация архитектуры для систем на основе компонентов В архиве 25 июля 2011 г. Wayback Machine Труды 2-го Международного семинара по формальным аспектам компонентного программного обеспечения FACS'05, стр. 247–261.
  29. ^ RTI Inc. 2007 "Соответствие требованиям реального времени в интегрированных системах защиты", Белая книга RTI В архиве 20 сентября 2008 г. Wayback Machine.
  30. ^ а б c Майерс, Т., Фрицсон, П., Дроми, Р.Г. 2008 г. Полная интеграция программного и аппаратного моделирования для крупномасштабных систем. 2-й Международный семинар по объектно-ориентированным языкам и инструментам на основе уравнений (EOOLT 2008), Кипр, июль 2008 г., стр. 5–15.
  31. ^ а б c d е ж Пауэлл, Д. 2007. Оценка требований с использованием деревьев поведения - отраслевые выводы В архиве 25 июля 2011 г. Wayback Machine
  32. ^ а б c Бостон, Дж. (Raytheon Australia), Деревья поведения - как они улучшают инженерное поведение?[постоянная мертвая ссылка ], 6-я ежегодная групповая конференция по процессам разработки программного обеспечения и систем (SEPG 2008), Мельбурн, август 2008 г.
  33. ^ Баркер, Д. 2000. Технология моделирования требований: видение лучших, быстрых и дешевых систем. Материалы осеннего семинара Международного форума пользователей VHDL, 2000 г., стр. 3–6.
  34. ^ Левесон, Н. Г. Безопасное ПО: безопасность систем и компьютеры: [руководство по предотвращению несчастных случаев и потерь, вызванных технологиями]. Издательство Эддисон-Уэсли, 1995. ISBN  0-201-11972-2
  35. ^ Футрелл, Р.Т., Шафер, Д.Ф., Шафер, Л.И. Управление проектами качественного программного обеспечения (серия Институт качества программного обеспечения). Прентис Холл, 2002 ISBN  0-13-091297-2
  36. ^ а б Зафар, С. Колвин, Р., Винтер, К., Ятапанаге, Н., Дроми, Р. Ранняя проверка и проверка распределенной модели управления доступом на основе ролей. 14-я Азиатско-Тихоокеанская конференция по разработке программного обеспечения, Нагоя, Япония, декабрь 2008 г., стр. 430–437.
  37. ^ а б Зафар, С., К. Винтер, Р. Колвин, Р. Г. Дроми, «Проверка интегрированной модели управления доступом на основе ролей» В архиве 25 июля 2011 г. Wayback Machine, 1-й международный семинар - Азиатская рабочая конференция по проверенному программному обеспечению (AWCVS'06), стр. 230–240, Макао, октябрь 2006 г.
  38. ^ а б Милошевич, З., Дромей, Р. О выражении и мониторинге поведения в контрактах, EDOC 2002, Труды 6-й Международной конференции по корпоративным распределенным объектным вычислениям, Лозанна, Швейцария, сентябрь 2002 г., стр. 3-14.
  39. ^ Дамиан Исла Решение сложных задач в Halo 2 AI.
  40. ^ Крис Хеккер Мои заметки для лайнера для Spore
  41. ^ Сяо-Вэнь, Терри Лю и Джеки Балтес Интуитивно понятная и гибкая архитектура интеллектуальных мобильных роботов 2-я Международная конференция по автономным роботам и агентам, 13–15 декабря 2004 г., Палмерстон-Норт, Новая Зеландия
  42. ^ Юкико Хосино, Цуёси Такаги, Уго Ди Профио и Масахиро Фудзита Описание и контроль поведения с помощью модуля поведения персонального робота
  43. ^ Тестирование на основе моделей (MBT) Тестирование на основе модели
  44. ^ MBTester [1]
  45. ^ а б Филлипс, В. (Raytheon Australia), «Реализация инструмента анализа дерева поведения с помощью платформ разработки Eclipse»[постоянная мертвая ссылка ], Австралийская конференция по разработке программного обеспечения (ASWEC’08), Перт, март 2008 г.
  46. ^ МакНиколас, Д. (Raytheon Australia), 2007. Выгоды для индустрии поведенческой инженерии[постоянная мертвая ссылка ]
  47. ^ Поведенческая инженерия. Веб-сайт Behavior Engineering В архиве 1 марта 2009 г. Wayback Machine
  48. ^ Подробнее см .:
  49. ^ Лин, К., Чен, Д., Сан, К., Дроми, Р.Г., Стратегия обслуживания ограничений и приложения в средах для совместной работы в реальном времени[постоянная мертвая ссылка ], 2-я Международная конференция по совместному проектированию, визуализации и проектированию (CDVE2005), 2005 г.
  50. ^ Лин, К., Чен, Д., Дромей, Р.Г., Сан, Чехия: Распространение ограничений многостороннего потока данных в системах для совместной работы в реальном времени В архиве 25 июля 2011 г. Wayback Machine, IEEE, 2-я Международная конференция по совместным вычислениям: сети, приложения и совместная работа (CollaborateCom 2006), Атланта, Джорджия, США, ноябрь 2006 г.
  51. ^ Грюнске, Л., Винтер, К., Колвин, Р., «Временные деревья поведения и их применение для проверки систем реального времени» В архиве 18 ноября 2008 г. Wayback Machine, Материалы 18-й Австралийской конференции по разработке программного обеспечения (AEWEC 2007), апрель 2007 г., приняты к публикации.

внешняя ссылка