UML -Unified Modeling Language-

今日は最近、書店でもたくさんの本を見かけるようになるほど注目され、普及してきたUMLについてです。

システム開発は認識合せが重要

システム開発というのは一人ではできなくてチームを組んで取り組みます。時にはお客様も巻き込んで開発が進みます。そのとき最も大切になるのはチーム内、対お客様間といかに認識を一致させていくかという意思疎通の問題です。

ソフトウェアというものは、できて動くまで目に見える形がありません。設計段階から仕様書などを作成して、どんなものを作るのかを関係者間で認識を合わせていく作業をします。画面や帳票なんかは作る前に絵に書いてお互いの認識をあわせることは比較的容易なのですが、それは見た目の部分だけであって、ボタンをクリックしたときどんな処理をするのかってことは認識をあわせるのは難しく、実装段階になって「このボタンを押したら一体どこのデータを書き換えるのか？」とか、できてみたら「あれっここってこんな処理にはずだったっけ？」なんてことが多々発生します。

建築にあこがれて

建築も同じように多人数でモノを作っていく作業です。建物もできてみるまでは形がありませんが、詳細な図面を設計段階で何枚も描きます。それを見ながら家を建てれば誰が立てても同じ家ができます。
ソフトウェア開発者はそんな建築の世界にあこがれて、長年システムを図示して視覚化する取り組みを続けてきました。しかし、それぞれの会社やチーム内で独自の図を描く場合が多く、誰にでも通用する表記法というものがなかったり、いろんな表記法が乱立する状況でした。

UML登場

そうした図の中からみんなが共通に描く対象や描き方をまとめ、システムモデリングのためのダイアグラムセットとその表記法を定義したのがUML -統一モデリング言語-です。
UMLはスリーアミーゴと呼ばれるGrady Booch氏、James Rumbaugh氏、Ivar Jacobson氏を中心にまとめられ、OMG により標準化されています。現在のバージョンは2.0です。

UMLではシステムが対象とする業務やモノをあらわすため、13種類の図の表記法が定義されています。UMLでは表記法を定義しているだけなので、それぞれの図を開発プロセスのどこで使うかは自由です。全部使う必要もなく、うちのチームでは次の図をよく使います。

・クラス図：オブジェクトモデルを表現する
・ユースケース図：システムの対象業務を表す
・シーケンス図：処理の流れとそれを担うオブジェクトの関係を表す
・ステートチャート図：オブジェクトの状態遷移を表す。

UMLを使う以前は設計者が独自の図を書くことが多く、レビューのときなんかは「この図どうやって読むの？」なんてところからはじめないといけなかったのですが、UMLを使うとそんなことはなくなりましたね。文章で長々とシステムの処理を説明する人も少なくなって互いに理解しやすく、認識あわせも楽になりました。逆に文章ばかりだと、図で書けと言われます。経験的には図で描けない人は矛盾だらけの設計をしがちです。文章では全体像が一望しにくいので、書いているうちにぶれてしまうんでしょうね。視覚化する事によりそのような不具合も早期に発見できるメリットがあると思います。

最近ではビジネスモデルを表現するのに使われたりシステム開発以外の分野でも活用されつつあります。

UMLが目指すもの

人と人との意思疎通に役立つUMLですが、システム開発の分野ではコミュニケーションの道具としての利用にとどまらず、UMLからプログラムを自動生成しようというアプローチが注目されています。それをMDA(Model Driven Architecture)といいます。
かなり昔からUMLからソースコードの雛形を作ってくれるツールはありましたが、MDAで目指すのは実際に動作するプログラムの生成です。MDAツールは商用製品からオープンソースまでいくつか出ていますが、僕はまだ使ったことがありません。まあ、評価している暇がないのが一番の理由ですが、雑誌などの記事を読む限りでは効果的に使えば今でも工数を下げることができそうですが、ツールとしてまだまだ発展途上なのかなぁと思うんですね。そういうところが積極的に評価してみようと思わない理由ですかね。まあ、もう少し様子見といったところです。でも期待はしています。今後10-20年後にはUMLで設計したシステムを商用レベルですぐ動かせるようになるかもしれません。