ObjectSquare [2003 年 4 月号]

[技術講座]


Java ではじめる UML

[第6回] UML による設計とコンポーネント図/配置図の作成

高木栄児/山口健/伊藤喜一/林俊樹/森三貴/山内亨和

 最終回の今回は、前回 ( 2002 年 12 月号掲載 ) の分析結果をもとにアラーム機能の設計を行っていきます。 分析結果をもとに設計を行っていく過程や設計時のクラス図やシーケンス図の活用方法を解説していきます。また、システムの物理的な構成を示すためにコンポーネント図と配置図を作成します。


1 . 前回のおさらい

 まず初めに、前回の内容を簡単に振り返っておきましょう。

 前回はアラーム機能の要件定義、分析をユースケース、クラス図、シーケンス図を用いて行いました。ユースケースは、システムの境界を識別したり、システムが提供する機能を定義するために作成し、クラス図やシーケンス図はシステムを分析するために作成しました。

 また分析では、boundary ( バウンダリ ) 、entity ( エンティティ ) 、control ( コントロール ) の3種類のクラスを使用しシステムを構造化しました ( これは同時に変更に対する局所性を与えています ) 。前回の分析時には実際の実装環境を考慮しませんでしたが、分析ではまずシステムを理解すること、それからシステムに良い構造を与えることが大きな目的です。

 分析時に実装環境まで考慮すると、そのモデルにはいろいろな要素を盛り込みすぎてしまい、システムを理解することが難しくなってしまいます。小規模のシステムでは問題ないかもしれませんが、大規模なシステムになるほど理解は困難になります。分析モデルは実際の実装環境を考慮しないため論理的です。このため、実装言語の変更などの設計モデルに影響をあたえるような実装環境の変更があっても分析モデルをそのまま利用できます。

 第 6 回の今回は、前回の分析結果をもとにしてアラーム機能の設計を行います。設計時には実装環境を考慮し、分析モデルを洗練、詳細化していきます ( 第 6 回の内容を、より理解していただくために第 5 回の内容をご一読していただけるよう読者の皆様にお願いします ) 。


 

2. 設計

 設計を行う前に、まず実際の実装環境の制約を洗い出しましょう。


		
	ハードウェア
	実装言語
	GUI の使用
	パッケージ・ソフトウェアの使用
	永続データの存在有無
	分散性
	並行性
	実行性能
		
		

等を考えます。
 ただし今回はアラーム機能という1機能の追加であり、スケジューラ・ソフトはシンプルなシステムであるため、特に詳細な洗い出しは行わず、「 実装言語は Java 、 GUI には Swing を使用する 」程度にとどめておくことにします。

Chen's small face~ 「 設計を始める前に、分析時に作成したアラーム機能のクラス図とシーケンス図を確認しておこう。」

 分析時に作成したクラス図は図 1 、シーケンス図は図 2 のようなものでした。

図 1 :分析クラス図
図 2 :分析シーケンス図


 分析時にはシステムを理解しやすくするためクラス名を図 3 のように日本語名にしましたが、設計時には実装言語は Java であることを考慮し、図 4 のように英語名に変換します。

図 3 :クラス名の日本語表記
図 4 :クラス名の英語表記


 次に、分析クラスをそれぞれ洗練、詳細化していきましょう。まずアラーム機能を起動する分析クラス 「 タイマー 」 ですが、 Java 標準ライブラリにおさめられている java.util パッケージにクラス Timer が用意されているので、これを使用することにします ( java.util.Timer の詳細については Java 標準ライブラリの API ドキュメントを参照)。ただし、クラス java.util.Timer がサポートされるようになったのは Java2 SDK Standard Edition 1.3 からです。このように設計時には使用するライブラリや製品のバージョンについてもきちんと考慮しておく必要があります。( * 1 )

 * 1 java.util.Timer と基本的な機能が同じである javax.swing.Timer クラスを使用することもできる。

 分析クラス 「 アラーム 」 を見てみましょう。クラス 「 アラーム 」 はアラーム機能をコントロールするクラスであり、クラス 「 タイマー 」 から定期的に繰り返し実行されます。これを設計クラス Alarm とし、新規に作成します。クラス Alarm はクラス java.util.TimerTask を継承してメソッド run を実装します ( java.util.TimerTask の詳細については Java 標準ライブラリの API ドキュメントを参照 )。

			
class Alarm extends TimerTask {

public void run() {

・・・略・・・

}


