行動ツリー

動作ツリーは、主にシステムおよびソフトウェアエンジニアリングで使用される正式なグラフィカルモデリング言語 です。動作ツリーは、大規模なソフトウェア統合システムの利害関係者のニーズを表現するために通常使用される数百または数千の自然言語要件を明確に表現するために、明確に定義された表記法を採用しています。^{[1] [2] [3] [4]}

大規模システムに対する自然言語による要件が多数ある場合、その詳細さの量は短期記憶の過負荷を引き起こし^{[1] [5]}、システムのニーズを深く、正確かつ総合的に理解することを妨げる障壁を作り出す可能性があります。^[6]また、自然言語の使用により、要件情報に関連する曖昧さ、別名、矛盾、冗長性、不完全性の問題が多く発生する可能性があります。^[3]これにより、不確実性と複雑さがさらに増します。一般的に、せいぜい数人がシステムまたは状況の一部をよく理解していますが、全体、つまりシステムの詳細な統合された動作については、誰も表面的な理解しかしていません。

動作ツリー表現は、(大規模な要件セットにおけるエイリアスやその他の語彙の問題を解決するコンポジションツリー^{[7]表現の助けを借りて)、短期的な記憶の過負荷を回避し、元の要件の語彙を厳密に使用するため、すべての}利害関係者が理解できるシステムニーズ^{[1]の深く正確な全体的な表現を生成することを可能にします。動作ツリー表記法は}形式意味論を使用するため、任意の例に対して、すでに実行可能になっているか、実行可能にすることができます。

単一の動作ツリー形式と複合または統合された動作ツリー形式はどちらも、システムおよびソフトウェア エンジニアリングにおける動作ツリーの応用において重要です。

• 要件動作ツリー: 最初に、個々の要件動作ツリー (RBT) を使用して、厳密で意図と語彙を保持する翻訳プロセスによって、個々の自然言語要件の動作のすべてのフラグメントをキャプチャします。翻訳プロセスによって、元の自然言語要件のさまざまな欠陥が明らかになることがあります。
• 統合動作ツリー: 要件のセットはシステムの統合動作を意味するため、すべての個別の要件動作ツリーを組み合わせて、システムの統合動作の単一の全体的ビューを提供する統合動作ツリー (IBT) を構築できます。これにより、要件からシステムの統合動作を構築できます。 ^[8]このプロセスを説明するのに役立つアナロジーは、ランダムに配置されたジグソーパズルのピースのセットから、各ピースを適切な場所に配置するまでの移行です。これを行うと、各情報が意図されたコンテキストで表示され、情報全体が全体として、そして全体の出現特性がわかります。

すべての要件を行動ツリー (RBT) に変換することは、ジグソーパズルのピースをテーブルの上にランダムに広げるのと似ています。すべてのピースを組み合わせるまで、全体像が見えず、ピースが欠けていたり、合わない部分があるかどうかもわかりません。統合行動ツリー (IBT) を構築することで、これが可能になります。^{[2] [3]}

使用された表現 – (重要)

• 行動ツリーは、複雑なシステムについての共通理解を深めるための手段を提供します。
• 全体的なプロセスにおける COMPOSITION TREE の役割は、システムの大規模な要件セットに関連する不完全な知識を克服するための手段を提供することです。

使用されたプロセス – (重要)

• 動作エンジニアリングでは、動作ツリーを使用して複雑さを制御しながら、複雑なシステムに対する共通の理解を深めます。
• 複雑なシステムについての共有された全体的な理解は、要件を統合するため、要件によって暗示されるシステムの新たな動作を示します。

動作ツリーと、それをシステムおよびソフトウェア エンジニアリングに適用するための概念は、もともと Dromey ^{[2] [3] [9] [10]}によって開発され、2001 年にいくつかの主要なアイデアが初めて公開されました。 ^[11]この研究に関する初期の出版物では、動作ツリーの適用を説明するために「遺伝的ソフトウェア エンジニアリング」および「遺伝的設計」という用語が使用されていました。遺伝的という単語が最初に使用された理由は、動作ツリーとして表現される遺伝子のセット、ジグソー パズルのピースのセット、および要件のセットがすべて、いくつかの重要な特性を共有しているように見えたためです。

