ホーム >  連載企画：UMLの基礎と応用 >  連載第３回 １ ２

連載第３回－２
UMLの基礎と応用

（株）NTTデータ 技術開発本部 副本部長
山本修一郎

■ユースケースのパッケージ化

　Rose2000eではモデルブラウザを用いてアクタやユースケースを移動できるので、パッケージ化のようなユースケース図の再構成ができる。
　
　それでは、早速、ボトムアップ的な階層化をRose2000eでやってみよう。

（１）ユースケース図で互いに関連する部分をパッケージ化の範囲として抽出する。
（２）ツールボックスからパッケージのアイコンを選択してユースケース図の中に挿入する。このとき適切な名前をパッケージに付ける。
（３）モデルブラウザ上にパッケージ名が付与されたフォルダがユースケースビュウの下位の階層に追加されているので、パッケージ化の範囲として抽出したモデル要素であるアクタと、ユースケースを、モデルブラウザ上で、ドラッグ＆ドロップして、目的とするパッケージのフォルダに移動する。
（４）移動元のユースケース図からパッケージに移動したモデル要素をすべて選択して、パッケージに対応するユースケース図にコピーする。
（５）移動元のユースケース図からパッケージに移動したモデル要素を削除する。

　上述したRose 2000eを使ったパッケージ化の手順を図２に示した。このようにユースケース図のパッケージ化を行うためのアクタやユースケースの編集作業をモデルブラウザ上で直接的に操作できるのは便利である。図３にパッケージで階層化して再構成したユースケース図を示す。

　モデルブラウザで、モデルに含まれるすべてのユースケースを階層化して閲覧できるのでシステム全体の構造を把握しやすいと思われる。ただし、このような手順は機械的な反復作業だけであるから、もし自動化できれば非常に便利だろう。たとえば、ユースケース図で、パッケージ化の範囲を指定するだけで、（２）から（５）までの手順を自動化できれば、再構成作業は大幅に効率化できると思われるし、パッケージ化自体の妥当性を、再構成してみてから判断することも繰り返しできるようになると思われる。したがって、パッケージ化の逆操作（いわゆるundo）もあれば便利だ。現状だと、いろいろやってみるにはそれなりの操作と時間がかかるので、大規模なソフトウェア開発の場合にはパッケージ化の範囲を良く見極めてから、編集作業を実施する必要があるだろう。

　ところで、このようにRose2000eではユースケースのボトムアップ的な再構成ができることが分かったが、パッケージ化のもう一つの方法として、トップダウンなアプローチが考えられる。図３では、編集委員会運営、論文情報管理、査読管理、投稿者管理という４個のパッケージに整理した。実はこの４個のパッケージとアクタとが次のように対応していることに気が付く。

・編集委員会運営パッケージ：編集長と編集委員
・論文情報管理パッケージ：編集係・査読管理パッケージ：査読者
・投稿者管理パッケージ：投稿者

　つまり、アクタごとにパッケージを作ればいいことになる。この理由は、もともとアクタをシステム境界の外部にある対象として抽出しているからである。システムの境界は、システムから見れば、システムの外側にあって最も不変性が高いから、それを基準にパッケージ化することでパッケージ間の関係を薄くできる可能性も高くなるのである。もし、パッケージ間の関係が強ければ、それはアクタ間の関係が強いということになり、そもそも別のアクタとして抽出してはいけない可能性がある。したがって、アクタごとにパッケージ化するというのは単純だが、比較的うまくいく方法だ。とくに大規模なソフトウェア開発の場合、ビジネスモデルが最初から明確になっている場合が多いと思われるから、ビジネスの主体としてのアクタごとにパッケージ化するほうが、はじめからすべてのビジネスフローを抽出してからボトムアップで階層化するよりも効率的だろう。次に、ビジネスモデルとユースケースの関係について考えてみよう。

■ビジネスモデルとユースケース

　たとえば、次世代ICカード研究会NICSS（the Next generation Ic Card System Study group）が提唱しているマルチアプリケーションICカードのビジネスモデル^[５][６]を考えてみよう。

　このモデルでは、ICカード発行者を保証するための発行登録機関、サービス提供者を保証するためのサービス登録機関がある。またカード発行者とサービス提供者は明確に分離されている。カード所有者は自分のICカードに、ICカード発行者が認めたサービスの中から、欲しいサービス提供者のアプリケーションを選択してダウンロードしてICカードに搭載して利用する。

　コストシェアモデルの考え方は次のようになる。カード発行者はサービス提供者とサービスを空き領域に格納するための賃貸関係を結ぶ。この賃貸関係に基づいてサービス提供者はカード発行者に、ICカードサービスを運用するための必要な経費を支払うのである。これにより発行者はサービス提供者から発行運用費を回収できる。また、カード発行者はカード利用者に対して発行費を徴収する。利用者はサービス提供者に対してサービス料を支払う。

