シーケンス図よりコミュニケーション図を使おう

　最近は、業務系でも組込系でも、どの現場でもたいがいUMLが使われている。一番よく目にするのはシーケンス図だ。下手をすると、シーケンス図が仕様です、なんていうところもある。「このシステムの全体の設計はどうなっていますか？」とか「全体の設計を示すドキュメントを見せてください。」なんて聞くと、「いや…そこまではよく分かってません…」とか「そういうものはありません」という答えが返ってくる。

　そういうところでは、シーケンス図に登場するクラスやオブジェクトが、名前とはかけ離れた役割を担わされていることが少なくない。さすがに名前がついていないということはないが、「このクラスはどういう役割を果たすのですか？」と聞いても、ハッキリとした答えが返ってくることはまず期待できない。結局、全体の設計をしている人が「誰もいない」のだ。全体の設計は、各コンポーネントの担当者同士の調停によってなされる。当然、全体の設計は統一性、整合性を欠くものになり、試験フェーズでその代償を支払うことになる。何人かの優秀な設計者は、自分が直接担当する範囲よりも広い部分に目を向けるので、設計の途上で欠陥を発見するが、関係者にその修正を了解してもらうには多大な労力が必要になる。せっかく気がついでも、試験フェーズで明るみに出てから対応した方が自分にとっては得策だと気づき、欠陥の修正を先送りにすることもしばしばだ。

　別にシーケンス図が悪いわけではない。ただ、シーケンス図では全体を俯瞰しづらい。シーケンス図ばかりを使っていると、どうしても近視眼的になりやすく、設計がいびつになっていることに気がつきにくい。少なくとも設計の初期段階では、関連するクラスやオブジェクトの協調関係が視覚的にとらえやすい、コミュニケーション図を使った方がよい。

　しばしば、コミュニケーション図とシーケンス図は等価なものだと説明されるが、これはまったく真実ではない。確かに、MDD的な観点で言えば表現できる内容は同じかも知れない。ダイヤグラム上のどの位置にどのコンポーネントを配置しているかは意味を持たないからだ。しかし、ダイヤグラムは人間が理解するためのものでもある。人間が理解する上では、ダイヤグラム上でのコンポーネント間の距離が近いか遠いか、上下に並んでいるのか左右に並んでいるのかなどはとても重要だ。ダイヤグラムが簡潔になるように工夫することは、各コンポーネントの役割を推敲することでもある。（それが設計でもある。）そうした工夫をするには、コンポーネント配置の自由度が限られているシーケンス図は向いていない。

　まず、コミュニケーション図（ないしそれに類した図）で各コンポーネントの役割を検討し、シーケンス図は、その上で各コンポーネントの細かな動作を検証する際に使うのが有効だ。

　シーケンス図は、全体の役割が決まってから演繹されるものにすぎない。その意味で、シーケンス図は詳細設計書（ないし基本設計書の説明資料）に位置づけるのがふさわしいものであり、シーケンス図が仕様だなどというのは本末転倒もはなはだしい。（シーケンス図が仕様だとして、全体を俯瞰できないのに、どうやってそれが正しいか検証するのだろう？）

　シーケンス図を書くのは全体の設計をしてからにしよう。