Silverlight をインストールするには、ここをクリックします*
Japan変更|すべてのMicrosoft のサイト|サインイン
Visual Studio 2005
|MSDN ライブラリ|デベロッパー センター|ダウンロード情報|開発ツール製品|コミュニティ|ご意見・ご要望|サイトマップ
Visual Studio 2008 Service Pack 1 提供開始
最新技術情報を、オンラインセミナーで素早く取得
MSDN Home   MSDN Home
MSDN Home > Visual Studio > 技術情報 > Visual Studio 2005 クラス デザイナを使用した API 設計

Visual Studio 2005 クラス デザイナを使用した API 設計

Tony Loton
LOTONtech Limited

March 2005
日本語版最終更新日 2005 年 6 月 23 日

概要 : Visual Studio 2005 クラス デザイナを使用した API の設計方法とダイアグラム作成方法について説明します。

ClassDesignerSample.exe ファイルのダウンロード

目次

はじめに
クラス分析
クラス設計
通貨変換 API
通貨変換 Web サービス
まとめ

はじめに

この記事では、Visual Studio 2005 (Express エディションを除く) で利用可能な新しいビジュアル デザイナの 1 つであるクラス デザイナについて概要を説明します。クラス デザイナは新しい分散システム デザイナの 1 つではありませんが、分散システム デザイナとの共通点をいくつか持っており、また分散システム デザイナの機能を補完するものです。

図 1 は、アプリケーション デザイナとの関連において、クラス デザイナが果たす役割を大まかに示したものです。

図 1. クラス デザイナとアプリケーション デザイナの関係

順方向の矢印は、アプリケーション デザイナによるアプリケーション定義が、ソリューションの構造をプロジェクトの集合として決定することを示しています。クラス デザイナを使用して設計したクラスは、このソリューション構造に配置されます。逆方向の矢印は、クラス デザイナを使用して設計したクラスが、アプリケーション デザイナで作成したアプリケーションが提供するサービスのパラメータまたは戻り値として適切に機能することを示しています。これは鶏と卵の関係に似ていると思われるかもしれません。ただし、言語の標準的な型 (倍精度浮動小数点型、整数型、文字列型など) を使用してアプリケーション サービスをまず設計し、その後適切に設計されたクラスにこのサービスを組み込むこともできますし、またスタンドアロンのクラス ライブラリとして最初にクラスを設計して、その後アプリケーション モデリングを行うこともできます。この記事では、両方のアプローチについて部分的に説明します。

読者が誤った認識を抱く前に強調しておきますが、上記の説明はアプリケーション デザイナとクラス デザイナの相互運用の可能性について提示したに過ぎません。必ずしも両方のデザイナを同時に使用する必要はありませんし、またクラス デザイナを単体で使用することももちろん可能です。実際、Visual Studio 2005 Team Edition for Software Architects を使用していない場合は、クラス デザイナを単体で使用する以外に選択肢はありません。

このデザイナはクラス デザイナと呼ばれています。なぜなら、その主な目的がクラス ライブラリと API の設計にあるからです。この名称は、UML (Unified Modeling Language) で用いられる用語とも一致しています。ただし、「クラス」は、列挙型、構造体、インターフェイス、およびデリゲートとともに、クラス ダイアグラム上に表示される型の 1 つを表しているに過ぎません。

この記事では、クラス ダイアグラムへのクラスのドラッグやクラスの削除などについてしばしば言及します。記事内で「クラス」という言葉を使用するとき、クラス、インターフェイス、列挙型、デリゲート、または構造体を指す場合があるということを基本原則として覚えておいてください。クラスそのものを指す場合は、その都度詳しく説明します。

この記事の流れは以下のようになります。まずはじめに、選択したドメインの分析 (クラス) モデルを提示します。次に、その分析モデルから実装の基となる設計モデルを作成することによって、分析モデルに含まれる制約について説明します。最終的な設計モデルが単体で API を構成することはありません。なぜなら、設計モデルは実際には何の機能も持たないからです。そのため、API 自体のためのクラスをいくつか作成します。最後に、アプリケーション デザイナに関する前回の記事の中で作成したアプリケーション設計と今回作成するクラス設計を結びつけることによって、この記事のまとめにしたいと思います。

クラス図に対応するコードを提示する場合、そのコードはすべて C# で記述されています。.NET プログラミングのスタイルは選択した言語にかかわらずほとんど同じであるため、たとえ読者が Visual Basic .NET のプログラマであったとしても、C# のプログラマと同様に記事内の簡単なコード例を利用できます。

実際、C# クラス ライブラリの作成指示を VB のクラス ライブラリに置き換えることによって、記事内の手順を Visual Basic のプロセスとして再現できます。唯一の違いは、使用する言語によって用語が若干異なるということだけです。UML の包括的アプローチとは異なり、クラス デザイナでは C# クラスを作成する場合は C# の用語 (public、protected など) が使用され、Visual Basic のクラスを作成する場合は Visual Basic の用語 (Public、Friend など) が使用されます。

クラス分析

前回の記事 アプリケーション デザイナの概要 では、指定した 2 種類の通貨間における最新の為替レートを提供する ExchangeRateService という Web サービスを設計しました。また、ある通貨で指定された金額を別の通貨に変換する Web サービスも別途設計しました。ここでこれらの Web サービスを再度図示しますが、既にその目的は説明済みであるため、前回の記事を再読する必要はありません。

これらの Web サービスのどこに問題があるのでしょうか。動作については問題ありませんが、機能面での制約があります。この制約は、各サービスが倍精度浮動小数点型の単一の値 (為替レートと変換後の金額) のみを返すという点に起因しています。1 回限りの変換では問題とはなりませんが、fromAmount、toAmount、変換日時、変換時の為替レート、および指定された通貨の種類を通貨変換の履歴として残しておきたい場合は機能的に不十分です。

概念図を図 2 に示します。この図には、筆者が想定するエンティティが表示されています。

図 2. 為替分析のエンティティ

拡張した ExchangeRateService は、倍精度浮動小数点型の値を返すのではなく、dateTime、為替レート、fromCurrency (コード)、およびレートが適用される toCurrency (コード) を保持する ExchangeRate エンティティを返します。ExchangeRate エンティティは、図 2 の右側に表示されています。

拡張した CurrencyConverterService は、倍精度浮動小数点型の値を返すのではなく、変換に使用される fromAmount および toAmount を保持する ExchangeTransaction エンティティを返します。CurrencyConverterService エンティティは、図 2 の左側に表示されています。

現時点では、エンティティという言葉を使用しています。その理由は、この分析が初期分析、つまり筆者が想定するドメイン モデルを表していることを強調するためです。これらのエンティティは後で設計モデルとして再定義されます。その段階では、このエンティティがクラスや列挙型などその他の型に変換されます。

メモ 図 2 を注意して見ると、CurrencyCode に Enum という印が既に付けられているのが分かります。これは、この分析モデルの作成に Visual Studio 2005 クラス デザイナを使用したためです。他のツールを使用して分析モデルを作成した場合 (後で説明します)、こうした印が付けられるとは限りません。

分析クラス ダイアグラムの作成

何らかのクラス モデリングを行う場合は、その前に少なくとも 1 つのクラス ダイアグラムを含む Visual Studio プロジェクトを作成する必要があります。どのような種類のプロジェクトに対してもクラス ダイアログを追加できますが、ここではクラス ライブラリ プロジェクトを選択しました。その理由は、通貨変換機能をサポートする再利用可能なクラス ライブラリ (つまり API) の作成を意図しているからです。

[ファイル] メニューの [新規作成] をポイントし、[プロジェクト] をクリックして、新しいプロジェクトを作成します。次に、C# プロジェクト タイプのクラス ライブラリ テンプレートを選択します。プロジェクト名として「CurrencyClassLibrary」と入力します。

