ユースケースシナリオのススメ

by 男爵

Slide 1

Slide 1 text

ユースケースシナリオのススメ 2021/03/26 PHPerKaigi 2021 @dnskimox

Slide 2

Slide 2 text

自己紹介男爵 Twitter：@dnskimox 所属：Alp,Inc. / Scalebase PHP歴：PHP4〜PHP7 業務経験：イラストSNS、C2Cショップ作成サービス、ソシャゲバックエンド、サブスクリプション管理SaaS 好きな話題：OOP、DDD、開発プロセス

Slide 3

Slide 3 text

ユースケースシナリオのススメ ▸ ドメインモデルに足りないもの ▸ ユースケースとはなにか？ ▸ ユースケースシナリオの書き方 ▸ シナリオからコードへ ▸ 結論

Slide 4

Slide 4 text

1. ドメインモデルに足りないものモデルに妥当性を与えるものは何か？

Slide 5

Slide 5 text

ショッピングカートのドメインモデル

Slide 6

Slide 6 text

この手のモデルから何がわかるの？これから作るべきソフトウェアについて、何を語っていて、何を語っていないのか……。

Slide 7

Slide 7 text

ドメインモデルはソフトウェアの静的な構造を表現する概念の名前、依存関係、関連、多重度、集約関係、etc...

Slide 8

Slide 8 text

静的な構造概念の名前、依存関係、関連、多重度、集約関係、etc... ソフトウェアが持つふたつの側面動的なふるまい情報を表示する、入力を受け付ける、入力値を検証する、計算をする、データを保存する、外部と通信する、etc...

Slide 9

Slide 9 text

“ ユーザーの立場で見ると、ソフトウェアを外部の世界から区別するようなシステムの境界があります。自分のタスクをソフトウェアがどのようにサポートしてくれるのかということを通して、ユーザーはソフトウェアを理解します。このタスク指向の視点は、一連の記述、すなわちユースケースによって説明できます。 ――『オブジェクトデザイン』(p.59)

Slide 10

Slide 10 text

2. ユースケースとはなにか？ UMLが教えてくれない大事なこと

Slide 11

Slide 11 text

ユースケースと聞いて多くの人が想像するであろう「図」

Slide 12

Slide 12 text