• それらは、構成を可能にするために十分な情報のセットを含んでいた。動作ツリーを使用すると、要件に基づいてシステムを構築することができる。
• ピースを組み立てる順序は重要ではない。要件があれば、複雑さに対処するのに役立つ。
• セットのすべてのメンバーをまとめると、結果として得られる統合エンティティは、一連の重要な創発特性を示しました。

行動ツリーにとって重要な創発特性には以下が含まれる。

• 要件によって暗示されるシステムの統合された動作
• 要件で参照される各コンポーネントの一貫した動作。

これらの遺伝的類似点は、別の文脈では、もともとウルフソンによって説明されたものである。^[12] (A. ウルフソン、Living Without Genes、Flamingo、2000)

遺伝的という用語の使用にさらなる重みを与えたのは、18世紀の思想家ジャンバッティスタ・ヴィーコの次の言葉です。「何かを理解するということは、単にそれを記述したり、構成要素に分析したりするだけではなく、それがどのようにして生まれたのか、つまりその起源、成長を理解するということである。…真の理解は常に遺伝的である」^{[13] 。これらの正当な遺伝的類似点にもかかわらず、この強調は}遺伝的アルゴリズムの概念との混同につながると感じられました。その結果、動作ツリーを利用してシステムを構築するプロセスを説明するために、動作エンジニアリングという用語が導入されました。「動作エンジニアリング」という用語は、以前は人工知能の専門分野であるロボット研究で使用されていました。現在の用法は、大規模システムをモデル化するために必要な動作および構成要件の大規模なセットの、はるかに広範で厳密な形式化と統合を包含しています。

ビヘイビア ツリー表記法が最初に考案されて以来、DCCS (Dependable Complex Computer-based Systems Group –クイーンズランド大学とグリフィス大学の共同研究グループ) の多くの人々が、表記法の進化と改良、およびビヘイビア ツリーの使用に重要な貢献をしてきました。このグループのメンバーには、David Carrington、Rob Colvin、Geoff Dromey、Lars Grunske、Ian Hayes、Diana Kirk、Peter Lindsay、Toby Myers、Dan Powell、John Seagrott、Cameron Smith、Larry Wen、Nisansala Yatapanage、Kirsten Winter、Saad Zafar、Forest Zheng が含まれます。

確率的時間動作木は、信頼性、パフォーマンス、その他の信頼性特性を表現できるように、コルビン、グルンスケ、ウィンターによって最近開発されました。^[14]

動作ツリーは、個々の要件における動作の断片を形式的に表現するために使用されます。同時実行が認められる大規模システムの動作は、一般的に、通信する一連の連続プロセスとして抽象的に表されます。動作ツリー表記法は、これらの構成されたコンポーネント状態を単純なツリーのような形式で表現します。

動作は、状態を実現するコンポーネントと、関係を作成および破壊するコンポーネントの観点から表現されます。プログラミング言語に見られる規則のロジックとグラフィック形式を使用して、コンポーネントはアクション、構成、イベント、制御フロー、データフロー、およびスレッドをサポートできます。^[3]

^{動作ツリーノードのトレーサビリティタグ（動作ツリー表記法[15]}のセクション1.2を参照）は、形式表現を対応する自然言語要件にリンクします。動作ツリーは、機能要件の自然言語表現で表現された動作を正確に捉えます。要件動作ツリーは、自然言語要件の語彙を厳密に使用しますが、あいまいさのリスクを排除するために、動作の構成にグラフィカル形式を使用します。これにより、自然言語表現で表現されたものとその形式仕様との間に、直接的で明確に追跡可能な関係が提供されます。^[16]

表記法の基本は、動作が常に何らかのコンポーネントに関連付けられているということです。動作のノードを表すコンポーネント状態は、自然言語の要件で表現された動作を表す動作ツリーを構築するために、順次または同時に構成されます。リーフ ノードを持つ動作ツリーは、動作を繰り返すために祖先ノードに戻る (キャレット演算子 ^ を追加して表される) か、新しいスレッドを開始する (2 つのキャレット ^^ で表される) 場合があります。

動作ツリーは、コンポーネントの状態の変化、コンポーネント間でデータと制御を渡す方法、およびスレッドが相互作用する方法を指定します。関係を作成および解除するための構成要素があります。また、コンポーネントの状態を設定およびテストするための構成要素や、メッセージ パッシング(イベント)、共有変数のブロック、同期などのプロセス間通信のメカニズムもあります。