 スケジューラ・ソフト起動時にクラス Timer のメソッド schedule を使用してクラス Alarm を登録しておくことで、クラス Alarm のメソッド run が定期的に繰り返し実行されるようになります。メソッド run では現在日時を取得し、ある日付のある時間内に登録されているスケジュールの一覧をクラス 「 スケジューラ 」 から取得します。

 例えば、クラス Alarm のメソッド run がクラス Timer により15分間隔で起動される場合、その起動日時が 2002/12/18 13:00 だとすると、2002/12/18 の 13:00 〜 13:15 の間に登録されているスケジュールの一覧を取得します。この一覧に含まれるスケジュールをそれぞれポップアップ・ウインドウに表示すればユーザーにスケジュールを通知することができます。

 分析クラス 「 スケジューラ 」 を見てみましょう。このクラスの設計クラスは Scheduler 、クラス ScheduleList として既に存在す るため、これらを使用します( 図 5 )。クラス Scheduler とクラス ScheduleList の関係を簡単に整理しておくと、クラス Scheduler はフィールド fixedSchedules を持ち、これには Date 型( 日付 )の変数 date をキーにして ScheduleList オブジェクトが格納されています。クラス ScheduleList はフィールド schedules を持ち、これには Schedule オブジェクトが格納されています。

図 5 :分析クラス 「 スケジューラ 」 の設計クラス


 クラス Scheduler には、日付と時間の範囲を指定して登録されているスケジュールの一覧を取得するメソッドを追加します。

		
public class Scheduler {

public ScheduleList getFixedSchedules( Date date, Time from, Time to ) {

・・・略・・・

}


 また、このメソッドでは date をキーにして ScheduleList オブジェクトを取得し、ScheduleList オブジェクトが保持する Schedule オブジェクトの中からある時間の範囲内の値を持つ Schedule オブジェクトを取得するようにすれば、最終的にユーザーに通知する必要のあるスケジュールの一覧を取得できます。このためのメソッド subScheduleList をクラス ScheduleList に追加します。

		
public class ScheduleList {

public ScheduleList subScheduleList( Time from, Time to ) {

・・・略・・・

}


 分析クラス「 アラーム画面 」を見てみましょう。アラーム画面はユーザーに対して予定の日時を知らせる画面 1 のようなポップ アップ・ウインドウです。

画面 1 :ポップアップ・ウインドウ


 これを設計クラス AlarmDialog とし、新規に作成します。クラス AlarmDialog はクラス javax.swing.JDialog を継承します。なお、複数のスケジュールが登録されている場合、ポップアップ・ウインドウがまったく重なってしまわないように表示位置を調整するために、設計クラス 「 AlarmDialogController 」 も新規に作成しました。( * 2 )

		
public class AlarmDialog extends JDialog {

・・・略・・・

}

public class AlarmDialogController {

public static void show( java.util.Date date , ScheduleList scheduleList ) {

・・・略・・・

}


 * 2 ポップアップ・ウインドウを表示する場合、Swing では JOptionPane を使用するのが一般的であるが、これはモーダル・ダイアログである。これをタイマー・タスクの同じスレッド内で使用するとポップアップ・ウインドウを表示している間、タイマー・タスクの制御が中断してしまう。これを防ぐために本編ではポップアップウインドウに JDialog を使用し、モードレス・ダイアログにしている。

 このようにして洗練、詳細化は 1 つの分析クラスを 1 つの設計クラスもしくは複数の設計クラスに置き換えることで行いました。つまり分析クラスから設計クラスへの追跡が簡単に行えるようにしています。これを追跡可能性と呼びますが、こうすることで分析モデルに変更があった場合でも、対応する設計モデルに変更が局所化されます。

 こうして出来上がったアラーム機能のクラス図は図 6、シーケンス図は図 7 となります。

図 6 :設計クラス図




図 7 :設計シーケンス図


Chen's small face~ 「 ふぅ。これで、ようやく設計が終わったかな?あっ、そうだった。Jun 先輩にスケジューラ・ソフトのシステム構成図をつくるように言われていたんだった。よし、コンポーネント図と配置図を作成してみるか。」

3 . コンポーネント図

 コンポーネント図は、ソースコードやバイナリコード、実行可能コードのソフトウェア・コンポーネント構成やそれらの依存関 係を示すダイアグラムです。ここでは、実行可能コードとバイナリコードの 2 種類のコンポーネント図を作成します。コンポーネントの表記法ですが、図 8 のように長方形の左側から、さらに小さな長方形が 2 つ突き出たかたちで表現し、コンポーネントの名前はいちばん大きな長方形内に表示します。

図 8 :コンポーネント


 コンポーネントが他のコンポーネントに依存する場合は、図 9 のように破線の矢印を使用します。

図 9 :コンポーネント間の依存関係


