情報通信学演習I　Bグループ担当分講義資料(本山担当分)

p2.The relative〜p3.piped streams

• 単語
• ＭＥＭＯ

アーキテクチャについての記述中の現在の実践の相対的な非形式化および高水準(ハイレベル)な抽象化が、アーキテクチャの記述がソフトウェアエンジニアに見合う本質的な価値をほとんど持っていないことを一目したところ提案しているかもしれない。しかし、これがそうでない2つの理由があります。最初に、エンジニアは時間とともに、共有され、意味論的に豊富な語彙(ごい)として役立つ、ソフトウェアシステム構成のイディオム、パターンおよびスタイルのコレクションを発展させました。システムをパイプフィルタアーキテクチャスタイル(様式)の実例であると確認することにより、例えばエンジニアは、システムは第1にstream transformation(流れ変形?)に関係すること、システムの機能的な振る舞いが要素フィルタの振る舞いに構成して由来することができること、システム潜在および処理能力の問題を比較的率直な方法で番地付け(アドレス)することができるという事実を(コミュニケーション)します。したがって、この共有される語彙(ごい)は大部分は非公式ですが、それはソフトウェアエンジニアの間の相当な意味的な内容を伝えます。

第2の理由は、アーキテクチャの構造は要素の実際の計算の詳細に関して抽象的ですが、それらの構造が、コミュニケーションのパターン、実行コントロール構造、スケーラビリティ、またシステム発展のパスを意図されたフロー（流れ）のグローバル割合のようなシステムレベルの関係をより広く、理解するための自然なフレームワークを供給するということです。したがって、アーキテクチャの記述は、システム特性が外側にむけられている骨格として役立ちます。それによって、システムがその総体のシステム必要条件を満たすという能力の露出における重大な役割に役立っている。

これはもちろん分析のアーキテクチャの記述および正確な技術用のために、より形式的記法が不必要であると言わないようにすることです。確かに、もし、よりよい記法、理論および分析的な技術でアーキテクチャ設計の現在の実践を支援することができれば、さらに多くを獲得することができるかもしれません。後の章では、私たちが、アーキテクチャの問題の形式化における改良がよりよい形式化のお膳立てをする方法への特別の注意と共に、ソフトウェアアーキテクチャの明細問題を調査します。

特定の領域（ドメイン）のニーズに役立つシステム用のモジュール相互連結言語、テンプレートおよびフレームワークを含むこのトピックの研究の相当な(また成長)体系およびコンポーネントの統合メカニズムの形式的モデルがあります。しかしながら、これらのフィールドの共通の要素を特徴づける一貫した用語は現在ありません。

私たちは、ソフトウェアアーキテクチャに関する完全に高度に発展した理論はいうまでもなく、そのようなアーキテクチャのパラダイムのよく容認された分類学を少しも持っていません。しかし、私たちは、明白に今アーキテクチャの記述の多くの基礎的な成分を識別することができます。さらに、私たちはまた、ソフトウェアアーキテクチャの基礎的なレパートリーを現在形成する1セットのアーキテクチャのパターンまたはスタイルを識別することができます。 (この基礎的なレパートリーは引用語で例証され、Chapter3の主題です。)

ソフトウェアシステムのアーキテクチャは、計算上のコンポーネントおよびそれらのコンポーネント中の相互作用によってそのシステムを定義します。コンポーネントはクライアントとサーバー、データベース、フィルタおよび７階層システムのようなものです。設計のこの水準(レベル)のコンポーネント中の相互作用は、手続き呼び出しおよび共有変数アクセスのように、単純でよく知られているかもしれません。しかし、さらにそれらはクライアントサーバプロトコル、データベースアクセシングプロトコル、非同期出来事マルチキャストおよびパイプストリームのように、複雑で、意味論的に豊富になりえます。