動作ツリー表記法バージョン1.0の完全なリファレンスについては、以下を参照してください。動作ツリー表記法v1.0（2007）^[15]

動作木の形式意味論はプロセス代数とその操作的意味論によって与えられる。^{[17]この意味論は}シミュレーション、モデル検査、故障モード影響分析の開発の基礎として使われてきた。^{[17] [18] [19]}

要件の翻訳は、非公式と公式の境界を越えるための手段です。以下の要件 R1 の翻訳プロセスを検討してください。最初のタスクは、コンポーネント (太字) の識別、動作 (下線) の識別、および動作が行われる 順序の指標 (斜体) の識別です。その後、対応する動作ツリーを構築できます。

このプロセスの結果から明らかなのは、代名詞や定冠詞などを除けば、文中にある、説明している行動に寄与する単語は基本的にすべて考慮され、使用されているということです。

要件セットが個別の要件動作ツリーとして形式化されたら、統合動作ツリーの作成を進めるために、システムと要件の 2 つの共同プロパティを活用する必要があります。

• 一般に、要件によって表現される動作のフラグメントには、動作が発生する前に満たす必要がある前提条件が常に関連付けられています (この前提条件は、要件で表現される場合も、表現されない場合もあります)。
• 要件が実際にシステムの一部である場合、セット内の他の要件が（1）で必要な前提条件を確立する必要があります。

動作ツリーとして表現される要件の場合、これは、あるツリーのルート ノードが他の動作ツリーのどこに出現するかを見つけ、そのノードで 2 つのツリーを統合することになります。

以下の例は、2 つの要件 R1 と R3 の要件統合を示しています。つまり、これら 2 つの要件がどのように相互作用するかを示しています。

統合された動作ツリーが構成されると、それに対して実行できる重要な操作がいくつかあります。

一般的に、要件の統合ビュー^[1]があり、各要件が実行する必要がある動作コンテキストに配置されている場合、多くの欠陥がはるかに目に見えるようになります。たとえば、ノードから発生する一連の条件またはイベントが完全で一貫しているかどうかを判断するのがはるかに簡単になります。トレーサビリティタグ^[15]を使用すると、元の自然言語の要件を簡単に参照することもできます。統合された動作ツリーで、いくつかの欠陥と一貫性のチェックを自動化する可能性もあります。^[20]

すべての欠陥が修正され、IBTが論理的に一貫して完全なものになると、モデル動作ツリー（MBT）となり、元の要件から構築されたシステムの動作の正式な仕様として機能します。これは、分析フェーズの明確に定義された停止ポイントです。他のモデリング表記法や手法（UMLなど）では、モデリングを停止するタイミングはそれほど明確ではありません。^{[21]場合によっては、仕様}を実行可能にするために、モデル動作ツリーの一部を変換する必要があります。MBTが実行可能になると、他の多くの信頼性チェックを実行できるようになります。

モデル動作ツリーは、システムの動的特性を調べるために簡単にシミュレートできます。これらのアクティビティをサポートするために、シンボリックツールとグラフィックスツールの両方が構築されています。^{[22] [23]}

モデルの動作ツリーを「アクションシステム」言語に変換するトランスレータが開発されました。この入力はSALモデルチェッカー^{[24] [25]}に入力され、特定の安全性とセキュリティのプロパティが満たされているかどうかをチェックできるようになります。^{[18] [26]}

モデル検査は、システムの通常動作中に危険な状態に到達できないことを確認するために、システムモデルによく適用されています。^{[27]モデル検査と動作ツリーを組み合わせて、}故障モード影響解析（FMEA）の自動サポートを提供することができます。 ^[18]この目的で動作ツリーを使用する利点は、アプローチの形式手法の側面を非専門家のユーザーから隠すことができることです。

システムの 機能要件の変更に対応する際に求められる理想は、それを迅速に決定できることです。

• どこで変更するか、
• 変更が既存のシステムのアーキテクチャにどのような影響を与えるか
• システムのどのコンポーネントが変更の影響を受けるか、
• 要件の変更によって影響を受けるコンポーネント（およびそのインターフェース）にどのような動作の変更を加える必要があるか。^[4]

