脱机手写中文文本行识别系统——需求分析与概念原型建立
在近两节高级软件工程课中，我们学习了有关软件工程中需求分析的知识，而本文就打算使用上课所讲的方法对工程实践项目进行需求分析并建立概念原型。
我的工程实践选题是基于深度学习的脱机手写中文文本行识别系统，脱机手写中文文本行识别是指，将手写体的中文纸质文档通过扫描或拍照的方式转化为数字图像，并进一步对该图像中的中文文本行进行识别。整个项目的开发流程并不像传统的信息管理系统那样有着从需求分析到项目测试、维护的完整流程，所以在刚开始做工程实践时我也没有认真考虑过此项目的需求是什么，看到作业题目时也是一脸懵，直到看到群里可能是助教学长说就算是深度学习项目也要落地，我才有了点思路。所以在接下来的文章中我就从脱机手写中文文本行识别系统落地的角度上对项目进行用例建模、业务领域建模以及数据建模，最终形成概念原型。
参考资料：课堂PPT
（一）用例建模
1、什么是用例？
用例的核心概念中首先它是一个业务过程，经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务的一系列活动就是业务过程。
2、用例建模的基本步骤：
- 第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例；
- 第二步，描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
- 第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
- 第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
3、按照上述步骤对项目进行用例建模：
(1)（第一步）根据分析，脱机手写中文文本行系统主要有以下几个用例：
R1：客户可以在系统的初始界面中登录系统，如果是新用户，则应先注册账户。
R2：客户通过脱机手写中文文本行系统传入一批手写中文的数字图像，系统可以及时地返回一个结果。这个结果包括将每一张图片中的每一个文本行用矩形框框出来，然后对每一个文本行进行识别并输出识别后的整体的电子文档。
R3：当客户点击纠错按钮时，系统要标出识别后的电子文档中它认为准确率不高的一些文本行，方便客户手动纠错。
R4：系统允许用户在线使用写字板写下一段文本，然后生成离线图片，再对这个图片进行识别，主要为了便于客户测试和验收（注意：尽管是在线写下文本段，但由于最终是对离线图片识别，所以依然是脱机手写中文文本行识别）。
R5：系统要提供接口允许管理员方便地更换优化后的模型。
R6：系统要允许管理员管理客户信息。
课件中提出了准确提取用例的方法，在这里可以得到：
① System：脱机手写中文文本行系统——识别子系统
Actor：客户
Use Cases：
UC1：登录系统；
UC2：注册账户；
UC3：上传手写中文数字图像，得到识别结果；
UC4：在线生成手写图片；
UC5：上传手写中文数字图像，得到纠错结果；
② System：脱机手写中文文本行系统——后台管理子系统
Actor：管理员
Use Cases：
UC6：更换模型；
UC7：管理客户信息（增删改查）；
(2)（第二步）描述上述用例的开始和结束状态，得到高层用例：
|
UC1：登录系统； TUCBW：客户输入账号和密码，点击登录按钮； TUCEW：成功登录，进入系统首页； |
|
UC2：注册账户； TUCBW：客户输入手机号/邮箱，点击发送验证码； TUCEW：注册成功，进入登录页面； |
|
UC3：上传手写中文数字图像，得到识别结果； TUCBW：客户上传一批手写中文的数字图像； TUCEW：系统框出图像中的所有文本行并显示识别结果； |
|
UC4：在线生成手写图片； TUCBW：客户在系统中打开手写板功能； TUCEW：客户点击确定，系统返回识别结果； |
|
UC5：上传手写中文数字图像，得到纠错结果； TUCBW：客户点击纠错按钮； TUCEW：系统给出识别结果中它认为准确率不高的一些文本段； |
|
UC6：更换模型； TUCBW：管理员通过接口将之前的模型文件替换为优化后的模型文件； TUCEW：系统正常运行； |
|
UC7：管理客户信息； TUCBW：管理员进入客户信息管理页面； TUCEW：点击“确认”，客户信息更新完毕； |
(3)（第三步）画出用例图
① 客户用例图：
② 管理员用例图：
(4)（第四步）进一步逐一分析用例与参与者的详细交互过程，列出扩展用例：
① 脱机手写中文文本行识别系统——识别子系统的扩展用例：
a. 登录系统的扩展用例：
| Actor：客户 | System：识别子系统 |
| 1. TUCBW 客户进入系统首页，点击登录按钮。 | 2. 系统弹出登录界面，要求客户填入必要的信息。 |
| 3. 客户点击确定按钮。 | 4. 系统检查客户填入的账号密码或验证码是否正确。若正确，则进入系统主页面；若不正确，则提示相应的错误信息。 |
| 5. TUCEW 客户进入系统主页面或根据相关提示信息重新登录。 |
b. 注册账户的扩展用例：
| Actor：客户 | System：识别子系统 |
| 1. TUCBW 客户进入系统首页，点击注册按钮。 | 2. 系统弹出注册界面，要求客户填入手机号。 |
| 3. 客户输入手机号后点击“获取验证码”。 | 4. 系统向客户手机发送验证码。 |
| 5. 客户输入验证码，点击确定。 | 6. 系统检验验证码是否正确，若正确，要求客户新建账户；若不正确，提示相应错误信息。 |
| 7. 客户输入账号密码完成注册或根据错误信息重新发送验证码。 | 8. 系统在后台数据库的客户表中新增一项。 |
| 9. TUCEW 完成注册，进入登录界面。 |
c. 上传手写中文数字图像并获取识别结果的扩展用例：
| Actor：客户 | System：识别子系统 |
| 1. TUCBW 客户点击上传，上传本地的某个文件夹，这个文件夹中包含一批手写中文图片。 | 2. 系统加载这批图片。 |
| 3. 客户点击识别按钮。 | 4. 系统调用训练好的模型对这批图片进行预测，框出图片中的每一个单独文本行并在旁边给出识别结果。 |
| 5. 客户点击下一张/上一张按钮。 | 6. 系统展示不同图片的识别结果。 |
| 7. TUCEW 客户点击下载将电子文档下载到本地。 |
d. 在线生成手写图片的扩展用例：
| Actor：客户 | System：识别子系统 |
| 1. TUCBW 客户点击“在线生成手写图片”按钮。 | 2. 系统打开手写板功能模块。 |
| 3. 用户通过鼠标或其他工具在手写板上写出一个文本段落，点击“完成”按钮。 | 4. 系统将其保存为图片格式，然后再对这个图片进行识别，将识别结果返回到屏幕上。 |
| 5. TUCEW 客户获得识别结果。 |
e. 上传手写中文数字图像并获取纠错结果的扩展用例：
| Actor：客户 | System：识别子系统 |
| 1. TUCBW 客户点击上传，上传本地的某个文件夹，这个文件夹中包含一批手写中文图片。 | 2. 系统加载这批图片。 |
| 3. 客户点击识别按钮。 | 4. 系统调用训练好的模型对这批图片进行预测，框出图片中的每一个单独文本行并在旁边给出识别结果。 |
| 5. 客户点击纠错按钮。 | 6. 系统标出识别结果中准确率较低的文本行。 |
| 7. TUCEW 客户获得了纠错结果。 |
② 脱机手写中文文本行识别系统——后台管理子系统的扩展用例：
a. 更换模型的扩展用例：
| Actor：管理员 | System：后台管理子系统 |
| 1. TUCBW 管理员登录后台管理子系统。 | 2. 弹出后台管理子系统主页面。 |
| 3. 管理员点击上传模型按钮。 | 4. 系统通过提前编写好的接口将新模型替换旧模型集成到系统中。 |
| 5. TUCEW 退出系统。 |
b. 管理客户信息的扩展用例：
| Actor：管理员 | System：后台管理子系统 |
| 1. TUCBW 管理员登录后台管理子系统。 | 2. 弹出后台管理子系统主页面。 |
| 3. 管理员对客户信息进行增删改查操作，然后点击确认按钮。 | 4. 系统将管理员所做修改保存到数据库中。 |
| 5. TUCEW 退出系统。 |
（二）业务领域建模
1、业务领域建模的步骤
- 第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
- 第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
- 第三步，给这些应用业务领域概念分类。分别列出哪些是类、属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
- 第四步，将结果用 UML 类图画出来。
2、给工程实践项目中的应用业务领域概念分类
(1) 有哪些类？
① 用户类
② 客户类（继承自用户类）
③ 管理员类（继承自用户类）
④ 文件类
⑤ 图片类
⑥ 标签类
⑦ 工具类
(2) 各个类中有哪些属性和方法？
① 用户类：
a. 属性：用户ID，用户名，账号，密码，手机号码，其他个人信息，用户类别；
b. 方法：登录、注册；
② 客户类（继承自用户类）：
a. 属性：用户类别；
b. 方法：上传数据；
③ 管理员类（继承自用户类）：
a. 属性：用户类别；
b. 方法：数据管理，模型管理，用户信息管理；
④ 文件类：
a. 属性：文件ID，文件格式，子文件数量，子文件名表，文件种类；
b. 方法：文件遍历，统一命名；
⑤ 图片类：
a. 属性：图片ID；
b. 方法：格式转换，尺寸归一化，数据增强，数据扩充；
⑥ 标签类：
a. 属性：标签ID；
b. 方法：生成字典，编码，解码；
⑦ 工具类：
a. 属性：工具ID，工具名称
b. 方法：检测，定位，纠错，测试工具；
(3) 类之间的关系？
- 客户类与管理员类都与文件类有关联关系；
- 标签类，图片类与文件类是聚合关系；
- 管理员类和客户类继承自用户类；
- 工具类和文件类有关联关系；
3、画出业务类图
- 根据上述分析，得到项目的类图：
（三）数据建模
根据上述的用例建模和业务领域建模，可以得到各个类的数据模型：
- 用户
| 序号 | 字段 | 字段类型 | 字段描述 | 备注 |
| 1 | user_ID | String | 用户ID | 主键、自增 |
| 2 | user_name | String | 用户名 | |
| 3 | account_num | String | 账号 | |
| 4 | password | String | 密码 | |
| 5 | phone_num | String | 电话号码 | 要求11位 |
| 6 | others | String | 其他信息 | |
| 7 | user_class | int | 用户类别 | 两类：客户和管理员 |
- 客户
| 序号 | 字段 | 字段类型 | 字段描述 | 备注 |
| 1 | user_ID | String | 用户ID | 外键 |
| 2 | user_class | int | 用户类别 |
- 管理员
| 序号 | 字段 | 字段类型 | 字段描述 | 备注 |
| 1 | user_ID | String | 用户ID | 外键 |
| 2 | user_class | int | 用户类别 |
- 文件类
| 序号 | 字段 | 字段类型 | 字段描述 | 备注 |
| 1 | file_ID | String | 文件ID | 主键、自增 |
| 2 | file_format | String | 文件格式 | |
| 3 | subfile_num | String | 子文件数目 | |
| 4 | subfile_name_list | List | 子文件名列表 | |
| 5 | file_class | int | 文件类别 | 分为图片和标签 |
- 图片类
| 序号 | 字段 | 字段类型 | 字段描述 | 备注 |
| 1 | pic_ID | String | 图片ID | 指一批图片而不是一张；主键、自增 |
- 标签类
| 序号 | 字段 | 字段类型 | 字段描述 | 备注 |
| 1 | label_ID | String | 标签ID | 是与上述图片对应的一批标签；主键、自增 |
- 工具类
| 序号 | 字段 | 字段类型 | 字段描述 | 备注 |
| 1 | tool_ID | String | 工具ID | 为不同的用户打开不同的功能权限 |
| 2 | user_ID | String | 用户ID | 外键 |
（四）总结概念原型
1、什么是概念？
概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。
2、什么是概念原型？
概念原型是一种虚拟的、理想化的软件产品形式。
3、工程实践项目中的概念原型工作过程：
根据上面的用例建模和数据建模可以从两方面总结系统的概念原型：
(1) 从客户角度：客户在系统首页登录系统，进入主界面后可以上传本地的一批中文手写图像，点击识别按钮后，系统会自动转换这批图片的格式、尺寸，即数据预处理，然后使用文本行检测模型对文本行进行定位，最后对这些图片进行识别。识别完成后会在界面上向客户展示识别结果，客户可以依次遍历每一张中文手写图片的识别结果，还可以点击纠错按钮看到本张图片中识别效果不好的一些文本行，再进行手动纠错。
(2) 从管理员角度：管理员可以登录系统进入后台管理页面，可以在页面中更换优化后的检测或识别模型，也可以管理客户的信息，对客户信息进行增删改查操作。
（五）总结与展望
其实在上述的分析中有一些内容并不是我们小组工程实践要做的内容，我们的主要精力集中在文本行的检测和识别上。但我觉得研究模型 ，然后用模型去解决问题的课题很难用软件工程的方法去需求分析，所以我自己构想了一些用例、功能模块、类加入到项目中，形成了一个我认为还算完整的项目，然后对这个项目分别进行了用例建模、业务领域建模、数据建模，最终形成概念原型。在做需求分析的整个过程中，我觉得我对项目的理解更加深刻、完善了，也认识到做好需求分析的重要性是贯穿整个项目的开发过程的。当然，对于本项目的需求分析我做的并不完善，还需要在今后的学习实践不断提高自己的分析建模能力。
浙公网安备 33010602011771号