　明らかにこのビジネスモデルのアクタは、カード所有者、カード発行者、サービス提供者、登録機関などである。

　マルチアプリケーションカードに関する業務の全体構造を表すためには、どのようなパッケージを考えればよいだろうか？ トップダウンに考えれば、カード所有管理、カード発行管理、サービス提供管理、登録管理となる。サービス提供管理をさらに詳細化することもできる。たとえば、サービス提供者の業務としてICカードに搭載するAPの管理、ICカードヘのAPのダウンロード、ICカードに搭載したAPのICカードからの削除などがあるので、この業務ごとにパッケージを作成することもできる。このような分割は機能分割に近いが、アクタを中心に分割していくことで、ユースケースモデルとしての安定性を保持できると思われる。ただし、APダウンロードなどを一つのユースケースとする考え方もある。したがって、どのレベルまでユースケースを詳細化するかは、必ずしも明確な判断基準があるわけではないので、実際のプロジェクトごとにプロジェクトの早い段階で決めておく必要があるだろう。そうしないと、プロジェクトの最終段階になって不ぞろいなユースケース図を抱えて途方にくれることになる。そうなってしまうと、本来あるべき図式ではなく、時間的な制約の範囲で作成できる図式を最終生産物として残すことになる。

■ユースケーステキスト

　ユースケーステキストにはビジネスモデルにおけるシナリオの一つを記述する。APダウンロードに対するユースケーステキストの例を図４に示す。


図4 ユースケーステキストの例

　ただし、この図では先に述べたNICSSモデルから簡略化した形で、登録機関に関する業務を省略して記述している。ユースケーステキストでも、アクタを意識した形式で業務を記述することが重要である。またこの図では確認というセクションで示したように、ユースケーステキストには関連する複数のシナリオを例外的な場合として含めることもできる。もちろん別のユースケーステキストとして独立させることもできる。その場合には、ユースケース間で関連が発生するので、これらの関連するユースケースに対してユースケース図の上で関係付けておくことが必要になる。Rose2000eでは、ユースケースを選択してマウスをダブルクリックすると仕様ウィンドウが出てくるので、その中にユースケーステキストを記述しておくことができる。

■ユースケースとアクティビティ図

　ユースケースを詳細化する図として、アクティビティ図と状態遷移図がある。Rose2000eでは、ユースケースを選択してマウスの右ボタンをクリックすると、ポップアップウィンドウが出てきて、『サブ図』というメニュを選択するとこの２つの図式をユースケースに対して選択できるようになっている。アクティビティ図を用いてユースケーステキストを書き直した結果を図5に示す。


図5　アクティビティ図によるユースケースの記述

　アクティビティ図を記述する場合、予めユースケースに対してユースケーステキストを記述しておくといい。まず、ユースケーステキストに出現するアクタに対して、『レーン』を定義する。

　レーンというのは、従来の業務フロー図では担当者の業務範囲を示すものだと考えられる。ここでは「カード所有者」「カード発行者」「サービス提供者」がレーンである。次にユースケーステキストの番号に従って、その文の主語であるアクタに対応するレーンに、その文の内容をアクティビティ名として記述していく。また番号の順序に従って、アクティビティを関係付ける。このとき、必要があればアクティビティを追加する。たとえば、ユースケーステキストでは、「サービス提供者がAPをダウンロードする」という記述しかないが、アクティビティ図では、「カード所有者がAPダウンロードを確認する」というカード所有者の動作も追加している。このように図にしたほうがより詳細なアクタ間のアクティビティを記述できるし、確認も容易になる。

　このようにして作成されたアクティビティ図の要素はモデルブラウザ上でユースケースの下に配置される。

　さて、このようにしてユースケーステキストに対するアクティビティ図を作ってみると、アクティビティがユースケースになるかもしれないことに気づく。たとえば、『APを選択する』というアクティビティはユースケースになる可能性がある。したがって、繰り返しになるが、ユースケース、パッケージ、ユースケーステキスト、アクティビティなどを用いてどのレベルまで、どのようにして詳細化するかは、ユースケースモデルでは非常に重要な判断となると思われる。

　今回は、ユースケース図の例をRational Rose2000eを用いて紹介した。次回は、相互作用を記述するシーケンス図やコラボレーション図についても紹介しよう。

参考文献
[１]ファウラ－,スコット著羽生田監訳,UMLモデリングのエッセンス 第2版,翔泳社,2000.
[２]エリクソン,ペンカー著，杉本他訳，UMLガイドブック，トッパン(原著名UML Toolkit)，1998.
[３]日本語版UML(Unified Modeling Language)ドキュメントver1.1, http://www.rational.co.jp/uml/
[４]日本ラショナルソフトウェア,http://www.rational.co.jp/
[５]次世代IC カードシステム研究会,http://www.nicss.gr.jp/main.htm
[６]遠藤力,次世代ICカードNICSS,いよいよ,エレクトロニクス,Vol.46,No.6,pp.14-17,2001．