システムはサービス期間中に多くの変更を経る可能性が高いため、変更シーケンスによって駆動されるシステムの進化を記録、管理、最適化する必要もあります。

トレーサビリティモデルは、機能要件を表すための正式な表記法として動作ツリーを使用し、要件の変更によって引き起こされるさまざまな種類の設計構成要素（ドキュメント）への変更の影響を明らかにします。^[28]このモデルは、設計の変更履歴を記録する進化的設計ドキュメントの概念を導入しています。これらのドキュメントから、設計ドキュメントの任意のバージョンと任意の2つのバージョン間の差分を取得できます。このモデルの重要な利点は、これらの進化的設計ドキュメントを生成する手順の大部分が自動化ツールによってサポートされることです。^[20]

システムの統合された動作を動作ツリーで表現すると、実行可能なモデルとしていくつかの重要な利点が得られます。コンポーネント統合のタスクと個々のコンポーネント実装のタスクが明確に分離されます。要件の統合から生じるシステムの統合された動作は、設計上の決定を適用して設計を作成するための基礎として使用できます。その結果、設計動作ツリー (DBT) が作成されます。^{[3] は、}元の要件から構築された実行可能なマルチスレッド コンポーネント統合仕様です。

動作ツリーモデルは、動作ランタイム環境（BRE）と呼ばれる仮想マシンで実行されます。BREはミドルウェアを使用してコンポーネントをリンクし、 ^{[29]コンポーネントを}分散環境で実行できる複数の言語のいずれかで記述された独立したプログラムにすることができます。BREには、コンポーネントに手動で実装する必要があるコードの量を最小限に抑えるために、単純な操作を自動的に実行する式パーサーも含まれています。

コンポーネントの実装は、DBT から自動的に抽出可能なビューによってサポートされます。これらのビューは、個々のコンポーネントのコンポーネント動作ツリー (CBT) と個々のコンポーネントのインターフェイスを提供します。この情報は、個々のコンポーネントについてキャプチャされた統合構成ツリー (ICT) の情報とともに、個々のコンポーネントを実装するために必要な情報を提供します。

システムオブシステム構造と動作エンジニアリング コンポーネント統合環境 (BECIE) を使用すると、複数の BRE をリンクして複雑なシステムを形成できます。BECIE は、産業プロセス制御で使用される監視制御およびデータ収集 (SCADA)システムと同様に、BRE 内で実行されている動作ツリー モデルの監視と制御にも使用されます。

実行可能な動作ツリーは、自動列車保護、^[30]、動的物体追跡機能を備えた移動ロボット、歩行型輸液ポンプ^{[19] 、信号管理システムなどのケーススタディ[21]}向けに開発されています。組み込みシステムに適したBREのバージョン（eBRE）も利用可能で、これは機能を縮小して小型のマイクロコントローラに合わせて調整されています。

動作ツリー モデリングは、長年にわたってさまざまなアプリケーションに適用されてきました。主な適用分野のいくつかを以下に説明します。

大規模なシステムを自然言語による要件の大量セットでモデル化することは、常に動作ツリーと全体的な動作エンジニアリング プロセスの試行における主要な焦点でした。この手法の評価と試行には、オーストラリアの多くの業界パートナーや政府部門との作業が伴いました。調査されたシステムには、多数の防衛システム、企業システム、輸送システム、情報システム、健康システム、厳格な安全要件を備えた高度な制御システムが含まれています。これらの研究の結果はすべて商業上の機密です。ただし、Raytheon Australiaとの大規模な業界試行^{[5] [6]}の結果は、以下の業界セクションで示されています。これらの作業で一貫して示されているのは、要件を翻訳し、要件の動的および静的な統合ビューを作成することで、現在の業界のベスト プラクティスで見つかる欠陥よりも多くの重大な欠陥が早期に発見されるということです。^{[31] [32]}

設計がシステム要件を満たさない場合、スケジュールとコストの超過につながる可能性があります。^[33]重大な信頼性の問題もある場合、システム要件を満たさないことは生命を脅かす結果を招く可能性があります。^[34]しかし、現在のアプローチでは、要件が満たされていることの確認は、テストとデバッグのサイクル中の開発プロセスの後半まで延期されることがよくあります。^[35]この研究では、システム開発アプローチである動作エンジニアリングを使用して、組み込みシステム用のソフトウェアを開発する方法について説明します。^[26]その結果、開発プロセスを適用した結果として、要件を満たす組み込みシステムソフトウェアを作成できる モデル駆動型開発アプローチが生まれました。

