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

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

Transcript

1. 分析・設計・テストで活きる ユースケースシナリオの書き方と使い方 @dnskimox 2021/12/08 ユースケース駆動開発をやってみた
2. 自己紹介 本名：丹賀健一 ハンドルネーム：男爵 Twitter：@dnskimox 所属：Alp, Inc. / Scalebase 業務経験：イラストSNS、C2Cショップ作成サービ ス、ソシャゲバックエンド、サブスク管理SaaS 好きな話題：OOP、DDD、アジャイル 好きな言語：Scala、PHP
3. Alpの開発プロセス ＊Product Requirement Document ＊
4. コンテンツ 1. コーバーン流 ユースケースシナリオ 2. 創作とコミュニケーションの協調ゲーム 3. クラスの候補に責務を割り当てる 4. 機能のスライスをテストする 5. 次のゲームの準備
5. 1. コーバーン流 ユースケースシナリオ
6. アリスター・コーバーン アジャイルマニフェストを作った17人のう ちの1人。軽量開発手法のクリスタルファ ミリーの提唱者。クリーンアーキテクチャ に影響を与えたヘキサゴナルアーキテク チャを考えた人。
7. ユースケース実践ガイド ユースケースについて体系的に学べる一 冊。本当に一冊丸々を使ってユースケー スについて語っている。特にユースケー スシナリオ（ユースケース記述）に非常に 重点を置いているのが特徴。ユースケー スの構造化、ユースケースを使ったプロ ジェクトマネジメントなど応用的な内容も。
8. ユースケースは、システムの振る舞いに関する利害 関係者間の契約を表現するものです。（中略）なんら かの目的を達成するために、主アクターはシステムと の相互作用を開始します。すべての関係者の利益を 守りながら、システムはそれに応答します。 『ユースケース実践ガイド』
9. コーバーンのシナリオフォーマット • 主アクター、支援アクター • 設計スコープ • 目的レベル • 事前条件 • 主成功シナリオ（主シナリオ、基本コース） • 拡張（副シナリオ、代替コース） • 成功時保証（事後条件） • etc...
10. 商品をカートに追加する 主アクター：買い物客　 支援アクター：なし 設計スコープ：システム（ブラックボックス） 目的レベル：ユーザー目的レベル 事前条件： • 対象の商品は販売停止されていない 主シナリオ： 1. 買い物客は「カートに追加する」ボタンを押す 2. システムは対象商品の在庫を確認する 3. システムはカートに対象商品を一つ追加する 4. システムは「カートに追加しました」というメッセージを表示する 副シナリオ： 3a. 在庫切れだった場合： 　3a1. システムは「在庫切れにつきご購入できません」というエラーを表示する 　3a2. ユースケースを終了する 4a. 同一の商品がすでにカートに入っていた場合： 　4a1. システムはカートに入っている商品の個数を 1増加させる 事後条件： • カートの中には一つ以上の商品が入っている
11. 設計スコープ（Design Scope） 主アクター 支援アクター
12. ヘキサゴナルアーキテクチャ 主アクター 支援アクター ユースケース＆ ドメインモデル
13. 目的レベル（Goal Levels）
14. ユーザー目的レベル（User Goal） • それを終わらせた後、席を立ってコーヒーを飲みにいけるか？ ◦ 「検索ボックスにテキストを入力する」は細かすぎる • いくつ終わらせるかによって、その日の仕事の成果が変わるか？ ◦ 何度ログインを繰り返しても成果は変わらない • 連続した時間内に完了するか？ ◦ オークションは数日間に渡り、断続的に操作が発生する
15. シナリオ記述のポイント • 設計スコープを定義する • ユーザー目的レベルにフォーカスする • 各ステップの主語を明記する • 主シナリオをシンプルに保つ • 読み手と共通の語彙（ユビキタス言語）を使う • UIの詳細ではなくアクターの意図を書く • 事前条件を書いて冗長な副シナリオを減らす • 事後条件はステップとは別の言葉で書く
16. ICONIXとの比較
17. 2. 創作とコミュニケーションの 　協調ゲーム
18. アジャイルソフトウェア開発 「ソフトウェア開発とはいかなる活動か」と いうことをひたすら掘り下げている一冊。 コミュニケーション、個人、チーム、方法 論について。特定の開発手法に閉じた内 容ではなく、クリスタルファミリーを生み出 すに至ったコーバーンの思想が詰まって いる。
19. ソフトウェア開発のゲームは協調的である。チーム内 のメンバは、ゴールに到 達するために協 力し合う。 チームの品質を測定する材料は、ゲーム中、チーム 内のメンバがどのように協調し、コミュニケーションを 取るかということである。これは、ゴールへの確 実な 到達に影響する（後略） 『アジャイルソフトウェア開発』
20. コミュニケーションの流れ
21. 完 全かつ完 結したコミュニケーションはまったく不 可 能だ。自分では自分の意図する内容がわかっていた としても、コミュニケーションの 受 け 手 はどこかで ギャップを埋めなければならない。しかも受け手だけ で行わなければならない。 『アジャイルソフトウェア開発』
22. コミュニケーションの成功は、結局、送り手と受け手 が共有している経験の有無に依存する。他人と経験 を十分に共有していると、相手の経験を呼び起こす だけでよくなる。（中略）中間成果物は、参照可能な 共有経験や、新しいアイデアを構築する支えになる。 『アジャイルソフトウェア開発』
23. 参照可能な共有経験を作る
24. ユースケースを共に作り、 理解のギャップを埋める
25. エクストリーム・プログラミングの５つの価値 • コミュニケーション • シンプル • フィードバック • 勇気 • 尊重
26. 3. クラスの候補に責務を割り当てる
27. ユースケースはクラスを見つけるのに最適の道具で はない。（中略）優秀なオブジェクト指向分析者および 設 計 者は、「システムはaを実 行し、次にbを実 行す る」という形式に見られる性質に注目しないように心 がけている。代わりに、「抽象Aのインスタンスに許さ れる操作は何か、それらの操作に対する制限は何 か」を問う。 『オブジェクト指向入門 第2版 方法論・実践』
28. オブジェクト指向とユースケース オブジェクト指向分析設計 • 抽象データ型が持つ振る舞い • 順序に依存しない性質を考える • ボトムアップで積み上げる • ネットワーク構造 • etc… ユースケース • ユーザーとシステムの境界を描き出す • ステップの順序を明記する • 機能をトップダウンで分解 • ツリー構造 • etc…
29. ユースケースは 分 析 ツールではなくむしろ 確 認 （validation）ツールである。（中略）提示された分析モ デルあるいは試験的な設計に欠けている属性がある かどうかを検査する方法としてユースケースは有効 なツールだろう。 『オブジェクト指向入門 第2版 方法論・実践』
30. CRCカードワークショップ
31. CRCカード：表面 『オブジェクトデザイン』より
32. CRCカード：裏面 Candidate Responsibility Colaborator
33. シナリオを使ったウォークスルー 1. コンピュータになったつもりで、カードをオブジェクトに見立てて動かす 2. オブジェクトは自分の責務以外のことはできない 3. オブジェクトはコラボレーター以外と対話できない 4. シナリオの最後のステップに到達したら、事後条件を達成しているかどうかを確認 する 5. 最後のステップまで到達できなかったり、事後条件を達成できなかった場合、カード を書き換えてリトライする
34. ドメインモデルの 構造と振る舞いを検証できる
35. ICONIXとの比較
36. 4. 機能のスライスをテストする
37. テスト駆動開発の二重のサイクル http://www.growing-object-oriented-software.com/figures.html
38. 受け入れテストに求められる性質 • ステークホルダーが内容を読んで理解できる • ユーザーの要求を満たしているかどうかを検証する • エンドツーエンドのテストである
39. ユースケースシナリオが持つ性質 • ユビキタス言語で書かれている • ユーザーが目的を達成するまでのシナリオである • システムはブラックボックスとして扱われる
40. そのままの形で 受け入れテストに使える
41. 機能のスライスごとの受け入れテスト 1. 主シナリオが動くところまで実装する 2. 主シナリオの受け入れテスト 3. 1つ目の副シナリオが動くところまで実装する 4. 1つ目の副シナリオの受け入れテスト 5. 2つ目の副シナリオが動くところまで実装する 6. （以下略） 外側の1巡目のサイクル 外側の2巡目のサイクル 外側の3巡目のサイクル ＊これはまだ実践できてません
42. ICONIXとの比較
43. 5. 次のゲームの準備
44. プロジェクトには2つの目 標がある。ソフトウェアを納 品すること、および次のゲームで有利な位置を占め ることである。次のゲームでは、システムの変更や置 換、関連システムの作成などを行う。 『アジャイルソフトウェア開発』
45. システムの要求や設計を次のチームに知らせるため の目印を作るべきである。（中略）この目印は、次の チームのメンバが、 前 のシステムを 完 成 させたチー ムメンバの思考に合理的に近づけるようにしなけれ ばならない。 『アジャイルソフトウェア開発』
46. その点、RDRAは強い
47. RDRAのいいところ • 情報同士のリレーション • 重複した記述の除去 • 情報粒度に応じた階層化 • 影響範囲の機械的な算出 • etc…
48. ＼Notionならできる／
49. 適正なドキュメントの量とは、ドキュメントを読む人が ゲームで次の作業をするために必要な量である。そ の量を超えると、モデルを完成、修正、更新する労力 は、すべて資金の浪費になる。 『アジャイルソフトウェア開発』
50. プロジェクト毎に軽量十分な やり方を見つける
51. Alpの開発プロセス（最新版） ( ) Optional
52. まとめ 1. ユースケースの作成を通じて共有経験を獲得する 2. ウォークスルーでドメインモデルの正しさを検証する 3. シナリオのスライスを受け入れテストに使う 4. ユースケースを構造化しておけば次のプロジェクトで役立つ（かもしれない）
53. 参考文献 • ユースケース実践ガイド • ユースケース駆動開発実践ガイド • アジャイルソフトウェア開発 • オブジェクトデザイン • 実践テスト駆動開発 • RDRA2.0 ハンドブック • オブジェクト指向入門 第2版 方法論・実践 • Alistair Cockburn - Wikipedia • ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳)