設計パッケージは、クラス、関係、ユース ケースの実現、ダイアグラム、その他のパッケージの集合体です。設計パッケージは、設計モデルをより細かな部分に分解して構造化するために使用されます。 
そのほかの関係:  一部設計モデル
役割:  設計者 
オプション度 / 使用時期:  必須。推敲フェーズと作成フェーズ
テンプレートとレポート: 
 
例:   
UML の表現:  設計内モデルのパッケージ 
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

設計パッケージは、関連性のある設計モデル要素を組織の目的に合わせて、また多くの場合構成管理のためにグループ化する目的で使用します。成果物: 設計サブシステムとは異なり、設計パッケージでは正式なインターフェイスは提供されませんが、振る舞いを提供するその内容の一部 (「public」とマークされたもの) を公開する場合があります。設計パッケージは主に、関連する要素群をグループ化するためのモデル組織化ツールとして使用するべきです。振る舞いのセマンティクスが必要な場合は、設計サブシステムを使用します。

設計パッケージとその内容物には、1 人の役割: 設計者が責任を持ちます。パッケージ内の要素が、ほかのパッケージに保有されている要素に依存する場合があります。これにより、パッケージ間に依存関係が発生します。パッケージの依存関係は、設計モデルの柔軟性を分析するためのツールとして使用できます。相互依存関係を持つモデルは、変化に対する柔軟性に欠けます。

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

プロパティ名 

概要 

UML の表現 

Name  パッケージの名前  モデル要素の「Name」属性 
Brief Description  パッケージの役割と目的、または「テーマ」の簡単な説明  「short text」型のタグ付き値 
Classes  パッケージに直接保有されるクラス  集約「owns」を通して所有される 
Relationships  パッケージに直接保有される関係  - " - 
Use-Case Realizations  パッケージに直接保有されるユース ケースの実現  - " - 
Diagrams  パッケージに直接保有されるダイアグラム  - " - 
Design Packages  パッケージに直接保有されるパッケージ  - " - 
Import Dependencies  パッケージからほかのパッケージへのインポート依存関係  集約「owns」を通して、包含する側のパッケージに所有される 

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

パッケージ作成は基本的に推敲フェーズの間に行われますが、作成フェーズの間、特に作業の割り当てをやり直したり、パッケージ間の依存関係を再構成したりする目的で、パッケージの微調整が行われます。

責務 ページの先頭へ

設計者は次の事柄を徹底し、パッケージの整合性に責任を持ちます。

  • 必要な要求をパッケージが満たしていること。
  • パッケージが、ほかのパッケージからできるだけ独立を保っていること。
  • 将来の変更による影響を見積もることができるように、対象のパッケージを起点とするインポート依存関係が記述されていること。
  • クラス、関係、ユース ケースの実現、ダイアグラム、パッケージなど、パッケージの直接の内容物の存在に正当性があり、整合性がとれていること。
  • パッケージの直接の内容物 (主にクラスとパッケージ) の可視性が正しいこと。設定できる可視性には「public」、「private」などがあります。

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

設計者は、パッケージに含まれるユース ケースの実現や、それらのユース ケースの実現に関連するダイアグラムには責任を持たないことに注意してください。これらに関しては、該当するユース ケースの設計者が責任を持ちます。

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

パッケージは、モデル内で類似したモデル要素をグループ化するため使用されます。これによって、モデルの組織化の度合いを高め、モデルを理解しやすくします。大きなモデルでは、パッケージ作成は不可欠です。小さなモデルであっても、適切なパッケージ化を行うと、モデルのわかりやすさが大幅に向上します。パッケージ化を行うことは、ほとんどどのような場合にも有用です。詳しくは、「ガイドライン: 設計パッケージ」を参照してください。



Rational Unified Process   2003.06.15