メモ ここではクラス設計に使用する言語として C# を選択しましたが、この記事で説明する内容の大部分は Visual Basic などその他の .NET 言語のクラス設計についても適用できます。

プロジェクトの作成を終えたら、1 つまたは複数のクラス ダイアグラムをそのプロジェクトに追加できます。クラス ダイアグラムを追加するには、[プロジェクト] メニューの [新しい項目の追加] をクリックします。クラス ダイアグラム テンプレートを選択して、適切な名前を入力します。この例では、「AnalysisClasses.cd」という名前を使用しています。

クラス ダイアグラムが画面に表示されると、たとえそのダイアグラムが空であったとしても、図 3 に示すツールボックスを使用できるようになります。

図 3. クラス デザイナのツールボックス

このツールボックスには、クラス、列挙型、構造体など、クラス ダイアグラムの作成に使用可能なすべての型が表示されています。 一般的な型と特定のクラスとの微妙な違いについて最初に指摘したのを覚えていますか。この違いについて詳しく見ていくことにしましょう。

分析クラス ダイアグラムの描画

次に、Visual Studio 2005 クラス デザイナを使用した、初期クラス ダイアグラムの描画方法について説明します。この説明を通じて、図 2 で提示したダイアグラムを作成していきます。読者は必要に応じて図 2 のダイアグラムを参照できます。

ExchangeTransaction クラスの追加

まずはじめに、ツールボックスから [クラス] をクラス ダイアグラムにドラッグして、そのクラスに「ExchangeTransaction」という名前を付けます。ダイアグラム上のクラスを右クリックし、コンテキスト メニューの [追加] をポイントして、[プロパティの追加] をクリックします。プロパティ名として「fromAmount」と入力し、同じ作業を toAmount プロパティに対して繰り返します。

ExchangeTransaction.cs という名前の新しいソース ファイルがソリューション エクスプローラに表示されます。このファイルには以下のコードが記述されています。

public class ExchangeTransaction
{
  public int fromAmount
  {
    get { throw new System.NotImplementedException(); }
    set  { }
  }

public int toAmount
{
    get { throw new System.NotImplementedException(); }
    set  { }
  }
}

このコードを表示するには、ソリューション エクスプローラから ExchangeTransaction.cs ファイルを開くか、またはダイアグラム上のクラスを右クリックして、コンテキスト メニューの [コードの表示] をクリックします。

CurrencyCode 列挙型の追加

ツールボックスから [列挙型] をクラス ダイアグラムにドラッグして、その列挙型に「CurrencyCode」という名前を付けます。ダイアグラム上の列挙型を右クリックし、コンテキスト メニューの [追加] をポイントして、[メンバの追加] をクリックします。メンバ名として「USD」と入力し、同じ作業を EUR メンバに対して繰り返します。それぞれのメンバに対して対応する値を [プロパティ] ウィンドウで設定します。USD に対しては「1」を、EUR に対しては「2」をそれぞれ指定します。

CurrencyCode.cs という名前の新しいソース ファイルがソリューション エクスプローラに表示されます。このファイルには以下のコードが記述されています。

public enum CurrencyCode
{
  USD = 1,
  EUR = 2,
}

ExchangeRate クラスの追加

ツールボックスから [クラス] をクラス ダイアグラムにドラッグして、そのクラスに「ExchangeRate」という名前を付けます。ダイアグラム上のクラスを右クリックし、コンテキスト メニューの [追加] をポイントして、[フィールドの追加] をクリックします。フィールド名として「dateTime」と入力し、同じ作業を rate フィールドに対して繰り返します。[クラスの詳細] ウィンドウ (図 4) で、それぞれのフィールドの型を設定します。

図 4. [クラスの詳細] ウィンドウ

[クラスの詳細] ウィンドウについては、この段階で少し詳細に説明しておくほうが良いでしょう。クラス名やメンバ名などクラスの詳細情報の一部についてはダイアグラム上で直接変更できますが、メンバの型や表示/非表示を変更する場合は、[クラスの詳細] ウィンドウを使用する必要があります。

