図の威力
久しぶりにJava側の開発作業を行っている。Javaの開発は、過去に自ら決めた開発手順を守らなくてはならないので、非常に面倒で手間がかかる。
1.UMLエンジニアリングツールでUMLクラス図を中心にクラス設計(変更)
2.設計したクラス図からクラス(インタフェース)の雛形を自動生成(フォワードエンジニアリング)
3.雛形をエディタかEclipseで開いて、内部を実装
4.ビルド/テスト
5.実装が完了するまで1〜4を繰り返す
つまりは始めにUMLクラス図ありきで開発作業が進んでいく訳だ。使用しているUMLエンジニアリングツールは敢えて名前は秘すが、Eclipse等のIDEに統合されている訳ではなく、ツールとEclipse又はエディタの間をいったりきたりする必要があり、非常に効率が悪い。ツールはフォワード/リバースエンジニアリングの為に全てのコードのデータを内部に独自形式で保持しており、それをメモリ上にロードして使うので全てのクラスのデータをロードするとメモリの消費量は半端ない。(200〜300MBの物理メモリを消費する)
今となっては、こんな効率の悪い作業を続けたくないと思うのは当たり前であり、事実.NET側の開発では、当時、C#のコードを吐ける手ごろなツールがないこともあり、この手順を踏襲しなかったのだが、いざ効率の悪いと思われていた作業に戻ってみると、悪いことばかりではないことに気がつく。
クラス図をコードよりも先に作る、ということは前もって、最低限、インタフェース程度の論理的な設計は済ませておく必要がある訳で、(今はそんな人はいないと思うが)いきなりコードを書き始めるのに比べて、論理的なミスが殆ど発生しないのだ。また、クラス図という2次元な、静的な図上でカテゴライズされた複数のクラスの関係が明らかになるので、非常に設計時の見通しが良くなるのである。特に、コンポジションや深い継承関係等を確認していく作業は、クラス図の威力を思い知ることになる。
ファウラーは彼のblikiの中で、UMLの基本的な捉え方、求めるものが人によって違うのに着目し、UMLの用途を大きく3つのカテゴリに分類している。
開発者にとって異なるUMLの用途
・UMLをスケッチとして用いる人(スケッチとしてのUML)
・UMLを設計図として用いる人(設計図としてのUML)
・UMLをプログラミング言語として用いる人(プログラミング言語としてのUML)出典: UmlMode「Martin Fowler's Bliki」 UMLモード 「Martin Fowler's Blikija」
この分類からすると、他の多くのUMLを使っている開発者同様、私はUMLをスケッチとして用いているのだと思う。ツールのエンジニアリング機能を使用しているだし、設計図として用いているのだと思われがちだが、設計図として使用するために、UMLのルールを厳密に適用しようとすると、恐らく日々の殆どをツールを使う時間に取られてしまうことだろう。そんなのまっぴらごめんだ。
結局、何が言いたいかというと、もっと手軽に使えて雛形として使用する言語を簡単に切替えることできてリソースを消費しない、直感的なスーパーなUMLツールが欲しいな、ということ。
クラス図群を俯瞰するメリットは凄く実感できるのだから、.NETの開発でも横断的にツールを使いたいのだが、今の環境で.NETでも同様のことを始める根性は私には無い。
