 |
|||||||
|
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
「Visual Studio 2005 Team System」、その本質に迫る 【第二回】 |
||||||||||||||||||||
|
||||||||||||||||||||
|
～システムアーキテクト向け機能「Software Architects」
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
今回解説するVisual Studio Team Edition for Software Architects（以下、Software Architects）は、その名前が示すようにシステムアーキテクトが使用するアプリケーション設計のツールセットで、モデルによって視覚的にアプリケーションを設計することができる。分散アプリケーション開発を強く意識しているため、設計の段階から運用や配置を意識したアプリケーション開発ができる。また、Software Architectsで作成されるモデル図は、Team Developerで作成するコード（ソースコード）と同期させることが可能となっている。 では、具体的にSoftware Architectsでは何ができるのだろうか？ 【3月23日更新】コンポーネントの名称変更に伴い、Team Systemのコンポーネント名を変更しました。 ■ 分散アプリケーション開発のためのモデリング機能 Visual Studio 2005 Team System（以下、Team System）は、大規模な分散アプリケーションをチームで開発することを目的としている。企業システムの多くは、複数の場所に配置されたソフトウェアのコンポーネントを相互に接続して構成される分散アプリケーションである。WebサービスやSOA（サービス指向アークテクチャ）に対応したり、既存の資産をラッピングして生かすなど、分散アプリケーションの開発は複雑となるため、開発者の知識や経験に左右される部分が大きい。にもかかわらず、アプリケーション開発には低コストで短納期であることが求められ、運用コストの削減も視野に入れなければならない。モデルによるアプリケーション開発（モデル駆動型開発）は、大規模・複雑化するアプリケーション開発の負担を軽減する解決策である。このモデル駆動型開発のベースとなるのは、オブジェクト指向という考え方である。オブジェクト指向によるアプリケーション開発では、アプリケーションをオブジェクトの集合として捉え、オブジェクトの目的や振る舞い、オブジェクト間のコミュニケーション、オブジェクト群の構図などを規定（プログラミング）していく。オブジェクトの構造やオブジェクト同士の関わりなどは、プログラミング言語だけで表現することは難しいため、設計や開発をスムーズにするために図（ダイアグラム）で表現されることが多い。この図を「モデル」と呼び、モデルを記述する規定された表記法がモデリング言語である。 しかし、モデリング言語で記述されたモデルは、あくまでも「絵に描いた餅」であり、モデルは実装コードに変換しなければならない。現在、多くの開発ツールは、モデルからコードを自動的に生成したり、コードからモデルを作成する機能が提供されている。もちろんTeam Systemも例外ではなく、Software Architectsで作成したモデルから実装コードを自動的に生成できるようになっている。 一般的に知られているモデリング言語の代表は「UML（Unified Modeling Language）」といえるが、Team Systemではマイクロソフトが提唱している「SDM（System Definition Model）」というシステム定義に最適化されたモデリング言語を使用する。UMLとSDMは対立関係にあるわけではない。UMLはその名前が示すように「Unified」、つまり統一的なモデルである。より広い範囲（業種）をカバーすることを前提とした仕様のUMLに対して、SDMはシステム定義に最適化することで効率化を図っている。両者は補完関係にある。これは、UMLと「BPEL」「ER」「DFD」が補完関係であるのと本質的には同じであるといえる。そのため、Team SystemでもVisioを介してUMLを利用することが可能となっている。 プラットフォームに依存するような低レベルの実装部分をオブジェクトとして抽象化することで、アプリケーションの設計を容易にし、多くの実装コードを自動生成することで開発の効率が向上する。また、アプリケーションの抽象度を上げることで、モデルやコードの再利用性が高くなる。 ■ 運用を意識した「分散システムデザイナ」 Software Architectsに含まれる「分散システムデザイナ」は、分散アプリケーションをGUIベースで設計するモデリングのツールセットだ。以前から「Whitehorse」というコードネームで呼ばれていた機能で、アプリケーションのアーキテクト、デザイナ、開発者、オペレーションアーキテクト用のツールが含まれている。システムの規模が大きくなると、アプリケーションの設計および開発のチームと、サーバーやネットワークの運用を行うインフラのチームに分かれてしまうことが多い。アプリケーション開発とインフラ運用チームの距離が近ければ、インフラにおける制約（ハードウェア的制約、運用ポリシーなど）と、アプリケーションの要件に矛盾が発生することはない。しかし両者のコミュニケーションがスムーズに行われなくなると、実際にアプリケーションを配置するまで、制約と要件との間にある矛盾に気づかないこともある。そこで分散システムデザイナでは、アプリケーションの構造だけではなく、実際にアプリケーションがどのように配置されるのかをモデルで表現できる。これによって、分散アプリケーションの構造を把握することが容易になり、実際の運用をイメージしたアプリケーション設計が可能になる。 分散システムデザイナで作成できるダイアグラムには、「アプリケーション接続ダイアグラム」「システムダイアグラム」「論理データセンターダイアグラム」「配置ダイアグラム」がある。
アプリケーション接続ダイアグラムでは、設計の段階から配置・運用を考慮したアプリケーションを定義することができる。アプリケーション接続ダイアグラムのツールボックスには、「Webサービス」「Webアプリケーション」「Windowsアプリケーション」「外部データベース」「外部Webサービス」「外部BizTalkサービス」といったアプリケーションのプロトタイプセット、およびその他のアプリケーションのプロトタイプを文書化するための「汎用アプリケーションプロトタイプ」が用意されている。また、このダイアグラムでは、ツールボックスでアプリケーションを追加してシステムを新規に作成する以外に、既存のシステムを解析（リバース）することもできる。
論理データセンターダイアグラムでは、相互接続された論理サーバーのダイアグラムを作成し、データセンターの論理的な構造を表現することができる。運用側のアナリストが、サーバーの種類、通信経路、使用可能なサービスの種類といった配置する環境に関する情報（インフラの制約）をデータセンターダイアグラムとして表現することで、設計や開発の段階から運用を考慮したアプリケーションの設計が可能になる。論理データセンターダイアグラムのツールボックスには、ダイアグラムサーフェスに追加できる定義済み論理サーバーのプロトタイプとして、「Windowsクライアントサーバー」「Webサーバー（IISサーバー）」「SQLサーバー」「汎用サーバー」が用意されている。また、論理サーバーの設定は、実際のサーバーからも設定をインポートできる。
システムダイアグラムでは、アプリケーション接続ダイアグラムで定義したアプリケーションから、システムを作成・設定できる。分散システムデザイナにおける開発単位は、1つ以上のアプリケーションとサブシステムで構成される「システム」となる。このシステムは他のシステムを組み合わせることもできるため、システムが入れ子状態になった複雑な多層システムも定義可能だ。システムダイアグラムでの定義は、特定のシステムをアプリケーション接続ダイアグラムで設定した開発構成から切り離して定義できる。
配置ダイアグラムでは、論理データセンターダイアグラムで定義されている特定のサーバーに対し、システム内のアプリケーション配置を定義できる。また、明示的に配置を定義することで、配置の妥当性を検証することが可能になる。検証では、システム内のアプリケーションが正しく連結されていることを確認し、アプリケーションが正しく制約を満たしているかどうか、必要な通信経路が存在するかどうかなどをチェックできる。 ■ クラスデザイナ
クラスデザイナは、Software ArchitectsとSoftware Developersの両側にまたがった機能として定義されており、既存のコードからクラス図を作成して視覚的に構造を把握することも可能だ。また、共通言語ランタイム用のデザインツールであるため、共通言語ランタイムに対応した複数の言語からクラス図を作成したり、逆にコードを生成することもできる。 クラスデザイナの情報は、開発チーム内のコミュニケーションツールとしての利用を意識しているため、クラス図を印刷したり、HTMLやPowerPointのデータとして保存することも可能である。 ■ まとめ ～アプリケーションの抽象度を上げるということ Software Architectsの機能を一言で表現するなら「モデリング」である。大規模で複雑なアプリケーションをビジュアル化して抽象度を上げ、実装レベルのコードを意識せずにデザインできることを目的としている。ビジュアルで表現することでアプリケーションの構造を容易に把握できるようになるため、設計・開発・運用と立場の違う技術者の間の意識をあわせることで、ライフサイクル全体を考慮したアプリケーション開発が可能になる。アプリケーションの抽象度を上げることのメリットには、プラットフォームに依存しない再利用性の高いオブジェクトが作成できることも挙げられる。最終的に生成される実装コードはプラットフォームに依存するが、その基となるモデルは、汎用的で再利用性が高いソフトウェア資産として蓄積される。ベストプラクティスとしてソフトウェア資産を蓄積することで、あるいはすでに存在しているベストプラクティスを利用することで、アプリケーション開発でのリスク軽減、品質向上、コスト削減、開発期間短縮といった効果を得ることができる。 次回は、実際にコードを記述するSoftware Developersについて解説する。 ■ ＵＲＬ マイクロソフト株式会社 http://www.microsoft.com/japan/ Visual Studio 2005 Team System http://www.microsoft.com/japan/msdn/vstudio/2005/teamsystem/
（ 北原 静香 ）
|
