ボトムアップアーキテクチャは、トップダウンパラダイムで効果的にプログラムできますか？

Question

包摂アーキテクチャ, 、1986年にロドニーブルックスによって提案されたのは、「ボトムアップ」アプローチであり、ロボットは単純な階層モデルを使用して設計されています。これらのモデルは、下部モジュールの上に構築および包含して、最終製品を形成します。たとえば、ロボットには、より抽象的な「戸口検索」モジュールに包まれた「開口部」モジュールを指定できます。これは、「競技場の出口」モジュールによって包まれます。

今、明らかに、より「オブジェクト指向の」デザインで、「競技場モジュールを出る」でデザインを開始できたかもしれませんが、議論のために、より原始的なコンポーネント（「関数」として）のいくつかを想定します。他のより高い概念で再利用される可能性があります。

このロボットを手続き言語（または機能的なものとして）に実装することが最も簡単になる可能性があることに気付くのは最も簡単ですが、オブジェクト指向のプログラミングパラダイムで包摂アーキテクチャベースのロボットを想像しようとすることは逆効果ですか？ （ソフトウェアエンジニアリングのパラダイムをロボット工学のパラダイムと比較検討することもおそらく難しいことに気づきます）ソリューションを取得するために、2つの競合するパラダイムを使用する効果を高めるために実装できる「アダプター」の形がありますか？

Answer 1

これをより一般的なシナリオに一般化したいと思います。これは理にかなっていると思います。なぜなら、包含アーキテクチャの詳細はおそらく質問の主要な側面ではないためです（そして、同じ問題も非ロボット分野でも発生します）。

一般的なソフトウェアの大文化では、質問のように、双方向アプローチ、またはマルチパラダイムアプローチがあります。動作環境の底部のほとんどのレイヤーは、一般的に下に書かれています。非常に具体的なコードビットは、システム上の非常に特定のハードウェア要素をドライバーに書かれています。次に、これらを組み合わせて、より高いレベルのコンポーネントを形成します。ロボットをシステム自体として単に説明し、そのシステムの特定の側面を制御する目標を単に説明する場合、これを包含アプローチとして簡単に説明できると思います。そうすることは意図的であるかどうかはわかりませんが。

トップダウンから、ほとんどのアプリケーションはより高いレベルの言語で記述されるか、抽象的なマシンの観点から説明されています。これは、実際に作業を行うほとんどのライブラリからかなり遠く離れています。

ある時点で、これらの2つのレイヤーは満たさなければなりません - 実際、彼らはさまざまなシナリオの多くの場所で会います。これは、他のレイヤーに適しているためにレイヤーを「適応」しなければならない場合。ここで「アダプター」という用語は100％正しいです。実際、この目的に使用される「アダプター」と呼ばれるソフトウェアパターンがあります。

特定のアダプターとは別に、最新のプログラミングのツールチェーン全体を実際に考慮することができます。コンパイラ自体は、ライナーと実行VMとともに、2つのレイヤー間の主要なインターフェイスです。つまり、高レベルの言語が1つのドメインに記述されており、コンパイラは低レベルのドメインで動作することを可能にします。

パラダイムの効果を特に探している場合は、命令プログラミング（C ++）、機能プログラミング（Haskell）、および宣言プログラミング（PROLOG）には高レベルの言語が存在することを考慮してください。これらのパラダイムはすべて、最終的に同じ基礎となる低レベルライブラリで機能します。

ロボット工学の質問は大きく異なりますか？いいえ、私はそう信じていません。実際、同じアイデアが今日策定された場合、通常のソフトウェアアーキテクチャから大きな違いがないため、ロボット固有の用語（包摂アーキテクチャ）があるとは思わない。最後の段落では、ロボットを制御するための機能的および命令的なパラダイムの両方を示します。ただし、ドメイン固有の言語を使用して使用します。また、ドメイン固有の言語の膨大な品揃えは、複数のパラダイムが互いに効率的に適応できるというさらなる証拠です。