目的

このツール・メンターでは、プロジェクトのための RSA モデリング環境をセットアップする方法を説明します。

ここでは、このツール・メンターに関連する追加情報へのリンクを示します。

概要

プロジェクトのための RSA をセットアップするということは、 チーム・メンバーが同時に同じモデルに従事できるようにするための基礎を据えることを意味します。 複雑なシステムの開発には、分析者、アーキテクト、開発者のグループが、それぞれの担当する作業に従事しながら、同時に「総括的展望」を参照し、アクセスできる能力が備わっている必要があります。複数のチーム・メンバーがさまざまな方法で同じモデルにアクセスできる環境を正常に管理するには、次のような作業が必要です。

  • チームの作業を管理する作業戦略の定型化
  • その戦略をサポートできるツールの保有

以下のガイダンスでは、次の用語を使用しています。

プロジェクト は、Eclipse ワークスペースに認識され、開発作業の作業生産物である Eclipse リソース (さまざまな種類の成果物) を保管するために使用されるファイル・システム・ロケーションを指します。

概念モデル は、 ユース・ケース、分析クラス、および設計コンポーネントなどの抽象的な概念を表すモデルです。 これらは、実装コードに固く結合されてはいません。 これらは、.emx という拡張子のファイルに保管されます。 これらは、実装コードそのものと .dnx という拡張子のファイルに保管されたコード図で構成される実装モデル とは異なります。 (実装モデルは、コードとコード図を含むプロジェクトに相当すると考えることができます。)

次に、こうした基礎作りのための基本的な手順を示します。

概念モデリングの役割とモデリング作業分担の確立 ページの先頭へ

基礎作りの一つは、開発作業での概念モデルの使用法を決定することです。 開発を主導するものとするか、あるいは (たとえば、文書の形式で) もっと遡及的に使用するかを決定します。

モデルで開発を主導する場合は、以下の事柄を決定します。

  • どのタイプのモデル (ユース・ケース、分析、企業 IT 設計など) を使用するか
  • 概念モデリング・チームの構成 (サイズおよびスキル・セット)
  • 概念モデリング作業の予想範囲
  • 概念モデリング作業割り当てをチーム・メンバーに割り当てる方法
  • 概念モデルの同一のエリアでチームの複数のメンバーが並行して作業しなければならなくなる可能性
  • 概念モデル資産の保管とバージョン管理に使用する構成管理ツールと、標準の CM ワークフロー

もう一つの考慮事項は、使用する概念モデルの種類です。 このツールは、ユース・ケース・モデル、分析モデル、企業 IT 設計モデルなどの特別なタイプの新しい概念モデルをインスタンス化するために使用できるいくつかのモデル・テンプレートを備えています。 テンプレートには通常、基本的な UML パッケージ構造と、いくらかのサンプルの内容が含まれます。 特定の UML2 プロファイルがあらかじめ適用されていることもあります。

RSA テンプレートとデフォルトのカスタマイズ (オプション) ページの先頭へ

以下のセクションでは、標準テンプレートを使用して RSA モデルを作成します。このモデルには、「Rational Software Architect のためのモデル構造ガイドライン」に従った基本的なパッケージ化構造が含まれます。

オプションで、ユーザー固有のテンプレートを作成できます。デフォルトのフォント、色、線種、ファイル記憶装置オプション、ステレオタイプとそのほかの情報が提示される方法などのプロパティーとオプションを事前に設定できます。 さらに、ユーザー独自の標準パッケージ構造とシード・コンテンツを定義し、 選択する UML プロファイル (作成するプロファイルを含む) を事前に適用することができます。

詳細については、Setting Up and Working with Modeling Projects」を参照してください。

モデル分割戦略の決定 ページの先頭へ

前のステップで同定したモデリング作業分担を考慮に入れ、 オンライン・ヘルプのチーム開発のセクションで説明されているいくつかの考慮事項に注意しながら、概念モデルを物理モデリング・ファイルに割り当てるための戦略を決定します。

RSA は、論理モデル・インスタンスを分解するための以下の 2 つの主要なアプローチをサポートしています。

  • 計画アプローチ (モデルに対して複数のモデリング・ファイルを作成することにより、最初からモデルを分解します)
  • 随時アプローチ (モデルのリファクタリングに基づきます)

現実の世界では、2 つのアプローチの混合がよく使用されます。 分割戦略を事前に計画した場合でも、 チーム・ワークフローを改善するためにモデルのリファクタリングが必要になることがあるからです。 このトピックの詳しい説明については、「Rational Software Architect のためのモデル構造ガイドライン」を参照してください。

詳細については、 Team Development」を参照してください。

モデリング・プロジェクトとモデルの作成ページの先頭へ

以下は、開発作業のための概念モデルのセットを確立するためのプロセスの説明です。 最初からすべてのプロジェクトとモデルを作成する必要はありません。開発作業のさまざまな段階で徐々に導入していくことができます。

  • UML プロジェクトを作成します。 サポートする開発作業と成果物を反映する名前 (たとえば、「Timesheet Management System Models」や「Timesheet Management System Use Case Modeling Files」など) を付けます。
  • プロジェクトを作成すると、そのプロジェクト内に作成する概念モデリング・ファイルのタイプを選択するように求められます。
    • 概念モデル・タイプごとに 1 つの UML プロジェクトを使用することを計画している場合は、 この時点でそのプロジェクトに望まれるモデル・タイプを選択する必要があります。
    • UML プロジェクトに複数のタイプの概念モデルを含める計画であれば、 この時点では、最終的にそのプロジェクトに含めることを計画しているタイプの中のいずれかのタイプのモデルを選択します。
    • どちらの場合も、新しいモデリング・ファイル用に分かりやすい名前を選択します。 名前は、開発するソリューションの名前とモデルのタイプを反映するもの (たとえば、「Timesheet Management System Use Case Model」や「Timesheet Management System Analysis Model」) にする必要があります。 1 つの概念モデルの論理コンテンツを複数のモデリング・ファイルに割り当てることを計画している場合は、 各モデリング・ファイルの名前が、ファイルに含められる論理コンテンツのサブセットを反映している必要があります (たとえば、「Timesheet Management System Employee Management Use Cases」や「Timesheet Management System Project Management Use Cases」など)。
  • 必要に応じて、追加のモデリング・ファイルをプロジェクトに追加します。
  • 必要な UML プロジェクトとモデリング・ファイルのセットがそろうまで、 引き続き UML プロジェクトを追加し、それらのプロジェクトに追加のモデリング・ファイルを追加します。

RUP モデルと RSA モデルの間のマッピングや、 プロジェクト・タイプの詳しい説明については、 「Rational Software Architect のためのモデル構造ガイドライン」を参照してください。

詳細については、Setting Up and Working with Modeling Projects」を参照してください。

Rational Unified Process   2003.06.15