Java ではじめる UML

　この連載を通して UML を理解していただくためには、ある程度 Java プログラミングの知識が必要です。そうはいっても、あまり難しいテクニックを使うわけではないので、一通りの Java のシンタックスを理解していただいている方であれば、問題なく読み進めていけるでしょう。

　UML といえばまた、「オブジェクト指向」についての前提知識を問われることが多いのですが、ここではあえてそれについては必須とはしません。当連載を通して、オブジェクト指向開発について、なんとなくエッセンスを学びとっていただければと考えています。

　本連載は「 UML を理解する」ことが目的ですが、この理解の到達レベルに目標を設定してみたいと思います。

　筆者が籍をおく ( 株 ) オージス総研では、 「 UML 技術者認定制度」( *1 ) というものを行っています。現在、「ブロンズ」「シルバー」「ゴールド」という 3 つのレベルの試験が設定されており、インターネットを通して Web ブラウザ上で受験し、その場で合否判定を受けることができます。 ( 無料 )

　2002 年 4 月時点で認定試験の受験者 ( ブロンズ ) は、のべ 123,000 人にものぼり、そのうち約 21,000 人が「ブロンズ」の試験に合格されています。

　今回の連載を通して、読者にはこの「ブロンズ」の試験に合格することを目標にしていただきたいと思います。どんどんチャレンジしてみてください。

　UML を利用することによる一番のメリットは、開発に携わる人たちが共通の言葉を持ち、コミュニケーションができるということです。そんなこと日本語や英語などの自然言語でも同じじゃないかと言われてしまいそうですが、自然言語がもつ万能の表現力は、逆にソフトウエアという限られた領域の中では、あいまいさや冗長性を生んでしまいます。「餅は餅屋」ではないですが、ある目的のために特化された道具は、他の汎用的なものより優れているものです。

　いったん作成した成果物 ( またはその一部 ) を、別の機会に再利用したいという要求は、どの世界でもあります。例えば、建築の世界でいえばデザインや構造。これらは設計図という形で残されます。同じ設計で作成された部品 ( たとえばドアや窓、ユニットバス ) などはいろいろな異なった建物に利用されます。すべての家ごとにそれらをいちいちデザインしてカスタムメイドで作成していたら、それころ大変なコストがかかってしまいます。 ( お金と時間に余裕のあるかたは、この自分だけのカスタムメイドに価値を見出すのですけど、なかなか庶民には・・・ )

　この「設計図」と「部品」という形での資産の残し方は、ソフトウエアの世界でも行われています。「部品」にあたるソースコードや実行モジュールという形での再利用はこれまでにも、それなりに行われてきました。しかし、利用するプログラミング言語や環境 ( OS やミドルウエア ) が異なってしまうと再利用は難しく、また同じプログラミング言語や環境を利用していても、進歩が早いこの世界では頻繁に機能向上・バージョンアップが行われ、バージョンが異なるため利用できなくなるといった問題を抱えています。

　「設計図」という形での再利用もこれまでに行われてきてはいますが、建築の世界のような標準の「設計図」の書き方のルールがなかったため、会社や組織ごとに書き方のルールがバラバラで、結局は有効に資産が活用されていないのが実情でした。

　その点 UML の登場によって、「設計」の再利用が非常にやりやすくなりました。UML はまた環境に非依存なモデリング言語のため、いったん作成した設計モデルは、いろいろな言語や環境で利用することができます。

　これは、モデルとして蓄積したノウハウが陳腐化しにくいということを意味します。

　オブジェクト指向の世界においては、とても頭のいい先人達が、いろいろなシチュエーションでのノウハウを「パターン」という形式で残してくれています。

　代表的なパターンとして、 デザインパターン ( *8 ) 、アナリシスパターン ( *9 ) があげられます。前者は設計、後者は分析におけるノウハウをいくつかのパターンという形で提供してくれています。これらは、もともと UML で記述されたものではありませんでしたが、よりスタンダードな UML 標記によって多くの書籍や Web ページで紹介されることにより、認知度も高まりつつあります。

　UML の大きな利点のひとつとして、その拡張性があげられます。もともと UML で定義されている基本語彙 ( 表記とセマンティクス ) のほかに、利用者が新たにそれらを拡張できる「ステレオタイプ」や「タグつき値」というメカニズムをもっています。これらの使い方については次回以降に回しますが、具体的な例として以下のような拡張例があげられます。

拡張例 1 ：特定の領域の専門言語として

拡張例 2 ：ソフトウエア開発以外で

◆ ユースケース図

　これに分類されるのは「ユースケース図」です。ユースケース図は、利用者の視点でみたシステムの機能群を表現します。もちろんシステムに対する要求をこの図だけで表現できるわけではなく、あくまでも一覧的に見るためのもので、実際の要求定義工程においては、その他いろいろな 補足ドキュメント ( *11 ) を作成します。

◆ クラス図

　UML での代表格がこのクラス図でしょう。クラス図はシステムを構成する論理要素の構造を示すものです。クラス図という名が示すとおり、代表的な構成要素がクラスになるわけですが、このクラスの説明についてはここでは省略します。とりあえず、Java のプログラムを組んだことがあるかたであれば、クラスという概念についてはご存知でしょう。

