札幌からきますた13年1月14日月曜日
札幌からきますた13年1月14日月曜日
札幌からきますた13年1月14日月曜日
ユースケースから         テスト駆動開発へ 2.0              2013.01.13 TDD BootCamp 大阪               Shuji Watanabe (@shuji_w6e)           ...
テスト駆動開発のFAQ     問. どのくらい事前設計すべきでしょうか?     どうすれば、いつやめるかわかるのでしょうか?     答. 何を構築すべきかわかるまでです。                        Derick Bai...
TDDが解決すること・                 しないこと13年1月14日月曜日
TDDは開発手法         良いプログラムは開発できるが、良いシステ         ムを開発できるわけではない         良いシステム = 顧客の要件を満たすシステム         なんらかの開発プロセスは必要         ...
TDDはテストリストが起点         プログラムが満たすべき仕様をリスト化              最初に全てを抽出できない              テストリストは随時、追加・修正         ただし、具体的な仕様(例)が必要  ...
プログラムの仕様と要件         システム開発の目的は顧客の要件の実現              仕様が要件を満たしていなければ本末転倒         要件から「何を構築するか」を設計する13年1月14日月曜日
TDDが解決する範囲                      TDD         顧客の要件                 テストリスト              「何を構築するか?」 プログラム13年1月14日月曜日
「何を構築するか?」を決める         顧客の言葉を使ったシステムの使い方              ユースケース              ユーザーストーリー         システムの外部的な振る舞い              画面モ...
ユースケース駆動開発13年1月14日月曜日
開発プロセス         ソフトウェアを作るための手順・段階         アジャイルでもWFでも基本は変わらない              要件定義                     外部設計                   ...
外部設計         システムの外部的振る舞い              利用者視点              要件定義とのトレーサビリティ              システム化するスコープ         実装とのトレーサビリティ    ...
システム境界         システムと外部との接点              どこからがシステムの機能・データなのか?         ユーザーインターフェイス(画面)         外部インターフェイス                  ...
トレーサビリティ         追跡(トレース)性         成果物同士が論理的に繋がっているか?              各フェイズでの成果物の整合性も必須        要件定義        外部設計         実装   ...
ユースケース駆動開発        ユースケース駆動開発とは、ユースケースを開        発の基点として顧客の要件を定義し、ユースケ        ースから設計・実装までのトレーサビリティを        保つ事を重視して開発を進める開発手...
ユースケース         システムの機能を表すシナリオ(使用例)         外部的な振る舞いと内部的な振る舞い              システムと外部とのやり取りを記述する         要件定義フェイズで抽出され、       ...
自動販売機でドリンクを購入する           ユーザは、お金を投入する          1.ユーザは、購入するドリンクのボタンを押す          2.システムは、対象のドリンクを排出する          3.ユーザは、払い出しボ...
参考)ユースケース図         ユースケースとアクターとの関係         構造化されたインデックス              重複を整理              関連するものをまとめる         本質はユースケース13年1月...
参考) 本質ユースケース         ビジネスユースケース/ Essential Use Case         簡潔で、抽象化され、一般的なユースケース              実装に依存しない形                   ...
ユースケースから              テスト駆動開発へ13年1月14日月曜日
ユースケースから実装を導く         ユースケースから実装を導く         ユースケースが適切である事が前提              つまり、顧客の言葉である         ユースケースからオブジェクト(名詞)を抽出      ...
ロバストネス分析         ユースケースからオブジェクトを抽出・整理         するための分析方法         ユースケースを3つの要素に分解する              バウンダリ                      ...
自動販売機でドリンクを購入する         1.ユーザは、お金を投入する         2.ユーザは、購入するドリンクのボタンを押す         3.システムは、対象のドリンクを排出する         4.ユーザは、払い出しボタンを...
アーキテクチャの適用         言語/フレームワークの選択              Rails, JavaEE, Django, CakePHP              細かい点は異なるが骨格は変わらない         ユースケース...
ユースケースシナリオを例にする           ユーザは、お金を投入する          1.ユーザは、購入するドリンクのボタンを押す          2.システムは、対象のドリンクを排出する          3.ユーザは、払い出しボ...
ユースケースシナリオを例にする          1.ユーザは、100硬貨を2枚を投入する           ユーザは、お金を投入する          2.ユーザは、コーラのボタンを押す          1.ユーザは、購入するドリンクのボ...
ユースケースシナリオを例にする          1.ユーザは、100硬貨を2枚を投入する           ユーザは、お金を投入する          2.ユーザは、コーラのボタンを押す 受け入れテスト          1.ユーザは、購入...
ユースケースシナリオを例にする          1.ユーザは、100硬貨を2枚を投入する           ユーザは、お金を投入する          2.ユーザは、コーラのボタンを押す 受け入れテスト          1.ユーザは、購入...
各ステップをテストリストにする         1.ユーザは、お金を投入する         2.ユーザは、購入するドリンクのボタンを押す         3.システムは、対象のドリンクを排出する         4.ユーザは、払い出しボタンを...
各ステップをテストリストにする       1.ユーザは、お金を投入する       2.ユーザは、購入するドリンクのボタンを押す    • (初期状態で)合計金額は0円である       3.システムは、対象のドリンクを排出する    • 1...
各ステップをテストリストにする       1.ユーザは、お金を投入する       2.ユーザは、購入するドリンクのボタンを押す    • (初期状態で)合計金額は0円である       3.システムは、対象のドリンクを排出する    • 1...
ユースケース駆動開発とTDD                    ユースケース                      TDD               クラス/メソッド         クラス/メソッド      受入テスト    クラ...
ユースケース駆動開発の利点         受入テストが設計時に明確              自動化できればベスト         適切な粒度の「何を構築すべきか?」         システムの完成度              本来はユースケ...
まとめ              ユースケースでシステム全体を設計する              顧客視点でシステム境界を明確にする              ユースケースは受入テスト              ユースケースから実装が導ける事が...
Upcoming SlideShare
Loading in...5
×

