项目实践精解：基于Struts-Spring-Hibernate的Java应用开发.docx

《项目实践精解：基于Struts-Spring-Hibernate的Java应用开发.docx》由会员分享，可在线阅读，更多相关《项目实践精解：基于Struts-Spring-Hibernate的Java应用开发.docx（109页珍藏版）》请在三一办公上搜索。

1、目前，国内外信息化建设已经进入以Web应用为基础核心的阶段。Java语言应该算得上是开发Web应用的最佳语言。然而，就算用Java建造一个不是很烦琐的Web应用系统，也不是件轻松的事情。有很多东西需要仔细考虑，比如要考虑怎样建立用户接口？在哪里处理业务逻辑？怎样持久化数据？而这3层构架中，每一层都有各自要仔细考虑的内容，比如各个层该使用什么技术？怎样的设计既能松散耦合还能灵活改变？怎样替换某个层而不影响整体构架？应用程序如何做各个方面的处理（例如，事务处理）？幸运的是，构架一个Web应用需要解决的一些问题已经由曾遇到过这类问题的开发者建立起处理这类问题的框架（Framework）。一个好框架应

2、具备以下几点：减轻开发者处理复杂问题的负担，具有良好的可扩展性，并且有一个支持它的强大的用户团体。好的框架一般有针对性地处理某一类问题，并且能将它做好（Do One Thing Well），好的框架还应该能指导代码如何分布。更重要的是，框架能把开发者从底层编码中解放出来，使他们能专心于应用程序的逻辑。本书将讨论怎样结合3种著名的框架Struts、Spring和Hibernate来使你的应用程序做到松散耦合。如何建立你的架构，并且怎样让你的各个应用层保持一致？如何整合框架，以便让每层以一种松散耦合的方式彼此作用而不用管底层的技术细节？这里讨论一个使用3种开源框架的策略：表示层用Struts，业务

3、层用Spring，而持久层则用Hibernate，如图1-1所示。大部分的Web应用在职责上至少能被分成4层：表示层（Presentation Layer）、持久层（Persistence Layer）、业务层（Business Layer）和域模块层（domain model Layer）。每个层在功能上都应该是十分明确的，而不应该与其他层混合。每个层要相互独立，通过一个通信接口而相互联系。下面将分别详细地介绍这4层，讨论一下这些层应该提供什么，不应该提供什么。1.1 表示层一般来讲，一个典型的Web应用的前端应该是表示层，这里可以使用Struts框架。下面是Struts所负责的： 管理用户

4、的请求，做出相应的响应 提供一个流程控制器，委派调用业务逻辑和其他上层处理 处理异常 为显示提供一个数据模型 用户界面的验证以下内容，不该在Struts表示层的编码中经常出现，它们与表示层无关的。 与数据库直接通信 与应用程序相关联的业务逻辑及校验 事务处理在表示层引入这些代码，则会带来高耦合和难以维护的后果。典型的Web应用的后端是持久层。开发者总是低估构建他们自己的持久层框架的挑战性。系统内部的持久层不但需要大量调试时间，而且还经常因为缺少功能使之变得难以控制，这是持久层的通病。幸运的是，有几个对象/关系映射（Object/Relation Mapping，ORM）开源框架很好地解决了这类

5、问题，尤其是Hibernate。Hibernate为Java提供了持久化机制和查询服务，它还给已经熟悉SQL和JDBC API的Java开发者创造了一个学习桥梁，使他们学习起来很方便。Hibernate的持久对象是基于POJO（Plain Old Java Object）和Java集合（collections）的。此外，使用Hibernate并不妨碍你正在使用的IDE（Integrated Development Enviroment）。下面是Hibernate所负责的内容。 如何查询对象的相关信息。Hibernate是通过一个面向对象的查询语言（HQL）或正则表达的API来完成查询的。HQL

6、非常类似于SQL，只是把SQL里的table和columns用Object和它的fields代替。HQL语言容易理解且文档做得很好。HQL是一种面向对象查询的自然语言，很容易就能学会它。 如何存储、更新、删除数据库记录。 Hibernate这类的高级ORM框架支持大部分主流数据库，并且支持父表/子表（Parent/ child）关系、事务处理、继承和多态。一个典型Web应用的中间部分是业务层或服务层。从编码的视角来看，这层是最容易被忽视的。我们往往在用户界面层或持久层周围看到这些业务处理的代码，这其实是不正确的。因为它会造成程序代码的高耦合，这样一来，随着时间推移，这些代码将很难维护。幸好，针

