設計モデルは、ユース ケースの実現を記述するオブジェクト モデルで、実装モデルとそのソース コードを抽象化する役割を果たします。また、実装とテストの作業に必須の入力情報としても使用されます。 
そのほかの関係:  含む
役割:  ソフトウェア アーキテクト 
オプション度 / 使用時期:  必須。推敲フェーズと作成フェーズ
テンプレートとレポート: 
 
例:   
UML の表現:  «designModel» としてステレオタイプ化されるモデル 
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

設計モデルはシステム実装の抽象概念です。ソフトウェア システムの設計を立案し、文書化するために使用されます。設計モデルは、すべての設計クラス、サブシステム、パッケージ、コラボレーション、およびそれらの要素間の関係を含む、包括的、複合的な成果物です。

プロパティ ページの先頭へ

プロパティ名 

概要 

UML の表現 

Introduction  モデルの簡単な紹介を記述したテキスト  「short text」型のタグ付き値 
Design Packages

Design Subsystems 

階層を表すモデル内のパッケージとサブシステム  関連「represents」を通して、または集約「owns」を通して再帰的に所有される 
Classes  パッケージに属するモデル内のクラス  集約「owns」を通して再帰的に所有される 
Interfaces  パッケージに属するモデル内のインターフェイス  集約「owns」を通して再帰的に所有される 
Events and Signals  パッケージに属するモデル内のイベントとシグナル  集約「owns」を通して再帰的に所有される 
Relationships  パッケージに属するモデル内の関係  - " - 
Use-Case Realizations  パッケージに属するモデル内のユース ケースの実現  - " - 
Diagrams  パッケージに属するモデル内のダイアグラム  - " - 

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

設計モデルは主にアーキテクチャを設定しますが、推敲フェーズで行われる分析の手段としても使用されます。その後、設計モデルは、作成フェーズで行われる詳細設計の決定に従って改良されます。

責務 ページの先頭へ

ソフトウェア アーキテクトは次の事柄を徹底し、設計モデルの整合性に責任を持ちます。

  • モデルが全体として正確で、一貫性があり、理解しやすいこと。ユース ケース モデルで記述される機能性を実現するときに設計モデルが正確であり、それ以外の振る舞いをしないこと。
  • 設計モデル内のアーキテクチャが、論理ビュー、プロセス ビュー、配置ビューを含めてその目的に合っていること。これらのビューについての記述は、別個の成果物に集められます。「成果物: ソフトウェア アーキテクチャ説明書」を参照してください。

ソフトウェア アーキテクトは、パッケージ、クラス、関係、ユース ケースの実現、ダイアグラムの各要素自体には責任を持たないことに注意してください。これらは各要素の設計者とユース ケース設計者の責務下に置かれます。

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

以下の点を決定します。

  • 組み込むプロパティ
  • 統一モデリング言語 (UML) の拡張の有無。たとえば、プロジェクトによってはステレオタイプの追加が必要な場合があります。
  • モデルに適用する形式性のレベル
  • 個々の副成果物に適用されるカスタマイズ
  • このモデルをどのように分析モデルにマッピングするか (「ガイドライン: 設計モデル」を参照)
  • 単独モデルと複数のモデルのどちらを使用するか
  • モデルが抽象仕様か、詳細仕様か、詳細設計か、それとも何らかの組み合わせであるかの区別 (「ガイドライン: 設計モデル」を参照)
  • このモデルをどのように実装モデルにマッピングするか (これは、リバース エンジニアリング、コード生成、ラウンドトリップ エンジニアリングのうちどれを使用するかの決定によって大きく影響されます)。「ガイドライン: 設計からコードへのマッピング」を参照

プロジェクトの設計ガイドラインで、カスタマイズに関する決定事項を文書化します 。



Rational Unified Process   2003.06.15