UMLは何でないか

UMLの誤解の多くは、ソフトウェア開発論すらよく知らない人に「UMLは何かす ごいらしい」と喧伝した事に端を発します。そして「UMLを使ったソフトウェ ア開発」と題して素晴らしい開発事例を紹介した事にあります。それらのほと んどは「ソフトウェア開発論」の成果なのであって、UMLの成果ではありませ ん。本当はUMLを学ぶ前にその土台について学ばなければならないのです。

UMLを使ってもオブジェクト指向開発はできない

最近「UMLで学ぶオブジェクト開発」というタイトルの本をよく見かけますが、 これのほとんどは本質を間違えています。UMLを使ってもオブジェクト指向 開発はできません。オブジェクト指向開発をする時に、表現方法としてUMLを 使うとというだけです。つまり目的と手段を取り違えているのです。

例えば「良い文章を書くときには句読点が少なすぎたり多すぎたりしないよう にしましょう」とか「ですます調かである調のどちらかに統一しましょう」と 言われたとしましょう。これは間違ってはいません。ただしこれらの注意点を 守っていれば良い文章かというとそんな事はありません。良い文章のための最 重要事項は「内容が良い」という事であって、文章の書き方というのは良い内 容を悪くしないために出来ることでしかありません。

UMLも同様です。オブジェクト指向で考えられた良いモデルはUMLによくマッチ し簡潔できれいに記述できます。しかし、こうした「良いモデルの作り方」は UMLを勉強しただけではわからないのです。

UMLを使っても従来の方法より簡単に開発はできない

UMLを使うと従来の方法より効率が落ちる時もあります。なぜなら、従来なら 手書きで適当に書いてきた図をUMLでどうやって書けばいいのか調べなければ ならないからです。書き方が全部頭の中に入った後でなら従来よりスムーズに 開発ができるようになるかもしれません。しかし、それまでは相当の苦労が必 要です。

これもまたUMLとオブジェクト指向開発を同一視した人がやりそうな発言です。 オブジェクト指向開発は確かに有効です。しかしそれとUMLとはまた別の話な のです。UMLはオブジェクト指向開発の道具にすぎないのですから。

UMLはプログラミング言語の代替ではない

見やすい図で表記されることから「UMLは簡単」というイメージが広まり、そ れに付随して「プログラミング言語は時代遅れでこれからはUMLだ」という意 識が広まり始めているような気がします。これは間違いです。UMLは単なる図 で、プログラミング言語とは目的が違うものなのです。

UMLは様々な記法を用意していますから、その気になればプログラミング言語 と同様の細かい記述をすることができます。しかしUMLはそのために作られて いるのではありません。だから、それをしようとするとプログラミング言語で 直接プログラムを作るよりずっと大変でわかりにくいものになってしまいます。

昔、あの悪名高い「フローチャート」がもてはやされた事を覚えているでしょ うか。フローチャートはプログラムが読めない人には人気がありましたが、プ ログラムが書ける人はこれを嫌いました。なぜならプログラムそのものの方が 見易かったからです。今ではさすがに「フローチャートを書け」なんて強制す る人はいないでしょうが、「プログラムをやめてUMLで書け」というのはこれ と同じ轍を踏むことになります。 ^[1]

まず、なぜプログラミング言語を使いたくないのかを考えてみて下さい。そし てその理由はおそらく自分がプログラミングできないからでしょう。要するに 単なる勉強不足なのです。自分ができないからといって人にもそれを押しつけ ないで下さい。プログラミングはあなたが思っているよりずっと簡単なのです。 本当に難しいのは「プログラミング」ではなく「設計」なのですから。

UMLでプログラミングレス開発はできない

これは言葉の矛盾です。プログラミングをしないでプログラムを作ることはで きません。なぜならプログラミングとはすなわちプログラムを作る事なのです から。

こういう事を言う人は、「プログラミング言語=C++・Java・Visual Basic」だ と、つまりプログラミング言語にはこれしかないと思っています。これはとん でもない誤解です。世の中にはPrologとかLispといった、思想的にも構造的に もC言語などとは一線を画した言語がたくさん存在します。プログラムを作る ための言語はすべてプログラミング言語なのです。そして、UMLだけでもしプ ログラムが作成できるとすれば、UMLもまたプログラミング言語の仲間入りを するというだけの事なのです。

プログラムコードの自動生成について

UMLのアクティビティー図などを駆使すればできない話ではありません。しか しそれより直にプログラムコードを書いた方がずっと速くて確実です。 UMLはそもそも分析や設計のための図であり、プログラムを書くための図では ありません。だから、そこにプログラムを生成するだけの全情報を盛り込もう とするとどうしても無理が出てきてしまいます。

ただ、UML図からクラス定義やメソッド定義などのスケルトンを自動生成 することはできます。それでもそれぞれのメソッドの中の動作についてはやっ ぱりプログラムを書く必要があります。それはツールの能力が足りないのでは なく、メソッドの中身はプログラムコードで記述するのが一番いいからなので す。

何より問題なのは、UMLの図が「プログラムコードの自動生成のための 図」になってしまうことです。そもそもUMLは「システムの分析や設計のため の図」です。特にシステム分析では、とりあえず設計の事は忘れてシステムの 仕様についてだけを考えることが必要になってきます。だから、システム分析 の結果がすぐプログラムコードになるのは本当は間違っているのです。本当は その間に「設計」という工程が入るはずのものですから。これができてしまう のは、「分析」という工程の中に「設計」が知らず知らずのうちに入ってきて しまっているからに他なりません。

「UMLという図さえ書けば設計もプログラミングも何もせずにポンと完成品が 出来てきますよ」というのは謳い文句としては素晴しいですが、実際はこれは 従来通りの悪い開発スタイルです。複雑なシステムの設計を一度に全部解決 するような夢の手法なんてないのです。何でもかんでも一度にやるのではなく 問題を区切って徐々に解決するというのが結局のところ一番の近道なのです。

プログラムコードの自動生成技術はうまく使えば便利な道具になります。しか しその意味もわからないままそれに頼ってはいけません。道具はどう使うかが 重要なのです。そして、重要なことはコードがどう生成されるかよりソフトの 分析や設計の方がずっと大事だということです。