第三章 系统分析
3.1 系统可行性分析
可行性研究(Feasibility Study)是通过对项目的主要内容和配套条件,如市场需求、资源供应、建设规模、工艺路线、设备选型、环境影响、资金筹措、盈利能力等,从技术、经济、工程等方面进行调查研究和分析比较,并对项目建成以后可能取得的财务、经济效益及社会环境影响进行预测,从而提出该项目是否值得投资和如何进行建设的咨询意见,为项目决策提供依据的一种综合性的系统分析方法。可行性研究应具有预见性、公正性、可靠性、科学性的特点。
3.1.1 技术可行性
自从2005年5月19日,里昂推出了Velo’v公共自行车系统。公共自行车事业便在世界各地飞速发展,相应的技术及设施也日益完善。公共自行车系统中应用的相关高新技术有:机电一体化技术,实现网点终端设备对自行车“锁”、“放”的电气控制;IC卡交通管理技术,用IC卡进行用户管理,实现不同收费模式,其他卡的兼容;RFID身份识别技术,用RFID对车辆进行身份登记,RFID(无线射频技术)记录用户使用过程中的信息;计算机网络技术实现异地还车、智能计费、自助充值、交通信息发布等功能;通讯技术,采用有线或无线的通讯方式,实现网点、终端、管理后台的通讯;PM智能停车管理技术实现交通信息预警与发布,交通流诱导,交通目的引导。
3.1.2 经济可行性
城市公共自行车系统建设,解决“最后一公里问题”,极大的方便市民活;有效缓解和解决公交拥堵问题;一定程度上,促进城市节能减排,净化城市空气,优化城市环境;为下岗工人创造就业机会;间接减少了资源浪费,提高自行车使用效率;间接解决了自行车防盗治安问题。
3.1.3 操作可行性
系统建成平稳运行之后,用户可以在任何一个租车点租车还车,查询最近租车点及租车点的车辆情况,方便快捷。系统全天候运行,满足了不同人群的需求。系统日常维护对其管理员的要求不高,可以很快上手。
3.2 需求分析
所谓“需求分析”,是指对要解决的问题进行详细的分析,弄清楚问题的要求,包括需要输入什么数据,要得到什么结果,最后应输出什么。简单的说就是分析用户的要求。需求分析是系统设计的起点,需求分析的结果是否准确地反映了用户的实际要求,将直接影响到后面各个阶段的设计,并影响到设计结果是否合理和实用。
随着社会物质条件的改善,生产生活节奏的加快,人们越来越意识到时间的重要性,在工作中,生活中越来越注重如何节省时间,提高效率。而城市交通环境的拥挤让人们在路上花费了大量的时间。公共自行车以其环保、便捷的特点一出现就受到广大群众的欢迎。因为工作和生活的缘故,在必要的时候向自行车出租公司提出租赁车辆的服务要求,已成为大众广为认可和接受的行为和选择。在这种社会需求的强力带动下,自行车车租赁市场出现了前所未有的一片繁荣景象。各个自行车租赁公司门庭若市,业务激增。
在当今社会,随着计算机的发展及网络技术的应用,计算机应用在全球范围内的普及。当今社会正快速向信息化社会前进,信息自动化的作用也越来越大。而在日常生活中信息技术的不断融入,在技术越来越先进的同时,我们应该从以前繁琐的事务中解放出来 ,来提高我们的工作效率。
传统的自行车租赁基本上是靠人工进行管理,但随着时间的变化,业务规模的扩大,有关自行车租赁管理工作和所涉及到的数据量越来越大越来越多,大多数运营商不得不靠增加人力,物力,财力来进行自行车租赁管理。但是人工管理档案具有效率低,查找麻烦,可靠性不高,保密性低等因素。因此开发一个采用计算机技术对自行车租赁进行管理的系统是必要的。
本管理信息系统采用计算机网络技术和数据库技术,为用户创造一个安全、简单、新颖、便捷的租赁环境,实现自行车租赁信息管理工作流程的系统化,规范化和自动化。本套公共自行车管理信息系统开发工具选用Delphi,数据库服务器选用SQL Sever 2005数据库。具体包括基础信息管理、租车管理、还车管理、查询管理、系统管理五大管理模块。
3.3 管理业务调查
业务流程图(transaction flow diagram,简称TFD),就是用一些规定的符号及连线来表示某个具体业务处理过程。一种描述系统内各单位、人员之间业务关系、作业顺序和管理信息流向的图表,利用它可以帮助分析人员找出业务流程中的不合理流向。
本系统租车业务流程图3-1:
图 3-1 租车业务流程图
查询业务流程图如图3-2:
图 3-2查询业务流程图
还车业务流程图如图3-3:
图 3-3 还车业务流程图
管理员业务流程图如图3-4:
图 3-4管理员业务流程图
整体业务流程图如图3-5:
图3-5 整体业务流程图
3.4 数据流程调查
数据流程图是描述系统数据流程的工具,它将数据独立抽象出来,通过图形方式描述信息的来龙去脉和实际流程。数据流程图是组织中信息运动的抽象,是管理信息系统逻辑模型的主要形式。这个模型不涉及硬件、软件、数据结构与文件组织,它与系统的物理描述无关,只是用一种图形及与此相关的注释来表示系统的逻辑功能。图形描述简明,清晰,不涉及技术细节,所描述的内容是面向用户的。因此数据流图是系统分析人员与用户进行交流的有效手段,也是系统设计的主要依据之一。
为了描述复杂的软件系统的信息流向和加工,可采用分层的DFD来描述,分层DFD有顶层,中间层、底层之分。
顶层:决定系统的范围,决定输入输出数据流,它说明系统的边界,把整个系统的功能抽象为一个加工,顶层DFD只有一张。
中间层:顶层之下是若干中间层,某一中间层既是它上一层加工的分解结果,又是它下一层若干加工的抽象,即它又可进一步分解。
底层:若一张DFD的加工不能进一步分解,这张DFD就是底层的了。底层DFD的加工是由基本加工构成的,所谓基本加工是指不能再进行分解的加工。
数据流程图的系统部件包括系统的外部实体、处理过程、数据存储和系统中的数据流四个组成部分,如图3-6:
图 3-6 数据流程图的符号
3.4.1 顶层数据流
顶层数据流程图如图3-7:
图 3-7顶层数据流程图
3.4.2 一层数据流
用户一层数据流程图如图3-8:
图 3-8用户一层数据流程图
管理一层数据流程图如图3-9:
图3-9 管理员一层数据流程图
3.4.3二层数据流
租车处理二层数据流程图如图3-10:
图3-10租车处理二层数据流程图
查询处理二层数据流程图如图3-11:
图3-11 查询处理二层数据流程图
还车处理二层数据流程图如图3-12:
图3-12 还车处理二层数据流程图
3.5数据字典
数据字典(Data dictionary)是一种用户可以访问的记录数据库和应用程序元数据的目录。主动数据字典是指在对数据库或应用程序结构进行修改时,其内容可以由DBMS自动更新的数据字典。被动数据字典是指修改时必须手工更新其内容的数据字典。数据字典由数据项、数据结构、数据流、数据存储、处理过程五个部分构成。
3.5.1 数据项定义
数据项编号:I-01
数据项名称:车辆号码
别 名:车辆编号
简 述:系统所拥有的车辆代码
类型及宽度:长整型,4位
取值范围:“0001”~“9999”
数据项编号:I-02
数据项名称:用户编号
别 名:用户编码
简 述:用户在本系统的身份代码
类型及宽度:长整型,4位
取值范围:“0000”~“9999”
数据项编号:I-03
数据项名称:管理员姓名
别 名:管理员姓名
简 述:管理员信息的代码
类型及宽度:字符型,20位
取值范围:文本
数据项编号:I-04
数据项名称:管理员性别
别 名:管理员性别
简 述:管理员信息的代码
类型及宽度:字符型,20位
取值范围:男,女
数据项编号:I-05
数据项名称:管理员电话
别 名:管理员电话
简 述:管理员信息的代码
类型及宽度:字符型,20位
取值范围: “00000000001”~“99999999999”
3.5.2 数据流描述
数据流编号:D-01
数据流名称:注册信息
简述:用户注册时填写的内容
数据流来源:用户
数据流去向:租赁管理模块
数据项组成:用户姓名+性别+年龄+用户名+用户密码+身份证号码
数据流量:50份/日
高峰流量:100份/日
数据流编号:D-02
数据流名称:登入信息
简述:用户的登入信息表
数据流来源:用户
数据流去向:租赁管理模块
数据项组成:用户姓名+性别+年龄+用户名+用户密码+身份证号码
数据流量:500份/日
高峰流量:1000份/日
数据流编号:D-03
数据流名称:租车成功信息
简述:系统反馈给用户得租车情况
数据流来源:用户
数据流去向:租赁管理模块
数据项组成:车辆编号+当前状态
数据流量:500份/日
高峰流量:1000份/日
数据流编号: D-04
数据流名称:用户信息
简述:用户注册信息
数据流来源:租赁管理模块
数据流去向:管理员
数据项组成:用户姓名+性别+年龄+用户名+用户密码+身份证号码
数据流量:500份/日
高峰流量:1000份/日
数据流编号:D-05
数据流名称:租车信息
简述:租车过程中所包含的基本信息表
数据流来源:用户
数据流去向:租车处理模块
数据项组成:车辆编号+租车起始时间
数据流量:500份/日
高峰流量:1000份/日
数据流编号:D-06
数据流名称:站点信息
简述:租赁站点信息
数据流来源:查询处理理模块
数据流去向:用户
数据项组成:站点名称+站点状态
数据流量:500份/日
高峰流量:1000份/日
数据流编号:D-07
数据流名称:还车信息
简述:还车过程中所包含的基本信息表
数据流来源:还车处理模块
数据流去向:用户
数据项组成:车辆编号+还车时间
数据流量:500份/日
高峰流量:1000份/日
数据流编号:D-08
数据流名称:站点车辆信息
简述:站点自行车的数量
数据流来源:查询处理模块
数据流去向:用户
数据项组成:车辆编号+车辆状态
数据流量:500份/日
高峰流量:1000份/日
3.5.3 处理逻辑描述
处理逻辑编号:P1
处理逻辑名称:租车处理
简述:处理用户租车请求
输入的数据流:登入信息
处理描述:系统根据用户的登录信息进行处理,查看其租车金额是否充足,并把租车信息反馈飞用户
输出的数流:租车信息
处理频率:对每个用户都要求处理一次
处理逻辑编号:P2
处理逻辑名称:查询处理
简述:用户在租赁网点查查看附近网点以及车辆信息
输入的数据流:登入信息
处理描述:用户到租赁点通过系统发送查询信息,系统对其进行处理,并把处理信息反馈给用户
输出的数流:站点信息,车辆信息
处理频率:对每个客户都要求处理一次
处理逻辑编号:P3
处理逻辑名称:还车处理
简述:用户通过系统把自行车还到一个租赁点
处理描述:系统根据用户的还车请求信息进行处理,并把还车成功信息反馈给用户
输出的数流:还车信息
处理频率:对每个预定信息及房间信息都处理一次
处理逻辑编号:P4
处理逻辑名称:车辆管理
简述:管理员对车辆进行分析统计
输入的数据流:登入信息
处理描述:管理员登入系统,通过系统来了解各个站点的车辆情况
输出的数流:车辆信息
处理频率: 对员工每次录入房间信息都处理一次
处理逻辑编号:P5
处理逻辑名称:用户管理
简述:管理员通过系统对用户信息进行管理
输入的数据流:登入
处理描述:管理员登入系统进行添加用户,修改用户信息等活动
输出的数流:用户信息
处理频率:对员工每次录入餐饮信息都要求处理一次
处理逻辑编号:P1.1
处理逻辑名称:办卡
简述:用户通过注册获取租赁凭借
输入的数据流:用户信息
处理描述:用户到服务点注册其个人信息,领取记录其信息的卡,凭卡进行自行车的租换
输出的数流:登入信息
处理频率:根据客户每次餐饮消费记录进行一次处理
处理逻辑编号:P1.2
处理逻辑名称:刷卡
简述:用户通过刷卡向系统发送信息
输入的数据流:登入信息
处理描述:刷卡过程及用户登入过程,用户通过刷卡向系统发送个人信息
输出的数流:刷卡成功信息
处理频率:根据客户每次的退房要求进行一次处理
处理逻辑编号:P1.3
处理逻辑名称:租赁请求
简述:用户的租车意愿
输入的数据流:刷卡成功信息
处理描述:用户刷卡成功后向系统发送租赁自行车的请求
处理频率:根据客户每次的结账要求进行一次处理
处理逻辑编号:P1.4
处理逻辑名称:核对信息
简述:系统对用户信息的核对
输入的数据流:用户信息
处理描述:系统对用户信息进行比较处理
处理频率:根据客户每次的结账要求进行一次处理
处理逻辑编号:P1.5
处理逻辑名称:开锁
简述:车辆解锁
输入的数据流:开锁指令
处理描述:核对信息无误后系统对车辆进行解锁
处理频率:根据客户每次的结账要求进行一次处理
处理逻辑编号:P1.6
处理逻辑名称:发送信息至中心管理端
简述:将用户信息以及车辆信息发送到中心管理端
输入的数据流:用户信息
处理描述:自行车解锁后系统记录用户信息以及相应的车辆信息
处理频率:根据客户每次的结账要求进行一次处理
处理逻辑编号:P1.7
处理逻辑名称:开始计时收费
简述:系统记录用户消费信息
输入的数据流:消费信息
处理描述:自行车解锁后系统开始对用户计时消费
处理频率:根据客户每次的结账要求进行一次处理
3.5.4 数据存储的描述
数据存储编号:F-01
数据存储名称:租车信息表
简述:租车处理所产生的信息表
数据存储组成:用户姓名+性别+年龄+用户名+用户密码+身份证号码+车辆
编号
关键字:用户姓名,车辆编号
相关联的处理:P1.6
数据存储编号:F-02
数据存储名称:站点信息表
简述:查询得到的站点情况以及车辆状况
数据存储组成:站点名称+车辆编号+车辆状态
关键字:站点名称编号
相关联的处理:P2.4,P2.5
数据存储编号:F-03
数据存储名称:用户信息表
简述:用户基本信息表单
数据存储组成:用户姓名+性别+年龄+用户名+用户密码+身份证号码
关键字:用户编号
相关联的处理:P1.3,P1.5
数据存储编号:F-04
数据存储名称:车辆信息单
简述:车辆即时状态
数据存储组成:车辆编号+车辆状态
关键字:车辆编号
相关联的处理:P2.4,P3.4
3.5.5 外部实体的描述
外部实体编号:S-01
外部实体名称:旅客
简述:自行车的使用者
输出的信息流:登录信息
流入的信息流:租车成功信息、消费信息
外部实体编号:S-02
外部实体名称:管理员
简述:系统的监管人员
输出的信息流:登录信息
流入的信息流:车辆信息、用户信息
第四章 系统设计
4.1功能结构图设计
按照系统架构设计方案和各模块功能,公共自行车管理信息系统有5大管理功能模块。各个子系统由后台数据库系统和相应的子系统应用程序组成。本系统的管理功能结构图如图4-1所示。
图4-1 公共自行车管理信息系统的管理功能结构图
该功能结构具体描述如下:
基础信息模块:包括用户信息、管理员信息、车辆信息。基础信息子系统记录了整个自行车管理信息系统所需的基本数据,以下几个模块都是以此来运行的。
借车管理模块:包括持卡人信息、租用车辆信息、卡内金额信息。该模块确保一辆车对应一个人,实现一一对应的关系。从而让系统管理员有效的管理车辆以及用户的消费情况。
还车管理模块:包括还车人信息、所还车辆信息、消费信息。该模块确保相应车辆的及时回收,消费结算。
查询管理模块:包括最近租赁店信息、租赁店车辆信息。这个模块是整个自行车管理信息系统的重之重的模块之一。它提供的查询功能让用户了解那里有车,最近网点在哪等信息。能很好解决市民借车还车过程中遇到的问题。
系统管理模块:包括系统管理员更换。修改用户信息、修改车辆信息。系统管理员依据该模块来有效的管理车辆,用户。确保相关信息的及时更新。
4.2数据库设计
系统数据库是整个系统能正常运行的基础,数据库的设计直接关系到系统开发的成败与运行效率。在系统的开发过程中,着重设计在有效、安全、完整的基础上实现数据库的最小冗余度。
从20世纪70年代末以来,众多学者对数据库设计方法进行了深入的探讨和尝试,结合出许多各有优点的数据库设计方法,有基于E-R模型的数据库设计方法,基于3NF的设计方法,基于抽象语法规范的设计方法等,较为实用的主流方法有两种:E-R模型加规范化关系的方法和数据元素图加规范化关系的方法。本系统在数据库概念结构设计中是采用E-R模型加规范化关系的方法进行设计的,下面对该方法进行简单的介绍。
E-R模型加规范化关系的方法在数据库结构设计中,主要工作是从需求分析所得到的所有信息以及它们之间的依赖关系出发,去构造系统数据模型。在构造模型中,最常用的是E-R模型法。E-R模型中最基本的成分是实体、联系以及它们的属性。而实体(或联系)与属性构成关系,因为是否“规范化”而有“好”、“坏”之分,而关系的好坏又直接影响数据库的质量。
4.2.1数据库的概念设计
数据库概念设计是数据库设计的关键,是由分析用户需求到生成概念产品的一系列有序的、可组织的、有目标的设计活动,它表现为一个由粗到精、由模糊到清晰、由具体到抽象的不断进化的过程。
为了满足系统的功能需求,抽象出自行车、管理员、用户、IC卡、租赁点五个实体,以及系统全局E-R图如下:
自行车(车辆编号,车辆型号,出厂日期,车辆状态,车辆位置)。如图4-2所示。
图4-2 自行车实体关系图
管理员(管理员编号,密码,姓名,性别,年龄,身份证号,电话),如图4-3所示。
图4-3 管理员实体关系图
用户(用户编号,用户姓名,性别,年龄,身份证号码),如图4-4所示。
图4-4 用户实体关系图
IC卡(卡号,用户编号,租赁车辆编号,卡内金额,消费金额),如图4-5所示。
图4-5 IC卡实体关系图
租赁点(租赁点名称,租赁点编号,租赁点车辆状态,租赁点车辆编号),如图4-6所示。
图4-6 租赁点实体关系图
系统全局E-R图,如图4-7所示。
图4-7 全局 E-R 图
4.2.2数据库的逻辑结构设计
逻辑设计的主要任务就是设计数据的结构,即按照数据库管理系统提供的数据模型,转换已设计的概念模型,实质上是把概念模型(即E-R模型)转换为所选用的DBMS所支持的模式。公共自行车管理系统中各个表的设计如下。其中每个表格都代表数据库中的一个表。
用户信息表(见表4-2-1)
表4-2-1 用户信息表 | |||||
序号 | 字段名 | 数据类型 | 长度 | 是否为空 | 字段说明 |
1 | UId | Varchar | 50 | NOT NULL | 用户编号,主键 |
2 | UGender | Varchar | 50 | NOT NULL | 用户性别 |
3 | UAge | Varchar | 50 | NOT NULL | 用户年龄 |
4 | UName | Varchar | 50 | Not NULL | 用户姓名 |
5 | INumber | Varchar | 50 | NOT NULL | 用户身份证号 |
管理员信息表(见表4-2-2)
表4-2-2 管理员信息表 | |||||
序号 | 字段名 | 数据类型 | 长度 | 是否为空 | 字段说明 |
1 | AId | Varchar | 50 | NOT NULL | 管理员编号,主键 |
2 | AGender | Varchar | 50 | NOT NULL | 性别 |
3 | AAge | Varchar | 50 | NOT NULL | 年龄 |
4 | APhone | Varchar | 50 | NOT NULL | 电话 |
5 | INumber | Varchar | 50 | NOT NULL | 身份证号 |
6 | AName | Varchar | 50 | Not NULL | 管理员姓名 |
7 | APassword | Varchar | 50 | NOT NULL | 密码 |
自行车信息表(见表表4-2-3)
表4-2-3 自行车信息表 | |||||
序号 | 字段名 | 数据类型 | 长度 | 是否为空 | 字段说明 |
1 | VCode | Varchar | 50 | NOT NULL | 车辆编号,主键 |
2 | VModels | Varchar | 50 | NOT NULL | 车辆型号 |
3 | VStatus | Varchar | 50 | NOT NULL | 车辆状态 |
4 | VLocation | Varchar | 50 | NOT NULL | 车辆位置 |
5 | FDate | Datetime | NOT NULL | 出厂日期 |
IC卡信息表(见表4-2-4)
表4-2-4 IC卡信息表 | |||||
序号 | 字段名 | 数据类型 | 长度 | 是否为空 | 字段说明 |
1 | CNumber | Varchar | 50 | NOT NULL | 卡号,主键 |
2 | UId | Varchar | 50 | NOT NULL | 用户编号 |
3 | RVCode | Varchar | 50 | NOT NULL | 租赁车辆编号 |
4 | CPayment | Money | 50 | NOT NULL | 卡内金额 |
25 | CRate | Money | 50 | NOT NULL | 消费金额 |
租赁点信息表(见表4-2-5)
表4-2-5 租赁点信息表 | |||||
序号 | 字段名 | 数据类型 | 长度 | 是否为空 | 字段说明 |
1 | RPName | Varchar | 50 | NOT NULL | 租赁点名称,主键 |
2 | LPNumber | Varchar | 50 | NOT NULL | 租赁点编号 |
3 | LPVCondition | Varchar | 50 | NOT NULL | 租赁点车辆状态 |
4 | LPCode | Varchar | 50 | NOT NULL | 租赁点车辆编号 |
4.3输入输出设计
系统设计的过程和系统实施的过程恰好相反,并不是从输入设计到输出设计,而是从输出设计到输入设计,这是因为输出设计直接和用户需求相联系,设计的出发点应该是保证输出方便地为用户服务,正确地反映用户所需要的有用信息。
输出设计的主要目的是满足用户和管理者对数据和信息的要求。输出设计要考虑的主要内容有:输出信息名,该输出信息的名称;输出功能,该输出信息起什么作用;输出周期,多长时间输出一次;输出期限,每次输出的期限;输出媒体,输出信息记录媒体名称;输出方式,批输出还是实时输出;输出用纸,专用纸或通用纸;传递方式,邮递、电话、传真、电子邮件或人工传递;使用后的处理,保存、销毁或上缴;输出用文字,英文、汉字、汉语拼音;输出信息校验,检验输出信息的正确性,包括确定校验内容、检验方法和校验后的处理。保密要求,有或无;输出项目名称,构成输出信息的每个数据项。
在计算机信息系统中,输入数据的正确与否决定着整个系统质量的好坏。若输入数据缺精确性和适时性,即使计算和处理十分正确,也不可能得到可靠的输出信息。最佳的信息系统始于最佳的输入系统。根据输出信息的要求,输入设计要考虑的主要内容如下: 输入信息名,该输入信息的名称;输入周期,多长时间输入一次;输入期限,每次输入的期限;输入媒体,输入信息记录媒体名称;输入方式,批输入还是实时输入;收集方式,原始记录如何收集;原始信息名,与本输入对应的用户原始凭证;输入项目名,构成输入信息的每个数据项名称;输入用文字,英文、汉字或汉语拼音。
查询输入界面,如图4-8所示。
图4-8 查询输入界面图
查询输出界面,如图4-9所示。
图4-9 查询输出界面图
其他的定制服务 下方联系卡片↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ 或者私信作者