開発プロセス内でのモデルの使用
Visual Studio Ultimate では、モデルを使用することで、システム、アプリケーション、またはコンポーネントを容易に把握し、変更することができます。 モデルは、システムが動作する環境の視覚化、ユーザーのニーズの明確化、システムのアーキテクチャの定義、コードの分析、およびコードが要件を満たしていることの確認を行うときに便利です。
ビデオによる紹介については、「Video: UML with Visual Studio 2010 (ビデオ: Visual Studio 2010 で UML を使用する)」を参照してください。
モデルの使用方法
モデルの利用方法にはいくつかあります。
モデリング図を描画することで、要求、アーキテクチャ、および大まかな設計に関連する概念を明確化できます。 詳細については、「ユーザー要求のモデリング」を参照してください。
モデルを使用することにより、要求の不整合を見つけることができます。
モデルを使用して意志を伝えることで、自然言語よりも明確に重要な概念を伝達できます。 詳細については、「ソフトウェア システムのアーキテクチャのモデリング」を参照してください。
場合によっては、コードまたはその他の成果物 (データベース スキーマやドキュメントなど) を生成するためにモデルを使用できます。 たとえば、Visual Studio Ultimate のモデリング コンポーネントはモデルから生成されます。 詳細については、「モデルからのアプリケーションの生成および構成」を参照してください。
エクストリーム アジャイルからハイ セレモニーまで、さまざまなプロセスでモデルを使用できます。
モデルの使用によるあいまいさの低減
モデリング言語は、自然言語よりも明瞭であり、ソフトウェア開発で一般的に必要とされる概念を表現することを目的として設計されています。
プロジェクトのチームが小規模であり、アジャイル手法を適用する場合は、モデルを使用してユーザー ストーリーを明確にすることができます。 モデルを生成しておくことで、顧客と顧客のニーズについて話し合うときに、スパイクやプロトタイプ コードを生成するより迅速、効果的に、より広い領域にわたる製品に関する質問をすることができます。
チームが世界各地に分散している大規模なプロジェクトの場合、プレーンテキストを使うよりもモデルを使用した方が、要求とアーキテクチャを効率的に伝えることができます。
どちらにしても、ほとんどの場合、モデルを生成することで不整合とあいまいさが大幅に低減されます。 システムが使用されるビジネス環境に関して利害関係者の間で理解が異なることや、システムがどのように動作するかについて開発者の間で理解が異なることはよくあります。 通常、話し合いにおいてモデルを使用すると、このような相違が明確に示されます。 モデルを使用して不整合を低減する方法の詳細については、「ユーザー要求のモデリング」を参照してください。
モデルと他の成果物の併用
モデルは、それ自身が要求の仕様またはアーキテクチャを示すものではありません。 モデルは、これらの特性をより明確に表現するためのツールですが、ソフトウェアの設計時に必要となるすべての概念を表すことはできません。 したがって、モデルは、OneNote のページまたは段落、Microsoft Office ドキュメント、Team Foundation の作業項目、プロジェクト ルームの壁に貼られたメモなどの他の伝達手法と共に使用する必要があります。 最後の例は別として、このようなオブジェクトはすべてモデルの要素パートにリンクできます。
一般的にモデルと組み合わせて使用される仕様の特性としては、これ以外に、次のようなものがあります。 プロジェクトの規模とスタイルによっては、これらを複数使用できる場合もあれば、まったく使用できない場合もあります。
ユーザー ストーリー。 ユーザー ストーリーとは、プロジェクトのイテレーションのいずれかで実現されるシステムの振る舞いの特性に関する短い説明であり、ユーザーなどの利害関係者によって話し合われます。 典型的なユーザー ストーリーは、"顧客は～ができる" で始まります。 ユーザー ストーリーは、一連のユース ケースを紹介するものであったり、以前に開発したユース ケースの拡張を定義するものであったりします。 ユース ケースの定義または拡張を行うことにより、ユーザー ストーリーがさらに明確になります。
変更要求。 より正式なプロジェクトにおける変更要求は、アジャイル プロジェクトのユーザー ストーリーとよく似ています。 アジャイル手法では、すべての要求が前のイテレーションで開発された内容への変更として扱われます。
ユース ケースの説明。 ユース ケースは、特定の目的を達成するためにユーザーがシステムを操作する方法を表します。 完全な説明には、目的、イベントの主要シーケンスと代替シーケンス、および例外的な出力が含まれます。 ユース ケースの概要を要約して伝えるためにユース ケース図を使用できます。
シナリオ。 シナリオは、イベントのシーケンスを詳しく説明するものであり、システム、ユーザー、およびその他のシステムがどのように連携して利害関係者に価値を提供するかを示します。 ユーザー インターフェイスまたはユーザー インターフェイス プロトタイプのスライド ショーという形式になる場合があります。 1 つのユース ケースまたはユース ケースのシーケンスを説明できます。
用語集。 プロジェクトの要求に関する用語集は、顧客が自分の環境を説明するときに使用する用語の解説を提供します。 ユーザー インターフェイスおよび要求のモデルでも、このような用語を使用する必要があります。 クラス図を使用することで、このような用語のほとんどの相互関係を明確化できます。 図と用語集を生成することで、ユーザーと開発者の間の誤解が減るだけでなく、さまざまなビジネス上の利害関係者の間の誤解を常に把握することができます。
ビジネス ルール。 ビジネス ルールの多くは、要求クラス モデルの関連付けと属性に関する不変の制約、およびシーケンス図に関する制約として表現できます。
大まかな設計。 主要なパートの説明と、それを組み合わせる方法を示します。 大まかな設計の主要パートは、コンポーネント図、シーケンス図、およびインターフェイス図です。
デザイン パターン。 システムのさまざまな部分で共通する設計のルールを示します。
テストの仕様。 テスト スクリプトおよびテスト コード設計では、アクティビティ図とシーケンス図を活用して、テスト ステップのシーケンスを記述できます。 システム テストは、要求が変更された場合に簡単に変更できるように、要求モデルの観点から表現する必要があります。
プロジェクト計画。 プロジェクト計画またはバックログで、それぞれの特性が実現される時期が定義されます。 特性は、その特性によって実装または拡張されるユース ケースおよびビジネス ルールを記述することで定義できます。 ユース ケースとビジネス ルールを計画で直接参照することも、別のドキュメントで特性のセットを定義してから計画で特性のタイトルを使用することもできます。
イテレーション計画でのモデルの使用
プロジェクトはそれぞれ規模と組織が異なりますが、一般的なプロジェクトは、2 週間～ 6 週間のイテレーションの連続として計画されます。 重要な点は、初期のイテレーションからのフィードバックに基づいて後期のイテレーションのスコープと計画を調整できるように、十分なイテレーションを計画することです。
反復プロジェクトでモデリングの利点を活かすには、次の提案を参考にすることをお勧めします。
イテレーションが近づくたびに重点を絞り込む
イテレーションが近づくたびに、モデルを使用して、そのイテレーションの終了時に実現される結果を定義します。
初期のイテレーションですべてを詳細にモデル化しないでください。 最初のイテレーションでは、ユーザー用語集の主要な項目のクラス図の生成、主要なユース ケースの図の描画、および主要なコンポーネントの図の描画を行います。 詳細はプロジェクトの後期で変更されるため、これらをあまり詳細に説明しないでください。 このモデルで定義されている用語を使用して、特性または主要なユーザー ストーリーの一覧を生成します。 推定されるプロジェクト全体の作業負荷が大まかに分散されるように、特性をイテレーションに割り当てます。 これらの割り当ては、プロジェクトの後期で変更されます。
初期のイテレーションでは、すべての最も重要なユース ケースの簡略版を実装するようにしてください。 これらのユース ケースは後期のイテレーションで拡張します。 この手法によって、プロジェクトの要求またはアーキテクチャの欠陥の発見が遅れて対処できなくなる危険性を低減できます。
イテレーションの終了が近づいてきたら、要求のワークショップを開き、次のイテレーションで開発する要求またはユーザー ストーリーを詳細に定義します。 優先度を決定できるユーザーおよびビジネス上の利害関係者だけでなく、開発者およびシステム テスト担当者も招待します。 2 週間のイテレーションに対する要求を定義するためには約 3 時間かかります。
ワークショップの目的は、次のイテレーションの終了までに達成する目標について全員が同意することです。 要求を明確化するためのツールの 1 つとしてモデルを使用します。 ワークショップの結果として、イテレーション バックログが作成されます。これは、Team Foundation の開発タスクと Microsoft テスト マネージャー のテスト スイートの一覧です。
要求のワークショップでは、開発タスクの見積りを決定するために必要な範囲でのみ、設計について話し合います。 それ以外では、議題をユーザーが直接体験する可能性のあるシステムの振る舞いに限定します。 要求モデルとアーキテクチャ モデルは切り離して議論します。
技術的な知識のない利害関係者であっても、通常はある程度の説明をすることで、UML 図を理解できるようになります。
モデルを作業項目にリンクする
要求のワークショップの後で、要求モデルの詳細を明確にし、モデルを開発タスクにリンクします。 これを行うには、Team Foundation で作業項目をモデルの要素にリンクします。 これを行う方法については、「方法: 作業項目をモデル要素にリンクする」を参照してください。
任意の要素を作業項目にリンクできますが、最も有用な要素は次のとおりです。
ユース ケース。 ユース ケースは、ユース ケースを実装する開発タスクにリンクできます。
ユース ケース拡張。 ユース ケースの 1 つの特性のみをイテレーションに実装する場合は、それを分離して 1 つ以上の拡張と共に基本ユース ケースにすることができます。 拡張は、<<extend>> 関係を持つ基本ケースにリンクされたユース ケースです。 ユース ケース拡張の詳細については、「UML ユース ケース図: リファレンス」を参照してください。
ビジネス ルールまたはサービス品質要求を記述するコメント 詳細については、「ユーザー要求のモデリング」を参照してください。
モデルをテストにリンクする
要求モデルに基づいて承認テストを設計します。 これらのテストを開発作業と同時進行で生成します。
この手法の詳細については、「モデルからのテストの作成」を参照してください。
残存作業を見積もる
要求モデルを使用して、それぞれのイテレーションのサイズからプロジェクトの合計サイズを見積もることができます。 ユース ケースとクラスの数および複雑さから推定して、今後必要な開発作業を見積もることができます。 最初のいくつかのイテレーションが完了したら、対応済みの要求と未対応の要求を比較することで、プロジェクトの残存作業のコストとスコープの概算値がわかります。
イテレーションの終了が近づくたびに、後続のイテレーションに対する要求の割り当てを見直します。 イテレーションが終了したときのソフトウェアの状態をユース ケース図の中のサブシステムとして表すと役立つ場合があります。 話し合いにおいて、このようなサブシステム間でユース ケースおよびユース ケース拡張を移動することができます。
抽象化のレベル
モデルのソフトウェアとの関係における抽象化のレベルにはさまざまあります。 最も具体的なモデルは、プログラム コードを直接表現します。最も抽象的なモデルは、コードで表されない場合もあるビジネス概念を表現します。
モデルは、いくつかの種類の図で表示できます。 モデルと図の詳細については、「ソフトウェア設計のためのモデルの開発」を参照してください。
複数の異なる種類の図を使用すると、設計をさまざまな抽象化のレベルで効果的に説明できます。 多くの種類の図が、複数のレベルにおいて効果的です。 次の表に、それぞれの図の種類をどのように使用できるかを示します。
設計レベル |
図の種類 |
|---|---|
ビジネス プロセス システムが使用されるコンテキストを理解することは、ユーザーのニーズの理解に役立ちます。 |
|
ユーザー要求 システムに対するユーザーの要求の定義。 |
|
大まかな設計 システムの全体的な構造 (主要なコンポーネントとその組み合わせ方法)。 |
|
デザイン パターン 設計のすべての部分で使用される、設計上の問題を解決する規則と方法。 |
|
コード分析 複数の種類の図をコードから生成できます。 |
|
外部リソース
カテゴリ |
リンク |
|---|---|
ビデオ |
|
フォーラム |
|
ブログ |
|
技術文書およびジャーナル |
|
その他のサイト |
.gif "ビデオへのリンク")