QRコードからスマホで注文するシステムの要件定義をRDRA使ってやってみる-その２

https://qiita.com/s3imamura/items/41949e5a76a8d19f2acd の続き

## ユースケースと情報モデルの整合性を合わせる

ユースケースと情報モデルの整合性を確認してみる。
とりあえず、現状確認

#### ユースケース一覧

```plantuml
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentBorderColor #000000
skinparam shadowing false
hide footbox

actor 店員 as store_user
storage store_usecase #line.dotted [
    - カテゴリーを登録する
    - カテゴリーを参照する
    - カテゴリーを更新する
    - カテゴリーを削除する
    - メニューを登録する
    - メニューを参照する
    - メニューを更新する
    - メニューを削除する
    - QR コードを印刷する
    - QR コードを再発行する
    - 料理を注文伝票に追加する
    - 注文をキャンセルする
    - 注文伝票内の料理注文を確定する
    - 料理の注文を取消する
    - 注文された料理を見る
    - 料理を提供済みにする
    - メニューを売り切れにする
    - テーブルの注文履歴を見る
    - テーブルの注文金額合計を見る
    - テーブルを食事終了にする
]
store_user -- store_usecase

actor "客" as end_user
storage end_usecase #line.dotted [
    - メニュー一覧を見る
    - 料理を注文伝票に追加する
    - 注文伝票内の料理注文を確定する
    - 注文をキャンセルする
    - 注文履歴を見る
    - テーブルのステータスを食事終了にする
]
end_user -- end_usecase

actor "システム（cron）" as cron_user
storage cron_usecase #line.dotted [
    - オーダーストップする
]
cron_user -- cron_usecase

@enduml
```

#### 情報モデル

```plantuml
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentBorderColor #000000
skinparam shadowing false
hide footbox

card 店舗
card テーブル
card QRコード
card 客
card QRコード発行
card 注文伝票
card 注文履歴
card 食事料金合計
card メニュー
card メニュー表
card 料金
card カテゴリー

' 関連
店舗 -- テーブル
QRコード発行 -- QRコード
客 -- QRコード発行
テーブル -- QRコード発行
店舗 -- メニュー表
メニュー表 -- カテゴリー
カテゴリー -- メニュー
メニュー -- 注文伝票
メニュー -- 料金
QRコード -- 注文伝票
注文伝票 -- 注文履歴
食事料金合計 -- 注文履歴

@enduml
```

---

### 情報モデルの更新

まずは、ユースケース上で出てくる用語の内、情報モデルに含まれていないものがないか確認する。

```plantuml
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentBorderColor #000000
skinparam shadowing false
hide footbox

card 店舗
card テーブル
card QRコード
card 客
card QRコード発行
card 注文伝票
card 料理提供
card 注文料理
card 注文履歴
card 食事料金合計
card メニュー
card メニュー表
card 料金
card カテゴリー

' 関連
店舗 -- テーブル
QRコード発行 -- QRコード
客 -- QRコード発行
テーブル -- QRコード発行
店舗 -- メニュー表
メニュー表 -- カテゴリー
カテゴリー -- メニュー
メニュー -- 注文伝票
メニュー -- 料金
QRコード -- 注文伝票
注文伝票 -- 注文履歴
食事料金合計 -- 注文履歴
注文料理 -- 料理提供
注文履歴 -- 注文料理

@enduml
```

ユースケースに出てくる文言「注文料理」「料理提供」を追加した。

---

### ユースケースと情報モデルの関連付け

ユースケースと情報の関連を繋いでみる。