多くの大規模システムは、相互に依存するソフトウェアとハ​​ードウェアの混合体で構成されています。ソフトウェアとハ​​ードウェアは性質が異なるため、異なるアプローチを使用して別々にモデル化されることがよくあります。これにより、ハードウェアとソフトウェアの相互作用に関する仮定が矛盾するため、統合の問題が発生する可能性があります。^[30]これらの問題は、動作ツリーを数学的モデリング手法であるModelicaと統合することで克服できます。 ^[30]環境とハードウェアコンポーネントはModelicaを使用してモデル化され、動作ツリーを使用する実行可能なソフトウェアモデルと統合されます。

複雑なアクセス制御要件を正しく実装するには、検証および検証された要件がシステムの他の部分と効果的に統合されることが重要です。^[36]また、開発プロセスの早い段階でシステムを検証および検証できることも重要です。統合されたロールベースのアクセス制御モデルが開発されました。^[37]このモデルはグラフィカルな動作ツリー表記法に基づいており、シミュレーションによる検証やモデルチェッカーを使用した検証が可能です。 このモデルを使用すると、アクセス制御要件を最初からシステムの他の部分と統合できます。その理由は、アクセス制御要件と機能要件の両方を単一の表記法で表現できること、正式な動作ツリー仕様を構築するための体系的かつ段階的なアプローチを採用できること、仕様をシミュレートしてモデルチェックできることです。 モデルの有効性は、分散アクセス制御要件のケーススタディを使用して評価されました。^[36]

行動ツリーは複雑な行動を記述するため、コンピュータベースのシステムに限らず、さまざまなシステムの記述に使用できます。^[38]生物学の文脈では、BTは、研究論文を上記の要件ドキュメントとして扱い、論文に記載されている生物学的機能の手順的解釈をまとめるために使用できます。これは、読むだけでは不可能な、より具体的なプロセスの説明を構築するのに役立ち、代替論文の競合する理論を比較するための基礎としても使用できます。進行中の研究では、行動ツリー表記法を使用して、恐怖条件付けを受けたラットの脳機能のモデルを開発しています。

^{BTはHalo [39]}やSpore ^[40]などのコンピュータゲームの人工知能のモデル化に人気があるが、これらのタイプのツリーはこのページで説明されているものとは非常に異なり、階層型有限状態機械または決定木の組み合わせに近い。サッカー選手のモデリングもBTの成功した応用例である。^{[41] [42]}

^[43]は、テスト対象ソフトウェア（SUT）の要件からテストモデルを作成するテスト担当者を必要とするソフトウェアテストのアプローチです。伝統的に、UML状態チャート、FSM、EFSM、フローチャートがモデリング言語として使用されています。最近では、イベント駆動型スイムレーンペトリネット（EDSLPN）をモデリング言語として使用する興味深いアプローチも登場しています。動作ツリー表記法はMBTにも適したモデリング表記法として考えるべきであり、他の表記法に比べていくつかの利点があります。

1. UML状態図やEDSLPNと同等の表現力を持つ
2. グラフィカルな性質のため、モデリング表記法として直感的に使用できます。
3. 各動作ツリーノードには要件タグがあり、これにより要件からテスト成果物までのトレーサビリティマトリックスの作成が簡単になります。

そのような試みがここでなされました。^[44] MBTesterは、モデラーとテストケース生成エンジンで構成されています。ビジネスオーナーまたはテスターは、モデラーを使用して要件を動作ツリーに変換し、次に（オプションで）いくつかの関連する動作ツリーを複合ツリーに統合します。動作ツリーをバックエンドエンジンに取り込むと、テストケース、テストスクリプト、およびテストデータが自動的に生成されます。

