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