UMLにはユースケース図やアクティビティ図,クラス図など10種類のダイアグラム(図)が定義されている。それぞれのダイアグラムは,要求定義や設計,開発のどのタイミングでどのように使っても自由である。とはいえ,それぞれのダイアグラムには使いどころがある。

 要求をモデルとして表現するために用意されているのがユースケース図である。その具体的な作り方を,ここから解説していこう。

 必要十分な情報をモデルに盛り込むには,いきなり完成型を目指して作り始めてはいけない。四つのステップを踏むことを推奨する。

ステップ1: アクターを識別

 最初のステップは,システムにかかわるアクターを識別することである(図1)。アクターとは,エンドユーザーや保守担当者,他システムなどシステムとかかわる外部の存在を指す。

図1●ステップ1: アクターを識別する
図1●ステップ1: アクターを識別する
[画像のクリックで拡大表示]

 アクターとして定義されると開発対象外となるので,このステップによってシステム開発の境界線を明示することができるのだ。

ステップ2: ユースケースを識別

 システムが何をしてくれるのかを決めるのがステップ!)である。具体的には,システムがそれぞれのアクターに提供するサービスを考える。ECサイトであれば「商品を検索する」「商品を注文する」などである。これらをユースケースと呼ぶ。ステップ!)では,アクターごとに必要となるユースケースを洗い出す(図2)。

図2●ステップ2: ユースケースを識別
図2●ステップ2: ユースケースを識別
[画像のクリックで拡大表示]

 ユースケースの設定は意外に難しい。「氏名を入力する」というユースケースを考えたとする。しかし,エンドユーザーは入力した氏名が画面に表示されても何もうれしいことはない。こういうものはユースケースにはふさわしくない。

 「預金口座を作成する」であれば,エンドユーザーはその結果に価値を感じるだろう。こういうものがユースケースにふさわしい。氏名の入力はユースケースを実現する一連の動作の一つにすぎないのである。エンドユーザーが価値を感じるかどうかという観点で判断するとよい。

この先は会員の登録が必要です。今なら有料会員(月額プラン)が12月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら