第3回　UMLモデリングによる設計の流れを理解する

樫山友一
2002/3/26

　前回「Webサイト設計時の考慮点を知ろう」までで、Webサイトの開発スタート時に必要な情報が明らかになりました。今回からは、いよいよWebサイトの開発を始めます。ECサイトなどの開発を例にするのが一般的かもしれませんが、現在の傾向として、Visual Basicなどのクライアント／サーバシステムからの移行案件が非常に多いようです。そこで今回は簡単な受発注システムの例を挙げることにします。さらにここでは、最近のトレンドであるUMLを使った開発手法を解説します。UMLについては筆者の著書『わかりやすいUML』（オーム社）が出版されています。本連載の補助的な資料としてご利用いただければ幸いです。また、Java Solutionでの連載「初歩のUML」も参考になるでしょう。

　さっそく本題に入りましょう。まず、大きな開発の流れを以下に示します。

図1 開発の流れ

　図1に開発の流れを示します。筆者が一般的に行う流れであり、開発を行う人によってこれはさまざまです。また、プロジェクトの内容や参加する人のスキルに応じてプロセスを変化させる必要があります。

　ここでは、プロジェクトの流れを説明するために、前述したように簡単な受発注システムの開発を例にしてみましょう。システムの要件を以下に示します。

受注システム
オペレータは、FAXか電話にて顧客から注文を受ける。注文を受けたときに顧客データをチェックし、登録されていなければ顧客の登録を行う。その後、注文を受けて請求書のデータを作成し、請求書をプリントアウトして顧客に発送する。

オペレータは、顧客から注文の問い合わせに応じてオーダーを変更することができなければ、キャンセルをすることもある。

　

 概念モデルの作成

　プロジェクトの参加者に、開発するシステムに対する知識がないような場合に行うと効果的です。ここでは、開発するものがどのようなものなのかを明らかにするために、現実の世界をなるべくそのままオブジェクトとしてとらえてモデルを作成します。このフェーズでは、モデルはプラットフォームや言語にまったく依存しない形で作成します。また、オブジェクトの名前も日本語で行った方が分かりやすくてよいでしょう。

図2 概念モデル

　図2に概念モデルを示します。ここから以下のようなことが読み取れます。

  • 請求書は、1つの顧客に対して1つ作成される
  • 請求書には、複数のオーダーが記載される
  • 1つのオーダーは、1つの商品についてのものである
  • オペレータは、請求書の作成・参照を行う
  • オペレータは、請求書オブジェクトを通してオーダーオブジェクトを扱うことになる
  • オペレータは、顧客オブジェクトの作成・参照を行う
  • オペレータは、商品の管理を行う

　上記のリストは、実際には顧客から聞き出してモデルに反映させた結果です。ここではモデルから読み取りましたが、皆さんは、上記のリストのような情報から概念モデルを作ることになります。

　この段階で、請求書とオーダーの関係や商品とオーダーの関係などが明らかになりました。また、オペレータの役割も分かりました。

　続いて、より日常の業務を正確にシステム化するためにユースケースを書きましょう。

　

 ユースケース

　まず、システムの全体を見るためにユースケース図を書いてみましょう。

図3　ユースケース図

　ユースケース図は、システム全体を見渡せるという点において優れていますが、実際のシステムの動作の定義は、それぞれのユースケースについて細かく記述する必要があります。特に例外処理は、システムの振る舞いとして重要です。想定される例外処理を記述しましょう。以下に１つの例を示します。

ユースケース： 顧客情報を入力する
概要： 顧客情報をデータベースに登録する
アクター： オペレータ
動作詳細： このユースケースは、オペレータが顧客からオーダーを受け顧客登録画面を選択したときに開始される。オペレータは、まず顧客検索画面で検索を行い、指定されたデータが検索されなかった場合、顧客登録画面を選択して新規顧客として登録を行う
例外処理： 新規登録時に誤った情報を入力してしまった場合は、顧客削除画面を選択して、削除を行う。また、同姓同名の顧客を入力した場合は、警告画面として同姓同名者のリストを表示する

　

 分析モデル

　分析モデルでは、オブジェクトの振る舞いも記述します。このモデルでは、まだ実装に依存しない形でモデルを作成していきます。

