[no_code]OCR表格处理——技术规格说明书
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 技术规格说明书 |
| 我们在这个课程的目标是 | 远程协同工作，采用最新技术开发软件 |
| 这个作业在哪个具体方面帮助我们实现目标 | 确定项目技术，制定技术规格 |
目前的最新版可以trace我们的石墨文档链接
技术栈
我们的任务有模式识别(OCR)，数据云服务等多个技术需求，总体上采取了前后端分离的设计，应对可能产生的发布在多平台的场景.
后端框架
Django，考虑到手机用户的跨平台性，以及开发效率与成员的技术栈，我们选择了Django.
数据库
由于后端框架选择的是Django，经过初步调研，我们选择了适宜于与Django配套使用的Postgresql作为主数据库。在后续开发过程中，如有必要，我们可能会加入如MySQL之类的数据库作为辅助。
前端框架
可能会选择React或者是vue.js，这一块可以考量一些表格显示方面比较优秀的框架。
移动端开发
为了尽可能地与前端开发共享技术栈，降低开发难度，我们选择ReactNative作为移动端开发的框架
web引擎
如果有必要，可以选择使用nginx.
云环境
当前的云环境：学校的华为云环境
可能需要的云环境:
- 内容分发网络服务CDN: 用户资源相关
- 云Postgresql数据库
技术如何体现设计原则
抽象原则
- 底层数据抽象化
- 把底层数据表单数据抽象化，原始图片(origin)和JSON格式的格式化数据(json)、以及Excel格式数据(excel)是这个表单数据的多个层次。
- 考虑到可能一个用户有针对单一表单的OCR需求，和多个表单联合的OCR需求，我们要开发不同层次的接口应对不同粒度的需求
- 数据行为模块化
- 考虑不同的行为，基于需求类型进行分类
- 不同行为的需求划分在不同的区域内
- 定义一些数据的预处理、后期处理操作
内聚与解耦合
采用前后端分离，采用Restful API就已经很好地体现了这一点。
信息隐藏和封装
我们认为信息隐藏需要做到：
-
前后端信息分离
-
用户无法直接访问与修改核心数据
我们应该通过接口与规格的约束，使得类和成员的可访问性最小。各种语言中提供了包、protect、private等等来限制访问权限，一些开源框架也有类似的作用。
目前，我们打算前后端通过Restful API进行交互，从而实现信息隐藏。
界面和实现分离
- 后端实现提供Restful API，前端通过访问特定的API完成相应的操作
- 前后端通过json进行交互，双方均可处理并具有可扩展性
- 前端进行同一化的视图层的管理, 易于更改. 不需要再去后端代码中分离.
错误处理
考虑到后端和前端的交互通过Restful API进行，我们选择使用HTTP状态码作为错误分类方式。
| HTTP状态码 | 表述的含义 |
|---|---|
| 400 | 请求参数有误，调用存在语义错误 |
| 401 | 用户未登录，请求身份验证 |
| 403 | 权限不足 |
| 404 | 请求路径错误 |
| 405 | 请求方法错误 |
| 413 | 请求实体过大，超出服务器的处理能力。 如上传图片尺寸过大 |
| 500 | 服务器内部错误、后端遇到了无法处理或者未捕获的错误 |
除了HTTP状态码以外，我们还在Body中的json信息加入一项status_code，用于更详细地描述错误。
软件运行的一些相关性假设
- 用户提供的都是表格数据、对于非表格数据，可以后续做一些误识别处理
- 用户提供的可合并表格具有可合并性，不可合并的表格需要定义一下行为
- OCR后的数据不一定是完整的表格数据、需要支持用户对表格数据的快捷修改
如何灵活应对变化
- 后端处理相关的操作，将提供多个粒度的Restful API，将方便应对不同的应用需求
- 扁平化的设计策略，避免多个业务逻辑直接耦合
大量数据的处理能力
- 读写和数据库分离：考虑到我们这边的需求比较简单，很难产生疯狂的需求压力，我们会在测试后考虑是否需要做分离操作。
- 数据上云：
- 前端资源可以考虑cdn分流静态资源、减轻服务器压力
- 用户的数据将及时备份到远端数据库，便于用户在其他设备上访问数据
