2010年06月06日

ユースケース記述が気になりますか?

このブログのアクセスログを見ると、どうもユースケース記述のアクセス数が常に上位にあるようです。
ユースケース記述(じゃなくて)に関心がある方が多いのでしょうか。
あなたは、どうですか?

ユースケース記述について、より理解を深めていただくために、ちょっと違う視点で説明してみたいと思います。
前回は、一般的なユースケース記述の書き方について、サンプルケースを使って、チュートリアルっぽく説明しました。
そこで、今回は重要なポイントに的を絞ってお話しします。

コンテンツ
  1. ユースケース記述の目的
  2. ユースケース記述の必須事項
  3. でも、結局は

ユースケース記述の目的

ユースケース記述は、アプリケーションが提供すべきサービスについて、ユーザと意識を合わせるためにあります。
ですので、ユーザにわからない用語は、使用すべきではありません
ユーザは、普通ビジネスドメインについてはエキスパートですので、ビジネス上の専門用語を使用するのは、構いません。

ユースケース記述の必須事項
前回も言ったように、ユースケース記述には、決まった形式があるわけではありません。
ただ、実際には仕様を明確にするために、「どうしてもこれだけは書くべき」と思われるものが、いくつかあります。
それは、以下の5つです。
  • 名前
    ユースケース図のどのユースケースのシナリオなのかわかるように、同じ名前をつけるべきです。
    中には、IDで対応づけを管理しているプロジェクトもあるようです。(ID?うえーっ)
  • サービスを受けるアクタ
    シナリオを理解するうえで、誰のためのものなのかは、非常に重要なポイントです。
    なぜ重要かは、次の概要/目的と同じです。
  • 概要(または目的)
    アプリケーションが、目的もなく動作するなんてことは、まずありません。
    たとえユーザが、自分は目的がないつもりでアプリケーションにインタラクトしようとしている場合でも、アプリケーション側は無目的ではありません。
    必ず、なんらかのサービスをユーザに提供することを目的にして、動いています。
    ユースケース記述は、そんなアプリケーションの目的ごとに、作成します。
    ここで記述する目的とは、どんなサービスを提供するかということにつきます。
    これが明確でないと、もう何を書きたくてわざわざ書かれたものなのか、わからなくなります。
  • 事前条件
    これは、本編であるシナリオがブレてしまうことを防ぐために、必要な記述です。
    たとえば、ショッピングサイトで「カートを見る」というユースケースが書きたいのに、「ユーザ登録」からハナシをはじめるのは、避けたいですよね。
    「カートを見る」ユースケースの前提条件には、きっと「ユーザ登録が済んでいる」とか、あるいは「ログインが済んでいる」とかいう前提条件が含まれるはずです。(この例の場合は、代替シナリオ「ユーザが未登録だった場合」を記述するというテも、あるわけですが)
  • イベントフロー(シナリオ)
    これが、待ちに待ったユースケース記述の本編ですね。
    大切なのは
    • 5W1Hに気をつけて、できる限り明確に書く
    • 本筋(基本シナリオ)をブラさない
    ということです。
    本筋をブラさないためには、枝道と考えられる筋はすべて、「代替シナリオ」や「例外シナリオ」に追い出すことが必要です。
    シナリオを書く際、「書き漏れ」を探すことは、たいていの人がするのですが、枝道の「追い出し漏れ」を探すことは、意外と忘れている人がいるのではないでしょうか。
    「足りないもの(書き漏れ)」を探すという行為は、必要なことではありますが、消極的な行動です。
    良いものを書くには、逆に「書きすぎ(追い出し漏れ)」を探すことが重要です。

でも、結局は
どんなフォーマットやテンプレートにしたがって書いてみても、結局はどの項目にも当てはまらないけど重要なことが出てきます。
なので、近頃使用されているフォーマットには、そういう事が書ける場所が用意されているのが普通です。
もしなかったら、自分で場所を作ってください。
結局のところ、ユースケース記述はフリーフォーマットなんですから。

前節で書いた「必須の項目」だって、あれはあくまで僕がそう感じてるだけのことで、誰かの論文や公式見解が根拠になっているわけではありません。
人によって、必須と思う項目は違ってくるでしょう。
あなたも、自分なりの必須項目を考えてみてください。

それと、フリーフォーマットの弊害(?)として、前節で書いたようなユースケースの各項の名称などは、イマイチ統一されていません。
人やプロジェクトによって、同じものを違う名前で呼んでいることがよくありますので、気をつけてください。
タグ:UML
posted by craftsman at 00:27 | 東京 ☀ | Comment(0) | TrackBack(0) | UML
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/152183740
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。