［Fowlerと軽量UML］

Fowlerと軽量UML

ＩＮＤＥＸ
	1. UML適用の問題点 - 大きさと複雑さ
	2. UML適用の心構え(1) - 軽量UML
	3. UML適用の心構え(2) - より儀式的なやり方
	4. さて、最後に．．．
	5. 参考文献とURL

1. UML適用の問題点 - 大きさと複雑さ

皆さん、UMLを描いていますか？かくいう私も、実際の開発の現場でUMLを使用しだしたのはつい最近のことです。幸いにもUML関係の情報は、いろいろなところから手にいれることができて、とても助かります。日本語で書かれた本（書き下ろしや翻訳）は多数出版されていますし、英語のできる方であれば、UMLの公式なドキュメントを米Rational社のWebページから、無料でダウンロードすることもできます。また、日本のいろいろなコンピュータ関係の雑誌にもUMLの特集記事や関連記事が載るようになりました。さらに、「オブジェクトの広場」のメーリングリストを始め、良質のメーリングリストも多数あり、その中から自分の興味にあうものを選び、そこで議論しながら考えを深めていくこともできます。

このようにUMLに関する情報には事欠かないと思えるのですが、それでも、ふと手が止まる時があります。特に、実プロジェクトでUMLを使う場合に大きな問題となるのが、大きさや複雑さという問題です。

教科書的にいえば、ユースケースを識別し、そのシナリオがわかれば、それをそのまま、インタラクション図で描くことができます。

しかし少なくとも私たちのプロジェクトでは、ユースケースのシナリオのシーケンス図を描こうとすると、それはあっという間に、縦にも横にも大きくなりました。つまり、オブジェクトの数と、処理の流れの長さの両方で大きくなったというわけです。

シーケンス図は確かに物理的には描けるかもしれません。しかし、それは見ていて、あまりわかりやすいといえるような物ではないようです。描いた本人にしか理解ができないような、そんな感じがします。

デザインパターンや、アナリシスパターンにシーケンス図が出てくると、一挙に理解が容易になったのに、ユースケースのシーケンス図は、どうしてこうもわかりにくくなるのだろう？これが私が抱いた悩みでした。

2. UML適用の心構え(1) - 軽量UML

マーティン・ファウラー氏は、この私の悩みに対して、１つの回答を与えてくれました。といっても、何かわかりやすくなるような特別な描き方を教えてくれたわけではありません。彼が教えてくれたのは、UMLを使うときの心構えというようなものです。それが本当の解決なのかどうかは、もう少し考えてみないとわかりません。しかし、それは私にとっては、ある種のパラダイムシフトをもたらしました。

先日行われた、彼の日本での講演から、興味深い発言をいくつか拾いあげてみましょう。

1. UMLはroughlyに書くという点が大事。詳細に拘泥してはならない。
   
   
2. UMLを本当に活かすのは、全てのNotationを使うのではなくて、限定されたものを使うほうがよい。なぜなら、読む人が全てのNotationを知っているとは限らないから。
   
   
3. すべてをインタラクション図で表そうとはしないほうがよい。興味深い点にしぼって書く。
   
   
4. （講演の話やファウラー氏の著作によれば、全てをインタラクション図で表現するとは考えないということですが、表現しない部分はどうするのですか？という会場からの質問に対して）プログラムコードで表して十分なところは、インタラクション図を描く必要はない。そのまま（プログラムコード）でよい。インタラクション図は有効な方法だが、やたらと使いまくることはしないほうがよい。たくさんドキュメントを書けばいいというものではない。大切なことはコミュニケーションであり、そのために必要なものだけを作成すればよい。
   
   
5. UMLの究極の目的はコミュニケーションを円滑にするということである。したがって、どのような局面で誰とコミュニケーションするかによって、UMLをちがった切り口で使うほうがよいし、ちがったテクニックが役に立つ。
   
   
6. UMLから自動コンパイルはできない。UMLはコミュニケーションの道具であり、自動コンパイルのためのものではない。

このように、彼のUMLの使い方は、非常にLightweightです。正式な設計ドキュメントの中心というよりは、文章を補足するために描かれるもの、そんな軽い感じをうけます。
事実、「UML　Distilled」（日本語訳「UMLモデリングのエッセンス」）には、以下のような刺激的な言葉があちこちに書かれています。

