Share via

Team System におけるシステム定義モデリング

こんにちは。無事に（締切オーバーして・・・） Tech・Ed のセッション資料の作成が完了しました。 前回の記事 をご覧いただいた方々から激励のメールをいただきました。ストレッチの効果的な仕方まで教えていただきました。ありがとうございます!! ブログもメールやコメントをいただくことで、インタラクティブにコミュニケーションがとれ、つながり感を感じられてとてもうれしいです（＾＾）

# ところで、spam なコメントが相変わらず多いのですが、これらはこまめに削除しています。承認方式などにするのもありなのですが、多くの方からのコメントをいただきたいため、今まで通りに自由にコメントいただけるようにしておくつもりです。もし怪しいコメントがありましたら、リンクをクリックしないようにご注意ください m(_ _)m

さて、Team System では、SOA 時代の非常に複雑なアーキテクチャやインフラをもつシステムのモデリング支援を行う機能が用意されています（VS2005 だと Team Edition for Software Architects、VS2008 だと Team System Architecture Edition）。システム定義モデル（SDM）というものを使うのですが、以下のモデル図を記述することができます：

  • アプリケーション ダイアグラム
  • システム ダイアグラム
  • 論理データセンター ダイアグラム
  • 配置ダイアグラム

（その後いろいろと書いていたのですが、ブログに書くにはあまりにも膨大になりすぎたので、それらを削除してまとめて書き直したものを掲載します（＾＾；）image

モデルは、ひとつ、ひとつが独立しているようで、実はすべてが連携されています。

アプリケーション ダイアグラムでは、ここのアプリケーションとアプリケ ーションごとの固有の詳細な設定と制約を記述していきます。

システム ダイアグラムでは、システムとサブシステムなどに分割し、imageアプリケーションを整理することができます。システムの高い粒度で議論や確認をするにはアプリケーションのレベルでは細かすぎるという場合はこのダイアグラムを活用します。

この二つのダイアグラムを用いて、システムの設計を行うことができるわけです。

論理データセンター ダイアグラムでは、インフラ側の設計を行うことができます。ネットワークのゾーンとしてどのようなものがあるか、そのゾーンと他のゾーンとの間のネットワーク セキュimage リティはどのようになっているのか、サーバーはどのゾーンに格納されているのか、そのサーバーはどういう代物なのか・・・といったことをモデリングすることができます。

これにより、開発初期の段階で見落としがちな実際の稼働するインフラ環境を IT Pro と一緒になってモデル化し、確認をすることができるようになります。これで、リリース直前になって実は会社のセキュリティポリシーでその通信は許可できない・・・なんていうことが起こらなくなりますね。

ここまでだと、システム側、インフラ側のモデリングができる・・・というだけですが、さらにこれらをマッピングして、インフラ上でのシステムの配置をモデリングすることができます。それが配置ダイアグラムです。

配置ダイアグラムでは、イメージとしては、論理データセンター ダイアグラム上に個々のアプリケーションを配置していく形をとります。やることはアプリケーションを選択し、サーバー上にドラッグ＆ドロップするというだけです。

このメリットは、システム側、インフラ側での設定と制約を検証することができる点です。実際に適用したときに設定が制約にひっかかる（すなわち、そのシステムはそのインフラでは動かない）ということをモデリングの段階で知ることができるのです。

把握した上で、アプリケーションの設計を見直すべきか、はたまたインフラを拡張すべきかといった議論をすることができるわけですね。開発の初期の段階でこれらを把握し、議論し、決定しておくことは非常に重要です。一般に初期の段階で発見すべき問題をあとの段階まで放置しておくと、その修正にかかるコストは100倍以上になるといわれています。

モデルは作成したら終わりではありません。その後もアプリケーションのライフサイクルが終えるまでそのモデルは現役であり続ける必要があります。アプリケーション ダイアグラムで設計した個々のアプリケーションは、そのまま Visual Studio のプロジェクトとして実装することができます（要するに VS のプロジェクトを生成します）。個々のアプリケーションでは、使用する開発言語やフレームワーク(* VSTS 2008 新機能)、Web サービスや Web メソッドなど詳細に定義することができます。これを基にして VS プロジェクトの設定も行ってくれます。

実装に入ると、実装上の事情で設計時の想定を変更せざるを得ないこともあります。これを繰り返していくと、設計と実装が乖離していき、設計情報が過去のものになっていってしまう危険性があります。とはいえ、実装と設計の両方をメンテナンスし、手動で同期するのは非常にコストのかかる作業となります。アプリケーション ダイアグラムと VS プロジェクトは、同期がとられています。ラウンドトリップ エンジニアリングが実現できているのです。

アプリケーションの設計と実装の乖離を防ぐことができるだけではなく、開発途中でのインフラの変更などについても同様にモデルを変更し、インフラ設計とアプリケーションの実装（*実際はインフラ設計とアプリケーション設計）において不整合がないかどうかをいつでも検証できるというのは非常に価値があります。

設計と実装という異なる粒度であっても、粒度を合わせ、検証が行える環境が提供されている点はアーキテクトにとっては非常に魅力的ではないでしょうか。また、デベロッパーにとっても自分たちの作業が無駄にならないということがわかっているのとそうではないのではモチベーションもわかってきますし、実装する立場から設計やインフラに（簡単に、論理的に）提言する機会が増えることは喜ばしいことではないでしょうか。

Comments

  • Last updated on