GMS气体管理系统需求.docx

GMS气体管理系统需求.docx

《GMS气体管理系统需求.docx》由会员分享，可在线阅读，更多相关《GMS气体管理系统需求.docx（22页珍藏版）》请在冰点文库上搜索。

GMS气体管理系统需求

GMS气体管理系统

系统需求

调控中心

二零一四年六月

1、编写目的

本文档将全面仔细的描述GMS气体管理系统需求分析说明和数据要求说明。

本文档是GMS气体管理系统开发工作的依据，也是用户将来检验GMS气体管理系统的是否达标的依据。

1.2背景

〔1〕随着公司场站及线路投产数量的大幅增加，公司调控中心及市场部有关方案、销售、结算等类型数据处理工作量大，开发GMS气体管理系统有助于帮助优化数据处理流程，通过层层审核把关，杜绝气量统计过程中的人为失误，提高工作效率。

〔2〕GMS气体管理系统的根本用户：

省天然气开展XX调度中心，场站及市场部。

2系统需求说明

2.1目标

GMS气体管理系统的开发是为了完成以下目标：

1.由原来手工处理，传输数据改为通过计算机通讯处理，传输数据，以提高工作效率。

2.通过气体计量需求的制定更科学的对各场站以及管线的输气进展管理。

3.由原来文件式的存储数据方式，改为后台数据库的存储方式。

增加了数据的平安性的同时，省去业务人员手工整理表格的繁琐操作。

4.通过全面的报表和图形功能，让业务人员更科学和实时的了解各个场站以及管线的输气供气情况。

5.将原来手工上报审批输气量的方式改为网上申报审核的方式，申报、批准信息及时反应至调度界面。

其中场站进展初步审核，对原始数据的准确性负责，调控中心对于场站产生的各类数据进展管理，场站原始数据的修改必须通过调控中心。

6.能够同时录入场站的温度、压力、流量等各种具体生产信息，并能够通过计算算出线路及管线的输气特点，给出输气建议，并可以根据调控中心及市场部对于数据的不同要求，自定义生成各类报表。

7.系统具备web发布功能，访问采用C/S或B/S方式，下游用户可以通过权限管理登陆气量申报界面。

8.系统必须有相应的平安特性，通讯组网需要考虑未来生产系统web的需求。

9.系统硬件架构要有冗余特性，采用虚拟IP、心跳帧等技术完成数据的热备功能。

2.2用户与角色

〔1〕系统管理员：

管理系统用户、角色与权限，保证系统正常运行。

〔2〕场站工作人员：

申报本场站每日的气体计量方案；

录入本场站每日的气体实际交接量；

录入本场站的气体压力、温度等生产数据；

维护场站各类设备配置项；

查询本场站的供气输气情况。

〔3〕市场部人员：

审核场站的气体计量方案；

对管线可调配的气量进展分配。

〔4〕调度中心工作人员：

查询输气过程中各类重要参数，智能监控输气的各个环节。

通过自定义报表以及图形功能，根据自身需要实时查询任一时间段一个站或多个站的输气情况。

根据实际需要选择相应参数型各类报表以及图形并打印；

维护各个场站，管线以及下游渠道的信息。

2.3系统功能划分

GMS气体管理系统将才用BS架构,分为气量管理，设备管理，数据管理，场站管理，管线管理，系统管理6大功能模块，每个模块中又有相应实现其功能的子模块〔如下列图所示〕。

3功能需求规定

3.1系统总用例图

系统总用例图如下所示，参与者包括调度中心，市场部以及场站〔系统管理员由调度中心人员担任〕。

3.2系统管理模块

3.2.1系统管理模块用例图

3.2.2参与者

该模块的参与者为系统管理员、其他用户。

3.2.3功能描述

1．用户管理：

〔1〕添加用户：

系统管理员负责添加用户，在界面输入用户信息和密码后提交，如果无重复用户名那么成功提交。

〔2〕删除用户：

系统管理员负责删除用户，再系统提示确认后，完成提交操作，删除用户成功。

〔3〕修改用户权限：

系统管理员负责修改用户权限，可以将对用户现有的角色进展添加和删除。

〔4〕修改用户属性：

系统管理员负责修改用户属性，可以修改用户部门，职务等属性。

〔5〕修改密码：

