UML

最近、ちょっとだけUMLについて考えさせらました。

詳細設計書を作成する際、UMLがベターな表現形式だと断言する方がいました。まぁ、悪くないと思います。自分がそこで違和感を感じ、考えさせられたというのは、その人が「だから、君のプロジェクトでもUMLを用いるべきだ」とまで言ってきた事です。

「まぁおりを見て」とだけ回答しておきましたが、あまり乗り気ではない自分の態度にその人は不満を抱いたようでした。知るかってーの。

一時期、自分はUMLでひたすら設計書を書いてましたから、UMLが優れた表現形式を持っているのは知っています。ただ設計書はあくまで開発者に設計者のイメージを伝えるだけのものであって、それがどんな表現形式であっても、漏れや誤解なく開発者に伝えられるものであれば良いと思っています。ここについては、以前エントリーを書いた記憶があります。

その時、自分が担当していた案件では、確かに設計はオブジェクト指向を意識して役割や存在が疎結合になるようにしましたが、あえてクラスという単位ではなくコンポーネントという単位でモジュールを集約したり、可能な限り「オブジェクト指向」そのものを前面に出さないようにしていました。

理由は簡単で、メンバーにJavaやC++、C#を使った経験のある人が一人もおらず、デザインパターンも自分が見せるまで知らなかったような状態でした。ただし、TransactionScriptベースでの実装を長く続けている人は、当然ながらたくさんいたのと、構造化技法について多少は話が通じたので、落胆は少しもしませんでした。

そういったメンバーと一緒に仕事をする以上、コンポーネントやクラスといった集約単位は「共通モジュール」と呼称した方が良かった時期が少なからずありましたし、設計書も内部仕様書も基本は過去のCOBOLの案件のように、テキストベースで作成しました。

恐らくはこの場合後者が正解な筈なんです。

UMLは「Unified Modeling Language」（統一モデリング言語）です。
“統一言語”という事は、形式を決め、表現方法を標準化することで書く側も受ける側も同じ視線で情報を共有しよう、ということを目的にしているからに他なりません。だから、UMLモデルとして定義されているクラス図やシーケンス図と同様に、簡単なフォルダ配置を書いた絵であってもそれが書く側も受ける側も同じ認識を得られるのであれば、それはUMLの理想を体現したモデルだ、と言える筈です。
逆に受ける側を意識せずに書く側がUMLで書きたいから書く、というスタンスだと、それはUMLモデルの表現形式を保っていたとしても、UMLの理想とはかけ離れてしまうでしょう。

ドキュメントの基本は、まず分かりやすいこと。
内容が正しいこと。
誰が読んでも、見ても、理解の齟齬が少ないこと。

これらが守られていないドキュメントは非常に「有害」な存在です。
TransactionScriptで実装を行い、OOやUMLを知っている人の比率が低いことや、そもそも開発言語がOOに対応していない場合、UMLを持ち込むのはデメリットしかありません。