分析クラスは、「責務と振る舞いを持つシステム内の事象」の初期概念モデルを表現します。
そのほかの関係:  一部分析モデル
役割:  設計者 
オプション度 / 使用時期:  オプション。推敲フェーズと作成フェーズ
テンプレートとレポート: 
 
例:   
UML の表現:  «boundary»、«entity»、«control» のいずれかとしてステレオタイプ化されるクラス 
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

分析クラスは、システムが果たすべき主要な「責務」の把握に使用されます。これらはシステムのクラスのプロトタイプで、システムで処理すべき主要概念の第一歩です。システムの「高水準」で概念的な概観を求めている場合、分析クラスを独立して維持します。また、分析クラスは、システム設計 (設計クラスやシステムのサブシステム) の主要な抽象概念を生み出します。

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

プロパティ名 

概要 

UML の表現 

name  クラスの名前  属性 
description  システム内でのクラスの役割の簡単な説明  属性 
responsibilities クラスの責務の一覧  属性 
attributes  クラスの属性  属性 

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

分析クラスは主に、ユース ケースの分析と並行して推敲フェーズで識別されます。作成フェーズまでユース ケースの分析を行わない場合、一部の分析クラスが作成フェーズで識別される場合があります。

責務 ページの先頭へ

設計者は次のことを確実にすることで、分析クラスの整合性に責任を持ちます。

  • 分析クラスが完全で、論理的に矛盾がない
  • すべての情報 (上の「プロパティ」を参照) が把握され、正確である

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

分析クラスは全体として、システムの初期概念モデルを表現します。この概念モデルは急速に発展し、さまざまな表現や各表現の意味が検討されるしばらくの間、流動的な状態にとどまります。正式に文書化するとこのプロセスの進捗が妨げられる可能性があるので、正式なものとしてこの「モデル」の保守にどの程度の労力を費やすかは、慎重に決定します。そうしないと、消耗品としての性質が強いモデルの改良に多くの時間を浪費してしまうことがあります。分析クラスが変更されずに設計に反映されることはほとんどありません。分析クラスの多くは、オブジェクトのコラボレーション全体を表現します。これはしばしばサブシステムによってカプセル化されます。

通常は、次の例のような、シンプルなメモカードを作成すれば充分です (これはよく知られた CRC カード技法に基づいています。この技術について詳しくは、参考資料 [WIR90] を参照してください)。まず、カードの表側にクラスの名前と説明を書きます。次に、履修コース登録システムにおける Course というクラスを例として示します。

クラス名  Course 
説明  Course の責務は、共通の科目、必要条件、時間割を持つ一連のコース セクションについての情報を保持することです。 
責務  コースについての情報を保持すること 
属性  説明   
Course Title  コースの名前  string 
Description  コースの簡潔な説明  string 

カードの裏側には、クラスの図を描きます。

Course のクラス図

ユース ケース分析検討会議の間に発見されたクラスごとに 1 枚の分析クラス カードを作成します。



Rational Unified Process   2003.06.15