1 INTRODUCTION

　 ソフトウェア・アーキテクチャーは最近とても多くの注目を集めているトピックです。これがそのシステムがどのように構築されるかだけでなく、主な影響を及ぼすすべてのソフトウェア・システムの重大な様相であることは明白になりました。しかし、さらに重要なことには、それはどれくらい容易に維持し発展することができるかということです。ソフトウェアのよく知られている柔軟性にもかかわらず、システムのオリジナルのアーキテクチャーの中で予想されなかった進化の変更が、インプリメントするのに法外に高価か、そうでなければ、実際に実行不可能であるということは多くの場合あるそうです。最も複雑なシステムは、重要な進化という成長を経験する長い一生を持つので、アーキテクチャーはあきらかに主な関心事になります。
　  しかしながら、ソフトウェア・アーキテクチャーに関する本質的な困難のうちの1つは、与えられたシステムについては、それが何のように見えるか正確に識別することが多くの場合非常に困難であるということです。一旦アプリケーションをコーディングが完了していれば、アーキテクチャーのただ一つの具体的な明示は詳細なコードのラインの何千あるいは何百万中に隠されているソース・コード自体にあります。あるハイ・レベルのブロックダイヤグラム形式を使用して、アーキテクチャーが上手にドキュメント化されていても、ドキュメンテーションが実際のコードに忠実であるという保証はありません。コードの中に構造上の明細とその実現の間に形式上のリンクがない場合、その二つを分岐するのは容易です。そしてそれが起こる場合に、見つけることが困難です。プログラミングは何千ものロー・レベルの決定を含んでいるタスクです。また、それが構造上の明細の意図と一致していることを保証する各ものを追跡することは不可能です。これは「構造上の腐食」として知っている現象に結びつき、システムのオリジナルのアーキテクチャーは、アーキテクチャーの重要な要素が悪くなる場合に出る警報ベルの時間を除いて徐々に変更されます。
　 UMLおよびモデルで駆動される開発方法はこの状況に重要な役割を果たすことができます。最初に言語は、指定しているアーキテクチャーを直接また容易に理解された手段を許可するモデリング設備の提供により支援することができます。コードが生成される出所としてのそれらの仕様書を使用することによって、構造上の腐食の問題は回避することができます。本章では、私たちがソフトウェア・アーキテクチャーを指定するためにこのボリュームの3章に記述されたUML2.0の新しい構造のモデリング能力をどのように使用することができるか説明します。特に、私たちは多くの重要な構造上のパターン上のこの能力を実証します。これらは様々なソフトウェア・アーキテクチャーの核心にある、共通の構造の配置です。

3 THE VIRTUAL-MACHINE LAYERING PATTERN(仮想の機械の層状化パターン)

　  実際にすべてのソフトウェア・システムまた、どんな複雑なソフトウェア・システムも主に層状化を含んでいます。図8-7の中で示されるように、根本的なオペレーティング・システム上にアプリケーションの基本の層状化があります。ほとんどの場合では、層状化が多数の内部層へ組み立てられて、アプリケーションそれら自身(オペレーティング・システムと同様に)と共にそれを越えます。実際、大多数のソフトウェア・アーキテクチャーの最高水準は1セットの層を含みます。各層は重要な異なるセットおよび実現する異なる抽象的概念と取り引きします。
    層になることにより提供される概念の単純性、それを建築家のための非常に便利で、一般に使用されたツールにします。不運にも、その普及にもかかわらず、概念はしばしば貧弱に理解されます。階層状の図形は非常に異なる概念を描くためにしばしば使用されます。そして、それらの記法上の類似性により、しばしば互いと混同されます。生じる混乱の種類を例証するために、パブリックドメインからの2つの有名な例を検討しましょう。
    1番目はISOによって標準化されたポピュラーな7層開放型システム間相互接続(OSI)アーキテクチャーです。これは分配されたソフトウェア・システム(図8-8)にコミュニケーション・メカニズムの層状化構造について記述するアーキテクチャーです。それは、1セットの関連する通信プロトコル基準の定義のために概念のフレームワークを定義します。
    第2の例はさらに国際的基準から次のとおりです:ITU-T(2)によって公表されたオープン分散処理(RM-ODP)のための参照モデル。このモデルは、与えられたシステムを5つのviewpointへ分類します。各viewpointは抽象的概念の異なるセットとやりとりをします。viewpointの抽象の相対的な程度を例証するために、それらは、底からトップへ増加する抽象のレベルと共に、垂直のスタックとして描かれます。したがって、底のtechnology viewは、その実現の中で使用される、特定のハードウェア用語およびソフトウェア技術ついて記述し、一番上のenterprise viewpointでは純粋にビジネス目的観点を記述し、それには任意の技術の特有の様相がありません。
    レベルおよび異なる名前の異なる数を除いて、図8-8および図8-9の中の2つの図形は全く類似したように見えます。そしてそれらが同じものを意味すると容易に結論を下すかもしれません。しかしながら、2つの図形は全く異なり、完全に異なる解釈があります。
    RM-ODPアーキテクチャーは、抽象の異なるレベルを識別するために層状化を使用します。technology levelは、実際のインプリメンテーションにとても接近しており、そのビジネス考察から最も遠くなっています。私たちが階層を上へ移動するとともに、ますます多くのインプリメンテーションおよび技術詳細が抽象されます。computational levelでは、例えば、ノードの移動の物的流通の詳細が削除されます。また、アプリケーションは単に合作するオブジェクトのネットワークとして見られます。information levelはこれをさらに抽象し、任意の技術的な考察と無関係に、表わされる必要のある情報および必要な関係の性質だけを表わします。したがって、各レベルは完全なシステムのモデルです。しかし、異なったviewpointは重要な異なったセットをアドレスします。
    対照的に、OSIモデル中の層の各々は他の層のうちのどの中にでもない別個のエンティティを表わします。完全なシステムは層のすべての合計です。したがって、リンク層はソフトウェアエンティティのポイントリンクレベルコミュニケーションの指定を記述している一方、フィジカル層はハードウェアを指定します。