(134ページ）
「これらの図（矢崎注：シーケンス図やコラボレーション図のこと） は芸術作品である必要はありません。私はよく紙切れや小さなホワイトボードに大まかに描いてしまいます。クラスの振る舞いを明確にするのに役立つので、その図を最新の状態に保つ価値がある、と思うときだけ、ドローツール（やCASEツール）を使って図を書き直します。」

まるで、手を動かすと脳に刺激が与えられ、いいアイディアが浮かぶので、メモとか紙切れに気楽にシーケンス図を描いています、そんな軽さがあります。

私たちはメモとか殴り書きの効用というものを軽視しすぎなのかもしれません。ファウラーやカニンガムが言うことには、簡単に否定できない説得力があります。

XP のファウラーの本領発揮といったところでしょうか。しかし、XP でなくとも、プログラムを書きながら思考をまとめたりロジックを変えたりするプログラマは結構いるのでは？

3. UML適用の心構え(2) - より儀式的なやり方

さて、このままだと、あまりにもとりとめがないかもしれません。幸い（？）にも、ファウラーは「Distributed Computing」という雑誌の連載コラムで、もう少し儀式的（？）なやり方を説明しています。（ https://www.martinfowler.com/articles/index.html ）

「The Almighty Thud」と名づけられたコラムの主題は、全てのことをドキュメント化するのではなく、重要な部分に光を当ててドキュメンテーションすべしというものですが、その中で、彼のやり方を次のように披露しています。

1. システムがそれなりの大きさであるならば、システムをパッケージに分割する。各パッケージは特定の目的のために、いっしょに働くクラスの集合から構成されるものである。パッケージとパッケージ間の依存関係を表す図を使って、システムの全体構造をドキュメント化する。UMLではこの種の図は、クラス図の一種であるが、私（ファウラー）はこの図を多用するので、パッケージ図と名づけたい。
   
   
2. 各パッケージ単位で、簡単なドキュメントを書く。このドキュメントの基本は、パッケージが何をどのようにやるのかについての、説明文書である。UMLの図は、これをサポートするために使うことができる。重要なクラスを表すクラス図を描くことができる。しかし全部のクラスを示す必要はない。各クラスについて、主要なアトリビュートとオペレーションを示す。全てを示そうとしてはならない。実装よりもインタフェースに集中すべきである。パッケージ内の重要なコラボレーションについては、インタラクション図を描く。ライフサイクルのおもしろいクラスについては、ステートチャート図を描く。ドキュメントは、アップデートが問題にならないよう、十分に少なくなければならない。
   
   
3. パッケージ単位のドキュメンテーションと同じように、パッケージを超えるコラボレーションを表すことも有効である。そのために、キーとなるユースケースを識別し、そのコラボレーションをインタラクション図と文書でドキュメント化する。そのコラボレーションに含まれるキーとなるクラスを強調したクラス図も有効である。多くの人々が、全てのユースケースについてのインタラクション図を描くことを主張するが、私は、それは大量のドキュメンテーションにつながると感じている。それが有効であればそうすべきだが、しかしその場合でも、重要なユースケースを強調しておくべきである。
   
   

上の説明によれば、ファウラーはパッケージ内部の重要なコラボレーションについて、インタラクション図を描くそうです。実は「UML　Distilled」の第二版（残念ながら翻訳は出版されていません）では、Chapter７が「PACKAGE　AND　COLLABORATIONS」となっています。第一版とちがい、パッケージ図が独立して説明されなくなり、コラボレーション（コラボレーション図ではありません。念のため）といっしょの章で説明されています。

また、ユースケースについて全てをインタラクション図で描く必要はないとしている点も目をひきます。

4. さて、最後に．．．

ファウラーの説くLightweightなUMLの使用方法は、彼がおそらく実践していることでしょうし、結構上手くいきそうです。今は、コードからリバースでクラス図を作成することもできるので、開発途中の設計ドキュメントを大事に保管しておく必要もないのではないでしょうか？必要なときにコードからリバースすればいいかもしれません。

それに、あたかもメモを描くかのように、設計を進める方法は、案外頭にもよさそうです。私も何か考えるときは、シャープペンシルで紙に落書きをしながら、考えをまとめるのですが、これはPCのキーボードを叩くことでは得られない感覚です。

しかし、どちらかといえばドキュメント至上主義の中で育ってきた私としては、やはり多少の違和感を覚えるのも事実です。この違和感を払拭するには、ファウラー流のやり方で徹底的に開発してみるのが一番かもしれませんが、そういうプロジェクトに参画する日はやってくるのでしょうか？

5. 参考文献とURL

1. UMLモデリングのエッセンス、M.Fowler、K.Scott著、羽生田栄一監訳、アジソンウエスレイ
2. UML DISTILLED SECOND EDITION、M.Fowler、K.Scott著、Addison　Wesley
3. The Almighty Thud、M.Fowler、https://www.martinfowler.com/articles/index.html

© 2000 OGIS-RI Co., Ltd.

HOME TOP