“ これはあくまで各ユースケースの相互関係を示すものです。しかしユースケースの価値はほぼすべてがその内容のほうにあり、ダイアグラムはわずかな意味を持つだけです。 ――『UMLモデリングのエッセンス第3版』(p.100）

Slide 13

Slide 13 text

UMLの父イヴァー・ヤコブソンスウェーデンのコンピュータ科学者。グラディ・ブーチ、ジェームズ・ランボーらと共にUMLの最初の版を策定した。ユースケース、シーケンス図、ロバストネス分析などを考案。 https://twitter.com/ivarjacobson

Slide 14

Slide 14 text

“ ［将来のシステムのユーザによって］開始されるイベントと［ユーザと］システムの間のインタラクションの完全な記述 ――『オブジェクト指向入門第2版方法論・実践』(p.100）で引用されているヤコブソンの言葉

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

“ 形式的手法、形式言語、形式的体系などに現れる「形式的」は、「数学や論理学に基礎を置いた、よく定義されて曖昧性が少ない」といった意味で使っていると思う。 ―― 「形式的」とは何だろう

Slide 17

Slide 17 text

“ 各ユースケースは、何らかの目的・目標/機能に関する台本（シナリオ）での主体（アクター）と呼ぶ利用者とシステムのやりとりを描いている。（中略）ユースケースでは技術専門用語をなるべく使わず、エンドユーザーやそのビジネスの専門家に分かり易い用語を用いる。ユースケースの作成は、ビジネスアナリストとエンドユーザーが共同で行う。 ―― ユースケース - Wikipedia

Slide 18

Slide 18 text

ソフトウェアの動的なふるまいについて合意を形成する可能な操作、入力値検証、計算、データ保存、検索、システムからの応答、エラー処理、etc...

Slide 19

Slide 19 text

3. ユースケースシナリオの書き方形式的な文書にするために欠かせない3カ条

Slide 20

Slide 20 text

1. 目的レベルを揃える

Slide 21

Slide 21 text

1. 目的レベルを揃える

Slide 22

Slide 22 text

『ユースケース実践ガイド』（ p. 80）

Slide 23

Slide 23 text

2. シナリオテンプレートに従うユースケース名：XXXをXXXする事前条件 - XXXであること主成功シナリオ 1. アクターは〜する 2. システムは〜する 3. アクターは〜する 4. システムは〜する拡張 2a. XXXがXXXの場合：システムは〜するアクターは〜する 1に戻る事後条件 - XXXであること晴れの日のシナリオ雨の日のシナリオ

Slide 24

Slide 24 text

2. シナリオテンプレートに従うユースケース名：ショッピングカートに商品を追加する事前条件 - 対象の商品が公開中であること主成功シナリオ 1. 買い物客は商品と購入数を選択する 2. システムは商品の在庫状況を確認する 3. システムはショッピングカートにカート品目を追加する 4. システムは「ショッピングカート」画面に遷移する 5. 買い物客はショッピングカートの中身を確認する拡張 2a. 商品の在庫が購入数未満だった場合：システムは「在庫が足りません」というエラーを表示するユースケースを終了する事後条件 - カート品目が一件増えていること - 対象の商品の在庫はまだ減っていないこと

Slide 25

Slide 25 text

ここでいう「システム」ってどこからどこまでのこと？バックエンドAPIだけなのか、フロントエンドも含むのか、 DBはどうなのか、連携しているSaaSは……。

Slide 26

Slide 26 text

3. 設計スコープを定義する主アクター支援アクター

Slide 27

Slide 27 text

4. シナリオからコードへ道はひとつではない

Slide 28

Slide 28 text

ICONIXプロセス『ユースケース駆動設計実践ガイド』今日はこの話はしません

Slide 29

Slide 29 text

CRCカードワークショップ https://slideplayer.com/slide/10494736/

Slide 30

Slide 30 text

CRCカード（表面）『オブジェクトデザイン』（ P. 145）

Slide 31

Slide 31 text

CRCカード（裏面）『オブジェクトデザイン』（ P. 146） Responsibility Class(Candidate) Collaboration

Slide 32

Slide 32 text

CRCカードで用意するもの 1. 情報カード 2. 鉛筆 3. 消しゴム Amazon | コレクト情報カード 5×3 補助 6ミリ罫 C-532 | 文房具・オフィス用品 | 文房具・オフィス用品

Slide 33

Slide 33 text

CRCカードの手順 1. 参加者はクラスの候補をカードに記入する a. 表面にはクラスの概要や不変条件を自由に書く 2. 裏面に責務とコラボレーターを書く a. 書ききれない責務は別のクラスを作って移譲する 3. コンピュータになったつもりで、カードをオブジェクトに見立ててシナリオを実行してみる（ウォークスルー） a. オブジェクトは自身の責務以外のことはできない b. オブジェクトはコラボレーター以外と対話できない 4. 最後のステップに到達したら、事後条件を達成しているかどうかを確認する 5. 最後のステップまで到達できなかったり、事後条件を達成できなかった場合、1に戻って考え直す

Slide 34

Slide 34 text

この手順に従うとクラスの数がどんどん増えるんだけど？たくさんのクラスの間を飛び回らないと読み解け無い難しいコードになりそう……。

Slide 35

Slide 35 text

“ それでも、私のようなオブジェクト偏愛者は分散制御を選びます。良い設計を実現する条件のひとつは、変更による影響を局所化することです。データとそれを評価する振る舞いは、一緒に変更されることが多いものです。 ―― 『UMLモデリングのエッセンス第3版』（P. 56）

Slide 36

Slide 36 text

“ 実は、この変化こそ、オブジェクト指向のパラダイムシフトの中心部分です。これは、教えるのが非常に難しい部分です。（中略）一度理解できると、脳内の配線が変わり、実際には分散制御のほうが簡単であると考えるようになります。 ―― 『UMLモデリングのエッセンス第3版』（P. 56）

Slide 37

Slide 37 text

最初に記述するクラスの候補はどこからくるの？ユースケースからクラス名を抽出するのか、他の源泉があるのか、あるとしたらそれは何なのか……。

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

最初のドメインモデルはシナリオよりも先につくる顧客へのヒアリング、要求文書、対象ドメインの専門用語、チーム内の会話、デザインパターン、etc...

Slide 41

Slide 41 text

オススメの設計プロセス（ドラフト版）ドメインモデルユースケースシナリオ CRCカード

Slide 42

Slide 42 text

結論ユースケースを有効活用するには覚えて帰ってほしい３つのこと

Slide 43

Slide 43 text

ユースケースは図ではない大事なのはシステムのふるまいを示すシナリオクラスの候補をシナリオで検証ウォークスルーを通じてオブジェクト同士の連携を観察ふるまいについて合意形成する文書そのものより、記述中に発生するコミュニケーション

Slide 44

Slide 44 text

現場でユースケースシナリオを書いてみよう！ご清聴ありがとうございました You can ﬁnd me at @dnskimox & https://dnskimox.hateblo.jp/

Slide 45

Slide 45 text

参考文献 ▸ 『オブジェクトデザイン』 ▸ 『UMLモデリングのエッセンス第３版』 ▸ 『ユースケース実践ガイド』 ▸ 『ユースケース駆動開発実践ガイド』 ▸ 『オブジェクト指向入門第2版方法論・実践』 ▸ ユースケース - Wikipedia ▸ イヴァー・ヤコブソン - Wikipedia ▸ CRCカードでチームが協働して設計する ▸ 「形式的」とは何だろう