次に、ExchangeTransaction クラスと同様に 2 つのプロパティを追加し、これらのプロパティに対して「fromCurrency」と「toCurrency」という名前を付けます。これらのプロパティの型を CurrencyCode に設定します。

ExchangeRate.cs という名前の新しいソース ファイルがソリューション エクスプローラに表示されます。このファイルには以下のコードが記述されています。

public class ExchangeRate
{
  private double rate;
  private DateTime dateTime;
   
  public CurrencyCode fromCurrency
  {
    get { throw new System.NotImplementedException(); }
    set  { }
  }

  public CurrencyCode toCurrency
  {
    get { throw new System.NotImplementedException(); }
    set  { }
  }
}

以上の操作の結果、通貨変換をサポートする初期分析モデルが完成しました。このモデルは後で設計モデルに変換されます。指示に従って操作したにもかかわらず、各クラスのフィールドやプロパティの型がダイアグラムに表示されていない場合は、[Class Diagram] メニューの [Display Member Types] をクリックすると正常に表示されるようになります。

他のモデリング ツールを使用したクラス分析

Visual Studio 2005 は、全範囲をカバーする分析レベルのダイアグラム表記法を (現時点では) 提供していません。Visual Studio 2005 が現時点で提供する表記法は、設計、実装、および配置に関するものに限定されています。

読者は要件を満たす好みの UML モデリング ツールを使用して、初期分析 (ドメイン) クラスを描画することももちろん可能です。筆者のお勧めのツールは Visio for Enterprise Architects です。筆者がこのツールに関する書籍の執筆に加わったことをご存知の読者であれば、このツールを推奨するのも何ら意外なことではないでしょう。

メモ この書籍は http://www.amazon.com/exec/obidos/tg/detail/-/0764543768 から入手できます。

Visio や無料なものも含め、他の UML ツールを使用することの客観的な利点の 1 つは、Visual Studio 2005 のフル スイートを購入する場合と比べて、ビジネス アナリストやシステム アナリストの負担する投資金額が安く済むということです。

(他のツールによる) クラス分析から (Visual Studio 2005 による) クラス設計に移行するための要件は、.NET のいずれかの言語で記述されたコードを他のツールを使用して生成できるかどうかということだけです。選択した言語でのクラスの作成を終えたら、後は Visual Studio 2005 を使用してそのコードからクラス ダイアグラムを作成するだけです。

ソース ファイルをプロジェクトに追加して、ソリューション エクスプローラからそれらのファイルを直接クラス ダイアグラムにドラッグします。空のクラス ダイアグラムを最初に作成するには、[プロジェクト] メニューの [新しい項目の追加] をクリックして、クラス ダイアグラム テンプレートを選択します。または、ソリューション エクスプローラのコード ファイルを右クリックして、[ダイアグラムで表示] をクリックすると、選択した項目を含むクラス ダイアグラムが作成されます。

コードの表示画面としてのクラス ダイアグラム

クラス ダイアグラムが、基礎となるコードの表示画面に過ぎないという点を理解することが重要です。これは、クラス ダイアグラムをいくつでも作成できるということを意味します。また、ソリューション エクスプローラからクラスをドラッグ可能なダイアグラムの数についても制限はありません。クラスをドラッグする際に、クラスの二重作成について考慮する必要もありません。

ダイアグラムはコードの表示画面に過ぎないため、両者は常に同期が取られます。したがって、変更を行う場合にはクラス デザイナとコード エディタから好きなほうを使用できます。いずれかのツールを使用して変更を加えると、もう一方の画面にその変更内容が自動的に反映されます。

クラス設計

筆者自身が作成した初期分析用のクラス ダイアグラムではなく、ビジネス アナリストまたはシステム アナリストが Visual Studio または Visio で作成したダイアグラムをインプットとして使用して、Visual Studio でコードとクラス ダイアグラムの作成を行うものと仮定してみましょう。