7、对这一问题有几种框架（Framework）存在，最受欢迎的两个框架是Spring和PicoContainer。这些也被称为轻量级容器（micro container），它们能让你很好地把对象搭配起来。这两个框架都着手于“依赖注射”（dependency injection），还有我们知道的“控制反转”（Inversion of Control，IoC）这样的简单概念。这里，我们将关注于Spring的依赖注射和面向方面编程。另外，Spring把程序中所涉及到的包含业务逻辑和数据存取对象（DataAccess Object）的Objectstransaction management handle

8、r（事务管理控制）、Object Factories（对象工厂）、service objects（服务组件）都通过XML配置联系起来。后面我们会通过项目和实例来揭示Spring是怎样运用这些概念的。下面是业务层所负责的。 处理应用程序的业务逻辑和业务校验 管理事务 提供与其他层相互作用的接口 管理业务层级别的对象的依赖 在表示层和持久层之间增加了一个灵活的机制，使得他们不直接联系在一起 通过揭示从表示层到业务层之间的上下文（Context）来得到业务逻辑（business services） 管理程序的执行（从业务层到持久层）既然我们致力于一个Web的应用，我们就需要一个对象集合，让它在不同层

9、之间移动。域模块层由实际需求中的业务对象组成，比如订单明细（OrderLineItem）、产品（Product）等。开发者在这层不用管那些数据传输对象（Data Transfer Object），而仅关注域对象（domain object）即可。例如，Hibernate允许你将数据库中的信息存入域对象（domain objects），这样你可以在连接断开的情况下把这些数据显示到用户界面层，而那些对象也可以返回给持久层，从而在数据库里更新。而且，你不必把对象转化成DTO（这可能导致它在不同层之间的传输过程中丢失）。这个模型使得Java开发者能很自然运用面向对象编程（Object-Oriented

10、 Programming），而不需要附加的编码。本书围绕上述架构，通过一个完整的项目online bookstore来具体展开Struts-Spring- Hibernate这3部分的讲解。项目开发并不是一个简单的过程，我们需要遵循一些开发流程。一个项目的开发会被分成很多步骤来实现，每一个步骤都有自己的起点和终点。也正如此，使得开发过程中的每个步骤起点和终点在不同的软件项目中出现不同难度的“坎”，使其难于达到该步骤开始或是终结的条件，开发过程也就不会一帆风顺。不同的开发模式其实就是将步骤的起点和终点重新定义，甚至重新组合排列，虽然任何一个开发模式最终目的都是完成软件项目的开发，但期间所经历的过

11、程不一样，过程步骤之间的起点和终点的定义不同，所带来的“坎”也就不一样，项目周期自然各不相同。因此，根据软件项目的实际情况选择一个适合的开发模式能减少开发周期中“坎”的出现次数与难度，可以很大程度地缩短开发周期。我们首先了解一下传统瀑布式开发流程，如图2-1所示。图2-1 瀑布式（Waterfall）开发流程瀑布模型是由W.W.Royce在1970年首先提出的软件开发模型，在瀑布模型中，开发被认为是按照需求分析、设计、实现、测试（确认）、集成和维护坚定而顺畅地进行的。线性模型太理想化，太单纯，以至很多人认为瀑布模型已不再适合现代的软件开发模式，几乎被业界抛弃。 我们向大家推荐的是统一开发流程R

12、UP（Rational Unified Process），它是目前最流行的一套项目开发流程模式，其基本特征是通过多次迭代完成一个项目的开发，每次迭代都会带来项目整体的递增，如图2-2所示。从纵向来看，项目的生命周期或工作流包括项目需求分析、系统分析和设计、实现、测试和维护。从横向来看，项目开发可以分为4个阶段：起始（Inception）、细化（Elaboration）、建造（Construction）和移交（transition）。每个阶段都包括一次或者多次的迭代。在每次迭代中，根据不同的要求或工作流（如需求、分析和设计等）投入不同的工作量。也就是说，在不同阶段的每次迭代中，生命周期的每个步骤

