トピック

はじめに 先頭

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

「An Introduction to Software Architecture」 の中で David Garlan と Mary Shaw が述べているように、ソフトウェア・アーキテクチャーは、次のような問題に関係する設計の 1 レベルです。「計算のアルゴリズムとデータ構造を越えて、システム構造全体の設計と指定が、新しい種類の問題として浮上します。構造の問題には次のものがあります。全体の編成と包括的な制御構造、通信プロトコル、同期、およびデータ・アクセス、設計要素への機能の割り当て、物理的な分散、設計要素の構成、スケーリングと性能、代替設計案からの選択などです。」 (参考資料 「GAR93」)

しかし、アーキテクチャーは単なる構造ではありません。IEEE Working Group on Architecture の定義では、アーキテクチャーは「システムの環境の中での最高レベルの概念」です。 (参考資料 「IEP1471」)また、アーキテクチャーは、システム統合、経済的制約、美的関心、スタイルへの「適合」を含んでいます。内向きの視点にとどまらず、ユーザー環境と開発環境の中でシステムを全体として考慮する外向きの視点も持っています。

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

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

ソフトウェア・アーキテクチャーについて説明するには、アーキテクチャーの重要な側面を記述する手段であるアーキテクチャーの表現を最初に定義する必要があります。RUP では、この定義は「ソフトウェア・アーキテクチャー説明書」に取り込まれます。

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

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

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

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

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

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

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

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

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

  • モデルの構造 - 編成パターン、例えば、レイヤリング
  • 不可欠な要素 - モデル内に存在するすべての要素に対するものとしての、重大なユース・ケース、主要なクラス、共通メカニズムなど。
  • いくつかの主要なシナリオは、システム全体の主な制御フローを示します。
  • サービスは、モジュール性、オプション・フィーチャー、製品ラインの側面を把握します。

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

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

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

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

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

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

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

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

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

レイヤー

コンテキスト

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

問題

問題をさまざまな抽象化レベルで処理する必要のあるシステム 例: ハードウェア制御の問題、共通サービスの問題、ドメイン固有の問題すべてのレベルで問題を処理する垂直コンポーネントの書き込みは、避けるべきです。同じ問題を異なるコンポーネントで (場合によっては常時) 複数回にわたって処理しなければならなくなります。

要因

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

システムを、相互に積み重なってレイヤーを形成するコンポーネントのグループに構成します。上位レイヤーが下位レイヤーのサービスのみを使用する (上位レイヤーのサービスは使用しない) ようにします。直下のレイヤーのサービス以外は使用しないようにします (中間のレイヤーがパススルー・コンポーネントのみを追加する場合以外は、レイヤーをスキップしないでください)。

例:

1. 汎用レイヤー

付属テキストに記載される図

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

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

付属テキストに記載される図

上記の図は、もう 1 つのレイヤリングの例を示します。この例では、垂直アプリケーション固有のレイヤーおよび水平のインフラストラクチャー・レイヤーが存在します。目標は、ビジネスの「ストーブパイプ」を非常に短くし、複数のアプリケーションにわたる共通点を利用することにあります。 そうでない場合は、同じ問題を (異なる方法で) 解決する担当者が複数存在する可能性があります。

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

パターン名

ブラックボード

コンテキスト

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

問題

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

要因

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

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

  • エージェントは直接互いの存在を知らなくとも、それぞれが通知した貢献を評価できます。

解決策

知識エージェントは、ブラックボードと呼ばれる共用データ・ストアにアクセスできます。ブラックボードは、その内容を検査し更新するためのインターフェースを提供します。制御モジュール/オブジェクトは、何らかの方針に従ってエージェントをアクティブにします。アクティブ化されたエージェントは、ブラックボードを検査して、問題解決に貢献できるかどうかを判断します。エージェントが貢献できると判断した場合、制御オブジェクトによって、エージェントは部分的 (または最終的) な解決策をブラックボードに書き込めるようになります。

例:

付属テキストに記載される図

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

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

ソフトウェア・アーキテクチャーは (またはアーキテクチャー・ビューだけが)、アーキテクチャー・スタイルと呼ばれる属性を持つことができます。アーキテクチャー・スタイルは、選択可能な形式のセットを減らし、ある程度の統一性をアーキテクチャーに持たせます。アーキテクチャー・スタイルを定義するには、パターンのセットを使用するか、特定のコンポーネントまたはコネクターを基本的な構築単位として選択します。特定のシステムではアーキテクチャー・スタイル・ガイド内のアーキテクチャー記述の一部としてスタイルを取得できます (これは、RUP ではプロジェクト固有のガイドライン成果物によって提供されます)。 スタイルは、アーキテクチャーの理解しやすさと保全性において主要な役割を果たします。

明らかになる重要なアーキテクチャー・スタイルの例は、Service-Oriented Architecture (SOA) です。SOA とは、オブジェクト指向のコンポーネントに基づく開発を構築する発展的ステップであり、サービス・レイヤー を使用して、ビジネス・ユース・ケースなどの取り込まれたビジネス・プロセスのすべてまたは一部を達成する、ビジネス機能に類似したサービスを提供します。サービスはコンポーネントによって提供されますが、コンポーネント・セットのコラボレーションを管理して (下位レベルのビジネス・エンティティーへのマッピング)、より細分度の粗い高価値のビジネス機能を提供するといった、構成的な特徴を持っています。これらのアイデアは発展途上にあり、用語または SOA に必要な特性の精度に関してはまだ国際的な合意が得られていませんが、次の点を含むいくつかの事項が一般的に受け入れられていると考えられます。

  • サービスは、ユーザーとプロバイダー間の自由な結びつきを可能にする必要があります。ユーザーが動的に (例えばレジストリーやブローカーを使用して) サービスを発見して、サービスの呼び出し期間中にサービス・インターフェース契約にバインドできるようにするべきです。
  • メッセージ・ベースの通信モデルによる対話 (アプリケーションその他のサービスを使用) を、多くの場合、非同期で実現します。
  • サービスはリソース・セットを管理します。多くの場合、サービス自体はステートレスで、値オブジェクトをリクエスターに引き渡します。

さらに詳しい SOA の説明については、IBM Rational Software 白書「Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications」を参照してください。

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

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

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

RUP では、アーキテクチャーは主に分析&設計ワークフローの成果です。プロジェクトがこのワークフローを繰り返し再現するにつれ、アーキテクチャーは改良され、洗練されていきます。ワークフローを繰り返すたびに、統合とテストを行うため、製品が納入されるまでの間にアーキテクチャーはきわめて堅固なものとなります。このアーキテクチャーは反復する推敲フェーズのメイン・フォーカスであり、通常、推敲フェーズの終了時にはアーキテクチャーのベースラインが出来上がります。



Rational Unified Process   2003.06.13