この方法の実現可能性をテストし、その機能を改良するための最初の業界試験は2002年に実施されました。過去3年間で、大規模な防衛、輸送、エンタープライズシステムに関する多くの体系的な業界試験が実施されました。^{[5] [31]}この作業により、この方法は多数の要件を持つシステムにも拡張できることが明らかになりましたが、グラフィックデータのこのような大規模で統合されたビューを効率的にナビゲートおよび編集するには、ツールサポート^{[22] [45]}を使用することが重要であることもわかりました。この業界との作業から、いくつかの主要な結果が得られました。平均して、いくつかのプロジェクトで、通常のレビューと修正が行われた後、1000の要件あたり130の確認された重大な欠陥が一貫して見つかりました。^[31]成熟度の低い要件セットでは、はるかに高い欠陥率が観察されています。

業界とのこの取り組みの重要な部分は、この方法の分析部分をレイセオンオーストラリアの 6 つの大規模防衛プロジェクトに適用することであった。彼らはこの方法を「ソリューション開発と調達文書の問題に関する顧客へのアドバイスの両方に使用できる重要なリスク軽減戦略」とみなしている。^{[32] [46]}これらの業界トライアルの結果、レイセオン オーストラリアとの共同開発^[6]により、大規模な統合要件セットの分析、編集、表示をサポートする業界最強のツールが生まれた。^[45]業界の調査結果の詳細については、Behavior Engineering の Web サイトをご覧ください。^[47]

テリー・スティーブンソン博士（レイセオン・オーストラリア最高技術責任者）とジム・ボストン氏（レイセオン・オーストラリア上級プロジェクトマネージャー）、オーストラリア国防資材機構のエイドリアン・ピットマン氏、ケルビン・ロス博士（KJロス＆アソシエイツ最高経営責任者）およびクリスティン・コーニッシュ氏（ブシェル＆コーニッシュ）は、この研究を支援し、産業界の試験^{[5] [31]と実際のプロジェクト作業を実施するために必要な特別な機会を提供しました。この研究は、}オーストラリア研究会議-ARC複雑系センターの支援を受けており、産業界から資金を受けています。^[要出典]

^[48]

動作モデリング表現として、動作ツリーには多くの重要な利点とメリットがあります。

• 彼らは、システムの初期のニーズが自然言語で書かれた数百または数千の要件を使用して表現されている場合に特に、要件の複雑さに対処するための明確で効果的な戦略を採用しています。これにより、大規模プロジェクトのリスクが大幅に軽減されます。^[31]
• 要件を厳密に翻訳し、可能な限り早い段階で統合することで、競合方法よりも要件の欠陥を発見するためのより効果的な手段を提供します。^{[31] [32]}
• 彼らは、システムの分析、仕様、動作設計を表現するために、単一の単純な表記法^{[15]を採用しています。}
• これらは、システムの動作を実行可能な統合された全体として表現します。
• これらは、機能要件からシステムの動作を直接追跡可能な方法で構築し、検証と妥当性確認に役立ちます。^{[22] [37]}
• 正式な方法のトレーニングを受けなくても、関係者は理解できます。元の要件の語彙を厳密に保持することで、理解の負担が軽減されます。
• これらは形式的な意味論を持ち、^[17]並行性をサポートし、実行可能であり、シミュレーションやモデルチェックが可能であり、故障モード影響分析を行うために使用することができます。^[18]
• これらは、人間のプロセスのモデル化、契約の分析、^[38]、法医学情報の表現、生物システムの表現、その他多数のアプリケーションに同様に使用できます。いずれの場合も、複雑さを管理し、全体をとらえるという点で同じ利点があります。また、セーフティクリティカルシステム、^[19]、 組み込みシステム^[26]、リアルタイムシステムにも使用できます。^{[49] [50] [51]}

• 教科書レベルの小さな例では、ツリーのような性質のため、生成されるグラフィック モデルは、ステートチャートやステート マシンの動作仕様ほどコンパクトではない場合があります。
• 数百または数千の要件を持つシステムの非常に大規模な統合動作ツリーをナビゲートするには、ツール サポートが必要です。
• 非常に大規模なシステムのグループウォークスルーには、優れた表示機能が必要です。
• 統合された動作ツリー モデルを最大限に活用するには、高度なツール サポートをさらに提供する必要があります。

• 行動工学
• モデリング言語

• 行動工学
• レイセオン・オーストラリアは先駆的なシステム研究を支援している
• ARC 複雑系センター – ACCS プログラム: 信頼性の高い複雑なコンピュータベースのシステム
• オーストラリア研究会議 – 成果: 複雑性の抑制^{[永久リンク切れ‍ ]}