作業:
|
目的
|
|
役割 設計者 | |
頻度: 現在の反復の開発対象となっている一連のユース・ケースまたはユース・ケース・シナリオごとに 1 回。 | |
手順
現在の反復の各ユース・ケースに対して以下の作業を行います。 以下の作業は、反復ごとに 1 回行います。 メモ: これらのステップは論理的な順序で示してあります。ただし、ステップを入れ替えたり、いくつかのステップを並行に実行する必要がある可能性もあります。 |
|
入力とする成果物: | 結果となる成果物: |
ツール・メンター: | |
詳細情報: |
ワークフローの詳細: |
目的 | ユース・ケースの振る舞いを表現するためのモデリング要素を作成する。 |
初期の分析設計作業のほとんどでは、ユース・ケースに焦点をあてます。 要件中心の作業から分析/設計中心の作業への移行にあたっては、成果物: ユース・ケースの実現が橋渡しとなり、設計モデルの振る舞いをユース・ケース・モデルに戻って追跡するための手段となります。また、設計モデルのコラボレーションをユース・ケースの概念に沿って整理できます。
存在しない場合には、ユース・ケースに、分析モデルでユース・ケースの実現を作成します。 ユース・ケースの実現の名前は、関連するユース・ケースと同じものにし、ユース・ケースの実現から関連するユース・ケースに「実現」関係を確立します。
ユース・ケースの実現について詳しくは、「ガイドライン: ユース・ケースの実現」を参照してください。
目的 | システムの顧客向けに書かれたユース・ケース記述から抜けている可能性のある、システムに必要な内部動作を理解するのに必要な追加情報を把握する。 |
各ユース・ケースの記述は、分析クラスとそのオブジェクトを見つけるのに必ずしも十分ではありません。顧客は一般的にシステムの内部で起きていることには無関心なので、ユース・ケース記述でもこういった情報は省かれることがあります。このような場合には、ユース・ケース記述は「ブラックボックス」の記述のようになり、アクターのアクションに対してシステムが何をするかの内部詳細は省略されるか、非常に簡単に記述されます。ユース・ケースを実行するオブジェクトを探すには、システムが何をするかを内部の視点から記述した「ホワイトボックス」の記述が必要です。
例
現金自動預け払い機 (ATM) の場合、システムの顧客は次のように記述したい場合があります。
「ATM が顧客のキャッシュ・カードを検証します。」
システムによるユーザー認証の振る舞いを記述します。 顧客にとってはこれで十分かもしれませんが、カードを検証するために ATM 内部で実際に生じている事柄についてはよく分かりません。
オブジェクトを確認するのに十分な詳細レベルで、システムの処理に関するイメージを理解するにはさらに詳細な情報が必要になります。ATM カードの検証作業を例に取ると、次のような詳細な説明にできるかもしれません。
「ATM により、ATM ネットワークに顧客の口座番号とパスワード情報が送られ、検証が行われます。顧客番号とパスワード情報が一致し、顧客がトランザクションを行うための認証が完了すると、ATM ネットワークにより成功が、それ以外の場合は失敗が戻されます。」
この程度の詳細があれば、どのような情報 (口座番号とパスワード情報) が必要で、何が認証を担当するか (ユース・ケース・モデルのアクターである ATM ネットワーク) が明確になります。この情報から、2 つのオブジェクトの候補 (口座番号とパスワード情報の属性を持つ顧客オブジェクトおよび ATM ネットワーク・インターフェース) と、これらのオブジェクトの責務が明確になります。
ユース・ケース記述を調べ、システムの内部的振る舞いが明確に定義されているかどうかを確認します。システムの内部的振る舞いはあいまいでなく、システムが実行すべきことがはっきりしていなければなりません。 システム (オブジェクト) 内部にある、この振る舞いを担当する要素まで定義する必要はなく、何をする必要があるかの明確な定義だけでかまいません。
この詳細情報の情報源としては、システムが何をすべきかの定義を手助けしてくれる問題領域の専門家がいます。システムの特定の振る舞いを検討するときには、「これを行うことは、システムにとってどういう意味をもつか」という質問を尋ねるようにします。この質問に答えられるほどシステムの動きが定義されていない場合は、おそらく明確にするべき情報がまだまだたくさんあります。
イベント・フローの記述を補足するには、次のような方法もあります。
目的 | ユース・ケースに記述されている振る舞いを実行する、モデル要素 (分析クラス) の候補セットを識別する。 |
分析クラスの候補セットを探すことは、単なる必要な振る舞いの宣言から、システムがどのように動作するかの記述への、最初のステップとなります。この作業では、分析クラスを使用してモデル要素のロールを表します。このロールは、ユース・ケースで指定される機能要求と、補足要求で指定する機能外要求を満足するのに必要な振る舞いを示します。プロジェクトの焦点が設計へと移っていくと、これらのロールは、ユース・ケースを実現する一連の設計要素へと展開していきます。
ユース・ケース分析で明確にしたロールは、システムの最上位層の振る舞い (アプリケーション特有の振る舞いと、ドメイン特有の振る舞い) を主に表現しています。バウンダリー・クラスとコントロール・クラスは一般的にアプリケーション層の設計要素へと展開し、エンティティー・クラスはドメイン固有の設計要素へと展開します。下層レイヤーの設計要素は、ここで明確にした分析クラスによって使用される、分析メカニズムから展開するのが普通です。
ここで説明するテクニックは、システムを異なる 3 つの視点から検討して、クラスの候補を明確にしていきます。この 3 つの視点とは、システムとアクターの境界、システムが使用する情報、およびシステムの制御論理です。対応するクラスのステレオタイプ、境界、エンティティー、コントロールは、分析中に便宜上使われるもので、設計段階では使用されません。
クラスの識別とは、クラスを識別し、名前を付け、数行で簡単に記述することを指します。
分析クラスの識別について詳しくは、ガイドライン: 分析クラス」を参照してください。ユース・ケースの実現について詳しくは、「ガイドライン: ユース・ケースの実現」を参照してください。
特定の分析メカニズムまたは分析パターン (あるいはその両方) がプロジェクト固有のガイドラインに記述されている場合は、それも分析クラスを特定するための「手掛かり」として使用します。
目的 | 分析クラスのコラボレーションの観点から、ユース・ケースの振る舞いを表現する。分析クラスの責務分担を決定する。 |
独立した各サブフロー図 (シナリオ) について、以下の作業を行います。
ユース・ケースのコミュニケーション図 預け入れ品目の検収。
特定の分析メカニズムまたは分析パターン (あるいはその両方) がプロジェクト固有のガイドラインに記述されている場合は、それも責務の割り当てとその結果の相互作用図に反映させる必要があります。
目的 | ユース・ケースの振る舞いから明確にしたオブジェクト・クラスの責務分担を記述する。 |
責務とは、オブジェクトに提供依頼が可能なものをいいます。責務は設計において、クラスの 1 つ (通常は複数) の操作に展開します。この責務には次の特徴があります。
各分析クラスは、いくつかの責務を負うようにします。1 つしか責務を持たないクラスは単純すぎます。一方、十数個にものぼる責務を持つクラスは合理性に欠けるので、複数のクラスに分割することを検討します。
すべてのオブジェクトを作成、削除できるのは自明なことなので、作成時や削除時にオブジェクトが特別な振る舞いをするのでない限り、改めて記述する必要はありません (ある種の関係が存在する場合、削除できないオブジェクトもあります)。
責務は相互作用図のメッセージから抽出します。メッセージごとに送信先のオブジェクトのクラスを調べます。責務が存在しない場合は、要求されている振る舞いを提供する新しい責務を作成します。
責務によっては機能外要求から得られるものもあります。新しい責務を作成する際には、関連する機能外要求がないかをチェックします。これを反映して、既存の責務の記述に追加を行うか、新しい責務を作成します。
責務は、責務を表す短い (最大で数語) 名前と、最大で数行の簡単な説明を付けて文書化します。この説明では、責務を遂行するためにオブジェクトが何をするか、責務が呼び出されるとどんな結果が返されるかを記述します。
目的 | 分析クラスが依存するほかのクラスを定義する。 クラスが認識する必要のあるほかの分析クラスのイベントを定義する。 分析クラスが維持する責務のある情報を定義する。 |
多くの場合、クラスが責務を果たすのにあたって、クラスは必要な振る舞いを提供する別のクラスに依存しています。関連は、クラス間の関係を文書化したもので、クラス結合の理解に役立ちます。クラス結合を理解し、可能な場合に結合を削減することによって、より優れた柔軟なシステムを作ることができます。
以下のステップでは、クラスの属性とクラス間の関連を定義します。
属性は、クラスごとに情報を格納するのに使用します。特に、次のような場合に属性が使用されます。
一方、情報の振る舞いが複雑な場合、2 つ以上のオブジェクトで共有される場合、または 2 つ以上のオブジェクト間で「参照による」受け渡しが行われる場合、情報は別のクラスとしてモデル化します。
属性名は、属性が保持する情報を明確に示す名詞にします。
属性の記述には、属性にどのような情報が格納されるかを記述します。属性名が格納する情報を明白に示している場合は、属性の記述はオプションとなります。
属性タイプは属性の単純データ型です。例としては、文字列、整数、数値などがあります。
分析クラスへの振る舞いの割り当てで作成した、相互作用図のリンクの検討から作業を開始します。クラス間のリンクは、ユース・ケースを実行するのに、2 つのクラスのオブジェクトが通信する必要があることを示しています。システムの設計では、これらのリンクはいくつかの方法で実現できます。
ただし、クラスの「一生」のこの初期段階では、これらの決定を下すには早すぎます。適切な決定を下すのに十分な情報がまだ得られていません。このため、分析では、2 つのクラスのオブジェクト間で送信する必要があるメッセージを表す (および「運ぶ」) ための関連と集約を作成します。(集約は関連の特殊な形で、オブジェクトが「全体/部分」の関係に関わることを示します。「ガイドライン: 関連」および「ガイドライン: 集約」を参照してください。)
これらの関連と集約は作業: クラス設計で見直します。
クラスごとに、ほかのクラスとの関連を示すクラス図を作成します。
オーダー・エントリー・システムの一部を示す分析クラス図の例
ユース・ケースの実現に必要な関連のみに焦点を当てます。相互作用図に基づいて必要な関連以外は、必要な可能性がある場合でも追加しないでください。
関連にロール名と多重度を与えます。
関連の簡単な説明を書いて、どのように関連を使用するか、または関連がどのような関係を表しているかを示します。
オブジェクトは、場合によって「対象」オブジェクトでイベントが発生したことを知る必要がありますが、「対象」オブジェクトではイベント発生の通知が必要なオブジェクトすべてを知る必要はありません。このイベント通知の依存性を示す簡略な方法として、通知予約関係を使用できます。
2 つのオブジェクト間に通知予約関係がある場合、予約される側のオブジェクトで特定のイベントが発生した時、予約する側のオブジェクトに通知が行われます。通知予約関係では条件を使用して、予約する側のオブジェクトに通知が行われます。 詳しくは、「ガイドライン: 通知予約関係」を参照してください。
通知予約関係の条件は、特定の属性または操作の観点からではなく、抽象的な特性の観点から表現されます。そうすることによって、変更される可能性のある関係元のエンティティー・オブジェクトの内容に関係先のオブジェクトは依存しないで済みます。
通知予約関係は次の場合に必要です。
「予約先」のオブジェクトは、通常エンティティー・オブジェクトです。エンティティー・オブジェクトは一般的に情報を受動的に格納し、すべての振る舞いはこの情報格納責務に関係付けられています。ほかの多くのオブジェクトでは、エンティティー・オブジェクトの変更を知る必要があります。通知予約関係を使用すると、エンティティー・オブジェクトがこれらのほかのオブジェクトすべてについて知る必要はなくなります。つまり、エンティティー・オブジェクトに興味があることを「登録」することで、エンティティー・オブジェクトが変更された場合に通知が送られるようになります。
この時点では、これは「分析のための策略」に過ぎません。設計作業では、この通知が実際にどのように機能するかを定義する必要があります。通知フレームワークを購入するか、独自に設計および開発する必要があるかもしれません。しかし、この段階では、通知メカニズムが存在していることが分かっているだけで十分です。
2 つのオブジェクトの間の関係は予約する側のオブジェクトからのみ認識される一方通行になっています。予約の内容はすべて予約する側のオブジェクト側に持たれています。他方、関係元のエンティティー・オブジェクトは通常どおりに定義され、ほかのオブジェクトがエンティティー・ オブジェクト内の作業に関連があるかどうかは考慮されません。このことは、予約先のオブジェクトを変更することなく、予約する側のオブジェクトをモデルに追加またはモデルから削除できることを暗示しています。
目的 | 個々のユース・ケースの実現を調整して、一貫した関係を持つ一連の分析クラスを特定する。 |
ユース・ケースの実現は、特定のユース・ケースを分析した結果として作成されたものです。 こうした個々のユース・ケースの実現を、この段階で調整する必要があります。 検討対象となるのは、それぞれのユース・ケースの実現で定義されている分析クラスとそれをサポートする関連です。 それらの間の不整合を見つけて解決し、重複があれば取り除きます。 たとえば、概念的に同じなのに、別の設計者によって特定されたために別の名前が付けられている分析クラスが、異なる 2 つのユース・ケースの実現に含まれている場合があります。
注: ソフトウェア・アーキテクトが初期アーキテクチャーの定義を適切に行うと、ユース・ケースの実現の間の重複を大幅に減らすことができます (「作業: アーキテクチャー分析」を参照してください)。
モデル要素を調整する際には、それらの関係を考慮に入れることが重要です。2 つのクラスをマージしたり、あるクラスを別のクラスで置き換えたりする場合は、必ず元のクラスの関係を新しいクラスに反映させてください。
ユース・ケースの実現の調整には、ソフトウェア・アーキテクトが参加する必要があります。これは、問題領域と解決領域を最もよく表す分析クラスを選択するためには、ビジネス状況の理解や、ソフトウェアのアーキテクチャーと設計を見通す力が要求されるためです。
クラスについて詳しくは、「ガイドライン: 分析クラス」を参照してください。
目的 | 分析クラスが使用する分析メカニズム (該当する場合) を識別する。分析クラスがどのように分析メカニズムを適用するかについて追加情報を提供する。 |
このステップでは、特定した各分析クラスに適用できる分析メカニズムについて検討します。
分析クラスで 1 つ以上の分析メカニズムが使用される場合、ソフトウェア・アーキテクトと設計者はアーキテクチャー設計メカニズムに必要な機能を決定するために、ここで把握した追加情報を役立てることができます。分析クラスのインスタンスの数、サイズ、アクセス頻度、予想寿命はいずれも重要なプロパティーで、設計者が適切なメカニズムを選択する際に役立ちます。
分析クラスで使用する各分析メカニズムに対し、適当な設計メカニズムと実装メカニズムの選択にあたって考慮しなければならない適切な特性を限定します。これはメカニズムのタイプによって異なります。適切な場合または不確定要素が多い場合は、範囲を指定します。アーキテクチャーのメカニズムが異なれば特性も異なるため、この情報は純粋に記述的で、情報の把握と伝達に必要なだけの構造化が済んでいるものであればかまいません。分析中は、この情報は一般的に推測によるものですが、情報が明らかになるにつれて推測は修正できるので、概要を把握するだけで価値があります。
クラスと、クラスに関連する特性で使用する分析メカニズムは、正式な方法で把握する必要はありません。ダイアグラムに注を付けたり、クラスの記述に追加するだけで情報を伝達するには十分です。クラスの発展過程である、この現時点での特性情報は、きわめて流動的かつ推論的です。このため、メカニズムの定義を正式にするよりも、予想値の把握に重点を置きます。
例
フライト・クラスが使用する永続性メカニズムの特性は次のように定められます。
詳細度: 1 フライト当たり 2 ~ 24 KB
ボリューム: 最高 100,000
アクセス頻度:
- 作成と削除: 1 時間当たり 100 回
- 更新: 1 時間当たり 3,000 回
- 読み込み: 1 時間当たり 9,000 回
例
ミッション・クラスで使用する永続性メカニズムでは、次のような限定を行うことができます。
詳細度: 1 ミッション当たり 2 ~ 3 MB
ボリューム: 4
アクセス頻度:
- 作成と削除: 1 日当たり 1 回
- 更新: 1 日当たり 10 回
- 読み込み: 1 時間当たり 100 回
目的 | 分析モデルとその他のモデルとの間の追跡可能性関係を保守する。 |
プロジェクトのプロジェクト固有のガイドラインには、分析モデル要素に要求される追跡可能性が明記されています。
たとえば、ユーザー・インターフェースの独立したモデルがある場合に、そのモデル内の画面やその他のユーザー・インターフェース要素を分析モデル内のバウンダリー・クラスまで追跡できると便利です。
目的 | 分析対象オブジェクトが、システムへの機能要求を満たすことを検証する。 分析オブジェクトと相互作用が一貫していることを検証する。 |
検討会議の最後に、同期ポイントとして、また作業: ユース・ケース分析の締めくくりとして、非公式なレビューを実施します。
チェックポイントをこの作業の結果となる成果物として使用します。
Rational Unified Process
|