このワークフローの詳細の目的は、システムの設計を洗練することです。

トピック


      分析クラス
分析クラス
  分析クラス
分析クラス
  設計クラス
設計クラス
  インターフェイス
インターフェイス
設計サブシステム
設計サブシステム
  ユース ケース
ユース ケース
 
               
 
設計者
設計者
 

 
Enterprise JavaBeans (EJB) の設計
Enterprise
JavaBeans
(EJB) の設計

 
クラス設計
クラス設計

 
テスト可能性要素の設計
テスト可能性要素の設計

 
サブシステム設計
サブシステム設計

 
ユース ケース設計
ユース ケース設計

 
               
      設計モデル
設計モデル
Enterprise Java Beans (EJB)
Enterprise
Java Beans
(EJB)
  設計モデル
設計モデル
設計クラス
設計クラス
  設計パッケージ
設計パッケージ
テスト可能性クラス
テスト可能性クラス
  設計サブシステム
設計サブシステム
設計クラス
設計クラス
  設計モデル
設計モデル
ユース・ケースの実現
ユース・ケースの実現
 
                  インターフェイス
インターフェイス
設計モデル
設計モデル
     

      ナビゲーション マップ
ナビゲーション
マップ
設計モデル
設計モデル
 
       
 
テクニカル レビュー担当者
テクニカル レビュー担当者
 

 
設計レビュー
設計レビュー

 
       
      レビュー記録
レビュー記録
 


説明 ページの先頭へ

このワークフローの詳細の目標は次のとおりです。

  • 要求される振る舞いを設計の要素 が実現する方法の「詳細」を考え出すことで、設計の要素の定義を洗練する
  • 識別される新しい設計の要素に基づいてユース ケースの実現を洗練、更新する (すなわち、ユース ケースの実現を更新された状態に保つ)
  • 発展していく設計をレビューする

関連情報 ページの先頭へ

このワークフローの詳細に関連する追加情報へのリンクを提供します。

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

推敲フェーズで開始します。作成フェーズと移行フェーズで繰り返します。

オプション度 ページの先頭へ

必須

要員配置方法 ページの先頭へ

通常は、1 人の人または小さいチームが 1 セットの設計の要素 (普通は、その他の設計の要素が含まれる 1 つ以上のパッケージまたはサブシステム) を担当します。この人またはチームは、パッケージまたはサブシステムに含まれる要素の設計の詳細の肉付けを行い、すべての操作定義とほかの設計の要素との関係の定義を完了します。「作業: クラス設計」では、 クラスの設計の要素の設計の洗練に重点を置き、「作業: サブシステム設計」では、サブシステムそのものにマッピングされる振る舞いを、中に含まれる設計の要素 (中に含まれるクラスまたはサブシステム) に割り当てることに重点を置きます。

クラスの設計を担当する個人は、実装言語、パッシブ クラスに使用されるアルゴリズムや技術にも精通している必要があります。サブシステムを担当する個人またはチームは、ゼネラリストである必要があり、設計の要素間での機能の適切なパッケージ分割について決定を下すことができ、さまざまな代替の設計に伴う固有のトレードオフを理解できる必要があります。

個別の設計の要素を洗練する一方で、設計の要素の責務の発展を反映するように、ユース ケースの実現を洗練しなければなりません。通常は、1 人の人または小さいチームが、1 つ以上の関連するユース ケースの実現の洗練を担当します。設計の要素が追加、洗練されるにつれて、ユース ケースの実現が古くなるか、設計モデルの改善によってユース ケースの実現の単純化が可能になるので、ユース ケースの実現を再検討して発展させる必要があります。ユース ケースの実現を担当する個人またはチームは、ユース ケースに必要な振る舞いについて、また、この振る舞いを設計の要素の中で割り当てるさまざまな方式のトレードオフについて、幅広く理解する必要があります。さらに、この個人またはチームは、ユース ケースを実行する要素の選択を担当しているので、設計の要素そのものの外部の (公開の) 振る舞いについて深く理解する必要があります。

作業ガイドライン ページの先頭へ

通常、ここでの作業は、個人または小さいチームによって行われ、チーム間で変更を伝達するために必要な場合は、非公式のグループ間相互作用を行います。設計の要素が洗練されるにつれて、多くの場合、チーム間で責務が移動し、複数の設計の要素とユース ケースの実現に同時に変更を加える必要が出てきます。責務が相互に影響するので、設計チームのメンバーが完全に単独で作業することはほとんど不可能になります。(ユース ケースの実現で表現された) システムに必要な振る舞いに重点を置いた設計作業を続けるために、たとえば次のような典型的なパターンの相互作用が行われます。

  • 担当者または担当チームによって設計の要素が洗練されます。
  • (約 2 ~ 5 人の) 小さいグループが非公式に集まり、既存のユース ケースの実現のセットについて、新しい設計の要素の影響を考え出します。
  • 討議の間に、ユース ケースの実現と参加する設計の要素の両方への変更が識別されます。
  • その回の反復に必要なすべての振る舞いが設計されるまで、このサイクルが繰り返されます。

プロセスそのものが反復的なので、「その回の反復に必要なすべての振る舞い」の基準は、ライフサイクルの中での位置に応じて次のように異なります。

  • 推敲フェーズでは、アーキテクチャ上重要な振る舞いに重点が置かれ、その他のすべての「詳細」は効果的に無視されます (または「スタブが作成されます」)。
  • 作成フェーズが終わるころには未解決の設計の問題がなくなるようにするために、作成フェーズでは設計の完全性と一貫性に重点が移ります。

1 回の反復の設計は、実装とテストの作業を始める前に完全にする必要はありません。1 回の反復の中でも、設計が発展するにつれて部分的に実装とテストを行うことは、設計の検証と洗練の効果的な方法になります。


Rational Unified Process   2003.06.15