デザイナやデベロッパにとっては、通貨変換をサポートするために必要なオブジェクトの説明から始めるのが適切です。ただし、アナリストの分析が少々ずさんで、クラス モデルが実装の基礎として不適切だったとします。対処すべき具体的な問題として以下が考えられます。

  • ExchangeRate クラスのフィールドがプロパティで適切にカプセル化されていない。
  • ExchangeTransaction のプロパティの型が不適切で、倍精度浮動小数点型ではなく整数型が使用されている。
  • ExchangeTransaction のプロパティに値の取得先となる基本フィールドが設定されていない。
  • ExchangeRate クラスと CurrencyEnum 列挙型のリンクが、fromCurrency メンバと toCurrency メンバの型を介して暗黙的に定義されているものの、ダイアグラム上で明示的な関連として定義されていない。
  • ExchangeTransaction と ExchangeRates の間につながり (関連) がない。したがって、通貨変換時に特定の ExchangeTransaction が使用した ExchangeRate を記録することができない。

もちろん、読者自身が別の問題を発見する場合もあるでしょう。上記の問題は実用的な側面を考慮して考案したものであり、以下ではこれらの問題の対処方法について説明します。

出発点

指示に従って初期クラス ダイアグラムを作成した場合は、1 つのクラス ダイアグラムと 3 つの C# ソース ファイルを含む Visual Studio プロジェクトが既に作成されているはずです。指示に従わなかった場合は、空のプロジェクトを作成して、筆者が用意した AnalysisClasses.cd、CurrencyCode.cs、ExchangeRate.cs、および ExchangeTransaction.cs ファイルをそのプロジェクトに追加します。

まず、DesignClasses.cd という名前のクラス ダイアグラムを新規に作成します。ダイアグラムを作成するには、ソリューション エクスプローラでプロジェクトを右クリックして、[追加] をポイントし、[新しい項目] をクリックして、クラス ダイアグラム テンプレートを選択します。次に、ソリューション エクスプローラから 3 つのクラス (実際にはクラスのソース ファイル) を新規ダイアグラム上にドラッグします。

分析クラスから設計クラスへの移行

上記の問題に対処することによって、分析クラス ダイアグラムを設計クラス ダイアグラムへと移行します。各手順ごとにほとんど同じ内容の図を再作成するのを回避するため、まずはじめに最終的なダイアグラムを図 5 に示します。指示があった場合は図 5 のダイアグラムを再度参照して、変更箇所を確認できます。

図 5. 為替設計クラス

フィールドまたはプロパティの型を変更

まずはじめに、ExchangeTransaction クラスの fromAmount プロパティと toAmount プロパティの型を整数型から倍精度浮動小数点型に変更する必要があります。図 6 に示すように、メンバのプロパティまたはフィールドを変更する場合は [クラスの詳細] ウィンドウを使用します。

図 6. [クラスの詳細] ウィンドウでメンバの型を変更

クラスをクリックしても [クラスの詳細] ウィンドウが表示されない場合は、[表示] メニューの [その他のウィンドウ] をポイントして、[クラスの詳細情報] をクリックするか、またはクラスを右クリックしてコンテキスト メニューを使用すると、いつでも [クラスの詳細] ウィンドウを表示させることができます。

プロパティの実装

ExchangeTransaction クラスの fromAmount プロパティと toAmount プロパティについては、これまでのところ実装が行われていません。つまり、これらのプロパティへの戻り値を取得するための基本フィールドまたはその他のメカニズムが存在しないことになります。プロパティの格納場所については言うまでもありません。

これらのプロパティを実装するには、コード ビューを開いて (ExchangeTransaction クラスを右クリックして、[コードの表示] をクリックします)、以下に示す C# のコードを記述します。 

public class ExchangeTransaction
{
  private double frmAmt;
  private double toAmt;
   
  public double fromAmount
  {
    get { return fromAmt; }
    set { frmAmt = value; }
  }

  public double toAmount
  {
    get { return toAmt; }
    set { toAmt = value; }
  }
}

