产品流程管理系统概要设计说明书

自主学习平台

概要设计说明书

编写：日期：2014/2/28 检查：日期：

审核：日期：

批准：日期：

文档变更记录

目录

1.引言 (1)

1.1编写目的和范围 (1)

2.系统框架 (1)

3.系统结构 (1)

4.功能描述 (4)

4.1用户管理模块 (4)

4.2产品要素管理模块 (5)

4.3流程管理模块 (7)

4.4产品状态管理 (10)

4.5单据管理模块 (10)

4.6产品的追溯 (12)

5.技术要求 (12)

5.1开发技术要求 (12)

5.2服务器要求 (13)

6.开发周期 (14)

7.阶段文档 (14)

8.项目沟通 (14)

1.引言

1.1编写目的和范围

说明程序模块的设计考虑。为软件编程和系统维护提供基础。本说明书的预期读者是系统设计人员、软件开发人员和项目评审人员。

2.系统框架

1、本系统是独立运行的。

本次开放系统是标签从无到有的过程，标签存在之后的处理是在现有的

系统中完成。

举例：农产品：在一块地上进行从：播种、施肥。。。包装到赋码这个过程是从无到有的过程。之后的流程是现有系统负责的

2、现有系统会去本次开放的系统中主动获取数据

3.系统结构

图3-1是产品生产流程管理系统的功能结构图。本系统从功能上分为用户管理、生产要素管理、流程管理、单据管理、产品状态管理、产品追溯和终端采集七大主要功能。实现了一套具有高普适性、高安全性、易操作、信息资源丰富的实时化产品生产流程管理系统。

系统应用功能结构图

图3-1

图3-2为本系统的基本流程图，包括的了各级用户从登陆系统开始，直到退出系统的基本操作流程，其中人事管理员1为总公司管理员，人事管理员2为分公司管理员，分公司管理员账号由总公司给予分配，员工账号由分公司人事管理员申请并由总公司人事管理员审核后，方可使用。操作人员的操作中需要单据的操作如入库、装箱等，不需要单据的操作如浇水、松土等。本流程中的生产要素定义与修改详见4.2；生产节点/生产流程/单据模板定义与修改详见4.3；单据下达流程详见4.5。

图3-2

4.功能描述

4.1用户管理模块

根据7大管理权限和3大查询权限，所有用户被分为了4个级别：

1.XXX

2.XXX

3.XXX

4.XXX。本模块主要用于系统各级用户的相关管理。主要

的实现了用户注册管理，用户信息管理，用户登录/登出和密码修改、找回等工作。

4.1.1权限定义

管理权限：

①提交用户注册申请。

②审批用户注册申请。

③用户信息修改权限（用户删除、密码重置、权限修改）。

④生产相关信息定义（生产要素定义，生产节点定义、组织流程定义、

相关单据定义）及修改。

⑤生产相关信息定义与修改的审批。

⑥生产要素信息的录入。

⑦终端生产信息的采集上传。

查询权限：

①产品状态查询。

②单据查询。

③溯源查询。

4.1.2各等级用户权限分配

一级用户：

二级用户：

三级用户：

四级用户：

4.1.3用户注册

不接受员工以个人名义单独申请，由某个部门经理统一申请，提交申请表时注明申请部门，用户等级，数量，申请理由及信息反馈邮箱。

审核人员在受理申请后将结果返回到申请人邮箱。若接受申请则返回各

级用户的用户名、密码，若拒绝则注明拒绝理由。

4.1.4用户管理

管理人员有权对用户信息做出修改（用户废除、账户密重置、用户权限变更，用户部门调整）。

4.1.5用户登录/登出、密码修改：

申请得到的用户名、密码即可自由登录/登出系统、修改密码，可在系统内进行权限允许的相关操作与查询。

4.1.6密码找回

由账户申请人（部门经理）提交密码重置申请，核对申请邮箱后将重置后密码发往目标邮箱。

4.1.7

4.1.8

4.1.9

4.2产品要素管理模块

图4-2

