連載:熱血VBプログラマ応援団


最終回 VBプログラマにとってのUML

―― VB.NETでもコーディングの方法は文字だけではない ――

株式会社ピーデー 川俣 晶
2004/09/15
Page1 Page2

− 今回のご相談 −

 これまでずっとVBで業務ソフト開発をしていましたが、最近になって、小さな悩みと大きな悩みが出てきました。小さな悩みというのは、VBで開発をしています、というとアンチウイルス・ソフトを開発しているのですか、といわれることがあるのです。どうも、アンチウイルス・ソフトの中で、略すと「VB」となる製品があって、それと間違われているようです。そのため、時々ウイルス被害についての質問の電話がかかってきて対応に困ることがあります。とはいえ、これはよく説明すれば済むことなので、大したことはありません。

 もう1つの大きな悩みとは、お客さんの側からしばしばUMLという言葉が出てくることです。しかし、UMLは使ったことがなく、使えるプログラマもいません。この前は、提出するドキュメントにUMLのクラス図を入れてくれ、といわれて、その要求を取り下げてもらうのに苦労しました。しかし、世間ではUMLに対する注目度は高いようです。これからは、UMLに対する要求も増えてくるのではないかと心配しています。

 それならUMLを勉強すればよいではないか、といわれそうですが、どうもあの手の図表はいまひとつ信用ができません。昔、フローチャートをまじめにたくさん描いたことがありますが、手間がかかっただけであまり有益な結果が得られなかったからです。それ以来、プログラムを図で表現する方法でうまくいったという話は聞いたことがありません。それなのに、UMLだけが成功するとも思えません。

 それに加えて、VBでUMLという話はあまり聞きません。UMLの話題はJava関係であることが多いように思います。もし、UMLがJavaの技術であるなら、われわれは関係がないといって押し通せそうな気がしますが、かといって、UMLができないためにJavaプログラマに仕事を取られてしまうのも面白くありません。

 果たして、VBプログラマとしては、UMLとどう向き合うべきなのでしょうか。

13日のV曜日 より

プログラムを図で表現することの是非

 まず小さな悩みの方から。あのアンチウイルス・ソフトの存在は悩ましいですね。私も「VBが……」という話題が出ると、思わずハッと見てしまいます。しかし、最近ではわれわれの愛するVisual Basicの話題ではないことが増えました。少し悲しいことですね。ですが、それはここでは重要な問題ではありませんね。もう1つの悩みの方に話を進めましょう。

 プログラムを図で表現する方法としては、フローチャートが最も有名でしょう。本来、プログラム開発のための図ではありますが、一般生活でも使われることが多くあります。例えば、条件によって変わる行動手順を描くには、割と便利といえます。

フローチャートの例(本来のフローチャートとしては不正確)

 しかし、プログラム開発の現場では、フローチャートはあまり有効とは見なされておらず、それに代わるべきさまざまなチャートが提案されています。構造化チャート、PAD、NSチャートなどがそれに当たります。私個人としては、構造化チャートを少し描いたことがありますが、いまひとつ有効ではなく、すぐにやめてしまった記憶があります。それ以降、私も同じようにプログラムを図示する方法に興味を持つことはなくなりました。

 なぜプログラムは文字で書けばうまく機能するのに、図示しようとするとうまく機能しない(かのように見える)のでしょうか。その理由はいろいろ考えられます。例えば、文字で書いたソース・コードは実行できるが、図は実行できない、という相違があります。人間とは間違いを犯す存在ですから、書いたものが完全無欠だなどということはあり得ません。ソース・コードは、実際にビルドして実行させることで、意図どおりに動作するかを検証することができます。しかし、フローチャートのような図は、一度ソース・コードに書き下ろしてからでなければ実行させることができません。もし実行させて誤りが発見された場合、フローチャートを手直ししてからソース・コードも手直しするという2重の手間が発生します。さらに悪いことは、手直しの手順にミスがあると、フローチャートの内容と、ソース・コードの内容が食い違う状況も発生します。それを考えると、フローチャートは描かないで、その分だけソース・コードを分かりやすく書くようにしよう、という考え方も説得力を持ちます。

 このような考え方は、現在でも1つの有力な選択肢として残っています。例えば、テスト駆動開発(Test-driven Development)では、追加すべき機能や作業項目を記したToDoリストから単体テストのソース・コードが生成され、そこから作成すべきプログラム本体のソース・コードが記述され、最後にリファクタリング(ソース・コードの整理)されてプログラムの構造が確定します。あらかじめ、プログラムの構造についての事前の決定は行われておらず、リファクタリングの結果によって構造は確定します。そこには図示されるチャート類の入り込む場所はありません。異論のある方はいらっしゃると思いますが、テスト駆動開発は(詳細な設計のために)図を使わないことが最善であるという思想による1つの開発方法論だと思います。

 しかし、文字がよく、図はまったくダメである、という結論は筋が通りません。文字で表現するか、図で表現するかは、単なる表現方法の違いにすぎません。表現される内容が同等であれば、文字であろうと図であろうと、有意義な結果が得られるのではないか、と考えることは間違いではないはずです。文字の優位性、つまりソース・コードの優位性とは、文字だから優れているという話ではなく、たまたま文字で書くと実行が容易だったにすぎないと考えることもできるはずです。そして、内容によっては、文字で見るよりも図で見た方が分かりやすいケースもあるはずです。