この変更はすべてコード内で行っています。これは、コードまたはダイアグラムのいずれを使用しても同様に変更できることを強調するためです。2 つのビューは完全に代替可能です。したがって、get メソッドと set メソッドの実装はダイアグラムに表示されませんが、ExchangeTransaction クラスに追加した 2 つのフィールドは自動的に表示されます。これは、現在の設計クラス ダイアグラムだけでなく、元の分析クラス ダイアグラムについても同様です。

フィールドをプロパティでカプセル化

ExchangeRate クラスについても同様の問題があります。ただし、先ほどとは逆で、フィールドがプロパティでカプセル化されていないという問題です。この問題についてもコードで修正可能ですが、ここではより興味深いアプローチを紹介したいと思います。

クラスのダイアログの任意のフィールドを右クリックして、コンテキスト メニューの [リファクタ] をポイントし、[フィールドのカプセル化] (Encapsulate Field) をクリックすると、図 7 のダイアログが表示されます。

図 7. [フィールドのカプセル化] (Encapsulate Field) ダイアログ

このダイアログでは、dateTime フィールドをカプセル化する DataTime という名前の新しいフィールドを作成できます。ダイアログの表示されている内容をそのまま使用し、rate フィールドについても同様にカプセル化します。

図 5 に戻ると、この変更の結果を確認できます。コードは以下のように変更されます。

public class ExchangeRate
{
  private double rate;
  public double Rate
  { get { return rate; } set { rate = value; } }

  private DateTime dateTime;

  public DateTime DateTime
  { get { return dateTime; } set { dateTime = value; } }
}

関連の表示

元の分析クラス ダイアグラム (図 2) を再度参照すると、ExchangeRate クラスには fromCurrency および toCurrency という 2 つの CurrencyCode 型のプロパティがあります。CurrencyCode は同じダイアグラム上で列挙型として表示されており、このプロパティに指定可能な値が分かります。

設計クラス ダイアグラム (図 5) では、これらのプロパティはもう表示されていません。ただし、プロパティに対応する関連付けが、ExchangeRate クラスと CurrencyCode 列挙型の間に引かれています。これは、為替レートと通貨コードの関係をより直感的に理解できる表示方法であり、また UML の使用経験がある読者にとっては非常になじみ深いものでもあります。

プロパティ表示を関連表示に切り替えるには、各プロパティを右クリックして、コンテキスト メニューの [関連として表示] をクリックします。プロパティ表示に戻すには、関連付けを右クリックして、コンテキスト メニューの [プロパティとして表示] をクリックします。これら 2 つの表示のいずれを使用するかは好みの問題であり、コードでは区別されません。

メモ 一部のUML ツールは、この機能を異なる方法で提供しています。これらのツールでは、基本型を既定する定義済みの規則に従って、メンバの型が属性 (プロパティに似た概念) または関連として表示されます。たとえば、文字列オブジェクトは基本型として定義されるため、UML の文字列はすべて String クラスへの関連ではなく属性として表示されます。

もう 1 つ追加する関連があります。それは、ExchangeTransaction クラスと ExchangeRate クラス の関連です。この関連を追加することにより、すべての通貨変換処理において、変換前の金額、変換後の金額、変換時の為替レート、および変換に使用された 2 種類の通貨を特定できます。

この関連は現在存在しないため、追加する必要があります。関連を追加するには、ツールボックスの [関連付け] を選択して、ExchangeTransaction クラスをクリックし、ExchangeRate クラスにドラッグします。この関連の名前は変更できますが、「ExchangeRate」という既定の名前が適切なため、そのままにしておきます。

以上の作業の結果、最初に図 5 で提示したダイアグラムが完成します。

プロパティの実装 (再考)

読者がクラス デザイナを使用するのは初めてかもしれませんが、最後の関連を作成したときに、ソフトウェアの専門家としてさらなる合理化の余地があることに気付いた読者もいるでしょう。

