トピック

概論 先頭へ

ソフトウェア アーキテクチャという概念は、理解しやすく、ほとんどのエンジニア (特に多少の経験のあるエンジニア) が直感的に感じることができますが、正確に定義することは困難です。特に、設計とアーキテクチャとを明確に区別することは困難です (アーキテクチャは設計の 1 側面であり、特定の機能に重点を置いています)。

"An Introduction to Software Architecture" の中でデビッド ガーラン と メアリー シャー が述べているように、ソフトウェア アーキテクチャは、次のような問題に関係する設計のレベルです。「計算のアルゴリズムとデータ構造以上に、システム構造全体の設計と指定が、新しい種類の問題として浮かび上がっています。構造の問題には次のものがあります。全体の編成と包括的な制御構造、コミュニケーションのプロトコルと同期とデータ アクセス、設計の要素への機能の割り当て、物理的な分散、設計の要素のコンポジション、スケーリングと性能、代替の設計からの選択などです (参考資料 [GAR93])。」

しかし、アーキテクチャは単なる構造ではありません。IEEE Working Group on Architecture の定義では、アーキテクチャは「システムの環境の中での最高レベルの概念」です (参考資料 [../../referenc.htm#IEEE98 -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんIEEE98])。また、アーキテクチャは、システム統合、経済的制約、美的関心、スタイルのすべてとの「適合」を含んでいます。内向きの視点にとどまらず、ユーザー環境と開発環境の中でシステムを全体として考慮に入れる外向きの視点も持っています。

RUP では、(特定時点での) ソフトウェア システムのアーキテクチャは、インターフェイスによって相互作用するシステムの重要なコンポーネントの編成または構造であり、コンポーネントは連続的に小さいコンポーネントとインターフェイスで構成されます。

アーキテクチャの記述 先頭へ

ソフトウェア アーキテクチャについて説明し、論理的に判断するには、まずアーキテクチャの表現、すなわちアーキテクチャの重要な側面の記述方法を定義しなければなりません。RUP では、この記述は「ソフトウェア アーキテクチャ説明書」で把握されます。

アーキテクチャ ビュー 先頭へ

複数のアーキテクチャ ビューでソフトウェア アーキテクチャを表現することを選択しました。それぞれのアーキテクチャ ビューは、開発プロセスの利害関係者 (エンドユーザー、設計者、管理者、システム エンジニア、保守担当者など) に固有の関心事項を扱います。

アーキテクチャ ビューは、主要な構造設計の決定を把握するために、どのようにソフトウェア アーキテクチャがコンポーネントに分解され、どのようにコンポーネントがコネクタによって接続されて便利な形式を作成するかを示します (参考資料 [PW92])。これらの設計の選択は、要求、機能、補足的などの制約に結びつかなければなりません。しかし、これらの選択は、要求と将来の設計の決定に対して、より低いレベルでさらなる制約をもたらします。

典型的なアーキテクチャ ビューのセット 先頭へ

アーキテクチャは、数種類のアーキテクチャ ビューで表現され、その本質は、モデルの「アーキテクチャ上重要」な要素を図示する抽出物です。RUP では、「4+1 ビュー モデル」と呼ばれる典型的なビューのセットから開始します (参考資料 [KRU95])。それは次のもので構成されます。

  • ユース ケース ビュー: アーキテクチャ上重要な振る舞い、クラス、技術面でのリスクを含むユース ケースとシナリオが含まれます。ユース ケース モデルのサブセットです。
  • 論理ビュー: 最も重要な設計クラスとそのクラスからパッケージサブシステムへの編成、これらのパッケージとサブシステムからレイヤへの編成が含まれます。ユース ケースの実現も含まれます。設計モデルのサブセットです。
  • 実装ビュー: 実装モデルと、モジュールの観点からのパッケージとレイヤへの編成の概要が含まれます。実装ビューのパッケージとモジュールへの、(論理ビューの) パッケージとクラスの割り当ても記述されます。実装モデルのサブセットです。
  • プロセス ビュー: 関与するタスク (プロセスとスレッド)、そのタスクの相互作用と構成、タスクへの設計オブジェクトとクラスの割り当ての記述が含まれます。このビューは、システムにかなりの程度の並行性がある場合にのみ使用する必要があります。RUP では、設計モデルのサブセットです。
  • 配置ビュー: ほとんどの典型的なプラットフォーム構成のさまざまな物理ノード、物理ノードへの (プロセス ビューの) タスクの割り当ての記述が含まれます。このビューは、システムが分散される場合にのみ使用する必要があります。配置モデルのサブセットです。

アーキテクチャ ビューは、「ソフトウェア アーキテクチャ説明書」に記述されます。さまざまな特殊な関心事項を表現するその他のビュー (ユーザー インターフェイス ビュー、セキュリティ ビュー、データ ビューなど) の構想を自分で立てることができます。単純なシステムの場合は、4+1 ビュー モデルのビューの一部を省略できます。

アーキテクチャの重点 先頭へ

以上のビューはシステムの全体的な設計を表現できますが、アーキテクチャは次のようになんらかの特定の側面にのみ関与します。

  • モデルの構造 — 編成パターン、たとえばレイヤリング
  • 不可欠な要素 モデル内に存在するすべての要素に対するものとしての、重大なユース ケース、主要なクラス、一般的なメカニズムなど
  • いくつかの主要なシナリオは、システム全体での主なコントロールのフローを示します
  • サービスは、モジュール性、オプション機能、製品ラインの側面を把握します

アーキテクチャ ビューは要するに、設計全体の抽象化または単純化であり、詳細を省略することで重要な特性を見やすくします。こうした特性は、次のことについて論理的に判断する際に重要です。

  • システムの発展 - 次の開発サイクルへの移行
  • 製品ラインのコンテキストでのアーキテクチャまたはその部品の再利用
  • 性能、利用可能性、移植性、安全性などの補足的品質の評価
  • チームまたは下請け業者への開発作業の割り当て
  • 市販のコンポーネントを含めることについての決定
  • より幅広いシステムへの挿入

アーキテクチャ パターン 先頭へ

アーキテクチャ パターンは、繰り返し発生するアーキテクチャの問題を解決する既製の形式です。アーキテクチャのフレームワークまたはアーキテクチャのインフラストラクチャ (ミドルウェア) は、特定の種類のアーキテクチャを構築するときの基になるコンポーネントのセットです。主なアーキテクチャの難題の多くは、このフレームワーク内またはこのインフラストラクチャ内で解決する必要があります。このフレームワークとインフラストラクチャは、通常は特定のドメイン (コマンドとコントロール、MIS、コントロール システムなど) を対象としています。

アーキテクチャ パターンの例

[BUS96] は、アーキテクチャ パターンが最も当てはまるシステムの特性に従って、アーキテクチャ パターンをグループ化します。1 つのカテゴリが、より一般的な構造化の問題を扱います。次の表は、参考資料 [BUS96] に掲載されているカテゴリと、そのカテゴリに含まれるパターンを示しています。

カテゴリ パターン
構造 レイヤ
パイプとフィルタ
ブラックボード
分散システム ブローカー
対話型システム モデル ビュー コントローラ
プレゼンテーションと抽象化のコントロール
適用可能なシステム 反映
マイクロカーネル

ここではこれらのうち 2 つについて詳しく説明します。これらの考え方について詳しくは、参考資料 [BUS96] を参照してください。パターンは、次のような広く使用されている形式で示されます。

  • パターン名
  • コンテキスト
  • 問題
    • 「要因」は、検討が必要なさまざまな問題の側面を記述します。
  • 解決法
    • 根拠
    • 結果となるコンテキスト
パターン名

レイヤ

コンテキスト

分解が必要な大規模システム

問題

異なるレベルの抽象化で問題を扱わなければならないシステム。たとえば、ハードウェアのコントロールの問題、一般的なサービスの問題、ドメイン固有の問題など。すべてのレベルで問題を扱う垂直のコンポーネントを作成することは、きわめて好ましくありません。異なるコンポーネントで何回も同じ問題を (おそらく一貫性を欠く方法で) 扱わなければならない可能性があります。

要因

  • システムの部品を置換可能にする必要があります
  • コンポーネントの変更が波及しない必要があります
  • 同じような責務をグループにまとめる必要があります
  • コンポーネントのサイズ - 複雑なコンポーネントは分解が必要になることがあります
解決法

システムを構造化し、相互の上にレイヤを形成するコンポーネントのグループを作成します。上位レイヤが下方のレイヤのサービスのみを使用する (上方のレイヤのサービスは使用しない) ようにします。直下のレイヤのサービス以外は使用しないようにします (中間のレイヤがパス スルー コンポーネントの追加しかしない場合を除き、途中のレイヤを抜かさないようにします)。

例:

1. 汎用のレイヤ

厳密にレイヤ化されたアーキテクチャでは、設計の要素 (クラス、パッケージ、サブシステム) が直下のレイヤのサービスのみを使用します。サービスには、イベント処理、エラー処理、データベース アクセスなどが含まれます。 最下位のレイヤに記録される生のオペレーティング システム レベルの呼び出しと異なり、わかりやすいメカニズムが含まれます。

2. ビジネス システムのレイヤ

このダイアグラムもレイヤリングの例を示し、垂直のアプリケーション固有のレイヤ、水平のレイヤ、インフラストラクチャ レイヤがあります。この目的は、非常に短いビジネス「ストーブパイプ」を持つこと、アプリケーション間で共通性を利用することです。そのようにしないと、複数の人がおそらく異なる方法で同じ問題を解決する可能性があります。

このパターンについて詳しくは、「ガイドライン: レイヤリング」を参照してください。

パターン名

ブラックボード

コンテキスト

完結した (アルゴリズム的な) 問題解決方法が知られていないか、実現可能なものがないドメイン。たとえば、AI システム、音声認識、監視システムなど。

問題

個別の問題解決エージェント (知識エージェント) が解決できない問題は、複数のエージェントが共同で解決しなければなりません。個別のエージェントの作業の結果は、その他すべてのエージェントが使用できなければなりません。そうすれば、解決法の発見に貢献できるかどうかや、作業の結果を登録できるかどうかを各エージェントが評価できます。

要因

  • 知識エージェントが問題の解決に貢献できる順序は一定ではなく、問題の解決戦略に応じて異なります

  • さまざまなエージェントからの入力情報 (結果または部分的な解決法) は、表現方法が異なることがあります

  • エージェントは相互の存在を直接は知りませんが、相互が登録した貢献の評価はできます

解決法

ブラックボードと呼ばれる共有のデータ ストアを複数の知識エージェントが利用できます。ブラックボードは、その内容の調査と更新をするためのインターフェイスを提供します。Control モジュール / オブジェクトは、なんらかの戦略の後にエージェントのアクティベーションを行います。アクティベーションが行われると、エージェントはそのブラックボードを調査し、問題の解決に貢献できるかを調べます。エージェントが貢献できると判断した場合、コントロール オブジェクトはこのエージェントが部分的 (または最終的) な解決法をブラックボードに登録できるようにします。

例:

これは UML を使用してモデリングされた構造的または静的ビューを示しています。これはパラメータ化されたコラボレーションの一部となり、実パラメータにバインドされてパターンをインスタンス化します。

アーキテクチャ スタイル 先頭へ

ソフトウェア アーキテクチャは、またはアーキテクチャ ビューだけが、アーキテクチャ スタイルと呼ばれる属性を持つことができます。アーキテクチャ スタイルは、選択可能な形式のセットを減らし、ある程度の統一性をアーキテクチャに持たせます。アーキテクチャ スタイルを定義するには、パターンのセットを使用するか、特定のコンポーネントまたはコネクタを基本的な構築単位として選択します。特定のシステムでは、アーキテクチャ スタイル ガイド スタイルは、アーキテクチャの理解しやすさと統合で主要な役割を果たします。

アーキテクチャの青写真 先頭へ

アーキテクチャ ビューをグラフィックで描写したものを アーキテクチャの青写真と呼びます。前に示したさまざまなビューの場合、アーキテクチャの青写真は、統一モデリング言語 (UML) からの次のダイアグラムで構成されます (参考資料 [UML01])。

  • 論理ビュー: クラス図、状態マシン、オブジェクト図
  • プロセス ビュー: クラス図とオブジェクト図 (タスク (プロセスとスレッド) を含む)
  • 実装ビュー: コンポーネント図
  • 配置ビュー: 配置図
  • ユース ケース ビュー: ユース ケース、アクター、普通の設計クラスを描写するユース ケース図。設計オブジェクトとそのコラボレーションを描写するシーケンス図。

アーキテクチャの構築プロセス 先頭へ

RUP では、アーキテクチャは主として分析 / 設計ワークフローの結果です。プロジェクトがこのワークフローの指定変更を何度も反復するにつれて、アーキテクチャが発展し、洗練、改善されます。反復のたびに統合とテストが行われるので、製品を納品するころにはアーキテクチャがかなり堅牢になっています。このアーキテクチャは、推敲フェーズを反復する際の主な注目点の 1 つです。推敲フェーズが終わるころには、アーキテクチャが通常はベースライン化されます。



Rational Unified Process   2003.06.15