13、是同步进行的，但权重不同。这是与传统瀑布式开发流程区别最大的地方。2.1.1 项目生命周期1项目需求分析需求分析阶段的活动包括定义潜在的角色（角色指使用系统的人，以及与系统相互作用的软、硬件环境）、识别问题域中的对象和关系，以及基于需求规范说明和角色的需要发现用例（use-case）和详细描述用例。2系统分析和设计系统分析阶段是基于问题和用户需求的描述，建立现实世界的计算机实现模型。系统设计是结合问题域的知识和目标系统的体系结构（求解域），将目标系统分解为子系统，之后基于分析模型添加细节，完成系统设计。3实现实现又称编码或开发阶段，也就是将设计转换为特定的编程语言或硬件，同时保持先进性、灵活性

14、和可扩展性。在这个阶段，设计阶段的类被转换为使用面向对象编程语言编制（不推荐使用过程语言）的实际代码。这一任务可能比较困难，也可能比较容易，主要取决于所使用的编程语言本身的能力。4测试和维护测试用于检验系统是否满足用户功能需求，以便增加用户对系统的信心。系统经过测试后，整个开发流程告一段落，进入运行维护或新的功能扩展时期。2.1.2 项目开发阶段1起始阶段（The Inception Phase）对于新的开发项目来说，起始阶段是很重要的。在项目继续进行前，我们必须处理重要的业务与需求风险。对于那些增强现有系统的项目，起始阶段是比较短暂的，但是其目的仍是确定该项目的实施价值及可行性。起始阶段有4

15、个重要活动。 制定项目的范围 计划并准备业务案例 综合分析，得出备选构架 准备项目环境2细化阶段（The Elaboration Phase）细化阶段的目标是为系统构架设立基线（baseline），为在构建阶段开展的大量的设计与实施工作打下坚实的基础。构架是通过考虑最重要的需求与评估风险演进而来的，构架的稳定性是通过一个或多个构架原型（prototype）进行评估的。3构建阶段（The Construction Phase）构建阶段的目标是完成系统开发。构建阶段从某种意义上来看是一个制造过程，其中，重点工作就是管理资源、控制操作，以优化成本、日程和质量。因此，在此阶段，管理理念应该进行一个转换

16、，从起始阶段和细化阶段的知识产品开发转换到构建和交付阶段的部署产品的开发。构建阶段的每次迭代都具有3个关键活动。 管理资源与控制过程 开发与测试组件 对迭代进行评估4交付阶段（The Transition Phase）交付阶段的焦点就是确保软件对于最终用户是可用的。交付阶段包括为发布应用而进行的产品测试，在用户反馈的基础上做微小的调整等内容。在生命周期的这个时刻，用户反馈主要集中在精确调整产品、配置、安装，以及可用性等问题上。交付阶段的关键活动如下： 确定最终用户支持资料 在用户的环境中测试可交付的产品 基于用户反馈精确调整产品 向最终用户交付最终产品最后，作为补充，我们再简单介绍一种新的开发

17、流程：敏捷开发和极限编程。2001年，为了解决许多公司的软件团队陷入不断增长的过程泥潭的问题，一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟。敏捷开发过程的方法很多，主要有SCRUM、Crystal、特征驱动软件开发（Feature Driven Development，简称FDD）、自适应软件开发(Adaptive Software Development，简称ASD)，以及最重要的极限编程(eXtreme Programming,简称XP)。极限编程是一套能快速开发高质量软件所需的价值观、原则和活动的集合，使软件能以尽可能快的速

18、度开发出来并向客户提供最高的效益。XP在很多方面都和传统意义上的软件工程不同，同时，它也和传统得管理和项目计划得方法不同。这些方法在软件工程和其他管理活动中都有借鉴意义。 XP具有12个过程，只有完全使用12个过程才是真正使用了XP，只是简单使用了其中一个方法并不代表使用了XP。XP的12个过程如下。 现场客户（On-site Customer） 计划博弈（Planning Game） 系统隐喻（System Design） 简化设计（Simple Design） 集体拥有代码（Collective Code Ownership） 结对编程（Pair Programming） 测试驱动（Tes

