UML

数年前SI様からプログラムの構造をドキュメント化するのにクラス図をご要望されたのをきっかけにUMLの使用を始めました。UMLについては既に広く知られていると思うので解説はしませんが、当方がどのように使っているかを紹介します。

UMLのツールは無償の物から大変高価なものまでいろいろとありますが、ここ２年ほどメインに使っているのは SparxSystems JapanのEnterprise Architectです。これ以外にJude Communityという無償のツールもお客様の指定がある場合に使用します。いろいろな図をサポートしていることDelphiのリバース・フォワードができること、表現力が豊かであること、価格面からEnterprise Architectの導入を決めました。ライセンス体系は独特でサポートに重点を置いています。返事が早いこと、問い合わせにより挙がった修正項目に丁寧に対応し修正が早いことなどサポートの質は高く、機能が改善・強化された物がダウンロードできますので、合理的なライセンス体系であると判断しています。

UMLはいろいろな図があります。講習を受けたときよく使う重要な図はクラス図とシーケンス図と教えられたのですが、その当時はシーケンス図の必要性が理解できなかったのです。なぜならば当時携わっていたプロジェクトではクラスとクラスの呼び出し関係が単純でわざわざシーケンス図を描くほどのこともなかったからです。Accessなどのツールに組み込まれているGUI部品を使ってアプリケーションを開発する場合にはシーケンス図は要らないと思いますが、GUIそのものを作るような開発に着手したとき必要性を痛感しました。

シーケンス図が必要かどうかの分岐点のひとつはコールバックがあるかどうかによると思います。単純にメソッドを呼び出すだけのシーケンスではそれぞれのメソッドの役割だけを理解して中身をブラックボックスと見なすことができるので、そこからどのクラスのメソッドが呼ばれようと考慮する必要がないと理解することもできます。しかし、呼び出し元に返ってくる場合はそうはいかなくなります。相互に状態変化をもたらすのでどのような状況で呼ぶのか細かく制約されるからです。

Visitorパターンや、フォームとコントロールのように親子関係のあるクラスが相互に連係しながら動作する場合には、このような状況が現れます。

当方は通常分析段階からシステム構築をしていますので、アプリケーションの大まかなフローを描くのにアクティビティ図、業務フローを描くのにBPMN(UMLではない)、ユーザの分類と使用する機能の関係を表すのにユースケース図、コンピュータやプログラムの配置を表すのに配置図を使っています。一つのシステムをいろいろな角度から俯瞰できますので、単にヒアリングした項目を列挙するだけの場合に比べて抜けが少なくなります。Enterprise Architectで作成した図をWordに貼り付けて提案資料としてお打ち合わせ時に使っています。