開発ライフサイクルとVisual Studio 2005という選択肢第2回

アーキテクチャ策定におけるVSTE for SAの有効性

アーキテクチャ策定におけるVSTE for SAの有効性として、アーキテクチャチームと基盤チームの相互理解とデザイナツールと成果物の連携があげられます。

アーキテクチャチームと基盤チームの相互理解

アーキテクチャ定義は重要ですが、専門性が進んでいる現在ではアプリケーションとシステム基盤に担当が分かれているケースが多く、認識の齟齬（そご）が後々大きな影響につながります。

このような問題を早期に解消する場合に分散システムデザイナは効果を発揮します。アーキテクチャチームがアプリケーションデザイナを使用してアプリケーションの構成を設計し、システム基盤チームが論理データセンターデザイナを用いてシステム基盤を設計します。その際お互いの設計に対して配置デザイナを用いてマッピングし、双方の構成の正当性を検証することによって、両者のギャップを早い段階に埋めることが期待できます。

デザイナツールと成果物の連携

アプリケーションデザイナでは検証後に構成ファイルを生成します。「ASP .NET Webサービス」の場合はサービスメソッドなどを含んだソリューションのプロジェクトを生成してくれます。インプリメントする言語も定義されていますので、アーキテクトが設計したとおりに実装されていくことが望めます。

ただしソースコードの変更がアプリケーションデザイナに反映されるのは、「ASP .NET Webアプリケーション」「ASP .NET Webサービス」、「Windowsアプリケーション」のみのため、そのほかのアプリケーション構成要素を使用する場合には不整合に注意しなければなりません。また分散オブジェクトの接続技術はXML Webサービスのみで、.NETリモーティング、MSMQなどは用意されていないため、この部分は残念です。

またアーキテクチャの実証ではクラスの設計と実装まで行いますが、ここでクラスデザイナが効果を発揮します。クラスデザイナによってデザインとソースコードが双方向で反映されるため、ドキュメントへの変更漏れなどの不一致による品質劣化を防げます。またドキュメントの修正を意識する必要がないため、管理コストも減らせます。クラス設計は設計時だけではなく、開発中にも仕様変更などによる変更があるため有効と考えられます。

まとめと今後の展開

VSTE for SAはアーキテクチャの策定を支援する機能が盛り込まれるため、基盤チームにも導入していただきたいツールです。

しかし多様な異種分散システム連携となった場合は、デフォルトの構成要素だけではではカバーできない部分も多くあり、これからの発展に期待しましょう。もちろんマイクロソフト社もこれが最終の形だとは言及していません。

マイクロソフトが提唱するDynamic Systems Initiative（注2）は、はじまったばかりの段階です。前述したニーズへの対応もされるでしょう。

※注2： Dynamic Systems Initiative（DSI）は、Microsoft Windowsプラットフォームを強化し、企業が分散システムを設計、展開、運用する際の作業を簡素化、および自動化する、調整の取れたソリューションのセットを提供することを目的としたマイクロソフトと業界の取り組みです。

また今後想定されている機能には、分散システムデザイナが検証だけでなくデザイナでの変更がそのままWebサーバやSQLサーバの設定に反映されるような機能が考えられます。もしそうなればツールの一貫性としては大きな躍進であり、成果物の作成や管理もかなり簡素化されるため、VSTE for SAの有効性がより高まると考えられます。

また基盤設計・運用系に関しては、アプリケーション診断、自動復旧、自動負荷分散などの運用時の自動化機能も想定されているようです。

DSI構想によるVS2005 Team Systemの進化は非常に興味深く、今後の発展に期待できる面白い構想に基づいた製品だといえます。

さらなる思いとしては、ロードバランシングやフェイルオーバークラスタなどのネットワーク機器やサービス、ファーム構成の検証なども対象になってくれるとうれしいです（マイクロソフトさん、よろしくお願いします！）。