図4●「顧客情報を印刷する」というユース・ケースのアクティビティ図
図4●「顧客情報を印刷する」というユース・ケースのアクティビティ図
[画像のクリックで拡大表示]
図5●顧客管理システムのステート・チャート図を基に作成したユーザー・インタフェース
図5●顧客管理システムのステート・チャート図を基に作成したユーザー・インタフェース
[画像のクリックで拡大表示]
図6●Windowsアプリケーションのメイン・メニューを表すクラス図とイベント・ドリブンを表すコラボレーション図
図6●Windowsアプリケーションのメイン・メニューを表すクラス図とイベント・ドリブンを表すコラボレーション図
[画像のクリックで拡大表示]
図7●顧客管理システムのコンポーネント図<BR>Windowsアプリケーションとして実装した場合
図7●顧客管理システムのコンポーネント図<BR>Windowsアプリケーションとして実装した場合
[画像のクリックで拡大表示]
図8●顧客管理システムのデプロイメント図&lt;BR&gt;Windowsアプリケーションとして実装した場合
図8●顧客管理システムのデプロイメント図<BR>Windowsアプリケーションとして実装した場合
[画像のクリックで拡大表示]
図9●UML設計ツールで記したクラス図と自動生成したソース・コード
図9●UML設計ツールで記したクラス図と自動生成したソース・コード
[画像のクリックで拡大表示]

設計1●アクティビティ図の作成

 情報システムをスパイラル・モデルで構築した場合の「設計」の工程は,システムの要求分析と開発(プログラミング)を結ぶための作業となる。要求分析で作成された各種の図を詳細化するのも設計の作業である。

 設計工程の最初の図として,アクティビティ図を作成しよう。アクティビティ図はステート・チャート図と同様にシステムの状態の変化を表す図であるが,オブジェクトの動作(アクティビティ)に注目している点がステート・チャート図と異なる。ステート・チャート図の矢印の上に書かれていた状態変化の要因が,アクティビティに相当する。

 アクティビティ図は,ユース・ケースごとに作成する。図4[拡大表示]は,「顧客情報を印刷する」というユース・ケースのアクティビティ図である。両端が半円の長方形にアクティビティ(「[印刷]ボタンをクリックする」など)を記し,状態の変化を表す。アクティビティ図は「○○する」,「△△する」…のように流れを表すことになり,その点は従来のフローチャート*に似ている。

設計2●ユーザー・インタフェース設計

 既にお気付きかもしれないが,UMLの図を基にユーザー・インタフェース設計(画面設計)を行うことができる。例えば図3に示したステート・チャート図から,図5[拡大表示]のようなWindowsアプリケーションのユーザー・インタフェースが設計できる。メイン・メニュー画面と複数のサブ画面が設計でき,図5ではメイン・メニュー画面とサブ画面の一つである顧客情報登録画面を示した。ユーザー・インタフェースの設計においても,UML図は役に立つ。

 少し話がそれるが,WindowsのようなGUIベースのアプリケーションを作成する場合,クラス設計が悩ましい問題になる。それは,開発ツールが提供する「ボタン」や「フォーム」などのクラス・ライブラリを,クラス設計でどのように扱うべきかに対して明確な答えが無いからである。GUIとロジック(内部的な処理)を分離して考えることも,GUIとロジックをまとめたクラスとして考えることもできる。理想的にはGUIとロジックは完全に分離させるべきだが,あまり複雑にならないなら,部分的にGUIとロジックが混在するクラスがあってもよいだろう。ただしその場合には,GUIのクラス・ライブラリを含んだクラス図を設計することになる。

 図6[拡大表示]左は,Windowsアプリケーションのメイン・メニュー画面のGUIを表すクラス図の例である。ボタンを5つ持ったフォーム(ウインドウの土台)を表している。フォームとボタンは,包含関係にある。<<Form>> と <<Button>> は,クラス・ライブラリの「フォーム」と「ボタン」を示すステレオタイプ*である。このようなステレオタイプはUMLで規定されているわけではなく,開発者の判断で自由に追加してよい。

 また,Windowsアプリケーションのユーザー・インタフェースは「○○すると△△が実行される」というスタイルで動作し,これをイベント・ドリブンと呼ぶ。イベント・ドリブンは,オブジェクト間のメッセージ・パッシングに置き換えられる。例えば「ボタンをクリックすると計算結果を表示する」というイベント・ドリブンなら,ボタン・オブジェクトがフォーム・オブジェクトの「計算結果を表示する」という操作を呼び出すことで表せる(図6右)。

設計3●コンポーネント図の作成

 コンポーネント図は,システムを構成する個々のファイルとその関連を表す図である。Javaでプログラムを記述する場合には,拡張子が「java」となっているファイルがコンポーネントの単位となる。Visual BasicやVisual C++でプログラムを記述する場合には,拡張子が「exe」である実行ファイル,拡張子が「dll」や「ocx」の動的ライブラリ・ファイルなどがコンポーネントの単位となる。コンポーネントの依存関係*1は,破線の矢印で示す。

 例題として取り上げている顧客管理システムを米Microsoftの開発ツール「Visual Basic」で作成し,それが「Kokyaku.exe」,「Msvbvm60.dll」,「Spread.ocx」,および「Mfc40.dll」という4つのコンポーネントで構成されているとする。その場合のコンポーネント図は図7[拡大表示]のようになる。ここでは,Kokyaku.exeがMsvbvm60.dllとSpread.ocxに依存し,Spread.ocxがMfc40.dllに依存していることを表している。

設計4●デプロイメント図の作成

 コンポーネントの配置方法を表すデプロイメント図は,システムのインストールなどに関連する。デプロイメント図はシステム開発が完了してから考えればよいわけではなく,設計の段階から完成したシステムをどのように配置すればよいかを取り決めておくべきである。

 図8[拡大表示]は,スタンドアローンのWindowsマシンに顧客管理システムを配置するためのデプロイメント図である。PC本体,ディスプレイ,プリンタといった物理的な装置を箱型の図記号(ノードと呼ぶ)で表し,ノードの関連*2を実線で結んで示す。

 図8中の「<<」と「>>」で囲んだものはステレオタイプであり,<<Processor>> はPC本体を,<<Device>> は周辺装置を表す。キーボードやマウスのようにPC本体に必ず付属しているようなデバイスは省略している。

 ノードの図記号の中には,そこに配置されるコンポーネントを記述する。アプリケーションを構成するファイルだけでなく,OSであるWindows 2000やプリンタ・ドライバもコンポーネントとなる。こうした方が,システムのインストール担当者に分かりやすいからである。

開発●プログラミング

 「開発」や「配置」の工程で,新しく作成するUMLの図はない。これらの工程では,要求分析や設計工程で作成したUMLの図を参照し,必要に応じて図を詳細化する。

 UMLの図を作成する際にRational Rose(販売は日本ラショナルソフトウエア)やVisio 2002(同マイクロソフト),WithClass(同グレープシティ)などのUML設計ツールを使った場合,その後の開発が効率的に行える。これらのUML設計ツールは,クラス図を基にプログラムのソース・コードを自動生成する機能を備えているからである。このようにUMLの図からソース・コードを自動生成することを「フォワード・エンジニアリング(forward engineering)」と呼ぶ。それとは逆に,プログラムのソース・コードからUMLのクラス図を自動生成することも可能で,それを「リバース・エンジニアリング(reverse engineering)」と呼ぶ。設計書がない既存のプログラムであっても,リバース・エンジニアリングでソース・コードからクラス図を作成できる。

 また,フォワード・エンジニアリングでソース・コードを自動生成し,手作業でソース・コードを修正した後,修正後のソース・コードをリバース・エンジニアリングしてクラス図に戻す,という繰り返しによる開発を「ラウンド・トリップ(round trip)開発」と呼ぶ。

 フォワード・エンジニアリングの具体例をお見せしよう。図9[拡大表示]上は,UML設計ツール「WithClass」で作成したクラス図である。継承関係にある2つのクラス「Shain」と「Eigyo」が記述されている。このクラス図からJavaのソース・コードを自動生成したものが図9下である。自動生成したソース・コードは中身の無いメソッド(スケルトンと呼ぶ)であり,メソッドの内容を記述すればプログラムが完成する。

配置●セットアップ・プログラムの作成

 プログラミングが完了したらテストを行い,テストが完了したらシステムをユーザーの環境に配布(インストール)する。複数のコンポーネントで構成されたシステムでは,すべてのコンポーネントをまとめてインストールするセットアップ・プログラムを作成するのが一般的である。そうしておけばシステムの運用後に何らかのトラブルが発生した場合でも,容易にシステムを再インストールできるからである。セットアップ・プログラムでは,システムを構成するコンポーネントを漏れなく網羅していることが重要になる。これは,デプロイメント図を見て確認できる。

◇            ◇            ◇

 システム開発に効果的なモデリング言語「UML」を初心者向けに解説するセミナーは,今回で最終回である。読者の皆さんには,UMLを思考の道具として気軽に使い,このセミナーで得た基礎知識をぜひ実践してほしい。市販の分厚い解説書を読み終わらなくても,UMLは書くことができる。皆さんの現状の知識だけで,オブジェクト指向で考えることができ,その考えをUMLで図示できるはずである。市販の解説書は,リファレンス的に参照すればよい。技術の世界は実践あるのみである。始めは架空のシステムでも構わないので,皆さん自身のアイディアをUMLの図で表してみてほしい。


矢沢 久雄
グレープシティ(旧文化オリエント) アドバイザリースタッフ