ObectSquare

[Fowlerと軽量UML]


Fowlerと軽量UML

written by

(株)プライド 矢崎博英

INDEX
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

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

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

  1. UMLはroughlyに書くという点が大事。詳細に拘泥してはならない。

  2. UMLを本当に活かすのは、全てのNotationを使うのではなくて、限定されたものを使うほうがよい。なぜなら、読む人が全てのNotationを知っているとは限らないから。

  3. すべてをインタラクション図で表そうとはしないほうがよい。興味深い点にしぼって書く。

  4. (講演の話やファウラー氏の著作によれば、全てをインタラクション図で表現するとは考えないということですが、表現しない部分はどうするのですか?という会場からの質問に対して)プログラムコードで表して十分なところは、インタラクション図を描く必要はない。そのまま(プログラムコード)でよい。インタラクション図は有効な方法だが、やたらと使いまくることはしないほうがよい。たくさんドキュメントを書けばいいというものではない。大切なことはコミュニケーションであり、そのために必要なものだけを作成すればよい。

  5. UMLの究極の目的はコミュニケーションを円滑にするということである。したがって、どのような局面で誰とコミュニケーションするかによって、UMLをちがった切り口で使うほうがよいし、ちがったテクニックが役に立つ。

  6. UMLから自動コンパイルはできない。UMLはコミュニケーションの道具であり、自動コンパイルのためのものではない。

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

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

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

(143ページ)
「クラス図と相互作用図を使って大まかな設計をすれば、考えをまとめるのに役立ち、コードを書くのが簡単になります。これらの図は初期段階のプロトタイプと考えています。後々までこれらの図を保存しておく必要はありませんが、保存していれば自分もあるいは他の人々にもコードが理解しやすくなります。」

(29ページ)
「UMLダイアグラムはシステムの全体的な理解を深めるのに役立つと思います。ただし、システム全体の詳細図を作成すべきだとは思っていないということを強調しておきます。Ward Cunningham氏(1996)の言葉を引用します。

注意深く選択され上手く書かれたメモは、従来の包括的設計文書の代用を十分に果たすことができます。従来の包括的設計文書はいくつかの箇所を除いてそのほとんどがクズです。そのいくつかの箇所だけを取り上げ、残りの部分は忘れてしまえばいいのです。」

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

(139ページ)
「これを実行するのに協調して働くいくつかのメソッドが存在します。これを示す図を描くこともできますが、わざわざ描くこともないでしょう。私がメソッドを分解する際にとる方法は、あらかじめ設計において考えるというよりもリファクタリングにもとづくことが多いように思います。」

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


 

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

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

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

  1. システムがそれなりの大きさであるならば、システムをパッケージに分割する。各パッケージは特定の目的のために、いっしょに働くクラスの集合から構成されるものである。パッケージとパッケージ間の依存関係を表す図を使って、システムの全体構造をドキュメント化する。UMLではこの種の図は、クラス図の一種であるが、私(ファウラー)はこの図を多用するので、パッケージ図と名づけたい。

  2. 各パッケージ単位で、簡単なドキュメントを書く。このドキュメントの基本は、パッケージが何をどのようにやるのかについての、説明文書である。UMLの図は、これをサポートするために使うことができる。重要なクラスを表すクラス図を描くことができる。しかし全部のクラスを示す必要はない。各クラスについて、主要なアトリビュートとオペレーションを示す。全てを示そうとしてはならない。実装よりもインタフェースに集中すべきである。パッケージ内の重要なコラボレーションについては、インタラクション図を描く。ライフサイクルのおもしろいクラスについては、ステートチャート図を描く。ドキュメントは、アップデートが問題にならないよう、十分に少なくなければならない。

  3. パッケージ単位のドキュメンテーションと同じように、パッケージを超えるコラボレーションを表すことも有効である。そのために、キーとなるユースケースを識別し、そのコラボレーションをインタラクション図と文書でドキュメント化する。そのコラボレーションに含まれるキーとなるクラスを強調したクラス図も有効である。多くの人々が、全てのユースケースについてのインタラクション図を描くことを主張するが、私は、それは大量のドキュメンテーションにつながると感じている。それが有効であればそうすべきだが、しかしその場合でも、重要なユースケースを強調しておくべきである。

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

(原著第二版113ページ)
「パッケージはクラスを含むのと同じように、コラボレーションを含むことができる。」

(同書114ページ)
「どのオペレーションがそれを呼び出すかを決める前に、コラボレーションをモデル化することができる。」

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


 

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、http://www.martinfowler.com/articles/index.html

アンケートにご協力お願いいたします
記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点

© 2000 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP