Save 37% off PRO during our Black Friday Sale! »

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

88ad4f75d7c84fcf560bb6205c52e8c1?s=47 男爵
March 26, 2021

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

PHPerKaigi2021の登壇資料です。
補足資料はこちら https://dnskimox.hateblo.jp/entry/2020/12/19/184101

88ad4f75d7c84fcf560bb6205c52e8c1?s=128

男爵

March 26, 2021
Tweet

Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  20. 1. 目的レベルを揃える

  21. 1. 目的レベルを揃える

  22. 『ユースケース実践ガイド』( p. 80)

  23. 2. シナリオテンプレートに従う ユースケース名:XXXをXXXする 事前条件 - XXXであること 主成功シナリオ 1. アクターは〜する 2.

    システムは〜する 3. アクターは〜する 4. システムは〜する 拡張 2a. XXXがXXXの場合: システムは〜する アクターは〜する 1に戻る 事後条件 - XXXであること 晴れの日のシナリオ 雨の日のシナリオ
  24. 2. シナリオテンプレートに従う ユースケース名:ショッピングカートに商品を追加する 事前条件 - 対象の商品が公開中であること 主成功シナリオ 1. 買い物客は商品と購入数を選択する 2.

    システムは商品の在庫状況を確認する 3. システムはショッピングカートにカート品目を追加する 4. システムは「ショッピングカート」画面に遷移する 5. 買い物客はショッピングカートの中身を確認する 拡張 2a. 商品の在庫が購入数未満だった場合: システムは「在庫が足りません」というエラーを表示する ユースケースを終了する 事後条件 - カート品目が一件増えていること - 対象の商品の在庫はまだ減っていないこと
  25. ここでいう「システム」ってどこか らどこまでのこと? バックエンドAPIだけなのか、フロントエンドも含むのか、 DBはどうなのか、連携しているSaaSは……。

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

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

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

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

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

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

  32. CRCカードで用意するもの 1. 情報カード 2. 鉛筆 3. 消しゴム Amazon | コレクト

    情報カード 5×3 補助 6ミリ罫 C-532 | 文房具・オフィス用品 | 文房具・オフィス用品
  33. CRCカードの手順 1. 参加者はクラスの候補をカードに記入する a. 表面にはクラスの概要や不変条件を自由に書く 2. 裏面に責務とコラボレーターを書く a. 書ききれない責務は別のクラスを作って移譲する 3.

    コンピュータになったつもりで、カードをオブジェクトに見立て てシナリオを実行してみる(ウォークスルー) a. オブジェクトは自身の責務以外のことはできない b. オブジェクトはコラボレーター以外と対話できない 4. 最後のステップに到達したら、事後条件を達成しているかど うかを確認する 5. 最後のステップまで到達できなかったり、事後条件を達成で きなかった場合、1に戻って考え直す
  34. この手順に従うとクラスの数が どんどん増えるんだけど? たくさんのクラスの間を飛び回らないと読み解け無い難 しいコードになりそう……。

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

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

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

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

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

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

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

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

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

  44. 現場でユースケースシナリオを 書いてみよう! ご清聴ありがとうございました You can find me at @dnskimox &

    https://dnskimox.hateblo.jp/
  45. 参考文献 ▸ 『オブジェクトデザイン』 ▸ 『UMLモデリングのエッセンス 第3版』 ▸ 『ユースケース実践ガイド』 ▸ 『ユースケース駆動開発実践ガイド』

    ▸ 『オブジェクト指向入門 第2版 方法論・実践』 ▸ ユースケース - Wikipedia ▸ イヴァー・ヤコブソン - Wikipedia ▸ CRCカードでチームが協働して設計する ▸ 「形式的」とは何だろう