クラスは同じ責務、関係、操作、属性、セマンティクスを共有するオブジェクトの集合を記述します。 
そのほかの関係:  一部設計モデル
役割:  設計者 
オプション度 / 使用時期:  設計クラスは、オブジェクト指向設計アプローチの基礎をなす部分です。
テンプレートとレポート: 
 
例:   
UML の表現:  クラス
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

クラスを使用するのは次の人々です。

  • 実装担当者。クラスを実装するときに仕様として使用します。
  • システムのほかの部分を担当する設計者。担当外の部分の機能の使用方法や、それらの部分間の関係を理解するために使用します。
  • ユース ケース設計者。ユース ケースの実現において、クラスをインスタンス化します。
  • システムの次のバージョンの設計者。設計モデルの機能を理解するために使用します。
  • クラスのテスト担当者。テスト作業の計画に使用します。

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

プロパティ名 

概要 

UML の表現 

Name  クラスの名前  モデル要素の「Name」属性 
Brief Description  クラスの役割と目的の簡単な説明  「short text」型のタグ付き値 
Responsibilities  クラスで定義される責務  (事前に定義された) スーパークラス「Type」のタグ付き値 
Relationships  クラスが参加する、汎化、関連、集約などの関係  集約「owns」を通して、包含する側のパッケージに所有される 
Operations  クラスで定義される操作  集約「members」を通して、スーパークラス「Type」に所有される 
Attributes  クラスで定義される属性  - " - 
Special Requirements  設計モデルでは考慮しないが、実装の段階で処理しなければならないクラスの要求 (機能外要求など) をすべて記述したテキスト  「short text」型のタグ付き値 
Diagrams  クラスが関係する、相互作用図、クラス図、ステートチャート図などのダイアグラム  集約「owns」を通して、包含する側のパッケージに所有される 

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

アーキテクチャ上重要な設計クラスは、推敲フェーズで識別され、記述されます。その他の設計クラスは、作成フェーズで識別され、記述されます。

責務 ページの先頭へ

設計者は次の事柄を徹底し、クラスの整合性に責任を持ちます。

  • クラスが参加するユース ケースの実現において、クラスに期待される要求をクラスが満たしていること。
  • ほかのクラスからできるだけ独立を保っていること。
  • 責務、単方向の関係、操作、属性などのクラスのプロパティが正しく設定され、互いに整合性がとれていること。
  • 関係している双方向関係におけるクラスの役割が、明確で直観的であること。
  • クラスのメンバー、主要な操作、主要な属性の可視性が正しいこと。設定できる可視性には「public」、「private」などがあります。
  • クラスのメンバー、主要な操作、主要な属性のスコープが正しいこと。型 / クラスのスコープについてはスコープは「true」、オブジェクト / インスタンスのスコープの場合は「false」となります。
  • Special Requirements (特殊な要求) プロパティの内容が理解しやすく、その目的に合っていること。
  • クラスを記述しているダイアグラムが理解しやすく、ほかのプロパティと整合性がとれていること。

あるクラスについて責任を持つ設計者は、そのクラスが属する設計パッケージについても責任を持つことが推奨されます。詳しくは、「設計パッケージ」を参照してください。

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

ステレオタイプを使用して、設計クラスを修飾したり、何らかの形態で実装を制約することができます。たとえば、ステレオタイプを使用して、クラスがプログラミング言語の特定の構造を表していることを示すことができます。

詳しくは、「ガイドライン: 設計クラス」を参照してください。



Rational Unified Process   2003.06.15