销售官网的设计与实现毕业设计（论文）.doc

大连交通大学信息工程学院毕业设计(论文)任务书题 目 卡西欧销售官网的设计与实现任务及要求：1.设计（研究）内容和要求任务：1、 调查卡西欧销售官网当前技术的发展近况，完成实习报告，字数不少于3000，第三周交给指导老师。2、 结合自己实习情况安排进度，填写进度计划表，第二周完成后交给指导老师签字，并严格执行。3、 按照软件工程思想，独立完成系统的设计和程序开发，完成代码估计2000行左右。4、 用JavaEE技术实现卡西欧销售官网。5、 程序简洁，算法可行，运行情况良好。要求：1、 每周和指导老师至少见面沟通一次，回报课题进展情况，接受老师询问。2、 接到任务书后，查阅与题目及专业相关的外文资料进行翻译，要求不少于10000个外文字符，译出汉字不得少于3000，于第四周交给指导老师审阅。3、 毕业设计第13周完成毕业论文的装订，并由指导老师评阅。论文要求12000字以上，包括综述、系统总体设计、系统实现、性能分析、结论等。4、 教学第13周通过中软及教研室组织进行软件验收，验收时要提供软件使用说明书。5、 于第13周提出毕业答辩申请并签字。6、 第14 周答辩，要求制作PPT2.原始依据通过大学几年的学习，已经学习了诸如软件工程、数据库原理及应用、数据结构、java、jsp、编译原理等多门程序设计语言及基础知识和专业知识，学生有能力而且可以独立完成中小型项目的设计与开发。学校现有设备和环境可以提供给学生实习和上机，而且具有专业老师可以指导学生。3. 参考文献1 张跃平.耿祥义.JSP实用教程.北京：清华大学出版社.2004 2 AnilDesai. SQL Server 2000备份与还原.北京：清华大学出版社.20033 王诚梅.JSP案例开发集锦.沈阳：电了工业出版社.20054 余金山.SQLServer2000编程指南M.北京：北京希望电子出版社.2001 5 孙卫琴.李洪成.Tomcat与Java Web开发技术详解.上海：电子工业出版社.20056 甘早斌.电子商务概论.上海：华东科技大学出版社.20047 陈学平.电子商务网站建设与全程实例.上海：科学出版社.20058 Hans Bergsten. Java Server Pages.广州：中国电力出版社.20049 罗国庆.陈良萍.网站建设案例精粹.大连：电了工业出版社.200410 陆永祯.段慧坤.周芸编著.SQL Sever 2000数据库开发.北京：中国铁道出版社.2005 11 Sun ApplicationProgramming With JavaTechnology M.2001.8指导教师签字：教研室主任签字： 2012年3月26日大连交通大学信息工程学院毕业设计(论文)进度计划与考核表学生姓名李心愉专业班级软件工程08-1班指导教师常敬岩史原本课题其他人员无题目卡西欧销售官方的设计与实现日期计划完成内容完成情况指导老师检查签字第1周完成任务书、提交进度表第2周完成毕业设计封面及摘要、调研设计封面第3周完成调研报告、完成毕设外文翻译第4周系统需求分析阶段及系统总体设计阶段第5周系统详细设计阶段第6周系统实现阶段、完成论文初稿第7周完成系统编码实施第8周系统编码调试、提交论文初稿第9周完成系统编码调试、完善毕业论文第10周完成毕业设计论文编写及代码测试第11周完成最终毕业论文、准备毕业论文打印、装订第12周提交毕业论文及代码第13周提交毕业论文成果资料第14周毕业论文答辩指导教师签字： 年月日注：“计划完成内容”由学生本人认真填写，其它由指导教师考核时填写。大连交通大学信息工程学院毕业设计(论文)调研报告学生姓名 李心愉 专业班级 软件工程08-1班指导教师 常敬岩 史原 职 称 高工 讲师 所在单位 信息科学系软件工程教研室 教研室主任 刘瑞杰 完成日期 2012年 4月6日实习报告1 课题来源及意义随着信息技术的发展，网络的普及，网上购物受到越来越多的人的青睐，而网上购物的便捷性，安全性，是否人性化成为了网上购物系统的发展目标。本次课题旨在开发满足一定安全性且使用更加便捷，用户操作更加人性化的网上商城系统。网络在各行各业的发展战略中占据了重要的位置，成为商家不可分割的部分。商品的宣传已不只局限于电视和报纸，网络也成为商家展示自己的另一个舞台。商家建立网站，将商家各方面的宣传与服务展现于网络中，通过网络更可实现如网上购物、信息查询等功能，这些在改变我们原有经营方式与经营理念的同时，也为商家带来了更高的效益。因为对于商家来说，拥有一个属于自己的网站是至关重要的。系统主要为用户提供了用户注册，购物车管理，商品搜索，用户资料修改等功能，为管理员提供了用户信息管理，类别管理，商品管理，订单管理等功能。2 国内外现状为了推动中国电子商务的发展，互联网研究与发展中心（CII）对电子商务指数作了测算，2008年8月8日在京发布的报告中显示： 2008年CII中国电子商务总指数为51.91，目前中国电子商务尚处于起步阶段，其中电子商务安全指数值最高，反映出我国近年来对信息安全基础建设方面比较重视；而电子商务人力资本指数值最低，反映了电子商务从业人员的素质不是很高，还不能满足电子商务的快速发展；技术与应用发展不平衡：（1）从交易额看，中国电子商务交易金额少，在社会商品零售额中尚未形成规模，不是交易的主流；（2）开展电子商务基础设施仍较差；（3）从交易内容看，交易主要限于书籍、光盘、计算机及相关产品、信息咨询服务等，传统产品少、实物性商品交易比重较低；（4）从付款方式看，主要是货到付款方式，即以网下付款为主；（5）从用户满意度看，对基础设施、交易品种、结算方式、货物佩松、信誉程度等方面，总体评价还是不很满意；（6）从政策环境看，对于我国电信资费、投资融资、安全保障、法律法规等方面的满意程度不是很高。测算结果还显示，电子商务比传统交易方式节省11.61%的费用和19.34%的时间。北京、广东和上海为中国电子商务三强。据悉，这是我国第一份独立于政府和企业的第三方电子商务指数报告，今后还将定期予以发布。尽管在最近五年内，中国网购市场每年都保持了100%左右的增长速度,但与网络购物发达的国家和地区相比，还有不少差距。淘宝网、易趣网和拍拍网等主要服务商，都推出了比传统零售市场更为苛刻的“无条件退换货”等消费者保障计划，希望提高买家的购物信心。 以2010年为例，据统计，中国网购人数在互联网用户中的占比只有42%，而美国已经达到94%，最高的韩国，更是高达99%。又比如网络购物在整个零售市场的比重，中国也远远落后于发达国家、地区。以2010年为例，中国网络购物在整个零售市场的比重，只有0.63%，而美国已经超过3.72%，是中国的5.9倍；韩国更是高达8.65%，是中国的13.7倍。3 本课题的研究目标Internet的发展，为改变传统的商业运作模式提供了一种技术上的可行性的方案：利用Internet的技术和协议，建立各种企业内部网Intranet，企业外部网Extranet，通过廉价的通讯手段，将买家与卖家、厂商和合作伙伴紧密结合在了一起，消除时间与空间带来的障碍，从而大大的节约了交易成本，扩大了交易范围。而在实际的生活中，这种方案已经被广泛的运用到了实际的商业活动中了。并且在实现网上商城系统时，会牵扯到许多技术上的问题，如：动态网页制作技术的，后台数据库的设计和管理，通过实际的制作网站，可以避免纸上谈兵，从而提高自己的编程水平。在设计方面，系统采用基于B/S模式下的三层体系结构，同时使用JSP技术进行动态页面的设计，从系统的安全性和代码的可重用性方面考虑，运用JavaBean对程序的关键代码进行封装，后台数据库选用MySQL数据库。4 研究内容卡西欧销售官方主要显示出已有商品，方便用户在网上选购自己需要的商品，以及确定订单后给出联系方式便于第三方将商品邮寄。用户可以通过该网站浏览商品，并对自己所选商品（即购物车中商品）进行修改、删除等相关操作。卡西欧销售官方的具体实现有以下内容： （1） 未注册的用户必须先注册，经过系统验证身份合格，才能注册成功。（2） 已注册的用户须先登录，经过用户名和密码的核实，方可进入系统。（3） 用户成功进入系统后，首先进入商品列表界面。界面中有所列举的商品。用户选定自己所需商品，点击购买按钮。界面跳转到设置所选商品数量界面，即设置你想买商品的数量。设置完毕后点击确认按钮，系统会将你所选商品放入购物车中，以及购买商品数量也一并在购物车中显示。购物车中还有修改数量按钮。如果想继续购物，可点击继续购物超链接，返回商品列表界面。如果购物完成，点击前台结账按钮进入前台结账界面。在此界面中，你必须填写你的真实联系方式，以便用户能准确收到购买的商品。成功填写后，会转入最后一个确定界面，一旦点击确定按钮，系统后台就会记下用户的联系方式，商品会即时发出。（4） 整个系统具体实现就此结束。5 可行性分析管理可行性分析：只需具备电脑基本操作方法，对于专业要求经短期培训即可；管理基础工作，各项管理制度比较健全，执行严格，原始数据采集完整，保存良好，在管理上具有一定的可行性。经济可行性分析：软硬件结构简单，易于实现，实现后可以为用户带来方便性，为商家带来一定的经济效益，在经济上是可行的。技术可行性分析：硬件方面，输入输出能力，内部存储器和外部存储器的容量都能满足用户的要求；软件方面，有合适的软件开发工具、数据库系统；技术人员方面，只要对操作人员进行简单培训就行。而用户方面，只要用户有可连接网络的电脑，就可以进行简单的购物操作，在技术上是可行的。经以上分析，本系统的开发具有可行性。6 研究方法与系统采用技术开发工具：MyEclipse 8.5系统服务器：Tomcat 6.0数据库： SQL2000数据库。JDK：JDK 1.5开发时用到的技术有：(1)java：是一种高级语言，具有简单、面向对象、分布式、编译、稳健及安全等特性。(2)Servlet：一种服务器端的Java应用程序，主要用于处理各种业务逻辑。 (3)JSP：是由Sun公司倡导、许多公司参与一起建立的一种动态网页技术标准。(4)Html：超文本标记语言或超文本链接标示语言。(5)CSS：层叠样式表。(6)Javascript：是一种比较流行的制作网页特效的脚本语言，由客户端浏览器解释执行。(7)Xml：是一种精简的标准通用化标记语言，作为一种提供数据描述格式的标记语言，它适用于不同应用程序间的数据交换。7 进度安排第1周实习调研，查阅课题相关外文资料第2周了解行业状况、查阅文献资料，阅读资料，撰写调研报告第3周完成10000字符或3000汉字以上的外文翻译资料，准备资料，学习JSP技术第4周进行需求分析第5周进行概要设计第6周进行概要设计, 基本框架完成，提交毕业论文提纲第7周完成后台数据库的设计并编码，完成部分论文第8周完成前台界面的设计并编码，完成部分论文第9周继续编码并进行测试，继续编写毕业设计论文第10周继续进行程序测试，继续编写毕业设计论文第11周整理资料、文档、图表等，修改毕业设计论文第12周完成毕业设计论文，打印，按要求装订第13周软件验收和准备毕业设计答辩第14周毕业设计答辩及成绩评定8 参考文献1 张跃平.耿祥义.JSP实用教程.北京：清华大学出版社.2004 2 AnilDesai. SQL Server 2000备份与还原.北京：清华大学出版社.20033 王诚梅.JSP案例开发集锦.沈阳：电了工业出版社.20054 余金山.SQLServer2000编程指南M.北京：北京希望电子出版社.2001 5 孙卫琴.李洪成.Tomcat与Java Web开发技术详解.上海：电子工业出版社.20056 甘早斌.电子商务概论.上海：华东科技大学出版社.20047 陈学平.电子商务网站建设与全程实例.上海：科学出版社.20058 Hans Bergsten. Java Server Pages.广州：中国电力出版社.20049 罗国庆.陈良萍.网站建设案例精粹.大连：电了工业出版社.200410 陆永祯.段慧坤.周芸编著.SQL Sever 2000数据库开发.北京：中国铁道出版社.2005 11Sun ApplicationProgramming With JavaTechnology M.2001.8大连交通大学信息工程学院毕业设计(论文)外文翻译学生姓名 李心愉 专业班级 软件工程08-1班指导教师 常敬岩 史原 职 称 高工 讲师 所在单位 信息科学系软件工程教研室 教研室主任 刘瑞杰 完成日期 2012年 4月13日 Concurrent Programming in Java: Design Principles and Patterns, Second EditionIn a safe system, every object protects itself from integrity violations. This sometimes requires the cooperation of other objects and their methods.Exclusion techniques preserve object invariants and avoid effects that would result from acting upon even momentarily inconsistent state representations. Programming techniques and design patterns achieve exclusion by preventing multiple threads from concurrently modifying or acting upon object representations. All approaches rely on one or more of three basic strategies:Eliminating the need for some or all exclusion control by ensuring that methods never modify an object's representation, so that the object cannot enter inconsistent states.Dynamically ensuring that only one thread at a time can access object state, by protecting objects with locks and related constructs.Structurally ensuring that only one thread (or only one thread at a time) can ever use a given object, by hiding or restricting access to it.The first three sections of this chapter describe the central features and usage patterns surrounding each of these approaches immutability, synchronization, and confinement. discusses some ways to combine these different approaches to improve safety, liveness, performance, and/or semantic guarantees. The mandatory use of these techniques represents an important difference between sequential and concurrent programming practices. To guarantee safety in a concurrent system, you must ensure that all objects accessible from multiple threads either are immutable or employ appropriate synchronization, and also must ensure that no other object ever becomes concurrently accessible by leaking out of its ownership domain. While the techniques that help maintain these guarantees are in many ways just extensions of other development practices, concurrent programs are typically less tolerant of error.As discussed in most of these matters cannot by nature be enforced by compilers or run-time systems. Analysis and testing tools may be helpful in detecting some kinds of failure, but the main responsibility for ensuring the safety of each class, component, subsystem, application, and system falls on its developers. Additionally, exclusion-related policies and design rules must be explicit and well advertised.Much caution is needed when using code that was not designed to operate in multithreaded environments. Most classes in the java.* packages are designed to be thread-safe when applied in their intended usage contexts. (Some exceptions are noted as they arise in this book. Other limitations appear in class API documentation.) However, when constructing multithreaded applications, it is often necessary to rework or wrap your own classes and packages that were originally designed only for use in single-threaded contexts.If an object cannot change state, then it can never encounter conflicts or inconsistencies when multiple activities attempt to change its state in incompatible ways.Programs are much simpler to understand if existing objects are never changed, but instead new ones are continually created during the course of any computation. Unfortunately, such programs are generally unable to handle interaction via user interfaces, cooperating threads, and so on. However, selective use of immutability is a basic tool in concurrent programming.The simplest immutable objects have no internal fields at all. Their methods are intrinsically stateless they do not rely on any assignable fields of any object. For example, all possible uses of the following StatelessAdder class and its add method are obviously always safe and live:The same safety and liveness properties hold in classes possessing only final fields. Instances of immutable classes cannot experience low-level read-write or write-write conflicts, because values are never written. And as long as their initial values are established in a consistent, legal fashion, these objects cannot experience higher-level invariant failures. It is of course possible to create immutable objects that contain more interesting structure and functionality than seen in ImmutableAdder. Applications include abstract data types, value containers, and shared state representations.Immutable objects can serve as instances of simple abstract data types representing values. Some common ones are already defined in the java.* packages. These include java.awt.Color, java.lang.Integer, java.math.BigDecimal, java.lang.String, and others. It is easy to define your own ADT classes, for example, Fraction, Interval, ComplexFloat, and so on. Instances of such classes never alter their constructed field values, but may provide methods that create objects representing new values. Classes that represent immutable data abstractions have instances that serve only to encapsulate values, so their identities are not important. For example, two java.awt.Color objects that both represent black (via RGB value 0) are typically intended to be treated as equivalent. This is one reason why ADT-style classes should normally override methods Object.equals and Object.hashCode to reflect equality of abstract value, as illustrated in the Fraction class. The default implementations of these methods rely on the identities of objects maintaining these values. Masking identity by overriding equals enables multiple ADT objects to represent the same values and/or perform the same functionality without clients needing to know or care exactly which ADT object is being used at any given time.You don't always have to commit to immutable representations of ADTs across an entire program. It is sometimes helpful to define different classes, supporting different usages, for the immutable versus updatable versions of some concept. For example, class java.lang.String is immutable, while class java.lang.StringBuffer is updatable, relying on synchronized methods.Immutable objects can be used when it is necessary or convenient to establish some consistent state once and then rely on it forever more. For example, an immutable ProgramConfiguration object may reflect all of the settings to be used during the execution of a given program.Immutable value containers can also be useful whenever creating different variants, versions, or states of an object by creating new ones through partial copying is relatively rare or cheap. In these cases, the expense of copying may be outweighed by the benefits of never needing to synchronize state changes. The analog of a state change for an immutable object is to produce a new immutable object that differs from the original in some specified way.Immutability is a useful technical device when you would like to share objects for space efficiency, and still provide efficient access to these objects. One immutable object can be referenced by any number of other objects without concern for synchronization or access restriction. For example, many individual character (or glyph) objects may all share references to the same immutable font object. This is one application of the Flyweight pattern described in the Design Patterns book. Most Flyweights designs are simplest to establish by ensuring the immutability of shared representations.Instances of many utility classes used in concurrent settings are intrinsically immutable and are shared by many other objects. While purely immutable objects are simple, convenient, prevalent, and useful, many concurrent OO programs also rely on partial immutability constancy for only some fields, or only after execution of a particular method, or only over some period of interest. Exploitation of immutability is a useful strategy for producing designs that would be difficult at best to realize using updatable objects. A number of such designs are presented in the course of this book, especially。To be effective, all design decisions relying on immutability must be enforced via appropriate use of the final keyword. Additionally, some care is required when initializing immutable objects. In particular, it is counterproductive to make an immutable object available to others before it has been fully initialized. As a general rule holding for any kind of class:Do not allow fields to be accessed until construction is complete.This can be harder to ensure in concurrent settings than in sequential programs. Constructors should perform only actions directly related to field initialization. They should not invoke any other methods whose effects may rely on the object being fully constructed. Constructors should avoid recording a reference to the object being constructed in fields or tables accessible by others, avoid making calls to other methods with this as an argument, and more generally, avoid allowing the reference to this to escape. Without such precautio