アシアルブログ

アシアルの中の人が技術と想いのたけをつづるブログです

UMLを描こう - Vol.4 ユースケース記述

■要件定義の2つの柱
ユースケース駆動開発の要件定義では、2つのモデルを柱として要件を分析・定義します。
1つが振る舞いモデル、もう1つがドメインモデルです。

振る舞いモデルは、ユースケースモデルにあたります。
ユースケースとは、システムの利用例、つまりはユーザが利用できる具体的なサービスのことです。
例えば通販サイトでは、「商品をカートに追加する」「注文する」「配送状況を確認する」などがユースケースです。
それぞれのユースケースに対して、ユーザが何をしてシステムがどう振る舞うかをシナリオとして記述する必要があります。この記述をユースケース記述といいます。
なお、ユースケースモデルはあくまで「振る舞いに関する要件」ですので、
その他のパフォーマンス要件やセキュリティ要件などは、ユースケースにひも付けておく必要があります。

ドメインモデルについては、前回説明しました。
ドメインモデル図(以下:概念モデル図)では、ユーザが思い描く現実世界の「もの」や情報の概念を、クラス図風に簡単に表現します。


ユースケースを洗い出す
初期の概念モデル図が描けたら次にすることは、ユースケースを洗い出すことです。
通販サイトのユースケース図の例を下図に示します。



ユースケースを洗い出すときに重要なのは、機能的な大きさを揃えることです。
この図では『注文する』が他に比べて大きなシナリオを含んでいそうですので、実際には『配送先を指定する』→『支払い方法を指定する』→『注文を確定する』など、複数のユースケースに分割することも考えられます。

(※大きな楕円を用いるユースケース図がもし必要であれば、パッケージごとに子ユースケース図を作ると良いでしょう。)


ユースケース記述を書く
ユースケースがリストアップできたら、それぞれのユースケースに対してユースケース記述を書く必要があります。
ユースケース記述は2つのパートから成り、
【基本コース】という正常系のシナリオ文章と、
【代替コース】という異常系・分岐系のシナリオ文章から成ります。

シナリオを書くときは、ユーザとシステムの両方の振る舞いに注目して書きます。
つまり、ユーザがどこの画面で何をして、システムがそれに対してどのような処理をして、どのように応答するのかを、淡々と書いていきます。

ユースケース記述では特に、代替コースをきちんと漏れなく書くということが、重要になってきます。


ユースケース記述の例1. 『商品を検索する』 (ユーザ側システム)

【基本コース】
・ユーザは、検索開始画面で検索ワードを入力し「検索」ボタンを押す。
・システムは、商品名が検索ワードにマッチする商品を検索する。
・システムは、見つかった商品を、検索結果画面に表示する。

【代替コース】
検索ワードが2文字以下だった場合:
・システムは、検索開始画面を再度表示し「検索ワードは3文字以上で指定してください。」と表示する。

商品が見つからなかった場合:
・システムは、検索開始画面を再度表示し「該当する商品は見つかりませんでした。」と表示する。

見つかった商品が1件のみだった場合:
・システムは、その商品の、商品詳細画面を表示する。


ユースケース記述の例2. 『商品を登録する』 (管理側システム)

【基本コース】
・管理者は、商品一覧画面で「商品の新規登録」ボタンを押す。
・システムは、商品登録画面を表示する。
・管理者は、商品の型番、タイトル、値段を入力し、「登録」ボタンを押す。
・システムは、入力内容が正しいかチェックする。
・システムは、商品を登録する。
・システムは、商品一覧画面にリダイレクトさせる。

【代替コース】
入力内容が正しくなかった(型番・タイトルが入力されていないか、値段が1円以上でなかった)場合:
・システムは、商品登録画面を再度表示し、訂正を促すメッセージを表示する。

商品の登録処理に失敗した場合:
・TODO:どうするか議論する。


ユースケース記述のポイント
☆概念モデル図の用語を使う
例えば概念モデル図では「ユーザアカウント」と書かれているものを、
ユースケース記述で「会員情報」と書いてしまっては、読む人に混乱を与えます。
ユースケース記述では概念モデル図の用語を使うことを始めから意識しておけば、
両者の間の整合性が取りやすくなります。

☆表現を具体的にする
ユースケース記述では、ユーザの行動も取りこぼさず書き、画面名も明示的に書くなど、具体的な表現を心がけます。
曖昧でぼやけた表現は、あまり役に立ちません。ユースケース記述が曖昧でぼやけていると、設計しづらいのはもちろんですが、ユースケース記述に対応するテストシナリオも同様に書きづらくなります。
読む人がイメージできなければ、意味がありませんよね。

☆SVOルール
ユースケース記述内の文は、SVO形式で統一します。
SVOとは、英語でいう「主語-動詞-目的語」形式の文のことで、日本語だとSOV(主語-目的語-動詞)の順になります。
つまり日本語の場合、「誰が-何を-どうする。」という形式で文を統一するのです。
これを守ると、後に設計しやすいユースケース記述が書けます。

☆代替コースを書くことを怠らない
最初にユースケース記述を書いた段階では、代替コースの記述が抜け落ちていることがよくあります。
チームメンバ間でユースケース記述のレビューをすることで、そういった不足を補うことが重要です。

一番危ないパターンは、代替コースに「特に無し」と書くことです。
システムは生き物ですから、代替コースが無いユースケースはほとんどありません。
特に無しと書くよりも「未定」と書いておいたほうがむしろ安全と言えます。

文章だけでは見つけづらい代替コースもあるので、足りない代替コースに関しては、
ロバストネス図を描くことで発見します。

ロバストネス図とは、ユースケース記述(基本コース+代替コース)を、1枚の絵で表現して分析する図です。
ということで、次回はロバストネス図ICONIXロバストネス図)の描き方について、取り上げたいと思います。


参考文献
・Doug Rosenberg and Matt Stephens, Use Case Driven Object Modeling with UML: Theory and Practice. Apress, 2007.