```plantuml
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentBorderColor #000000
skinparam shadowing false
hide footbox
left to right direction

storage "マスターデータ関連" #line.dotted {
    usecase UC_カテゴリー関連 [
        - カテゴリーを登録する
        - カテゴリーを参照する
        - カテゴリーを更新する
        - カテゴリーを削除する
    ]
    usecase UC_メニュー関連 [
        - メニューを登録する
        - メニューを参照する
        - メニューを更新する
        - メニューを削除する
    ]
    card カテゴリー as category
    card メニュー as menu

    ' 関連
    UC_カテゴリー関連 -- category
    UC_メニュー関連 -- category
    UC_メニュー関連 -- menu
}

storage "QRコード関連" #line.dotted {
    usecase UC_QRコード関連 [
        - QR コードを印刷する
        - QR コードを再発行する
    ]
    card 客 as customer
    card テーブル as table
    card QRコード as qr_code

    ' 関連
    UC_QRコード関連 -- table
    UC_QRコード関連 -- customer
    UC_QRコード関連 -- qr_code
}

storage "料理注文関連" #line.dotted {
    usecase 料理を注文伝票に追加する
    usecase 注文をキャンセルする
    usecase 注文伝票内の料理注文を確定する
    usecase 料理の注文を取消する
    card メニュー as menu3
    card 注文伝票 as order_slip
    card 注文料理 as ordered_dish

    ' 関連
    料理を注文伝票に追加する -- menu3
    料理を注文伝票に追加する -- order_slip
    注文をキャンセルする -- order_slip
    注文伝票内の料理注文を確定する -- order_slip
    注文伝票内の料理注文を確定する -- ordered_dish
    料理の注文を取消する -- ordered_dish
}

storage "調理提供関連" #line.dotted {
    usecase 注文された料理を見る
    usecase 料理を提供済みにする
    usecase メニューを売り切れにする

    card 注文料理 as ordered_dish2
    card メニュー as menu2

    ' 関連
    注文された料理を見る -- ordered_dish2
    料理を提供済みにする -- ordered_dish2
    メニューを売り切れにする -- menu2
}


storage "会計関連" #line.dotted {
    usecase テーブルの注文履歴を見る [
        - テーブルの注文履歴を見る
        - テーブルの注文金額合計を見る
    ]
    usecase テーブルを食事終了にする

    card テーブル as table2
    card 注文履歴 as order_history
    card 注文金額合計 as total_amount

    ' 関連
    テーブルの注文履歴を見る -- order_history
    テーブルの注文履歴を見る -- total_amount
    テーブルを食事終了にする -- table2
}

storage "システム関連" #line.dotted {
    usecase オーダーストップする

    card メニュー as menu4

    ' 関連
    オーダーストップする -- menu4
}

' マスターデータ関連 -[hidden]- QRコード関連
QRコード関連 -[hidden]-- 料理注文関連
料理注文関連 -[hidden]-- 調理提供関連
料理注文関連 -[hidden]-- 会計関連

@enduml
```

---

「オーダーストップ」と「メニュー」の関連はなんか変な感じ。
店舗情報として営業時間、最終注文時刻（オーダーストップ）を設けるべきと思う。
曜日によって、営業時間は異なるかかどうかでデータの持ち方が変わるだろうか。
「テーブル」の管理はユースケースに必要かも。
お客さんの人数によっては、テーブルを統合させたりするケースもありそうだ。

とりあえずこのシステムにおいては以下を想定する。
→ 曜日は問わず、11:00 ～ 14:00（LO:13:30）、17:30 ～ 22:00（LO:21:30）営業
→ 店の配置席数自体が大きく変わることはないが、お客さんの人数によっては、複数のテーブルをひとつに統合したりする場合もある。

---

### ユースケースと情報の関連付け修正

さっきの懸念点を踏まえて、ユースケース情報関連、情報モデル、ユースケース一覧を修正してみる。

```plantuml
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentBorderColor #000000
skinparam shadowing false
hide footbox
left to right direction

storage "マスターデータ関連" #line.dotted {
    usecase UC_カテゴリー関連 [
        - カテゴリーを登録する
        - カテゴリーを参照する
        - カテゴリーを更新する
        - カテゴリーを削除する
    ]
    usecase UC_メニュー関連 [
        - メニューを登録する
        - メニューを参照する
        - メニューを更新する
        - メニューを削除する
    ]
    usecase UC_店舗関連 [
        - 営業時間を参照する
        - 営業時間を更新する
        - 最終注文時刻を参照する
        - 最終注文時刻を更新する
    ]
    usecase UC_テーブル関連 [
        - テーブルを登録する
        - テーブルを参照する
        - テーブルを更新する
        - テーブルを削除する
    ]
    card カテゴリー as category
    card メニュー as menu
    card 店舗 as store
    card 営業時間 as business_hour
    card 最終注文時刻 as last_order_datetime
    card テーブル as table

    ' 関連
    UC_カテゴリー関連 -- category
    UC_メニュー関連 -- category
    UC_メニュー関連 -- menu

    UC_店舗関連 -- last_order_datetime
    UC_店舗関連 -- business_hour
    UC_テーブル関連 -- store
    UC_テーブル関連 -- table
}

storage "システム関連" #line.dotted {
    usecase オーダーストップする

    card 最終注文時刻 as last_order_datetime2

    ' 関連
    オーダーストップする -- last_order_datetime2
}

@enduml
```