19、t-driver） 小型发布（Small Release） 重构（Refactoring） 持续集成（Continous integration） 每周40小时工作制（40-hour Weeks） 代码规范（Coding Standards） 下面是极限编程的有效实践。完整团队XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。 计划博弈是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。 客户测试作为选择每

20、个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。 简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。 结对编程所有的产品软件都是由两个程序员并排坐在一起在同一台机器上构建的。 测试驱动开发编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。 改进设计随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净，

21、具有表达力。 持续集成团队总是使系统完整地被集成。一个人拆入（Check in）后，其他所有人负责代码集成。 集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其他方面的开发。 编码标准系统中所有的代码看起来就好像是由一人单独编写的。 隐喻将整个系统联系在一起的全局视图，它是系统的未来影像，使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。 可持续的速度团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑

22、。极限编程是一组简单、具体的实践，这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。UML（Unified Modeling Language）是实现项目开发流程的一个重要工具，它是一套可视化建模语言，由各种图来表达。图就是用来显示各种模型元素符号的实际图形，这些元素经过特定的排列组合来阐明系统的某个特定部分或方面。一般来说，一个系统模型拥有多个不同类型的图，一个图是某个特定视图的一部分。通常，图是被分配给视图来绘制的。另外，根据图中显示的内容，某些图可以是多个不同视图的组成部分。

23、图具体分为静态模型和动态模型两大类。其中，静态模型包括： 用例图（Use-case Diagrams） 类图（Class Diagrams） 对象图（Object Diagrams） 组件图（Component Diagrams） 部署图（Deployment Diagrams）动态模型包括： 序列图（Sequence Diagrams） 协作图（Collaboration Diagrams） 状态图（State Chart Diagrams） 行为图（Activity Diagrams）2.2.1 用例图用例图（Use-case Diagram）显示多个外部参与者，以及他们与系统之间的交互和

24、连接，如图2-3所示。一个用例是对系统提供的某个功能（该系统的一个特定用法）的描述。虽然实际的用例通常用普通文本来描述，但是也可以利用一个活动图来描述用例。用例仅仅描述系统参与者从外部通过对系统的观察而得到的那些功能，并不描述这些功能在系统内部是如何实现的。也就是说，用例定义系统的功能需求。图2-3 一个超市系统的用例图2.2.2 类图类图（Class Diagram）用来显示系统中各个类的静态结构，如图2-4所示。类代表系统内处理的事物。这些类可以以多种方式相互连接在一起，包括关联（类互相连接）、依赖（一个类依赖/使用另一个类）、特殊化（一个类是另一个类的特化）或者打包（多个类组合为一个单元

25、）。所有的这些关系连同每个类的内部结构都在类图中显示。其中，一个类的内部结构是用该类的属性和操作表示的。因为类图所描述的结构在系统生命周期的任何一处都是有效的，所以通常认为类图是静态的。图2-4 旅馆系统的类图我们常常会使用特殊化（Specialize）、一般化（Generalize）、特化（Specialization）和泛化（Generalization）这几个术语来描述两个类之间的关系。例如，对于一个类A（即父类）派生出另一个类B（即子类）这样一个过程，也常常这样描述：类A可以特殊化为类B，而类B可以一般化为类A；或者类A是类B的泛化，而类B是类A的特化。一个系统一般都有多个类图并不是所

26、有的类都放在一个类图中并且一个类可以参与到多个类图中。2.2.3 对象图对象图（Object Diagram）是类图的一个变体，它使用的符号与类图几乎一样。对象图和类图之间的区别是：对象图用于显示类的多个对象实例，而不是实际的类。所以，对象图就是类图的一个实例，显示系统执行时的一个可能的快照在某一时间点上系统可能呈现的样子。虽然对象图使用与类图相同的符号，但是有两处例外：用带下划线的对象名称来表示对象和显示一个关系中的所有实例，如图2-5所示。图2-5 显示类的类图和显示类的实例的对象图虽然对象图没有类图那么重要，但是它们可以用于为一个复杂类图提供示例，以显示实际和关系可能的样子。另外，对象图

