手写中文签名真伪鉴别系统的需求分析与概念原型设计

手写中文签名真伪鉴别系统的需求分析与概念原型设计

一、实验目标

本实验是针对本人工程实践的选题进行需求分析与概念原型的设计，实验选题是基于深度学习神经网络与网站搭建技术设计一个网站，工程实践的主要目的是对手写中文签名图片进行真伪鉴别，以判定两个签名是否为同一个人所写。

二、需求分析

（1）需求分析的定义

在系统工程及软件工程中，需求分析指的是在创建一个新的或改变一个现存的系统或产品时，确定新系统的目的、范围、定义和功能时所要做的所有工作，其中包括考虑来自不同利益相关者的需求，确认是否冲突，在冲突的需求之间进行取舍，并针对软件需求及系统需求进行分析、记录、确认以及管理。

需求分析是软件项目或系统项目中的关键过程，关系项目的成败。理想的需求要整理成文件、可以运行、可以量测、可以测试、可以追踪、和识别到的商业的需求或机会有关，而且要有系统设计的相关设计细节。

（2）本项目的需求分析

当前，手写签名作为一个法律性的生物特征，已经被广泛用于身份的真实性和有效性的证明，平日里合同、证书、协议和单据等文书都会使用到签名。然而目前对于手写签名的检测，大都采用人为鉴别的方式，这种检测方式准确率不高且效率低下。而且手写签名作为一个后天性的生物行为特征，稳定性较差，即便同一个人连续写出的签名也不会完全相同，甚至有较大差异，并且签名也较容易被模仿。因此本课题实现一个手写签名鉴别系统，以达到快速鉴别真伪签名的同时，能够非常准确地鉴别出随机伪造的签名，比较准确的检测出高水平伪造签名的目的。

三、用例建模

（1)用例的定义

用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。业务过程则是在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动。

一个用例有三个基本要素：一个用例应该由业务领域内的某个参与者（Actor）所触发、用例必须能为特定的参与者完成一个特定的业务任务、一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。

（2）参与者的定义

用例中的参与者是业务领域内的参与者或者业务实体；参与者不是待开发软件系统的一部分，但参与者需要和待开发软件系统交互；参与者常常是人，比如客户，但也可以是一个外部的硬件或软件，甚至是待开发软件系统内部的一个组件，比如内部计时器可以触发某个业务过程；某个参与者触发某个用例为相应的参与者完成一个业务任务。

（3）用例的三个抽象层级

在准确理解用例概念的基础上，我们可以进一步将用例划分为三个抽象层级：
抽象用例（Abstract use case）。只要用一个干什么、做什么或完成什么业务任务的动名词短语，就可以非常精简地指明一个用例；
高层用例（High level use case）。需要给用例的范围划定一个边界，也就是用例在什么时候什么地方开始，以及在什么时候什么地方结束；
扩展用例（Expanded use case）。需要将参与者和待开发软件系统为了完成用例所规定的业务任务的交互过程一步一步详细地描述出来，一般我们使用一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来。

（4）用例建模基本方法

第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例；
第二步，描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
其中第一步到第三步是计划阶段，第四步是增量实现阶段。

（5）实践项目的用例建模

根据用例建模的步骤和上文的需求分析，我们可以对工程实践项目进行用例建模：

本项目中的参与者种类较为简单，主要有普通用户和系统管理员两类，普通用户主要是使用系统提供的签名真伪鉴别的功能并对个人信息、已上传的图片数据进行管理等；系统管理员使用该系统完成用户信息的管理、系统图片管理、网络模型管理等功能。

根基以上功能需求可以得到系统的抽象用例为：

参与者：普通用户

相关用例：登录、注册、修改个人信息、查询个人信息、上传图片、删除图片、查询图片、下载文件。

参与者：管理员

相关用例：登录、修改个人信息、查询个人信息、上传图片、删除图片、查询图片、添加用户信息、删除用户信息、修改用户信息、查询用户信息、查询网络模型、修改网络模型、上传文件、下载文件。

系统高层用例：

参与者：普通用户

用例名称	开始状态	结束状态
登录	用户点击登录按钮	用户成功登录系统并显示欢迎信息
注册	用户点击注册按钮	用户注册成功并跳转到系统登录页面
修改个人信息	用户点击修改信息按钮	用户信息成功修改并在页面上提示修改操作成功
查询个人信息	用户点击查询信息按钮	用户信息成功在页面上显示
上传图片	用户点击上传图片按钮	图片上传成功并在页面上显示已上传图片
删除图片	用户点击删除图片按钮	图片删除成功并在页面上提示删除操作成功
查询图片	用户点击查询图片按钮	图片查询成功并在页面上显示图片列表
下载文件	用户点击下载按钮	鉴别结果下载成功并在页面上提示下载成功

参与者：管理员

