|
[2006 年 4 月号] |
［技術講座］
正木威寛 PMP
※本稿は、技術評論社刊『JAVA PRESS Vol.42』に掲載された記事「大規模プロジェクトにおける UML 活用の業」を加筆、修正したものです。JAVA PRESS 編集部の了承を得たうえで転載しています。
※一切の転載をお断りします。
筆者は，お客様の企業やプロジェクトのために UML を使った開発プロセスを策定したり，その実践をサポートする仕事が多いのですが，開発者の方がいざ UML でモデリングを始めると，ときには開発者のほうが行き詰まってしまうことがあります．このうちの大半は，UML やオブジェクト指向，そして開発ツールへの不慣れが原因ですが，一方で開発プロセスの策定時には予想していなかったケースで，どのように UML で表せばよいのかわからないために行き詰まっていることもあります．このような想定外のケースというのは，UML の教科書にはあまり取り上げられていないが，実際のビジネスシステム，特に大規模の開発ではよく遭遇するものも少なくありませんでした．
本稿では，このようなケースから
をピックアップし，そのときにどのようにモデルとして表せばよいのかを紹介していきたいと思います．
エンティティクラスとは，対象業務において扱われる重要な概念を表すクラスです．エンティティクラスのオブジェクトは，業務フロー上の作業で作成／更新／削除されたり，次の作業や他の業務フローへ渡されたりします．場合によってはエンティティの有無や状態が業務フローの流れを変えることもあります．ここで，業務フローでソフトウェアが支援する作業や，自動化する作業がユーザから見たソフトウェアの機能，すなわちユースケースになります．したがって，エンティティは，業務フロー内や複数の業務フローを横断して存在し，ユースケースの終了後も存在することを設計では考慮する必要があります．このようなオブジェクトがユースケース終了後も存在（＝永続化）するための技術的な実現手段としては，リレーショナルデータベース（RDB）やEntityBeanとRDBの組み合わせなどが思い浮かぶことが多いでしょう．
前述のとおり，エンティティクラスは業務上の概念ですので，業務フローなど業務に関するモデリングや，ユースケースのイベントフローの記述などユーザから見た機能の定義を通して識別されます．エンティティクラスを識別しクラス図へまとめる作業は，「ドメインモデリング」と呼ばれることもあります．その成果物であるドメインモデルは，あくまで概念的なモデルで，直接RDBとやりとりするのか，Entity Beanを使うのか，フラットファイルで十分なのかなど技術的な実現方法の選択はされません．このような技術的な実現方法の選択は設計で行い，アプリケーションの設計と区別して「ソフトウェアアーキテクチャ設計」と呼ばれます．
一方，従来のデータモデリングでは，ドメインモデルにあたるモデルを「論理データモデル」と呼び，実際にRDBに定義されるテーブルを表したものを「物理データモデル」と呼びます．物理データモデルでは，カラムにDBMS固有のデータタイプが割り当てられたり，パフォーマンスなどの機能外要求を満たすために非正規化が行われたりします．
それでは，オブジェクト指向開発において，いつ，どのようにデータモデリングを行うのかという話をします．まず，論理データモデルですが，UML で描いたドメインモデルで目的が達成できますので，あえて別にモデルを作成する必要はないでしょう．一方の物理データモデルは，ドメインモデルをインプットとして作成できるかというとそうでもありません．なぜならば物理データモデルに対応するRDB上に作られるテーブルは，ドメインモデルではなく設計モデルに表されたクラスと双方向に変換できる必要があるからです．このようなクラスとRDBのテーブルとの間の変換ルールを，「ORマッピング」と呼びます．設計モデルは機能外要求を満たすソフトウェアアーキテクチャを反映したクラス群で，設計モデルを考慮せずにデータタイプの割り当てや非正規化を施した物理データモデルを設計するのは良い方法とは言えません．しかし開発の現場では，従来の開発で処理とデータを分担して設計していた慣習によって，異なるチームで設計モデルと物理データモデルの設計が行われ，複雑な変換を要求されたり，パフォーマンスが思うようにでなかったり，混乱を生んでいることも少なくありません．
ここで，ORマッピングがオブジェクト指向による設計モデルやソフトウェアアーキテクチャ設計と切り離して検討できない例を紹介します．図1は，クラスの汎化が行われている設計モデルですが，このような設計モデルとテーブルとでは，どのようなORマッピングがありえるでしょうか？ 代表的なものには図2，図3，図4の3つがあります参考文献1．どのパターンにも，メリット，デメリットがあり，オブジェクトの数，アクセスの頻度，将来予想される変更などの特性によって，適切なマッピングがあります．このことから，1つのシステムで唯一のパターンが選択されるわけでなく，クラスあるいはいくつかのクラスごとにマッピングが決定されます．また，同時に保管先もRDBであるべきか否かもマッピングと合わせて決定します．エンティティによっては，フラットファイル，CVSファイル，XMLファイルを使って永続化しても必要十分なこともあるからです．以上のように，オブジェクト指向開発におけるデータモデリングは，ソフトウェアアーキテクチャの一部としてORマッピングが検討され，設計モデルを反映したものであるべきであることを覚えておいてください．
図 1 設計モデル(説明のため日本語にしています）
図 2 Class Table Inheritanceパターン
図 3 Single Table Inheritanceパターン
図 4 Concrete Table Inheritanceパターン
J2EEの登場を境にソフトウェアの再利用は，クラスの再利用から，コンポーネントへの再利用へとシフトし，再利用される単位がより大きく，より抽象的になりました．さらにはWeb サービスやSOA（Service OrientedArchitecture）のようにシステム間を有機的に接続してシステムを構築することも行われています．一方でこのようなコンポーネントの再利用を前提としたアセットベースの開発は，それまでの開発プロセスやガイドラインではうまく表せないこともあります．
外部システムと接続するソフトウェアを開発するときのユースケースモデリングでは「外部システムは，アクターとして描きなさい」と教わった方も多いかと思います．しかし，開発済みの既存システムのコンポーネントを使った分散システムを開発する場合はどうなるでしょうか？ たとえば最近登場したインターネットのビデオレンタルシステムは，自システムだけで構築すると仮定すると図5のようになります．既存のコンポーネントを含む外部システムをアクターとしなければ同じですが，外部システムをアクターとしてユースケース図に明示的に表そうとすると図6のようになってしまいます．このユースケース図を見ただけで，既存のコンポーネントを含む外部システムをアクターとして描くと，情報のノイズが多いことが推測できるかと思いますが，さらにそのユースケースのイベントフローを描いてみると問題がよくわかります．
図 5 ○：外部システムを表記していない例
図 6 ×：外部システムをアクターとして表記した例
図7が図5のイベントフロー，図8が図6のイベントフローです．図8は，アクター「顧客」がこのユースケースの目的を達成できることを表すには，余計な情報が多すぎてわかりにくいですし，外部システムとのやりとりに目がいきがちです．しかし，ソフトウェア要求の定義は技術的な実現手段であるソフトウェアアーキテクチャを検討することではありません．また，それをユースケース図やイベントフローに一色単に表現したところで，ネットワークもH/Wも表現されていないのでは情報不足です．以上のことから，このような情報のノイズが多いユースケースモデルよりは，外部システムの既存のコンポーネントを含んでいても，図5や図7のように表したほうが望ましいです．
図 7 ○：外部システムを含めていないイベントフロー
図 8 ×：外部システムを含めたイベントフロー
ユースケースモデルと同様に，外部システムの既存のコンポーネントを含んでいるシステムの分析モデルでも，表し方に注意が必要です．分析モデルでは，アクターとの境界となりチャネルの違いとして表されるバウンダリクラス，ユースケースが参照／作成／変更／削除する情報と関連する小さなビジネスロジックを含むエンティティクラス，エンティティクラスを横断して実行されるビジネス上の手続きを表すコントロールクラス，この3種類に分類して表します．ビジネスロジックは特定のエンティティクラスに閉じたものはエンティティクラスに，エンティティクラスを横断的するようなものはコントロールクラスに割り当てます．それぞれは<<boundary>>、<<entity>>、<<control>>のステレオタイプで，図9のアイコンを使って表します．
ここで，教科書どおりに「システムの境界にはバウンダリクラスを定義する」と，図5（あるいは図6）のユースケースは図10の分析モデルのように，既存のコンポーネントを含む外部システムとの境界はすべてバウンダリクラスとして表されます．この図ではアクター「顧客」がこのユースケースを実行することにより，どのようなエンティティが関係するのかまったく読み取れません．このように分析モデルが表現している論理的なシステムに，アーキテクチャで表されるべき物理的なシステムの境界を持ち込むと，本来の目的である論理的なシステムが表現されなくなります．そこで，既存のコンポーネントを識別でき，分析モデルとしての本来の目的も達成できるために工夫したのが図11です．通常の分析モデルと同じ表現ですが，既存のコンポーネントが識別できるようにエンティティクラスに網掛けして表しています．この場合，実際にソフトウェアがどのような技術的な手段で既存のコンポーネントを利用するのかは，ソフトウェアアーキテクチャ設計に任せています．
図 9 分析モデルのステレオタイプ
図 10 ×：外部システムがすべてバウンダリ
図 11 ○：関係するエンティティが表されている
ここ数年で，一般家庭や企業における携帯電話やインターネットの普及は爆発的で，新しいビジネスだけでなく，銀行，株取引，チケット販売，書籍販売など既存のビジネスにおいても，新たな販売チャネルとして活用されています．当初このような新規チャネルを扱うシステム開発では，ビジネスを開始することが最優先されるので，どのように構築するかはあまり考慮されていませんでした．その結果，まったく別のシステムとして開発されているケースも多くあります．しかし，近年それらのシステムも更改の時期を迎え，今度は，いかに効率よく，市場のニーズに柔軟性のあるシステムがどのようにすれば開発できるのかというところに関心が集まってきています．これにはビジネス的な背景があります．もはや携帯電話やインターネットのサービスというだけではどのライバル企業でも提供しているので，そのサービス内容を市場のニーズに合わせて，できるだけ柔軟に変更できる必要があるからです．当然そこには，できるだけ短期間，低コストという要求も加わってきます．また，このような新たなチャネルにより，当時の見込み以上に爆発的にユーザが増えてしまい，ばらばらに開発されたシステム間を連携させるのがもはや限界というケースもあります．
それでは，このようなシステムは，どのようにすれば効率よく開発でき，柔軟性を持たせることができるのでしょうか？ まず，これらのシステムは，従来の対面販売や電話，それに携帯電話，インターネットとチャネルは違いますが，ビジネスとして提供するサービスは同じことに着目してください．ビジネスとして提供するサービスが同じということは，それに関連するビジネス上の手続きや取り扱う情報は同じということです．異なるのは顧客と対話する手段つまりチャネルだけです．このことから，ビジネス上の手続きと取り扱う情報は共通で作って，顧客との対話だけを別々に作れば効率よく開発できます．サービスの変化に対するシステムの柔軟性という点でも，ビジネス上の手続きと取り扱う情報が1つであれば，何かを求めるビジネスロジックが変わったり，情報にデータ項目が追加になったりしても，変更しなければならない箇所が局所化されていますので，変更の見通しもよく，影響を小さくできます．
次に，このような多チャネルのユースケースモデリングをどうすすめればよいか，ユースケースとアクターそれぞれについて説明します．
多チャネルの違いは，ユースケース図では図12のように，汎化を使って表せます．上側にあるスーパーユースケースの定義には，ビジネスあるいはサービスとしての本来の目的を定義します．スーパーユースケースは具体的なチャネルがないので，抽象ユースケースにしておきます．各チャネルに対応するユースケースには，それぞれチャネルについて定義します（図12ではユースケース名に明示的にチャネルを示していますが，ユースケースのパッケージで分けてユースケース名を同じにすることもできます）．
このときにモデリングツールがタグ付き値をサポートしているのであれば，単位時間あたりの実行頻度，ピーク時期，セキュリティなど機能外要求に関連する項目を予め用意して，穴埋め式に記述していくことがきでます．
図 12 多チャネルのユースケース
アクターについては，2つの表し方があります．そのビジネスあるいはサービスとして区別しておく必要があるか否かで異なります．区別する必要がある場合というのは，それぞれのチャネルについて，顧客の人数や今後見込まれる増加の割合，客層や収入などの顧客属性の違いを，ソフトウェア要求を定義する上で意識しておかなければならないケースです．たとえば小売りのシステムであれば，インターネットや携帯電話での販売は，それまでの対面や電話での販売と比較して，1桁も2桁も違う顧客数を意識して作る必要がある場合があります（図13）．
図 13 アクターの汎化が有用な時
次はユースケースの分析について説明します．多チャネルのシステムは，チャネルによって手段は異なりますが，目的は同じですので，分析モデルで表現されるソフトウェアの構造から，チャネル共通の構成要素を識別できます．チャネル共通の構成要素は，目的に対して実行されるビジネス上の手続きと，その対象となるビジネス上の情報です．たとえば図14のようになります．この図のように，チャネルの違いはバウンダリクラスの違いになり，コントロールクラスとエンティティクラスには違いが現れません．このような分析モデルのクラスは，この後に行われる設計時にコンポーネントの境界を検討する上での目安として利用されます．したがって，分析でチャネルの違いとなる部分と，共通の部分を区別してモデリングしておくことは，効率的にコンポーネント開発を行う上ではとても重要です．
図 14 多チャネルの分析モデル
多チャネルにおけるモデリングで，しばしば開発者の疑問となるのは，アクターとソフトウェアの間にハードウェアが関与する場合です．典型的なのはチャネルが電話の場合で，通話する人間とソフトウェアの間に，音声自動応答装置（IVR）が使われます．
UML の教科書によっては，「ソフトウェアとやりとりするハードウェアはアクターにせよ」となっている場合もありますが，それを適用するとユースケース図は，図15のようになります．この図が奇妙な点にお気づきでしょうか？ ユースケースである「電話で航空券を予約する」は，アクターであるIVRの目的ではありません．あくまで「電話で航空券を予約する」を目的としているのは顧客です．この場合IVRはチャネルのインフラを構成するH/Wで，システムアーキテクチャ設計で決定されることです．考慮するのはソフトウェアの機能外要求やソフトウェアアーキテクチャで，ソフトウェアの機能要求の定義では，この例のように的はずれな要求定義にならないように考慮しません．他のチャネルと同様に，図16とするのが望ましいです．
図 15 音声応答装置をアクターとした場合
図 16 顧客をアクターとした場合
さらにチャネルが電話の場合に次のようなケースもあります．シナリオの最初はアクターである顧客とソフトウェアがIVRを経由して対話しますが，途中からオペレータが顧客と電話で会話して，オペレータがソフトウェアと対話する場合です．この場合，2つの表し方が思い浮かぶでしょう．
1つは，アクター「顧客」だけでなく，途中参加の担当者もソフトウェアと対話するのでアクターであるという考えです．もう1つは，担当者はIVRと同様にインフラであるという考えです．しかし，ユースケースで定義しようとしているのはソフトウェア要求であり，ソフトウェアのユーザから見た機能要求を定義していることを考えると，前者のほうが好ましいと言えます．
次に，ユースケースにどのように表すとよいのか考えてみましょう．いちばんシンプルに描くと図17のようになります．アクターが2つありますので，ユースケースを開始するアクターである「顧客」とユースケースの関連には矢印を付けて区別しています．ここで，いつも担当者に替わるのではなく，あるシナリオのときだけ担当者に替わるようなユースケースがあると，この図はそのことが十分に表せず，誤解を与える可能性があります．そのような場合には，図18のようにオペレータに交代するケースのシナリオだけ，extendを使って分けて表すとよいでしょう．イベントフローには，この交代するケースの代替フローだけextendしたユースケース「契約変更を受け付ける」に描いて，残りのイベントフローはextendされたユースケース「契約を変更する」に描きます．
図 17 シンプルな例
図 18 extendを使って表した例
音声やプッシュボタンによる対話を行う電話は，インターネットや携帯電話のブラウザによる対話よりはるかに細かくやりとりが行われます．たとえばブラウザでの入力フォームの項目1つ1つに対応する質問をシステムが行い，利用者はプッシュボタンや音声でそれに答えるという対話形式がとられます．ブラウザを使う場合には，バウンダリクラスの定義はWebページの単位を基本とすればよいのですが，音声やプッシュボタンの場合はどうでしょう？ もし何かを話したりプッシュボタンを押したりして，その返事が返される対話1つ1つをバウンダリとすると図19のようになります．見た目的にも細かすぎるのがおわかりになるかと思います．
このようなモデルを改善するには，まとまりを見つける必要があります．通常，一連の対話の中にはまとまりがあります．たとえば図16のユースケース「電話で航空券を予約する」で，システムが顧客に搭乗者の情報を質問する場合は，搭乗者氏名，搭乗者の生年月日，搭乗者の性別と分けて聞いたとしても，搭乗者の情報というまとまりがあります．図19のバウンダリクラスを図20のようにまとめると，ロバストネス図は図21のようになります．もしWebなど他のチャネルもある場合は，そのバウンダリクラスが参考になります．たとえば，チャネルがインターネットなら，Webページの入力フォーム上の見出しやレイアウトに現れています．このように，まとまりを単位に階層的にバウンダリクラスを定義することにより，図も見やすくなるばかりか，対話内容や対話順序を洗練できます．
図 19 ×：音声による対話を表したロバストネス図
図 20 ○：対話をまとめたクラス図
図 21 ○：改善したロバストネス図
再構築する現行システムがメインフレームなどで，バッチを多用している場合，ソフトウェア要求の定義でバッチをいつ，どのように検討するのかという疑問を開発者が抱かれることがあります．ここでは，バッチとソフトウェア要求定義について述べたいと思います．
ソフトウェア要求を定義する段階では，開発者が識別できるバッチは3種類あります．
図 22 ○：業務上の作業を自動で行うためのバッチ
図 23 ×：システムアーキテクチャによるバッチ
図 24 ×：現行システムのバッチ
1つめには図22のように，営業時間が終わってその日の売り上げを精算する日時処理のようなケースです．この場合，業務上の担当者（人間）がいますので，アクターはその担当者としたいところですが，コンピュータシステムによって自動的に行われますので担当者が関与することはありません．そこで，自動的にユースケースが実行されることを表すために，きっかけとなるイベントをアクターとします．この例では，イベントは精算の開始となるイベントである閉店となります．
2つめは，システムアーキテクチャで決定され，ソフトウェアへの制約となるもので，もともとの業務として見た時には，作業やユースケースとして現れません．たとえば図23のように，こちら側のシステムから外部システムのトランザクションをまとめて転送する必要がある場合です．この場合は，機能外要求として定義されユースケースとしては定義されません．
3つめは，動機として単に現行システムがバッチだからという場合で，1や2のバッチも含んでいることがありますが，そうでないバッチも含んでいます．1や2にあたらないバッチというのは，現行システムのソフトウェアアーキテクチャとして，バッチで更新するというメカニズムを当時のアーキテクトが選択したもので，これから開発するシステムに適切かどうかは再考する必要があります．たとえば，それまでにバッチで行っていた処理を，トランザクションが発生したときにリアルタイムに処理するようにすることにより，業務フロー全体のスループットを改善することができる場合があります．このような処理方式は，STP（Strait Through Processing）と呼ばれ，すでに国内でもシステム再構築の際の新たなアーキテクチャに採用されることも少なくありません．このように単に現行システムがバッチだからといってもqに該当しないのであれば，図24のようなユースケースに表すのではなく，ソフトウェアアーキテクチャ設計として今一度再検討したほうが好ましいです．
今の技術では，ソフトウェアのユーザであるアクターとの境界となる実現方法は多数あります．
スタンドアロンのJavaアプリケーションやリッチクライアントで用いられるGUIによる画面，Webページ，携帯電話のWeb，音声，プリンタで印刷するレポート（紙），PDF，Ｅメールなどさまざまです．図25は図11にEメールの通知やPDFを加え，もっと便利にしたユースケースの分析モデルです．このようにこれらを単にバウンダリクラスとして表すのは直感的ではなく，設計者やアーキテクトがコミュニケーションする図としては可読性があまりよくありません．また，これらには独自の属性が存在します．たとえばGUIやWebであれば画面のサイズ，音声であれば男性の声か女性の声かなど音声の種類，紙やPDFであれば印刷用紙のサイズ，Eメールであればhtmlのメールかテキストのメールかというように，この後のソフトウェアアーキテクチャ設計やアプリケーションの設計への重要な情報となるものがいろいろあります．
これらの情報を UML のモデルとしてうまく取り込むには，バウンダリクラスにさらに独自のステレオタイプを定義するか，バウンダリクラスの代わりに独自のステレオタイプを定義し，ステレオタイプに対応するアイコンと，重要な情報項目を定義するタグ付き値を予め定義しておく方法があります．このような特定の目的に合わせてステレオタイプ，アイコン，タグ付き値を定義した一式を「UML プロファイル」と呼びます．
UML プロファイルを利用すると図26のようになります．いかがでしょうか？ かなり可読性がアップして，クラス名で推測しなくても，一目で画面なのか，PDFなのか，メールなのかわかりますね．わかりやすい分析モデルは，ソフトウェアアーキテクトにそのユースケースで必要とされるソフトウェアアーキテクチャを示唆しますし，設計者は対応するメカニズムが探しやすくなります．
なお，UML プロファイルは，UML モデリングツールによってサポートしているもの，サポートしていないもの，サポートしていてもタグ付き値の印刷ができないものなどさまざまですので，UML プロファイルの利用を検討される場合には注意が必要です．
図 25 UML プロファイルを使わない例
図 26 UML プロファイルを使う例
本稿では，大規模開発などの実際のビジネスシステムを開発する際に，UML を使って開発者の方がどのようにモデリングすればよいのかわからなくなるケースで頻出するものをピックアップして紹介しました．もし同じケースでモデリングする手が止まってしまうことがありましたら，ここに紹介したモデリングの方法が参考になればと思います．
| © 2005 正木威寛 |
|