　実際の開発では、何をこのクラスとして定義するかがポイントになってくるわけですが、次回以降のケーススタディを通してご説明していきます。

◆ パッケージ図

　パッケージという要素は、その言葉のとおり、いくつかの要素を含んでひとまとめにしたものです。上述したクラスもこのパッケージに含めることができます。また、このパッケージもそのもう一つ上のパッケージに包含させることもできます。

　パッケージ図は、このように要素をグルーピングしたり、グループ間の依存関係を定義するために使用します。なお、正式にはパッケージ図という言葉は OMG における UML 仕様では定義されていません。パッケージはあくまでもクラス図で扱う一要素として定義されています。しかし、このパッケージとその関係だけを定義した図は実際の開発でよく利用され、パッケージ図という名称で広く普及しています。

◆ オブジェクト図

　クラス図とよく似ているのですが、オブジェクト図はある時点でのクラスから生成されたオブジェクト間の関係を示したものです。例えば Java 言語で言えば、クラス図がソースコード上のクラス構造を表現しているとしたら、オブジェクト図はその Java プログラムが実行されたある一時点でのメモリ上のオブジェクト ( インスタンス ) の関係を表します。

◆ シーケンス図・コラボレーション図

　これらはどちらも、ある機能を実現するために、システムの構成要素 ( オブジェクト ) がどのように協調動作する必要があるかを表現したものです。これら二つの図をまとめて相互作用図と言います。

　これら二つの図は、好みにもよりますが、その図で明確にしたい点がなにかによって使い分ければよいでしょう。例をあげれば、シーケンス図は相互作用の順番を明確に表現することを得意とします。それに対し、コラボレーション図は、協調動作 ( コラボレーション ) における各オブジェクトの役割が見やすいという利点があります。筆者は、より上流段階の作業においてコラボレーション図を多用します。

◆ ステートチャート図

　あるオブジェクトの状態が、外部からのイベントなどにより、どのように変化するかを示した図です。実際の開発においては、オブジェクトの状態だけではなく、システム全体や、ユースケースの実行状態など、状態やその変化を表現する目的全般に使われます。

◆ アクティビティ図

　処理や業務の流れ ( ワークフロー ) を表現するのに利用されます。前者の目的で利用した場合はいわゆるフローチャート、後者の目的で利用する場合は業務フローとして以前から広く利用されていたものとほぼ同様なものです。

◆ コンポーネント図・配置図

　システムの物理的な構成を表現するのがコンポーネント図と配置図です。コンポーネント図は、システムを構成する物理的要素 ( コンポーネント ) や、それら要素間の依存関係などを表現します。

　配置図は、コンポーネント図で定義されているコンポーネントが、実際にどの機器 ( コンピュータやその他の装置 ) に配置され、稼働するかを示すものです。

　中堅ソフトウエア会社に勤める Chen 君は、ある日の午後、Jun 先輩に呼び出された。Chen 君は今回転勤した Mika さんの後任として、Jun 先輩のチームに配属されたばかりなのだが・・・

	Chen 君。Mika が転勤したのは知ってるよね。
	はい。 ( いやな予感・・・ )
	そこで君にお願いなんだけど、うちのグループで標準にしているスケジューラソフトあるでしょ。あれ、彼女が片手間に Java で作ったんだけど、なんてったってタダだし結構便利なんだよね。でも、ちょっと機能が足りないので追加して欲しいんだけど、いいかな。
	今、仕事もひと段落ついていることだし、いいですよ。で、当然ドキュメントとかあるんですよね？
	いや〜、それがないんだよね ( キッパリ ) 。君も UML については結構勉強しているようだし、ついでにドキュメントの作成もしてみないか。君のためになると思うよ。
	( ・・・・・ )
	じゃあ、追加してほしい機能とソースコードの場所をメモに書いておいたので後はよろしく。一週間もあればできるよね。それじゃ。

　Jun 先輩は一枚のメモ用紙を残して去っていくのであった。

　Jun 先輩から渡されたメモ用紙には、次のような機能の追加要望が書いてあった。

　「予定の時間になったら何らかの方法で知らせてくれる、アラーム機能の追加」

　「まずは、現状のプログラムの調査から初めてみるか。」
　Chen 君は、指定された場所に置いてあったソースコードを自分の PC のディレクトリにコピーしてコンパイル後、早速実行してみた。その結果、次のような画面が表示された。これがメインの画面らしい。

　日付の部分をクリックしてみると、予定を入力する画面がポップアップ表示された。この画面からスケジュールを入力するようだ。

　試しに予定入力をしてみると、予定を入力した日付が黄色くマークされた。

　再度、マークされた日付をクリックしてみると、今度は先ほどとは違う画面が表示された。どうやら、すでにその日にスケジュールが入力されている場合はこのような画面が表示されるようだ。

　この画面では、さらに予定の追加や編集・削除ができるようだ。Chen 君はこれらの機能を整理してメモにまとめてみた。

• カレンダー画面を表示する
• 予定を入力する
• 予定を削除する
• 予定編集する
• 一日の予定一覧を表示する

　「さて、機能や画面の使い方もわかったし、早速ソースコードを解析しながらUMLでのドキュメント作成を始めるかな。 ( ワクワク ) 」