27、也可被作为协作图的一部分，用于显示一群对象之间的动态协作关系。2.2.4 状态图一般来说，状态图（State Diagram）是对类的描述的补充。它用于显示类的对象可能具备的所有状态，以及那些引起状态改变的事件，如图2-6所示。对象的一个事件可以是另一个对象向其发送的消息，例如到了某个指定的时刻，或者已经满足了某条件。状态的变化称之为转换（Transition）。一个转换也可以有一个与之相连的动作，后者用以指定完成该状态转换应该执行的操作。在实际建模时，并不需要为所有的类都绘制状态图，仅对那些具有多个明确状态的类，并且类的这些不同状态会影响和改变类的行为才绘制类的状态图。另外，也可以为系统绘制

28、整体状态图。图2-6 电梯系统的状态图2.2.5 序列图序列图（Sequence Diagram）显示多个对象之间的动态协作，如图2-7所示。序列图重点是显示对象之间发送的消息的时间顺序。它也显示对象之间的交互，也就是在系统执行时，某个指定时间点将发生的事情。序列图由多个用垂直线显示的对象组成，图2-7中时间从上到下推移，并且序列图显示对象之间随着时间的推移而交换的消息或函数。消息是用带消息箭头的直线表示的，并且它位于垂直对象线之间。时间说明以及其他注释放到一个脚本中，并将其放置在顺序图的页边空白处。图2-7 打印服务器的序列图2.2.6 协作图协作图（Collaboration Diagra

29、m）像顺序图一样显示动态协作。为了显示一个协作，通常需要在顺序图和协作图之间做选择。除了显示消息的交换（称之为交互）以外，协作图也显示对象以及它们之间的关系（上下文）。通常，选择序列图还是协作图的决定条件是：如果时间或顺序是需要重点强调的方面，那么选择序列图；如果上下文是需要重点强调的方面，那么选择协作图。序列图和协作图都用于显示对象之间的交互。协作图可当做一个对象图来绘制，它显示多个对象以及它们之间的关系（利用类/对象图中的符号来绘制），如图2-8所示。协作图中对象之间绘制的箭头显示对象之间的消息流向。图2-8中的消息上放置标签，用于显示消息发送的顺序。协作图也可以显示条件、迭代和返回值等信

30、息。当开发人员熟悉消息标签语法之后，就可以读懂对象之间的协作，以及跟踪执行流程和消息交换顺序。协作图也可以包括活动对象，这些活动对象可以与其他活动对象并发地执行。图2-8 打印服务器的协作图2.2.7 活动图活动图（Activity Diagram）用于显示一系列顺序的活动，如图2-9所示。尽管活动图也可以用于描述像用例或交互这类的活动流程，但是一般来说，它主要还是用于描述在一个操作内执行的那些活动。活动图由多个动作状态组成，后者包含将被执行的活动（即一个动作）的规格说明。当动作完成后，动作状态将会改变，转换为一个新的状态（在状态图内，状态在进行转换之前需要标明显式的事件）。于是，控制就在这些

31、互相连接的动作状态之间流动。同时，在活动图中也可以显示决策和条件，以及动作状态的并发执行。另外，活动图也可以包含那些被发送或接收的消息的规格说明，这些消息是被执行动作的一部分。图2-9 打印服务器的活动图2.2.8 组件图组件图是用代码组件来显示代码物理结构的。其中，组件可以是源代码组件、二进制组件或一个可执行的组件。因为一个组件包含它所实现的一个或多个逻辑类的相关信息，于是就创建了一个从逻辑视图到组件视图的映射。根据组件图中显示的那些组件之间的依赖关系，可以很容易地分析出其中某个组件的变化将会对其他组件产生什么样的影响。另外，组件也可以用它们输出的任意的接口来表示，并且它们可以被聚集在包内。

