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

by 男爵

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Alpの開発プロセス＊Product Requirement Document ＊

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

設計スコープ（Design Scope）主アクター支援アクター

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

目的レベル（Goal Levels）

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

ICONIXとの比較

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

CRCカードワークショップ

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

CRCカード：裏面 Candidate Responsibility Colaborator

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

ICONIXとの比較

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

ICONIXとの比較

Slide 43

Slide 43 text

5. 次のゲームの準備

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

その点、RDRAは強い

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

＼Notionならできる／

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Alpの開発プロセス（最新版） ( ) Optional

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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