UMLのポテンシャルを探る：FTP Online（1/5 ページ）

効率的なJavaアプリケーション開発には、設計時にUMLを利用することが不可欠となっている。さまざまなモデル例を挙げ、UMLの使い方とその効果を解説しよう（日本語訳：澤田侑尚）。

[Craig Larman，FTPOnline]

INDEX　UMLのポテンシャルを探る

1. 序文 2. キーモデル 3. ユースケースモデル 4. ドメインモデル 5. システムオペレーションコントラクト 6. オペレーションコントラクト 7. デザイン：ダイナミックモデリング 8. アジリティを備えた静的なデザイン 9. インタラクティブモデリング 10. 進化的なモデリング

UMLは比較的些細なものであり、重要ではない――この言葉に驚くだろうか？　多くの人はそうかもしれないが、これを読む読者は驚くことはない。また、UMLを暗に否定的にほのめかすようなこの言葉が、誤りだとする必要もない。

　しかし、私たちはそうであってはならない。UMLが有用ではないことを暗示することがそうであるように、その声明も誤って説明されてはならない。

　しかし、見通しは批判的だ。UML（Unified Modeling Language）は、ボックスと吹き出し、線、文字によるダイアグラム表記の単なる標準形式である。OMG（Object Management Group）は、UMLの仕様を「システムの青写真を書く標準の方式」と表現しているが、この「青写真」という表現は的を射ている。文明と電子の世界においてエンジニアたちは、構造を図示し、構築するものを記述する標準のダイアグラム言語を持つ。われわれは、構築物を心に描き設計するための知識とスキルを用いる標準の青写真といえるダイアグラム言語について、読む能力と書く能力を同一視しない。それはエンジニアであるべきか、設計者であるべきかということだ。

　それにも関わらず、ソフトウェア開発とUMLの状況において、UML表現を読み書きするスキルの獲得は、オブジェクト指向アーキテクチャデザイン（OOA/D）のスキルとよく混同される。UMLを対象とする書籍を手にすることや、UMLの教育コースを受けること、またUML 2.0における表記中で証明されるようになること、さらにUMLケースツールの使い方を知ることが、オブジェクト指向システムの最適な設計における思考や分析の実現に関する能力を持つことではない。確かに、UMLの表記やツールを学ぶ人は多少はいるが、Javaにおけるコード記述の削減や、パターンを使ったデザインを行うスキルはまだない。そして、いくつかの中途半端なシステムにおける結果として、それはアナリストや設計者のような上級者の役割に割り当てられ、彼らはプログラムの本質から離れたUMLダイアグラムの作成という先進的な作業を行う。もちろん、ダイアグラム自体には価値はない。効果的なUMLとは、充分な経験を持ったオブジェクト指向を持つプログラマーにより、彼らがプログラミング中にヒラメキとして独自に描き出す以前に、クリエイティブな思考とコミュニケーション（理想的にはホワイトボード上で2つが1組となって）を支援するものとして描かれる。

　重要なのは、最適なオブジェクト設計とプログラムを作り出せることで、それはOOA/D（オブジェクト指向アーキテクチャとデザイン）の芸術でもある。厳しい状況に遭遇しコードの削減が必要となる時、信頼性と疎結合によるデザインの作成、および高い結束性、理解力、そして容易な修正などに割り当てる能力とは何か。それは、UMLのようなダイアグラム表現を知ることから大きくかけ離れたものである。

　すべての人がこう言う。「プログラミング以前にビジュアルなスケッチを行うことを強く奨める。そして、特にアジャイルなモデリング精神が応用される時、UMLなどを使ったビジュアルなモデリングが開発を大いに支援することを知っている」と。では、クリティカルなスキルとOOA/Dを調べてみよう。そして、分析と設計において、どのように効果的にUMLを利用できるかについて見てみよう。

キーモデル

　モデルは何らかの抽象物であり、詳細と概要をつまびらかにするものではない。各種のモデルをここで調べるが、詳細に入る前に重要なポイントについて考えよう。このUMLが各種のモデルを定義するわけではない。UMLは方法ではなく、単なる未処理のダイアグラム表記である。

　おそらく読者は、「ドメインモデル」や「ユースケースモデル」などのモデルについて耳にしたことがあるだろう。これらはUMLで定義されてはいない。というより、UMLは「クラスダイアグラム」や「ユースケースダイアグラム」などの、より低レベルな定義を行うものだ。モデル概念とモデル名は、高位レベルのコンセプトであり、UMLにおける低級レベルの上位に位置する。特にモデルは、ユニファイドプロセスやフューチャードリブンデベロップメント（Feature-Driven Development)、Catalysis（触媒的作用）などの各種方法論や、開発プロセスで定義される。これらの方法論は、別々の名前と目的によりモデルを定義しているにも関わらず、モデルをビジュアライズするために未加工のUML表現を使用している。しかし、あるモデルは必然ではなく、なおさらダイアグラムのセットもそうなる。例えば、あるユースケースモデルは、元々テキストドキュメントに組み入れられている。

　OOA/Dとモデルを語るには、モデルを定義する何らかの方法論を選ばなければならない。ここでは、ユニファイドプロセス（統一プロセス）と、そのモデルを例題中で使用する。それが、オプションモデルが精巧に設計されたセットを用い、現状でも既に広く利用されている進歩的な方法論だからである。ユースケースモデルなどのいくつかのモデルは、要件分析における主たるパートである。ドメインモデルなどのいくつかは、伝統的なオブジェクトの分析だ。また、デザインモデルなどは、オブジェクトデザインの領域である。私が紹介したいのは、どのような共通モデルがあるのかということや、また、その関連性や、UMLのビジュアライゼーションの例、そしてカギとなる学習用の資料などである（参照、記事最後の関連リンク）。