UML でモデル化する理由

要約

UML (Unified Modeling Language: 統一モデリング言語) の目的は、言語およびプラットフォームに依存しないモデリング表記法を提供することです。UML が基礎的であるのと同じように、UML ツールには汎用性があります。この記事は、モデリングの目的に関する情報を提供すると同時に、UML の基本概念に関する入門書として役立ちます。ハウツーマニュアルではありませんが、よくできたチュートリアルを紹介するため、適切な場所にリンクが提供されています。それらのチュートリアルには、NetBeans IDE で提供される UML 機能の使用手順が示されています。

この記事は、コーディングを始める前にプロジェクトをモデル化する時間が持てない技術者、またシステムのコーディング前にモデルを作成することを考えたことのない技術者を対象に記述されています。この記事は、作業の効率を高め、場合によっては時間の節約にさえ役立つ方法と戦略をいくつか提示します。この記事の内容によって、「正しく行う時間があった試しはないが、再び行う時間はきっとある」というもっともらしい言い訳に異議を唱えることができるかもしれません。

目次

はじめに

喫茶店で、「すごい」ソフトウェアの構想を得たときに、興奮してナプキンをつかんで考えを明らかにするために絵を描いたとしましょう。たいてい、その絵は自分以外には意味がなく、判読不能なものの集まりです。

しかし、自分にとっては何らかの意味があります。その判読不能な絵は、それを実現するために、自分の人生の次の 2 年を捧げるかもしれないアイデアを表現したものです。描いた内容は初歩的なモデルです。頭の中では、ボックスは 1 つの要素を表します。円、三角形、線などは別の要素を表します。ナプキンの裏にモデリング言語を考え出したということです。もしナプキンを単にコンパイルして実行できるならば、それで終わりです。これは、思うほど不可能なことではありません。次の 2、3 ヶ月を使ってナプキンの各オブジェクトが何を表すか、また各オブジェクトのソースコードを生成する方法をコンピュータに教え込めば、ナプキンのコンパイルは可能です。

ナプキンモデリングの過去 25 年にわたって、一握りの非常に素晴らしいモデリング言語が作成されました。統一モデリング言語 (UML) が追加されました。モデラーは自分たちのナプキンをすべて集めて、各オブジェクトおよびオブジェクト間の関係の定義について合意しました。統一モデリング言語を使用して、各言語のプログラマは、各種オブジェクト用のコードを作成するためのテンプレートの開発に着手しました。そして今、UML の構成要素であるオブジェクトをナプキンに描く限り、ナプキンはコンパイルできます。

「なぜ、モデル化すべきなのか？」これは、素晴らしい疑問です。この記事では、その疑問に対して 2 つの答えを提示しています。それらを UML ユースケースと考えてください。「ナプキンをコンパイルする」で述べる最初の答えでは、技術者がホワイトボードあるいは喫茶店のナプキンにアイデアをスケッチすることに焦点を当てています。この節の目的は、プロジェクトの計画段階でモデル化する利点を示すことです。この節からリンクされている複数のチュートリアルによって、モデリングの実行に関する詳細な手順を学ぶことができます。

「なぜモデル化」という疑問の 2 番目の答えは、「考えられていたこと」の節にあります。2 番目の答えは、長さ 30 万行のコードを渡されて、その保守とバグ修正の仕事を任され、苛立ちを募らせている技術者に焦点を当てています。元のプログラマがパッケージを知っていたことが分かってほっとしましたが、全体がどのように組み合わせられているのかまだ分かりません。もしこれが自分で、自分が映像人間なら、システムの図を見て、元のプログラマが考えていたことを知りたいと思うでしょう。これは、UML ツールの一般的なユースケースです。効率的にコードを解析してモデルを作成し (「リバースエンジニアリング」という)、そこから図を作成できます。

次の表は各種 UML 図をまとめたもので、ネットワーク上のさまざまな場所で見つけることができますが、便利なようにここに含めています。 サムネイル画像をクリックすると、その図の例が表示されます。