ExchangeTransaction クラスが toAmt フィールドを保持する必要はもうありません。なぜなら、fromAmt と ExchangeRate 関連付け/プロパティを使用することで、toAmount を算出できるからです。したがって、以下のコードに示すように、toAmt フィールドを削除して、toAmount プロパティの実装を変更します。

public double toAmount
{
  get 
  {
    // toAmt を返します。
    return fromAmt * ExchangeRate.Rate;
  }
}

toAmount を計算で算出するように変更したため、このプロパティは読み取り専用に設定する必要があります。つまり、set ブロックが必要なくなります。この変更を行うかどうかは読者の判断にお任せします。

通貨変換 API

この記事では API の設計を行うということを暗に示してきました。読者は、API という言葉の意味を、特定のコンテキストで有用な機能を果たす 1 つまたは複数のオブジェクトとして捉えたかもしれません。これまでは API をサポートするオブジェクト モデルを作成してきましたが、API それ自体については何も手をつけていません。

API は以下の 2 つのクラスから構成されます。

  1. BureauDeChange クラス。getExchangeRate メソッドを使用して、2 種類の通貨間の為替レート情報を提供します。
  2. CurrencyConverter クラス。ある通貨表示の金額を別の通貨表示の金額に変換するためのさまざまなメソッドを提供します。

少なくとも BureauDeChange クラスについては、拡張 API を使用した複数の実装を可能にしたいと考えています。こうすることによって、複数のベンダによって競争的に提供される為替レート機能の中から、最も価値の高いサービスを選択できるようになります。

実際には BureauDeChange を、実装例を含むインターフェイスとして定義します。この理由は、クラス ダイアグラム上でインターフェイスの使用例を示すため (真の目的) だけでなく、クラス モデリングと異なり、インターフェイス モデリングはそれ自体が優れたテクニックだからです。

CurrencyConverter については複数の実行を行うつもりはないので、単純にクラスとして設計します。

ここでもまた、最終的なダイアグラムを先に提示することにします。こうすることによって、読者が次の手順を予期できるようになり、また必要に応じて参照できるようになります。APIClasses.cd という名前のクラス ダイアグラムを図 8 に示します。

Figure 8. API クラス

図 8 に示す APIClasses.cd という名前のクラス ダイアグラムを作成するための最初の手順については、もう説明の必要はないでしょう。

BureauDeChange インターフェイスと実装クラス

まずはじめに、ツールボックスから [Interface] をクラス ダイアグラムにドラッグして、そのインターフェイスに「IBureaDeChange」という名前を付けます。次に、[クラスの詳細] ウィンドウを使用して、getExchangeRate という名前のメソッドを追加し、そのメソッドに対して図 9 に示す戻り値の型とパラメータを設定します。

図 9. IBureauDeChange のクラス詳細

パラメータと戻り値の型が先に定義した (ドメイン) 設計クラスに一致していることに注意してください。その結果、オブジェクト モデルと API が結合され、API がモデルで定義されたオブジェクトを使用してサービスを提供できるようになります。

次に、このインターフェイスの具体的な実装を作成する必要があります。ツールボックスから [クラス] をダイアグラムにドラッグして、そのクラスに「BureauDeChange」という名前を付けます。ツールボックスの [継承] をクリックして、次に BureauDeChange クラスをクリックし、最後に IBureauDeChange インターフェイスをクリックします。この操作によって、BureauDeChange クラスが IBureauDeChange インターフェイスを実装することになります。図 9 に示すように、IBureauDeChange インターフェイスを表すロリポップ形の記号が BureauDeChange クラスの上に表示されます。IBureauDeChange インターフェイスに定義されたメソッドに対するメソッド スタブが、クラス デザイナによってBureauDeChange クラスに自動的に作成されます。

CurrencyConverter クラス

API クラス ダイアグラム I を作成するには、以下の手順を実行します。

  • ツールボックスから [クラス] をダイアグラムにドラッグして、そのクラスに「CurrencyConverter」という名前を付けます。
  • 図 10 に示すように、[クラスの詳細] ウィンドウを使用して、このクラスに 3 つのメソッドを追加します。
  • ツールボックスの [関連付け] を使用して、CurrencyConverter クラスとIBureaDeChange インターフェイスの間に関連付けを作成します。

