基于脱机手写中文文本行检测系统的需求分析和概念原型
-
前言
本人的工程实践题目是脱机手写中文文本行检测系统，主要是对手写文本照片进行文本行的检测，输出标注的坐标，是为了方便从事文本识别的研究工作者们，让他们能够跳过文本检测的步骤，专注于对手写中文文本的识别工作，因此系统的核心功能比较单一，操作界面应该比较简介明了，让用户能尽快上手，应具有较强的数据独立性，用户数据进行隔离，让用户可以多次获取标注后的数据，不受其他用户数据干扰，对标注过程可视化，标注进度和标注效果能清晰的呈现在用户眼前。
本篇博客将基于这个工程实践选题进行用例建模和业务领域建模，以及数据建模，最终形成概念原型。
-
需求分析
首先我们看一下什么是需求分析？
需求是对用户期望的软件行为的表述；而获取需求就是需求分析师通过关注用户的期望和需要，从而获得用户期望的软件行为，然后对其进行表述的工作；最后需求分析是在获取需求的基础上进一步对软件涉及的对象或实体的状态、特征和行为进行准确描述或建模的工作。
接下来针对脱机手写中文文本行检测系统进行需求分析：
2.1 功能性需求
(1) 直观、简洁、清晰的操作界面：用户可以通过GUI界面，进行各种操作，查看标注过程。
(2) 注册登录功能：用户先注册然后登录进入系统，将每个用户的工作区进行分离，方便对用户状态和用户数据进行保存，且用户之间不受干扰。
(3) 数据管理功能：用户可以批量上传手写中文文本照片并存储到自己的个人空间，删除照片，将文本框标注文件以及标注完的照片下载到本地。
(4) 文本行检测功能：用户上传手写中文文本数据后进行文本行的检测，输出文本框标注文件以及标注完的照片。
(5) 标注过程可视化：用户可以查看标注进度，选择标注好的照片查看文本行检测的效果。
2.2 非功能性需求
(1) 浏览器兼容：系统部署在网站上，用户可能使用不同的浏览器进行访问，需要对不同浏览器进行兼容。
(2) 数据安全：系统需要对所有的数据进行安全的存储，方便各种用户对数据的操作，保证数据提取的准确性和高效性。
(3) 并发：多个用户可能同时访问网站进行数据的文本行检测，系统应该满足适当的并发需求，防止用户等待时间过长。
-
用例建模
3.1 定义
用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。
用例的三个基本要素：
- 一个用例应该由业务领域内的某个参与者（Actor）所触发。
- 用例必须能为特定的参与者完成一个特定的业务任务。
- 一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。
3.2 基本步骤
-
第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例；
-
第二步，描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
-
第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
-
第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
其中第一步到第三步是计划阶段，第四步是增量实现阶段。
3.3 实例
在了解了用例建模的四个基本步骤后，接下来对脱机手写中文文本行检测系统进行用例建模。
根据需求分析可以提取用例：
System：脱机手写中文文本行检测系统
Actor：用户
Use Cases：
UC1：注册账户；
UC2：登录系统；
UC3：管理数据；
UC4：标注文本行；
UC5：查看标注过程；
然后可以画出完整用例图为：
-
业务领域建模
4.1 定义
业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。
4.2 基本步骤
-
第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
-
第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
-
第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
-
第四步，将结果用 UML 类图画出来。
4.3 实例
在了解了业务领域建模的四个基本步骤后，接下来对脱机手写中文文本行检测系统进行业务领域建模。可以画出如下类图（为了方便后面进行关系数据建模，这里引入了关联类）：
-
-
数据模型
5.1 定义
数据模型（Data Model）是数据特征的抽象，它从抽象层次上描述了系统的静态特征、动态行为和约束条件，为数据库系统的信息表示与操作提供一个抽象的框架。数据模型所描述的内容有三部分，分别是数据结构、数据操作和数据约束 。
5.2 分类
数据发展过程中产生过三种基本的数据模型，它们是层次模型、网状模型和关系模型。层次模型的基本结构是树形结构；网状模型的基本结构是一个不加任何限制条件的无向图。关系模型为非格式化的结构，用单一的二维表的结构表示实体及实体之间的联系，关系模型是目前数据库中常用的数据模型。
5.3 实例
可以根据上面的类图画出关联数据模型：
(1)User表
列名 类型 备注 userID String 用户id username String 用户名 password String 密码 (2)Image表
列名 类型 备注 imageID String 图片id path String 图片路径 label int[] 图片文本行标注坐标 (3)Model表
列名 类型 备注 modelName String 模型名称 hyperParams String 超参数 (4)ManageData表
列名 类型 备注 userID String 用户id imageID String 图片id time String 创建时间 (5)Choose表
列名 类型 备注 userID String 用户id modelName String 模型名称 result Image 标注结果 -
概念原型
6.1 定义
概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论，而概念原型是一种虚拟的、理想化的软件产品形式。
概念原型=用例+数据模型
6.2 实例
根据前面的用例建模和数据模型分析，可以得到脱机手写中文文本行检测系统概念原型的工作流程：
用户先注册账户，登录进入系统，然后批量上传手写文本的照片，选择模型并设置模型超参数，等待系统进行文本行标注，可以查看标注进度和标注好的照片，最后可以下载标注好的照片和标注文件。
-
小结
本文通过脱机手写中文文本行检测系统这个案例，进行需求分析，用例建模，数据建模，最后形成概念原型，学习和深入理解了软件工程的一些建模和分析方法，这些方法从不同方面对项目进行分析，可以让我们更加了解项目的实际需求和工作流程，方便对醒目进行具体实现。
参考文献：