图4-2是本模块的功能结构图，本模块主要负责定义用于监控生产流程的各项元素，即生产要素。并进一步细化要素类型，为后期的信息采集工作提供预设的门类。以及对已定义要素的相关管理。

4.2.1生产要素添加

向系统中添加生产过程中的生产要素。主要包括生产要素（如：地块、种子、农药、肥料）和需要监管的生产影响因素（虫害）。

4.2.2生产要素门类预设

为每一个定义好的生产要素做进一步细化，预设其门类（如生产要素“地块”门类：1号地块，2号地块……生产要素“种子”门类：西瓜种子，白菜种子……）。

生产要素门类的预设为最后的信息采集提供了依据，操作人员在要素中勾选了对应的门类后，将相关信息上传。（如播种环节，操作人员勾选一号地，西瓜种子后，扫描种子包装上的条码后将数据上传）。

4.2.3生产要素维护

主要任务是对已添加生产要素进行删除、修改和查询等相关管理操作。

删除：当因为某些原因（生产工艺的改进，监管目标的变更）需要删除已定义好的生产要素时候，需要用到生产要素删除功能。

修改：当对生产要素的门类发生变化时（如公司要新种植一种农作物，需要在生产要素种子的门类中做相应的修改，添加该作物的种子）

需要对生产要素中已定义好的门类进行相关的修改。

查询：查询已定义好的生产要素和要素资门类，便于管理者从宏观上把握所采集信息的大体情况。

4.2.4

4.2.5

4.2.6

4.3流程管理模块

图4-3

图4-3是本模块的功能结构图，本模块主要通过定义生产过程中的各个操作环节（即节点）和节点的相关属性来构建一套完整的生产流程。

并为每个需要通过下命令单（如：生产任务单）来控制生产的节点定义

命令单的统一格式。

4.3.1生产节点添加

为生产流程中的各个操作步骤添加节点（如：播种、施肥、浇水、打药、采摘、装箱），并为节点添加唯一的节点ID。

4.3.2节点属性添加

为每个操作节点分配需要进行数据监视的节点属性（如播种节点的：种子种类、播种数量、播种地块、播种时间、操作人员等）。这些属性中有些是经过生产要素定义，可在要素相应的门类中勾选（如种子种类，播种地块），有些是无法在事先分门别类的定义好的（比如播种时间）。那么在节点添加时对于无法勾选，需要输入的信息应尽量少，输入也尽量简单（以数字为主）。

其中有两个固定属性，是每个节点都固有的：

①命令需要类型“是/否”。

②上下步骤节点ID。

以下具体对两种固有属性作进一步的解释：

①命令需要类型“是/否”：

决定该节点的操作是否需要上级命令的支配。对于“是”类型的节点，任何一次对于节点的操作都需要严格遵循命令的支配，对于“否”类型的节点，操作人员对于节点的操作有自由支配的权利，上级“只求结果不求过程”，即上级只要求操作人员在完成操作后上传操作结果即可。例如：对于农产品生产过程，播种为“是”类型的节点，上级决定什么时候播种，播什么种，播多少种。而后的浇水、施肥、除草等操作就是“否”类型的节点，上级不干预操作的执行，只要求操作员在每操作后将操作的情况上传即可。

②上下步骤节点ID：

用于定义某节点上一步和下一步的操作节点的ID，用一个类链表的形式方便而后的流程组织定义。

4.3.3生产节点维护

该功能用于在生产流程中某些节点或者节点属性发生改变时，对已

经定义好的节点进行相关的管理，完成节点的重命名，属性变更或删除等操作。

4.3.4生产流程定义

将已经定义好的生产节点进行排序组合，使得各个步骤串联成为一套能代表真实生产情况的流程。流程的定义实际上就是对节点的上下步骤ID属性进行填充的过程。完成了流程定义也就意味着每个节点都具有了上下步骤ID属性。

4.3.5生产流程维护

该功能用于在生产流程发生改变时，对已经组合好的流程图进行相关的管理，完成流程的重新组合，属性变更或删除等操作。

4.3.6节点单据添加

