[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分流静态资源、减轻服务器压力
- 用户的数据将及时备份到远端数据库，便于用户在其他设备上访问数据