 |
[2004 年 10 月号] |
|
[2004 年 10 月号] |
［技術講座］
（株）オージス総研 筒井彰彦
※本稿は、雑誌『 JAVA Developer 』 2004 年 5 月号に掲載された拙稿「 UML の基礎固め」を加筆、修正したものです。
※本稿は、ソフトバンク パブリッシング様の承認を得て掲載しています。
JAVA Developer の Web サイト
https://www.javadeveloper.jp/
最近、Java のプログラマが UML で書かれた図を目にすることが多いのではないでしょうか。しかし、プログラマの中には、「 Java や SQL などの言語知識は実開発で応用できているが、UML についての知識を応用しきれていない」という方もいるのではないのでしょうか。具体的には、ビジネスの分析という、システム設計よりも上流の開発工程について、UML を活かしきれていないということもあるかもしれません。
そこで、本稿では、ある程度 Java のプログラミングはできるが、「もう一歩スキルアップを図りたい」という方、あるいは、 UML を応用したい方に対して、すぐに役立つ上流工程のテクニックを紹介します。
本稿で読者に知ってほしいことは、以下の 2 点です。
本稿の読者として、以下のような方を想定しています。
本稿では、UML 自体の使い方のポイントを、ありがちなシステム開発の題材を用いて説明します。さらに、IBM Rational Unified Process （以降、RUP と略します）の用語を用いて、ビジネスモデリングと要求の作業分野でどのようにシステムを開発していくのか、について説明します。
RUP には、複数の作業分野があります。システム開発の核となる作業分野と、システム開発を側面から支援する作業分野です。前者の作業分野には、ビジネスモデリング、要求、分析および設計、実装、テスト、導入があります。後者の作業分野には、構成および変更管理、プロジェクト管理、環境があります。
それでは、RUP のような開発プロセスにおいて、なぜビジネスモデリングが必要なのでしょうか。既存の業務にシステムを導入することで業務を変更する場合、ビジネスモデリングには、以下のような目的があります。
このうち、業務の流れ、すなわち、業務フローからは、構築するシステムの機能要求（ユースケース）を抽出できます。また、重要な概念、すなわち、ビジネスエンティティ（後述します）からは、分析および設計の作業分野で必要なクラスを抽出できます。
このように、ビジネスモデリングは、既存の業務を把握し、その結果をもとに新しい業務を検討するだけではありません。ビジネスモデリングは、以降のシステム開発の準備を行う役割を持っています。
システム開発において、今後もスキルの高いプログラマは必要です。しかし、ハードウェアの性能の向上、開発言語の高度化、 IDE などという開発環境の機能の向上、さらに、フレームワークの整備などにより、プログラマの意味合いは変わってくると予想できます。エンジニアとしては、プログラミングよりも、よりよい設計ができるスキル、さらには、業務を分析できるスキルを求められてきます。
RUP では、プログラマは、実装の作業分野にかかわることになります。しかし、現実的には、プログラマを担う人が、設計者も兼務している場合が多いでしょう。このような設計者兼プログラマが、スキルを伸ばすためには、UML を用いたシステム開発の手法を習得するのがよいと思います。なぜなら、UML を使うと、ビジネスモデリングからシステムの設計までできるからです。もちろん、 UML の表記法を暗記すれば、事が足りるということではありません。 RUP を開発プロセスとして使うなら、 UML を RUP の作業分野でどのように使うのか、また、 UML の各図がどのように各作業分野の成果物と連携しているのかを把握する必要があります。
UML で、ビジネスモデリングからシステムの設計までを行えるのは、 UML の表現力の豊かさにあります。 UML では、クラス図、シーケンス図、ステートマシン図などの複数の図で、システムの構造と振る舞い（動作）を記述できるのです。
図 1 では、 UML が複数の作業分野においてどのように使われているのか、および、 UML で記述した図がどのような関係を持っているのかを例示しています。
 |