生产中比较重要的环节是需要上级部门通过命令单的模式进行下单监管的，而不是由操作人员决定是否进行该步骤操作（即命令需要类型属性为“是”的节点）。那么该功能就是为每个命令需要类型为“是”的节点定义命令单模板，实现单据与节点的一一对应关系。以规定这张命令单需要填写的条目。

4.3.7单据条目添加

为每张定义好的单据添加单据条目，即填单是需要具体填写的内容（如：下单人员，操作人员，下单时间等）。在管理人员下单的时候，只需调出模板，按需填写相关条目，进行下单即可。

4.3.8单据模板维护

该功能用于对已经定义好的节点单据进行管理。在生产流程中某些节点的命令需要类型发生改变，从“是”变为“否”时，对单据进行删除操作，或是对已定义好的节点更名、修改其中的条目等管理操作。

4.3.9

4.3.10

4.3.11

4.3.12

4.3.13

4.4产品状态管理

按照流程点查询列表（农产品）

检索出一定时间范围内，某个流程节点的状态

每个点数据直接采集上传到服务端

4.5单据管理模块

图4-5-1

图4-5-1是本模块的功能结构图，本模块用于产品生产时的管理调控。主要的管理模式是基于对各节点进行下命令单的方式来进行的。各节点对应的命令单的模板已在节点定义模块中进行了定义，管理人员在针对某一节点进行命令单下达时只需要填写相应条目后直接进行下单操作即可。为了便于管理单据，对单据的状态做了一定分类：单据已下达、单据已完成。

图4-5-2

图4-5-2是本模块的基本流程图，表明了生产流程中单据从填写到下达的操作过程。

4.5.1单据填写

选择需要管理的节点后，调出相应的命令单模板，填写相关命令信息（如：下单人员，操作人员，下单时间等）。

4.5.2单据下达

通过选择命令单接受单位，进行单据的下达，若所选与单据自身接收部门不一致则给出提示信息。成功下单后，单据状态为：单据已下达。

4.5.3单据完成

现对已经接受到操作人员完成命令信息返还的单据进行单据完成的状态标记，并将完成的单据分类储存。便于日后的查阅。

4.5.4单据查询

对已完成的单据或是已下达未完成的单据按需求进行有目的查阅。（如查阅某段时间内某生产节点完成的所有单据）。

4.5.5

4.5.6

4.5.7

4.5.8

4.5.9

4.5.10

4.6产品的追溯

系统的产品数据通过某个标识ID管理起来的，这里通过这个ID能查询出该产品在系统内存储的溯源信息。

5.技术要求

5.1开发技术要求

Java/Tomcat/Mysql/Android

1、画面不用富客户端技术

2、不用存储过程

3、数据库数据删除不用delete

4、Log处理

5、采集终端，Android手机采集，WEB端可以录入

5.2 服务器要求

数据提取服务器是产品流程管理系统和其它系统的通信接口。它们之间通过TCP/IP 协议建立通信连接。该服务器相对独立，在物理上分割了产品管理系统和其它系统。

该服务器可以理解为产品流程管理系统的数据服务前置，与其它系统之间需要频繁的通讯，需要承担来自其它系统频繁IO 访问的压力。

一、

系统结构图

如图所示，最上层是产品流程管理系统，考虑到系统的独立性和数据的安全性，系统数据中心是不对外开放的，其它系统只能通过数据提取服务器获取产品流程管理系统的业务数据。

二、

性能要求

1.异步架构服务器，实现请求应答模式即可；

2.要求多线程并发处理

3.服务器连接响应时间控制在30毫秒以内

4.服务器处理响应时间控制在百毫秒级别

5.服务器要求有自动修复功能

6.开发周期

2个月（2014/03~2014/04）

7.阶段文档

1、设计文档（软件设计文档、数据库设计文档）

2、进度管理表

3、测试计划

4、测试报告

5、编码规范

8.项目沟通

1、指定沟通窗口进行沟通

2、每周会议（报告项目进展情况）

组内先开会、整理会议记录发往北京，武汉北京进行会议沟通