---

```plantuml
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentBorderColor #000000
skinparam shadowing false
hide footbox

card 店舗
card テーブル
card QRコード
card 客
card QRコード発行
card 注文伝票
card 料理提供
card 注文料理
card 注文履歴
card 食事料金合計
card メニュー
card メニュー表
card 料金
card カテゴリー
card 営業時間
card 最終注文時刻

' 関連
店舗 -- テーブル
店舗 -- 営業時間
営業時間 -- 最終注文時刻
QRコード発行 -- QRコード
客 -- QRコード発行
テーブル -- QRコード発行
店舗 -- メニュー表
メニュー表 -- カテゴリー
カテゴリー -- メニュー
メニュー -- 注文伝票
メニュー -- 料金
QRコード -- 注文伝票
注文伝票 -- 注文履歴
食事料金合計 -- 注文履歴
注文料理 -- 料理提供
注文履歴 -- 注文料理

@enduml
```

```plantuml
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentBorderColor #000000
skinparam shadowing false
hide footbox


actor 店員 as store_user
storage store_usecase #line.dotted [
    - 営業時間を参照する
    - 営業時間を更新する
    - 最終注文時刻を参照する
    - 最終注文時刻を更新する
    - テーブルを登録する
    - テーブルを参照する
    - テーブルを更新する
    - テーブルを削除する
    - カテゴリーを登録する
    - カテゴリーを参照する
    - カテゴリーを更新する
    - カテゴリーを削除する
    - メニューを登録する
    - メニューを参照する
    - メニューを更新する
    - メニューを削除する
    - QR コードを印刷する
    - QR コードを再発行する
    - 料理を注文伝票に追加する
    - 注文をキャンセルする
    - 注文伝票内の料理注文を確定する
    - 料理の注文を取消する
    - 注文された料理を見る
    - 料理を提供済みにする
    - メニューを売り切れにする
    - テーブルの注文履歴を見る
    - テーブルの注文金額合計を見る
    - テーブルを食事終了にする
]
store_user -- store_usecase

actor "客" as end_user
storage end_usecase #line.dotted [
    - メニュー一覧を見る
    - 料理を注文伝票に追加する
    - 注文伝票内の料理注文を確定する
    - 注文をキャンセルする
    - 注文履歴を見る
    - テーブルのステータスを食事終了にする
]
end_user -- end_usecase

actor "システム（cron）" as cron_user
storage cron_usecase #line.dotted [
    - オーダーストップする
]
cron_user -- cron_usecase

@enduml
```

---

次は、サイトマップ（画面一覧）を作成しながら、ユースケースを調整する

## ユースケースと画面の整合性

まずは、どんな画面が必要か思いつくままにリストアップしてみる。
店舗側とお客さん側両方の画面をそれぞれ考える。

```plantuml
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentBorderColor #000000
skinparam shadowing false
hide footbox

left to right direction

storage "店舗サイト" {
    rectangle ログイン

    storage "来店～会計" #line.dotted {
        rectangle "ダッシュボード\n（各テーブルの状況）" as dashboard
        rectangle テーブル詳細 as table_detail
        rectangle "料理注文状況\n（店舗全体の注文一覧）" as order_list
        rectangle "売り切れ設定" as sold_out_setting

        dashboard -- table_detail
    }
    storage "マスターデータ設定" #line.dotted {
        rectangle 店舗設定
        rectangle テーブル管理
        rectangle カテゴリー一覧
        rectangle メニュー一覧
        rectangle メニュー詳細
        rectangle メニュー新規登録

        メニュー一覧 -- メニュー詳細
        メニュー一覧 -- メニュー新規登録
    }

    ログイン -- dashboard
    dashboard --[hidden]-- 店舗設定
}


storage "メニュー表" {
    rectangle "メニュー表\n（ホーム）" as end_home
    rectangle "メニュー詳細\n（注文伝票追加）" as end_order
    rectangle 注文伝票 as end_order_slip
    rectangle 料理注文完了 as end_order_complete
    rectangle 注文履歴 as end_order_history
    rectangle 食事終了 as end_stop
    end_home -- end_order
    end_home -- end_order_slip
    end_order_slip -- end_order_complete
    end_order -- end_order_complete

    end_home -- end_order_history
    end_order_history -- end_stop
}

@enduml
```

