Coursera Software Architecture Week2 Learning Objectives-3

Coursera

Data Flow Architecture

Pipe and Filter Architecture

Filter: データの変換 Pipe: データの通り道

Filterは『どのようなデータが入ってきて』『どのようなデータが出ていくのか』だけに集中することで、疎結合になる。 また、Filterの内部をブラックボックスとすることができ、Filterは再利用が可能である。

しかし、Filterを増やすと、そのぶんオーバーヘッドが増える。 また、このPipe & Filter Architectureはインタラクティブなアプリケーションには向かない。レスポンスに時間がかかるからである。

Event Based

Event Based Architectureでは、イベントはシステム内の主要要素である。シグナルやユーザー入力、メッセージ、データなどがイベントになりうる。イベントが発生することにより、何かしらの機能が動作する。 Event Based Architectureでは、イベントジェネレータ（イベントを作成する）とイベントコンシューマ（イベントを受け取り処理する）の二つの役割のものがある。

イベントによって起動される機能は、サブルーチンを実行するときのように明示的に実行されるのではなく、イベントバスを通じて暗黙的に実行される。イベントバスはイベントジェネレータとイベントコンシューマをつなぐ役割をする。イベントジェネレータがイベントを作成すると、イベントバスがそれを検知しイベントコンシューマに通知する。つまり、すべてのイベントはイベントバスを通じてイベントコンシューマに届けられる。これはデザインパターンのオブザーバーパターンと同じである。

このようにすると、イベントジェネレータはどのコンシューマがイベントを受け取るのかを気にしないし、イベントコンシューマはどのジェネレータがイベントを作成したのかを気にしなくて良くなる。

しかし、イベントバスを使うと、複数のコンシューマが同時に同じイベントを受け取り処理することで、データ更新で競合するということが発生する。競合を防ぐため、セマフォという仕組みが考えられた。値が使用されているかどうかを示すことで、競合を防ぐ。

Event Based Architectureでは、事前に機能が実行される順番を予測することはできない。

Process Control

フィードバックループ

  • センサー：状態を監視する
  • コントローラー：ロジック
  • アクチュエーター：プロセスを操作する
  • プロセス：操作したい対象 センサーがプロセスの状態を取得し、コントローラーに送る。コントローラーのロジックが状態をあるべき状態の差を計算し、アクチュエーターに操作をリクエストする。アクチュエーターはプロセスを操作する。そしてその状態をセンサーが取得する。

コントローラーは常に動いていなければいけない（状態はつねに変化するので）。

フィードフォワードループ

フィードバックループに、外的要因を排除するための修正操作を追加したもの。