Visual Studio では、モデルを使用して、システム、アプリケーション、またはコンポーネントの理解と変更に役立ちます。 モデルは、システムが動作する世界を視覚化し、ユーザーのニーズを明確にし、システムのアーキテクチャを定義し、コードを分析し、コードが要件を満たしていることを確認するのに役立ちます。
各種類のモデルをサポートする Visual Studio のバージョンについては、 アーキテクチャおよびモデリング ツールのバージョンのサポートに関するページを参照してください。
モデルは、いくつかの方法で役立ちます。
モデリング図を描画すると、要件、アーキテクチャ、および高度な設計に関連する概念を明確にするのに役立ちます。 詳細については、「 モデルのユーザー要件」を参照してください。
モデルを操作すると、要件の不整合を明らかにするのに役立ちます。
モデルと通信すると、重要な概念を自然言語よりもあいまいに伝えるのに役立ちます。 詳細については、「 アプリのアーキテクチャをモデル化する」を参照してください。
モデルを使用して、コードやデータベース スキーマやドキュメントなどの他の成果物を生成できます。 たとえば、Visual Studio のモデリング コンポーネントはモデルから生成されます。 詳細については、「 モデルからアプリを生成して構成する」を参照してください。
極端なアジャイルから高い式まで、さまざまなプロセスでモデルを使用できます。
モデルを使用してあいまいさを減らす
モデリング言語は自然言語ほどあいまいではなく、ソフトウェア開発時に通常必要なアイデアを表現するように設計されています。
プロジェクトにアジャイル プラクティスに従う小規模なチームがある場合は、モデルを使用してユーザー ストーリーを明確にすることができます。 顧客のニーズについて話し合う場合、モデルを作成すると、スパイクやプロトタイプ コードを記述するよりも、製品の広範な領域にわたって、はるかに迅速に有用な質問が生成される可能性があります。
プロジェクトが大規模で、世界中のさまざまな場所にチームが含まれている場合は、モデルを使用して、プレーンテキストで行うよりもはるかに効果的に要件とアーキテクチャを伝えることができます。
どちらの場合も、モデルを作成すると、ほとんどの場合、不整合とあいまいさが大幅に減少します。 システムが動作するビジネスの世界について、利害関係者によって理解が異なる場合が多く、開発者によってシステムのしくみに関する理解が異なることがあります。 通常、ディスカッションの焦点としてモデルを使用すると、これらの違いが明らかになります。 モデルを使用して不整合を減らす方法の詳細については、「 モデルのユーザー要件」を参照してください。
他のアーティファクトと共にモデルを使用する
モデルは、それ自体が要件の仕様やアーキテクチャではありません。 これらの要素の一部をより明確に表現するためのツールですが、ソフトウェア設計時に必要なすべての概念を表現できるわけではありません。 そのため、モデルは、OneNote ページや段落、Microsoft Office ドキュメント、Team Foundation の作業項目、プロジェクト ルームの壁の付箋など、他のコミュニケーション手段と共に使用する必要があります。 最後の項目とは別に、これらのオブジェクトの種類はすべて、モデルの要素部分にリンクできます。
通常、モデルと共に使用される仕様のその他の側面には、次のようなものがあります。 プロジェクトのスケールとスタイルによっては、次のいくつかの側面を使用するか、まったく使用しない場合があります。
ユーザー ストーリー。 ユーザー ストーリーは、プロジェクトのイテレーションのいずれかで提供されるシステムの動作の側面について、ユーザーやその他の利害関係者と話し合った簡単な説明です。 一般的なユーザー ストーリーは、「顧客は...」から始まります。ユーザー ストーリーでは、ユース ケースのグループが導入されたり、以前に開発されたユース ケースの拡張機能を定義したりできます。 ユース ケースを定義または拡張すると、ユーザー ストーリーがより明確になります。
変更要求。 より正式なプロジェクトでの変更要求は、アジャイル プロジェクトのユーザー ストーリーによく似ています。 アジャイル アプローチでは、すべての要件が、以前のイテレーションで開発されたものに対する変更として扱われます。
ユース ケースの説明。 ユース ケースは、ユーザーがシステムと対話して特定の目標を達成する 1 つの方法を表します。 完全な説明には、目標、イベントのメインシーケンスと代替シーケンス、および例外的な結果が含まれます。 ユース ケース図は、ユース ケースの概要を要約して提供するのに役立ちます。
シナリオ。 シナリオは、システム、ユーザー、およびその他のシステムが連携して利害関係者に価値を提供する方法を示す一連のイベントのかなり詳細な説明です。 ユーザー インターフェイスのスライド ショーまたはユーザー インターフェイスのプロトタイプの形式を取る場合があります。 1 つのユース ケースまたは一連のユース ケースについて説明できます。
用語集。 プロジェクトの要件用語集には、顧客が自分の世界について話し合う単語が記載されています。 ユーザー インターフェイスと要件モデルでも、これらの用語を使用する必要があります。 クラス図は、これらの用語の大部分間の関係を明確にするのに役立ちます。 図と用語集を作成すると、ユーザーと開発者の間の誤解が減るだけでなく、ほとんどの場合、異なるビジネス利害関係者間の誤解が生じます。
ビジネス ルール。 多くのビジネス ルールは、要件クラス モデルの関連付けと属性に対する不変制約として、およびシーケンス 図の制約として表現できます。
高度な設計。 主要な部分とその組み合わせについて説明します。 コンポーネント、シーケンス、インターフェイスの図は、高度な設計の主要な部分です。
デザインパターン システムのさまざまな部分で共有される設計規則について説明します。
テスト仕様。 テスト スクリプトとテスト コードの設計では、アクティビティ図とシーケンス図を適切に使用して、テスト ステップのシーケンスを記述できます。 システム テストは、要件が変更されたときに簡単に変更できるように、要件モデルの観点から表現する必要があります。
プロジェクト計画。 プロジェクト計画またはバックログは、各機能が配信されるタイミングを定義します。 実装または拡張するユース ケースとビジネス ルールを指定することで、各機能を定義できます。 プランでユース ケースとビジネス ルールを直接参照するか、別のドキュメントで一連の機能を定義し、プランで機能タイトルを使用することができます。
イテレーション計画でモデルを使用する
すべてのプロジェクトの規模と編成は異なりますが、一般的なプロジェクトは 2 ~ 6 週間の一連のイテレーションとして計画されています。 初期のイテレーションからのフィードバックを使用して、後のイテレーションのスコープと計画を調整できるように、十分なイテレーションを計画することが重要です。
反復的なプロジェクトでモデリングの利点を実現するのに役立つ次の提案が見つかる場合があります。
各イテレーションが近づくにつれてフォーカスをシャープにする
各イテレーションが近づくにつれて、モデルを使用して、イテレーションの最後に配信される内容を定義できます。
初期のイテレーションですべてを詳細にモデル化しないでください。 最初のイテレーションでは、ユーザー用語集のメイン項目のクラス ダイアグラムを作成し、主要なユース ケースの図を描画し、主要なコンポーネントの図を描画します。 詳細はプロジェクトの後半で変更されるため、これらの詳細は記述しないでください。 このモデルで定義されている用語を使用して、特徴または主要なユーザー ストーリーの一覧を作成します。 イテレーションに特徴を割り当てて、プロジェクト全体で推定ワークロードのバランスを取るようにします。 これらの割り当ては、プロジェクトの後半で変更されます。
初期のイテレーションで、最も重要なすべてのユース ケースの簡略化されたバージョンを実装してみてください。 これらのユース ケースは、後のイテレーションで拡張します。 このアプローチは、要件の欠陥を発見するリスクや、プロジェクトのアーキテクチャが遅すぎて何もできないリスクを軽減するのに役立ちます。
各イテレーションの終わりに近づいて、要件ワークショップを開催して、次のイテレーションで開発される要件またはユーザー ストーリーを詳細に定義します。 優先度を決定できるユーザーとビジネス利害関係者、および開発者やシステム テスターを招待します。 3 時間で 2 週間のイテレーションの要件を定義できます。
ワークショップの目的は、誰もが次のイテレーションの終わりまでに何を達成するかに同意することです。 要件を明確にするのに役立つツールの 1 つとしてモデルを使用します。 ワークショップの出力はイテレーション バックログです。つまり、Team Foundation の開発タスクと Microsoft Test Manager のテスト スイートの一覧です。
要件ワークショップでは、開発タスクの見積もりを決定する必要がある場合にのみ、設計について説明します。 それ以外の場合は、ユーザーが直接経験できるシステム動作について説明します。 要件モデルはアーキテクチャ モデルとは別に保持します。
通常、非技術関係者は、UML 図を理解するのに問題はありません。ガイダンスもあります。
モデルを作業項目にリンクする
要件ワークショップの後、要件モデルの詳細を詳しく説明し、モデルを開発タスクにリンクします。 これを行うには、Team Foundation の作業項目をモデル内の要素にリンクします。
任意の要素を作業項目にリンクできますが、最も便利な要素は次のとおりです。
- ビジネス ルールまたはサービスの品質要件を説明するコメント。 詳細については、「 モデルのユーザー要件」を参照してください。
モデルをテストにリンクする
要件モデルを使用して、受け入れテストの設計をガイドします。 開発作業と同時にこれらのテストを作成します。
この手法の詳細については、「 モデルからのテストの開発」を参照してください。
残存作業時間の見積もり
要件モデルは、各イテレーションのサイズに関連してプロジェクトの合計サイズを見積もるのに役立ちます。 ユース ケースとクラスの数と複雑さを評価すると、必要な開発作業を見積もるのに役立ちます。 最初のいくつかのイテレーションを完了すると、対象となる要件とまだカバーする要件の比較によって、プロジェクトの残りの部分のコストとスコープのおおよその測定値が得られます。
各イテレーションの終わり近くで、将来のイテレーションに対する要件の割り当てを確認します。 各イテレーションの最後にあるソフトウェアの状態をユース ケース図のサブシステムとして表すのが役立ちます。 ディスカッションでは、ユース ケースとユース ケース拡張機能をこれらのサブシステムの 1 つから別のサブシステムに移動できます。
抽象化のレベル
モデルには、ソフトウェアに関連するさまざまな抽象化があります。 最も具体的なモデルはプログラム コードを直接表し、最も抽象的なモデルは、コードで表される可能性がある、または表されない可能性があるビジネス概念を表します。
モデルは、複数の種類の図で表示できます。 モデルと図の詳細については、「 アプリのモデルを作成する」を参照してください。
さまざまな種類の図は、さまざまな抽象化レベルで設計を記述するのに役立ちます。 ダイアグラムの種類の多くは、複数のレベルで役立ちます。 次の表に、各種類の図を使用する方法を示します。
| デザイン レベル | ダイアグラムの種類 |
|---|---|
| ビジネス プロセス システムが使用されるコンテキストを理解することは、ユーザーがシステムに何を必要とするかを理解するのに役立ちます。 |
- 概念クラス図では、ビジネス プロセス内で使用されるビジネスの概念について説明します。 |
| ユーザー要件 ユーザーがシステムから必要とする内容の定義。 |
- ビジネス ルールとサービス品質の要件は、個別のドキュメントで記述できます。 |
| 高度な設計 システムの全体的な構造: 主要なコンポーネントとそれらがどのように結合されるか。 |
- 依存関係図は、システムが相互に依存する部分にどのように構造化されているかを記述します。 依存関係図に対してプログラム コードを検証して、アーキテクチャに準拠していることを確認できます。 |
| コード分析 ダイアグラムはコードから生成できます。 |
- 依存関係図は、クラス間の依存関係を示しています。 更新されたコードは、依存関係図に対して検証できます。 - クラス 図は、コード内のクラスを示します。 |
外部リソース
関連コンテンツ
注
テキスト テンプレート変換コンポーネントは、Visual Studio 拡張機能開発ワークロードの一部として自動的にインストールされます。 SDK、ライブラリ、フレームワーク カテゴリの下にある Visual Studio インストーラーの [個々のコンポーネント] タブからインストールすることもできます。 [個々のコンポーネント] タブから Modeling SDK コンポーネントをインストールします。