Visual Studio .NET+Visioでクラス図作成

 ここで話題を変えましょう。実は、Visual Studio 2003 Enterprise Architects(以下、VS.NET)とVisio for Enterprise Architects(以下、Visio)を使うと、既存のソース・コードに対応するUMLのクラス図を簡単に生成することができます。UMLの知識は要りません。例えば、本連載第11回「継承とは隠された条件判断である」のサンプル・ソース(動物、犬、猫、ホトトギスの各クラスを持つ)から、クラス図を生成してみましょう。

 まず、目的のソース・コードを含むソリューションをVS.NETで開きます。

 そして、[プロジェクト]−[Visio UML]−[リバース エンジニアリング]とメニューをたどります。ファイル選択のダイアログ・ボックスが出ますが、そのまま保存ボタンをクリックします。すると、ソース・コードが解析され、Visioが起動します。

VS.NETから起動したVisioの画面

 この状態では、図を描く領域には何も存在していません。しかし、ウィンドウ左下の「モデル・エクスプローラ」を見ると、ソース・コードに含まれるクラスなどの名前が見えます。そこで、モデル・エクスプローラの「動物」という名前をウィンドウ右側のグリッド線の入った白紙部分にドラッグしてみましょう。

自動作成された「動物」クラスのクラス図

 これだけで、クラス名とメソッド名の入ったクラスについての図が作られました。UMLの知識は必要ありません。さらに「犬」も同じようにドラッグしてみましょう。

クラス図に「犬」クラスを追加

 ここで注目すべきは、「犬」クラスから「動物」クラスに向かって引かれた矢印です。これはジェネラリゼーション(汎化)と呼ばれる、クラス間のリレーションシップ(関係)を示すもので、具体的には継承関係を示しています。リレーションシップ(関係)にはいくつかの種類があり、矢印の書き方が異なります。しかし、ここではそのような知識はまったく必要とされていません。ただ単に、「犬」をドラッグしただけで、すでに書き込まれた「動物」との関係がソース・コードから自動的に判定され、適切な矢印が自動的に補われています。

 同様に、「猫」「ホトトギス」もドラッグしてみましょう。

クラス図に「猫」クラスと「ホトトギス」クラスを追加

 この4つのクラスのリレーションシップ(関係)は、すべて自動的に判定され、適切な線が引かれました。これで、取りあえずこの4つのクラスに関する最低限のクラス図は完成です。

 このような機能がすでにあることから、単純に既存のソース・コードからクラス図を作成することは、さほど大きな問題ではないといえると思います。

 しかし、クラス図をUMLの知識なしで作れてよかったね、ということで話は終わりではありません。このクラス図と、基になった以下のソース・コードを見比べてみてください。どんな感想を持つでしょうか。

MustInherit Class 動物
  Public MustOverride Sub 鳴かせる()
End Class

Class 犬
  Inherits 動物
  Public Overrides Sub 鳴かせる()
    Console.WriteLine("ワン")
  End Sub
End Class

Class 猫
  Inherits 動物
  Public Overrides Sub 鳴かせる()
    Console.WriteLine("ニャア")
  End Sub
End Class

Class ホトトギス
  Inherits 動物
  Public Overrides Sub 鳴かせる()
    Console.WriteLine("テッペンカケタカ")
  End Sub
End Class
基になったソース・コード

 この2つを比較すると、クラス図の方がクラスの関係が分かりやすい、といえると思います。例えば、開発中のプログラムについて、プロジェクト・メンバーを集めてソース・コードのレビューをやろうという状況のとき、ソース・コードしかない状況と、このようにして作成されたクラス図もある状況を比較してみるとどうでしょうか。もし、クラス図がなければ、これから検討しようとするソース・コードの全体構造をよく把握していないメンバーは、膨大な文字の羅列から構造を把握しようとして多くの文字を読む必要に迫られます。しかし、クラス図があれば、まずクラスの関係を図から直感的に把握することができます。それによって、どの機能がどのクラスにより実装されているかを容易に把握したうえで、ソース・コードに取り組むことができます。

 実は、このようなソース・コードをいつもと違った見せ方で見せるという技術には、重要な意味があると私は考えています。例えば、まだコンピュータが高価だったころ、ソース・コードは必ずプリントアウトするという人たちが珍しくありませんでした。プリントアウトする理由の1つに、画面で見ても気付かない誤字をプリントアウトだと見つけられることがある、といった人がいました。同じようなことは、出版業界の人からも聞いたことがあります。画面で見て気付かない誤りを、プリントアウトでは見つけられるからプリントアウトするといいます。

 ただ単にプリントアウトするだけでも効能があるわけですから、もっと大胆に、違う表現形式に変換することも有効ではないかと考えています。例えば、ここで紹介しているように、ソース・コードからクラス図を生成してみる、というただそれだけの試みからも、ソース・コードを見るだけでは気付かなかった何かに気付くことができるチャンスがあるのではないかと思うわけです。

 

 INDEX
  [連載]熱血VBプログラマ応援団
  最終回 VBプログラマにとってのUML
  1.プログラムを図で表現することの是非
    2.Visioでビジュアル・プログラミング
 
インデックス・ページヘ  「熱血VBプログラマ応援団」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

注目のテーマ

業務アプリInsider 記事ランキング

本日 月間
ソリューションFLASH