系统管理员可以修改任一用户密码。

普通用户在输入自己原密码后，可以修改自身密码。

2.角色管理：

（1）添加角色

系统管理员负责添加系统角色，每个角色可对应一个或多个功能模块。

（2）删除角色

系统管理员负责删除角色，再系统提示确认后，完成操作。

（3）修改角色

系统管理员负责修改角色，可以对每个角色所能覆盖的功能进展添加或者删除。

3.3气量管理模块

3.3.1数据管理模块用例图

3.3.2参与者

该模块参与者为场站与市场部人员。

3.3.3功能描述

1.查询数据

场站人员可以使用此功能查询该场站的力量，温度，压力等数据。

2.录入气量数据

场站人员使用此功能录入场站的各类凭证，方案气量，交接气量等数据。

3.确认气量方案

市场部人员在场站人员提交了该场站当天的气量方案后，使用此功能进展气量方案确实认，如果对气量数据有疑问，可以退回到场站人员重新录入提交。

4.管道存量分配

该功能可以通过系统对于线路能够根据线路的实际运行情况，计算出相应的管道存储气量，能够调节的气量，并给出相应的调节区间，此数据提供应市场部的界面中，由市场部进展气量统计分配。

3.4场站管理模块

3.4.1场站管理模块用例图

3.4.2参与者

该模块的参与者为系统管理员与一般用户。

3.4.3功能描述

1.查询场站：

该功能所有用户均可使用，可以在页面中查询到天然气公司所有场站信息，包括场站的上游接气渠道信息，下游供气渠道信息，以及场站的位置，设立时间等其他属性。

2.添加场站：

由系统管理员负责添加场站，添加场站时除添加场站的名称，地点，设立时间等属性时，还需要可以对上游进气以及下游输气的渠道进展关联。

5.修改场站：

由系统管理员负责修改场站，除可以修改场站的根本属性外，还可以修改场

站上游接气以及下游送气的渠道。

6.删除场站：

由系统管理员负责删除场站，删除场站前系统会提示需要解除与上下游管线以及供气商的关联关系。

系统确认被删除场站已经无上下游关联关系后，成功完成删除操作

7.下游用户管理

（1）添加下游用户：

由系统管理员负责添加下游用户，在界面上完成属性填写后提交,系统判断是否已有该供气商,判定为新供气商那么完成添加操作。

并且需要与上游场站关联。

（2）修改下游用户：

由系统管理员负责修改下游用户，可以修改其属性以及关联场站。

（3）删除下游用户：

由系统管理员负责删除下游用户，点击删除按钮后，系统提示需确认，确认后完成删除下游用户操作，并同时删除与上游场站关联。

3.5管线管理模块

3.5.1用例图

3.5.2参与者

该模块的参与者为系统管理员与一般用户

3.5.3功能描述

1.查询管线

系统管理员与一般用户均可使用查询管线功能，在该功能界面中可以查询到公司各个管线的具体信息以及各个管线的上下游关系。

2.添加管线

系统管理员以及授权用户负责添加管线功能，在完成管线根本信息提交并填写后，系统转跳到添加管线上下游关系页面〔如果此时上下游渠道信息还未建立可以跳过此步骤〕，完成与上下游关系关联后，操作完成。

3.修改管线

系统管理员以及授权用户负责修改管线功能，可以对管线的属性以及上下游关联关系进展修改。

4.删除管线

系统管理员以及授权用户负责删除管线功能，在完成确认删除操作后，可成功删除管线，并同时删除该管线的上下游关联关系。

5.上下游渠道管理

（1）添加渠道

系统管理员以及授权用户负责此功能，该功能可以添加管线的上下游渠道信息，并且与管线关联。

（2）修改渠道

系统管理员以及授权用户负责此功能，该功能可以对管线的上下游渠道属性以及关联关系进展修改。

（3）删除渠道

系统管理员以及授权用户负责此功能，删除渠道后被删除渠道的上下游关联关系也将被删除。

3.6设备管理模块

3.6.1用例图

3.6.2参与者

该模块的参与者为系统管理员〔或者系统管理员授权用户〕以及一般用户

3.6.3功能描述

1.查询设备

该功能所有用户可使用，该功能可以查询天然气公司各个场站的所有设备的属性以及关联关系。

2.添加设备模板