32、一般来说，组件图用于实际的编程工作中，如图2-10所示。图2-10 显示代码组件之间依赖关系的组件图2.2.9 部署图部署图（Deployment Diagram）用于显示系统中的硬件和软件的物理结构。这些部署图可以显示实际的计算机和设备（节点），同时还有它们之间的必要连接，也可以显示这些连接的类型，如图2-11所示。在图中显示的那些节点内，已经分配了可执行的组件和对象，以显示这些软件单元分别在哪个节点上运行。另外，部署图也可以显示组件之间的依赖关系。图2-11 系统物理结构的部署图正如前面所说的那样，显示部署视图的部署图描述系统的实际物理结构，这与用例视图的功能描述完全不同。但是，对一个明确

33、定义的模型来说，可以实现从头到尾的完整导航：从物理结构中的一个节点导航到分配给该节点的组件，再到该组件实现的类，接着到该类的对象参与的交互，最终到达用例。系统的不同视图在总体上给系统一个一致的描述。3.1 项目需求分析网上购书系统由3部分组成：用户管理、购书网站和订单处理中心。其中，用户管理负责用户注册及用户登录；购书网站是一个Web应用程序，用户可以通过Web浏览器登录到此网站，在此网站，用户可以搜索要找的书，查看书的详细信息并购书（将书加入购物车）；订单处理中心用来管理购物网站转过来的订单，如图3-1所示。用户管理主要包括以下功能模块。 注册用户信息 对于新用户，单击“注册”按钮，进入用户

34、注册页面； 填写相关注册信息，*为必填项；填写完成后单击“确定”按钮； 弹出“注册成功”对话框，即成功注册。 用户登录验证 对于已注册的用户，进入用户登录页面，如图3-2所示； 填写您的用户名和密码； 单击“登录”按钮； 用户名和密码正确，登录成功，进入购书网站。图3-2 用户登录页面购书网站主要包括以下功能模块： 浏览图书网站的书籍列表要列出当前网站所有的图书名称，如图3-3所示。当用户单击某一图书名称时，要列出该书的详细信息（包括书名、作者、单价）。图3-3 浏览图书页面 查找图书用户可以在网站的查找框中输入一个书名，单击“查找”按钮可以查看网站是否有此书，系统将查找结果（如果有此书，返回

35、书的详细信息；如果没有，返回当前没有此书的信息）返回给用户，如图3-4所示。图3-4 查找图书页面 购物车管理用户可以随时查看自己的购物车，可以添加或删除购物车中的商品，如图3-5图3-7所示。图3-5 购物车管理页面图3-6 购物车增加商品页面图3-7 购物车减少商品页面 购书在浏览图书时，用户可以在查看选中图书的详细信息时添加此书到购物车，添加完毕可以选择继续购物或是结算。如果选择结算，要填定一个购书登记表，该表包括以下内容：购书人姓名、地址、E-mail、所购图书的列表、总价，如图3-8所示。订单处理中心的功能：订单处理中心是一个Web应用程序，在此将列出所有等待处理的订单，每一笔订单包

36、含购书人姓名、地址、E-mail、所购图书的列表、总价。其中，所购图书的列表包括各个书籍信息的明细内容，总价是系统自动计算的。图3-8 购书页面系统是由Web服务器、数据服务器和浏览器客户端组成的多层Web计算机服务系统，采用Struts-Spring-Hibernate架构，具用先进性、灵活性、可扩展性等特点。3.2.1 数据库设计（data model）实体关系（Entity-Relationship）图（1）逻辑图（Logic diagram），如图3-9所示。（2）物理图（Physical diagram），如图3-10所示。建立表：book、customer、orderitem和or

