成果物:
|
![]() |
この成果物は、ユース ケースの実現を記述し、成果物: 設計モデルの抽象化として機能するオブジェクト モデルです。分析モデルには、ユース ケース分析の結果と成果物: 分析クラスのインスタンスが含まれます。 |
そのほかの関係: |
含む
|
---|---|
役割: | ソフトウェア アーキテクト |
オプション度 / 使用時期: | オプション。推敲フェーズと作成フェーズ |
テンプレートとレポート: |
|
例: | |
UML の表現: | «analysis model» としてステレオタイプ化されるモデル |
詳細情報: | |
成果物を入力とする作業: | 成果物を出力とする作業: |
分析モデルには、分析クラスと関連する成果物が含まれます。分析モデルは、設計モデルに発展する場合は一時的な成果物となりますが、プロジェクトの一部または全体を通して活用され、さらにはその先に至るまで、システムの概念を理解するための資料として役立つ場合もあります。
プロパティ名 |
概要 |
UML の表現 |
Introduction | モデルの簡単な紹介を記述したテキスト | 「short text」型のタグ付き値 |
Analysis Packages | 階層を表すモデル内のパッケージ | 関連「represents」を通して、または集約「owns」を通して再帰的に所有される |
Classes | パッケージに属するモデル内のクラス | 集約「owns」を通して再帰的に所有される |
Relationships | パッケージに属するモデル内の関係 | -" - |
Use-Case Realizations | パッケージに属するモデル内のユース ケースの実現 | -" - |
Diagrams | パッケージに属するモデル内のダイアグラム | -" - |
分析モデルは推敲フェーズで作成され、作成フェーズでモデルの構造が変更されるときに更新されます。
ソフトウェア アーキテクトは次のことを確実にすることで、分析モデルの整合性に責任を持ちます。
「分析クラス」は通常、そのまま設計モデルの要素に発展します。設計クラスになるものもあれば、設計サブシステムになるものもあります。分析の目標は、システム内のモデリング要素に対する必要な振る舞いの予備的なマッピングを識別することです。設計の目標は、この予備的な (ある種理想化された) マッピングを、実装可能な一連のモデル要素に変換することです。その結果、分析から設計に移行する際には、詳細部分や精度が洗練されることになります。つまり、「分析クラス」は多分に流動的で変わりやすく、設計作業でその内容が確定するまでに大きく発展します。
独立した分析モデルが必要かどうか判断するポイントは、次のとおりです。
何十年も同じシステムを使ったり、同系列のシステムが多数存在したりするような会社では、独立した分析モデルを使用すると役に立つことが実証されています。
Rational Unified Process
|