トピック
  • 分析クラスからの設計要素の識別
  • 分析モデルへのマッピング
  • 実装モデルへのマッピング
  • よい設計モデルの特徴
  • 分析クラスからの設計要素の識別 ページの先頭へ

    成果物: 分析クラス」は、設計要素のインスタンスが演じるロールを表しています。これらのロールは、1 つ以上の設計モデル要素で実現できます。さらに、1 つの設計要素が複数のロールを実現することも可能です。次に、分析ロールの実現方法について説明します。

    • 分析クラスは、設計モデルにおいて 1 つの設計クラスになる場合があります。
    • 分析クラスは、設計モデルにおいて 1 つの設計クラスの一部になる場合があります。
    • 分析クラスは、設計モデルにおいて 1 つの集約クラスになる場合があります (つまり、この集約の一部は分析クラスとして明示的にモデル化されない場合があります)。
    • 分析クラスは、設計モデルの同じクラスから継承する設計クラスのグループになる場合があります。
    • 分析クラスは、設計モデルにおいて機能的に関連したクラスのグループになる場合があります。
    • 分析クラスは、設計モデルにおいて設計サブシステムになる場合があります。
    • 分析クラスは、設計サブシステムの一部になる場合があります。1 つ以上のインターフェイスとそれに対応する実装のような場合です。
    • 分析クラスは、設計モデルにおいて関係になる場合があります。
    • 分析クラス間の関係は、設計モデルにおいて設計クラスになる場合があります。
    • 分析クラスは主に機能的要求を扱い、「問題」領域からのオブジェクトをモデル化します。設計クラスは非機能的要求を扱い、「ソリューション」領域からのオブジェクトをモデル化します。
    • 分析クラスを使用すると、ハードウェアやソフトウェアによるサポートの程度を決定しなくても、「システムでサポートしたいオブジェクト」を表現できます。このため、分析クラスの一部をハードウェアで実現し、設計モデルではまったくモデル化しないことも可能です。

    上記の任意の組み合わせも可能です。

    分析モデルを独立して保持する場合は、識別された設計要素から対応する分析クラスへの追跡可能性を、維持する必要があります。詳しくは、「分析モデルへのマッピング」を参照してください。

    分析モデルへのマッピング ページの先頭へ

    ここでの説明は、分析モデルを独立して保持する場合にのみ適用されます。

    設計の際には、アーキテクチャおよび選択された技術との密接な対応をサポートする設計要素を識別します。分析モデルのすべての分析クラスは、設計モデルの少なくとも 1 つの設計クラスに関連付けられなければなりません。

    この追跡可能性をモデル化するには、次のダイアグラムで示すように、設計要素から、それが表す分析クラスに対して、≪trace≫ 依存関係を記述する必要があります。

    メモ: 追跡可能性のリンクは、設計モデル要素から分析モデル要素に対して記述し、設計モデルが分析モデルに依存するのであって、その逆ではないことを示します。

    実装モデルへのマッピングページの先頭へ

    設計モデルのクラスがどのようにして実装クラスと関連するかは、設計開始前に決定し、プロジェクト固有のの設計ガイドラインに記述する必要があります。

    設計モデルは、クラス、パッケージ、サブシステムを、実装モデルの実装クラス、ファイル、パッケージ、サブシステムにどのようにマップするかによって、実装モデルにある程度近いものにすることができます。実装作業中は、設計モデルには影響を与えない、実装環境に関連する小さな戦術的問題に対処することが多くあります。たとえば、並列開発に対処したり、インポート依存関係を調整したりするために、実装中にクラスとサブシステムを追加できます。詳しくは、「作業: 実装モデルの整理」と「概念: 設計のコードへのマッピング」を参照してください。

    設計モデルから実装モデルに対しては、一貫したマッピングが存在しなければなりません。「../artifact/ar_projspecgls.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません成果物: プロジェクト固有ガイドライン」では、このマッピングを定義して、設計モデル全体にわたって一貫したレベルの抽象化を適用します。

    よい設計モデルの特徴 ページの先頭へ

    よい設計モデルは、次の特徴を備えています。

    • システム要求を満たします
    • 実装環境の変更に耐えられます
    • 異なるオブジェクト モデルを使用した場合や、システム実装段階でも、保守が容易です
    • 実装方法が明快です
    • プログラム コード中に文書化するのが最善な情報を含んでいません
    • 要求の変化に簡単に対応できます

    具体的な特徴については、「チェックポイント: 設計モデル」を参照してください。



    Rational Unified Process   2003.06.15