$30 off During Our Annual Pro Sale. View Details »

分析・設計・テストで活きる ユースケースシナリオの書き方と使い方

男爵
December 08, 2021

分析・設計・テストで活きる ユースケースシナリオの書き方と使い方

『現場から学ぶモデル駆動設計 ユースケース駆動開発をやってみた』の発表資料です。
https://modeling-how-to-learn.connpass.com/event/229330/

男爵

December 08, 2021
Tweet

More Decks by 男爵

Other Decks in Programming

Transcript

  1. 分析・設計・テストで活きる
    ユースケースシナリオの書き方と使い方
    @dnskimox
    2021/12/08 ユースケース駆動開発をやってみた

    View Slide

  2. 自己紹介
    本名:丹賀健一
    ハンドルネーム:男爵
    Twitter:@dnskimox
    所属:Alp, Inc. / Scalebase
    業務経験:イラストSNS、C2Cショップ作成サービ
    ス、ソシャゲバックエンド、サブスク管理SaaS
    好きな話題:OOP、DDD、アジャイル
    好きな言語:Scala、PHP

    View Slide

  3. Alpの開発プロセス
    *Product Requirement Document

    View Slide

  4. コンテンツ
    1. コーバーン流 ユースケースシナリオ
    2. 創作とコミュニケーションの協調ゲーム
    3. クラスの候補に責務を割り当てる
    4. 機能のスライスをテストする
    5. 次のゲームの準備

    View Slide

  5. 1. コーバーン流 ユースケースシナリオ

    View Slide

  6. アリスター・コーバーン
    アジャイルマニフェストを作った17人のう
    ちの1人。軽量開発手法のクリスタルファ
    ミリーの提唱者。クリーンアーキテクチャ
    に影響を与えたヘキサゴナルアーキテク
    チャを考えた人。

    View Slide

  7. ユースケース実践ガイド
    ユースケースについて体系的に学べる一
    冊。本当に一冊丸々を使ってユースケー
    スについて語っている。特にユースケー
    スシナリオ(ユースケース記述)に非常に
    重点を置いているのが特徴。ユースケー
    スの構造化、ユースケースを使ったプロ
    ジェクトマネジメントなど応用的な内容も。

    View Slide

  8. ユースケースは、システムの振る舞いに関する利害
    関係者間の契約を表現するものです。(中略)なんら
    かの目的を達成するために、主アクターはシステムと
    の相互作用を開始します。すべての関係者の利益を
    守りながら、システムはそれに応答します。
    『ユースケース実践ガイド』

    View Slide

  9. コーバーンのシナリオフォーマット
    ● 主アクター、支援アクター
    ● 設計スコープ
    ● 目的レベル
    ● 事前条件
    ● 主成功シナリオ(主シナリオ、基本コース)
    ● 拡張(副シナリオ、代替コース)
    ● 成功時保証(事後条件)
    ● etc...

    View Slide

  10. 商品をカートに追加する
    主アクター:買い物客 
    支援アクター:なし
    設計スコープ:システム(ブラックボックス)
    目的レベル:ユーザー目的レベル
    事前条件:
    ● 対象の商品は販売停止されていない
    主シナリオ:
    1. 買い物客は「カートに追加する」ボタンを押す
    2. システムは対象商品の在庫を確認する
    3. システムはカートに対象商品を一つ追加する
    4. システムは「カートに追加しました」というメッセージを表示する
    副シナリオ:
    3a. 在庫切れだった場合:
     3a1. システムは「在庫切れにつきご購入できません」というエラーを表示する
     3a2. ユースケースを終了する
    4a. 同一の商品がすでにカートに入っていた場合:
     4a1. システムはカートに入っている商品の個数を
    1増加させる
    事後条件:
    ● カートの中には一つ以上の商品が入っている

    View Slide

  11. 設計スコープ(Design Scope)
    主アクター
    支援アクター

    View Slide

  12. ヘキサゴナルアーキテクチャ
    主アクター 支援アクター
    ユースケース&
    ドメインモデル

    View Slide

  13. 目的レベル(Goal Levels)

    View Slide

  14. ユーザー目的レベル(User Goal)
    ● それを終わらせた後、席を立ってコーヒーを飲みにいけるか?
    ○ 「検索ボックスにテキストを入力する」は細かすぎる
    ● いくつ終わらせるかによって、その日の仕事の成果が変わるか?
    ○ 何度ログインを繰り返しても成果は変わらない
    ● 連続した時間内に完了するか?
    ○ オークションは数日間に渡り、断続的に操作が発生する

    View Slide

  15. シナリオ記述のポイント
    ● 設計スコープを定義する
    ● ユーザー目的レベルにフォーカスする
    ● 各ステップの主語を明記する
    ● 主シナリオをシンプルに保つ
    ● 読み手と共通の語彙(ユビキタス言語)を使う
    ● UIの詳細ではなくアクターの意図を書く
    ● 事前条件を書いて冗長な副シナリオを減らす
    ● 事後条件はステップとは別の言葉で書く

    View Slide

  16. ICONIXとの比較

    View Slide

  17. 2. 創作とコミュニケーションの
     協調ゲーム

    View Slide

  18. アジャイルソフトウェア開発
    「ソフトウェア開発とはいかなる活動か」と
    いうことをひたすら掘り下げている一冊。
    コミュニケーション、個人、チーム、方法
    論について。特定の開発手法に閉じた内
    容ではなく、クリスタルファミリーを生み出
    すに至ったコーバーンの思想が詰まって
    いる。

    View Slide

  19. ソフトウェア開発のゲームは協調的である。チーム内
    のメンバは、ゴールに到 達するために協 力し合う。
    チームの品質を測定する材料は、ゲーム中、チーム
    内のメンバがどのように協調し、コミュニケーションを
    取るかということである。これは、ゴールへの確 実な
    到達に影響する(後略)
    『アジャイルソフトウェア開発』

    View Slide

  20. コミュニケーションの流れ

    View Slide

  21. 完 全かつ完 結したコミュニケーションはまったく不 可
    能だ。自分では自分の意図する内容がわかっていた
    としても、コミュニケーションの 受 け 手 はどこかで
    ギャップを埋めなければならない。しかも受け手だけ
    で行わなければならない。
    『アジャイルソフトウェア開発』

    View Slide

  22. コミュニケーションの成功は、結局、送り手と受け手
    が共有している経験の有無に依存する。他人と経験
    を十分に共有していると、相手の経験を呼び起こす
    だけでよくなる。(中略)中間成果物は、参照可能な
    共有経験や、新しいアイデアを構築する支えになる。
    『アジャイルソフトウェア開発』

    View Slide

  23. 参照可能な共有経験を作る

    View Slide

  24. ユースケースを共に作り、
    理解のギャップを埋める

    View Slide

  25. エクストリーム・プログラミングの5つの価値
    ● コミュニケーション
    ● シンプル
    ● フィードバック
    ● 勇気
    ● 尊重

    View Slide

  26. 3. クラスの候補に責務を割り当てる

    View Slide

  27. ユースケースはクラスを見つけるのに最適の道具で
    はない。(中略)優秀なオブジェクト指向分析者および
    設 計 者は、「システムはaを実 行し、次にbを実 行す
    る」という形式に見られる性質に注目しないように心
    がけている。代わりに、「抽象Aのインスタンスに許さ
    れる操作は何か、それらの操作に対する制限は何
    か」を問う。
    『オブジェクト指向入門 第2版 方法論・実践』

    View Slide

  28. オブジェクト指向とユースケース
    オブジェクト指向分析設計
    ● 抽象データ型が持つ振る舞い
    ● 順序に依存しない性質を考える
    ● ボトムアップで積み上げる
    ● ネットワーク構造
    ● etc…
    ユースケース
    ● ユーザーとシステムの境界を描き出す
    ● ステップの順序を明記する
    ● 機能をトップダウンで分解
    ● ツリー構造
    ● etc…

    View Slide

  29. ユースケースは 分 析 ツールではなくむしろ 確 認
    (validation)ツールである。(中略)提示された分析モ
    デルあるいは試験的な設計に欠けている属性がある
    かどうかを検査する方法としてユースケースは有効
    なツールだろう。
    『オブジェクト指向入門 第2版 方法論・実践』

    View Slide

  30. CRCカードワークショップ

    View Slide

  31. CRCカード:表面
    『オブジェクトデザイン』より

    View Slide

  32. CRCカード:裏面
    Candidate
    Responsibility Colaborator

    View Slide

  33. シナリオを使ったウォークスルー
    1. コンピュータになったつもりで、カードをオブジェクトに見立てて動かす
    2. オブジェクトは自分の責務以外のことはできない
    3. オブジェクトはコラボレーター以外と対話できない
    4. シナリオの最後のステップに到達したら、事後条件を達成しているかどうかを確認
    する
    5. 最後のステップまで到達できなかったり、事後条件を達成できなかった場合、カード
    を書き換えてリトライする

    View Slide

  34. ドメインモデルの
    構造と振る舞いを検証できる

    View Slide

  35. ICONIXとの比較

    View Slide

  36. 4. 機能のスライスをテストする

    View Slide

  37. テスト駆動開発の二重のサイクル
    http://www.growing-object-oriented-software.com/figures.html

    View Slide

  38. 受け入れテストに求められる性質
    ● ステークホルダーが内容を読んで理解できる
    ● ユーザーの要求を満たしているかどうかを検証する
    ● エンドツーエンドのテストである

    View Slide

  39. ユースケースシナリオが持つ性質
    ● ユビキタス言語で書かれている
    ● ユーザーが目的を達成するまでのシナリオである
    ● システムはブラックボックスとして扱われる

    View Slide

  40. そのままの形で
    受け入れテストに使える

    View Slide

  41. 機能のスライスごとの受け入れテスト
    1. 主シナリオが動くところまで実装する
    2. 主シナリオの受け入れテスト
    3. 1つ目の副シナリオが動くところまで実装する
    4. 1つ目の副シナリオの受け入れテスト
    5. 2つ目の副シナリオが動くところまで実装する
    6. (以下略)
    外側の1巡目のサイクル
    外側の2巡目のサイクル
    外側の3巡目のサイクル
    *これはまだ実践できてません

    View Slide

  42. ICONIXとの比較

    View Slide

  43. 5. 次のゲームの準備

    View Slide

  44. プロジェクトには2つの目 標がある。ソフトウェアを納
    品すること、および次のゲームで有利な位置を占め
    ることである。次のゲームでは、システムの変更や置
    換、関連システムの作成などを行う。
    『アジャイルソフトウェア開発』

    View Slide

  45. システムの要求や設計を次のチームに知らせるため
    の目印を作るべきである。(中略)この目印は、次の
    チームのメンバが、 前 のシステムを 完 成 させたチー
    ムメンバの思考に合理的に近づけるようにしなけれ
    ばならない。
    『アジャイルソフトウェア開発』

    View Slide

  46. その点、RDRAは強い

    View Slide

  47. RDRAのいいところ
    ● 情報同士のリレーション
    ● 重複した記述の除去
    ● 情報粒度に応じた階層化
    ● 影響範囲の機械的な算出
    ● etc…

    View Slide

  48. \Notionならできる/

    View Slide

  49. 適正なドキュメントの量とは、ドキュメントを読む人が
    ゲームで次の作業をするために必要な量である。そ
    の量を超えると、モデルを完成、修正、更新する労力
    は、すべて資金の浪費になる。
    『アジャイルソフトウェア開発』

    View Slide

  50. プロジェクト毎に軽量十分な
    やり方を見つける

    View Slide

  51. Alpの開発プロセス(最新版)
    ( )
    Optional

    View Slide

  52. まとめ
    1. ユースケースの作成を通じて共有経験を獲得する
    2. ウォークスルーでドメインモデルの正しさを検証する
    3. シナリオのスライスを受け入れテストに使う
    4. ユースケースを構造化しておけば次のプロジェクトで役立つ(かもしれない)

    View Slide

  53. 参考文献
    ● ユースケース実践ガイド
    ● ユースケース駆動開発実践ガイド
    ● アジャイルソフトウェア開発
    ● オブジェクトデザイン
    ● 実践テスト駆動開発
    ● RDRA2.0 ハンドブック
    ● オブジェクト指向入門 第2版 方法論・実践
    ● Alistair Cockburn - Wikipedia
    ● ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳)

    View Slide