| 図 1 ： RUP における作業分野の一部 |
本稿では、よくある業務を題材にして、ビジネスモデリングと要求の作業分野の成果物を一部分だけ作ってみます。題材となる業務の内容は以下のとおりです。
−・−・−・−・−・−・−・−・−・−
L 社は、全国 30 か所に店舗を有する文具チェーンである。各店舗には、オフィス向け、家庭向けなどの文具を販売する部署がある。L 社は、現在、各部署が販売する文具を仕入先に発注するためのシステムを検討中である。
L 社の現在の文具発注業務は以下のとおりである。
（1）発注係は、部署ごとの文具の在庫を確認してから、購入を依頼すべき文具の種類と数量を決定し、購入依頼票を起票している。購入依頼済みの文具が、まだ納品されていない場合には、再度、購入を依頼する場合もある。
（2）各部署が起票した購入依頼票は、各店舗の購買部に集められる。購買部は、文具ごとに指定している仕入先の名前を購入依頼票に記入する。
（3）購買部は、各部署の購入依頼票を仕入先ごとの注文票に転記し、 FAX を使ってその注文票を仕入先に送信し、文具を発注している。
システムインテグレータの R 社は、現行の文具発注業務の新システムに関して提案を行った。その提案内容は以下のとおりである。
（1）各部署に PC を設置し、発注係は購入依頼データを PC から入力する。このとき、発注係が、購入依頼済みの文具の有無、あるいは、納品されていない文具の有無を照会できるようにする。
（2）購買部は、各部署から購入を依頼された文具に対して、仕入先のコードを付与する。
（3）購入依頼データを仕入先別に分類し、営業時間の終了後に仕入先への注文票を作成する。
（4）各仕入先への注文票を FAX で自動的に送信する。
（1）今回検討対象とする業務は、発注係の購入依頼と、購買部の発注の業務である。
（2）ある文具の仕入先は複数ありうる。
（3）文具の情報（品目コードや品目名など）を登録するシステムは作成済みである。
（4）仕入先の情報（仕入先名や電話番号など）を登録するシステムは作成済みである。
−・−・−・−・−・−・−・−・−・−
それでは、この題材をもとに、ビジネスモデリングと要求の作業分野を見ていきましょう。
今回は、ビジネスモデリングの成果物として、ビジネスアクター、ビジネスユースケース、ビジネスエンティティ、ビジネスワーカー、業務フローを取り上げます。これらのうち、ビジネスアクター、ビジネスユースケースは、ビジネスユースケースモデルという成果物の一部です。また、ビジネスエンティティ、ビジネスワーカー、業務フローは、ビジネス分析モデルという成果物の一部です（厳密には、 RUP では、業務フローのことを「ビジネスユースケースの実現」と呼びます）。
これらのビジネスモデリングの成果物は、既存の業務マニュアルを収集したり、システム開発の依頼者にヒアリングしたりした結果をもとに作成します。
以下では、これらの成果物について説明します。
図 2 は、ビジネスアクターとビジネスユースケースの関係を示した図です。図 2 は、 UML のユースケース図を使って記述しています。 UML の通常の表記と異なる点は、斜線の入ったアクターとユースケースを使っている点です。これらの絵は、アクターとユースケースが、システム（情報システム）に関するものではなく、ビジネスに関するものであることを理解しやすくしています。
 |
| 図 2 ： ビジネスアクターとビジネスユースケースの関係 |
図 2 でわかるのは、以下の点です。
図 2 は、発注業務の内と外を区別しています。仕入先は、発注業務にとっては、外の会社なので、仕入先はビジネスアクターです。また、発注係や購買部は、発注業務を遂行する人や部署なので、ビジネスアクターではありません。
以上のビジネスアクターとビジネスユースケースでは、ビジネスユースケースの中でどのような業務が行われているのか、わかりません。その点は、次に示す図で記述します。
図 3 は、ビジネスワーカーとビジネスエンティティの関係を示した図です。ビジネスアクターも登場させています。図 3 は、「業務に登場する役割と、その役割が管理する情報」を記述するために存在しています。
 |
| 図 3 ： ビジネスワーカーとビジネスエンティティの関係 |
図 3 は、 UML のクラス図を使って記述しています。今回は、ビジネスワーカーとビジネスエンティティをクラスとして記述しています。しかし、 UML の長方形のクラスを使っていません。 UML のクラスの絵をそのまま使わないのは、ビジネスワーカーとビジネスエンティティを一目で理解しやすくするためです。ビジネスワーカーとビジネスエンティティの絵は、以下のとおりです。
 |
| 図 4 ： ビジネスワーカーとビジネスエンティティの表記 |
ビジネスワーカーは、業務を遂行する組織の役割です。具体的には、人、部署、会社などがビジネスワーカーです。ビジネスエンティティは、組織の役割によって管理され、生産される物です。具体的には、請求、支払、在庫などがビジネスエンティティです。ビジネスエンティティは、業務において作成されたり、更新されたり、参照されたりします。
したがって、図 3 は、どのビジネスワーカーが、どのビジネスエンティティをもとに業務を行っているのかを表しています。発注係と購買部と仕入先が UML の関連の線で結ばれているのは、その 3 者で発注業務が遂行されるからです。
以上のように、確かに、図 3 では、だれが何をもとに業務を行うのかを理解できます。しかし、どのような順番で業務を行うのかは不明です。その点は、業務フローで記述します。
図 5 は、業務フローです。
 |