该功能系统管理员以及授权用户可使用，可以同坐制作模板的方式实现添加一种新类型的设备。

3.修改设备模板

该功能系统管理员以及授权用户可使用，可以对已有的设备模板进展修改，比方修改设备属性名称，修改设备属性单位，增加设备属性等。

4.删除设备模板

该功能系统管理员以及授权用户可使用，可以删除现有的设备模板，删除模板后也会把属于该模板的设备全部删除。

5.添加设备

该功能系统管理员以及授权用户可使用，可以在现有设备模板的根底上添加新的设备。

同时该设备可以关联到具体的管线以及场站。

6.修改设备

该功能系统管理员以及授权用户可使用，可以对已录入设备的属性进展修改。

7.删除设备

该功能系统管理员以及授权用户可使用，可以对已录入设备进展删除。

在系统提示确认并按下确认按钮后，完成删除操作。

3.7数据管理模块

3.7.1用例图

3.7.2参与者

该模块的参与者为普通用户

3.7.3功能描述

1.查询数据

所有用户都可以使用此功能，可以通过改变查询条件查询任一时间段，一个或多个场站，一条或多条管线的气量，温度，压力等数据。

2.自定义报表

所有用户都可以使用此功能，可以通过改变查询条件生成任一时间段，一个或多个场站，一条或多条管线的气量，温度，压力等数据报表，并提供打印功能。

3.自定义图形

所有用户都可以使用此功能，，可以通过改变查询条件生成任一时间段，一个或多个场站，一条或多条管线的气量，温度，压力等数据折线图，饼状图，并提供打印功能。

4.非功能需求规定

4.1系统部署需求

4.1.1系统部署架构

1.前端代理效劳器

设置两台台代理效劳器，用于接收请求并做负载均衡处理。

技术上适使用keepalived和haproxy两款软件。

Keepalived的作用是检测web效劳器的状态，如果有一台web效劳器死机，或工作出现故障，Keepalived将检测到，并将有故障的web效劳器从系统中剔除，当web效劳器工作正常后Keepalived自动将web效劳器参加到效劳器群中，这些工作全部自动完成，不需要人工干预，需要人工做的只是修复故障的web效劳器。

HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。

。

HAProxy运行在当前的硬件上，可以支持数以万计的并发连接。

并且它的运行模式使得它可以很简单平安的整合进当前的架构中，同时可以保护web效劳器不被暴露到网络上。

利用Haproxy对多台WEB效劳器进展负债，再利用keepalived对Haproxy进展监控，从而使系统具有高可用的负债均衡功能，将请求均衡的分配到后台WEB效劳器的同时，通过对故障WEB效劳器的剔除保证系统的可用性。

2．WEB效劳器

GMS气体管理系统拟使用两台WEB效劳器，中间件容器为轻量级的应用效劳器apachetomcat7.x。

通过前端的haproxy分发请求后，做出响应。

2.数据库

GMS气体管理系统拟使用两台数据库效劳器，数据库软件拟使用关系型数据库软件MySql。

MySQL的高可用，由一对互为主从的MySQL效劳器组成，平时只有主库提供效劳，备库不提供效劳。

当主库停顿效劳时，效劳自动切换到备库。

主备库通过双向复制，保证数据一致性。

主备库以VIP对外统一效劳接口。

MySQL对外效劳接口的VIP，由Keepalived来实现心跳检查和动态漂移。

因此MySQL和Keepalived部署在同一台效劳器上.

4.1.2系统硬件需求

1.代理效劳器

CPU核数：

2个

存：

8G

磁盘容量：

100G

指令集：

X86

操作系统：

Linux

2.WEB效劳器

CPU核数：

4个

存：

8G

磁盘容量：

200G

指令集：

X86

操作系统:

Linux

3.数据库效劳器

CPU核数：

4个

存：

8G

磁盘容量：

500G

指令集：

X86

操作系统:

Linux

4.1.2系统开发框架

系统开发采用MVC框架，即模型〔Model〕、视图〔View〕和控制器〔Controller〕。

页面局部使用JSP动态网页技术标准，CSS框架使用基于JQuery框架开发的Bootstrap。

JavaScript使用JQuery。

后台使用轻量级的控制反转〔IOC〕和面向切面〔AOP〕的容器框架Spring，以及基于SQL映射支持Java和·NET的持久层框架ibtais。