次の上のレベルで、私たちは、リンク層の中にないソフトウェアの仕様書を持っています。それは分散型ネットワークを介してのコミュニケーションをうけもっています。この場合、上記の層は、層のより抽象的な視界を下に表わしません。言いかえれば、これらは抽象層ではありません。同じことは図8-7の中で示される層に適用できます:アプリケーションは最も確かにオペレーティング・システムの抽象的な見解ではありません。また、2つの層の中のコードは完全に別個で、別個のランタイムエンティティに帰着します。
    本章では、私たちがランタイム層状化について話すことに興味を持っていますだけです。この種の層状化について記述するために使用することができる、共通の用語は仮想機械層状化です。これは個々の連続の層がその上に層の中のソフトウェアのために仮想機械を直接提供するからです。各層が、より低い層の技術的な現実から私たちをさらに奪う時から、それが1種のなぜこの二つが混乱している抽象層状化を表わすことなのか言えるかもしれません。しかしながら、2つのケースに起こる抽象の2つの種類が異なることは明らかです。
    層状化パターンはどの状況で有用ですか?それに答えるために、私たちは、複雑なテレコム・スイッチング・システム(図8-10)の一部である個々のコミュニケーション・ラインのコントロールの元である典型的なリアルタイムのコンポーネントの例を考慮します。
    管理の概念の単純性および容易さについては、ソフトウェア・コンポーネント全体が、CommLineController(ミクロパターンコンテナーのアプリケーション)と呼ばれるコンテナーで包まれます。このコンポーネントのインプリメンテーションは、ピア・ツー・ピア関係によって合作する4つのサブコンポーネントから成ります。LineDriverはハードウェアの接続およびコントロールのうけおいです。その機能性のうちのいくらかが時間依存であるので、このサブコンポーネントはRealTimeClockサブコンポーネントと対話する必要があります。これは物理的な時計装置をコントロールし、汎用のタイミング・サービス(例えば、リアルタイムの時計装置の現在値を読んで書くタイムアウト信号の生成)を提供するサブコンポーネントです。ProtocolHandlerサブコンポーネントはある内部プロトコル(例えばソケット)によってシステムの中で他のコンポーネントとの相互作用のために他のサブコンポーネントによって使用されます。それは時間依存の機能性をまた持つので、それはRealTimeClockサブコンポーネントと対話する必要があります。UnitControllerは、LineDriverおよびProtocolHandlerのオペレーションを同期させることをうけおいます。例えば、外部コマンドがコミュニケーション・ラインで診断のメンテナンスを実行するために与えられる場合、UnitControllerは他のサブコンポーネントがこのタスクのために適切に調整されることを保証するでしょう。
    標準エンジニアリング実行および常識は、このコンポーネントのインプリメンテーションを構成する4部がコンポーネント内に完全にカプセルに入れられるべきであると私たちに伝えます。しかしながら、これをしようとする際に、私たちは問題に衝突します:それが、他のタイプのコンポーネントにとっても他のライン・コントローラー実例にとっても有用かもしれないので、特にこのコンポーネントはリアルタイムの時計コンポーネントを独占することができません。実際、たとえそれがライン・コントローラーのインプリメンテーションの一部でも、私たちはリアルタイムの時計機能性を共有されるサービスにしてほしい。
    実際上、リアルタイムの時計のような様々な種類の共有されるサービスがあります。これは異なる相互プロセス情報提供サービス、エラーおよびアラーム報告サービス、ファイル・システム・サービス、出来事通知サービス、記入するサービスなどを含んでいます。それらのすべてに共通のことは、アプリケーションコンポーネントをインプリメントするためにそれらが使用されますが、それら自身アプリケーションの直接の部分でないということです。
