ボーランドの.NET戦略

聞き手、文責：デジタルアドバンテージ
2003/12/25

藤井：.NETの長所の1つは、システム開発において異なる言語の混在が可能なことです。これに対しC# Builderには、DelphiとC#でボーランド独自の共通開発環境をサポートするという意味があります。前後しましたが、.NET対応版として現在開発中のDelphi 8が登場すると、C# Builderの位置づけがより明確になると思います。Delphiのみですべてを開発するケースもあるでしょうが、今後はDelphiとC＃を混在させて.NETアプリケーションを開発するケースが増えるでしょう。このようにDelphiとC＃の両方を視野に入れて開発しようとする開発者にとって、DelphiとC＃が共通のIDE（統合開発環境）でサポートされるのは非常に便利なはずです。将来的には、DelphiとC#を統合したパッケージも提供することになるでしょう。

藤井：それもありますが、C# Builderには、それ以外にもモデル指向開発支援のBorland ECO（Enterprise Core Objects） for .NETを提供すること、豊富なデータベース・アクセス機能を提供することが特徴として挙げられます。

奥村：BDP（Borland Data Provider） for ADO.NETです。これは特定のデータベースに依存しない共通のデータベース・アクセス・インターフェイスを提供するデータ・アクセス・コンポーネントです。.NETアプリケーションから、プログラムを変更することなくMicrosoft SQL ServerやOracle、IBM DB2、Borland InterBaseなどの主要なデータベースにアクセスできます。.NETアプリケーションに対して、自由なデータベースの選択肢を与えることになります。

藤井：IDEの操作性という意味ではよく似いています。しかしJavaと.NETでは文化的に大きく異なる部分があると感じています。これは個人的な意見ですが、Javaはメインフレームやオフコン的な流れを汲んでおり、背後に流れる思想が.NETとは異なっていると思います。これが正しいとすれば、Java流の考え方を無理やり.NETに当てはめることには無理があります。こうした違いを開発環境が吸収するというのは理想ではありますが、開発手順や考え方を隠蔽してしまい、思想の異なるもの同士を統合しようとすると、かえって混乱を招くのではないかと思います。

藤井：現在、C++ Builderでは、組み込み分野に大きくフォーカスしています。.NET対応は検討課題ではありますが、C++ Builderについては、当面は各ハードウェアの性能を最大限に引き出すネイティブ・コード開発の生産性をいかに向上させるかという点に集中していきます。

藤井：これは大きく2つに分かれます。1つは、バックエンドのデータベースにアクセスするフロントエンド・アプリケーション開発用のRADツールとして使われるケースです。データベースにアクセスするためのちょっとしたユーザー・インターフェイスを設計するといった場合で、専門の開発者だけでなく、エンド・ユーザーが簡便な開発ツールとしてDelphiを利用しているケースが少なくありません。

　もう1つは、パッケージ・アプリケーション開発分野です。これには実際にパッケージとして販売されるソフトウェアだけでなく、受託開発会社が、自社のソリューションをある程度パッケージ化して展開するというケースにDelphiが使われています。さまざまな機能をDelphiのコンポーネントとして開発しておき、それらを組み合わせてカスタマイズしたRADツールとして活用するというものです。RADツールとしてはVisual Basicも利用可能ですが、VBと比較するとDelphiではネイティブな処理が容易です。またVBとは異なり、Delphiで開発したアプリケーションは、ランタイムなしでも実行が可能という特徴があります。企業ユーザーの中には、「Delphiはランタイムが不要なのでクライアント・ソフトのメンテナンスが容易だ」という理由からDelphiを採用しているケースもあります。

藤井：そうです。

藤井：マイクロソフトの開発環境であるVS.NET 2003に追加インストールすることでUMLベースのモデリング機能を提供するツールです。

藤井：はい。設計フェーズと開発フェーズの双方を支援するツールになっています。多くの場合、ソフトウェアの設計フェーズでは、ホワイト・ボードや付箋、WordやPowerPointなどといったツールを思い思いに使って仕様を検討します。UMLツールを利用して開発を進めるなどはまだ一握りでしょう。設計フェーズだけを考えれば、ホワイト・ボードや付箋でも問題はないかもしれません。しかし開発が一通り進んで、一度見直すフェーズに入ると、設計フェーズの決定が本当に正しかったかどうかを振り返る必要が生じるものです。また、当初は予定していなかった機能追加なども発生してきます。この場合に、もう一度過去のホワイト・ボードでの議論や付箋作業に戻って再検討するというのは現実的ではありません。Together for VS.NETは、こうした設計フェーズと開発フェーズの行き来を容易にするツールです。具体的には、UMLベースのクラス図と、コードの間を自由に行き来できるようになります。

奥村：Together for VS.NETは、ソースコードをよりどころとしてクラス図を表示します。図の配置や色情報などといった図のレイアウトに関する情報は別にあるのですが、クラス図にどういう項目があり、それがどういう値を持っているかという構成要素はすべてソースコードとして保存され、クラス図はこのソースコードから生成されます。中間的な情報ファイルなどは一切ありません。これがモデル図とコードの同期を保証するボーランド独自のLiveSourceと呼ばれる技術です。

奥村：そうです。LiveSourceで重要なのは、ソースコードさえあればよいということです。Together for VS.NETを購入してからモデル設計を開始するという必要はありません。ソースコードさえあれば、Together for VS.NETによって即モデル指向の開発が可能になる。最初から作り直す必要はありません。またモデル指向開発に移行した後でも、クラス図を手直しするよりソースコードを直すほうが簡単ならば、ソースコードを修正すればよいのです。もちろん、クラスの構成を変更したり、デザイン・パターンを適用したりする場合はクラス図で作業します。この場合でもすべての修正はソースコードに同期されます。