---

おそらく、店舗のフロアスタッフとしては、現在の店舗のテーブルステータス（満空状況、未提供の料理注文数、合計金額）を俯瞰して把握できる画面がほしいだろう。
また店舗の調理スタッフとしては、現在の料理注文のステータス（何がいつ注文されて、未提供なのか）を俯瞰して把握できる画面がほしいだろう。
お客さん側には必要ないけど、店舗側には ID ／パスワード等による認証機能が必要だろう。

---

### ユースケースと画面の関連をつなぐ

一覧で出した画面とユースケースをひとまず思いつくままにつないでみる。
不足する画面やユースケースが存在する場合は適宜更新する。

```plantuml
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentBorderColor #000000
skinparam shadowing false
hide footbox

left to right direction


storage "メニュー表" {
    rectangle "メニュー表\n（ホーム）" as end_home
    rectangle "メニュー詳細\n（注文伝票追加）" as end_order
    rectangle 注文伝票 as end_order_slip
    rectangle 料理注文完了 as end_order_complete
    rectangle 注文履歴 as end_order_history
    rectangle 食事終了 as end_stop
    end_home -- end_order
    end_home -- end_order_slip
    end_order_slip -- end_order_complete
    end_order -- end_order_complete

    end_home -- end_order_history
    end_order_history -- end_stop

    usecase メニュー一覧を見る
    usecase 料理を注文伝票に追加する
    usecase 注文伝票内の料理注文を確定する
    usecase 注文をキャンセルする
    usecase 注文履歴を見る
    usecase テーブルのステータスを食事終了にする

    end_home ... メニュー一覧を見る
    end_order .. 料理を注文伝票に追加する
    end_order_slip .. 注文伝票内の料理注文を確定する
    end_order_slip .. 注文をキャンセルする
    end_order_complete .. 注文伝票内の料理注文を確定する
    end_order_history .. 注文履歴を見る
    end_order_history .. テーブルのステータスを食事終了にする
    end_stop .. テーブルのステータスを食事終了にする
}
@enduml
```

