用例分析
主要从以下三种元素入手：
角色
信息
动作
接下来做单独分解。角色
在我们的报餐系统里，将会出现以下角色：
• 游客 —— 没有登录的用户；
• 普通用户 —— 注册用户， 可以订餐、撤餐、查看报餐记录、消费记录、一周菜式，只能订标准餐；
• 办公室用户 —— 注册用户， 可以订餐、撤餐、查看报餐记录、消费记录、一周菜式、登记自助餐（只选择餐别、用餐时间、用餐人数）或者接待餐（用餐人员信息、时间、菜单、餐标）；
• 运营 —— 可以导入、编辑用户、导入菜单、导入餐别、菜品、处理订单；
• 管理员 —— 权限最高的用户角色，可以管理运营。信息结构
主要信息有：
• 部门 —— 模型名称 Department，包含 部门名称；
• 用户 —— 模型名称 User，包含 姓名、性别、状态、头像、部门id、职务、手机、微信openid、密码、邮箱；hasMany(Order)
• 餐厅 —— 模型名称 Canteen， 包含 名称、地址；
• 餐别 —— 模型名称 Meal，包含餐别名称、订餐开始时间、订餐结束时间、用餐开始时间、用餐结束时间；
• 菜品类别 —— 模型名称 DishType，包含名称；
• 菜品 —— 模型名称 Dish , 包含 名称、类别id、餐厅id、计量单位、单价、图片、备注；
• 菜谱 —— 模型名称 Menu，包含：餐厅、星期、餐别id、菜品id、菜品名称；
• 订单
• 点餐明细 —— 模型名称 OrderDetail，包含：员工id、部门id、餐厅Id、餐别Id、订餐日期、菜品编码、菜品名称、单位、单价、数量、操作日期、订单状态；
• 订单 —— 模型名称 Order，包含订单流水、员工id、订单总金额、订单备注、支付时间、支付方式、支付平台订单号、退款状态、退款单号、订单是否关闭、额外数据；hasMany(OrderItem)
• 订单项 —— 模型名称 OrderItem，一个订单会包含一个或多个订单项，每个订单项都会与一个菜品id关联，包含所属订单id、餐厅Id、餐别Id、订餐日期、对应菜品id、菜品名称、单位、单价、数量；belongsTo(Order)
• 运营人员 —— 模型名称 Operator，管理员也属于运营人员。动作
角色和信息之间的互动称之为『动作』，动作主要有以下几个：
• 创建 Create
• 查看 Read
• 编辑 Update
• 删除 Delete
用例
1.游客
• 游客可以看到每日菜谱；用户
• 用户可以手机注册、微信注册登录；
• 用户可以看到每日菜谱；
• 用户可以点菜点餐；
• 用户可以通过微信支付订单；
• 用户可以查看自己的订单信息；
• 用户可以对已支付的订单申请取消订餐、退款；
• 用户可以对已购买的订单发布评价（options）。运营
• 运营可以看到所有的用户列表；
• 运营可以设置餐厅、餐别、菜品、菜式；
• 运营可以对申请撤餐的订单执行退款；管理员
• 管理员可以查看运营人员列表；
• 管理员可以新增运营人员；
• 管理员可以编辑运营人员；
• 管理员可以删除运营人员。