| 図 5 ： 業務フロー |
図 5 は、 UML のアクティビティ図を使って記述しています。図 5 の上のほうにあるのは、ビジネスワーカーとビジネスアクターです。これらのビジネスワーカーとビジネスアクターは、先ほどの図 3 「ビジネスワーカーとビジネスエンティティの関係」に登場していたものです。
図 5 は、各ビジネスワーカーがどのような順番でどのような作業を行っているかを示しています。また、各作業で使う入力情報と、各作業を行ったときの出力情報も記述されています。例えば、購買部が「文具を発注する」という作業を行う場合、発注というビジネスエンティティを入力し、注文というビジネスエンティティを出力しています。この「文具を発注する」という作業は、題材の以下の業務要件を実現するものです。
つまり、「文具を発注する」という作業では、複数の発注というビジネスエンティティを仕入先ごとにまとめて、注文というビジネスエンティティを作成しているのです。
以上の業務フローについて、注意すべき点がいくつかあります。
まず、今回は、新しい業務フローのみを提示しましたが、実開発では、既存の業務についても業務フローを記述するとよいでしょう。新しいシステムを導入する前の、既存の業務を業務フローで整理することにより、以下の点を把握できます。
2 つめの注意点は、ビジネスエンティティの名前です。業務フローを検討するとき、ビジネスエンティティの名前を、例えば、「注文」でなく、「注文票」にしたほうがよい場合もあるかもしれません。それは、現行の業務をそのまま模写したい場合です。しかし、注文は、紙の注文票で渡す情報かもしれないし、注文画面から入力する情報かもしれません。したがって、今回は、ビジネスエンティティを単に「注文」としています。媒体にかかわらず、どのような情報が業務フローの中で使われているのかを記述するために、ビジネスエンティティを使っているからです。
3 つめの注意点は、業務フローを構成する作業の粒度をどうするかという点です。業務フローを構成する作業を切り出す際に用いる観点として、以下が挙げられます。
図 6 は、 UML のクラス図を使ってビジネスエンティティ同士の関係を示した図です。図 3「ビジネスワーカーとビジネスエンティティの関係」や、業務フローに登場したビジネスエンティティ同士には、関係があります。ビジネスエンティティのインスタンスに対して、相手のビジネスエンティティのインスタンスがいくつかあるか、という点を図 6 は表しています。具体的には、クラス間の多重度で、インスタンスの個数を表しています。
 |
| 図 6 ： ビジネスエンティティどうしの関係をクラス図で示したもの |
図 6 からわかるのは以下の点です。
このように、ビジネスエンティティ間の関係は、多重度を決めることで、各ビジネスエンティティ(のインスタンス)にとって相手のビジネスエンティティ(のインスタンス)がいくつ存在しうるかを定義しているのです。
ここで注意すべき点があります。
まず、重要な点は、ビジネスエンティティが、業務フローの入力情報および出力情報として抽出されているという点です。そうすると、重要なビジネスエンティティが、漏れることは少ないと予測できます。
もちろん、業務マニュアル、画面や帳票から名詞を取り出して、ビジネスエンティティを発見するという方法もあるかもしれません。しかし、この方法だと、名詞の数が多いため、結果としてビジネスエンティティの数が多くなる可能性があります。しかも、その抽出したビジネスエンティティの中には、ノイズ（余計な情報）が存在する可能性もあるのです。
次に注意すべき点は、多重度の意味です。多重度の「 0..1 」と「 1 」、そして、「 0..* 」と「 1..* 」はそれぞれどう違うのでしょうか。例えば、文具から見た在庫の多重度は、「 0..1 」です。この多重度は、文具のインスタンスが存在するときに、在庫のインスタンスが存在しないときもあることを示しています。例えば、新しい文具を取り扱う場合を考えてください。その場合、文具の在庫は存在しません。また、文具から見た購入依頼の多重度は、「 0..* 」です。この多重度は、文具のインスタンスにとって購入依頼のインスタンスが存在しないこともあるということを表しています。すべての文具に購入依頼を行っているわけではないからです。このように、 0 か 1 かを明記することで、業務ルール(業務の規約)の一部を定義できます。
さらに注意すべき点は、「 0 以上」であることを意味する多重度に「 0..* 」と指定している点です。「 0..* 」の多重度は、 UML の表記上は「 * 」でもかまいませんが、「 0..* 」と書くほうが誤解を少なくできます。このように、 UML の図を書く場合は、できるだけ誤解の少ない記述方法を採用すべきです。
要求の作業分野の成果物として、ユースケースモデルが挙げられます。ユースケースモデルは、システム開発の依頼者と、システム開発者との契約の役割を持ちます。
ユースケースモデルには、アクター、ユースケース、イベントフローが含まれます。また、イベントフローを検討するためには、システムの画面や帳票のイメージが必要です。
以下では、各成果物について説明します。
図 7 は、アクターとユースケースの関係を示した図です。図 7 は、 UML のユースケース図を使って記述しています。
 |
