高中教务在线选课系统毕业设计(本科论文).doc

大连交通大学信息工程学院
毕业设计(论文)任务书

题 目 鞍山市华育高中教务在线选课系统

任务及要求：
1.设计（研究）内容和要求
任务：
1、 调查基于鞍山市华育高中教务在线选课系统，完成实习报告，字数不少于3000，第三周交给指导老师。
2、 结合自己实习情况安排进度，填写进度计划表，第二周完成后交给指导老师签字，并严格执行。
3、 按照软件工程思想，独立完成系统的设计和程序开发，完成代码估计2000行左右。
4、 用JSP实现鞍山市华育高中教务在线选课系统。
5、 程序简洁，算法可行，运行情况良好。

要求：
1、 每周和指导老师至少见面沟通一次，回报课题进展情况，接受老师询问。
2、 接到任务书后，查阅与题目及专业相关的外文资料进行翻译，要求不少于10000个外文字符，译出汉字不得少于3000，于第四周交给指导老师审阅。
3、 毕业设计第13周完成毕业论文的装订，并由指导老师评阅。论文要求12000字以上，包括综述、系统总体设计、系统实现、性能分析、结论等。
4、 教学第13周通过中软及教研室组织进行软件验收，验收时要提供软件使用说明书。
5、 于第13周提出毕业答辩申请并签字。
6、 第14 周答辩，要求制作PPT

2.原始依据
通过大学几年的学习，已经学习了诸如软件工程、数据库原理及应用、数据结构、C++、Visual Basic、JAVA等多门程序设计语言和网络等基础知识和专业知识，学生有能力而且可以独立完成小中型项目的设计与开发。学校现有设备和环境可以提供给学生实习和上机，而且具有专业老师可以指导学生。

3.参考文献
[1] 孙卫琴. 李洪成．Tomcat与Java Web开发技术详解[M]．北京：电子工业出版社. 2005.8.
[2] 石志国. 薛为民. 董洁. JSP 应用教程[M].北京：清华大学出版社, 北京交通大学出版社.2004.9.
[3] 汪孝宜.刘中兵.徐佳晶. JSP数据库开发实例精粹[M]. 北京：电子工业出版社.2005.1.
[4] Bruce Eckel. JAVA 编程思想(Thinking in Java)[M].北京：机械工业出版社.2002.9.
[5] 耿祥义.张跃平. JSP实用教程[M]. 北京：清华大学出版社. 2003.4.
[6] 蔡卫欣. Mysql数据库的设计方法[M].北京：人民邮电出版社,2007.1.
[7] 蔡俊平. Java Script实用范例辞典[M].北京：清华大学出版社.2007.4.
[8] Beauchamp,K. G. Applications of Walsh and Related Functions. New York:Academic Press,2000
[9] Tzafestas,S. G. ed. Walsh Functions in Signal and Systems Analysis and Design. New York:VanNostrand Reihold Co.2004.
[9] 倪宏. 微计算机应用[J].北京：中国科学院,2006.4.
[10] 武延军.黄飞跃. 精通JSP编程技术[M].北京：人民邮电出版社,2001.3.

　指导教师签字：
教研室主任签字：
　　　　　　　　　　　　　　　　　　　　　　 年 月 日
大连交通大学信息工程学院
毕业设计(论文)进度计划与考核表
学生姓名
范函铭
专业班级
软件工程08-3班
指导教师
袁振海
刘瑞杰
本课题其他人员
无
题　目
鞍山市华育高中教务在线选课系统
日　期
计划完成内容
完成情况
指导老师检查签字
第1周
拟定《毕业论文进度计划与考核表》

第2周
完成实习或调研报告

第3周
提交外文文献翻译质料

第4周
系统概要设计阶段

第5周
系统详细设计阶段

第6周
系统编码实施、完成论文初稿

第7周
完成系统编码实施

第8周
系统编码调试、提交论文初稿

第9周
完成系统编码调试、完善毕业论文

第10周
完成撰写毕业设计论文编写及代码测试

第11周
完成论文终稿、准备毕业论文打印、装订

第12周
提交毕业论文终稿及代码

第13周
完成毕业论文

第14周
毕业论文答辩

指导教师签字：　　　　　　　　　　　 　　年　　月　　日

注：“计划完成内容”由学生本人认真填写，其它由指导教师考核时填写。

大连交通大学信息工程学院
毕业设计(论文)外文翻译

学生姓名 范函铭 专业班级 软件工程 08-3班
指导教师 袁振海 刘瑞杰 职 称 高工　讲师
所在单位 　 信息科学系软件工程教研室
教研室主任 　 刘瑞杰

