レイヤを使用したコンポーネントに基づくアーキテクチャ

トピック

コンポーネントに基づくアーキテクチャとは ページの先頭へ

コンポーネントに基づくアーキテクチャは、概念: コンポーネントで説明されている置き換え可能なコンポーネントに基づくアーキテクチャです。コンポーネントに基づくアーキテクチャは、独立していて置き換えが可能なモジュール コンポーネントを使用するため、複雑なアーキテクチャを管理してコンポーネントの再利用を促進するのに役立ちます。

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

RUP (Rational Unified Process) はライフサイクル全体にわたってユース ケースを使用しますが、設計作業ではシステム アーキテクチャの概念が中心となり、ソフトウェア集約型システムではソフトウェア アーキテクチャの概念が中心になります。プロセスの初期段階の反復 (大部分は推敲フェーズ) における主な重点は、ソフトウェア アーキテクチャの作成と確認にあります。このため、初期の開発サイクルでは、徐々に進化して終盤の反復で最終システムとなる実行可能なアーキテクチャ プロトタイプを作成します。

実行可能なアーキテクチャは、選択したシステムの機能とプロパティ、特に、機能外要求を満たすことを示すために作成する、システムの部分的な実装を表します。実行可能なアーキテクチャの目的は、作成フェーズで欠陥に対する不安を持たずにシステムのすべての機能をしっかりとした基盤上に追加できるように、性能、スループット、適応性、信頼性などに関するリスクを軽減することにあります。

アーキテクチャの概念 (特にソフトウェア アーキテクチャ) とこの概念が重要である理由の説明については、「概念: ソフトウェア アーキテクチャ」を参照してください。

RUP は、アーキテクチャを設計、開発、検証するための組織的、系統的な方法を備えています。複数のアーキテクチャ ビューの概念を中心としたアーキテクチャ記述のためのテンプレートと、アーキテクチャ スタイル、設計規則、制約を把握するためのテンプレートも用意されています。分析と設計の作業分野には、アーキテクチャを選択する方法のガイドラインに加え、アーキテクチャ上の制約とアーキテクチャ上重要な要素の識別を目的とした固有の作業が含まれます。管理プロセスは、初期の反復で、アーキテクチャの設計と主な技術上のリスクの解決策を考慮に入れて計画を立案する方法を示します。詳しくは、../../process/workflow/ovu_mgm.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんプロジェクト管理の作業分野と役割: ソフトウェア アーキテクトに関連するすべての作業を参照してください。

次のさまざまな理由により、アーキテクチャは重要です。

  • プロジェクトの効率的な管理と維持を行うことにより、複雑なプロジェクトを管理しシステムの整合性を維持することが可能です。

システムの複雑さは、システムのパーツごとの複雑さを合わせたものや、独立した小さな戦術上の決定が連続する場合の複雑さを上回ります。アーキテクチャは、これらのパーツを系統的に編成するためにいくつかの統一された一貫性のある構造を持ち、人の理解を超えるような複雑さにならずに、システムを拡張する方法について的確な規則を提供する必要があります。

共通の参照や設計の問題点について議論するための共通の用語を用意することにより、アーキテクチャでプロジェクト全体の意思の疎通と理解が向上する方法を確立できます。

  • 大規模な再利用を実現するための効率的な基礎になります。

主要なコンポーネントと、コンポーネント間の重要なインターフェイスを明確に表現することにより、共通部分を判別して使用する内部的な再利用と、既成の市販コンポーネントを組み込む外部的な再利用の両方が促進されます。一方、共通の領域でさまざまな機能に対処する一連の製品群の環境でアーキテクチャそのものを再利用する、大規模な再利用も可能です。

  • プロジェクト管理のための基礎を提供します。

計画立案と要員配置を、一連の主要なコンポーネントに合わせて編成します。基本的な構造上の決定は、分割されていない小規模でまとまったアーキテクチャ チームで実行します。開発をいくつかの小編成のチームにわたって分割し、それぞれのチームがシステムの 1 つ以上のパーツについて責務を負います。

コンポーネントに基づく開発 ページの先頭へ

コンポーネントに基づく開発は、一般的なアプリケーション開発と次の点が異なります。

  • アプリケーションを、多くの場合別のチームで開発され、比較的相互に独立している個々に実行可能なコンポーネントで構成します。RUP ではこれらのコンポーネントを「アセンブリ コンポーネント」と呼びます。詳しくは、「概念: コンポーネント」を参照してください。
  • アプリケーションを構成するいくつかのアセンブリ コンポーネントのみを更新することにより、アプリケーションを小さな追加要素で更新することができます。
  • アセンブリ コンポーネントを複数のアプリケーションで共有すると再利用が可能になりますが、プロジェクト間に依存関係も発生します。
  • 厳密にはコンポーネント化にかぎりませんが、コンポーネントに基づくアプリケーションは分散する傾向があります。

アセンブリ コンポーネントは次の方法で作成します。

  • モジュールで構成される典型的なアーキテクチャを定義する場合は、明確な形を持つコンポーネントの識別、切り分け、設計、開発、テストを行います。これらのコンポーネントは単体でテストを行い、徐々に統合してシステム全体を形成させることができます。
  • 特に広範囲の共通の問題に対して共通の解決策を提供するいくつかのコンポーネントは、再利用を目的として開発することができます。ユーティリティまたはクラス ライブラリを集めただけのものより大きい場合があるこれらの再利用可能なコンポーネントは、組織内での再利用の基礎となり、全体的なソフトウェアの生産性と品質が向上します。
  • CORBA、インターネット、ActiveX、JavaBeans、.NET、J2EE など、最近商業的に成功したコンポーネント環境の出現により、さまざまな分野で市販コンポーネントの全業界が活性化し、すべてを組織内で開発する代わりに、コンポーネントを購入して統合することができます。

ここに示した一覧で最も重要なことは、モジュール化とカプセル化の従来の概念を活用し、オブジェクト指向技術の基礎をなすこれらの概念をさらに進めることです。一覧の最後の 2 項目では、一度に 1 行を記述するソフトウェアのプログラミングから、コンポーネントを組み合わせることによりソフトウェアを構成する方法にソフトウェア開発が移行します。

RUP は、次に示す方法でコンポーネントに基づく開発をサポートします。

  • 反復型の手法を使用すると、コンポーネントを段階的に識別し、開発するコンポーネント、再利用するコンポーネント、購入するコンポーネントを決定することができます。
  • ソフトウェア アーキテクチャに焦点を当てると、コンポーネントが相互作用する基本的なメカニズムとパターンを含めた構造 (コンポーネントと、コンポーネントを統合する方法) を明確にすることができます。これにより、プロジェクト管理の計画立案の側面をサポートし、並行して開発できるコンポーネントと順番に開発するコンポーネントをコンポーネントの依存関係から決定することができます。
  • パッケージ、サブシステム、レイヤなどの概念は、分析と設計の段階でコンポーネントを編成してインターフェイスを指定するために使用します。
  • テストはまずコンポーネントを中心に編成し、次第に大規模な統合されたコンポーネントを中心に編成します。

コンポーネントについて詳しくは、「概念: コンポーネント」を参照してください。



Rational Unified Process   2003.06.15