37、ders的脚本如下，其对应表结构如表3-1表3-4所示。CREATE TABLE book ( book_id int(11) NOT NULL auto_increment, book_name varchar(100) NOT NULL default , book_author varchar(100) NOT NULL default , book_price double NOT NULL default 0, image varchar(100) NOT NULL default , describe varchar(200) NOT NULL default , PRIMARY

38、KEY (book_id) CREATE TABLE customer ( customer_id int(11) NOT NULL auto_increment, cust_name varchar(100) NOT NULL default , password varchar(100) NOT NULL default , email varchar(100) NOT NULL default , PRIMARY KEY (customer_id) CREATE TABLE orderitem ( orderItem_id int(11) NOT NULL auto_increment,

39、 quantity int(11) NOT NULL default 0, order_id int(11) NOT NULL default 0, bookid int(11) NOT NULL default 0, PRIMARY KEY (orderItem_id) CREATE TABLE orders ( order_id int(11) NOT NULL auto_increment, cust_id int(11) NOT NULL default 0, totalprice double NOT NULL default 0, PRIMARY KEY (order_id) 表3

40、-1 book（书籍）表结构列 名类 型描 述book_id int(11)表示书籍标识号，是自动递增的主键book_namevarchar(100)表示书籍名字book_authorvarchar(100)表示书籍作者book_pricedouble表示书籍价格imagevarchar(100)表示书籍图片在文件系统中的路径descibevarchar(200)表示书籍描述信息（describe是数据库关键字，这里有意命名为describe）表3-2 Customer（客户）表结构列 名类 型描 述customer_idint(11)表示客户标识号，是自动递增的主键cust_namevarc

41、har(100)表示客户姓名passwordvarchar(100)表示客户登录密码emailvarchar(100)表示客户电子邮件表3-3 Orders（订单）表结构列 名类 型描 述order_idint(11)表示订单标识号，是自动递增的主键cust_idint(11)表示客户标识号totalpricedouble表示订单的总价格表3-4 Orderitem（订单明细）表结构列 名类 型描 述orderItem_idint(11)表示订单明细标识号，是自动递增的主键quantityint(11)表示订单中购买每种书的数量order_idint(11)表示订单标识号bookidint(1

42、1)表示订单中购买每种书的标识号1系统分析我们通过UML语言里的用例图（use-case diagram）、类图（class diagram），以及序列图（sequence diagram）来分析网上书店项目。（1）use-case diagram：项目用例图如图3-11所示。（2）class diagram：用户管理模块类图、图书管理模块类图和订单管理模块类图分别如图3-12、图3-13和图3-14所示。图3-11 项目用例图图3-13 图书管理模块类图图3-14 订单管理模块类图（3）sequence diagram：用户管理模块序列图、图书管理模块序列图和订单管理模块序列图分别如图3-1

43、5、图3-16和图3-17所示。图3-15 用户管理模块序列图图3-16 图书管理模块序列图图3-17 订单管理模块序列图2系统设计系统的整体逻辑结构如图3-18所示。图3-18 项目整体逻辑结构图具体如下。（1）Web应用程序设计本项目中使用了Struts-Spring-Hibernate框架建立购书网站。在Struts框架中，JSP用于前端展现，Servlet用于控制，Action用于处理前端页面JSP发来的请求，请求参数通过ActionForm进行传递，Action在获得请求后通过调度业务系统提供的Spring service bean做处理，最后将处理结果转发到相应的JSP进行展现。W

44、eb应用程序的组织结构可以分为4个部分。 Web应用根目录下放置用于前端展现的JSP文件 com.ascent.struts.action放置处理请求的Action com.ascent.struts.form放置所有的ActionForm com.ascent.struts放置程序中用到的资源文件ApplicationResources.properties下面以组织结构中的4个部分为例，分别进行介绍。JSP文件包括10个文件，表3-5列出了每个JSP文件实现的功能。表3-5 JSP文件列表文件名称功 能index.jsp索引页面，入口界面Login.jsp用户登录页面reg.jsp用户注册

45、页面Listbook.jsp书籍列表页面bookdetail.jsp书籍详细信息页面viewCart.jsp购物车管理页面cartok.jsp购物结算页面checkok.jsp订单处理页面head.jsp页眉模板页面tail.jsp页脚模板页面action包括10个文件，表3-6列出了每个Action的功能。表3-6 Action列表文件名称功 能BaseAction所有Action的父类，同时是服务定位器LoginAction用户登录ActionLogoutAction用户退出ActionRegisterAction用户注册ActionBookQueryAction.java查询指定书籍ActionQueryDetailAction书籍详细信息ActionAddCartAction.java往购物车添加书籍ActionDeleteCartAction.java查看购物车ActionEmptyCartAction.java结算ActionOrderCheckAction.java订单处理Actionform包括5个文件，表3-7列出了每个ActionForm的功能。表3-7 ActionForm列表文件名称功 能LoginForm表示用户登录数据RegisterForm表示用户注册数据BookQueryForm.java表示