 ここまで説明した表記法を用いて、実行可能コードのコンポーネント図を作成してみましょう。スケジューラ・ソフトは scheduler.jar という 1 つの jar ファイルにアーカイブされるため実行可能コードのコンポーネントは scheduler.jar の 1 つのみとなります。このため、実行可能コードのコンポーネント図は図 10 のようにとてもシンプルです。

図 10 :コンポーネント図(実行可能コード)


 また、バイナリコードのコンポーネント図をパッケージ domain の各クラス・ファイルをもとにして作成すると図 11 のようになり ます。

図 11 :コンポーネント図 ( バイナリコード )

4 . 配置図

 配置図は、実行時のシステム構成を管理するためのダイアグラムであり、コンポーネントがどのノードに割り当てられるのかを 示します。それでは、配置図を作成してみましょう。ただし、今回のスケジューラ・ソフトのシステム構成はシンプルですから、スケジューラ・ソフトをクライアント側に GUI 部分、サーバ側にスケジュール管理機能を持たせたクライアント・サーバ型のシステムにした場合の配置図も作成してみます。配置図のコンポーネントは実行時に稼動しているモジュールを表します。配置図のコンポーネントはインスタンスになるため、その名前文字列には下線を引きます。コンポーネントインスタンスは名前を持ち、その名前とコンポーネントタイプ名をコロンで区切って表現します( 図 12 )。

図 12 :コンポーネントインスタンス


 ノードはハードウェアなどのコンピュータ資源を表します。ノードもインスタンスになるため、その名前文字列には下線を引きます。名前文字列は以下のように名前とノードタイプ名をコロンで区切って表現します。

		
名前 :ノードタイプ名

 名前とノードタイプ名はどちらかを省略することもできます。図 13 ではノードタイプ名を省略しています。クライアント・サー バシステムのようにノード間に関係がある場合は、図 14 のようにコミュニケーション関連を使用します。

図 13 :ノードインスタンス
図 14 :ノードインスタンス間のコミュニケーション関連


 ここまで説明した表記法を用いてスケジューラ・ソフトの配置図を作成してみましょう。スケジューラ・ソフトを PC 上で動作させる場合の配置図は図 15 のようになります。またクライアント・サーバ型スケジューラ・ソフトの場合、クライアント側に GUI 部分を担当する GUI.jar 、サーバ側にスケジュール管理機能を担当する scheduleServer.jar を配置するため、その配置図は図 16 のようになります。

図 15 :配置図(スケジューラ・ソフト)
図 16 :配置図(クライアント・サーバ型スケジューラ・ソフト)


*  *  *

5.まとめ 

 設計モデルを書き終えた Chen 君のところへ、 Jun 先輩がやって来ました。

Jun's small face~ 「 どうかな、進み具合は。」
Jun's small face~ 「 分析のクラス図とシーケンス図から設計のクラス図とシーケンス図を作成し、どうすればアラーム機能を実現できるか検討しました。それからスケジューラ・ソフトのシステム構成がわかるようにコンポーネント図と配置図も作成しました。」
Jun's small face~ 「 がんばっているようだね。あとは実装とテストが残っているけど、ここままで UML を使った要件定義 → 分析 → 設計という開発工程の流れは理解できたかな。」
Jun's small face~ 「 感じはつかめたと思います。」
Jun's small face~ 「 頼もしいね。そうそう、リサ( スケジューラ・ソフトの作成者 )が週単位でスケジュールを登録できるウイークリー・スケジュール機能を追加しようとしてたけど、開発途中で転勤してしまったんだよ。今の調子で完成お願いできるかな。」
Jun's small face~ 「 ...。」

 Chen 君にかわり、ウイークリー・スケジュール機能の追加は読者の皆様にお願いすることにします。第 1 回から第 6 回までの内容はいかがだったでしょうか?筆者一同は初心者の方にもできるかぎりわかりやすく解説することに努めたつもりですが、開発現場ですぐに役立つ UML の知識を実践的に短期間で紹介したため難しくなってしまった部分もあったかと思います。先ほどの Jun 先輩と Chen 君との会話にもあったように、この連載を通して、 UML を使った「 要件定義 → 分析 → 設計 」という開発工程の流れを少しでもご理解いただければと思います。




《 参考文献 》


※この記事は、『 Java World 』 2003 年 1 月号に掲載された 「 Java で学ぼう ! 初めての UML 」 に一部加筆・追加したものです。


連載記事一覧

関連記事一覧


© 2002-2003 OGIS-RI Co., Ltd.
Prev. Index
Prev. Index