UMLとコミュニケーションと

ふぅ～今日も長かった進捗＆レビュー会議。

今日は最長不倒の２．５時間でした。

も～最悪です

そして、今日改めて気になったこと。

それは、UMLクラス図のことです。

今日の進捗の中で成果物としてクラス図を発表した人がいました。

そして、そのクラス図をみせられたメンバーたちのコメント。

Aさん

「すげ～インターフェース使ってるよ。でも、なんで製品受払がインターフェースなの？」

Bさん

「製品在庫ってなんでクラスがないの？これってテーブルになるんでしょ。

インターフェースだけでいいの？」

そして、回答・・

クラス図を発表した人

「いやあ～インターフェースが好きなんですよ」

・・・。

そうですかあ～

何の根拠もないのね。

これじゃ、解釈がバラバラになるわけです。

レビューがこれでいいのか。

前から思っていますが、UMLで表現されたクラス図は個人の解釈に依存してしまいます。

属性だけをならべてもいいし、メソッドをつけてもいい、そしてもちろんインターフェースを作ってもいい。

いうなれば個人の自由。

まえに買ったこの本にも書いてあります。

ERモデリングvs.UMLモデリングデータベース概念設計/真野 正

￥2,415

Amazon.co.jp

ただ分析クラス図を作るということが目的となってしまうと、

こういう状況になってしまう。

だから、なんのために作るかが大事だと思っています。

例えば、データを表現するために、ER図的に作る。

そして、それを要件定義者とのコミュニケーションに使う。

みたいな。

このようなルールにすると、分析クラスといわれるものは、

”エンティティ”しか出てこなくなるはずです。

私はよく標準化プロジェクトのほうで、

”データモデルが好きなヤツ”と勘違いされますが、

データ構造を表現するのはシステムを作る上で

”当たり前のこと”だと思っているだけです。

この当たり前のことができていないので、それをどっかで

作っておきたいというだけ。

UMLの理解が進まない上の人たちにとっても

このほうがベストのはずです。

これが私たちが普段テーマにしている

コミュニケーションを活性化させるための

実践（プラクティス）でもある。

なにがともあれ

「プロジェクトはコミュニケーション」

この本質に気づいている人であれば、

今回のような、”使えないドキュメント”は

つくろうとしないはず。

そして、その道を示すのがリーダーもしくは

アーキテクトではないかと私は考えます。

というわけで、話がデータモデリング寄りになってしまいましたが

言いたくなったので書きました。

以上