参照アーキテクチャとは、本質的には事前に定義されたアーキテクチャ パターン (またはパターンの集合) のことです。ビジネスまたは技術上の特定のコンテキストの中で利用できるように、そのアーキテクチャの使用を可能にする補助的な成果物と共に、部分的または完全に実例化、設計、実証されます。これらの成果物は、以前のプロジェクトから再利用されることがよくあります。 
役割:  ソフトウェア アーキテクト 
オプション度 / 使用時期:  オプション。方向づけフェーズと推敲フェーズ
テンプレートとレポート: 
 
例:   
UML の表現:  関連する各種のアーキテクチャ ビュー。ユース ケース ビュー、論理ビュー、プロセス ビュー、配置ビュー、実装ビュー、データ ビューなど
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

参照アーキテクチャの成果物は、組織の再利用可能な資産ベースの一部です。この成果物の目的は、アーキテクチャ開発の出発点となることです。この成果物の範囲は、既製のアーキテクチャ パターンアーキテクチャ メカニズムフレームワークといったものから、特徴が知れ渡り運用実績のある、完成したシステムにまで及びます。これらは一様に、つまりドメイン間にまたがって幅広い階層のシステムに適用できることもあれば、ドメインに特化した、より狭い範囲に焦点が合っている場合もあります。

テスト済みの参照アーキテクチャの使用は、多数の機能外要求、特に品質要求に対処するために効果的な方法です。これは、そのような要求を満たすために使用されたことがあり有用性が実証されている、既存の参照アーキテクチャを選択することによって行います。参照アーキテクチャは、さまざまな抽象化レベルで、またさまざまな観点から作成または使用することができます。これらは 4+1 ビューに対応しています (「典型的なアーキテクチャビュー セット」を参照)。ソフトウェア アーキテクトはこのように、完成の程度に応じて最も適するもの (アーキテクチャ設計だけか、それとも設計と実装の両方か) を選択できます。 

参照アーキテクチャが製品群アーキテクチャになる場合、システムの構築に使用されるコンポーネントのインスタンスを含まないように参照アーキテクチャを定義することがよくありますが、これは厳密な、または定着した区別法ではありません。RUP (Rational Unified Process) では、参照アーキテクチャの概念に、再利用可能な既存コンポーネント (実装) への参照を含めることができます。

概要 ページの先頭へ

資産の組織化

参照アーキテクチャ資産を所有する組織では、それらの資産をどのように分類し、組織化するかを決定する必要があります。それにより、ソフトウェア アーキテクトは新しいシステムに対応する選択基準と照合することによって、必要な資産を簡単に取り出すことができます。参照アーキテクチャの作成と保存は現時点では RUP の対象範囲外となっていますが、1 つの提案として、ドメインの概念を中軸に据えてアーキテクチャを組織化する方法があります。その場合はドメインが、システムのある側面またはシステム ファミリーについての知識と概念を定義する主観的領域になります。ここでは「ドメイン」という用語を、アプリケーションよりも下位の階層における用語として使用できるものとします。この用法は一部の定義、たとえば参考資料 [HOF98] で提案されているものとは多少異なりますが、参考資料 [LMFS96] で提案されているものとはよく合致しています。

製品群ドメイン: 現存または将来の能力をグループ化して境界を定めたもの。コミュニケーション、分析、設計を促進し、製品群を貫く共通性を識別し、設計し、管理することを目的とします。そのようなドメインとして定義できるものの例には、密接に関連するエンドユーザー システムのグループ、複数のシステム間で共通して使用される機能、幅広く適用可能な基盤サービス群のグループ化、などがあります。」

この定義には、システムを構成するために使用される要素があるドメインに属しており、そのドメイン自体に考察の対象としての意味がある、という考えが含まれます。参考資料 [LMFS96] から引用した次の図は、この原則を示しています。

米軍の水平ドメインと垂直ドメイン

この図では、主要なシステム ファミリー、情報システム、指揮統制系統、兵器システムを示しています。それぞれにはいくつかの垂直ドメインと、それらの垂直ドメインだけでなくシステム ファミリーをも横断するいくつかの水平ドメインが完全に包含されます。そのため、リアルタイム スケジューリングの概念を、指揮統制系統の戦術ドメインと、兵器システムのすべての垂直ドメインに適用できます。したがって、これらすべてのドメインに対してリアルタイム スケジューリングの問題をいったん解決し、その過程で培われた知識と資産を独立したドメインとして扱うことには多分に意味があります。たとえば、そのようなドメインは以後、「兵員情報システム」ではなく「電子戦」に関連づけられるようになります。