それらは、様々な種類のコンポーネントによって共有されるかもしれないので、通常属に関して定義されます。そして多くの場合、それらを使用するアプリケーションと無関係です。最も原型の例はオペレーティング・システム・サービスです。
    これは、サポートするランタイム層が実際に共有されるインプリメンテーションサポートサービスのパッケージングであると示唆します。便利な層の上の仮想マシン環境は実現の中で使用することができます。
    しかしながら、共有されるインプリメンテーション・サービスを抽出し仮想機械層へそれらをグループ化することが、1つの重要な欠点を持つように見えるかもしれません:コンポーネントの内部インプリメンテーションへの変更はインターフェイスへの変更と反射するかもしれないからです。例えば、私たちが共有するのではなく内部リアルタイムの時計サービスを利用するためにコミュニケーション・ライン・コントローラーのインプリメンテーションを変更すれば、サービスを共有するコンポーネントのインターフェースは削除される必要があります。インターフェースの変更が一般に環境への対応する変更を意味するので、これはカプセル化の主要な目的を破るように見えます。
    しかしながら、実際上、そのようなインプリメンテーション変更からの波及効果が常にほとんど生じません。層をサポートするためのインターフェースが通常定義されそれらを使用するアプリケーションと無関係に存在することを思い出してください。アプリケーションコンポーネントを設計する際に、デザイナーは、最も新しいものの要求ではなく層のサポートの中で既に定義されたサービスを利用するそれらのインプリメンテーションを組み立てる傾向があります。したがって、層境界でのインプリメンテーション変更は、異なる(通常、既に既存)インターフェースによって既存のインターフェースの除去あるいはその置換のいずれかを意味します。いずれの場合も、コンポーネントの仲間は変更に影響されません。
    しかしながら、これは、コンポーネントの層(インプリメンテーション)インターフェースおよびその仲間インターフェースを識別することが有用であることを示します。層インターフェースは、層をサポートしている共有サービスにアクセスするときに使われますが、仲間インターフェースは、コンポーネントと対話するその仲間コンポーネントとのインターフェースです。この区別は、私たちがコンポーネント上のインターフェース変更がその環境の上に持っているかもしれないインパクトをよりよく決定するのを助けるでしょう。
    この区別はポートのその概念によってUMLでサポートされます。また、それは、層状化パターンの直接のモデリングを可能にします。特に、UMLクラスかコンポーネント上で「サービス」ポートとして定義された振る舞いポートを指定することは可能です。これは、このポートによって表わされるインターフェースが層インターフェース(それはコネクターによって、サポートする層の要素上の任意の対応するポートに接続することができる)であることを意味します。サービス・ポートとして指定されないポートは自動的に仲間ポートであることになります。この例は、図8-12(それはサービス・ポートを示すために「ダイヤモンド」記法を使用する)で見ることができます。この場合、サブコンポーネントProtocolHandlerおよびLineDriverの上の「rtclk」と呼ばれた2つのポートは、他のコンポーネント(通常層の支援中のもの)上の任意の一致するポートに接続することができるサービス・ポートです。
    サービス・ポートは外部実体と接続されることを可能にする社会視界(もし望まれれば、さらに、それらはコンポーネントの内部の部分に接続される
かもしれませんが)を持っています。更に、それらは、それらの対応するサブコンポーネントがどれくらい深く入れ子にされるかにかかわらず常に目に見えます。これは、層が直接アプリケーションレベルを入れ子にすることにより自由で、互いに隣接していると仮定される場合に関係を層にする性質を反映します。これは、仲間ポートからの異なる「飛行機」で層ポートがあるという事実の現れです。

5 SUMMARY(要約)

    本章の主要な目的は、構造上の記述言語(最高水準からサブシステムの最も小さなものまで粒状のすべてのレベルにアーキテクチャーについて記述することができる)としてUMLが役立つという能力を導入することでした。その目的のために、私たちは、ソフトウェア・アーキテクチャーの初歩を表わす、基本の構造の関係(マイクロ・パターン)を最初に識別しました。さらに、私たちはUML2.0の構造化したクラス概念を使用して、真直ぐなやり方で、どのようにこれらの基本的なパターンを表現することができるか示しました。高度で著しい構造上の2つのパターンが詳細に記述されました。「再帰的なコントロール」パターンが所定の層の内に、あるいは多数の層を横切ってさえ生じるかもしれない構造について記述している一方、「層状化」パターンは階層的に組織された仮想機械の「垂直の」構造と取り引きします。これらのパターンは両方とも、そのようなシステムの部分と同様に完全なシステムにも適用可能です。例えば、層はそれ自体内部に層になるでしょう。
    もちろん、ここに(いくらか含むことはこのボリュームの他の章でカバーしました)記述されたもの(それはOMLのこれらの特徴を使用して表現することができる)を越えて他の多くの重要な構造上のパターンがあります。実際のシステムで要求された詳細の十分な範囲を包含する完全なシステム仕様書を生産するために、そのようなハイ・レベル記述は他のUML仕様書(例えば行動の仕様書)と結合することができます。これは、互い(それらがすべて同じUMLモデルの一部であるので)とシステムを含む様々な見解仕様書がすべて形式的に提携することができるという主な長所を持ちます。これは、複雑なシステムが異なる形式に基づいた異なる見解から記述される場合、一般に生じる和解問題を回避します。