基于签名真伪识别项目的需求分析和概念模型

Posted 2020-12-21 sly0824

基于签名真伪识别项目的需求分析和概念模型

参考文献：从需求分析到软件设计.pptx

前言

本人所参与的工程实践项目为基于深度学习，对中文手写签名进行特征提取，分析该签名是否为本人所签名。本项目偏向研究型，展示系统较工程类工程实践稍显简略，下面对项目进行相应的需求分析与概念原型等分析。

需求分析

在写本项目的需求分析之前，我们需要知道需求分析的定义是什么，即什么是需求分析。在孟老师的课件上可以找到如下定义：需求就是对用户期望的软件行为的表述；而获取需求就是需求分析师通过关注用户的期望和需要，从而获得用户期望的软件行为，然后对其进行表述的工作；最后需求分析是在获取需求的基础上进一步对软件涉及的对象或实体的状态、特征和行为进行准确描述或建模的工作。

了解了定义之后，接着就可以进行本课题的需求分析。当前，手写签名作为一个法律性的生物特征，已经被广泛用于身份的真实性和有效性的证明，平日里合同、证书、协议和单据等文书都会使用到签名。然而目前对于手写签名的检测，大都采用人为鉴别的方式，这种检测方式准确率不高且效率低下。而且手写签名作为一个后天性的生物行为特征，稳定性较差，即便同一个人连续写出的签名也不会完全相同，甚至有较大差异，并且签名也较容易被模仿。而本课题主要是针对这些问题，设计了基于深度神经网络技术的离线手写签名鉴别系统，以达到快速鉴别真伪签名的同时，能够非常准确地鉴别出随机伪造的签名，比较准确的检测出高水平伪造签名的目的。

用例建模

同样，在进行用例建模前，需要了解什么是用例。课件中给出的定义如下：用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。而在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。

用例还包含几个基本要素：

1、一个用例应该由业务领域内的某个参与者（Actor）所触发。

2、用例必须能为特定的参与者完成一个特定的业务任务。

3、一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。

在准确理解用例概念的基础上，我们可以进一步将用例划分为三个抽象层级：

1、抽象用例（Abstract use case）：只要用一个干什么、做什么或完成什么业务任务的动名词短语，就可以非常精简地指明一个用例；

2、高层用例（High level use case）：需要给用例的范围划定一个边界，也就是用例在什么时候什么地方开始，以及在什么时候什么地方结束；

3、扩展用例（Expanded use case）：需要将参与者和待开发软件系统为了完成用例所规定的业务任务的交互过程一步一步详细地描述出来，一般我们使用一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来。

将用例划分为三个抽象层级后，我们就可以知道用例建模的四个基本步骤。

第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例；

第二步，描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；

第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；

第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。（其中第一步到第三步是计划阶段，第四步是增量实现阶段。）

有了这些预备知识以后，那么本项目的用例图也就能够完成了。

用户用例图

管理员用例图

业务建模

业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。

而开发团队获取业务领域知识的过程一般如下所示：

第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；

第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；

第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。

第四步，将结果用 UML 类图画出来。

本项目的各类属性为如下所示：

用户类：

属性：用户名，账号，密码，邮箱

方法：注册、注销、图片输入

管理员类：

属性：用户名，账号，密码，邮箱

方法：管理用户信息、模型管理

图片文件类：

属性：文件名称、文件格式

方法：上传

模型类：

属性：模型版本

方法：调用、更换版本

其中用户类和管理员类是关联关系，用户类和图片文件类也是关联关系，管理员类和模型类是关联关系，而图片文件类和模型类为聚合关系。

而本项目的UML图如下所示：

数据建模

数据模型如下所示

管理员：

字段	字段描述	类型
Name	用户名	string
ID	账户	int
Password	密码	string
Email	邮箱	string

用户：

字段	字段描述	类型
Name	用户名	string
ID	账户	int
Password	密码	string
Email	邮箱	string

图片文件：

字段	字段描述	类型
Image_Name	图片名称	string
Image	图片格式	image

模型：

字段	字段描述	类型
Model_version	模型版本	float

概念模型

概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论，而概念原型是一种虚拟的、理想化的软件产品形式，就像程序=算法+数据结构一样，概念原型=用例+数据模型

而本课题的工作流程可以概括如下：

1)用户通过系统首页进行账号注册，注册成功后使用账户密码登陆系统。然后根据需求选择相应功能，按照提示输入签名图片，得到对应功能模型生成的回答。

b)管理员通过接口更换模型版本，管理用户信息。

总结

因为我的工程实践偏向于算法的研究，所以业务上较其他人的工程类工程实践要显得简单一些，但是通过这一次作业，对从需求分析到软件设计的基本建模方法有了一次较为完整的体会，为之后的软件工程开发打下了良好的基础。