4.1.3系统开发工具

GMS气体管理系统的集成开发环境拟使用Eclipse。

JDK版本拟采用jrockit1.6。

4.2系统可靠性

4.2.1web层可靠性

WEB层通过前置keepalived+haproxy代理效劳器的方式实现高可靠性，并且可以通过增加WEB效劳器的方式提高WEB层面的可用性。

用户请求到经过DNS效劳器解析到VIP后，将请求分发到Haproxy1效劳器，Haproxy将请求通过轮询的方式将请求均衡的分发给后端两台WEB效劳器。

如果KeepAlive检测到HaproxyMaster无法访问，那么将VIP漂移到HaProxy2效劳器，此时HaProxy2负责分发用户请求道后端两台WEB效劳器。

4.2.2数据库层可靠性

数据库层通过一组互为主从关系的MySql效劳器实现高可用性。

如下列图所示，

KeepAlived分别安装在两台DB主机上，共用一个VIP，默认以DB1为主效劳器，此时请求会分发到主效劳器DB1，如果keepAlive检测到DB1出现问题，那么VIP漂移到从效劳器DB2上，此时请求分发到DB2效劳器上。

数据库的数据一致性由MySql配置主从同步实现。

4.3系统可扩展性

4.3.1系统功能的可扩展性

GMS拟采用插件式系统架构设计，任何一个系统功能模块都用插件的方式进展开发，提高通用功能模块的的重用性。

各个功能进展独立开发，相互之间不存在依赖性，使每个单独的功能都能够单独运行。

需要对功能进展扩展时，直接在架构中开发新的功能模块即可。

4.3.2处理请求能力的可扩展性

1.WEB层

GMS采用HAPROXY+KEEPALIVED的模式实现负载均衡以及系统HA，需要扩展WEB端处理能力时，只需要增加部署WEB效劳器，然后配置HAPROXY以及KEEPALIVED，使其参加集群即可。

2.数据库层

GMS采用的是KEEPALIVED+MYSQL主从模式的数据库HA架构。

可以将主从模式调整为多主模式对数据库层面的性能进展扩展，具体架构如下列图所示。

一台MySQLMaster负责处理写请求，通过异步的方式将写入的数据同步到其他负责处理读请求的MySQLSlave效劳器。

4.4系统平安性

4.4.1程序设计平安性

〔1〕在后台代码中必须验证输入信息平安后，才能向效劳层提交由用户输入产生的操作。

可以防止嵌入到查询字符串、表单字段、cookie和HTTP头中的恶意字符串的攻击。

这些攻击包括命令执行、跨站点脚本（XSS）、SQL注入和缓冲区溢出攻击。

〔2〕程序设计中，用户身份信息必须由效劳器部的会话系统提供，防止通过表单提交和页面参数的形式获取用户身份。

〔3〕在访问XX数据或受限数据时，根据用户身份和相应的权限配置来判断操作是否允许。

防止非法用户访问XX数据或受限数据、篡改数据以及执行XX的操作。

〔4〕程序设计中，对改变系统状态的操作，记录下详细的操作信息，使操作记录可溯源。

以便在发现入侵或其他非法现象时有迹可查。

4.4.2程序部署及操作系统平安性

〔1〕在系统部署前，安装全部的平安升级补丁，关闭了所有不需要的系统效劳，只对外开放必须的端口。

〔2〕通过定期查看所部署效劳器系统平安通告，及时安装平安补丁。

〔3〕通过定期检查系统日志，对可疑操作进展分析汇报。

〔4〕应用效劳器程序建立的操作系统用户来运行，不使用ROOT运行。

4.4.3数据库平安性

〔1〕只对需要访问的网络地址进展监听

〔2〕定期数据库备份制度。

定期对数据库中数据进展全量备份。

〔3〕数据库操作授权限制，对表一级及其以上级别的数据库操作授权不对应用效劳器开放。

4.4.4网络平安性

〔1〕GMS系统前端设置企业级防火墙。

〔2〕根据具体网络环境，制定周密的防火墙规那么。

4.4.5物理平安性

〔1〕效劳器部署于专业的数据机房。

〔2〕对于支持热插拔的各种接口，部署前在系统BIOS中关闭。

效劳器在运行过程中，做好各种防护措施。