```plantuml
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentBorderColor #000000
skinparam shadowing false
hide footbox

left to right direction

storage "店舗サイト" {
    rectangle ログイン

    usecase UC_ログイン関連 #greenyellow [
        - ログインする
        - ログアウトする
    ]
    ログイン . UC_ログイン関連

    storage "来店～会計" #line.dotted {
        ' 画面
        rectangle "ダッシュボード\n（各テーブルの状況）" as dashboard
        rectangle "料理注文状況\n（店舗全体の注文一覧）" as order_list
        rectangle "売り切れ設定" as sold_out_setting
        rectangle "テーブル詳細\n（注文履歴一覧）" as table_detail
        rectangle "テーブル詳細\n（メニュー表）"  as table_detail_menu_list #greenyellow
        rectangle "テーブル詳細\n（メニュー詳細）" as table_detail_menu_detail #greenyellow
        rectangle "テーブル詳細\n（注文伝票）" as table_detail_order_slip #greenyellow
        rectangle "テーブル詳細\n（注文完了）" as table_detail_order_complete #greenyellow

        dashboard -- table_detail
        table_detail -- table_detail_menu_list
        table_detail -- table_detail_order_slip
        table_detail_menu_list -- table_detail_menu_detail
        table_detail_menu_detail -- table_detail_order_complete
        table_detail_order_slip -- table_detail_order_complete

        ' ユースケース
        usecase UC_QRコード  #greenyellow [
            - QR コードを発行する
            - QR コードを再発行する
        ]
        usecase 料理を注文伝票に追加する
        usecase 注文をキャンセルする
        usecase 注文伝票内の料理注文を確定する
        usecase 料理の注文を取消する
        usecase 料理の注文状況を見る #greenyellow
        usecase 料理を提供済みにする
        usecase メニューを売り切れにする
        usecase テーブルの注文履歴を見る
        usecase テーブルの注文金額合計を見る
        usecase テーブルを食事終了にする

        ' 画面 - ユースケース関連
        dashboard .. UC_QRコード
        table_detail .. UC_QRコード
        table_detail_menu_detail .. 料理を注文伝票に追加する
        table_detail_order_slip .. 注文をキャンセルする
        table_detail_order_slip .. 注文伝票内の料理注文を確定する
        table_detail_order_complete .. 注文伝票内の料理注文を確定する
        table_detail .. 料理の注文を取消する

        order_list .. 料理の注文を取消する
        order_list .. 料理の注文状況を見る
        order_list .. 料理を提供済みにする
        sold_out_setting .. メニューを売り切れにする
        table_detail .. テーブルの注文履歴を見る
        table_detail .. テーブルの注文金額合計を見る
        table_detail .. テーブルを食事終了にする
    }

    storage "マスターデータ設定" #line.dotted {
        ' 画面
        rectangle 店舗設定
        rectangle テーブル管理
        rectangle カテゴリー一覧
        rectangle メニュー一覧
        rectangle メニュー詳細
        rectangle メニュー新規登録

        メニュー一覧 -- メニュー詳細
        メニュー一覧 -- メニュー新規登録

        ' ユースケース
        usecase UC_店舗情報 [
                - 営業時間を参照する
                - 営業時間を更新する
                - 最終注文時刻を参照する
                - 最終注文時刻を更新する
        ]
        usecase UC_テーブル情報 [
            - テーブルを登録する
            - テーブルを参照する
            - テーブルを更新する
            - テーブルを削除する
        ]
        usecase UC_カテゴリー情報 [
            - カテゴリーを登録する
            - カテゴリーを参照する
            - カテゴリーを更新する
            - カテゴリーを削除する
        ]
        usecase UC_メニュー情報 [
            - メニューを削除する
            - メニューを参照する
        ]

        usecase メニューを登録する
        usecase メニューを更新する

        ' 画面 - ユースケース関連
        店舗設定 ... UC_店舗情報
        テーブル管理 ... UC_テーブル情報
        カテゴリー一覧 ... UC_カテゴリー情報
        メニュー一覧 ... UC_メニュー情報
        メニュー新規登録 .. メニューを登録する
        メニュー詳細 .. メニューを更新する
    }
}
@enduml
```

---

追加、更新した要素は、黄緑色にした。
・ユースケースの文言を「QR コードを印刷する」→「QR コードを発行する」に変更した。
・ユースケースの文言を「注文された料理を見る」→「料理の注文状況を見る」に変更した。
・ユースケース「ログイン／ログアウトする」を追加した。
・画面「テーブル詳細」を分割した。

---

## 論理 ERD のたたき台を作成

RDRA の範疇からは外れてしまうが、ユースケースの整合性合わせたり、ここではじめて気づくこともあるので、要件定義の中でも早めに論理 ERD を作成していく。
※物理は考えない

とりあえず、今のユースケースを満たすようなデータ構造を考える。
ユースケース外でも必要と思われるデータがあれば適宜追加する。

```plantuml
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentBorderColor #000000
skinparam linetype ortho
skinparam shadowing false
hide footbox
hide circle

entity ログインアカウント {
    ID
    --
    パスワード
}

entity 営業時間 {
    営業開始時刻
    --
    営業終了時刻
    最終注文時刻
}

entity テーブル {
    テーブル名
    --
    活性化ステータス
}

entity カテゴリー {
    カテゴリー名
    --
}

entity メニュー {
    メニュー名
    （カテゴリー名）
    --
    メニュー料金
    写真URL
    提供可否フラグ
}

entity QRコード発行 {
    トークン
    （テーブル名）
    --
    発行日時
    有効期限
    有効ステータス
}

entity 食事料金 {
    トークン
    （テーブル名）
    --
    食事ステータス
    合計金額
}

entity 注文伝票 {
    伝票番号（代理キー）
    --
    テーブル名
    トークン
    連番
    --
    注文ステータス
    注文確定日時
}

entity 注文伝票明細 {
    伝票番号 <<FK>>
    連番
    --
    メニュー名
    （カテゴリー名）
    数量
    注文日時
    提供済みフラグ
    提供日時
    取消フラグ
    取消日時
}

カテゴリー ||--o{ メニュー
テーブル ||--o{ QRコード発行
QRコード発行 ||--o{ 注文伝票
注文伝票 ||--o{ 注文伝票明細
メニュー ||..o{ 注文伝票明細
QRコード発行 ||-|| 食事料金


@enduml
```

---

**思ったこと**

- アカウントって複数必要なんだろうか？
  - 1 コで良い気がする
- QR コードは有効期限が必要と思う
  - 発行から 2~3 時間くらい？
- QR コードは「再発行」じゃなくて「再印刷」のほうが良いかも
  - 「発行」だとトークンも変わってしまうイメージがした
- テーブルの状態遷移はもう少し考えるほうが良さそう
  - 「（テーブル統合による）非活性化、活性化」と「食事中、食事終了」のステータスは分けて考えるほうがよい
- 「伝票に登録しているけど注文確定していない状態からのキャンセル」と「注文確定からの取消」を区別できるようにしなきゃいけない
  - データ構造だけでなく、用語も考え直すべき
    - 取消とキャンセルって一緒じゃねーか）
  - （ほんとは前から思ってたけど、無視してたら、ここに来てやっぱり問題になった感じ）
- 金額はどこに持つか？
- 売り切れとオーダーストップは、同じステータスで管理してもよいか？
- というか「QR コード」って発行するものじゃなくて、単なる出力形式か
  - 本当に発行しているのは「トークン」
- 注文確定させる前の仮置場のようなもの
  - ショッピングカートの概念に近い
  - お客様側で使っている用語がなければ「注文カート」とする。
  - あれ、というか、注文カートってデータ持たないほうがよいな。
  - 複数人で同時に注文とかした場合とか、勝手に注文されたり、気づかずに重複して注文したりして、店舗側のオペレーションがめんどくさくなりそう
  - ということをお伝えして、注文カートは各端末で管理。すなわち DB では関与しないとする
  - ユースケース、情報モデルにも反映する
- まとめて料理を注文する際の単位も業務上、大きな意味はなさそうなので「注文伝票」「注文伝票明細」テーブルは「料理注文」にまとめる

---

上記考慮して ERD 更新する。

```plantuml
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentBorderColor #000000
skinparam linetype ortho
skinparam shadowing false
hide footbox
hide circle

entity ログインアカウント {
  アカウントID
  --
  パスワード
}

entity 営業時間 {
  営業時間ID
  --
  営業開始時刻
  営業終了時刻
  最終注文時刻
}

entity カテゴリー {
  カテゴリーID
  --
  カテゴリー名
}

entity メニュー {
  メニューID
  --
  カテゴリーID <<FK>>
  メニュー名
  メニュー料金
  写真URL
  提供可否フラグ
}

entity テーブル {
  テーブルID
  --
  テーブル名
  テーブルステータス
}

entity トークン発行 {
  トークン発行ID
  --
  テーブルID<<FK>>
  トークン
  発行日時
  有効期限
  トークンステータス
}

entity 食事 {
  食事ID
  --
  トークン発行ID<<FK>>
  （テーブルID）<<FK>>
  食事ステータス
  合計金額
}

entity 料理注文 {
  料理注文ID
  --
  食事ID <<FK>>
  メニューID <<FK>>
  数量
  注文日時
  料理注文ステータス
  （テーブルID） <<FK>>
}

カテゴリー ||--o{ メニュー

テーブル ||--o{ 食事
トークン発行 ||..o| 食事
テーブル ||..o{ トークン発行

食事 ||--o{ 料理注文
メニュー ||--o{ 料理注文

@enduml
```

---

いったんここまで。
論理 ERD で色々と考えることがあったので、清書も兼ねて他のモデルにも反映させていく。
それができたら、お客様に説明しつつ懸念点など一緒に確認してもらう予定。

↓ 続き
https://qiita.com/s3imamura/items/e169b7507d59053117e5