共享单车概念设计

holic-x...大约 5 分钟

共享单车概念设计

场景1

题目说明

(数据流图)假设你是某家共享单车公司的软件工程师，请你为共享单车管理系统的维修模块做需求分析。业务流程为用户申请修理单车，上报到维修人员，然后维修人员到场回收和维修。该操作涉及到的外部实体有用户和维修人员，处理流程有申请维修、回收单车和维修单车，请自行设计合适的数据流和数据存储，并把需求分析的结果画成数据流图。

需求分析

结合题目要求分析，可将共享单车管理系统的维修模块进行拆分：主要面向系统应用群体为用户、维修人员，主要功能模块针对维修模块进行扩展，划分为用户：申请维修、维修反馈；维修人员：回收单车、维修单车

数据流图（StarUML）

结合题目要求分析，按照分层数据流图的设计方案勾勒基本的数据流图，具体分析如下（构建如下数据流图）

顶层图
顶层图主要是把整个系统看成一个大的加工，然后根据数据实体从哪些外部实体接收数据流，以及系统发送哪些数据流到外部实体，就可以画出输入输出图。此处将“共享单车管理系统的维修模块”当做是一个大的加工，从用户、维修人员这些外部实体接收、转化、输出数据流，勾勒其简单的输入输出图

一层图
一层数据流图对顶层图进行了系统功能拆分拆分，将其分为“申请维修、回修处理、维修处理、维修反馈”四个个加工站点，在此基础上细化了与外部实体交互输入输出流。由于涉及的交互比较简单，此处直接在顶层图的基础上勾勒一层图，细化外部实体、加工站点、数据流、数据存储文件等交互，参考如下图所示

场景2

题目说明

(E-R关系图)假设你是某家共享单车公司的软件工程师，请你为共享单车管理系统的维修模块做概念结构设计。由于单车覆盖越来越广，单个维修人员无法满足业务需要，公司设置了维修部门。该阶段设计涉及到的实体有用户、单车、维修部门主管和回收人员。业务流程为用户申请修理单车，上报到维修部门主管，维修部门主管通知回收人员，回收人员到场回收。(提示: 参考工厂管理系统的E-R关系图)

功能模块说明

ER图设计说明

初步用户体系ER构建

结合题目要求分析，系统模块主要涉及的用户类型可划分为2类，一类是针对普通用户、一类是针对员工（员工可根据不同的员工类别进行扩展，例如此处涉及到维修部门主管、回收人员亦或是回收人员），根据用户体系简单构建如下E-R图

用户拥有自己的账号信息（一对一）、单车信息（一对多）

员工拥有自己的账号信息（此处将维修部门主管和回收人员划分为员工概念，通过员工类型或者其关联的账号类型界定其身份和角色权限，便于后续扩展）

（其中设计冗余字段“扩展属性”概念可结合系统需求自定义调整实体的属性定义）

-- 实体说明
【用户】：用户id、用户姓名、用户性别、出生日期、扩展属性
【账号信息】：账号id、登录类型、账号角色、登录账号、登录密码
【员工（维修部门主管、回收人员）】：员工id、员工姓名、入职日期、身份证号、扩展属性
【单车】：单车记录id、单车型号、单车名称、扩展属性

功能扩展延伸ER构建

结合题目要求分析，业务流程为用户申请修理单车，上报到维修部门主管，维修部门主管通知回收人员，回收人员到场回收。其中涉及到“申请修理记录管理”、“任务分配”、“回收处理”概念，则可定义如下实体存储关联信息并将其与用户体系进行绑定

-- 实体说明
【申请维修记录】：维修记录id、申请人（关联普通用户）、报修单车（关联单车记录id）、记录处理状态、记录创建时间、记录更新时间
【任务分配】：分配记录id、指派任务（关联申请维修记录）、分配人（关联维修部门主管）、指派人处理人（关联回收人员）、分配时间、任务处理状态、记录更新时间
【回收处理】：处理记录id、处理人（关联回收人员）、所属分配记录（关联任务分配id）、回收处理状态、记录更新时间

（先画出每个单独实体绑定的属性，随后在建立关联的时候去除“外键”属性，用“关联”（1-1、1-n、m-n）替代相对应的属性设定）