用例名称	开始状态	结束状态
登录	用户点击登录按钮	用户成功登录系统并显示欢迎信息
修改个人信息	用户点击修改信息按钮	用户信息成功修改并在页面上提示修改操作成功
查询个人信息	用户点击查询信息按钮	用户信息成功在页面上显示
上传图片	用户点击上传图片按钮	图片上传成功并在页面上显示已上传图片
删除图片	用户点击删除图片按钮	图片删除成功并在页面上提示删除操作成功
查询图片	用户点击查询图片按钮	图片查询成功并在页面上显示图片列表
添加用户信息	用户点击添加用户按钮	用户信息添加成功并在页面上提示添加操作成功
删除用户信息	用户点击删除用户按钮	用户信息删除成功并在页面上提示删除操作成功
修改用户信息	用户点击修改信息按钮	用户信息修改成功并在页面上提示修改操作成功
查询用户信息	用户点击查询用户按钮	用户信息查询成功并在页面上显示用户信息列表
查询网络模型	用户点击查询模型按钮	网络模型信息查询成功并在页面上显示模型详细信息
修改网络模型	用户点击修改模型按钮	网络模型修改成功并在页面上显示模型修改成功
上传文件	用户点击上传按钮	文件上传成功并在页面上显示文件上传成功
下载文件	用户点击下载按钮	鉴别结果下载成功并在页面上提示下载成功

系统用例图：

在以上用例图中，将系统的需求通过用例表达出来，再将联系紧密的多个用例结合为了一个功能模块，如上图中的用户信息管理模块中包含四个用例，分别实现对于用户信息的增删改查功能。

四、手写中文签名真伪鉴别系统业务类图

（1）业务领域建模的基本步骤

第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
第四步，将结果用 UML 类图画出来。

（2）业务类图

通过以上针对项目的需求分析与系统业务分析，本系统可以将各个参与实体抽象为类，主要有用户类、管理员类、图片类及模型类。

用户类：

属性：用户名、账号、用户密码、性别、联系电话、注册邮箱、注册日期

方法：登录、注册、个人信息管理、上传图片、图片信息管理、下载文件。

管理员类：

属性：用户名、账号、用户密码、性别、联系电话、注册邮箱、注册日期、管理权限

方法：登录、个人信息管理、上传图片、图片信息管理、用户信息管理、网络模型管理、文件管理。

图片类：

属性：文件名称、文件格式、上传者账号、上传日期

方法：打印图片信息、修改图片信息

模型类：

属性：输入格式、模型版本、创建时间、所属用户

方法：打印模型信息、修改模型信息

在以上四类实体中，用户类存储的是已注册在该系统上的用户基本信息，管理员类是用户类的子类，继承了用户类的属性和方法。图片类记录每一张图片的格式，文件名和上传者信息，且用户和图片之间存在一对多的联系，一位用户可以上传多张图片，而一张图片只能属于一位用户。模型类记录的是网络模型的输入格式、创建时间等基本信息。

根据类图对项目进行数据建模如下：

1.用户

序号	字段名	数据类型	描述
1	userName	String	用户名称
2	userId	String	账号
3	password	String	用户密码
4	sex	String	性别
5	phone	String	联系电话
6	email	String	注册邮箱
7	registerDate	Date	注册日期

2.管理员

序号	字段名	数据类型	描述
1	userName	String	用户名称
2	userId	String	账号
3	password	String	用户密码
4	sex	String	性别
5	phone	String	联系电话
6	email	String	注册邮箱
7	registerDate	Date	注册日期
8	privileges	String[]	管理权限

3.图片

序号	字段名	数据类型	描述
1	fileName	String	文件名称
2	fileType	String	文件格式
3	uploaderID	String	上传者账号
4	uploadTime	Time	上传时间

4.模型

序号	字段名	数据类型	描述
1	inputSize	String	输入格式
2	modelVersion	String	模型版本
3	uploadDate	Date	创建时间
4	owner	Administrator	所属用户

五、概念原型

概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论，概念原型是一种虚拟化的、理想化的软件产品形式。

概念原型=用例+数据模型

在该项目中，普通用户使用该系统进行签名真伪鉴别的概念原型工作流程可以描述为：用户登录系统，点击上传图片按钮，选择要上传的图片，等待图片上传完成。系统提示上传完成后自动完成真伪鉴别并将鉴别结果返回用户界面，用户可以点击下载按钮将检测结果保存到本地计算机上。

管理员拥有比普通用户更大的权限，可以实现对用户信息的管理。对用户信息的管理的概念原型工作流程可以描述为：当管理员登录系统后，点击用户信息管理按钮，系统将列出所有的用户信息，管理员对数据进行相应的操作后可以选择将修改后的数据保存到系统中，当管理员完成对系统信息的管理后则退出系统。

参考文献

[1] 面向对象分析与设计之用例建模

[2] 从需求分析到软件设计.pptx