ユースケースからテスト駆動開発へ

5,912

Published on

TDD BootCamp 大阪 3.0 外伝での講演資料

Published in: Technology
0 Comments
21 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,912
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
44
Comments
0
Likes
21
Embeds 0
No embeds

No notes for slide

ユースケースからテスト駆動開発へ

  1. 1. 札幌からきますた13年1月14日月曜日
  2. 2. 札幌からきますた13年1月14日月曜日
  3. 3. 札幌からきますた13年1月14日月曜日
  4. 4. ユースケースから テスト駆動開発へ 2.0 2013.01.13 TDD BootCamp 大阪 Shuji Watanabe (@shuji_w6e) 313年1月14日月曜日
  5. 5. テスト駆動開発のFAQ 問. どのくらい事前設計すべきでしょうか? どうすれば、いつやめるかわかるのでしょうか? 答. 何を構築すべきかわかるまでです。 Derick Bailey http://www.infoq.com/jp/news/2008/03/tdd-smells13年1月14日月曜日
  6. 6. TDDが解決すること・ しないこと13年1月14日月曜日
  7. 7. TDDは開発手法 良いプログラムは開発できるが、良いシステ ムを開発できるわけではない 良いシステム = 顧客の要件を満たすシステム なんらかの開発プロセスは必要 アジャイルでもウォーターフォールでも13年1月14日月曜日
  8. 8. TDDはテストリストが起点 プログラムが満たすべき仕様をリスト化 最初に全てを抽出できない テストリストは随時、追加・修正 ただし、具体的な仕様(例)が必要 例:getListで1件のデータが取得できる 「何を構築すべきか」=事前設計13年1月14日月曜日
  9. 9. プログラムの仕様と要件 システム開発の目的は顧客の要件の実現 仕様が要件を満たしていなければ本末転倒 要件から「何を構築するか」を設計する13年1月14日月曜日
  10. 10. TDDが解決する範囲 TDD 顧客の要件 テストリスト 「何を構築するか?」 プログラム13年1月14日月曜日
  11. 11. 「何を構築するか?」を決める 顧客の言葉を使ったシステムの使い方 ユースケース ユーザーストーリー システムの外部的な振る舞い 画面モックアップ APIや他システム連携13年1月14日月曜日
  12. 12. ユースケース駆動開発13年1月14日月曜日
  13. 13. 開発プロセス ソフトウェアを作るための手順・段階 アジャイルでもWFでも基本は変わらない 要件定義 外部設計 プログラミング テスト13年1月14日月曜日
  14. 14. 外部設計 システムの外部的振る舞い 利用者視点 要件定義とのトレーサビリティ システム化するスコープ 実装とのトレーサビリティ 内部(システム化方式)に依存しない13年1月14日月曜日
  15. 15. システム境界 システムと外部との接点 どこからがシステムの機能・データなのか? ユーザーインターフェイス(画面) 外部インターフェイス システム境界 システム 機能 データ ユーザ 外部システム13年1月14日月曜日
  16. 16. トレーサビリティ 追跡(トレース)性 成果物同士が論理的に繋がっているか? 各フェイズでの成果物の整合性も必須 要件定義 外部設計 実装 比較的に保てる 保ちにくい13年1月14日月曜日
  17. 17. ユースケース駆動開発 ユースケース駆動開発とは、ユースケースを開 発の基点として顧客の要件を定義し、ユースケ ースから設計・実装までのトレーサビリティを 保つ事を重視して開発を進める開発手法。 システム トレーサビリティ ユースケース System Software ユースケース アクター Heuristics13年1月14日月曜日
  18. 18. ユースケース システムの機能を表すシナリオ(使用例) 外部的な振る舞いと内部的な振る舞い システムと外部とのやり取りを記述する 要件定義フェイズで抽出され、 外部設計フェイズで詳細化する13年1月14日月曜日
  19. 19. 自動販売機でドリンクを購入する ユーザは、お金を投入する 1.ユーザは、購入するドリンクのボタンを押す 2.システムは、対象のドリンクを排出する 3.ユーザは、払い出しボタンを押す 4.システムは、お釣りを払い出す システムとユーザのインタラクションを記述 1行で1つのアクションを記述 文末は「∼する」(「∼できる」は厳禁)13年1月14日月曜日
  20. 20. 参考)ユースケース図 ユースケースとアクターとの関係 構造化されたインデックス 重複を整理 関連するものをまとめる 本質はユースケース13年1月14日月曜日
  21. 21. 参考) 本質ユースケース ビジネスユースケース/ Essential Use Case 簡潔で、抽象化され、一般的なユースケース 実装に依存しない形 要求 抽象的 要求分析に適する 本質ユースケース システムユースケース 実装に結びつけにくい 具体的 実装 http://www.ogis-ri.co.jp/otc/swec/process/am-res/am/artifacts/essentialUseCase.html http://www.ogis-ri.co.jp/otc/swec/process/am-res/am/artifacts/systemUseCase.html13年1月14日月曜日
  22. 22. ユースケースから テスト駆動開発へ13年1月14日月曜日
  23. 23. ユースケースから実装を導く ユースケースから実装を導く ユースケースが適切である事が前提 つまり、顧客の言葉である ユースケースからオブジェクト(名詞)を抽出 「表示する」「取得する」など動詞 アーキテクチャに依存しない13年1月14日月曜日
  24. 24. ロバストネス分析 ユースケースからオブジェクトを抽出・整理 するための分析方法 ユースケースを3つの要素に分解する バウンダリ アクター バウンダリ コントローラ コントローラ エンティティ エンティティ ユースケースに対する健全性チェック13年1月14日月曜日
  25. 25. 自動販売機でドリンクを購入する 1.ユーザは、お金を投入する 2.ユーザは、購入するドリンクのボタンを押す 3.システムは、対象のドリンクを排出する 4.ユーザは、払い出しボタンを押す メソッドの候補 クラスの候補 何を構築すべきか?13年1月14日月曜日
  26. 26. アーキテクチャの適用 言語/フレームワークの選択 Rails, JavaEE, Django, CakePHP 細かい点は異なるが骨格は変わらない ユースケース + アーキテクチャ 実装可能13年1月14日月曜日
  27. 27. ユースケースシナリオを例にする ユーザは、お金を投入する 1.ユーザは、購入するドリンクのボタンを押す 2.システムは、対象のドリンクを排出する 3.ユーザは、払い出しボタンを押す 4.システムは、お釣りを払い出す 具体的な例とすることで テストできる 問題点に気付くことができる13年1月14日月曜日
  28. 28. ユースケースシナリオを例にする 1.ユーザは、100硬貨を2枚を投入する ユーザは、お金を投入する 2.ユーザは、コーラのボタンを押す 1.ユーザは、購入するドリンクのボタンを押す 3.システムは、コーラを排出する 2.システムは、対象のドリンクを排出する 4.ユーザは、払い出しボタンを押す 3.ユーザは、払い出しボタンを押す 5.システムは、10硬貨を8枚を払い出す 4.システムは、お釣りを払い出す 具体的な例とすることで テストできる 問題点に気付くことができる13年1月14日月曜日
  29. 29. ユースケースシナリオを例にする 1.ユーザは、100硬貨を2枚を投入する ユーザは、お金を投入する 2.ユーザは、コーラのボタンを押す 受け入れテスト 1.ユーザは、購入するドリンクのボタンを押す 3.システムは、コーラを排出する 2.システムは、対象のドリンクを排出する (Cucumberなど) 4.ユーザは、払い出しボタンを押す 3.ユーザは、払い出しボタンを押す 5.システムは、10硬貨を8枚を払い出す 4.システムは、お釣りを払い出す 具体的な例とすることで テストできる 問題点に気付くことができる13年1月14日月曜日
  30. 30. ユースケースシナリオを例にする 1.ユーザは、100硬貨を2枚を投入する ユーザは、お金を投入する 2.ユーザは、コーラのボタンを押す 受け入れテスト 1.ユーザは、購入するドリンクのボタンを押す 3.システムは、コーラを排出する 2.システムは、対象のドリンクを排出する (Cucumberなど) 4.ユーザは、払い出しボタンを押す 3.ユーザは、払い出しボタンを押す 5.システムは、10硬貨を8枚を払い出す 4.システムは、お釣りを払い出す # language: ja フィーチャ: 自動販売機で飲み物を購入 具体的な例とすることで シナリオ: コーラを1本買う 前提 100円を2枚投入する テストできる もし コーラのボタンを押した ならば コーラが出力される かつ お釣りは10円が’8’枚である 問題点に気付くことができる13年1月14日月曜日
  31. 31. 各ステップをテストリストにする 1.ユーザは、お金を投入する 2.ユーザは、購入するドリンクのボタンを押す 3.システムは、対象のドリンクを排出する 4.ユーザは、払い出しボタンを押す 5.システムは、お釣りを払い出す13年1月14日月曜日
  32. 32. 各ステップをテストリストにする 1.ユーザは、お金を投入する 2.ユーザは、購入するドリンクのボタンを押す • (初期状態で)合計金額は0円である 3.システムは、対象のドリンクを排出する • 100円硬貨を投入すると、合計金額が100円である 4.ユーザは、払い出しボタンを押す • 100円硬貨を投入されている時に、 5.システムは、お釣りを払い出す  10円硬貨を投入すると、合計金額が110円である13年1月14日月曜日
  33. 33. 各ステップをテストリストにする 1.ユーザは、お金を投入する 2.ユーザは、購入するドリンクのボタンを押す • (初期状態で)合計金額は0円である 3.システムは、対象のドリンクを排出する • 100円硬貨を投入すると、合計金額が100円である 4.ユーザは、払い出しボタンを押す • 100円硬貨を投入されている時に、 5.システムは、お釣りを払い出す  10円硬貨を投入すると、合計金額が110円である { @Test public void 初期状態でgetTotalAmountは0を返す() throws Exception VendingMachine sut = new VendingMachine(); int actual = sut.getTotalAmount(); assertThat(actual, is(0)); }13年1月14日月曜日
  34. 34. ユースケース駆動開発とTDD ユースケース TDD クラス/メソッド クラス/メソッド 受入テスト クラス/メソッド クラス/メソッド (機能テスト) TDD クラス/メソッド クラス/メソッド クラス/メソッド クラス/メソッド 受入テスト ユースケース (機能テスト) ユースケース13年1月14日月曜日
  35. 35. ユースケース駆動開発の利点 受入テストが設計時に明確 自動化できればベスト 適切な粒度の「何を構築すべきか?」 システムの完成度 本来はユースケース単位で意味がある 現実として進 管理が必要13年1月14日月曜日
  36. 36. まとめ ユースケースでシステム全体を設計する 顧客視点でシステム境界を明確にする ユースケースは受入テスト ユースケースから実装が導ける事が重要 ユースケースの1文は「構築すべきこと」 テスト駆動開発の起点 テストリスト13年1月14日月曜日
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×