|
[2005 年 9 月号] |
［技術講座］
正木威寛 PMP
※本稿は、技術評論社刊『JAVA PRESS Vol.36』に掲載された記事「J2EE開発に求められるモデリング手法 第一回 ビジネスモデリングの基礎」を加筆、修正したものです。JAVA PRESS 編集部の了承を得たうえで転載しています。
※一切の転載をお断りします。
J2EE も最初のリリースから数年が過ぎました。J2EE は、確かに優れたコンポーネントの実行環境を提供してくれますし、Javaエンジニアも爆発的に増えました。日本国内の企業でも小さなプロジェクトでの検証段階が終わり、私の周りでも基幹系のシステムなど大規模開発への適用も始まっています。ですがJ2EEは、どのようにコンポーネントを設計していくのかという開発プロセスは提供していません。そのようなことから、単にオブジェクトの永続化やトランザクション管理などのメカニズムだけを目的にJ2EEを採用したというケースもありました。しかし最近の案件では、J2EEが広く認知されたことによって、経営層などプロジェクトスポンサーからトップダウンで、より効果的なコンポーネントの再利用を要求されているケースも珍しくありません。
この連載では、このようなJ2EEを使った効果的なコンポーネントベース開発(*1)のために、どのようなことを検討し、モデリングを進めていけば良いかをいろいろな切り口で紹介していきたいと思います。第１回は、適切なコンポーネントを定義するための最初の一歩となるビジネスモデリングを取り上げます。第２回はソフトウェア要求のモデリング、第３回は分析でのモデリングと順次紹介していく予定です。
(*1) Component Based Developmentを略してCBDと呼ばれることもあります。
再利用に効果的なコンポーネントベースの開発を行うには、メカニズムとしてのコンポーネントというだけではなく、企業内の複数のシステムで再利用できるコンポーネントについて考える必要があります。それには、各ソフトウェアの範囲でチューンされたコンポーネントの単位を考えるよりも前に、業務に存在する共通の概念(ビジネスオブジェクト)を基準にコンポーネントの単位を考えなければいけません。ビジネスオブジェクトがなぜ再利用に効果的かというと、
図 1のように実装上の単一のクラスよりもずっと広範囲に再利用されることと、業務上の概念そのものが変わってしまうことは、ソフトウェアや実装レベルの変更よりも可能性が低いからです。
図 1 再利用の効果
このようなビジネスオブジェクトを識別するには、今回紹介するUMLを使ったビジネスモデリングが効果的です。ビジネスモデリングは、経営層が業務を再構築するためだけのものではありません。業務をシステムとしてモデル化し、ソフトウェア開発への重要なインプットとすることができます。
今回の題材では、最初に業務を定義して、次に業務フローから業務の動的な側面をモデリングします。次にそこから業務の静的な側面をモデリングしていきます。ここでは比較的わかりやすい、ラショナルユニファイドプロセス(RUP)のビジネスモデリングのUMLプロファイルを使ってモデリングしていきます。
図 2 販売業務
顧客に商品を販売する業務です。
現在はテレホンショッピングのみですが、今回の開発でインターネットショッピングもできるようにします。
顧客は、会員制ではなく、だれでも注文できます。
決済方法は、代引きのみで販売業務の対象ではありません。
発送の準備に取り掛かっていなければ、顧客は注文をキャンセルすることができます。
顧客が、発送の状況を確認できるようにします。
最初に、検討の対象となる業務と、業務の相手を定義します。ビジネスモデリングでは、業務をユースケースのステレオタイプ<<business usecase>>で表します。業務の相手とは、サービスを受ける顧客、取引先、部署などで、ビジネスアクターと呼び、アクターのステレオタイプ<<business actor>>で表します。これらを使ってモデリングした図面を、ビジネスユースケース図と呼びます。
題材の販売業務のビジネスユースケース図を書くと図 3のようになります。この販売というビジネスユースケースは、ビジネスプロセスを含む業務のシステムであり、担当する人、ハードウェア、ソフトウェアが含まれます。ハードウェアには、コンピュータだけでなく、たとえばベルトコンベアなどの機械も含まれることもあるので注意してください。このトップレベルのビジネスユースケース図では、企業にどのような業務があるのか、どの業務を検討するのかが判別できれば十分です。図 3のように、検討対象が一つしかないのであればこの図は省略しても良いでしょう。
図 3 ビジネスユースケース図
多くのビジネスアクターは人、部署、企業などですが、特定の人や特定の企業ではなく業務から見た関係で抽象化します。
例)顧客、会員
業界や社内で既に使われている呼び方がある場合は、それを優先してください。
識別したビジネスアクターに関するメトリクスも収集しておきます。たとえば現在の顧客数や、年間の顧客数の推移などです。このようなメトリクスは、実現する業務システムの達成基準やその根拠となりえます。
この後に、業務の流れや構造を識別するために、ビジネスユースケースをビジネスアクターが利用する単位まで詳細にします。
図 4 詳細なビジネスユースケース図
ビジネスアクターから見て同じサービスであれば、業務の流れが異なるケースがあることを知っていても、一つのビジネスユースケースで構いません。それは、この後の業務フローで検討します。
この後のオブジェクトや状態などの名前と、読み手が混同しないように動詞にします。主語がビジネスアクターとなるようにしてください。たとえば、図 4では「顧客は、購入する」、「顧客は、注文をキャンセルする」「顧客は、注文の状況を確認する」となっています。
それぞれのビジネスユースケースに関するメトリクスを収集しておきます。たとえば一人の顧客が１年に購入する回数や、１時間あたりに購入が利用される回数などです。このようなメトリクスは、実現する業務システムの達成基準やその根拠となりえます。
業務は、作業とその順序により実行され、ビジネスプロセスと呼びます。この作業の流れをモデリングしたものを業務フローと呼び、システム開発に限らず、業務の現場でもよく活用されます。業務フローを書くことにより、行き当たりばったりではなく、定型化されたムラがないサービスに改善したり、作業コストや作業時間を改善したりできます。
さらにシステム開発では、業務システムのそれぞれの作業を人が担うのか、ハードウェアが担うのか、ソフトウェアが担うのかを明確にし、目的とする業務(サービス)が実現できることを確認します。
それでは、これからUMLを使って、業務フローを書いてみます。
まず業務に含まれる作業とその順序を識別します。業務フローには、UMLのアクティビティ図、シーケンス図などが使えますが、ここではアクティビティ図を使うことにします。作業は、UMLのアクション状態で表記します。最初に行われる作業はUMLの開始状態を示し、最後に行われる作業はUMLの終了状態で示します。題材の「購入する」ビジネスユースケースの業務フローをアクティビティ図で表すと、図 5のようになります。
図 5 「購入する」ビジネスユースケースの作業を識別した業務フロー
見やすさの観点からアクションは、作業順に上から下へ配置します。
作業と、この後に出てくるクラスや状態などの名前とを、読み手が混同しないように動詞にします。たとえば、図 5の「注文する」という作業名は、「注文」でも誤りではありませんが、好ましくありません。
アクティビティで表す作業の粒度は、その業務の管理者が識別する必要があるか、あるいは識別できるかを目安にします。たとえば、管理者が進ちょく管理するのに適当な粒度を考えてみてください。
図 5の作業「注文を受け付ける」を「注文商品を選択する」「発送先の氏名を入力する」、「発送先の住所を入力する」「注文を確定する」としてしまうのは細かすぎます。このように細かくしすぎると、まだ範囲も決定していないはずのソフトウェアの仕様に、検討対象が脱線してしまうことがあります。
それぞれの作業に関するメトリクスを収集しておきます。たとえば必要な作業時間などでビジネスユースケースやビジネスアクターのメトリクスから導き出される場合もあります。このようなメトリクスは、実現する業務システムの達成基準やその根拠となりえます。
ビジネスプロセスにおける、それぞれの作業担当を識別します。先ほど識別した作業を、だれが担当するのか識別し振り分けます。先ほどのアクティビティ図に担当ごとのレーンを書き、担当している作業をそのレーン上に移動すれば完成です。このような業務に存在する役割をビジネスワーカーと呼び、業務にとって重要なビジネスオブジェクトの一つです。
ビジネスワーカーは、クラスのステレオタイプ<<business worker>>で表します。図 5の業務フローに、ビジネスワーカーごとのレーンを追加し作業を割り振ると、図 6のようになります。
図 6 レーンを追加した業務フロー
実際のビジネスワーカーの多くは人ですが、特定の人名ではなく業務から見た役割名にします。既存の業務であれば、○○係、△△担当など肩書きが業務上の役割名を表していることも多いでしょう。
例)テラー、売り場担当、お客様係
業界や社内で既に使われている呼び方がある場合は、それを優先してください。
読みやすさの観点から、ビジネスアクターに対応するレーンは、業務フローに参加する順に配置します。開始状態は左上になり、右下に向かっていきます。
作業の対象や、作業を開始するきっかけとなっているオブジェクトを識別します。作業の対象となっているオブジェクトとは、その作業によって作成されたり、変更されたり、削除されるオブジェクトで、作業名に現れていることもあります。作業を開始するきっかけとなっているオブジェクトとは、あるオブジェクトが所定の状態の時に作業を開始しなければならないものです。
このようなオブジェクトをビジネスエンティティと呼び、これも業務にとって重要なビジネスオブジェクトです。ビジネスエンティティはクラスとして識別され、クラスのステレオタイプ<<business entity>>で表します。
アクティビティ図では、業務フローに関係するビジネスエンティティは、オブジェクトフローとして表記します。図 6の業務フローに、それぞれの作業に関係するビジネスエンティティを追加してみると図 7のようになります。ここでは、ビジネスエンティティはアイコンを使って表記しています。
図 7 オブジェクトフローを追加した業務フロー
ビジネスエンティティは、業務で取り扱われるオブジェクトをクラスとして識別したものですので名詞にします。クラスは、実体ではなくその実体に含められる概念を優先してください。たとえば図 2の業務イメージでは、注文を受け付けると注文書が作成されていますが、注文書は注文を紙に表したものですので「注文」というビジネスエンティティ名にしています。
既存システムをベースに、ビジネスエンティティを検討し始めると、ついつい既存のソフトウェアの処理を連想してしまい、業務フロー上の作業の説明にも現れないような小さなオブジェクトやDBMSのテーブルを検討してしまうことがあります。それはこの先で検討することで、ビジネスモデリングの目的ではありませんので、ここでは検討する必要はありません。
作業から作業へ引き渡されるビジネスエンティティがある場合は、それまで表記していた遷移は冗長ですので省略します。
多くの業務では、ビジネスエンティティの状態の変化が業務フローを駆動しています。そのような状態や作業上識別しなければならない状態は、オブジェクトフローに明示しておきます。
状態遷移のトリガーとなるイベントが起きない限り、状態は変わりません。既に業務で使われている適当な状態名がない時は、なるべく持続することを表す名前にします。
それぞれのビジネスエンティティに関するデータを収集しておきます。たとえばそれぞれのビジネスエンティティの数やその推移などです。
ここでは、業務フロー上のどの作業を、これから開発するソフトウェアが実現するのかを決めます。
ソフトウェアによって実現される作業には、ビジネスワーカーに替わって完全に自動化されるものと、そのままビジネスワーカーが作業をするが、ソフトウェアによって支援されるものがあります。
この題材では、作業「発送の準備をする」と作業「注文商品を配送する」は、支援するように実現することとします。作業「注文を受け付ける」は、少し特殊なケースで、インターネットショッピングでは顧客が直接購入できるように完全に自動化され、テレホンショッピングでは受付担当を支援するように実現します。
ここまでに作成した業務フローは、ソフトウェアが自動化するのか、支援するのかを検討するのにはちょうど良いのですが、作業「発送の準備をする」と作業「注文商品を配送する」のような支援する場合は、手作業も含まれるので、より詳細に検討する必要があります。その場合は、その作業に対して別にアクティビティ図を書いて、ソフトウェアが支援する範囲を明らかにしていきます。
図 8は作業「発送の準備をする」に対して、図 9は作業「注文商品を配送する」に対して、詳細なアクティビティ図を書いています。ここでは支援する範囲を検討した結果として、支援しない作業はグレーに色分けしています。
図 8 作業「発送の準備をする」の詳細
図 9 作業「注文商品を配送する」の詳細
ここまでの書き方で「注文をキャンセルする」業務フロー、「配送状況を確認する」業務フローについて書くと 図 10、図 11のようになります。
図 10 「注文をキャンセルする」 業務フロー
図 11 「配送状況を確認する」業務フロー
各業務フローに登場したビジネスワーカーやビジネスエンティティをクラス図に整理します。この題材では業務フローによって、登場するビジネスワーカーやビジネスエンティティがそれほど変化しないので、このクラス図を書く意味があまり感じられないかもしれませんが、業務によっては業務フローごとに異なるビジネスオブジェクトが関連している場合もあります。その場合は、図 3のビジネスユースケースで表した業務が、結局どのようなビジネスオブジェクトで構成され、関連しあっているのかが、このクラス図で整理されることになります。題材をモデリングすると図 12になります。
図 12 「販売」ビジネスユースケースを実現するクラス図
図 12のように、クラス図にビジネスアクターを示すと、業務システムとしてどのビジネスワーカーがビジネスアクターと関連しているのかが明らかになります。
業務フローは、業務の動的な側面をモデリングしたもので、業務に参加するビジネスオブジェクトであるビジネスワーカー、そこで取り扱われているビジネスオブジェクトであるビジネスエンティティを識別できました。ここでは、これまでにわかったことから、静的なモデリングを行います。
業務フローで識別したビジネスワーカーをクラス図に整理します。業務フローで割り振られた作業は、ビジネスワーカーの操作として表記します。同様な作業がある場合、割り振りが適当か、あるいは上位概念の役割がないか検討します。上位概念がある場合は、汎化を使ってモデリングします。この題材はシンプルですが、図 13のようになります。
図 13 ビジネスワーカーのクラス図
業務フローで識別したビジネスエンティティをクラス図に整理します。
ビジネスエンティティ同士に、どのような関連があるか、業務フローやビジネスエンティティの記述から識別します。ここでも上位概念がある場合は汎化を使ってモデリングします。ビジネスエンティティで注意しなければならないのは、業務フロー上のある作業で複数のビジネスエンティティが関係している場合、そこに現れていないビジネスエンティティが存在することがあります。この題材では、作業「注文を受け付ける」でビジネスエンティティ「注文」と「在庫」オブジェクトフローとして示されています。この「注文」と「在庫」には、共通する概念「商品」があります。クラス図に表すと図 14のようになります。
図 14 ビジネスエンティティのクラス図
それぞれのビジネスエンティティの状態をステートチャート図に整理します。
ビジネスエンティティの状態は、各業務フロー上のオブジェクトフローに既に識別されていますので、それらをビジネスエンティティ単位にステートチャート図にまとめます。遷移も各業務フローからどの状態からどの状態に変わったか読み取れます。
図 15 ビジネスエンティティ「注文」のステートチャート図
読みやすさの観点から、開始する状態を上か左に書いて、おおよそ下あるいは右に遷移していくように書きます。
状態遷移のトリガーイベントは、そのオブジェクトが知り得るイベントでなければいけません。業務フロー上の作業によって状態が変わる場合、作業によってそのオブジェクトが知り得るイベントは何かという観点で書いてください。
たとえば図 15で、注文オブジェクトの遷移のイベント名は、作業「注文をキャンセルする」に対して「キャンセルされた」となります。
状態遷移のトリガーイベントが起きている時間は一瞬です。読みやすさの観点から、持続するように読み取れるイベント名は好ましくありません。何かが開始した瞬間なのか、終わる瞬間なのか読み手にわかるようにします。たとえば図 15で、注文オブジェクトの遷移のイベント「キャンセルされた」が、「キャンセル」ではキャンセルの作業が開始した瞬間なのか、完了した瞬間なのか読み手がわかりません。
今回は、検討の対象の業務をビジネスユースケース図、詳細なビジネスユースケース図に表し、そのビジネスユースケースを実現する業務システム内部の振る舞いを業務フローとクラス図にモデリングしました。ここまでにモデル化したビジネスワーカーやビジネスエンティティは、サブシステムやコンポーネントの目安として使われます。業務フローで識別したソフトウェアで実現する作業は、要求分析でユースケースの目安として使われます。次回は、今回のモデルから要求分析を行う手順について見ていきます。
| © 2005 正木威寛 |
|
