UMLを基礎から理解する　――UMLでできること，できないこと

●図による分析法はいろいろあるが...

　UMLを図と考えると，同様なものとして関係データベースを設計するER（Entity Relation）図，構造化分析・設計のDFD（Data Flow Diagram）などがあります．実際，あるアンケートによると，UMLを使い始めたけれどもなじみの深いDFDを手放せずに併用している人の割合は，組み込み関係では20％程度だそうです．

　DFDは処理手順と処理モジュール（あるいは関数）を同時に考えるときに便利な図です．UMLでこれに対応するものはアクティビティ図になります．あるいは処理手順だけならシーケンス図，処理モジュールはクラス図とオブジェクト図などが対応します．

　UMLでは目的に特化した図（ダイヤグラム）を何種類も使用してソフトウェアの構造を表現します．UMLは何種類もの図によって定義されている言語なので，DFDのような1種類の図とは異なります．このことは，目的別に精密な表現が可能になるという利点があります．

　欠点は，覚えなければならないことが増えること，重複する情報を持った図が複数存在するので，保守がたいへんなことです（図3）．例えば，あるクラスのオペレーション名を変更すると，関連するシーケンス図なども変更しなければなりません．UMLをその場限りのコミュニケーション言語と考えるか，設計成果物とするかによって保守の負荷が変わります．設計成果物とするためには，紙と鉛筆，あるいはお絵描きツールではない，モデル要素間の整合性を維持してくれるモデル作成（モデリング）ツールが必要になるでしょう．

　DFDを詳細に書こうとすると，どんどん細かくなってしまいます．サブルーチンを通り越して，ステートメント・レベルまで分解してしまうことがあるかもしれません．UMLの場合，「意味付け」されているので，通常このようなことはありません．一般には，オブジェクトの粒度で分解は止まります．「意味付け」とは，その図を見るだけで，どのレベルの抽象度で議論すればよいかが明確になっているということです．

〔図3〕目的ごとにいろいろな図があるのは便利だけれど，保守はたいへん