図 10. CurrencyConverter のクラス詳細

この関連付けは、CurrencyConverter クラスが、IBureaDeChange インターフェイスの実装クラスによって提供されるサービスに依存していることを示しています。この実装クラスは、先ほど作成した既定の BureauDeChange 実装クラスである必要は必ずしもありません。

この API クラスがパラメータと戻り値の型にオブジェクト設計モデルのクラスを使用している点についても、改めて注意が必要です。

通貨変換 Web サービス

以上で、通貨変換エンティティを提供するドメイン オブジェクト モデルと、これらのドメイン クラスを使用して通貨変換機能を提供する一連の API クラスの分析と設計が終了しました。

この API は、.NET の通常のクラスとインターフェイスとして設計されており、同じプログラムのインスタンス内から直接呼び出されます。これは、クラス デザイナの動作を説明する場合には良い方法ですが、実際にサービスを提供する API についてはこの方法を採用するつもりはありません。

この連載の最初の記事を読んでいる読者は、これらの API クラスがかなりなじみ深いものに思えるでしょう。前回の記事に掲載した図 11 を見れば、筆者の意図していることが理解できると思います。

図 11. 通貨変換 Web サービス

当時の筆者の考えは、為替レート情報を提供する Web サービス (ExchangeRateService) を組み込んだWeb アプリケーション (BureauDeChange) と、通貨変換機能を提供する Web サービス (USDollarService および EuroService) を組み込んだ Web アプリケーション (CurrencyConversion) を設計することでした。すべてのケースにおいて、同じプログラムのインスタンス内からではなく、リモートから機能が呼び出されます。

これらの Web サービス アプリケーションの設計を行ったとき、パラメータおよび戻り値の型として単純な整数型や倍精度浮動小数点型などを指定しました。Web サービスの機能を拡張するには、この点に立ち返ってみる必要があります。パラメータおよび戻り値の型として、ExchangeTransaction、ExchangeRate、CurrencyCode などのドメイン オブジェクトを使用することで、この記事で作成したクラス設計をこれらの Web サービスから利用できるようになります。また、これらのサービスは、ここで作成した API クラスのデリゲートとなる単純なファサードとして機能するように実装されています。これは、Web サービスおよび標準クラスとして同じ機能を重複して実装することを避けるためです。

まとめ

この記事では、論理的な進行に従って、まずはじめにクラス分析 (Visual Studio 2005 クラス デザイナなどのツールで実行できます) を、続いてクラス設計 (実装を行ううえで Visual Studio 2005 クラス デザイナが不可欠です) を行いました。

ただし、クラス デザイナの機能は、初期クラス設計に限定されるものではありません。バージョン 1 のクラス デザイナは、既存コードの視覚化、リファクタリング (この記事でも触れています)、ドキュメント用のダイアグラムの作成など、いくつかの追加的用途に対する最適化が行われました。

初期分析や初期設計は API の基礎となるドメイン オブジェクト モデルを対象としていますが、実際に API を作成するためには、このオブジェクト モデルに基づいてサービスを提供する追加クラスを設計する必要があります。

これらのサービスは、単純に通常のクラスのメソッドとして提供される場合もありますし、Web サービスなど純粋なサービスとして提供される場合もあります。この連載では、今回の記事で行った作業と前回の記事で行った作業を関連付けることによって、これら 2 つの方法を統合しています。

Tony Loton は、LOTONtech Limited (www.lotontech.com) のプリンシパル コンサルタント兼ディレクタ、Cogenture (www.cogenture.com) のプリンシパル コンサルタント兼マイクロソフト部門ヘッド、英国放送大学の準講師など、多くの肩書きを持つ MCP です。現在は、2005 年夏に Wiley/Wrox より発刊予定の『Professional Visual Studio 2005 Team System』(ISBN 0764584367) を共同執筆中です。


Microsoft