Compartir a través de

PDC 2008 3rd day

  • Artículo

昨日はレポートできませんでした（＾＾； ですので、本日に二日分まとめて！（と思ったのですが、3日目だけで結構なボリュームになったので、3日目だけにしました・・・）

まず、昨日レポートできなかったのはなぜかというと・・・・

"Oslo" と "Rosario" で遊んでいたから!!

でした（＾＾;)

遊んでいたといっても、本当に遊んでいたわけではなく、日本から PDC へご参加くださっている皆さんへのラップアップを最終日の PDC 終了後に行う予定があり、その準備も兼ねてです。

ですが、そんなことを忘れて（本当に忘れたわけではもちろんありませんが）、楽しんでいました。気がついたら朝の4時をまわっており・・・ということで、本日は寝不足な中、最終日のセッションを受講しまくったわけです（＾＾；

さて、本題に入りましょう♪ まずは、3日目です。参加したセッションは以下です：

  • TL37: Microsoft Visual Studio Team System: Leveraging Virtualization to Improve Code Quality with Team Lab
  • TL18: "Oslo": Customizing and Extending the Visual Design Experience
  • TL28: "Oslo": Repository and Models
  • TL15: Architecture without Big Design Up Front

ということで、結果的にも、"Oslo" と "Rosario" だったわけです（＾＾；

Codename "Team Lab" は本当に画期的な試みになります。"Rosario" からは Codename "Camano" と呼ばれていた包括的なテスト管理が盛り込まれ、Team Foundation Server と統合することで、テストケースの管理から、テスト実施のナビゲーション、テスト中の合否やテスト実施の記録（WMVで録画および、システム環境のロギングなど）も自動で行えるものですが、"Team Lab" を用いることで、ここに仮想化技術を用いたテスト環境の構築（もちろんテストのデプロイも含まれます）、そしてテストの実施、実施後の環境の破棄までがほぼ自動で行えます。

テスト環境の構築やその維持管理は非常に負担となりますし、物理環境ですべてを用意することはなかなかできません。そのあたりを System Center Operations Manager、System Center Virtual Machine Manager のエッセンスも含め Hyper-V、VMWare ESX の仮想化技術を活用し、実現できるものだと思ってください。

開発者とテスト担当者の間で、バグのやりとりが滞ったり、お互いに牽制しあったりすることはよくありますが、これだけのインフラが整えば、お互いに協調も、適確で、ロジカルな主張、客観的な状況把握も行えるようになります。

実にすばらしいソリューションです！ただ残念なのは、今回公開された CTP には含まれていないということです（これだけの規模のものですから当然と言えば当然かもしれません）。ちなみに、デモでは BOX型のデスクトップPCで実施を行っていました。

"Rosario" 関連では、最終セッションで Architecture の話を見てきました。こちらは Visuao Studio 2010 で目玉の一つにも挙げられていた Architecture Explorer と UML サポートが中心の話題になります。

Architecture Explorer は、すでにある資産に対し、そのアーキテクチャを可視化し、把握できるようにするものです。ソリューションと各プロジェクトの依存関係や、各クラスの依存関係などが動的に（そのつど解析されるという意味）把握可能になると思ってください。表現方法もいろいろと変えることができます。オブジェクト間の依存関係の線での表現から、依存関係をマトリックス上に表現するなどができます。

そのほか、アプリケーションのレイヤーを可視化する機能や、TFS との組み合わせで、アーキテクチャとバグやタスクの関係、テストとの関係なども見ることができます。

UML のサポートでは、主要なダイアグラムをサポートする予定ですが、その目的は、「考える手段」であると言っていいでしょう。問題領域が特定できていない段階や抽象度が高い段階での洗い出し、明確化を行う際には、標準の表記法である UML は非常に有効です。その反面、問題領域が特定されば場合は、その汎用性が逆に足かせとなり、粒度や曖昧性がでてきてしまう恐れがでてきます。

したがって、問題領域を明確化する、共通で議論できるところまでの落とし込みをするとったところで UML を活用し、問題領域が明確になったら、DSL で・・・これがマイクロソフトが考えているアプローチでしょう。

なので、UML のクラス図から、コード生成（フォワードエンジニアリング）の機能はないようです。Visual Studio には クラスダイアグラムという（名前がややこしいですが） DSL があります。これは .NET の型情報を可視化するためのものになります。この２つの関係は、ちょうど、 MDA でいうところの、PIM（プラットフォーム非依存のモデル）と PSM（プラットフォーム依存のモデル）に近い関係ではないでしょうか？

となると UML のクラス図から、クラスダイアグラム（.NET 型）のトランスフォームができるといいですね。UML のダイアグラムだからといって特別なテクノロジーを用意しているわけではなく、DSL Tools でしょうから、モデル to モデルも十分に可能でしょう。ただし、問題領域が特定できたら、手動でも DSL を書くのはそんなに煩雑でもないのでよしと考えるのもありかもしれません。ただし、トレーサビリティ（追跡可能性）が確保できないとなると変更時の影響範囲や、実装のカバレッジなどに影響します。

また、UML のシーケンス図については様相が変わってきます。というのは、実際のソースコードからシーケンス図を生成できるからです。特定のメソッドなどを指定し、シーケンス図を生成すれば、そのオブジェクトから他のオブジェクト（対象とするカバー範囲も設定できます）へのメッセージのやりとりを可視化してくれます。

セッション時にも言っていましたが、これはテスト駆動開発を実践しているときにも力を発揮します。単体テストのコードからシーケンス図を生成すれば、当然テスト対象のメソッドの動きを可視化して、把握することができるというわけです。コード カバレッジでは、通ったことはわかりますが、どう通ったのか（何回も通っているのか、それはどの順番だったのか、1回目と2回目ではルートが同じなのか異なるのか）までは、わかりません。非常に有効な手立てとなるでしょう。

さてさて、"Oslo" についてですが、最終日のセッションも合わせて、私は、5セッションすべて参加しました。"Oslo" を新しいモデリングであり、"M" Language を新しい言語として単純に関心をもっている方が結構多いと思いますが、私は、“懐疑的な” 視点でカバーをしました。というのは、"Oslo" はモデル駆動のためのエンジンであり、実現方法でしかないからです。"Oslo" ですべてが解決するわけではなく、"Oslo" を用いてどのような DSL を提起し、活用するかにかかっていると思っています。したがって、マイクロソフトだけですべての DSL を提供することは不可能なため、マイクロソフトにしかできないものは MS で、それ以外の大部分のものは皆さんで準備をする必要がると思っています。こう考えてください。皆さんのお客様とシステム化の範囲や仕様を詰めていく時に、業務要件や、課題などを洗い出していきます。たとえば、非機能要件などいいと思いますが、こうしたいああしたいをまとめる必要があり、それは人によって、または、話している時間によって異なってしまうかもしれません。そういった特定の問題領域（この例だとお客様へのヒアリングかな？）においてモデル化を行い、意思疎通を行う、そして、そこからなんらかの成果をトランスフォームすることで、開発や配置、管理に活かすという感じです。

したがって、"Oslo" により先に挙げた、UML と DSL、PIM と PSM のトランスフォームが可能になるかもしれません（というか理論上はどんなものも可能なはずです）。

"Oslo" は、モデル駆動でアプリケーションの開発、配置、運用を定義実践するためのプラットフォームであるということができます。そう、開発だけではないんです。

非常に面白いですので、皆さんもこれらの活かし方をエンジニアの視点とビジネスの視点で妄想してみてください(^^)

 

ながさわともはる

Comments