[no_code]OCR表格处理——技术规格说明书

项目 内容
这个作业属于哪个课程 2020春季计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里 技术规格说明书
我们在这个课程的目标是 远程协同工作,采用最新技术开发软件
这个作业在哪个具体方面帮助我们实现目标 确定项目技术,制定技术规格

目前的最新版可以trace我们的石墨文档链接

技术栈

我们的任务有模式识别(OCR),数据云服务等多个技术需求,总体上采取了前后端分离的设计,应对可能产生的发布在多平台的场景.

后端框架

Django,考虑到手机用户的跨平台性,以及开发效率与成员的技术栈,我们选择了Django.

数据库

由于后端框架选择的是Django,经过初步调研,我们选择了适宜于与Django配套使用的Postgresql作为主数据库。在后续开发过程中,如有必要,我们可能会加入如MySQL之类的数据库作为辅助。

前端框架

可能会选择React或者是vue.js,这一块可以考量一些表格显示方面比较优秀的框架。

移动端开发

为了尽可能地与前端开发共享技术栈,降低开发难度,我们选择ReactNative作为移动端开发的框架

web引擎

如果有必要,可以选择使用nginx.

云环境

当前的云环境:学校的华为云环境

可能需要的云环境:

  1. 内容分发网络服务CDN: 用户资源相关
  2. 云Postgresql数据库

技术如何体现设计原则

抽象原则

  1. 底层数据抽象化
    • 把底层数据表单数据抽象化,原始图片(origin)和JSON格式的格式化数据(json)、以及Excel格式数据(excel)是这个表单数据的多个层次。
    • 考虑到可能一个用户有针对单一表单的OCR需求,和多个表单联合的OCR需求,我们要开发不同层次的接口应对不同粒度的需求
  2. 数据行为模块化
    • 考虑不同的行为,基于需求类型进行分类
    • 不同行为的需求划分在不同的区域内
    • 定义一些数据的预处理、后期处理操作

内聚与解耦合

采用前后端分离,采用Restful API就已经很好地体现了这一点。

信息隐藏和封装

我们认为信息隐藏需要做到:

  1. 前后端信息分离

  2. 用户无法直接访问与修改核心数据

我们应该通过接口与规格的约束,使得类和成员的可访问性最小。各种语言中提供了包、protect、private等等来限制访问权限,一些开源框架也有类似的作用。

目前,我们打算前后端通过Restful API进行交互,从而实现信息隐藏。

界面和实现分离

  1. 后端实现提供Restful API,前端通过访问特定的API完成相应的操作
  2. 前后端通过json进行交互,双方均可处理并具有可扩展性
  3. 前端进行同一化的视图层的管理, 易于更改. 不需要再去后端代码中分离.

错误处理

考虑到后端和前端的交互通过Restful API进行,我们选择使用HTTP状态码作为错误分类方式。

HTTP状态码 表述的含义
400 请求参数有误,调用存在语义错误
401 用户未登录,请求身份验证
403 权限不足
404 请求路径错误
405 请求方法错误
413 请求实体过大,超出服务器的处理能力。 如上传图片尺寸过大
500 服务器内部错误、后端遇到了无法处理或者未捕获的错误

除了HTTP状态码以外,我们还在Body中的json信息加入一项status_code,用于更详细地描述错误。

软件运行的一些相关性假设

  1. 用户提供的都是表格数据、对于非表格数据,可以后续做一些误识别处理
  2. 用户提供的可合并表格具有可合并性,不可合并的表格需要定义一下行为
  3. OCR后的数据不一定是完整的表格数据、需要支持用户对表格数据的快捷修改

如何灵活应对变化

  1. 后端处理相关的操作,将提供多个粒度的Restful API,将方便应对不同的应用需求
  2. 扁平化的设计策略,避免多个业务逻辑直接耦合

大量数据的处理能力

  1. 读写和数据库分离:考虑到我们这边的需求比较简单,很难产生疯狂的需求压力,我们会在测试后考虑是否需要做分离操作。
  2. 数据上云:
    • 前端资源可以考虑cdn分流静态资源、减轻服务器压力
    • 用户的数据将及时备份到远端数据库,便于用户在其他设备上访问数据
原文地址:https://www.cnblogs.com/no-code-2020/p/12657183.html