図4　分析モデル（1）

　分析モデルは、概念モデルをベースとしてシステムの動作とオブジェクトの役割を考えながら作成します。図4に作成中の分析モデルを示します。大きくは管理を行うためのオブジェクトとデータとして扱われるオブジェクトに分かれています。この管理がつくオブジェクトは、実際にデータとして扱われるオブジェクトを生成したり、検索などを行ったりします。今後、設計が進んでいくとこれらの役割を基にJ2EEの中でどの技術を利用するかといった判断に利用されます。よって、オブジェクトの役割を明確にするためにそれぞれのクラスにステレオタイプとして、以下のものを付けておきましょう。

Entity： データを表すステレオタイプ
Control： データを利用して、ロジックを実装したオブジェクトを表すステレオタイプ

　ステレオタイプを記入した分析モデルを図5に示します。請求書は、複数のオーダーを持ち、担当のオペレータと関連付けられています。また、請求書は必ず１人の顧客に対して発行され、関連付けられています。請求書は、複数のオーダーを持ち、オーダー商品の個数を持っているので合計金額を計算するための機能を持っています。また、顧客へ郵送する請求書を印刷するための操作も持っています。

図5　分析モデル（2）

　ここまで設計が進んでくると、ユースケースに誤りがあることに気が付きます。オペレータの新規追加やパスワードの管理などを行うためのユースケースがありません。これは、オペレータ自身がやるというよりはシステムの管理者が行うべき仕事です。そこで、「オペレータを管理する」というユースケースを追加します。

図6　修正後のユースケース図

　システム管理者がオペレータを管理するためのオブジェクトを追加しましょう。図7にオペレータ管理を追加した分析モデルを示します。

図7　分析モデル（3）

　さて、これらのオブジェクトが実際にはどのような振る舞いをするのかをシーケンス図を使って記述しましょう。シーケンス図は、すべてについて記述を行うと量が膨大になってしまうので、動作を明記しておきたいものや動作が複雑なもの、例外処理などを中心に記述します。図8に顧客からの注文処理のシーケンス図を示します。

図8　シーケンス図

　クライアントは、このシステムを利用するための端末だと思ってください。よって、クライアントから出されている矢印は、実際のオペレータが画面を操作した結果出されるメッセージです。

　ここでの要求仕様にはありませんでしたが、請求書がいくつかの状態を持つことが考えられます。例えば、郵送中であるとか、社印の押印待ちになっている状態などです。このような場合には、そのオブジェクトの状態を状態遷移図を用いて表しておきます。これにより、そのようなメッセージで請求書の状態が変化するかを定義することができます。

図9　請求書の状態図

　図9に状態遷移図の例を示します。より設計が進んでくるとそれぞれの状態間の遷移のイベントを帰休することになります。

◆

　ここまでで、開発言語や利用するプラットフォーム（OSやアプリケーションサーバなど）に依存しない設計の概要の説明を終わります。次回は、ここからいかにアーキテクチャを決定して、J2EEのテクノロジに落とし込んでいくかを解説します。

プロフィール
樫山友一（かしやま ゆういち）

大手電機メーカー研究所でオブジェクト指向によるシステム開発に従事する。1996年よりJavaへの取り組みをはじめ、J2EEアプリケーションサーバを活用したWebシステム構築のコンサルタントとして多数のプロジェクトを手掛ける。
2001年3月にイーズ・コミュニケーションズ株式会社の設立に参加し、最高技術責任者に就任。
著書に「わかりやすいUML入門」、「Webサイトがわかる本」（いずれもオーム社）がある。


Java Solution全記事一覧

Development Styleコーナー読者調査実施中
UMLモデリング、開発プロセス、ソフトウェア部品の再利用など、いま注目されているオブジェクト指向技術をベースとした開発手法についてご意見をお聞かせください。結果は統計数値として本コーナーで後日発表いたします。また、お答えいただいた方の中から、抽選でお好きなIT雑誌の1年間無料購読をプレゼントいたします。



Java Agile フォーラム 新着記事
＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

注目のテーマ

Java Agile 記事ランキング

本日 月間
＠IT