D.Horiyama's output

Use Case Driven Object Modeling with UMLTheory and Practice ch3. Use Case Modeling (1/2)

ユースケース駆動モデリング勉強メモ

出典: 

Use Case Modeling

  • ユーザーはシステムで何をしようとしているか？
  • ユーザーの体験は何か？

The 10,000-Foot View

  • ユースケースは…

    • よいオブジェクト指向設計の足がかり
    • すばやく高品質なコードを得るのを助ける

Why Do I Need Use Cases in Addition to Functional Requirements?

  • 機能要件が重要なのはもちろんのこと
  • だが、設計、コーデング、見積もりを行うためには振る舞い要件に落とし込まなければならない

Don’t Forget the Rainy-Day Scenarios

  • 晴れの日シナリオ

    • 振る舞いの9割はこれであるかに思われる
    • 機能にして10%程度

  • 雨の日シナリオ

    • 残りの90%の機能
    • エラーハンドリングやあまり使われない機能など
  • 両方カバーしてこそシステムの広範囲を仕様化できたことになる

Do an Initial Domain Model Before You Write the Use Cases

  • ドメインモデルの文脈でユースケースを書く

    • ドメインモデルで列挙した語彙で書くということ
  • ICONIXプロセスでは、最初のドメインモデルは間違っているものと想定する

  • ユースケース分析を通じて改善する

    • 最初のドメインモデリングに時間を掛けすぎるべきでないのはこのため
  • ロバストネス図やシーケンス図を書くときにも随時ドメインモデルを修正していく

Driving Your Design (and Your Tests) from the Use Cases

  • ユースケースが直接、クラス設計に結びつく

    • コードと単体テストから、対応する振る舞い要件がわかる
    • どんな単体テストを書けばユースケースが実装されていることを担保できるか簡単にわかる

Use Case Modeling in Theory

  • ユースケースとクラスとの間に密な関連があること

Top 10 Use Case Modeling Guidelines

システムの利用をオブジェクトの文脈で記述せよ

  • 10_ 2段落ルールに従え
  • 9_ ユースケースを、アクターとユースケース図で整理せよ
  • 8_ ユースケースは active voice (能動態)で記述せよ
  • 7_ イベント/応答の流れで書く。ユーザーとシステムの対話で書く
  • 6_ GUIプロトタイプと画面のモックアップを使え
  • 5_ ユースケースは実行時の振る舞いの仕様である
  • 4_ ユースケースはオブジェクトモデルの文脈で書く

  • 3_ noun-verb-noun 構文で書く

    • 【補】日本語だと 名詞-目的語-動詞 かな
  • 2_ ドメインモデルのクラスを名前で参照せよ
  • 1_ 境界クラス(画面など)を名前で参照せよ

10. 2段落ルールに従え

  • これより長くなるとシーケンス図が理解不可能になるので、個別のユースケースへの分割を検討する

  • 非ユースケースの機能要件を混ぜない

    • 【補】「xxできる」ではなくて、「ユーザーはXXする」「システムはYYを応答する」と書き下せ、ということか

HOW TO WRITE A USE CASE: THE THREE MAGIC QUESTIONS

  1. 何が起こる？

    • 晴れの日シナリオの始まり

  2. 次に何が起こる？

    • 晴れの日

  3. 他に何が起こるかもしれない？

    • 雨の日

9. ユースケースを、アクターとユースケース図で整理せよ

  • アクター

    • システムの外側のモノ
  • アクターとユースケースの関連は、アクターがそのユースケースを実行する責任を有するということを意味する

8. ユースケースは active voice (能動態)で記述せよ

  • 受動態:

ユーザーにはログイン機能が提供される。パスワード型認証認可機構。

  • 良くないところ

    • 主語があいまいになる
    • これは機能要件
    • 結局解読して能動態で書き直さないと振る舞いは分からない
  • 能動態のほうが誤解が生じづらい

ユーザーはユーザ名とパスワードを入力し、ログインボタンをクリックする。 システムはユーザ名でユーザプロファイルを検索し、パスワードをチェックする。 システムはユーザをログイン状態にする。

  • ↑は晴れの日シナリオしか記述していないことに注意

7. イベント/応答の流れで書く。ユーザーとシステムの対話で書く

  • 多くの場合、ユーザーのイベントにシステムが応答
  • システムのイベントにユーザーが応答することもある
  • いずれにせよ、イベント/応答の流れで書く

  • たいていユーザーがシステムに語りかけることから始まるので、ユースケース記述は「システムはXYZ画面を表示し、ZZZ情報を表示する」で始まる

    • 効能
    • ZZZ情報のフェッチ処理の考慮が漏れにくい
    • 画面名の曖昧さがなくなる

システムはログイン画面を表示する。 ユーザーはユーザ名とパスワードを入力し、ログインボタンをクリックする。 システムはユーザ名でユーザプロファイルを検索し、パスワードをチェックする。 システムはユーザをログイン状態にする。

  • ユーザーとシステム両主語から記述するのが肝要

    • ユーザー主語
    • ユーザー視点で振る舞い要件を記述
    • システム主語
    • 究極的に仕様化したいのはソフトウェア — システムの振る舞い

6. GUIプロトタイプと画面のモックアップを使え

  • CASEツールなどで書き起こしてユースケース記述に添える
  • このさい、ユーザーが触れるボタンやメニューの類はすべて揃えること

  • 「プロトタイプ」という言葉よりも「ストーリーボード」(絵コンテ)を推奨

    • 「プロトタイプ」というとGUIを作り込みすぎるきらいがある
    • 「完璧な」GUIを作り込むあまり、(機能にして90%を占める)雨の日シナリオがおざなりになりがち
    • ナプキンの裏に書いたような線画でいい

5. ユースケースは実行時の振る舞いの仕様である

  • したがって、ユースケース図からシーケンス図を起こせる

Q&A: USE CASE = USER DOCUMENTATION?

  • ユースケースはユーザーガイドに似ている
  • 「ユースケース駆動」とは、とどのつまり「ユーザーガイドを書いてからコーディングする」ということ

英語

  • enthralling

    • 人をとりこにする、大変面白い

  • interspersed

    • 散らばった

  • tome

    • 大きな本

  • construe

    • 解釈する