ツール・メンター: Rational Software Architect を使用したユース・ケース分析の実行
目的
ここでは、このツール・メンターに関連する追加情報へのリンクを示します。
このツール・メンターの手順は、作業の手順と一致しています。RSA のオンライン・ヘルプのトピックへのリンクには というマークが付いています。
概要
このツール・メンターは、設計モデルとユース・ケース・モデルが 「Rational Software Architect のためのモデル構造ガイドライン」に従って作成されていることを前提としています。
さらに、「ツール・メンター: Rational Software Architect を使用したアクターとユース・ケースの獲得」に従って、ユース・ケース・モデルにアクターとユース・ケースが配置されていることを前提としています。
このツール・メンターでは、現在の反復で各ユース・ケースに対して以下の手順を実行します。
1 回の反復ごとに次の手順を実行します。
追加ツール情報
ユース・ケースの実現の作成
分析対象の各ユース・ケースについて、次の手順を実行します。
- ユース・ケース実現を作成するパッケージまで移動します。
「Rational Software Architect のためのモデル構造ガイドライン」を参照してください。
- このパッケージに UML コラボレーションを追加して、ユース・ケースの実現を表します。
実現しようとしているユース・ケースと同じ名前を付けます。
オプションで、UML キーワード「ユース・ケースの実現」を割り当てます。
- ユース・ケースの実現を作成したパッケージ内に、フリー・フォームのダイアグラムを作成します。
ユース・ケースの実現をこの上までドラッグします。
その後、ユース・ケースそのものを (ユース・ケース・モデルから) ダイアグラムまでドラッグします。
ユース・ケースの実現からユース・ケースに対して実現関係を描画します。
この時点で、追跡可能性のセマンティクスが確立されています。
フリー・フォームのダイアグラムは破棄したければ、破棄できます。
この後、
トピック・ダイアグラムと追跡可能性分析機能を使用して、モデル内の派生と洗練の関係を検査できます。
詳細については、
RSA オンライン・ヘルプのトピック 「Collaborations」を参照してください。
ユース・ケースの説明に対し、内部の振る舞いについての補足説明を追加する必要がある場合、「ツール・メンター: Rational Software Architect を使用したユース・ケースの詳細の作成」に概要を示した手順に従って作成された既存のユース・ケースの説明に対して追加します。システムの内部的な振る舞いに、外部の振る舞いとの類似性がほとんど見られない場合、別個の説明にしても構いません。この場合、コラボレーションに対して別個のユース・ケース仕様書 (テンプレートについては、「成果物: ユース・ケース」を参照) を添付します。あるいは、外部 (リンク) 文書を希望せず、説明を簡潔にできる場合は、コラボレーションのモデル文書内にこれを取り込みます。
「Linking External Files to Model Elements」を参照してください。
- 分析クラスを含めるパッケージに移動します。
「Rational Software Architect のためのモデル構造ガイドライン」を参照してください。
- 1 つ以上のクラス図を作成して、分析クラスを把握します。
「Adding Class Diagrams to Model Elements」を参照してください。
- 分析クラスを追加します。
「Adding Class Diagrams to Model Elements」を参照してください。
- 分析クラスのステレオタイプを適切に割り当てます。
「Applying Stereotypes」を参照してください。
- 各クラスに簡単な説明を追加します。
「Documenting Model Elements」を参照してください。
- オプションとして、それぞれのクラスに文書を関連付けます。
「Linking External Files to Model Elements」を参照してください。
詳細については、RSA オンライン・ヘルプのトピック 「Modeling Static Structure with Class Diagrams」を参照してください。
- 分析レベルのユース・ケース実現 (UML コラボレーション) を作成したパッケージまで移動します。
- ユース・ケースの名前付きの各ワークフロー (シナリオ) ごとに、
ユース・ケースの実現 (つまりコラボレーション) を選択し、それにシーケンス図を追加します。
この結果、UML 相互作用がコラボレーションに追加されます。
相互作用とシーケンス図の両方に、
ユース・ケース・モデル内のユース・ケース・フローに割り当てた名前と一致する名前を付けます。
- 相互作用のモデル文書内に、
このシーケンス図が表すシナリオの短い説明を入力します。
さらに、この説明をコピーしてシーケンス図そのもののモデル文書にも貼り付けます。
「Documenting Model Elements」を参照してください。
- (ユース・ケース・モデルの) アクターと分析クラスを図までドラッグ・アンド・ドロップし、相互作用のオブジェクトを作成します。
または、必要に応じ、相互作用の参加者として新しい分析クラスを作成します。
「Sequence Diagrams」を参照してください。
- オブジェクト間のメッセージを追加します。
セマンティクスの面から見れば、これらのメッセージは操作のインスタンスの仕様書なので、
これらのメッセージを既存の操作にマップするか、必要に応じて新しい操作を作成します。
「Sequence Diagrams」を参照してください。
- 各メッセージ (相互作用の要素) について、そのモデル文書フィールドで記述します。
「Documenting Model Elements」を参照してください。
- メッセージを受け取ったときのオブジェクトの振る舞いを記述するには、そのメッセージに操作を割り当てます。
(操作が存在しない場合は、以下の「責務の記述」で説明する方法に従って、クラスに操作を 1 つ追加してから、その操作をメッセージに割り当てます。)
各操作 (分析クラスの要素) について、そのモデル文書フィールドで記述します。
- 新しく作成した操作のシグニチャーを定義します。
詳細については、RSA オンライン・ヘルプの次のトピックを参照してください。
Modeling Static Structure with Class Diagrams
Sequence Diagrams
- 操作を追加することによってクラスの責務について記述します。
「Managing Attributes and Operations in Classifiers」を参照してください。
- 各操作に説明を追加します。
「Documenting Model Elements」を参照してください。
以下の手順を使用して、属性と関連を記述します。
各属性のモデル文書フィールドで、その属性に格納される情報について記述する必要があります。
属性に簡潔な記述名を付けることでその情報の性質が明白になるときは、これはオプションです。
各属性の多重度を指定します。
RSA オンライン・ヘルプのトピック 「Adding Attributes to Classifiers in Diagrams」を参照してください。
- 各ユース・ケースの実現まで移動し、クラス図を追加して、ユース・ケースの実現の参加者を示します。オプションで、これに「参加者」という名前を付けることができます。
「Adding Class Diagrams to Model Elements」を参照してください。
- 実現に参加するすべてのクラスを図に取り込みます。
以前に作成したシーケンス図の中の生存線を調べることによって、
これらのクラスを検出します。
- 図に置かれたクラスに関して、それらの間の既存の関連があれば、それらを表示します。
「Relationships」を参照してください。
- 必要に応じて、クラス間の新しい関連関係を追加します。
ユース・ケースの実現のシーケンス図を調べれば、
どのクラスとどのクラスが対話し、
それらの間でどのタイプがメッセージ・パラメーターとして受け渡されるのかが分かります。
この情報は、存在すべき関連を暗示し、
ときには「参加者」図に追加すべき他の (新規または既存の) クラスを暗示することもあります。
- 各関連の終了で多重度を指定します。
「Specifying Multiplicity of Association Ends」を参照してください。
- 各関連の終了で誘導可能性を指定します。
多重度が 1 より大きく、
指定したタイプのコンテナー・クラス内にソース・クラス・インスタンスのコレクションが維持されることを期待する場合は、属性のモデル文書フィールドか、「参加者」図の注釈にそのことを書き留めます。
「Specifying Navigability in Association Ends」を参照してください。
イベント依存関係を示すために、関連に名前を付けるかステレオタイプ化します。
「Relationships」と 「Applying Stereotypes」を参照してください。
分析クラスとその関連を検討します。不整合を識別、解決し、重複がある場合は削除します。
クラスが使用する分析メカニズムと関連する特性は、形式的な方法で把握する必要はありません。
図に添付された注釈やクラスの記述の延長 ( 「Documenting Model Elements」と 「Adding Notes to Shapes」を参照) で十分に情報は伝わります。
分析/設計モデル要素と他のモデルの間の追跡可能性依存関係を、プロジェクト・ガイドラインで指定されているとおりに追加します。
たとえば、分析クラスの追跡の対象になる独立したビジネス・モデル、概念的なデータ・モデル、ユーザー・インターフェース画面モデルなどがあります。そうするには、次のようにします。
- 追跡可能性のためのダイアグラムを作成します。
「Adding Diagrams to Models」を参照してください。
- ダイアグラムに追跡される要素をドラッグ・アンド・ドロップします。
「Adding
Shapes」を参照してください。
- 追跡可能性の依存関係を追加します (オプションでステレオタイプ化された抽象化依存関係<<trace>>)。
「Adding Abstraction Relationships」を参照してください。
- 追跡可能性レポートを生成します。
実装との追跡可能性関係 (暗黙的な関係を含む) があるモデル要素は、モデル・レポート・ビューに表示されます。
「Viewing Traceability Relationships」を参照してください。
モデルを HTML 形式にして発行すると便利です。さらに、RSA から Microsoft Word などのプログラムに図をコピーできるという点も押さえておいてください。
詳細については、 「Publishing Models for Review Outside the Modeling Tool」と以下のチュートリアルを参照してください。
-
Generating Standard Model Reports
-
Generating Custom Model Reports
-
Publishing Models to Web
チュートリアル:
Requirements: Create a Use-Case Diagram
Analysis: Create the Analysis Model
Analysis: Realize the Use Cases
Analysis: Create the Sequence Diagram
サンプル:
Annotated Use Case Diagram
Annotated Sequence Diagram
参考文献:
Performing Use-Case Analysis
|