完成日期 2012 年 4 月 13 日
Object persistence and Java
Object durability, or persistence, is the term you often hear used in conjunction with the issue of storing objects in databases. Persistence is expected to operate with transactional integrity, and as such it is subject to strict conditions. (See the Resources section of this article for more information on transaction processing.) In contrast, language services offered through standard language libraries and packages are often free from transactional constraints.
As we'll see in this article, evidence suggests that simple Java persistence will likely stem from the language itself, while sophisticated database functionality will be offered by database vendors.
No object is an island
In the real world, you rarely find an object that lacks relations to other objects. Objects are components of object models. The issue of object durability transcends the issue of object model durability and distribution once we make the observation that objects are interconnected by virtue of their relations to one another.
The relational approach to data storage tends to aggregate data by type. Rows in a table represent the physical aggregate of objects of the same type on disk. The relationships among objects are then represented by keys that are shared across many tables. Although through database organization, relational databases sometimes allow tables that are likely to be used together to be co-located (or clustered) in the same logical partition, such as a database segment, they have no mechanism to store object relationships in the database.Hence, in order to construct an object model, these relationships are constructed from the existing keys at run time in a process referred to as table joins. This is the same well-known property of the relational databases called data independence. Nearly all variants of object databases offer some mechanism to enhance the performance of a system that involves complex object relationships over traditional relational databases.
To query or to navigate?
In storing objects on disk, we are faced with the choice of co-locating related objects to better accommodate navigational access, or to store objects in table-like collections that aggregate objects by type to facilitate predicate-based access(queries), or both. The co-location of objects in persistent storage is an area where relational and object-oriented databases widely differ. The choice of the query language is another area of consideration. Structured Query Language (SQL) and extensions of it have provided relational systems with a predicate-based access mechanism. Object Query Language (OQL) is an object variant of SQL, standardized by ODMG, but support for this language is currently scant. Polymorphic methods offer unprecedented elegance in constructing a semantic query for a collection of objects. For example, imagine a polymorphic behavior for acccount called isInGoodStanding. It may return the Boolean true for all accounts in good standing, and false otherwise. Now imagine the elegance of querying the collection of accounts, where inGoodStanding is implemented differently based on business rules, for all accounts in good standing. It may look something like:
setOfGoodCustomers= setOfAccounts.query(account.inGoodStanding());
While several of the existing object databases are capable of processing such a query style in C++ and Smalltalk, it is difficult for them to do so for larger (say, 500+ gigabytes) collections and more complex query expressions. Several of the relational database companies, such as Oracle and Informix, will soon offer other, SQL-based syntax to achieve the same result.
Persistence and type
An object-oriented language aficionado would say persistence and type are orthogonal properties of an object; that is, persistent and transient objects of the same type can be identical because one property should not influence the other. The alternative view holds that persistence is a behavior supported only by persistable objects and certain behaviors may apply only to persistent objects. The latter approach calls for methods that instruct persistable objects to store and retrieve themselves from persistent storage, while the former affords the application a seamless view of the entire object model -- often by extending the virtual memory system.
Canonicalization and language independence
Objects of the same type in a language should be stored in persistent storage with the same layout, regardless of the order in which their interfaces appear. The processes of transforming an object layout to this common format are collectively known as canonicalization of object representation. In compiled languages with static typing (not Java) objects written in the same language, but compiled under different systems, should be identically represented in persistent storage.
An extension of canonicalization addresses language-independent object representation. If objects can be represented in a language-independent fashion, it will be possible for different representations of the same object to share the same persistent storage.
One mechanism to accomplish this task is to introduce an additional level of indirection through an interface definition language (IDL). Object database interfaces can be made through the IDL and the corresponding data structures. The downside of IDL style bindings is two fold: First, the extra level of indirection always requires an additional level of translation, which impacts the overall performance of the system; second, it limits use of database services that are unique to particular vendors and that might be valuable to application developers.
A similar mechanism is to support object services through an extension of the SQL. Relational database vendors and smaller object/relational vendors are proponents of this approach; however, how successful these companies will be in shaping the framework for object storage remains to be seen.
But the question remains: Is object persistence part of the object's behavior or is it an external service offered to objects via separate interfaces? How about collections of objects and methods for querying them? Relational, extended relational,and object/relational approaches tend to advocate a separation between language, while object databases -- and the Java language itself -- see persistence as intrinsic to the language.
Native Java persistence via serialization
Object serialization is the Java language-specific mechanism for the storage and retrieval of Java objects and primitives to streams. It is worthy to note that although commercial third-party libraries for serializing C++ objects have been around for some time, C++ has never offered a native mechanism for object serialization. Here's how to use Java's serialization:
// Reading an object from a stream
// Step 1. Create an input stream
FileInputStream in = new FileInputStream("fooFile");
// Step 2. Create an object input stream
ObjectInputStream ins = new ObjectInputStream(in);
// Step 3. Got to know what you are reading
String fooString = (String)ins.readObject();
Foo foo = (Foo)s.readObject();
Object serialization and security
By default, serialization writes and reads non-static and non-transient fields from the stream. This characteristic can be used as a security mechanism by declaring fields that may not be serialized as private transient. If a class may not be serialized at all writeObject and readObjectmethods should be implemented to throw NoAccessException.
Persistence with transactional integrity: Introducing JDBC
Modeled after X/Open's SQL CLI (Client Level Interface) and Microsoft's ODBC abstractions, Java database connectivity (JDBC) aims to provide a database connectivity mechanism that is independent of the underlying database management system (DBMS).To become JDBC-compliant, drivers need to support at least the ANSI SQL-2 entry-level API, which gives third-party tool vendors and applications enough flexibility for database access.
JDBC is designed to be consistent with the rest of the Java system. Vendors are encouraged to write an API that is more strongly typed than ODBC, which affords greater static type-checking at compile time.
Here's a description of the most important JDBC interfaces:
1. java.sql.Driver.Manager handles the loading of drivers and provides support for new database connections.
2. java.sql.Connection represents a connection to a particular database.
3. java.sql.Statement acts as a container for executing an SQL statement on a given connection.
4. java.sql.ResultSet controls access to the result set.
You can implement a JDBC driver in several ways. The simplest would be to build the driver as a bridge to ODBC. This approach is best suited for tools and applications that do not require high performance. A more extensible design would introduce an extra level of indirection to the DBMS server by providing a JDBC network driver that accesses the DBMS server through a published protocol. The most efficient driver, however, would directly access the DBMS proprietary API.
Object databases and Java persistence
A number of ongoing projects in the industry offer Java persistence at the object level. However, as of this writing, Object Design's PSE (Persistent Storage Engine) and PSE Pro are the only fully Java-based, object-oriented database packages available (at least, that I am aware of). Check the Resources section for more information on PSE and PSE Pro.
Java development has led to a departure from the traditional development paradigm for software vendors, most notably in the development process timeline. For example, PSE and PSE Pro are developed in a heterogeneous environment. And because there isn't a linking step in the development process, developers have been able to create various functional components independent of each other, which results in better, more reliable object-oriented code.
PSE Pro has the ability to recover a corrupted database from an aborted transaction caused by system failure. The classes that are responsible for this added functionality are not present in the PSE release. No other differences exist between the two products. These products are what we call "dribbleware" -- software releases that enhance their functionality by plugging in new components. In the not-so-distant future, the concept of purchasing large, monolithic software would become a thing of the past. The new business environment in cyberspace, together with Java computing, enable users to purchase only those parts of the object model (object graph) they need, resulting in more compact end products.
PSE works by post-processing and annotating class files after they have been created by the developer. From PSE's point of view, classes in an object graph are either persistent-capable or persistent-aware. Persistent-capable classes may persist themselves while persistent-aware classes can operate on persistent objects. This distinction is necessary because persistence may not be a desired behavior for certain classes. The class file post-processor makes the following modifications to classes:
1. Modifies the class to inherit from odi.Persistent or odi.util.HashPersistent
2. Defines the initializeContents()method to load real values into hollow instances of your Persistent subclass. ObjectStore provides methods on the GenericObject class that retrieves each Field type.
Be sure to call the correct methods for the fields in your persistent object. A separate method is available for obtaining each type of Field object. ObjectStore calls the initializeContents() method as needed. The method signature is:
n Public void initilazeContects(GenericObject genObj);
3. Defines the flushContents() method to copy values from a modified instance (active persistent object) back to the database. ObjectStore provides methods on the GenericObject
Be sure to call the correct methods for the fields in your persistent object. A separate method is available for setting each type of Field object. ObjectStore calls the flushContents()method as needed. The method signature is:
n Public void flushContents(GenericObject genObj);
4. Defines the clearContents()method to reset the values of an instance to the default values. This method must set all reference fields that referred to persistent objects to null. ObjectStorecalls this method as needed. The method signature is:public void clearContents()
5. Modifies the methods that reference non-static fields to call the