基于JSP网络售票系统毕业论文.doc

基于JSP网络售票系统毕业论文目录第一章 概述11.1概述11.2意义11.3任务1第二章 系统的可行性研究与需求分析23.1可行性研究23.1.1经济可行性23.1.2技术可行性23.1.3操作可行性23.2需求分析23.3.1功能需求23.3.2数据需求33.3.3性能需求43.3.4数据流图53.3.5数据字典53.3.6实体-联系图63.3.7数据库逻辑结构7第三章 系统的总体设计84.1系统软件结构设计84.1.1软件结构84.1.2模块算法84.2系统流程图9第四章 系统的详细设计125.1接口设计125.1.1用户接口125.1.2外部接口125.1.3内部接口125.1.4软件接口125.1.5模块内部125.2过程设计125.3.1程序流程图12第五章 系统的实现与调试196.1应用系统的开发及测试196.1.1系统首页196.1.2产品说明196.1.3用户登录及访问权限196.1.4车次信息查询216.1.5售票信息查询226.1.6售票236.1.7退票265.2部分代码285.3.1登陆界面285.3.2主界面305.3.3车次查询条件选择界面325.3.4精确车次信息355.3.5搜索车次信息365.3.6售票信息查询395.3.7售票用户信息405.3.8售票售票信息425.3.9退票43结束语45参考文献4562第1章 概述1.1概述目前火车站售票的状况是仅靠手工操作，以现有的工作人员很难应付车票订购高峰时刻的大量数据处理问题。同时还会出现由此带来的大量记录存放和管理所带来的问题。本次设计拟开发一个火车票售票系统，可以降低工作人员的工作量，提高工作人员的工作效率，同时方便顾客售票。1.2意义火车站市场的管理和规范问题，是困扰我们多年的一个老问题，也是政府管理中的一个难点，售票是客运业务中的一个最基本的业务，表面上看，它只是火车站业务的一个简单的部分，但是它涉及到管理与客户服务等多方面，因此，过去传统的售票方式已经不能满足现代客运业务流量剧增的客观要求，这就要求一种全新的售票方式网上售票，来缓解售票高峰时期的客运压力，并为用户提供方便快捷的售票服务。本次设计便是利用开发工具JSP 和SQL Server 2000数据库共同开发的一个火车票售票系统，它能方便快捷地运用在火车站售票业务的营运之中。1.3任务本系统设计主要是根据售票业务的基本流程进行的，系统功能包括如下几个方面：查询：分为对车次信息的查询和客户对已订车票信息的查询售票：通过查询系统，客户根据自己的需求找到满意的车次，再输入个人信息后直接通过网上售票确定已预订选中的车票。退票：可退票，通过查询系统，客户可以根据自己的名字找到自己的售票信息，通过退票模块退去已购车票。第2章 开发工具JSP 简介Java I/O 系统对编程语言的设计者来说，创建一套好的输入输出(I/O)系统，是一项难度极高的任务。这一点可以从解决方案的数量之多上看出端倪。这个问题难就难在它要面对的可能性太多了。不仅是因为有那么多I/O的源和目地(文件，控制台，网络连接等等)，而且还有很多方法(顺序的sequential，随机的random-SQLServer2000，缓存的buffered，二进制的binary，字符方式的character，行的by lines，字的by words，等等)。 Java类库的设计者们用创建很多类的办法来解决这个问题。坦率地说Java I/O系统的类实在是太多了，以至于初看起来会把人吓着（但是，具有讽刺意味的是，这种设计实际上是限制了类的爆炸性增长）。此外，Java在1.0版之后又对其I/O类库作了重大的修改，原先是面向byte的，现在又补充了面向Unicode字符的类库。为了提高性能，完善功能，JDK 1.4又加了一个nio(意思是new I/O。这个名字会用上很多年)。这么以来，如果你想对Java的I/O类库有个全面了解，并且做到运用自如，你就得先学习大量的类。此外，了解I/O类库的演化的历史也是相当重要的。可能你的第一反应是别拿什么历史来烦我了，告诉我怎么用就可以了！但问题是，如果你对这段历史一无所知，很快就会被一些有用或是没用的类给搞糊涂了。 本章会介绍Java标准类库中的各种I/O类，及其使用方法。 File 类在介绍直接从流里读写数据的类之前，我们先介绍一下处理文件和目录的类。 File类有一个极具欺骗性的名字；或许你会认为这是一个关于文件的类，但它不是。你可以用它来表示某个文件的名字，也可以用它来表示目录里一组文件的名字。如果它表示的是一组文件，那么你还可以用list( )方法来进行查询，让它会返回String数组。由于元素数量是固定的，因此数组会比容器更好一些。如果你想要获取另一个目录的清单，再建一个File对象就是了。实际上，叫它 FilePath可能会更好一些。下面我们举例说明怎样使用这个类及其相关的FilenameFilter接口。 目录列表器假设你想看看这个目录。有两个办法。一是不带参数调用list( )。它返回的是File对象所含内容的完整清单。但是，如果你要的是一个限制性列表(restricted list)的话 比方说，你想看看所有扩展名为.java的文件 那么你就得使用目录过滤器了。这是一个专门负责挑选显示File对象的内容的类。DirFilter实现了FilenameFilter接口。我们来看看FilenameFilter究竟有多简单： public interface FilenameFilter boolean accept(File dir, String name);也就是说，这类对象的任务就是提供一个accept( )的方法。之所以要创建这个类，就是要给list( )提供一个accept( )方法，这样当list( )判断该返回哪些文件名的时候，能够回过头来调用accept( )方法。因此，这种结构通常被称为回调(callback)。更准确地说，由于list( )实现了基本功能，而FilenameFilter提供了对外服务所需的算法，因此这是一种策略模式(Strategy Pattern)。由于list( )拿FilenameFilter对象当参数，因此你可以将任何实现FilenameFilter接口的对象传给它，并以此(甚至是在运行时)控制list( )的工作方式。回调能提高程序的灵活性。 DirFilter还告诉我们，interface只是包含了一些方法，它没说你只能写这些方法。(但是，你至少要定义接口里有的方法。) 这里我们还定义了DirFilter的构造函数。 accept( )方法需要两个参数，一个是File对象，表示这个文件是在哪个目录里面的；另一个是String，表示文件名。虽然你可以忽略它们中的一个，甚至两个都不管，但是你大概总得用一下文件名吧。记住，list( )会对目录里的每个文件调用accept( )，并以此判断是不是把它包括到返回值里；这个判断依据就是accept( )的返回值。 切记，文件名里不能有路径信息。为此你只要用一个String对象来创建File对象，然后再调用这个File对象的getName( )就可以了。它会帮你剥离路径信息（以一种平台无关的方式）。然后再在accept( )里面用正则表达式(regular expression)的matcher对象判断，regex是否与文件名相匹配。兜完这个圈子，list( )方法返回了一个数组。输入与输出I/O类库常使用流(stream)这种抽象。所谓流是一种能生成或接受数据的，代表数据的源和目标的对象。流把I/O设备内部的具体操作给隐藏起来了。 正如JDK文档所显示的，Java的I/O类库分成输入和输出两大部分。所有InputStream和Reader的派生类都有一个基本的，继承下来的，能读取单个或byte数组的read( )方法。同理，所有OutputStream和Writer的派生类都有一个基本的，能写入单个或byte数组的write( )方法。但通常情况下，你是不会去用这些方法的；它们是给其它类用的 而后者会提供一些更实用的接口。因此，你很少会碰到只用一个类就能创建一个流的情形，实际上你得把多个对象叠起来，并以此来获取所需的功能。Java的流类库之所以会那么让人犯晕，最主要的原因就是你必须为创建一个流而动用多个对象。 我们最好还是根据其功能为这些class归个类。Java 1.0的类库设计者们是从决定让所有与输入相关的类去继承InputStream入手的。同理，所有与输出相关的类就该继承OutputStream了。 InputStream的种类InputStream的任务就是代表那些能从各种输入源获取数据的类。这些源包括： byte数组 String对象 文件 类似流水线的管道(pipe)。把东西从一头放进去，让它从另一头出来。 一个流的序列(A sequence of other streams)，可以将它们组装成一个单独的流。 其它源，比如Internet的连接。（这部分内容在Thinking in Enterprise Java中讨论。） 这些数据源各自都有与之相对应的InputStream的子类。此外，FilterInputStream也是InputStream的子类，其作用是为基类提供decorator(修饰)类，而decorator又是为InputStream配置属性和接口的。这部分内容我们以后再谈。 OutputStream的种类这部分都是些决定往哪里输出的类：是byte的数组(不能是String；不过你可以根据byte数组创建字符串)还是文件，或者是管道。 此外，FilterOutputStream还是decorator类的基类。它会为OutputStream安装属性和适用的接口。添加属性与适用的接口使用分层对象(layered objects)，为单个对象动态地，透明地添加功能的做法，被称为Decorator Pattern。(模式是Thinking in Patterns (with Java)的主题。)Decorator模式要求所有包覆在原始对象之外的对象，都必须具有与之完全相同的接口。这使得decorator的用法变得非常的透明-无论对象是否被decorate过，传给它的消息总是相同的。这也是Java I/O类库要有filter(过滤器)类的原因：抽象的filter类是所有decorator的基类。(decorator必须具有与它要包装的对象的全部接口，但是decorator可以扩展这个接口，由此就衍生出了很多filter类)。 Decorator模式常用于如下的情形：如果用继承来解决各种需求的话，类的数量会多到不切实际的地步。Java的I/O类库需要提供很多功能的组合，于是decorator模式就有了用武之地。 但是decorator有个缺点，在提高编程的灵活性的同时(因为你能很容易地混合和匹配属性)，也使代码变得更复杂了。Java的I/O类库之所以会这么怪，就是因为它必须为一个I/O对象创建很多类，也就是为一个核心I/O类加上很多decorator。 为InputStream和OutputStream定义decorator类接口的类，分别是FilterInputStream和FilterOutputStream。这两个名字都起得不怎么样。FilterInputStream和FilterOutputStream都继承自I/O类库的基类InputStream和OutputStream，这是decorator模式的关键(惟有这样decorator类的接口才能与它要服务的对象的完全相同)。 用FilterInputStream读取InputStreamFilterInputStream及其派生类有两项重要任务。DataInputStream可以读取各种primitive及String。(所有的方法都以read打头，比如readByte( )， readFloat( )。它，以及它的搭档DataOutputStream，能让你通过流将primitive数据从一个地方导到另一个地方。这些地方都列在表13-1里。 其它的类都是用来修改InputStream的内部行为的：是不是做缓冲，是不是知道它所读取的行信息(允许你读取行号或设定行号)，是不是会弹出单个字符。后两个看上去更像是给编译器用的(也就是说，它们大概是为Java编译器设计的)，所以通常情况下，你是不大会用到它们的。 不论你用哪种I/O设备，输入的时候，最好都做缓冲。所以对I/O类来说，比较明智的做法还是把不缓冲当特例(或者去直接调用方法)，而不是像现在这样把缓冲当作特例。用FilterOutputStream往OutputStream里面写东西DataInputStream的另一半是DataOutputStream。它的任务是把primitive数据和String对象重新组织成流，这样其它机器就能用DataInputStream读取这个流了。DataOutputStream的方法都是以write开头的，比如writeByte( )，writeFloat( )等等。PrintStream的用意是要以一种大家都能看懂的方式把primitive数据和String对象打印出来。这一点同DataOutputStream不同，后者是要将数据装入一个流，然后再交给 DataInputStream处理。PrintStream的两个最重要的方法是print( )和println( )。这两个方法都已经作了重载，因此可以打印各种数据。print( )和println( )的区别在于，后者会多打印一个换行符。 使用PrintStream的时候会比较麻烦，因为它会捕捉所有的IOException(所以你必须直接调用checkError( )来检查错误条件，因为这个方法会在碰到问题的时候返回true)。再加上，PrintStream的国际化做得也不好，而且还不能以与平台无关的方式处理换行。Reader 和 Writer类系Java 1.1对最底层的I/O流类库作了重大修改。第一次看到Reader和Writer的时候，你会觉得它们大概是用来取代InputStream和OutputStream的 (和我一样)。但事实并非如此。虽然InputStream和OutputStream的某些功能已经淘汰了(如果你继续使用，编译器就会发警告)，但它们仍然提供了很多很有价值的，面向byte的I/O功能，而Reader和Writer则提供了Unicode兼容的，面向字符的I/O功能。此外:Java 1.1还对InputStream和OutputStream作了新的补充，所以很明显这两个类系并没有被完全替代。 有时，你还必须同时使用基于byte的类和基于字符的类。为此，它还提供了两个适配器(adapter)类。InputStreamReader负责将InputStream转化成Reader，而OutputStreamWriter则将OutputStream转化成Writer。 Reader和Writer要解决的，最主要的问题就是国际化。原先的I/O类库只支持8位的字节流，因此不可能很好地处理16位的Unicode字符流。Unicode是国际化的字符集(更何况Java内置的char就是16位的Unicode字符)，这样加了Reader和Writer之后，所有的I/O就都支持Unicode了。此外新类库的性能也比旧的好。秉承本书的一贯风格，我这里只准备作一个简要的介绍，要想了解具体的细节，比如类都有哪些方法，请查阅JDK的文档。数据源和目的几乎所有的Java I/O流都有与之对应的，专门用来处理Unicode的Reader和Writer。但有时，面向byte的InputStream和OutputStream才是正确的选择；特别是java.util.zip；它的类都是面向byte的。所以最明智的做法是，先用Reader和Writer，等到必须要用面向byte的类库时，你自然会知道的，因为程序编译不过去了。自成一派: RandomSQLServer2000FileRandomSQLServer2000File是用来访问那些保存数据记录的文件的，这样你就可以用seek( )方法来访问记录，并进行读写了。这些记录的大小不必相同；但是其大小和位置必须是可知的。首先，你可能会不太相信，RandomSQLServer2000File竟然会是不属于InputStream和OutputStream类系的。实际上，除了实现DataInput和DataOutput接口之外(DataInputStream和DataOutputStream也实现了这两个接口)，它和这两个类系毫不相干，甚至都没有用InputStream和OutputStream已经准备好的功能；它是一个完全独立的类，所有方法(绝大多数都只属于它自己)都是从零开始写的。这可能是因为RandomSQLServer2000File能在文件里面前后移动，所以它的行为与其它的I/O类有些根本性的不同。总而言之，它是一个直接继承Object的，独立的类。基本上，RandomSQLServer2000File的工作方式是，把DataInputStream和DataOutputStream粘起来，再加上它自己的一些方法，比如定位用的getFilePointer( )，在文件里移动用的seek( )，以及判断文件大小的length( )。此外，它的构造函数还要一个表示以只读方式(r)，还是以读写方式(rw)打开文件的参数 (和C的fopen( )一模一样)。它不支持只写文件，从这一点上看，假如RandomSQLServer2000File继承了DataInputStream，它也许会干得更好。只有RandomSQLServer2000File才有seek方法，而这个方法也只适用于文件。BufferedInputStream有一个mark( )方法，你可以用它来设定标记(把结果保存在一个内部变量里)，然后再调用reset( )返回这个位置，但是它的功能太弱了，而且也不怎么实用。RandomSQLServer2000File的绝大多数功能，如果不是全部的话，已经被JDK 1.4的nio的内存映射文件(memory-mapped files)给取代了。输入流1. 对输入文件作缓冲要想打开打开文件读取字符，你得先用String或File对象创建一个FileInputReader。为了提高速度，你应该对这个文件作缓冲，因此你得把FileInputReader的reference交给BufferedReader。由于BufferedReader也提供了readLine( )方法，因此它就成为你最终要使用的那个对象，而它的接口也成为你使用的接口了。当你读到了文件的末尾时，readLine( )会返回一个null，于是就退出while循环了。String s2是用来累加文件内容的(再加一个换行符，因为readLine( )会把它们都剥掉)。后面的程序都要用到这个s2。最后，用close( )来关闭文件。单从技术角度上说，程序退出的时候(不管有没有垃圾要回收)都应该调用finalize( )，而finalize( )又会调用close( )。不过各种JVM的实现并不一致，所以最好还是明确地调用close( )。1b部分还演示了如何用System.in来生成一个能读取控制台输入的流。System.in是一个InputStream，而BufferedReader需要一个Reader作参数，所以要先通过InputStreamReader来转转手。3. 读取内存现在String s2里面已经有一个完整的文件了。因此这部分程序要用它去创建一个StringReader。然后用(StringReader的)read( )方法把字符读出来，再送到控制台上去。注意，read( )会把读出来的byte当作int，所以要想正常打印的话，你得先把它们转换成char。4. 读取格式化的内存要想读取格式化的数据，你就得用DataInputStream了，它是一个面向byte的I/O类 (不是面向char的)，因此你只能从头到底一直用InputStream了。当然你可以把所有东西(比方说文件) 都当成byte，然后用InputStream读出来，但这里是String。要想把String变成成byte数组，可以用String的getBytes( )方法，而ByteArrayInputStream是可以处理byte数组的。到了这一步，你就不用担心没有合适的InputStream来创建DataInputStream了。如果你是用readByte( )逐字节地读取DataInputStream的话，那么无论byte的值是多少，都是合法的，所以你无法根据返回值来判断输入是否已经结束了。你只能用available( )来判断还有多少字符。下面我们来演示一下怎样逐字节地读取文件:/: c12:TestEOF.java/ Testing for end of file while reading a byte at a time.import java.io.*;public class TestEOF / Throw exceptions to console: public static void main(String args) throws IOException DataInputStream in = new DataInputStream( new BufferedInputStream( new FileInputStream(TestEOF.java); while(in.available() != 0) System.out.print(char)in.readByte(); /:注意，available( )的工作方式会随读取介质的不同而不同；严格地讲，它的意思是可以不被阻塞地读取的字节的数目。对文件来说，它就是整个文件，但如果是其它流，情况就不一定了，所以用之前要多留一个心眼。你也可以像这样，用异常来检查输入是不是完了。但不管怎么说，把异常当成控制流程来用总是对这种功能的滥用。5. 读取文件这段程序还演示了怎样往文件里面写数据。先创建一个FileWriter。BufferedWriter总是免不掉的。(试试把BufferedWriter去掉，你就能看到它对性能的影响了 缓冲能大幅提高I/O的性能)。然后再让PrintWriter去排版。这样就能得出能够读得懂的，普通的文本文件了。随着程序一行一行地写文件，我们就顺便加了一个行号。注意，我们没用LineNumberInputStream，因为这是一个傻乎乎的，没什么用的类。正如这里所看到的，要知道行号还不简单。输入流用完之后，readLine( )会返回null。你会发现，程序显式地调用了out1的close( )，因为如果写文件的时候不调用close( )，它是不会去清空缓冲区的，这样就有可能会落下一些东西了。输出流根据写数据的方式不同，OutputStream主要分成两类；一类是写给人看的，一类是供DataInputStream用的。虽然RandomSQLServer2000File的数据格式同DataInputStream和DataOutputStream的相同，但它不属于OutputStream的。5. 存储和恢复数据PrintWriter会对数据进行格式化，这样人就能读懂了。但是如果数据输出之后，还要恢复出来供其它流用，那你就必须用DataOutputStream来写数据，再用DataInputStream来读数据了。当然，它们可以是任何流，不过我们这里用的是一个经缓冲的文件。DataOutputStream和DataInputStream是面向byte的，因此这些流必须都是InputStream和OutputStream。如果数据是用DataOutputStream写的，那么不管在哪个平台上，DataInputStream都能准确地把它还原出来。这一点真是太有用了，因为没人知道谁在为平台专属的数据操心。如果你在两个平台上都用Java，那这个问题就根本不存在了。用DataOutputStream写String的时候，要想确保将来能用DataInputStream恢复出来，唯一的办法就是使用UTF-8编码，也就是像例程第5部分那样，用writeUTF( )和readUTF( )。UTF-8是Unicode的一种变形。Unicode用两个字节来表示一个字符。但是，如果你处理的全部，或主要是ASCII字符(只有7位)，那么无论从存储空间还是从带宽上看，就都显得太浪费了，所以UTF-8 用一个字节表示ASCII字符，用两或三个字节表示非ASCII的字符。此外，字符串的长度信息存在(字符串)的头两个字节里。writeUTF( )和readUTF( )用的是Java自己的UTF-8版本(JDK文档里有关于这个字符集的完整讲解，就在这两个方法的文档里)，所以如果你要用一个Java程序读取writeUTF( )写的字符串的话，就必须进行一些特殊处理了。有了writeUTF( )和readUTF( )，你就能放心地把String和其它数据混在一起交给DataOutputStream了，因为你知道String是以Unicode的形式存储的，而且可以很方便地用DataOutputStream恢复出来。writeDouble( )会往流里写double，而它影子readDouble( )则负责把它恢复出来(其它数据也有类似的读写方法)。但是要想让读取方法能正常工作，你就必须知道流的各个位置上都放了些什么数据。因为你完全可以把double读成byte，char，或其它什么东西。所以要么以固定的格式写文件，要么在文件里提供额外的解释信息，然后一边读数据一边找数据。先提一下，对于复杂数据的存储和恢复，对象的序列化可能会比较简单。6. 读写随机文件正如我们前面所讲的，如果不算它实现了DataInput和DataOutput接口，RandomSQLServer2000File几乎是完全独立于其它I/O类库之外的，所以它不能与InputStream和OutputStream合起来用。虽然把ByteArrayInputStream当作随机存取的元素(random-SQLServer2000 element)是一件很合情合理的事，但你只能用RandomSQLServer2000File来打开文件。而且，你只能假定RandomSQLServer2000File已经做过缓冲了，因为即便没做你也无能为力。构造函数的第二个参数的意思是：是以只读(r) 还是读写(rw)方式打开RandomSQLServer2000File。RandomSQLServer2000File的用法就像是DataInputStream和DataOutputStream的结合(因为它们的接口是等效的)。此外，你还能用seek( )在文件里上下移动，并进行修改。随着JDK 1.4的new I/O的问世，你该考虑一下是不是用内存映射文件(memory-mapped file)来代替RandomSQLServer2000File了。管道流这一章只会大致地提一下PipedInputStream，PipedOutputStream，PipedReader和PipedWriter。这并不是说它们不重要，只是因为管道流是用于线程间的通信的，所以除非你已经理解了多线程，否则是不会理解它的价值的。标准I/O标准I/O是Unix的概念，它的意思是，一个程序只使用一个信息流 (这种设计思想也以某种形式体现在Windows及其它很多操作系统上)。所有输入都是从标准输入进来的，输出都从标准输出出去，错误消息都送到标准错误里。标准I/O的优点是，它可以很容易地把程序串连起来，并且把一个程序的输出当作另一个程序的输入。这是一种非常强大的功能。读取标准输入Java遵循标准I/O的模型，提供了Syetem.in，System.out，以及System.err。本书一直都在用System.out往标准输出上写，而它(System.out)是一个已经预先处理过的，被包装成PrintStream的对象。和System.out一样，System.err也是一个PrintStream，但是System.in就不对了，它是一个未经处理的InputStream。也就是说，虽然你可以直接往System.out和System.err上写，但是要想读System.in的话，就必须先做处理了。第3章 系统的可行性研究与需求分析3.1可行性研究该阶段通过对系统目标的初步调研和分析，提出可行性方案并进行论证。我们在这里主要从技术可行性、经济可行性和操作可行性三方面进行分析。3.1.1经济可行性开发该系统所需的相关资料可以通过已存在的网上售票系统进行调查采集,所需的其他应用软件、硬件系统也易于获得.因此,开发成本较低。而引进使用本系统后，与传统方式相比，具有高效率、低成本、高质量的特点，可以节省不少人力、物力及财力。所以，从经济的角度来看，该系统可行。3.1.2技术可行性开发工具：JSP 数据库环境：SQL Server 2000系统环境：Microsoft Windows 2000或以上版本。系统实现依靠相对熟悉的JSP语言和SQL Server2000数据库系统，其基本操作实质还是对数据库进行添加、删除、查找等操作，暂不存在技术问题。3.1.3操作可行性系统采用菜单式，实现用户与数据库的交互，界面简洁友好，操作方便。用户只需对售票流程和业务调查了解即可，不需掌握数据库等相关知识。3.2需求分析需求分析是软件设计的一个重要的环节。本阶段对售票系统的应用情况作全面调查，以确定系统目标，并对系统所需要的基础数据以及数据处理要求进行分析，从而确定用户的需求。用户对系统的需求我们从以下几方面进行分析。3.2.1功能需求本网上售票系统应该具备如下功能：1.查询分为对车次信息的查询和客户对已订车票信息的查询。要求：1）对车次的查询，可以按照发车车次进行查询； 2）车次信息包括：车号、出发地、目的地、发车日期、开出时刻、票价。3）座位类型设定。4）车次信息只允许用户查询，不能修改。3.售票通过查询系统，客户根据自己的需求找到满意的车次，再输入个人信息后直接通过网上售票确定已预订选中的车票。要求：售票记录应包括：会员名、车号、发车日期、订购日期、订购票数、总价。4.退票可退票，通过查询系统，客户可以根据自己的名字找到自己的售票信息，通过退票模块退去已购车票。3.2.3性能需求为了保证系统能够长期、安全、稳定、可靠、高效的运行，本系统应该满足以下的性能需求。1.准确性和及时性系统处理的准确性和及时性是系统的必要性能。系统应能及时而且准确的根据用户权限及所输入的信息做出响应。由于本系统的查询功能对于整个系统的功能和性能完成举足轻重。作为系统的很多数据来源，而车票的数量和时间又影响用户的决策活动，其准确性和及时性很大程度上决定了系统的成败。在系统开发过程中，必须采用一定的方法保证系统的准确性和及时性。3.易用性本系统是直接面对用户的，而用户往往对计算机并不是非常熟悉。这就要求系统能够提供良好的用户接口，易用的人机交互界面。要实现这一点，就要求系统应该尽量使用用户熟悉的术语和中文信息的界面，从而保证系统的易用性。4.安全性网上售票系统中涉及到的数据是客运公司相当重要的信息，系统要保证用户的权限，对于车次等信息用户只享有查询服务，不得更改；系统还要提供方便的手段供系统维护人员进行数据备份、日常安全管理、以及系统意外崩溃时数据的恢复等工作。同时系统还要保证对数据库进行及时更新，保证数据一致性。事务事务事务用户信息事务用户事务接收事务车次信息车次信息更新数据库事务接收事务订单信息反馈事务用户事务事务更新数据库接收事务事务订单信息事务查询订单修改订单反馈用户订票事务接收事务反馈用户更新数据库更新数据库用户信息接收事务退票3.2.4数据流图图3.1数据流图3.2.5数据字典表3-2 车次信息数据字典名字：车次信息别名：描述：存放车次信息的文件，以供用户查询定义：车次信息=车号+出发地+目的地+发车日期+开出时刻+到达时刻+ 坐位类型+票价位置：输出到CRT终端或类似的显示部件表3-3售票信息数据字典名字：订票信息别名：订单信息描述：存放订单信息的文件，以供用户查询，并作相应操作定义：订票记录=用户名+车号+发车日期+订购日期+订购票数+总价位置：输出到CRT终端或类似的显示部件表3-4用户信息数据字典名字：用户信息别名：描述：存放用户信息的文件，以供用户方便的查询订单信息，进而做出相应的操作定义：用户信息=用户名+地址+性别+电话位置：输出到CRT终端或类似的显示部件3.2.6实体-联系图用户的需求具体体现在各种信息的提供、保存、更新和查询，这就要求数据库结构能充分满足各种信息的输出和输入。针对火车票售票系统，通过对网上售票工作的过程、内容以及数据流程分析，设计如下所示的数据项和数据结构：1.车次信息包括：车号、出发地、目的地、发车日期、开出时刻、剩余座位数、票价。3.售票记录包括：订单号、身份证号、车号、订购日期、订购票数、总价。4.用户信息包括：用户名、身份证号、性别、电话。E-R图如图4.2所示。nnn11m查询退票订票订单号用户身份证号车号订购日期总价发车日期订票信息用 户用户名地址性别电话车次车次 出发地目的地发车日期开出时刻坐位类型票价订购票数图3.2实体-联系图（E-R图）3.2.7数据库逻辑结构火车票售票系统数据库中各个表格的设计结果如表3-5表3-7所示。每个表格表示在数据库中的一个表。表3-5车次信息表BusInfo字段名数据类型是否可空说明BusIDchar(10)NOT NULL车号（主键）BusFromvarchar(50)NOT NULL出发地BusTovarchar(50)NOT NULL目的地BusDateDatetimeNOT NULL发车日期（主键）BusBeginDatetimeNOT NULL开出时刻BusEndDatetimeNOT NULL到达时刻TicketNumintNOT NULL剩余票数PriceMoneyNOT NULL票价表3-6订单表OrderInfo字段名数据类型是否可空说明OrderIDChar(10)NOT NULL订单号（主键）UserIDChar(18)NOT NULL身份证号（外键）BusIDchar(10)NOT NULL车号（外键）BusDatedatetimeNOT NULL发车日期（外键）OrderDatedatetimeNOT NULL订购日期OrderNumIntNOT NULL订购票数TotalMoneyNOT NULL总价表3-7用户表User第4章 系统的总体设计4.1系统软件结构设计4.1.1软件结构本火车票售票系统可划分为信息查询、网上售票、取消售票三个部分。其中信息查询又可分为车次查询和订单查询两个部分。其层次图如图5.1所示。火车票售票系统信息查询车次查询售票查询网上售票取消售票图4.1火车票售票系统的层次图4.1.2模块算法1.各级别算法1）界面级算法处理输入信息，产生相应任务。输入数据产生任务客户端校验数据数据信息反馈信息加工图4.2界面级算法示意图2）数据库级算法执行相应数据库操作，并直接返回信息反馈。底层数据库操作（封装）用户界面级模块任务数据校验，调用相关模块功能图4.3数据库级算法示意图4.2系统流程图系统顶层流程图如下图4.5所示。图4.6图4.9为各模块详细系统流程图。查询程序售票程序退票程序火车站售票系统系统数据库事务相应信息操作反馈图4.5顶层系统流程输入所需车次的重要信息查询程序系统数据库符合用户需求的车次信息事务查询程序系统数据库符合用户需求的订票信息事务输入查询条件图4.6车次信息查询系统流程图图4.7订单信息查询系统流程图订票程序系统数据库操作反馈事务输入订票信息图4.8售票系统流程图第5章 系统的详细设计5.1接口设计5.1.1用户接口用户通过界面接口实现参数的输入，进入相应的界面后输入提示的信息即可产生相应的任务。5.1.2外部接口接口通过一个数据转换器，将网络二进制数据流转换为一个合适的数据结构单位并添加到缓冲区中。5.1.3内部接口表5-1内部接口说明表顶层模块二级模块接口数据模块底层数据操作模块取出记录集，执行SQL语句用户操作模块对应数据库相关表操作界面模块界面模块生成任务缓冲区模块生成批处理5.1.4软件接口本系统程序所使用的数据库来源于主机数据库，所以系统数据与主机数据库数据向一致。5.1.5模块内部模块以接受参数方式独立登陆主机数据库并且独立运行，返回数据包显示在界面上。5.2过程设计5.2.1程序流程图本系统主界面为用户设计了三个功能操作以供选择：查询，售票，退票。另外，为方便用户，还将“退出系统”也单另列了出来，用户可以根据需要触发不同事件。其处理流程如图5.1所示。图5.2图5.6反映了不同触发事件具体的处理流程。1.系统用户权限的系统主处理流程NYYYNY开始主界面NY选择订票窗口选择查询窗口查询界面订票订票界面选择退票窗口YN退票退票界面退出N查询车次信息订票查询订票信息退票结束登录框登录，确定访问权限图5.1系统用户权限的系统主程序流程图3.新用户权限的系统主处理流程YNYNY选择查询窗口查询界面订票订票界面YN退出查询车次信息订票结束开始主界面选择订票窗口登录框登录，确定访问权限图5.2新用户权限的系统主程序流程图4.车次信息查询处理流程NNN