UMLスケッチから始めよう

2. 異なった解釈モデルは対象の理解を深める

UMLスケッチが「解釈モデル」である以上、モデラーが異なれば、描かれる「解釈モデル」も異なります。また、「解釈」なので、「解釈モデル」の中に誤りが存在する場合もあります。

こうして描かれた、異なる「解釈モデル」を基に議論を行うのは、大変有意義です。異なる「解釈モデル」を比較すれば、相互に欠けている視点が理解でき、対象の解釈の誤りに気付くこともできます。時には、どうしても異なる解釈を、意見として主張しあうこともあるでしょう。

こうしたモデルを使って議論を行う場面では、UMLの正確性よりも、さまざまな人がどのようにその事象を解釈したのかという「視点」の方が重要です。

例えば、UMLスケッチの実践例として、第2回で登場した、自動販売機のクラス図を記述してみてください。読者によっては、記述したモデルの属性に、下記に示した項目があるかも知れません。一方で、これらとは異なる項目を属性として挙げてい方もいるでしょう。

• ペットボトルなのか、缶なのか、瓶なのか、といった、外装の材質（商品スペック）
• 炭酸飲料など、取り扱いに配慮が必要かどうか（商品スペック）
• 外装パッケージの情報（継続して販売している商品は、あるタイミングで外装が変わる）（商品スペック）

これらの属性が「不要」かといえば、そうとも限りません。実運用には必要になる属性かも知れません。もしかすると、ある飲料だけに必要な、特殊な属性があるかも知れません。自動販売機に商品を補充しているアルバイトなど、各種の作業担当者も含めてモデリングを行うと、システムにとって本当に必要な視点が得られます。

このように、さまざまな人が描いた異なるモデルを基に議論をすると、対象としている問題領域に対して、より一層深い理解が得られます。もし、モデルを描けなかった作業担当者がいたとしても、エンジニアがヒアリングし、モデルをスケッチすればよいのです。ヒアリングしつつ、スケッチし、描いたUMLスケッチについて軽く補足しながら確認すれば、表記法の詳しいルールを知らなくても理解でき、お互いの「解釈」を議論できます。