| 図 7 ：アクターとユースケースの関係を示した図 |
ユースケースは、業務フローを構成する作業の中から、自動化できるものや、ビジネスアクターを支援するものをシステム化の対象として切り出してきたものです。ユースケースと関係のあるアクターは、ビジネスアクターかビジネスワーカーのいずれかです。
図 7 からわかるのは、システムの利用者がだれであるかという点と、システム化すべき機能は何かという点です。
このユースケース図は、情報量をあまり持ちませんが、意義があります。このユースケース図は、システムを分割する単位を明示しているからです。ユースケース図は、システムを鳥瞰するために存在しています。ただし、ユースケースの詳細が別途必要です。詳細は、イベントフローで記述します。
ここで、ユースケースを検討する場合の注意点について述べます。ユースケースの名前を名詞にせず、「○○を〜する」という形式で記述しています。その理由は、ユースケース名に動詞を使うほうが、システムが何をしてくれるのかを説明しやすいからです。
以下は、画面と帳票のイメージです。
 |
 |
| 図 8 ：「文具の購入を依頼する」というユースケースの画面イメージ |
 |
| 図 9 ：「仕入れ先を指定する」というユースケースの画面イメージ |
 |
| 図 10 ：「文具を発注する」というユースケースの帳票イメージ |
要求の作業分野で作成される画面や帳票のイメージには、まだ細かい指定はありません。細かい指定とは、入出力項目やボタンという要素の配置場所、文字のフォントや大きさや色、ボタンの具体的な絵などの指定のことです。このような細かい指定は、分析および設計の作業分野で決めます。なぜなら、要求の作業分野では、システムの利用者が何をすべきか、システムの利用者に何が提供されるのか、を決めることに主眼が置かれるからです。
ユースケースごとに、イベントフローを作成します。イベントフローは、利用者とシステムとの連携を記述するドキュメントです。イベントフローで明らかになるのは、システムの利用者が何をしないといけないか、および、システムが利用者に何を提供するのか、という点です。したがって、システムが何かをすれば、それに呼応して利用者が何をするのか、さらに、利用者のその反応に対してシステムが何をするのかを、イベントフローで記述します。
今回は、「文具の購入を依頼する」というユースケースのイベントフローを以下に示します。
−・−・−・−・−・−・−・−・−・−
1. システムは、購入依頼画面を表示する。
2. 発注係は、購入依頼画面で、購入する文具の情報を入力し、 OK ボタンを押す。
3. システムは、購入依頼完了画面に購入依頼番号と、購入する文具の情報を表示する。
4. 発注係は、購入依頼完了画面で、 OK ボタンを押す。
5. システムは、購入依頼完了画面を閉じる。
2a. 発注係が購入依頼を取り消す場合
2a-1. 発注係は、購入依頼画面でキャンセルボタンを押す。
2a-2. システムは、購入依頼画面を閉じる。
−・−・−・−・−・−・−・−・−・−
イベントフローを書く場合は、新しいシステムの画面や帳票のイメージが必要です。画面や帳票のイメージがないと、システムが何を提供するのか、利用者が何をすべきか（例えば、どのような項目を画面に入力すべきか）を把握できないからです。
イベントフローには、さまざまな記述形式があります。今回は、イベントフローを基本フローと代替フローに分割しました。基本フローはそのユースケースでもっとも一般的なフローであり、代替フローは基本フローよりも特殊なフローです。
複数ありうるフローから、基本フローを選択する基準として以下が挙げられます。
したがって、あまり使われないフローは、代替フローに持っていきます。そうすることで、システムの利用者やシステム開発者が、システムに対する要求の本質的な箇所に焦点を絞り込めます。
それでは、具体的なフローはどうなっているのでしょうか。「文具の購入を依頼する」というユースケースの基本フローでは、「 1 → 2 → 3 → 4 → 5 」という流れでシステムの利用者とシステムが作業を行います。代替フローでは、「 1 → 2a-1 → 2a-2 」という流れで利用者とシステムが作業を行います。この「 1 → 2 → 3 → 4 → 5 」や「 1 → 2a-1 → 2a-2 」のような流れの1つ1つは、ユースケースの具体的な流れであるので、ユースケースのインスタンスと呼ばれます。シナリオと呼ばれる場合もあります。
ここでイベントフローに関する注意点を述べます。分析モデルでは、エンティティを検討します。エンティティとは、システムに長期間存在している情報です。今回の方法では、分析モデルのエンティティは、ビジネスモデリングで検討したビジネスエンティティをもとに作成します。ところが、エンティティを見つける方法としては、以下のような方法もあります。すなわち、その方法では、要求の作業分野で作成するイベントフローから名詞を見つけて、その名詞を整理し、その結果をもとにエンティティを定義するのです。しかし、今回は名詞を使う方法を使っていません。その理由は以下のとおりです。
以上のように、ビジネスモデリングと要求の作業分野では、 UML を活用できます。ここでは、 UML の利点を整理し、さらに、 UML の使用上の注意について述べます。
システム開発の上流工程を担う者と、下流工程を担う設計者やプログラマは、それぞれ以下のような問題意識を持っているかもしれません。
システム開発の依頼者に PowerPoint で業務内容を説明されたけれども、設計者やプログラマにどうやってこの業務内容を説明したらよいのかわからない
このような UML の図で、上流工程の担当者に自分の設計内容を理解してもらえるだろうか
このような問題の解決策の 1 つは、ビジネスモデリングと要求の作業分野に UML を使うことです。 UML という 1 つの表記法を設計者とプログラマが使うから、両者の誤解が少なくなります。しかし、それだけが UML の効果ではありません。ビジネスのどの箇所がシステム化されるのかが、 UML の図を使うことで明確になります。その点が、 UML の利点として重要です。
次に、 UML を利用する場合の注意点を列挙します。
まず、 UML の図の規模が大きくなると、モデリングツールを使うほうがよいです。なぜなら、クラス名の変更などが発生したとき、通常のモデリングツールでは、 1 箇所の変更を他の箇所にも反映してくれるからです。この変更作業を手作業で行うとすると、非常に手間がかかり、しかも、変更を間違う場合もあります。
注意点の 2 つめは、 UML の図だけがシステム開発のドキュメントではないという点です。例えば、ビジネスエンティティを定義するためには、ビジネスエンティティについて UML のクラス図を使って書くだけでは不十分です。各ビジネスエンティティの意味について、自然言語で記述する必要があります。
注意点の 3 つめは、クラス図を書くと決めた場合、何のクラス図なのかを明確にしないといけないという点です。「業務に登場する役割と、その役割が管理する情報」を示すクラス図なのでしょうか。それとも、「業務にとって重要な情報」を示すクラス図なのでしょうか。ユースケース図でも同様です。つまり、 UML では、どのような場合にどの図を使えばよいか決まっていません。したがって、もし、読者の方が「クラス図を書いてください」といわれたら、指示した方に質問してみてください。「何をクラス図で書くのですか」と。
注意点の 4 つめは、各成果物は 1 回で完成するものではないという点です。例えば、ビジネスモデリングの成果物を作成するにしても、業務フローと、ビジネスエンティティ間の関係を示す図は、一方を作成して、もう一方を作成し、さらにそれぞれを変更する、というように、複数の成果物を行ったり来たりしながら作成していきます。
上記で説明した成果物の種類や意義は、システム開発の対象によって変わるかもしれません。また、上記で説明した開発手法とは違う手法を使っている方もいると思います。
ただし、自分なりのシステム開発の枠組みを持っておけば、自分の枠組みと、他人の枠組みあるいはプロジェクトの枠組み、さらに部署や会社の枠組みとの違いを認識できるはずです。その結果、自分の枠組みを改良することもできるし、自分のプロジェクトによりよい開発プロセスを提示できるようになるはずです。
プログラマは、大規模か小規模かにかかわらず、開発プロジェクトに参加するはずです。開発プロジェクトでは、何らかの開発プロセスを用いていると思います。それが、 UML を使った開発プロセスなら「ビジネスモデリングの箇所はどうなっているのだろうか」と考えるのもよいかもしれません。また、「自分が UML で設計したモデルは、どのビジネスユースケースのどの箇所を実現したものだろうか」などと考えると、活躍の場面が増えるかもしれません。
本稿は以上で終わりです。「ビジネスモデリングに UML を使えそうだ」「ビジネスモデリングの結果が次の開発工程の入力になることがわかった」というように思っていただければ、幸いです。
| © 2004 OGIS-RI Co., Ltd. |
|
