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

ビューの切り替え

Visual Studio 2005 クラスデザイナを使用した AP...

言語フィルタ

Tony Loton
LOTONtech Limited

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

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

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

はじめに

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

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

ms379621.vstsclassdesigner-fig1(ja-jp,VS.80).gif

図 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 に示します。この図には、筆者が想定するエンティティが表示されています。

ms379621.vstsclassdesigner-fig2(ja-jp,VS.80).gif

図 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 に示すツールボックスを使用できるようになります。

ms379621.vstsclassdesigner-fig3(ja-jp,VS.80).gif

図 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) で、それぞれのフィールドの型を設定します。

ms379621.vstsclassdesigner-fig4(ja-jp,VS.80).gif

図 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 のダイアグラムを再度参照して、変更箇所を確認できます。

ms379621.vstsclassdesigner-fig5(ja-jp,VS.80).gif

図 5. 為替設計クラス

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

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

ms379621.vstsclassdesigner-fig6(ja-jp,VS.80).gif

図 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 のダイアログが表示されます。

ms379621.vstsclassdesigner-fig7(ja-jp,VS.80).gif

図 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; } }
}

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

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

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 つのクラスから構成されます。

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

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

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

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

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

ms379621.vstsclassdesigner-fig8(ja-jp,VS.80).gif

Figure 8. API クラス

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

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

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

ms379621.vstsclassdesigner-fig9(ja-jp,VS.80).gif

図 9. IBureauDeChange のクラス詳細

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

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

CurrencyConverter クラス

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

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

ms379621.vstsclassdesigner-fig10(ja-jp,VS.80).gif

図 10. CurrencyConverter のクラス詳細

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

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

通貨変換 Web サービス

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

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

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

ms379621.vstsclassdesigner-fig11(ja-jp,VS.80).gif

図 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) を共同執筆中です。

ページのトップへ

プロファイル (個人情報) の管理 | お問い合わせ先 | MSDN Flash ニュースレター | 日本での個人情報の取り扱い | サイトマップ

目次

はじめに

クラス分析

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

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

ExchangeTransaction クラスの追加

CurrencyCode 列挙型の追加

ExchangeRate クラスの追加

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

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

クラス設計

出発点

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

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

プロパティの実装

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

関連の表示

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

通貨変換 API

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

CurrencyConverter クラス

通貨変換 Web サービス

まとめ

目次

はじめに

クラス分析

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

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

ExchangeTransaction クラスの追加

CurrencyCode 列挙型の追加

ExchangeRate クラスの追加

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

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

クラス設計

出発点

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

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

プロパティの実装

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

関連の表示

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

通貨変換 API

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

CurrencyConverter クラス

通貨変換 Web サービス

まとめ

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

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

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

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