内容

参照アーキテクチャの形態は、成果物: ソフトウェア アーキテクチャ説明書やそれに関連するモデルと同じですが、参照アーキテクチャを資産ベース内で適切に分類できるように、プロジェクト固有の参照情報が割愛されているか、プロジェクトごとの参照や特徴が汎用的なものに置き換えられています。SAD (ソフトウェア アーキテクチャ説明書) と関連づけられる一般的なモデルには、ユース ケース モデル、設計モデル、実装モデル、配置モデルがあります。

SAD とそれに関連づけられたモデルへのアクセスは、ソフトウェア アーキテクトにとって作業を開始するための出発点となります。ソフトウェア アーキテクトは、アーキテクチャの概念部分または論理部分だけを選択的に使用できます (組織の再利用ポリシーでそのことが認められている場合)。それとは正反対に、ソフトウェア アーキテクトは、物理レベルで完全に機能するサブシステムや配置モデル (つまり、完成したハードウェアとネットワークの青写真) を資産ベースから再利用することも可能です。

アーキテクチャ資産を使用可能にするには、その他の補助成果物が必要です。 

  1. ユース ケース モデルはアーキテクチャの振る舞いを記述しますが、ソフトウェア アーキテクトは機能面以外のアーキテクチャの品質についても知る必要があります。その 2 つの側面 (ユース ケースモデルと機能外要求) は、ソフトウェア要求仕様書で既に把握されている場合があります。ソフトウェア アーキテクトはこの仕様書に基づいて、参照アーキテクチャが現在の要求をどの程度満たしているかを判断することができます。

  2. アーキテクチャを使用するとき、特にその修正を行うときは、開発当初と同じガイダンスが必要となります。たとえばソフトウェア アーキテクトは、参照アーキテクチャの作成時に適用されたルールや、インターフェイスの修正の難易度について知る必要があります。参照アーキテクチャに関連づけられた設計ガイドラインにアクセスすると、これらの疑問への答えを得る上で役立つ可能性があります。

  3. (オプション) 関連する既存のテスト計画書を見直すことも役に立つ場合があります。これらのテスト計画書は、類似のアーキテクチャをテストする目的で使用される前に、テストと評価の戦略をアーキテクトに伝達し、その性質上、アーキテクチャの潜在的な脆弱性を見つけ出すための手掛かりとなる傾向があります。

  4. (オプション) 関連する既存のテスト自動化成果物とテスト インターフェイス仕様書を見直すと役に立つ場合があります。これらの成果物によって、アーキテクトは対象のアーキテクチャに頻出する要求を知ることができ、テスト作業が円滑になります。

タイミング ページの先頭へ

参照アーキテクチャは方向づけフェーズ、および推敲フェーズの初期に、アーキテクチャの合成とアーキテクチャ候補の選択がなされる間に使用されます。参照アーキテクチャの作成は組織面の問題であり、現時点では RUP の対象範囲外です。プロジェクトが終了すると、プロジェクトの期間中に作成された成果物が検査され、組織の資産ベースに取り込んで保存できるものがあるかどうかが調べられます。ただし、この検査のために実施する作業とその際の手法は、ここでは推敲の対象になりません。

責務 ページの先頭へ

ソフトウェア アーキテクトは、参照アーキテクチャの選択と使用に責任を持ちます。

カスタマイズ ページの先頭へ

全く前例のないシステムを開発するような場合を除いて、開発組織が利用できる参照アーキテクチャが存在する場合には、そのアーキテクチャを (対象のドメインと開発タイプに) 適用できるかどうかを検査することが推奨されます。参照アーキテクチャの作成は、組織レベルで対処する問題です。前の「内容」の項で示した項目は必要に応じて取捨選択でき、その場合でもアーキテクチャの再利用の利点はある程度は享受できます。たとえば、テスト モデルは省略することができます。ただし、アーキテクチャが修正された場合にはテストを作成し直す必要があります。最低限のセットとして考えられるのは、1 つの設計モデルと、そのモデルに関連づけられる振る舞いの記述 (おそらくはユース ケース モデル) です。それよりも少ない内容であれば、ある種の有効なパターン (分析、設計など) であることには違いないものの、その資産を参照アーキテクチャと呼ぶことは難しいでしょう。



Rational Unified Process   2003.06.15