东疆海事局船舶管理系统设计方案.docx
- 文档编号:12847653
- 上传时间:2023-04-22
- 格式:DOCX
- 页数:65
- 大小:2.11MB
东疆海事局船舶管理系统设计方案.docx
《东疆海事局船舶管理系统设计方案.docx》由会员分享,可在线阅读,更多相关《东疆海事局船舶管理系统设计方案.docx(65页珍藏版)》请在冰豆网上搜索。
东疆海事局船舶管理系统设计方案
东疆海事局船舶管理系统
设计方案
北京奇迹无限软件有限公司
2017年8月16日
第1章项目概述
1.1.项目背景
东疆海巡执法支队作为东疆海事局的一支精干力量,管理着全局包括:
海巡0201、海巡0202、海巡0203、海巡0204、海巡02001、海巡02002、海巡02003、海巡02009、海巡02010、海巡02011、海巡02012、海巡15013、海巡15023在内的所有船舶。
在日常的管理工作中,船舶人员的管理、船舶以及船上设备的管理、巡航任务的出勤、物资的采购发放等占据着较大的比重,涉及到大量申请单的流转审批、工作事务的记录。
传统的纸质文件在流转过程中,存在着延误、统计不方便和存档后查看不方便的问题,为了能够提高东疆海巡执法支队内部的管理能力,通过东疆海事局牵头招标,委托北京奇迹无限软件公司为东疆海巡执法支队量身定制了东疆船舶管理系统。
(1)改变管理理念,提升管理水平,促进天津海事科学发展的需要
水运经济持续发展,水上安全监管压力日益增大,水监体制改革不断深入,都对天津海事建立权责统一、运转协调、办事高效、反应迅速、保障有力的管理机制提出了更高的要求。
海事发展也由粗放型管理向精细化管理转变,更加注重发展质量和海事管理水平的提升。
通过信息整合,深化应用,不仅使内部管理业务高效运转并相互协作、信息共享,连接成一个有机整体,减轻人工劳动的强度,而且会促进传统管理理念和模式的改变,实现海事管理由“定性管理”到“定量管理”,为科学决策提供有力支撑,真正实现信息化引领海事管理科学化、现代化的目标,从而提升我局的综合竞争力,满足自身科学发展的要求。
(2)贯彻部局顶层设计,推动海事信息化升级创新的需要
“十二五”期间,为继续推进海事信息化建设,充分发挥科技信息的支撑与引领作用,解决海事信息化全局性、系统性问题,部海事局开展了海事信息化顶层设计的研究工作。
顶层设计在现有信息化基础上,以“智慧海事”为理念,充分汲取先进理论方法,结合物联网、云计算、移动外网等先进思想和技术,为海事信息化体系提出了信息系统架构模型、基础设施架构模型和海事信息化标准规范体系,全面勾画海事信息化的远程目标和发展蓝图。
政务中心实施行政审批船舶管理系统是实施智慧海事落地的一个重要举措,也是推动海事管理转变发展方式,全面提升海事系统的综合实力,加快海事监管现代化建设进程,持续提升海事发展的能力和水平,不断提高海事工作的质量和效率。
通过不断对业务流程梳理与优化过程,来加快推进天津海事系统的规范化、标准化、正规化建设,实现天津海事系统的科学发展、率先发展。
1.2.项目目标
信息化战略作为东疆海巡执法支队战略规划的一部分,通过建设东疆海巡执法支队行政审批业务船舶管理系统项目,对行政审批业务流程进行全面管理和支持,支撑东疆海巡执法支队的服务理念和业务发展,提升东疆海巡执法支队的IT竞争价值,成为东疆海巡执法支队的竞争优势。
通过融合具备高度开放性和稳定性的SOA技术架构,来构建适用于东疆海巡执法支队行政审批的信息平台,制度统一、规范的IT架构标准体系,包括数据规范、服务规范、流程规范、界面规范、接口规范等。
东疆海巡执法支队行政审批业务船舶管理系统项目的建立将严格遵循统一建设标准和服务标准,实现信息的共享共通,各业务模块的无缝集成,实现跨部门、跨系统的工作协同,为东疆海巡执法支队提供安全、可靠、便捷、灵活和经济的信息化服务平台,有效改善整体资源利用率,降低总体成本,实现行政业务审批的快速办理。
东疆海巡执法支队通过实施东疆海巡执法支队行政审批业务船舶管理系统项目,助推东疆海巡执法支队实现信息化建设的长远目标,严格遵循了东疆海巡执法支队整体规划,符合了海事局顶层设计的要求:
●实现业务流程整合和持续优化,提供完全业务流程驱动的工作模式。
●实现应用功能的整合,提供异构系统间的无障碍信息互传。
●异构数据资源的整合,提供异构系统间无障碍的数据交换和共享。
●遵循“横向融合、上下互动”的信息化治理体系。
依据国际国内标准,调研和分析东疆海巡执法支队实际,制定信息化各类标准规范,完善东疆海巡执法支队信息系统建设的规范化,建立东疆海巡执法支队自己的信息化标准规范体系,将规范和促进东疆海巡执法支队信息化建设有序、高效、快速和健康地发展。
统一的信息化标准规范为东疆海巡执法支队信息系统和各成员单位互通、互连、互操作的提供了可落地的东疆海巡执法支队信息化通用语言。
东疆海巡执法支队行政审批业务船舶管理系统项目的建设必须遵循东疆海巡执法支队信息化标准规范体系,在此前提下完善东疆海巡执法支队行政审批船舶管理系统业务功能,加强和改善系统应用范围及体验。
第2章项目建设原则
2.1.建设原则
东疆海巡执法支队行政审批业务船舶管理系统()项目是东疆海巡执法支队对外服务的平台,在建设前需要充分考虑好建设模式和建设内容,才能避免无序施工、环节重复和资源浪费,而这一切需要精深且经过深入实践的思想和方法论的指导。
东疆船舶管理系统作为东疆海巡执法支队内部综合管理的一款系统,它在建设中遵循下列原则:
●可扩展性原则
应用的开发、部署、运行、管理、连接等方面具有高度的统一性和规范性,系统要采用积木式结构。
选择开放的应用平台,分层设计,组件化实现。
硬件装备和软件平台具有可扩展性,应用系统具有二次开发能力。
●技术先进性原则
系统在设计思想、系统架构、采用技术、选用平台上均要具有一定的先进性、前瞻性和扩充性。
在满足现有需求的基础上,能够适应今后一定时期内业务的增长和变化,以保障投资的回报。
●统一原则
整个系统的建设按照需求需要分为内网系统和外网系统两个部分,数据信息需要完成高度同步,把两个系统揉合为一个整体。
●易用性原则
在满足业务功能需求的前提下,适应各业务角色的工作特点,简单、实用、人性化。
实现了个性化界面和内容定制,使操作更加人性化。
第3章项目需求分析
3.1.海巡执法支队业务分析
3.1.1.系统用户网络情况特点
系统用户多为船上的工作人员因为任务需要常常需要出海作业,出海距离较远时不能使用3G网络,而现有船舶内网部署只完成了两条船的建设,针对这一问题,在多次沟通和多方面协调后,解决方案为:
●同时部署内网、外网两套系统,分别对用户有内网或者有外网时的系统使用情况。
●两套系统通过网闸,共用一个数据库。
●使用文档同步工具将内网外上传的附件同步到一个服务器上的指定位置,实现文档将的同步。
3.1.2.人员管理业务特点
海巡执法支队日常针对用户的管理包括:
用户基本信息管理、证书管理、考勤管理、评价管理、培训管理、月度排班的管理。
在这些管理业务中主要的业务要点为:
●人员在部门、船舶间的调动,通过人员统一管理的理念,由调度人员通过船舶人员模块,对人员的信息调整来改变。
●人员考勤的管理,通过人员考勤模块用户每天做到岗、离岗登录形成人员考勤日报表和月报表,方便管理人员的统一管理。
●月度排班需要动态生成,我们通过对日历的关联自动,在用户选择年月后自动生成对应长度的表单方便录入排班信息。
3.1.3.设备管理业务特点
海巡执法支队日常针对设备的管理包括:
设备基本信息的管理、证书管理、维修申请、申请审批、工单记录、运维策略管理等。
在这些管理业务中主要的业务要点为:
●针对需要定期进行维护保养的设备,我们制定了设备维护保养策略管理,通过对设备设定好固定的设备维护保养方式、初始化设备信息后可以在设备需要维护保养时自动生成维保工单并提示用户。
●针对用户业务中设计的需要进行维保申请和维保审批的业务,我们制定了对应的流程状态控制,通过不同的状态显示给用户,方便用户识别需要办理的业务。
●大量设备的维修记录,我们通过设备与工单的关联,实现了通过设备信息能看到本设备对应的具体工单的列表,方便了管理人员和设备维护人员能够通过历史工单的查询了解设备和为后期维护提供参考。
3.1.4.物资管理业务特点
海巡执法支队日常针对物资的管理包括:
物资主数据信息的管理、采购申请、采购审批、库存管理等。
在这些管理业务中主要的业务要点为:
●针对用户业务中设计的需要进行采购申请和采购审批的业务,我们制定了对应的流程状态控制,通过不同的状态显示给用户,方便用户识别需要办理的业务。
●针对用户业务中多种类型的物资申请单,我们量身定制了五个对应的申请按钮,通过不同的按钮,我们能形成不同的采购申请单,并按照指定的流程状态去改变它在系统中的展示权限。
●对于采购回来的物资,我们通过库存管理中的出入库单据,及对应的历史查询来实现采购到的物资的跟踪管理。
3.2.船舶管理系统业务需求
船舶管理系统是一个面向服务对象和内部业务管理人员的系统,主要功能如下:
●实现远程电子申报行政审批项目,方便行政相对人通过远程申报客户端进行网上申报,减轻行政相对人的办事成本。
●通过微信及时信息将接收结果和告知信息主动推送给行政相对人,提高服务质量。
●为政务大厅一线业务受理人员服务:
实现局行政审批业务受理工作的全过程管理。
通过统一的行政审批业务受理模块完成各类行政审批事项的处理,按需生成各类行政文书;通过将分散在每个具体受理人员的业务办理经验构成具体案例库,通过对案例库数据挖掘、关联检索等技术手段形成业务受理知识库,为其他受理人员在处理同类型的业务事项提供有价值的服务支撑,提高工作效率。
●为局及政务中心领导服务:
通过该平台所提供的行政审批业务受理实时查询、多维度统计、报表中心等功能为各级领导在决策管理过程中提供强有力的数据支撑。
东疆海巡执法支队行政审批业务船舶管理系统()项目作为一期项目的扩展,需要在保障系统稳定的同时解决以下需求:
●扩大业务范围,增加各分支局业务受理审批需求。
●与其他系统集成:
获取申报人所在公司对应船舶信息、船员信息,方便业务申请需要。
●实现资料上传中“一次上传多次使用”的建设思路:
将船舶资料、公司资料整合为文档资料库,提高系统使用效率。
●完善业务辅助功能:
提高业务指南、业务须知、业务动态的实用性和用户体验。
●在微信端实现业务动态查询:
使相对人可以及时便捷的查询到指定业务的信息。
●在微信端建立问题库:
能够通过收集用户常见问题进行整理,为相对人提供除在线客服以外的又一咨询通道。
●完善系统配置功能:
使政务中心业务人员可以自行管理业务流程、组人员、业务信息配置等功能,增加系统的可维护性。
●完善系统权限控制功能:
在现在空间权限、业务权限管理的基础上,增加操作管理权限。
●增加账号管理功能:
使政务中心业务人员可以根据需要对业务相对人的账号进行管理,以免账号有问题后,维护不方便的情况出现。
此外,现有功能的优化也是东疆海巡执法支队行政审批业务船舶管理系统()项目建设的重点内容。
3.3.非功能性需求
3.3.1.性能需求
系统支持系统注册用户4000个,同时系统支持并发用户200个,并保证登陆、打开功能菜单时间不超过3秒。
3.3.2.易用性需求
只需很少地培训操作者就能使用系统和它地任何特性,系统应该被设计成与其目标使用者地业务技术水平很匹配。
当用户做一些处理时间较长的操作时,能给出提示信息提醒用户。
在返回数据量过大导致响应时间过长时,能提供部分响应,例如:
分页取数据等,减少操作人员等待的时间。
界面要简洁、清晰、柔和、美观、大方,操作简单方便。
前端界面具有统一界面风格,使系统具有统一、美观、人性化的界面,增强系统的易用性和友好性。
3.3.3.可用性需求
系统应能够连续7×24小时不间断工作。
系统前三年,每运行2000小时,累计中断时间不超过1小时;以后每运行1000小时中可用时间至少不小于999小时,故障间隔时间应大于1000小时。
故障恢复时间:
<4小时。
3.3.4.可扩展性需求
系统必须保证软件新旧版本的平稳过渡,保证主机系统,网络系统在将来能够顺利扩容,且不影响正常的生产运行。
系统需要具有对技术和业务需求变化的支持能力。
当技术变化或业务变化时,不可避免将带来系统的改变―不仅要进行设计实现的修改,甚至要进行产品定义的修改。
好的软件设计应在系统构架上考虑能以尽量少的代价适应这种变化。
开放性与标准化是一个系统赖以生存发展的基础。
只有遵循开放性和标准化的系统才具有生命力,才能保护用户的投资,才能体现良好的扩展性和互操作能力。
在设计中不仅应考虑目前业务的需求,更应充分考虑未来业务量及业务种类增长的需求,同时也要考虑与行政管理体制的配合和协调。
系统规模具有可调性,可以逐渐增大;新的软件模块即插即用,新功能、新业务的增加能够在不影响系统运行的情况下实现。
3.3.5.可伸缩性需求
系统在性能上必须能容易且有效地伸缩以满足业务需求增长地需求。
应用软件的任意模块更新加载时不影响业务运转和服务。
个别服务器或子系统的故障不影响整体系统的运行。
3.3.6.可管理性需求
系统必须能被配置、部署、监控和优化以确保其在预定地环境中工作良好。
系统应该包括数据备份、数据恢复、日志管理、垃圾数据清除等基本功能,哪怕这些功能的核心只是一条语句或命令。
用户管理功能是另一项必不可少的功能,它定义哪些用户可以以什么样的功能使用系统。
好的用户管理功能不仅可以有效控制用户对系统的使用,使系统处于一个安全、负载合理的运行状况,还能提高系统的应用适应性。
第4章项目设计
4.1.技术架构
4.1.1.总体技术架构
东疆海巡执法支队行政审批业务船舶管理系统项目是依托“智慧海事”项目建立的平台,总技术架构为:
通过服务总线(ESB)技术实现原有业务系统的接入和服务标准化,通过业务流程管理(BPM)组件实现业务流程的重新编排和管理,通过门户平台实现业务流程、决策分析信息等统一展现,实现海事对内信息系统建设的标准化与规范化。
(1)技术路线
比较各种不同的主流技术架构体系,目前国际上达成一致的观点是:
SOA是企业IT架构全面整合的最佳方法,而J2EE是企业级应用的最佳支撑平台。
因此,在东疆海巡执法支队行政审批业务船舶管理系统()项目的建设上,依旧遵循标准、开放、灵活的SOA架构方法,并采用了成熟的J2EE技术体系。
(2)技术应用
行政审批船舶管理系统项目,是一个全局性的顶层系统,需要与全局若干行政审批系统进行互联必须考虑以后业务的变化与扩展,因此系统的体系结构必须先进、稳定、易扩展,既需要安全稳健的系统平台支持,又需要面向更广阔的业务支撑和更灵活的应用集成扩展能力。
(3)J2EE架构
本系统采用J2EE架构实现应用体系结构,本系统设计采用基于J2EE的技术,完全采用MVC+DAO(Model+View+Control+DAO)应用设计模式,使得层之间相对松耦合,具有良好的扩展性和稳定性,如图所示应用设计结构图:
J2EE实现思路:
客户端:
用户通过WEB浏览器与不同应用程序交互,浏览器作为应用程序的客户可以使用JSP页面和XHTML来呈现客户页面。
应用程序控制器:
应用程序控制器是主控制器Servlet,负责初始化委派请求和响应请求处理程序。
请求处理程序:
JAVA类,通过调用相应的请求执行程序完成要求的处理,并对请求进行预处理,这种调用采用命令模式。
请求执行程序:
完成具体的请求活动,例如与服务交互。
请求执行程序依靠业务定位程序发现相应的服务,然后通过这些服务访问需要的资源信息。
业务定位程序:
这些程序负责隐藏查找服务的复杂性,并提供缓存逻辑。
业务展现接口:
通过聚合来自多个系统或服务的方法,简化复杂对象的视图。
WEB服务:
提供WEB服务端点的业务逻辑。
DAO(数据访问接口):
封装数据库异构的复杂性,使得在应用服务层面独立于数据层面。
J2EE是一个基于组件-容器模型的系统平台,其核心概念是容器。
容器是指为特定组件提供服务的一个标准化的运行时环境,Java虚拟机就是一个典型的容器。
组件是一个可以部署的程序单元,它以某种方式运行在容器中,容器封装了J2EE底层的API,为组件提供事务处理、数据访问、安全性、持久性等服务。
在J2EE中组件和组件之间并不直接访问,而是通过容器提供的协议和方法来相互调用。
组件和容器间的关系通过“协议”来定义。
容器的底层是J2EE服务器,它为容器提供J2EE中定义的各种服务和API。
一个J2EE服务器(也叫J2EE应用服务器)可以支持一种或多种容器。
每个容器的服务包括两部分:
J2SE(Java2PlatformStandardEdition)和一组扩展的服务。
这是因为J2EE是以Java标准版为基础的,各容器在J2SE之上再根据需要提供一些扩展的服务,如目录服务、事务管理、数据访问、消息机制、安全性等。
EJB是J2EE平台的核心,也是J2EE得到业界广泛关注和支持的主要原因。
我们知道,J2EE的一个主要目的就是简化企业应用系统的开发,使程序员将主要精力放在商业逻辑的开发上。
EJB正是基于这种思想的服务器端技术,它本身也是一种规范,该规范定义了一个可重用的组件框架来实现分布式的、面向对象的商业逻辑。
EJB的核心思想是将商业逻辑与底层的系统逻辑分开,使开发者只需关心商业逻辑,而由EJB容器实现目录服务、事务处理、持久性、安全性等底层系统逻辑。
企业级Java(Java2EnterpriseEdition)的示意图。
J2EE构架划分为表示层、业务层和数据层三个层次。
在表示层,支持Java应用、在浏览器中的小应用程序、Corba客户端、以及Web客户端;在业务层,通过EJBBeans来实现业务逻辑,并运行在支持EJB的应用服务器中;数据层同样支持各种数据库管理系统。
表示层和业务层之间主要通过RMI-IIOP进行通讯;业务层和数据层则通过JDBC和SQL/J进行连结。
J2EE使用的是业界的标准,而不是一个厂商的标准。
特别是对OMG的Corba标准有很好的支持。
它能够在各种不同的硬件平台和操作系统上运行。
J2EE规范里包含了多种技术,并形成一个有机的整体:
●EJB:
企业级Java组件,能够封装复杂的业务逻辑,并在整个系统范围内重用,支持远程调用和集群;
●RMI-IIOP:
远程方法调用协议,支持Java程序象调用本地对象一样调用远程对象,该协议既支持Java本身的RMI调用,也支持CORBA的IIOP协议,因而能够与CORBA服务进行互访问;
●JDBC:
提供Java程序访问数据库的标准接口;
●Servlet:
支持动态地生成html页面,用于基于浏览器的应用开发;
●JSP:
能够通过混合编写java和html脚本,动态地生成html页面,比编写Servlet的开发效率更高;
●JTA:
Java事务接口提供对事务的支持,包括分布式事务;
●JavaIDL:
允许Java对象访问外部CORBA对象;
●JMS:
Java消息服务,支持可靠的点对点、发布/订阅方式的消息传输;
●JNDI:
Java命名和目录服务,支持按照名称来查找资源;
●JavaMail:
提供在Java里面发送和接收电子邮件的支持;
●JAF:
被JavaMail用来处理MIME数据;
●JAXP:
Java处理XML文件的标准接口,支持SAX和DOMAPI;
●JCA:
允许遗留的信息系统提供出适配器接口,与J2EE应用程序进行整合;
●JAAS:
支持基于用户的认证和授权模型;
J2EE的特点在于:
支持所有的硬件和操作系统平台,使用户在操作系统和硬件的选择上具有更大的自由度;
技术规范更全面,对企业级应用的支持更强大;
具有“编写一次,到处运行”的优点;
系统的可扩展性更强,后期维护费用较低;
适合大型的系统和关键的业务;
现有标准,后有实现,标准的设计很完善;
只需要用Java一种语言,开发效率高。
(4)MVC处理模式
MVC是Model/View/Control的缩写。
Model/View/Control是软件设计的典型结构。
在这种设计结构下,一个应用被分为三个部分:
Model、View和Controller,每个部分负责不同的功能。
Model是指对业务数据/信息的处理模块,包括对业务数据的存取、加工、综合等。
;View是指用户界面,也就是面向用户的数据表示,Web的视图可以是HTML页面,也可以是图片或者其他媒体;Controller则负责View和Model之间的流程控制,也就是完成两个方向的动作:
1.将用户界面(View)的操作映射到具体的Model,以完成具体的业务逻辑;2. 将通过Model处理完的业务数据及时反应到用户界面(View)上。
具体地说,视图可以用JSP或者HTML来定义,模型可以用Java对象来定义(通常称为JavaBean),控制器可以通过Java对象的动作类来定义。
以下是MVC架构的处理流程:
MVC架构使得应用程序的结构更加清晰,通过将代码按照层次划分为业务逻辑/数据、用户界面和应用流程控制这三个层次,增强代码稳定性。
我们知道,对于Model、View、Controller这三部分功能来讲,View的实现一般是由界面设计人员和界面程序员来完成,Model则是由业务逻辑程序员来完成,Controller则一般由负责整体控制的程序员来完成。
Controller部分的代码比较稳定,一般会实现一个通用的架构;而Model则跟随商务流程的变化而变化;View的更改则是随着用户需求的更改而更改。
这种模块功能的划分有利于在代码修改过程中进行模块的隔离,而不需要把具有不同功能的代码混杂在一起造成混乱。
对于项目开发而言,有利于在项目小组内按照小组成员各自的擅长进行分工,有利于三个部分并行开发、加快项目进度。
(5)XML技术
XML即ExtensibleMarkupLanguage(可扩展标记语言)的缩写。
XML实际上是Web上表示结构化信息的一种标准文本格式,它没有复杂的语法和包罗万象的数据定义。
XML同HTML一样,都来自SGML(标准通用标记语言)。
SGML是一种在Web发明之前就早已存在的用标记来描述文档资料的通用语言。
但SGML十分庞大且难于学习和使用。
鉴于此,人们提出了HTML语言。
但近年来,随着Web应用的不断深入,HTML在需求广泛的应用中已显得捉襟见肘,有人建议直接使用SGML作为Web语言。
但SGML太庞大了,学用两难尚且不说,就是全面实现SGML的浏览器也非常困难。
于是Web标准化组织W3C建议使用一种精简的SGML版本--XML。
XML与SGML一样,是一个用来定义其他语言的元语言。
与SGML相比,XML规范不到SGML规范的1/10,简单易懂,是一门既无标签集也无语法的新一代标记语言。
系统在数据交换中采用XML技术。
(6)Struts
Struts最早是作为ApacheJakarta项目的组成部分,项目的创立者希望通过对该项目的研究,改进和提高JavaServerPages、Servlet、标签库以及面向对象的技术水准。
Struts这个名字来源于在建筑和旧式飞机中使用的支持金属架。
这个框架之所以叫"Struts",是为了提醒我们记住那些支撑我们房屋,建筑,桥梁,甚至我们踩高跷时候的基础支撑。
这也是一个解释Struts在开发Web应用程序中所扮演的角色的精彩描述。
当建立一个物理建筑时,建筑工程师使用支柱为建筑的每一层提供支持。
同样,软件工程师使用Struts为业务应用的每一层提供支持。
它的目的是为了帮助我们减少在运用MVC设计模型来开发Web应用的时间。
我们仍然需要学习和应用该架构,不过它将可以完成其中一些繁重的工作。
如果想混合使用Servlets和JSP的优点来建立可扩展的应用,Struts是一个不错的选择。
4.1.2.技术架构组成
东疆船舶管理系统项目技术架构模块图如下所示
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 海事局 船舶 管理 系统 设计方案