トピック

概論先頭

    • クラス名は、そのクラスが果たす役割を明確に反映している。
    • クラスの説明は、そのクラスの目的を明確に伝えている。
    • クラスは、単一の入念に定義された抽象を表している。
    • クラスの属性と操作はいずれも、そのクラスの責任を果たすのに不可欠である。
    • 各クラスは、少量で一貫性があってしかも固有である一連の責務を表している。
    • クラスの責務は、入念に定義され、明快に記述され、そしてそのクラスの目的に対してはっきりと関連付けられている。
    • 各クラスは、相対的に自己完結であって、他のクラスに疎結合されている。
    • クラスの責務は一貫性のある抽象レベル (アプリケーション・レベル) 上にあって、下位レベル (実装レベル) の責務は混じっていない。
    • 同じ階層内のクラスは固有のクラス属性、操作、および関係をもっている (すなわち、共通の属性、操作、および関係を継承している)。
    • クラスのインスタンスのライフ・サイクルは総体的に妥当なものである。 どのオブジェクトも、1 つ以上のユース・ケースの実現によって作成、使用、および除去される。
    • クラスは、ユース・ケースの実現によって確立された動作に関する要件を満足している。
    • 要件定義内のクラスに関するすべての要件が特定されている。
    • クラスの必要性 (クラスの説明においてと、シーケンス・ダイアグラム中のオブジェクトで反映されているもの) は、そのクラスの状態マシンに対して一貫性がある。
    • クラスのすべての責務は相互に関連しあっている。それによって、責務によっては利用されることもされないこともあるシステムでは、そのクラスは存在できないようになっている。
    • 基本的に同じ目的をもつクラスが複数存在することはない。

一般化/特殊化先頭へ

    • 階層が浅すぎたり深すぎたりするクラスが生じないように、一般化階層のバランスがとれている。
    • 明確な共通性が継承階層において反映されている。
    • 複数のサブクラスの属性を併合したと思われるスーパークラスはない。
    • 直交プロパティーをもった継承階層内に中間の抽象クラスはない。その例には、継承ツリーの両端で重複しているサブクラスがあります。
    • コードまたはクラス構造を再利用するためなどの、主として実装に対する配慮からではなく、設計の共通抽象を取り込むのに継承が使用される。

命名規則先頭へ

    • クラス名は、目的を示している。
    • クラス名は、プロジェクト設計ガイドラインに指定された命名規則に従っている。

操作 先頭へ

    • 各操作の名前は、よく意味の通じる分かりやすい名前である。
    • 状態マシンと操作には一貫性がある。
    • 状態マシンと操作は、クラスの動作を十分に表現している。
    • 各操作のパラメーターは、数字、名前、およびタイプという見地から見て正しい。
    • 各操作が定義済みの場合、それぞれの実装の仕様は正しい。
    • 操作シグニチャーは、ターゲットのプログラム言語の規格に準拠している。
    • どの操作も、少なくとも 1 つのユース・ケースの実現で使用される。

属性先頭へ

    • クラスの一部の操作をサポートするのに、クラスのすべての関係が必要である。
    • 属性は、それぞれ 1 つの概念事項を表している。
    • 各属性の名前は、よく意味が通じていて、保管している情報を正しく伝えている。

関係先頭へ

    • 集約と関連付けの役割名は、関連付けを行う側と行われる側のクラスの関係を言い表している。
    • 関係の多様性は正しい。

状態マシン 先頭へ

    • 状態マシンは、可能なかぎり単純でありながら、必要とされる動作は十分に表している。
    • 状態マシンには、不必要な状態や遷移はまったく入っていない。
    • 状態マシンは明確な前後関係をもっている。
    • すべての参照オブジェクトは、それを収容するオブジェクトから見えている。
    • 状態マシンは効率が良く、ディスパッチするアクションで定義されたとおりに、時間とリソースの最適なバランスをとりながら動作を実行する。
    • 状態マシンは分かりやすい。
      • システム・ドメインの観点から見て、状態と遷移の名前は分かりやすい。
      • 状態名は、過去に発生した事項ではなく、将来または現在発生する事項を示している。
      • 状態と遷移の名前は、状態マシン内の固有名である (ただし、これは絶対的な要件ではなく、固有名の実施のためのデバッグで役立ちます)。
      • 複合状態には、状態の論理的なグループ化が組み入れられている。
      • 煩雑さを軽減するために、複合状態が効果的に使用されているか。
      • 遷移ラベルは、遷移の根本原因を反映している。
      • 状態遷移を対象とした、25 行を超える詳細コードから成るコード断片はない。その代わりに、関数が効率よく利用されて、遷移コードの複雑さが軽減される。
      • 状態マシンのネスティングは検査されて、理解できないほどネスティングが深くなっていないことが確認されている。動作が複雑であっても、たいていは 1 つまたは 2 つのレベルのサブ状態で十分です。
    • 並行しあっているサブ状態ではなく、アクティブなクラスを使用している。ほぼ常に、アクティブ・クラスのほうが、並行のサブ状態よりも適切であってしかも分かりやすいクラスです。
    • エラー状態または保守状態について説明されている。
    • 拡張状態変数の代わりにサブ状態を使用している。遷移の実行を指示するかどうかを決めるのに複数の変数をテストする遷移保護条件はない。
    • 状態マシンは、フローチャートに似通っていない。
    • 状態マシンは、過度に細かい構成になっていない。それぞれがサブ状態を 1 つずつもった複数のネストされた状態マシンで構成されていない。 将来の設計作業またはサブクラスの設定のために、ネストされたサブ状態をプレースホルダーにしたい場合、その選択を慎重に行うことを前提に、これが暫定的に許容されることもあります。


Rational Unified Process   2003.06.15