トピック

説明ページの先頭へ

数百の要素から成る実装モデルの複雑さを減少させる基本的な方法は、実装サブシステムを使うことです。

一般に、サブシステムはディレクトリ構造を採用し、構造情報や管理情報を付加しています。たとえば、サブシステムは、ディレクトリまたはファイル システムのフォルダとして、C++ や Ada 用の Rational/Apex のサブシステムとして、Java を使用するパッケージとして作成できます。Rational XDE の開発では、サブシステムは統合開発環境 (IDE) で定義されている「プロジェクト」です。

実装サブシステムは、実装において設計パッケージ (または大まかな 設計サブシステム) に相当するものです。実装モデルと実装サブシステムは、実装ビューの対象となるも ので、開発時に最も重要となります。

要素のエクスポート

実装サブシステムは、コンテンツの外部からの可視性を制御します。要素を宣言しているサブシステムにより可視 (「エクスポート済み」) になっている場合、その要素はサブシステム外の要素から参照できます。

一般に、サブシステム内のすべての要素 (および含まれているサブシステム) は、デフォルトでサブシステム外から可視状態になっています。これは、このサブシステム外のどの要素からも、すべての要素を参照できるということです。たとえば、C++ では、外部にある要素はサブシステム内の全要素を #include できることを意味しています。

使用 ページの先頭へ

実装モデルは、設計パッケージを実装モデルの実装サブシステムにどのようにマッピングするかにより、ある程度設計モデルに近づけることができます。

このマッピングでは、1 対 1 つまり 1 つの設計パッケージを 1 つの実装サブシステムにマッピングすることが推奨されます。このようにするのは、設計からコーディングまでシームレスに追跡できるようにするためです。

実装のサブシステムを設計のパッケージおよびサブシステムとは異なるものにすることが必要になる場合があります。詳しくは、「作業: 実装モデルの整理」を参照してください。このマッピングを表現するかどうか、またその方法については、「../artifact/ar_projspecgls.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません成果物: プロジェクト固有ガイドライン」で記述する必要があります。

システムをサブシステムに区分するのには、多くの理由があります。設計時と同じ基準を実装時にも適用できます。詳しくは、「ガイドライン: 設計パッケージ」を参照してください。



Rational Unified Process   2003.06.15