ユースケース図		主に「アクター」と「ユースケース」で構成されます。ユースケース図は、システムの機能要件の把握に役立ちます。プロジェクトの開始で使用するものとして、常に優れた図です。	チュートリアルを表示
コンポーネント図		主に「主要システムコンポーネント」とその「関係」で構成されます。これは、複雑なシステムの高レベルの概観図を意図しています。頭の中、ナプキン、または UML ツールのどれであれ、この図はこれまでに取り組んだすべてのプロジェクト用に作成されました。	チュートリアルは準備中
クラス図		主に「クラス」、「インタフェース」、およびその「関係」で構成されます。クラスとインタフェースはかなり単純ですが、関係は、多重度、汎化、関連などで少し複雑になることがあります。システムを構成するコンポーネントが明らかになったら、自然の流れとして、コンポーネントを構成するクラスを作図します。	チュートリアルを表示
アクティビティ図		主に「アクティビティ」と「決定」で構成されます。この図は基本的に、コードの一般的な流れを把握するのに使用するフローチャート図とデータフロー図です。	チュートリアルを表示
コラボレーション図		主に「オブジェクト」と「メッセージ」で構成されます。この図は、オブジェクト間の通信に重点を置いた図であり、シーケンス図に似ています。	チュートリアルを表示
配置図		主にサーバーなどの「配置要素」とその「関係」で構成されます。これはシステムの論理的な地形図です。	チュートリアルは準備中
シーケンス図		主に「オブジェクト」(生存線付き)と「呼び出しメッセージ」で構成されます。シーケンス図は、システム内の呼び出しの順序に加えて各種オブジェクトの作成を表現します。	チュートリアルを表示
状態図		主に「状態」、「遷移」、「イベント」、および「アクション」で構成されます。状態図は、ロジックが非常に複雑な場合を除いて、めったに必要になることはありません。	チュートリアルは準備中

ページの先頭へ

ナプキンをコンパイルする

アイデアを描き込んだナプキンを持って、喫茶店から会社に戻ってきたとしましょう。自分のグループあるいは上司に、解決策を説明する必要があります。このため、ナプキンに描いたアイデアをホワイトボードに書き写し、それを見せるため、同僚全員に自分の席に集まってもらいます。ホワイトボードの前で起こる会話を置き換えるソフトウェアツールはありません。しかし、自分のアイデアを会社の外に持ち出さなければならない場合、一般に、ポラロイドを郵送したり、ホワイトボードのデジタル写真付きで電子メールを送信したりすることは好ましいことではありません。あとで参照できるように、ホワイトボードによって、アイデアのドキュメント化が簡単になることはありません。気に入らないかもしれませんが、UML ツールを探して、自分のアイデアを説明するモデルを作成する必要があります。

モデルは単にモデル要素とそれら要素の関係の集まりですが、これらの要素をグループ化して図を形成することができます。これらの図は、モデルのさまざまなビューを提供するため、要素全体をまとめたものより優れています。さまざまなビューを使用して、アプリケーションがどのような構造になっているかについてのストーリーを伝えることができます。モデルを視覚化するために使用する図の種類は、問題によって異なります。

初めて取り組むときに、ユースケース図の作成を選択するかもしれません。これは、プロジェクトの主要コンポーネントを識別する、優れた概観図です。ユースケース図は必要に応じて複雑にすることができますが、実際にはアクターとユースケースの 2 つの主要部品があるだけです。アクターは、システムと相互作用するエンティティーを表します。エンティティーの例としては「顧客 (Customer)」や「銀行の出納係 (Bank Teller)」があり、プログラムと相互作用します。アクターは、サードパーティーのライブラリやハードウェアであることもできます。ユースケース図の主旨は、それらアクターがプログラムとの間で相互作用できることを示すことにあります。たとえば銀行の出納係は「入金」したり、「出金」したりします。この場合、「入金」と「出金」はユースケースです。コードはアクターやユースケースと直接関係しませんが、これらの相互作用は、プロジェクトに特定のコンポーネントが必要であることを明らかにします。

ユースケースを熟考することは、しばしば計画段階で省略されますが、あらゆるプログラマが知っているように、ユースケース分析は最終的に行う必要があります。プロジェクト要件が何であるかを熟考すると、不要な機能を実装したり、必要な機能を忘れたりすることがなくなります。ユースケース図を作成すると、見落とされていることが明らかになる可能性があります。ユースケース図によって不要な機能の追加を抑えることはできませんが、少なくとも、機能が不要であることを教えてくれます。したがって、最初の手順は、ユースケース分析を行なって、ユースケース図を作成することです。チュートリアルでは、ユースケース図の作成プロセスを示します。

ユースケース分析とユースケース図を完了すると、通常次の手順は、システムのコンポーネントをスケッチすることです。頭の中、ナプキン、UML ツールのどれであれ、成功したシステム開発で、この手順が省略されたことはありません。コンポーネント図を形式的に作成する利点は、コンポーネントを構成するクラスおよびインタフェースを定義するのに役立てることができることです。ユースケース図のチュートリアルを完了している場合は、その分析がどのくらい重要かおわかりになるでしょう。チュートリアルの最後にあるユースケース図から、必要なコンポーネントのいくつかが明らかになります。Customer コンポーネント、Account コンポーネント、および Database コンポーネントです。コンポーネント間の相互作用は、コラボレーション図とシーケンス図でさらに定義することができます。これらコンポーネントは、成果となるシステムの一部を表します。これらの成果物は、十分であるとして、上司か顧客、またはその両方から承認される必要があります。コンポーネントが承認されるまで、設計者とプログラマは変動するターゲットを対象としています。しかし、コンポーネントが設定されると、細部の構造面の作業に進むことができます。

この細部設計は、クラス図を作成することから始めます。これにもまた、クラス図作成の詳細手順を示すチュートリアルがすでにあります。正確なユースケース図とコンポーネント図の作成に努力すると、すぐに座ってコーディングを始めようという気になっているかもしれません。しかし、以前それを行い、コーディングを始めたときに必要な関係を理解していなかったために、あとでインタフェースやスーパークラスを作り直す必要があったことを覚えていますか?

クラス図を作成すると、すべての構成部品をまとめ上げることが求められ、インタフェースやスーパークラスが必要となる場所や、さらには全体のデザインパターンにまで反映されます。ご存知のように、クラス図の利点は、いくつかのクラスを記述して、同じメソッドを繰り返し記述することになる前に、継承構造を明らかにすることです。

NetBeans UML ツールを利用すると、クラス図に別の優れた一面、すなわちデザインパターンを追加できます。システムの特定のコンポーネントがデザインパターン、または一連のデザインを利用することが分かっている場合は、単にそのパターンをキャンバスにドラッグ＆ドロップするだけで、その基本コンポーネントが作成されます。さらに良いことに、ツールは正しくパターンを作成します。デザインパターンが実際にどのような構造になっているかを記憶しようとすることは忘れてください。NetBeans の UML 機能には、すぐに使用できる Gang of Four (GoF) および Enterprise Java Beans (EJB) デザインパターンが用意されています。カスタムデザインパターンをよく使用する場合は、あとで使用できるように保存することができます。

素晴らしいことに、こうした作業は何も無駄になりません。NetBeans の UML 機能を使用していれば、ボタンを 1 回クリックするだけで、クラス図を Java ソースコードに変換できます。ヘッダー、コメント、変数の配置、その他の書式設定など、コードの生成方法に関するオプションを設定することもできます。これらの設定には、生成されたファイルのすべてに著作権情報を追加することも含まれています。コードの生成だけで、開発サイクル中に行う価値のある手順になるはずです。つまり、最初にモデルの作成に時間をかけて、あとでツールに基本コードのすべてを生成させることは、報われるのです。

あらゆる人が、さまざまな方法で作図します。違いは、UML ツールを使用して作図する人には、図が完成したときに、計画の成果として見せるものがあるということです。ナプキンはこぼれた飲み物を拭くために使われて、捨てられることになりがちです。しっかり考え抜かれたプロジェクトはどれも、ユースケース図、コンポーネント図、およびクラス図などの形になり、喫茶店での「心像設計」が終わったあとも長い間残ることができます。

ページの先頭へ

考えられていたこと

UML は単なるモデリング言語で、あらゆるコーディング言語から独立しています。このため、UML をコーディング言語に変換できるのと同様に、コーディング言語を UML に変換することができます。この処理は「リバースエンジニアリング」として知られています。この処理には数多くの用途がありますが、もっとも一般的な用途は、コードがどのように構成されているかの概要を得ることです: オブジェクトにはどのようなものがあり、それらはどのように関係しているのか?コードを図で見ることによって、コードを見るだけでは明白ではない可能性があるデザインパターンやその他の複雑な情報を明らかにすることができます。NetBeans UML ツールを使用する「ハウツー」チュートリアルについては、「Java アプリケーションのリバースエンジニアリング」という名前のチュートリアルを参照してください。

この記事はチュートリアルではありませんが、NetBeans を使用してリバースエンジニアリングを行う場合、注目すべき 2、3 の手順があります。自由形式の Java コードベースに取り組んでみましょう。このコードベースをリバースエンジニアリングする最初の手順は、NetBeans の「既存のソースを使用する Java プロジェクト」を作成することです。NetBeans のウィザードが、この処理で役に立ちます。プロジェクトが作成されると、リバースエンジニアリングを行うためのメニュー項目がプロジェクトに追加されます。大きなプロジェクトであっても、この処理にかかる時間はごくわずかです。完了すると、UML プロジェクトがプロジェクトツリーに表示されます。

これで、このプロジェクトを自由に操作できます。生成されたモデル要素から図を作成することができます。図に変更を加える必要がある場合は、単にその変更を加えて、コードを生成し直します (「フォワードエンジニアリング」という)。モデルの元のコードを置き換えることも、別の場所に保存することもできます。これらの機能の持つパワーに注目してください。モデル自体からコードを開発できます。この柔軟性によって、モデルのすべてのビジュアル機能、レポート機能を維持し、コードをコンパイルして実行することもできます。それは本当に、両方の一番良いところです。図からコードを作成するのではなく、コードをを入力したい場合は、単純にそうすることができます。部署の責任者からコードレビューを求められたら、コードをリバースエンジニアリングしてモデルを更新し、図を会合に持参すればよいだけです。

リバースエンジニアリングは過去のコードの理解に役立つ非常に有用なツールですが、あらゆる疑問に対する答えを提供するものではありません。たとえば、リバースエンジニアリングによって作成されたモデルからユースケース図を作成することはできません。コードには、ユースケースが必要とするのとは異なるレベルの情報が含まれているため、結果は期待しないでしょう。その他、リバースエンジニアリングしたモデルから作成する意味のない図には、コンポーネント図、アクティビティ図、コラボレーション図、状態図、配置図などがあります。ただし、クラス要素と関係はすべて判明しているため、これらのいずれの図もすぐに作成することができ、そのあと自然に出てくる疑問に対する答えも導き出せます: ユースケースはどうなっているのか? 配置構造はどうなっているのか? 主要コンポーネントはどうなっているのか?完全に開発されたモデルを得るには、図に関係する不足情報を提供する必要があるだけです。

ページの先頭へ

まとめ

UML は言語です。UML で作業をするための素晴らしいツールが存在するとしても、UML が言語であることに変わりはありません。言語の構造を理解していなければ、ツールにあるデザインパレットはいらいらを引き起こすだけです。言語を「統一」されたものにするため、UML は多数の機能を取り込んできました。この巨大であるということが、UML ツールを煩雑で使いにくくしているのかもしれません。Sun Microsystems は、オブジェクト指向分析と設計のコンテキストで、UML を学習するためのクラスを提供しています。UML のさまざまな要素のコンテキストに関する知識を活かすことで、モデルは高レベルの実用性と効率性を得ることができます。間違った要素でモデルを作成している場合、そのモデルはコードに変換されません。

設計者またはプログラマのどちらであっても、モデリングは、HelloWorld よりも複雑なあらゆるプロジェクトに必要な手順です。一部のモデリング言語は、たとえばデータベース設計などの用途向けに調整されていますが、1 つのモデリング言語を学ぶ時間しかないのであれば、UML はモデリングの業界標準になっています。NetBeans の UML 機能などの UML ツールは、これまで進化してきました。もはやモデリングは、プログラミングを開始したあとに放り投げられる、時間の浪費、または単に学術的な演習ではありません。ツールはプログラミングの完成に役立てることができ、現実にその役割を果たし、コーヒー店での出来事を再現する機会を提供してくれます。

---

この記事の最終更新日は 2007 年 10 月 19日です

ページの先頭へ