連載：熱血VBプログラマ応援団 最終回 VBプログラマにとってのUML ―　VB.NETでもコーディングの方法は文字だけではない　― 株式会社ピーデー 川俣 晶 2004/09/15
Page1 Page2

Visioでビジュアル・プログラミング

　もう1つ、VS.NETとVisioを使うと、面白いことができます。Visio上でプログラミングができるのです。

　試しに、「猫」クラスに、「集会に行く」メソッドを追加してみましょう。まず、クラス図上の「猫」クラスをダブルクリックして、プロパティ・ダイアログボックスを開きます。そして、［カテゴリ］から「操作」を選び、［新規］ボタンをクリックします。

UMLクラス・プロパティで「操作」を新規作成

　さらに［プロパティ］ボタンをクリックし、名前を「集会に行く」に書き換えます。

UML操作プロパティで「操作」の名前を変更

　次に［カテゴリ］の中から「メソッド」を選び、メソッドの本体の欄にコードを書き込みます。

「集会に行く」メソッドの本体を記述

　［OK］ボタンを2回押してダイアログ・ボックスを閉じます。すると以下のように「猫」クラスのメソッドが追加されていることが分かります。

「猫」クラスの図に追加された「集会に行く」メソッド

　次に、［UML］−［コード］−［生成］とメニューを選び、生成ダイアログ・ボックスを表示させます。そして、右側のツリーから「猫」クラスをチェックし［OK］ボタンをクリックします。

ソース・コードの生成ダイアログ

　すると、プロジェクトの下位のディレクトリに「猫.vb」というファイルが生成されています。この内容は以下のようになります。

' 静的モデル Imports 最上位パッケージ.Test001 Namespace Test001   Public Class 猫      Inherits 動物     Public Overrides Sub 鳴かせる ()     End Sub     Public Sub 集会に行く ()       Console.WriteLine("集会に行く")     End Sub   End Class ' END CLASS DEFINITION 猫 End Namespace ' Test001

生成された「猫.vb」ファイル

　見てのとおり、「集会に行く」メソッドが、内容を含めて、自動的に生成されています。このように、Visio上でクラス図を対象にメソッドを追加したり、その内容を記述したりすることができます。

　しかし、Visio上で書き込んだメソッドの内容は生成されているのに対して、UMLを生成する基となったクラスの内容はここにはありません。UMLの生成時に引き継がれていないためです。このように現在のVS.NETとVisioの組み合わせでは、まだ使いやすいとはいいにくい粗削りなものですが、次期VS.NETであるVisual Studio 2005では、より使いやすく強力な機能が提供されるようです。Visual Studio 2005では、クラス図とソース・コードを往復しながら、作業内容によって最適な方を使ってプログラムを組み立てていく、といった方法も取れるようになるでしょう。そして、そのような開発スタイルを行うためのプログラム言語として、VBも視野に入っているということです。VBにも、このような未来への道があり得ることを知っておくことは、価値があるでしょう。

UMLの本来の位置付け

　とはいえ、クラス図をこのような目的で使用するのは、UMLの本筋とは外れた使い方です。以下は、私の専門外の話題なので、間違いがあればご容赦を願います。

　UMLは、UP（Unified Process：統一プロセス）という開発プロセス手法の中で、モデリング言語として位置付けられています。UPはプログラムを開発するための始まりから終わりまでの手順について定めたものです。この手順に沿って作業を行う際に、プログラムの構造をモデルと呼ばれる形で記述するモデリングという作業を行うためのダイアグラムとしてUMLは用いられます（もちろん、UP以外の開発プロセスでもUMLはよく利用されています）。

　そして、この一連の手順に最適なプログラム言語としてJavaがあります。UP→UML→Javaという流れが、オブジェクト指向開発の1つの理想型といってよいかもしれません。しかしながら、このような流れの中に、VBはあまりきれいに収まってはくれません。例えば、UMLのクラス図でVB.NETのプロパティがそのまま扱えない（Visioではメソッドと同じ「操作」として扱う）といった問題は、まさにVBがUP→UML→Javaという流れの外側にあるために起こった非互換性であるといえます。

　しかし、そこでVBはもうダメでJavaに乗り換えねばならないのか、と悲観する必要はないと思います。そもそも、UPは開発プロセスの1つにすぎず、ほかにもいろいろなやり方があり得ます。それを絶対不動の自明の前提などと思う必要はありません。必然的に、UMLも絶対ではありません。

　また、UPやUMLといったオブジェクト指向技術が開発されるモチベーションとして、大規模で複雑なプログラムの開発に対処したい、という願いがあることも見落としてはならないと思います。

　一般論として、この世の中の多くのものは、規模が変われば性質も変わります。大規模で複雑なシステムのために考えられた技術が、小規模なシステムでも最善であるとは限りません。むしろ、同じではないのが当然と思うのが、理性的な態度というものだと思います。その点から考えれば、何が何でもUMLを使わねばならないと考えるのではなく、小規模なシステムを開発するのであれば、もっと別のやり方（例えば、標準でモデリングの手順を含まないエクストリーム・プログラミングなど）もある、と考えるのも1つの態度ではないかと思います。そして、何百人何千人のプログラマが規律正しく働く大規模開発というよりは、もっと少ない人数でフットワーク軽く顧客のニーズにきめ細かく対応していく小規模開発の方が、VBには似合っているように私は思います。

連載の終わりに

　この連載を終えるに当たって、VBプログラマの皆さんに向けて、最後に書いておきたいことがあります。それはVBの正しさを信じることの重要性です。

　例えば、UPは1つの正義ではありますが、VBが不正義というわけではありません。VBも、長い歴史の中で、言語仕様を積み重ねて進化してきた言語ですから、歴史に裏打ちされた正しさを持ちます。これも一種の正義です。正義と正義が相互に互換性を持つとは限らないことは、お互いに正義を名乗りながら戦争することが歴史上に多くあることからも明らかでしょう。すべての正義が共存できないことは、この世界のごく普通の特徴にすぎません。だから、異なる正義を標ぼうする勢力から、自らの正義と互換性がないという理由でVBは不正義であると主張されたとしても、その言葉をそのまま受け取る必要などありません。

　それよりも重要なことは、VBに込められた潜在的な力を、より的確に引き出して解放してやることです。いかにVBは正しいと主張したところで、使い方が間違っていれば、良い結果は得られません。

　そして、最も強調しなければならないことは、潜在的な力を引き出し、可能性を開花させるだけの価値がVBにはあると私は信じている、ということです。

　だからこそ、以下のような言葉を堂々と書くことができるわけです。

　頑張れVBプログラマ、君たちが使うVisual Basic .NETは取り組む価値のある可能性に満ちたプログラム言語だ！

INDEX
	［連載］熱血VBプログラマ応援団
	最終回 VBプログラマにとってのUML
	1．プログラムを図で表現することの是非
	2．Visioでビジュアル・プログラミング

　

「熱血VBプログラマ応援団」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）