別案
「UML は間違っている?!」
…と、興味を引きそうなコピーで始めてみる。まあ、読んでがっかりされるかもしれないけれど…。
「すべてのダイアグラムを覚える必要はない。」「クラス図がもっとも重要。」などの記述が UML 関係の入門記事によく書かれている。私もすっかりそう思っていたのだが、もしかしたら、間違っているんぢゃなかろうか? …と思ったのだ。まあ、OMG がなんと言っているかは知らないけどね。
「結局は整理術なんだよ。」と、一言で片づけてしまいたいところだけれども、頑張って説明してみる。
構造化プログラミングにせよ、オブジェクト指向にせよ、どれが偉いとか優れているかはさておき、結局のところ、どーゆーふーに整理してやれば、理解しやすいだろうか? と云う問題のアプローチの一つな訳だ。で、整理と云えば本棚だ。大掃除とか模様替えとかでもいいんだけどね。
本棚を効率よく整理しようと思えば、一冊、一冊の本をこまめに整理しては埒が明かない。普通は、先に大ざっぱに分類してしまう。「こっちの本棚は漫画置き場に使って、あっちの本棚は IT 関係に使って、真ん中の本棚には小説なんかの一般的なヤツにしよう。おっと、えっちなヤツは百科事典の裏に…。」のような感じで棚を決め、まずは大ざっぱな分類で本を分けてしまう。それが終わってから、見やすいように棚に片づけて行くのだ。だよね? 普通だよね? …まあ、そんなに大量に本を持ってないって人は、紀伊国屋の入庫のバイトでもしてみてくれ。
で、UML の話なんだけれども、本棚をダイアグラム、一つ一つの記号を本に割り当ててみると、クラス図にフォーカスしているのは、一つの本棚に向かってモクモクと片づけをしている作業みたいなもんだ。後ろを振り返ると、片づけられていない本が部屋に散乱している訳だな。片づけなければならない本は他にもいろいろあるとのに…。すなわち、クラス図以外に関わる情報がたくさんあふれてるってことだ。先にそいつらを、大まかに分類して、片づけ先の指標を作った方がいいんぢゃない? と云うことだ。後ろにちらばっている本も少しは整理できて、マシな状態になるし、他の棚の事は友だちに手伝ってもらうこともできるようになる。だろ?
「そうは言っても UML の全部は覚えられないよ~」と言うのはごもっとも。で、記号を覚えるのは後でいいんぢゃん、と割り切ってみる。まずは、ダイアグラムの種類と、そこに何を入れるのか、にだけフォーカスする。図は描けなくて構わないけれど、概念だけは明確に分離しておきたいってことだ。
で、システム開発を進めて行く中で、顧客から訊き出したことを、ダイアグラムの中に入れて行く。図は誰かに描いてもらうとして、メモ書きで十分。「この話は使い方の話しっぽいなぁ…。じゃ、ユースケース図にメモしておこう。えーと、管理する項目の名前はクラス図方面で…。ふむふむ、なんか状態図にメモるのが良さそうな話をしているなぁ…。おや、配置図は空っぽだぞ。これは、訊き出せてないことがあるに違いない。」みたいな感じ。
けっこう有効な手法ではないだろうか? 「UML を描けなくて何が有効なんだ?」と思われたかもしれないけれども、それは「どの問題を解決しようとしているか?」が異なるからかもしれない。
私が解決したいのはこんなこと。
精度と正確さは同じではありません。「πは 4.141592 である」と言ったときには、精度はとても高くなっています。しかし、それは正確さからは非常にかけ離れたものであり、不正確です。「πは 3 ぐらいである」と言うと、精度はあまり高くありません (桁数が少ない) が、言われていることについては正確です。*1
UML は、記号を覚えたら描けると云うものではなく、それなりのトレーニングの積み重ねと適性が求められる。そうでなければ、表現が不正確で精度だけが上がって行ったりして、本来の意図とは違うものを含めてしまったり、あるいはかえって混乱を招く虞もある。…ってか、混乱する。だから、いっそ未熟なうちは描かないか、もしくは描く根拠となったネタを残しておくのが吉かな。これが一点。
それから、UML は学習コストがかかりすぎると思う。学習コストを低くして、使っている気持ちになってもらうには、図を描くよりも振り分けだけに絞るのが有効なんぢゃないかと思う訳だ。
後は、私の考える開発の進め方に向かってってことなんだけれども…。まあ、これはいいか。
UML の記述範囲ですべての要件をまとめられる訳ではないけれど、要求記述の網羅性と云う点では、現状より進むのではないかと云う期待もある。このあたりは、もうちょっと考察を重ねる必要があるな。
