商务中心管理子系统毕业设计 .doc

目 录商务中心管理子系统毕业设计目 录摘 要IAbstractII引 言1第一章 Open Source21.1开源软件简介21.2 项目中开源软件介绍31.2.1 Struts31.2.2 Hibernate31.2.3 Eclipse41.2.4 Cewolf Web 动态报表41.2.5 Junit41.2.6 StrutsTestCase41.2.7 Jmetter41.2.8 JBoss5第二章 需求分析62.1 系统功能定义62.2 基于RUP构建管理子系统8第三章 构建用例模型93.1 识别角色93.2 识别用例93.3 管理子系统性能需求103.4 角色与用例的交互113.5 细化用例123.5.1 用例1 管理员登陆123.5.2 用例2 商家管理133.5.3 用例3 用户管理133.5.4 用例4 公告栏管理163.5.5 用例5 报表统计183.5.6 用例6 访问量统计193.5.7 用例7 管理员管理193.5.8 用例8 管理员登出20第四章 架构分析214.1 MVC 架构214.2 管理子系统架构分析224.3 面向接口编程24第五章 用户体验模型265.1 管理员登陆页面关系275.2 商家管理页面关系285.3 用户管理页面关系295.4 公告栏管理页面关系305.5 报表统计页面关系305.6 访问量统计页面关系315.7 管理员管理页面关系315.8 管理员登出页面关系32第六章 设计模型336.1 分析工作区336.1.1 关键抽象336.1.2 控制类346.1.3 边界类346.2 分析工作区用例实现346.2.1 管理员登陆346.2.2 商家管理376.2.3 用户管理386.2.4 公告栏管理396.2.5 报表统计406.2.6 访问量统计426.2.7 管理员管理436.2.8 管理员登出456.3 类的设计456.3.1 定义包结构466.3.2 定义设计类476.2.3 定义持久化类50第七章 系统数据库设计537.1 数据字典537.2 E-R图557.3 数据表的设计57第八章 接口设计618.1 持久化层设计618.2 EJB层业务接口设计648.3 Web 层业务代理接口设计738.4 对代码进行版本控制83第九章 系统运行与测试869.1 系统运行869.1.1 启动应用869.1.2 系统运行结果879.2 性能测试929.2.1 建立测试计划929.2.2 对单个功能进行并发测试939.2.3 对所有功能进行并发测试103结 论105致 谢106参考文献107引 言引 言从来没有任何事物像互联网那样，对人类的活动产生如此深刻的影响，无论是政府、企业，以及个人，莫不如此。与此同时，IT产业也正面临着一场变革由传统应用向基于Internet/Web的服务模式转化。随着Internet的快速发展，传统电子商务技术难以胜任商务信息爆炸式的增长以及网络环境日益复杂。以常见的电子商店为例，传统的电子商店通过Web页面方式，向顾客提供商品信息供其交互式查询和操作，顾客通常不得不浏览许多网站后才能找到所需商品，然后自行进行商品比较、订购。由于这些过程都需要在线操作，当系统的应用量增大时，顾客和网站之间的频繁交互使得网络带宽浪费严重，系统负荷增加，既浪费了顾客的时间和精力，又增加了网络的信息流，造成效率降低和资源浪费。另外，商家需要顾客访问网站才能为其提供服务，这是一种被动的销售方式，他们希望能够采取主动的方式向顾客推销服务。面向以上问题，传统的电子商务技术（如Client/Server模式）已经无法满足要求，电子商务领域迫切需要一种积极、主动、智能的新技术来满足人们对电子商务的新需求。近年来，随着面向Agent软件技术的发展，一种新型的分布计算模式移动Agent(Mobile Agent)技术引起业界的广泛注意，并被引入到电子商务领域中。移动Agent是一种粒度比普通对象更大的程序实体，能够携带其代码和状态自主地在网络中从一个节点移动到另一个节点，以寻找合适的计算资源和信息资源，完成特定的任务。Agent在移动过程中，它的自身状态被保存，并封装成信息传送到新的主机上，从而在新的主机上继续执行。移动Agent最基本的特征是自主性和移动性，其基本的目标是减少网络信息传输和实现异步交互。移动Agent为网络提供了一种崭新的计算模式，与支持传统电子商务的分布技术(如Client/Server模式、Code OnDemand模式)相比，它具有节约网络带宽、支持离线计算、减轻用户负担、提高交易效率等方面的优点。另外，移动Agent为电子商务提供更自然的模式：代表顾客的Agent可以在网上自由移动，寻找卖家，查询商品种类，和卖家Agent商谈价格和交易方式；卖家Agent也可以主动上门向买家推荐商品。基于移动Agent的智能商务系统管理子系统，是针对基于移动Agent的智能商务系统，对其注册用户、注册商家，系统数据的报表统计以及商务中心的事务进行管理。该系统的设计目的，是能够方便快捷地对商务中心进行管理。在统计方面，能把数据库的数据以图形的形式生动地表达出来，使管理人员对数据的分析更为直观、生动。同时，其它的管理工作也应该做到人性化，个性化，对管理系统的操作尽量做到“零岗前培训”，这样不紧可以大大降低网站的经营成本，也能提高管理的效率。通过该系统的设计，不仅可以巩固自己已有的知识，而且也可以学到新的知识，从而扩大了知识面，也为将来的实际工作打下坚实的基础。在建模、设计、编码、测试等一系列开发过程，可以熟练掌握Rose、Visio、Eclipse、Junit、Jmeter等工具软件。在整个系统的开发过程中不仅能熟练掌握常用的开发工具、软件包、架构等，同时也增强了团队的合作精神，增强了解决问题的能力。- 109 -第一章 Open Source第一章 Open Source应用软件的目的是解决某一领域的业务问题，然而在开发过程中，除了业务需求要关注，技术方面也会有大量的问题，另外软件开发的费用常常会超出预算。那么如何降低软件开发项目的风险呢（包括技术以及成本两方面）使用开源软件是一个很好的选择。开源软件使开发人员从底层功能中解脱出来，可以更好地专注于用户的业务需求。由于开源软件的代码已经通过了充分的测试，系统的成本降低了，周期缩短了，风险减少了。1.1 开源软件简介企业软件曾经是比较昂贵的。如果想让软件适合自己特定的业务需要必须和软件开发商联系才能进行修改。更令人难以忍受的是如果软件产品出现问题，也只能等软件开发商进行修改，这通常是定期进行的，而不可能是发现问题，立刻修正的。开源软件的出现，改变了这一切。开放源代码软件就是在开放源代码许可证下发布的软件，以保证软件用户自由使用及接触源代码的权利，这同时也保护用户可以自行修改、复制，以及分发的权利。开放源代码发起行动组织（Open Source Initiative Association ，简称OSIA）的开放源代码定义中，对开放源代码软件的认定标准由如下几方面：自由地再发布 如果被发布的软件是由不同来源的程序组成的，许可证不得限制任何当事人或组织销售或赠送作为被发布软件成分之一的开放源码软件。源代码程序必须包括源代码，必须允许以源代码方式发布、还必须允许以编译后的形式发布。如果产品的某个部分没有与源代码一同发布，那么必须提供通行的、不需要支付合理范围之外的任何费用的手段以获得源代码-从网络上免费下载是一种可取的方式。源代码必须是程序员对其进行修改的最佳形式。故意地使源代码变得含混晦涩是不允许的。也不允许给出预处理器或翻译器处理的中间结果。 作者的源代码的完整性只有在许可证允许与源代码一同发布补丁文件（该补丁文件以在创建时对程序进行修改为目的）时，许可证才能限制对修改形式的源代码的发布。不得歧视任何个人或团体 不得歧视任何应用领域许可证不得限制任何人把程序应用于任何领域。许可证的发布与程序有关的权利必须适用于该程序的任何使用者，并且程序的使用者也不需要为了使用该程序而获得其它许可证的许可。许可证不能针对于一个产品与程序有关的权利不能由该程序是否作为某个软件产品的一部分来决定。如果程序从那个发布中被抽出来，并且按照程序的许可证的条款进行使用和发布，那么得到该程序的当事人或组织将获得与得到原程序的使用者相同的权利。许可证不能影响其它软件许可证不得向与采用它的软件一同发布的其它软件提出任何限制。1.2 项目中开源软件介绍1.2.1 StrutsStruts是一个基于Sun J2EE平台的MVC框架，主要是采用Servlet和JSP技术来实现的。它把Java Web应用分为模型、视图、控制器三层。模型层由业务数据和业务逻辑的JavaBean或EJB组件构成。控制器则由ActionServlet和Action来实现，用于接收用户的请求并把结果用适当的视图表现给用户。视图层，通过JSP标签或客户化标签展现相应的视图给用户。图1.1 Struts 实现MVC架构1.2.2 HibernateHibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。 Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序实用，也可以在Servlet/JSP的Web应用中使用，最具革命意义的是，Hibernate可以在应用EJB的J2EE架构中取代CMP，完成数据持久化的重任。本系统中，采用Hibernate作为持久化层。图1.2 Hibernate 模型 图1.3 MVC架构中各层的依赖关系1.2.3 EclipseEclipse平台是IBM向开发源码社区捐赠的开发框架，它是一个成熟的、精心设计的以及可扩展的体系结构。可以通过各种不同的插件来扩展该平台的功能。而且各种各样的插件都是开源的，可以不受限制地使用。1.2.4 Cewolf Web动态报表Cewolf可以在一个基于Servlet/JSP的Web应用程序内部使用，以在Web页中嵌入各种复杂的图形图表(如，直方图、饼图、棒图等等)。它提供了一个功能完备的标签库来定义图表的所有属性(颜色、笔画、图例等)，这样嵌入了图表的JSP就不用使用任何Java代码。系统中采用Cewolf来动态生成图形报表，使呆板的关系数据变得直观生动。1.2.5 JunitJUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（Regression Testing Framework）。Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。Junit是一套框架，继承TestCase类，就可以用Junit进行自动测试了。系统中采用Junit 作为单元测试。1.2.6 StrutsTestCaseStrutsTestCase是Junit TestCase类的扩展，提供基于Struts框架的代码测试。StrutsTestCase同时提供Mock 对象方法和Cactus方法用来实际运行Struts ActionServlet，你可以通过运行servlet引擎来测试。因为StrutsTestCase使用ActionServlet控制器来测试你的代码，因此你不仅可以测试Action对象的实现，而且可以测试mappings，from beans以及forwards声明。StrutsTestCase不启动servlet容器来测试struts应用程序（容器外测试）也属于Mock对象测试，但是与EasyMock不同的是，EasyMock是提供了创建Mock对象的API，而StrutsTest则是专门负责测试Struts应用程序的Mock对象测试框架。系统中使用StrutsTestCase对Struts架构进行模拟测试。1.2.7 JmeterApache JMeter是一个专门为运行和服务器装载测试而设计的、100的纯Java桌面运行程序。原先它是为Web/HTTP测试而设计的，但是它已经扩展以支持各种各样的测试模块。它和用于HTTP和SQL数据库（使用JDBC）的模块一起运送。它可以用来测试静止资料库或者活动资料库中的服务器的运行情况，可以用来模拟对服务器或者网络系统加以重负荷以测试它的抵抗力，或者用来分析不同负荷类型下的所有运行情况。它也提供了一个可替换的界面用来定制数据显示，测试同步及测试的创建和执行。系统中使用JMeter进行压力测试。1.2.8 JBoss在J2EE应用服务器领域，Jboss是发展最为迅速的应用服务器。由于Jboss遵循商业友好的LGPL授权分发，并且由开源社区开发，这使得Jboss广为流行。另外，Jboss应用服务器还具有许多优秀的特质。其一，它将具有革命性的JMX微内核服务作为其总线结构；其二，它本身就是面向服务的架构（Service-Oriented Architecture，SOA）；其三，它还具有统一的类装载器，从而能够实现应用的热部署和热卸载能力。因此，它是高度模块化的和松耦合的。Jboss用户的积极反馈告诉我们，Jboss应用服务器是健壮的、高质量的，而且还具有良好的性能。为满足企业级市场日益增长的需求，Jboss公司从2003年开始就推出了24*7、专业级产品支持服务。同时，为拓展Jboss的企业级市场，Jboss公司还签订了许多渠道合作伙伴。比如，Jboss公司同HP、Novell、Computer Associates、Unisys等都是合作伙伴。 在2004年6月，Jboss公司宣布，Jboss应用服务器通过了Sun公司的J2EE认证。这是Jboss应用服务器发展史上至今为止最重要的里程碑。与此同时，Jboss一直在紧跟最新的J2EE规范，而且在某些技术领域引领J2EE规范的开发。因此，无论在商业领域，还是在开源社区，Jboss成为了第一个通过J2EE 1.4认证的主流应用服务器。现在，Jboss应用服务器已经真正发展成具有企业强度（即，支持关键级任务的应用）的应用服务器。本系统使用用Jboss 4.0作为EJB容器以及Web服务器。第二章 需求分析第二章 需求分析 需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。需求分析的基本任务是准确地回答“系统必须做什么？”这个问题了。2.1 系统功能定义通过对基于移动Agent的智能商务系统管理子系统的分析，当管理员登陆管理系统后，将对商务中心进行管理，或对自己的账户进行管理等操作。管理子系统应用包含以下功能需求：1）、管理员登陆 用于系统识别不同的管理员（普通管理员和超级管理员）的身份和授权情况。对于超级管理员，主要工作是对限权管理员的管理；对于普通管理员的登陆，普通管理员的和密码必须已经存在（可以超级管理员在管理员管理中使用添加功能创建）。2）、商家管理 对申请加入商务中心的商家进行批准或拒绝操作；对已加入的商家进行删除（由于收费问题或商家要求等）或修改（商家要求等）操作。3）、用户管理：根据实际的需要，对用户的情况进行查看。其中，对用户的查询可以按照注册时间、积分、地区进行。对于修改用户信息（如密码等）问题，由于涉及用户私有信息，交由用户自己操作（在购物子系统的“我的信息管理”中实现）。4）、报表管理 对商务中心的交易信息（交易量）进行统计并制成报表进行打印。对于不同时期的报表可以根据输入不同的时段进行搜索。5）、访问量统计 统计用户或商家对商务中心的访问，同时也可生成图形报表。6）、管理员管理 此管理功能只有超级管理员拥有。主要对普通管理员进行管理，可添加普通管理员、对普通管理员进行权力授予、删除普通管理员等操作。7）、公告栏管理 在商务中心发布/修改公告。8）、管理登出 普通管理员或超级管理员在进行完管理工作后不想继续使用系统。退出当前会话，返回商务中心首页。图2.1 管理子系统功能层次图图 2.2 商家管理功能层次图图2.3 用户管理功能层次图2.2 基于RUP构建管理系统管理子系统采用基于RUP构建J2EE应用的4 个基本流程来设计，4个基本流程如下：1）、用例模型 找出角色和用例，画出角色和用例的交互图，细化用例的事件流内容，画出每个用例的活动图和顺序图。2）、用户体验模型 找出用户执行用例过程中与系统交互时所使用的页面，使用页面描述用户与系统交互的内容。定义页面关系，画出页面之间跳转的类图和页面之间跳转的顺序图。3）、设计模型 找出系统的关键抽象实体以及它们的属性，画出实体关系图。针对用例模型中的每个用例，找出那些执行用例中描述的行为内容的分析类（边界类、控制类、实体类），包括它们的属性、责任以及关系，画出每个用例分析类的静态关系图。根据分析类为用例事件流建模，针对用例中的每个事件序列，建立一个UML的顺序图，展示这些分析类如何协作以执行用例中的事件流内容；设计子系统及其接口，将实体类分组，使得每组实体类都可以用一个企业组件进行管理，设计EJB、Agent类，画出EJB、Agent类图。为每个用例设计控制类和页面类，并画出相应的顺序图和类图。4）、实施模型 定义实施类的组织结构（包括源代码和可执行代码），产生实施类，并进行单元测试。建立实施模型的结构，包括Java包结构、虚拟目录结构、J2EE模块组织和相应的部署描述符。第三章 建立用例模型第三章 构建用例模型用例模型是基于外部视角定义了系统的行为，包括与系统进行交互的角色 (Actor)（如：管理员），以及描述交互内容的用例（Use Case）（如：管理子系统的管理员登陆）。3.1 识别角色 角色是在系统外部与系统交互的某人或者系统。角色可以是人、外部系统或者是一个处部设备（如用户、商家、管理员）。找出角色有助于建立系统的边界，因为它们是系统的外部环境。系统的边界同样有助于我们理解系统的目的和范围。在管理子系统中主要包含：普通管理员、超级管理员两个角色。图3.1 角色间关系表3.1 管理子系统角色的描述角色描述普通管理员由超级管理员设定其管理权限，未权的模块，普通管理员不能进行管理。超级管理员拥有普通管理员的所有权限，可对所有模块进行管理，同时对普通管理进行管理，修改普通管理员的管理模块等。通常管理子系统只有一个超级管理员，但如果需要也可设定多个超级管理员3.2 识别用例用例是一个完整的事件流描述，为特定的角色提供一个有价值的结果。在管理子系统中，找到了个用例：报表统计；访问量统计；公告栏管理；管理员登陆；管理员管理；商家管理；用户管理；管理员登出；图3.2 Rose中的管理子系统的用例包结构表3.2 管理子系统用例描述用例描述管理员登陆管理员登陆用例帮助管理员让系统识别自己的身份。如果系统中已经有账号，管理员可以通过用户名和密码进行登陆。报表统计报表统计用例主要通过图形的方式对商务中心的数据进行统计。管理员可以通过输入特定时间段获得所需数据 。访问量统计顾名思义，就是统计商务中心的访问量，可以通过年、月、日进行统计。公告栏管理管理员用于管理商务中心公告信息。管理员可添加、删除和修改公告信息。管理员管理超级管理员通过该用例，添加、删除管理员，或者修改管理员的管理模块。普通管理员，只可以查看管理员的信息。商家（销售者）管理管理员可以查看已注册商家和申请商家。对于申请商家，管理员可以批准其进入商务中心或者拒绝其进入商务中心。而对注册商家，则可以停止其在商务中心的活动，或把其在商务中心删除。用户（购物者）管理用于查看注册在商务中心的用户资料。或删除该用户。管理员登出允许管理告诉系统该管理员已经不想继续使用系统。登出是，管理员必须已登陆。3.3 管理子系统性能需求在识别角色和用例的过程中，发现有些需求并不能分配给特定的用例，这些需求是针对整个系统的性能的。针对管理子系统的性能需求如下表：表3.3 管理子系统性能需求分类描述可用性管理子系统应该提供必要的操作提示已经出错提示，出错信息应该已较友好的方式显示给管理员，真正的出错信息应该写入日志文件中。可靠性管理系统应该可以持续运行，如：7*24小时正常运行。在进行系统维护操作时，不应该要求系统停机。性能在100Mbps的网络里，应该保证查询的响应时间不超过3s。开发和运行环境管理子系统应该基于J2EE平台开发和部署。3.4 角色与用例的交互下图展示了管理子系统中角色与用例间的交换关系图3.3 管理子系统角色与用例的交互3.5 细化用例 在细化用例过程中用到一系列的场景。对这些场景的描述如下： 前置条件：开始使用这个用例之前必须满足的条件。 后置条件：用例的执行结果必须为真的条件，并不是每个用例都有 后置条件。 相关角色：使用用例的角色。 主场景：用例的正常流程。 次场景：用例的非正常流程。如出错。3.5.1 用例1 管理员登陆 前置条件：管理员已经在管理系统中注册 相关角色：管理员 主场景：A、 管理员输入用户名和密码，系统验证用户名和密码。 次场景： A、 若管理员输入的用户名和密码错误，提示相应的错误。 B、 若输入的用户名不存在，提示于超级管理员联系。 后置条件：进入管理子系统首页。管理员登陆的活动图为：图3.4 管理员登陆用例活动图3.5.2 用例2 商家管理 前置条件：管理员已登陆 相关角色：管理员 主场景：A、 管理员进入商家管理页面；B、 管理员选择申请商家列表，系统查询当前申请的商家，以列表的形式显示出来；C、 管理员选择其中某条，系统检索出其详细信息；D、 管理员查阅信息后，可批准或拒绝其进入商务中心；E、 管理员选择注册商家列表，系统检索出已注册的商家列表；F、 管理员选择其中某条，系统检索出其详细信息；G、 管理员查阅信息后，可停止其在商务中心的活动，或把其在商务中心删除掉； 次场景：无 后置条件：无商家管理用例活动图见 图3.5商家管理用例活动图3.5.3 用例3 用户管理 前置条件：管理员已登陆 相关角色：管理员 主场景：A、 管理员进入用户管理页面；B、 系统检索出当前商务中心注册的用户，以列表的形式显示出来；C、 管理员选择其中某条，系统检索出其详细信息；D、 管理员查阅信息后，根据实际情况可删除用户或不做任何操作；E、 管理员根据需要按注册日期、按地区等查询用户信息； 次场景：无 后置条件：无用户管理用例活动图 见图3.6商家管理用例活动图图3.5 商家管理用例活动图图3.6 用户管理用例活动图3.5.4 用例4 公告栏管理 前置条件：管理员已登陆 相关角色：管理员 主场景：A、 管理员进入发布公告栏；B、 系统显示出公告发布表单，管理员按表单的格式填写公告；C、 管理员提交公告，系统添加一条公告信息到公告表；D、 管理员选择查看公告；E、 系统检索公告表，以列表的形式显示出系统中有效和无效公告；F、 管理员选择其中一条公告，系统检索出该公告的详细信息；G、 管理员查看该公告详细信息后，可对其进行修改/删除操作，系统根据管理员的操作，对公告表进行更新/删除操作； 次场景：无 后置条件：无公告栏管理用例活动图 见图3.7商家管理用例活动图图3.7 公告栏管理用例活动图3.5.5 用例5 报表统计 前置条件：管理员已登陆 相关角色：管理员 主场景：A、 管理员进入报表统计，系统默认检索出当天的数据，并生成图表数据显示出来；B、 管理员根据需要选择某年/某月/某天，查看数据，系统根据管理员的输入，检索数据库，把相应的数据显示出来； 次场景：A、 数据库没用查询的数据，系统提示管理员“数据库无请求数据” 后置条件：无报表统计用例活动图 见图3.8报表统计用例活动图图3.8 报表统计用例活动图3.5.6 用例6 访问量统计 前置条件：管理员已登陆 相关角色：管理员 主场景：A、 管理员进入访问量统计，系统计算出当天的访问量，并显示给管理员； 次场景：无 后置条件：无访问量统计用例活动图 见图3.9访问量统计用例活动图图3.9 访问量统计用例活动图3.5.7 用例7 管理员管理 前置条件：管理员已登陆 相关角色：超级管理员 主场景：A、 超级管理员选择添加管理员，系统掉出添加管理员表单；B、 超级管理员根据表单的内容设定新管理员的用户名、管理模块等信息；C、 超级管理员提交表单，系统增加一条管理员信息；D、 超级管理员选择查看管理员；E、 系统检索出所有的管理员，并按照管理员的级别分类列出；F、 超级管理员年选择其中某项，系统检索出该管理员的详细信息；G、 超级管理员查看详细信息后，可对其进行停职、修改管理模块等操作，系统根据超级管理员的操作，做出相应才更新操作； 次场景：A、 管理员填写的表单不符合要求，系统提示表单的相应项不符合要求； 后置条件：无管理员管理用例活动图 见图3.10管理员管理用例活动图图3.10 管理员管理用例活动图3.5.8 用例8 管理员登出 前置条件：管理员已登陆 相关角色：管理员 主场景：A、 管理员点击登出，系统结束对该管理员的会话跟踪； 次场景：无 后置条件：返回登陆页面由于管理员登出只是简单的结束会话跟踪，并没有涉及到业务逻辑，因此省略其活动图。第四章 架构分析第四章 架构分析4.1 MVC 架构管理子系统采用基于MVC 的J2EE架构。J2EE是一个开放的、基于标准的平台，可以开发、部署和管理N层结构的、面向Web的、以服务器为中心的企业级应用，它是利用Java 2 平台来简化与多级企业解决方案的开发、部署和管理相关的诸多复杂问题的应用体系结构。J2EE平台采用一个多层次分布式的应用模式。这意味着应用逻辑根据功能被划分成组件，组成J2EE应用的不同应用组件安装在不同的服务器上，这种划分是根据应用组件属于多层次J2EE环境中的哪一个层次来决定的。这里采用MVC进行分层，所谓MVC就是模型（Model）、视图（View）、控制器（Controller）即三层结构（如图4.1），因为它们是被分布在三个不同的地点：客户端机器、J2EE服务器和数据库或后端的传统系统服务器。在管理子系统中采用Struts实现MVC模型。图4.1 基于Struts的J2EE 应用的结构1）视图在Struts中视图就是一组JSP文件和Struts标签库或客户化的自定义标签。视图中没有业务逻辑，也没有模型信息。视图通过控制器把数据传到模型层。图4.2 视图与控制器的关系2）模型模型表示应用程序的状态和业务逻辑，管理子系统业务逻辑由EJB组件来实行。图4.3 客户端调用模型3) 控制器Struts中控制器由ActionServlet类和Action类来实现。当ActionServlet接收到用户的请求后，把请求转发到一个Action。Action负责调用模型的方法，更新模型的状态，并帮助控制应用的流程。图4.4 Struts实现MVC架构4.2 管理子系统架构分析 管理子系统采用一个无状态的EJB组件来实现业务逻辑，Web层通过EJB的本地接口调用业务方法。Web层和EJB容器可以分别采用不同的服务器实现，但在本系统中采用JBoss与Tomcat的整合服务器，它能够同时充当Web容器和EJB容器。图4.5展示了管理子系统的体系结构。图4.5 基于J2EE 的管理子系统的体系结构 图4.6 管理子系统中通过业务代理访问EJB组件为了削弱Web应用和模型之间的关系，在Web应用和EJB组件间增加了业务代理模式。Web应用通过代理接口访问EJB组件的业务逻辑（如图4.6）。同时在EJB和数据库服务器间也增加了DAO（Data Access Object）来削弱EJB组件和数据库的关系。这样上层只需针对接口编程，而无须针对实现来编程，这样即使需求发生改变，只要接口没有改变就不用从新编码。图4.7 管理子系统的分层应用4.3 面向接口编程在一个面向对象的系统中，系统的各种功能是由许许多多的不同对象协作完成的。在这种情况下，各个对象内部是如何实现自己的对系统设计人员来讲就不那么重要了；而各个对象之间的协作关系则成为系统设计的关键。小到不同类之间的通信，大到各模块之间的交互，在系统设计之初都是要着重考虑的，这也是系统设计的主要工作内容。面向接口编程而不是实现，可以避免当某个功能需要改变时而要更改所有代码。面向接口编程具有以下优点： 程序员不必知道其使用对象的具体所属类，只须制定该接口的功能就可以了。 一个对象可以很容易地被（实现了相同接口的）的另一个对象所替换。 对象间的连接不必硬绑定（hardwire）到一个具体类的对象上，因此增加了灵活性。 松散藕合（loosens coupling）。 增加了代码的可重用性。 提高了（对象）组合的机率，因为被包含对象可以是任何实现了一个指定接口的类。 图4.8 实现交通工具接口的不同类图4.8所示，描述了4个实现交通工具接口的实现类，轮船、飞机、火车和小汽车。我们只需关心交通工具这一接口提供的功能即可，即方便人们出行，节省时间。使用时，掉用交通工具这一接口即可，无需知道其具体实现时轮船还是飞机。第六章 设计模型第五章 用户体验模型建立用户体验模型是通过系统中反映用户体验的元素去定义每个用例所表达的行为。用例使用过程描述用户在执行用例过程所经过的页面。每个用例使用过程都有一个结构视图和一个动态视图。屏幕式用户体验模型中的主要元素。在Web应用系统中，屏幕是一个客户端元素，该元素表达该应用系统在一个客户窗口中产生的全部内容。一个屏幕可以包含多个页面的信息。建立用户体验模型主要有以下两步：1）、找出参与的页面找出用户执行用例过程中与系统交互时所使用的页面，使用页面描述用户与系统交互的内容，页面是一个客户端元素，该元素表达系统在一个客户窗口中产生的内容。以下内容是找出页面上的各类信息： 动态内容。动态内容是在页面上显示的一类信息，它提供运行是的业务逻辑内容。那些静态内容并不需要在用户体验模型中描述，因为静态内容通常关注的是直观的的视觉感受，并不影响系统表示与系统业务逻辑之间的配合关系。 用户所提供的内容。那些由用户通过输入方式的提供的内容。 用户动作。用户可以在页面上执行的动作。如点击一个按钮或者选择一个菜单项。2）、定义页面关系针对用例的每个事件流，建立页面关系图：根据第三章的用例分析可找出了各用例的屏幕，就可以得出各用例的页面关系。5.1 管理员登陆页面关系图5.1 管理员登陆页面关系5.2 商家管理页面关系图5.2 商家管理页面关系5.3 用户管理页面关系图5.3 用户管理页面关系5.4 公告栏管理页面关系图5.4 公告栏管理页面关系5.5 报表统计页面关系图5.5 报表统计页面关系5.6 访问量统计页面关系图5.6 访问量统计页面关系5.7 管理员管理页面关系图5.6 管理员管理页面关系5.8 管理员登出页面关系图5.8 管理员登出页面关系第六章 设计模型设计模型主要是根据用户体现模型和用例实现找出参与该用例的分析类，以及这些分析类之间的关系，同时为这些用例的事件流建模。分析类包括用例的用例的属性、责任和关系。分析类主要分为边界类、控制类、实体类三种，表6.1给出分析类详细说明。在找分析类的同时，可根据MVC的架构对分析类做初步的分层。表6.1 分析类描述类别UML表示说明边界类边界类表达系统与其环境之间的边界控制类控制类表达系统的控制与协调逻辑实体类实体类封装了在系统在系统内部表达的信息 边界类用于描述系统和其环境之间进行的交互，一个边界类可以作为一组页面的概括，相应设计Structs架构中的ActionForm类。 控制类封装针对用例的行为并处理主要的事件控制流程。相应设计Structs架构中的Acion类。 实体类封装了在系统内部表述的信息内容，同时也包括相关的属性和行为内容。设计的实体类（关键抽象）将与设计实体EJB或JavaBean相对应6.1 分析工作区6.1.1关键抽象 关键抽象即实体类，主要是管理子系统中的名词。管理子系统中，找到个关键抽象，见图6.1。图6.1 管理子系统的关键抽象6.1.2 控制类控制类主要是应用中的动词或表示跳转的事件。图6.2管理子系统中的控制类6.1.3 边界类管理子系统中边界类较多，将在用例实现中加以描述6.2 分析工作区用例实现根据分析工作区找出的分析类为用例事件建立事件序列，即建立UML序列图和，同时根据把分析类初步分层，即分为表示层、控制层、业务逻辑层和持久化层。分析类都分布在这几层里。 6.2.1 管理员登陆管理登陆包含有管理员登陆、商务中心首页两个边界类，一个管理员登陆控制类和一个管理员实体类，相应的业务接口分布在业务逻辑层，见图6.3。图 6.3 管理员登陆用例分析类和分层结构图 6.4 管理员登陆序列图6.2.2 商家管理商家管理包含有商家管理页、商家信息页等6个边界类，一个商家管理控制类和申请、已注册商家实体类，见图6.5。图6.5 商家管理用例分析类及分层结构6.2.3 用户管理该用例含有用户管理页、用户信息页等5个边界类，1个用户控制类和1个用户实体类，见图6.6。图6.6 用户管理用例分析类及分层结构6.2.4 公告栏管理 该用例含有公告列表、公告添加/修改等5个边界类，1个公告处理控制类和1个公告栏实体类，见图6.7图6.7 公告栏管理分析类及分层结构6.2.5 报表统计该用例含有报表交易列表等3个边界类，1个报表控制类和1个报表实体类，见图6.8。图6.8 报表管理分析类及分层结构图6.9 报表管理用例序列图6.2.6 访问量统计该用例只有1个访问量管理页边界类、访问量控制类和访问量实体类，见图6.10。图6.10 访问量控制分析类及分层结构6.2.7 管理员管理该用例含有管理员设定 等4个边界类，1个管理员管理控制类和1个管理员实体类，见图6.11。图6.11 管理员管理分析类及分层结构图6.12 管理员管理用例序列图6.2.8 管理员登出由于管理员登出只需告诉服务器，结束当前管理员的会话跟踪即可，因此该用例只有简单的2个边界类，见图6.13。图6.13 管理员登出用例分析类图6.14 管理员登场序列图6.3 类的设计类的设计，主要是把找到的分析类转化为与特定编程语言相关的设计类。初步确定这些类的属性及方法，以及这设计类的包结构。由于管理子系统是基于MVC的J2EE应用，所以我们采用Java语言的语法来分析设计类。这里的设计类主要包括: servlet、JSP页面和Java类。6.3.1 定义包结构包，即目录。把相关的类放入同一个包中，方便查找和集中管理。包的命名应该有自解作用而且要简单明了。1)、EJB容器中的包结构 com.ais.manager 表示组织及子系统。 图6.15 EJB容器中的包结构如图6.15所示，dao包主要与数据库相关的DAO类及一些实体类。exceptions包定义了整个管理子系统的出错类型，如当数据库发生错误时抛出DatastoreException。ejb 包存放EJB组件。interfaces 定义了给EJB容器的客户段调用的接口。util 存放常用工具类。2）、Web容器中的包结构在Web容器中，通常一个包对应一个用例，见图6.16。如admin包则对应管理员管理用例，但并不是所有的包都对应一个用例，如service 包则存放web容器中的服务类如业务代理或者一写公共的服务。图6.16 Web容器中的包结构6.3.2 定义设计类定义设计类包含如下工作： 定义类的可见性； 定义类的方法； 定义类的属性； 定义好类的依赖关系；图6.17 报表管理的设计类图6.18 管理员登陆设计类图6.19 管理员管理设计类图6.20 访问量统计设计类6.2.3 定义持久化类持久化类（实体类）实际上也是设计类的一种，但实体类属性通常与数据库的字段相对应，因此这里把它和设计类分开处理。基类BasePersistentObject有持久化类的基类，所以持久化类必须继承这个类；id: 代表对象的OIDversion: 用于版本控制；公告栏（CallBoard）标题：title内容：description有效时间：periodOfValidity发表时间：publishTime作者：author报表（ReportForms）数据来源于商务中心的订单买方:buyer卖方:seller交易时间:dealTime交易金额:dealSum订单号:ordered访问量（VistSum）日访问量：dateVisit总访问量：totalVisit日用户注册量:dayReg总用户注册量:totalReg日商家注册量:dayMechantReg总商家注册量: totalMechantReg管理员（Admins）登陆名：name密码：password级别：level管理模块：module真实姓名：realName出生日期：birthday地址：assress电话：phone移动电话：mobilePhoneEmail：email注册实际：regTime描述：description状态：state第七章 系统数据库设计第七章 系统数据库设计由于管理子系统要读到购物子系统5张表并对其数据进行管理，这5 张表分别为：消费者（用户）注册信息（Customer）、商家（客户）注册信息(Seller)订单信息表（Order）、商品项表（Item）、商品信息表（Goods）、商品类别表（Category）。这5张表并不属于管理子系统，因此不再进一步描述。7.1 数据字典1管理员信息(1)名字：管理员ID变量名：ID描述：系统生成，管理员的编号，是该管理员的唯一标识定义：一个Long型值位置：管理员信息表(2)名字：管理员名称变量名：Name描述：管理员登录系统后台所需要的身份识别，由