销售支持办公系统的设计与实现毕业论文.doc

销售支持办公系统的设计与实现毕业论文目 录第一章 绪论11.1研究背景和课题来源11.1.1选题背景11.1.2选题意义11.2课题研究目标及内容11.2.1研究目标11.2.2研究内容11.3论文的组织结构2第二章 相关技术42.1轻量型JAVAEE平台Struts2+Spring3+hibernate3框架整合简介42.1.1Struts242.1.2Spring42.1.3Hibernate52.2富客户端前段开发框架ExtJS52.3工作流/业务流程管理框架 jBPM452.4相关定义62.5本章小结6第三章 系统需求分析73.1系统介绍73.1.1基本概念73.2系统角色分析73.2.1目标用户73.2.2用户类型73.3系统业务性办公需求83.3.1业务性系统主要实现功能83.3.2系统用例分析93.4系统非业务性办公需求113.4.1非业务性系统主要实现功能113.4.2系统用例分析113.5系统用户管理性需求133.5.1用户管理性系统主要实现功能133.5.2系统用例分析143.6系统非功能需求143.6.1国家节假日的显示143.7系统目标143.8本章小结15第四章 系统总体设计164.1设计原则164.2系统软件结构图164.3系统物理结构图174.4系统流程图174.5销售支持管理系统功能模块划分194.5.1系统功能模块总图194.5.2项目管理模块194.5.3客户管理模块204.5.4统计模块204.6请假系统功能模块划分214.6.1系统功能模块总图214.6.2假期管理模块224.6.3统计模块224.7后台管理系统功能模块划分234.7.1系统功能模块总图234.7.2菜单管理模块234.7.3角色管理模块234.7.4职称，职务，部门管理模块244.7.5员工管理模块244.8难点与关键技术的设计方案254.8.1假期计算的实现方案254.8.2基于JBPM4工作流审批流程的实现方案254.8.3倒休管理功能的实现方案264.8.4单点登入的路径转换和session转移264.9运行环境264.9.1硬件环境264.9.2软件环境274.10本章小结27第五章 系统详细设计285.1系统实现技术框架285.1.1系统表示层实现技术285.1.2应用服务层实现技术295.2销售支持管理系统详细设计方案295.2.1实体层设计305.2.2控制层设计305.2.3服务层设计315.2.4数据库层表设计325.2.5系统的实现和部署335.3后台管理系统详细设计方案365.3.1实体层设计365.3.2控制层设计365.3.3服务层设计375.3.4数据库层表设计375.3.5系统的实现和部署385.3.6假期的计算的算法实现415.3.7基于JBPM4工作流的审批流程的算法实现425.4技术实现中的创新点435.5本章小结43第六章 系统测试456.1系统测试目标456.2系统测试的原则466.2.1需要测试的特性466.2.2不需要测试的特性466.3系统测试环境466.4系统测试用例476.5系统测试内容486.5.1界面测试486.5.2系统功能测试486.5.3负载测试486.5.4兼容性测试496.6系统测试结果及说明分析496.6.1系统测试结果496.6.2测试出的问题和解决方案506.7本章小结51结 论52工作总结52工作展望53参考文献54致谢56III北京航空航天大学硕士学位论文第一章 绪论1.1 研究背景和课题来源1.1.1 选题背景在现代公司中，办公软件使用很频繁。但是由于每个公司都有很多的部门，每个部门的需求都不一样，所以一个公司内部会有很多不同的系统，如财务系统，报销系统，请假系统等，这些系统后台使用的数据库甚至都是分开的。所以需要设计一个可以实现内外资源整合的高效的信息系统很重要。这样可以将公司内部的所有系统整合起来，从而提升其管理水平。1.1.2 选题意义使用销售支持办公系统的设计与实现作为这次论文的题目，是因为这个办公系统与普通的系统不同，它使用了cas单点登录框架，系统选择平台，和我们自主开发的后台管理系统。其中最大的不同是普通的管理系统着眼于功能的实现和信息的管理，而销售支持办公系统的设计与实现主要目的是设计一个统一的标准并让所有系统都符合这个标准，同时这个标准要既要能实现平台功能，又不能影响各个子系统的功能实现，所以这个标准必须要有很强的灵活性。销售支持管理系统是公司的核心业务系统，已经和其他系统整合在了一起。在这个系统中已经解决了许多问题，如session转移，后台管理系统的通用性设计，不同数据库不同表的整合等。在解决这些问题中，获得了很多平台经验，可以为以后开发其他平台打下基础。1.2 课题研究目标及内容1.2.1 研究目标本研究将针对公司的办公自动化系统提供可行的功能设计方案进行深入研究，并从技术上提供整套系统的设计方法。深入探讨公司销售支持系统的工作流设计，上级领导的审批流程设计，请假系统中关于请假时间的设计。同时还要考虑到不同类型的用户需求和不同的使用环境，使得系统设计方案适应不同类型的用户和不同环境下的应用。1.2.2 研究内容1) 设计并完成一个后台管理系统，这个后台管理系统是其他系统的后台管理系统，它统一设置用户，设置员工，设置权限，设置系统，让所有系统统一到他的管理。这个系统是一个独立的系统，只能由系统管理员登入，其他类型的用户不能登入。2) 设计并完成一个请假管理系统，这个请假系统可以请事假，年假，病假等假期，还可以审批，驳回，修改请假，也可以将请假放入草稿箱，延迟提交。请假系统可以根据不同请假种类，设计不同的审批流程。可以交给组长批，可以交给经理批，也可以交给助理审批。同时为了记录，还会向有关人发送邮件。既然需要审批，相关职务的用户看到的菜单和相关数据也不相同，可以根据情况选择通过或驳回。如果选择驳回请假，那么请假申请人就会看到被驳回的请假，可以根据驳回原因修改请假再次申请。根据公司的工作特点，系统会有倒休管理，经理可以给员工增加倒休。3) 设计并完成一个销售支持管理系统。这个系统主要管理销售人员和支持人员的业绩和相关的合同，工程以及必要信息的管理。销售人员可以新建合同并定义合同的具体任容，也可以在定义合同时指定合同的支持人员名单。支持人员会根据合同内容去招聘合适的外包工程师和顾问。销售人员还能维护客户的基本信息。4) 设计并完成个平台，将销售支持管理系统和请假管理系统放入平台中，统一登入，统一选择，统一退出。每次打开平台时，都会有通知的自动推送，可以在第一时间知道公司的重要通知。1.3 论文的组织结构本论文分为七个部分，分别论述课题的背景、使用的相关技术、关键问题的解决、系统功能的设计与实现以及系统运行结果分析。第二章对本系统所使用的相关技术做了简要的说明，第三章介绍了销售支持办公系统的需求说明；第四章介绍了销售支持办公系统的设计；第五章介绍了该系统的实现方法；第六章首先对销售支持办公系统进行性能测试以及压力测试，然后对服务器进行优化并对该系统的实际运行结果作出分析并给出评价；最后对销售支持办公系统的优势，缺陷进行了总结，针对办公系统存在的问题给出解决方案。具体安排如下：（1） 第一章，绪论。本章介绍了销售支持办公系统的研究背景、课题来源、研究的内容和目标。（2） 第二章，相关技术。本章详细介绍了销售支持办公系统技术的基础：首先是Struts+Spring+Hibernate框架，分别概述了Struts、Sring、hibernate三个框架的基本概念，并对三个框架的整合以及整合后的优缺点做了简单的介绍。然后是MVC三层结构以及它在本系统实现过程中发挥的作用。再者，本章还对系统前端使用最多的ajax技术jquery和富客户端技术Extjs以及数据处理过程中使用的比较多的网页抓取工具Jsoup工具做了简单的概述。（3） 第三章，系统需求分析。本章对销售支持办公系统的需求进行了详细的说明，对该系统的开发目的，开发功能，预期使用者等等方面进行了较详细的阐述。（4） 第四章，系统总体设计。本章描述了销售支持办公系统的设计方案，以及该系统的功能实现等关键点，并从逻辑结构和功能模块设计这两个角度对系统设计方法进行了分析。（5） 第五章，系统详细设计。本章根据销售支持办公系统设计方案阐述了该系统的实现方案，然后详细阐述了原型系统中各个模型的具体实现，最后归纳介绍了本系统实现工作中所遇到并解决了的一些关键技术及难点。（6） 第六章，系统测试。对销售支持办公系统的稳定性以及吞吐量进行测试，并根据测试结果来调整服务器各项指标参数，对系统性能进行调优工作，保证系统可以长期有效稳定的运行。通过一段时间的系统运行观测，可以包括对销售支持办公用户访问量数据统计等数据进行深入分析，对该系统的优缺点进行整理，给出销售支持办公系统的分析报告。（7） 结论。对销售支持办公系统的优势，缺陷进行了总结，针对办公系统存在的问题给出解决方。第二章 相关技术本文研究工作的技术基础是Java web编程，为提高开发效率，本系统采用Java EE平台，再加上轻量级框架技术，即现今市场上比较主流的Struts+Spring+hibernate框架，包括前台的展示、逻辑的处理以及数据的持久化等。下面对本课题中用到的一些相关技术进行简要的说明。2.1 轻量型JAVAEE平台Struts2+Spring3+hibernate3框架整合简介在技术上具体来说，实体层采用Hibernate框架将数据库中的数据映射成实体并提供基本的增删改查功能，采用Spring框架进行控制反转并向Service层插入事务。这样做的好处是MVC的每一层之间的耦合比较小，相互之间只依赖于接口，与具体实现并不依赖。这样做可以让每层的实现变的灵活。Service层插入事务可以避免重复的事务语句，统一管理事务，设置事务。表现层主要靠Struts框架，Struts框架主要负责页面的跳转，页面的显示，数据的传递。2.1.1 Struts2图1 Struts 2.1.2 Spring图2 Spring框架结构2.1.3 Hibernate图3 Hibernate体系结构概要图2.2 富客户端前段开发框架ExtJSExtJS与其他前台的图形库不同的是，普通的图型库编写风格与普通的HTML类似，是标签式的编写风格，而ExtJS的编写风格完全是面向对象的，可以实现前台MVC分层，将数据，控制，图像分离开来，ExtJS只负责从服务器端获得数据，删除，修改都可以在前台操作，只需要在最后保存到数据库就行了。前台和后台的数据交流依靠Ajax技术，数据格式必须是Json格式。2.3 工作流/业务流程管理框架 jBPM4jBPM4是一种基于Java语言的开源工作流/业务流程管理框架（Framework），它主要包括工作流引擎（WorkflowEngine）和基于Eclipse平台的图形化流程设计器（GraphProcessDesigner）。在jBPM的发展到4.X版本时对于主流开源Java框架的兼容、集成方案已经非常多且很成熟了。图4 jbpm4的结构图2.4 相关定义为了便于后文的陈述，下面给出本文中所陈述的一些概念的定义，以免混淆：定义 1. 系统选择平台（System Selection Platform）：在本文中指用户登入成功后可以在一个平台上选择系统。定义 2. 单点登入（Single Sign On）：简称SSO，采用Cas框架，在本文中指用户只要登入一次就可以访问相互信任的网站。定义 3. 工作流（Work Flow）：工作流主要用在请假系统中的审批流程上。2.5 本章小结本章首先概述了本系统采用的web架构，接着简单介绍了本系统所使用的几项技术以及开发工具，并对使用每项技术的原因进行了简单的描述，最后对本文后面所使用到的一些名字进行了说明，以区别于往常文档中使用的名词。第三章 系统需求分析由于每个公司都有很多的部门，每个部门的需求都不一样，所以一个公司内部会有很多不同的系统，如财务系统，报销系统，请假系统等，这些系统后台使用的数据库甚至都是分开的，所以需要一个系统将这些系统整合起来。我们公司是一个外包企业，也有很多的系统存在，所以设计一个可以实现内外资源整合的高效的信息系统，将公司内部的所有系统整合起来，提升公司管理水平是势在必行的。3.1 系统介绍3.1.1 基本概念本系统是销售支持办公系统，这个系统包括一个系统选择平台，这个系统选择平台与普通的系统不同，它使用了cas单点登录框架，在加上我们自主开发的后台管理系统。其中最大的不同是普通的管理系统着眼于功能的实现和信息的管理，而系统选择平台主要目的是设计一个统一的标准并让所有系统都符合这个标准，同时这个标准要既要能实现平台功能，又不能影响各个子系统的功能实现，所以这个标准必须要有很强的灵活性。我现在我在公司里主要任务就是开发这个平台，将那些公司中已经存在的系统改造以便放入平台中。现在本系统就是包括请假系统和销售支持系统，这样就可以展示这样从单点登入到系统选择，最后退出系统这样一个全过程了。具体来说，在销售支持系统中会有合同的管理和客户的管理。请假系统采用工作流jbpm4技术，所以流程的设计可以比较灵活。可以根据不同请假种类，设计不同的审批流程。可以交给组长批，可以交给经理批，也可以交给助理审批。同时为了记录，还会向有关人发送邮件。3.2 系统角色分析3.2.1 目标用户所有在公司的员工，包括在外的外包员工和内部员工。本系统根据模块的不同会分出销售人员，支持人员，管理人员，内部员工，外包员工等。3.2.2 用户类型企业拥有一套成熟的办公软件是企业实现管理现代化的标志。用户类型就是企业中的员工，从操作系统的人员上来说人员主要分为系统管理员和普通用户。普通员工分为内部用户和外包用户。内部用户分为销售人员，支持人员，行政人员。外包员工分为外包工程师和外包顾问。销售人员分为普通销售人员和销售经理。行政人员分为普通员工，组长，和部门经理。用户具体分类如图：图5 用户类型图3.3 系统业务性办公需求3.3.1 业务性系统主要实现功能我公司是一个外包服务的公司，业务性需求主要指公司的外包业务需求，主要业务是派遣外包人员去其他公司完成软件项目。公司的业务性需求主要依靠销售支持管理系统来完成。公司中的职位主要有销售，支持，外包工程师，外包顾问，这些职位的员工相互配合来完成这些项目。销售人员主要负责与客户签订合同，支持人员主要负责根据合同的内容招聘外包工程师和外包顾问。外包工程师和外包顾问负责完成这个项目。销售人员中还分为普通销售人员和销售经理，普通销售人员可以看自己的业绩，销售经理可以查看自己下属和本人的业绩。销售经理可以对下属的业绩情况进行统计，这样就可以清楚的了解到属下业绩的基本信息。本系统主要为公司中的这些员工提供服务，增强他们的办公效率。3.3.2 系统用例分析对于销售支持管理系统，普通销售人员主要业务是和客户谈项目，签署项目，定义项目的详细定义。主要需求分为维护客户关系和项目管理。维护客户关系包括客户关系程度维护，客户信息的维护，见客户记录维护。项目管理包括项目需求管理，项目信息管理，模块信息管理。在项目信息管理时可以指定项目的支持人员。普通销售人员具体需求如图：图6 普通销售用例图对于销售支持管理系统，销售经理的主要业务和普通销售人员是一样的。但是销售经理作为领导，需要管理下属人员的销售业绩。销售经理通过统计模块来管理下属，销售经理不但管理普通销售人员也管理支持人员。统计模块可以统计下属销售业绩，支持业绩，销售会见客户记录统计，整个销售组的业绩统计。图7 销售经理用例图对于销售支持管理系统，支持人员的主要业务是配合销售人员招聘外包工程师和外包顾问。支持人员一般都是熟悉软件开发技术的工程师，他们可以根据合同的具体要求招聘合格的软件工程师，包括程序员，测试员，需求人员等。支持人员具体需求如图：图8 支持人员用例图3.4 系统非业务性办公需求3.4.1 非业务性系统主要实现功能非业务性需求是指公司的一般性办公需求，主要指请假，出差报销等与业务无关的一般需求。为满足这样的需求，我将设计并实现一个请假系统。对于请假系统，在功能方面，主要功能就是请假，包括请事假，请病假，请年假。请假时，可以保存到草稿箱，延后提交。由于采用数据流jbpm4，所以流程的设计可以比较灵活。可以根据不同请假种类，设计不同的审批流程。可以交给组长批，可以交给经理批，也可以交给助理审批。同时为了记录，还会向有关人发送邮件。既然需要审批，相关职务的用户看到的菜单和相关数据也不相同，可以根据情况选择通过或驳回。如果选择驳回请假，那么请假申请人就会看到被驳回的请假，可以根据驳回原因修改请假再次申请。根据公司的工作特点，系统会有倒休管理，经理可以给员工增加倒休。将请假系统和销售办公系统集成起来需要一个单点登入和系统选择平台。对于单点登入和系统选择平台。登入界面包括密码用户的输入，验证码的输入，还能选择记住密码。登入界面的关键不在于功能，关键在于用户名密码的保存和安全，申请路径的过滤和跳转。我想主要描述一下关于安全的设置，在登入路径上采用https加密，在密码的输入上采用MD5加密，密码每登入一次，就会根据算法将加密过的不同字符串写入数据库中。即使登入数据库直接看密码也不能看到真是密码。系统选择平台主要显示可用的系统，点击图标后进入到选择的系统，不用重复登入。3.4.2 系统用例分析对于请假系统来说，所有员工只分为普通员工，组长，经理，并且只针对内部员工，不包括外包人员，外包员工的请假由项目公司负责。销售人员，支持人员和行政人员都是一样的，只分为普通人员，组长和经理，如果只有两级，那么就是只分为组长和经理。普通人员可以请事假，请病假，请倒休等。普通人员如果请事假在两天以内，则只需要组长审批即可，如果事假超过两天，则首先需要组长审批，然后需要经理审批。请病假，请婚假，产假等都是这样，但是请倒休不需要审批。普通人员在系统中可以直接请假或者将事假放入草稿箱延后发出。在请假系统中普通人员的用例图如下：图9 普通人员用例图对于请假系统，组长请假的情况基本和普通员工相似，只是在审批流程上有所区别，不管组长请假几天，都需要经理审批。组长也可以审批下属员工的请假请求。在请假系统中组长的用例图如下：图10 组长用例图对于请假系统，经理的主要职责就是审批下属的流程，经理的请假不用审批。经理除了审批下属假期，还可以统计下属假期的情况，可以日统计，月统计和年统计，还可以据假期的种类进行统计。在请假系统中经理的用例图如下：图11 经理用例图3.5 系统用户管理性需求3.5.1 用户管理性系统主要实现功能所有办公系统都要管理用户的基本信息和权限，所以将所有办公系统的用户管理独立起来，设计并实现一个后台管理系统来管理用户和员工的基本信息。对于后台管理系统，从功能结构上来说，后台管理系统主要有用户管理模块，员工管理模块以及相关的部门，公司，职务，职称的管理模块。其中最重要的是菜单，权限管理模块，同时这两个功能模块也是最难实现的模块。公司的职位有很多，而且上下级关系也比较复杂，甚至有的员工有多个职位，而每个职位的员工权限是不一样的，看到的系统也是不一样的。权限本身也有可能相互包含或部分包含。由于要考虑这些可能出现的情况，这两个功能模块就要足够的灵活，自然也会变的复杂。后台管理系统还支持工作流，具体技术是采用jbpm4.后台管理系统上的工作流主要为其他OA系统提供工作流基础，这样每个OA系统都能拥有完整的工作流支持，也就意味着他们会有灵活的审批流程，可以满足不同OA系统的需求。3.5.2 系统用例分析后台管理系统的唯一用户类型是管理员，只有管理员才能登入系统。管理员可以在系统中管理用户信息，员工信息和权限信息。后台管理系统是其他两个系统的基础，可以依靠这个系统来管理他们的权限和用户。在后台管理系统中管理员的用例图如下：图12 管理员用例图3.6 系统非功能需求3.6.1 国家节假日的显示为方便用户在请假时查看节假日信息，这样让用户可以合理的管理自己的假期。中国的假期比较乱，每年的假期情况都不一样，只有到假期的临近时间才能了解到国家对本年度的假期安排，如国庆节。有这样一个功能就会变得很有必要。3.7 系统目标本系统核心目的就是设计一个可以实现内外资源整合的高效的信息系统，将公司内部的所有系统整合起来，从而提升其管理水平的办公系统。公司中有请假系统，公司中所有员工的请假全部在这个系统中进行，还有一个销售支持系统，主要进行合同的管理。本系统的主要目标是为方便用户只要登入一次就能登入到公司的所有系统。这样做还不仅仅只是为了让登入减少。这样可以控制用户的系统级权限，可以让每个用户可以访问的系统是不同的。3.8 本章小结主流的OA产品，项目型产品由于其过于依赖特别定制的开发方式导致办公系统的产品化生产无法实现，这种开发模式周期长、费用高、未来升级扩展的灵活度差，因而整体性价不高。而平台型OA产品则由于个性化与产品化的成功结合，使产品在满足不同企业的个性化需求同时，还大幅降低了开发费用，同时依靠定制开发平台使产品质量稳定可靠，未来升级扩展性强，具有很高的性价比。平台型OA办公软件重视系统的技术架构，使产品的各个模块之间围绕平台而联结，具有相对独立性，使产品运行更加稳定，在初期部署实施时更加易于员工上手，在日常使用时也无需专门的技术人员进行维护或解决问题，能够最大限度上为企业节省开支和时间成本，在未来扩展和升级时同样由于这种优势而为企业节约更多时间与费用。正因为此，平台型的OA办公软件产品自从推出之后，凭借其高性价比、革新的技术优势、系统安全稳定、优秀的二次开发扩展性能，更符合企业长远发展需求的特点，在成长与发展型企业之中快速赢得了认可与欢迎，目前已经在众多成长与发展型企业之中成功实施部署，为企业的快速发展提供更加持久和可靠的支持保障。所以我这次开发的办公系统就有一个系统选择平台，则可以认为是办公系统的一个平台化尝试吧。 本章详细阐述了本系统的主要特点，首先对整个系统做了简单的介绍，其次从产品期望的角度阐述了设计本系统的主要目标，然后从面向的用户群体的方向对系统的功能进行简单的阐述，最重要的是从用例分析的角度对整个系统的核心功能进行了阐述，另外还有一些特殊的需求也在本章最后部分进行了说明。总的来说，销售支持系统是一个有前景的办公系统，这个系统是我们企业的专门办公软件，完全符合企业的需求，可以大大减轻员工的业务任务，增加他们工作的便捷性和业绩的便捷性。第四章 系统总体设计4.1 设计原则由于企业的发展日新月异，随着时间的推移会不断上升到新的台阶，由此带来办公和管理方面新的需求与变革，这就对OA办公软件有了新的功能要求。在这种情况下，对原有系统进行必要的二次开发完成功能扩展就成为必然。要实现在不修改源代码的基础上来完成新功能的扩展，这就能使二次开发不会影响到企业正常的使用，这样就能在不影响原系统运行的情况下，由企业自由的新增公司独立开发新的功能模块。4.2 系统软件结构图图13 系统结构图系统结构为系统的软件结构，系统结构图展示了对于不同种类的用户，系统对于他们的软件结构是不同的。同时，系统结构图也很好的介绍了用户在进入到系统中以后，可以进入到不同的系统中，而这些系统又是如何从数据库和日志数据库中获得信息的。4.3 系统物理结构图图14 系统物理结构图系统物理结构图主要是展示系统的物理部署，通过系统物理结构图可以理解到每个系统的物理部署，以及这几个系统之间的数据传递和用户如何从系统中获得自己想要的信息。这次的办公系统包含一个系统选择平台，通过系统物理结构图就能很清楚的了解到请假系统，后台管理系统，销售支持管理系统可以部署在不同的服务器，然后通过系统选择平台将这些系统连接起来。4.4 系统流程图普通用户流程图如下：图15 普通用户流程图管理员用户流程图如下：图16 管理员用户流程图4.5 销售支持管理系统功能模块划分4.5.1 系统功能模块总图图17 销售支持管理系统功能图4.5.2 项目管理模块项目管理模块是销售支持管理系统的核心模块，主要负责项目的生成，项目信息的管理，项目进度的控制，包括进入项目的外包工程师和出项目的工程师的信息管理。项目管理模块主要有以下功能：l 项目需求管理销售人员可以新建项目需求，普通销售人员和销售经理都可以新建项目需求，也可以修改项目需求。当销售人员与客户谈过项目以后，需要把这个项目的需求和项目的基本信息通过这个模块导入到数据库中，方便以后根据这个需求招聘外包工程师。l 项目信息管理项目信息管理除了管理项目的基本信息，还管理项目的进度。销售人员可以根据项目的进度，决定是否更换支持人员，或者催促支持人员。l 模块信息管理模块信息管理主要负责模块进度和基本信息的管理。一个项目由几个模块组成，项目的进度在项目信息模块中管理，而在模块信息管理中可以具体的管理每个模块的进度，可以更好的了解到项目的进度细节。l 顾问信息管理在顾问信息管理模块中主要管理顾问的基本信息，例如姓名，职位等，尤其是顾问的状态。顾问的状态提示他是否在项目中，还是即将进入项目，或者已经出项目。这个模块只有支持人员使用，销售人员不使用。l 工程师信息管理在工程师信息管理模块中主要管理顾问的基本信息，例如姓名，职位等，尤其是工程师的状态。工程师的状态提示他是否在项目中，还是即将进入项目，或者已经出项目。这个模块只有支持人员使用，销售人员不使用。4.5.3 客户管理模块客户管理模块是销售支持管理系统的核心模块，这个模块主要是销售人员使用，销售人员通过这个模块维护客户信息，维护客户关系，维护客户的见面记录。主要可以实现以下功能：l 客户关系维护销售人员可以根据自己与客户签的合同，对于客户有一个大概的了解，可以在客户关系维护模块中管理客户的亲密度。l 客户信息维护销售人员可以在客户信息维护中管理客户的基本信息，如客户公司，客户性质等基本信息。这些信息可以为客户关系维护模块提供基础。l 客户记录维护销售人员每见一次客户都要在客户记录维护模块中记录这次见面，要把这次见面的地点，时间，客户名称记录下来。这样，销售经理可以知道下属的具体工作。4.5.4 统计模块统计模块主要是销售经理使用，销售经理可以通过这个模块统计下属销售人员和支持人员的业绩，也可以统计整个小组的总业绩。l 下属业绩统计销售经理可以统计下属销售人员的业绩，可以清晰的看到每个下属的业绩情况。l 支持业绩统计销售经理可以统计支持人员的业绩，支持人员的业绩就是项目的完成度，项目中外包工程师的到达率。l 客户记录统计销售经理可以统计下属销售人员的客户会见记录，可以通过这些数据了解到下属人员的勤劳度，为他们的业绩做出判断。l 总销售业绩统计销售经理可以统计整个销售小组的业绩。销售业绩目标是以整个小组为单位的，统计整个小组业绩可以清晰的看到销售目标的完成度，可以有效的控制整个销售小组的销售进度。4.6 请假系统功能模块划分4.6.1 系统功能模块总图图18 请假系统功能图4.6.2 假期管理模块假期管理模块是请假系统的核心模块，主要负责假期的申请，批准，驳回，修改等功能，用户可以在这个模块中根据权限的不同拥有不同的功能。假期管理模块主要有以下功能：l 事假申请用户可以申请事假，事假没有什么条件，但是审批的流程会因为事假的天数有所不同。如果事假两天一下，只要组长批准就行。如果事假两天以上，不仅需要组长批准，还需要部门经理批准。l 倒休申请用户可以申请倒休，倒休是由客户经理添加的。倒休是对员工加班的一种补偿，所以员工的初始倒休数量是零。只有当倒休数量不为零时，才能申请倒休。l 假期批准/驳回如果该用户是组长或部门经理，那么该用户就可以批准或驳回组内员工的请假申请，但是驳回请求时需要填写驳回理由。被驳回的用户可以修改请假理由再次申请。l 假期修改当用户自己的事假申请被驳回时，用户可以修改假期，可以修改假期的日期，也可以修改假期的理由，再次申请。l 假期草稿箱用户在写完假期申请以后，如果不想立刻申请，还要考虑一段时间，就可以将这次假期申请放入草稿箱，在需要的时候再发出申请。4.6.3 统计模块统计模块主要是经理使用，经理可以统计当天的请假情况，控制请假人数，保证不会因为在同一天请假的人太多而导致项目无法按期完成。还可以对某个员工进行月统计和年统计，可以了解到这个员工是否经常出差，当然也可以按某种类型统计，如统计事假，病假，倒休等。4.7 后台管理系统功能模块划分4.7.1 系统功能模块总图图19 后台管理系统功能图4.7.2 菜单管理模块后台管理系统中中最重要的是菜单，权限管理模块，同时这两个功能模块也是最难实现的模块。公司的职位有很多，而且上下级关系也比较复杂，甚至有的员工有多个职位，而每个职位的员工权限是不一样的，看到的系统也是不一样的。权限本身也有可能相互包含或部分包含。由于要考虑这些可能出现的情况，这两个功能模块就要足够的灵活，自然也会变的复杂。菜单管理模块主要有以下功能：l 菜单信息编辑用户在这个模块下可以编辑菜单的名称，上传菜单图标以及定义菜单的优先级，序号等，这样可以让用户的菜单顺序固定。l 主题选择系统会制定一些颜色搭配的界面风格以及一些默认的背景图片供用户选择。用户可以选择菜单的界面和风格4.7.3 角色管理模块后台管理系统中角色管理与菜单，权限管理模块有很大的关系，角色是菜单和权限之间的桥梁。可以为某个角色赋予一些菜单的权限，这样可以实现角色与权限的多对多的关系。角色管理模块主要有以下功能：l 角色信息编辑用户在这个模块下可以编辑角色的名称。l 角色与权限绑定信息编辑用户在这个模块下可以编辑角色与权限绑定的信息。一个角色可以对应多个权限，角色与角色之间可以有权限的重合。4.7.4 职称，职务，部门管理模块职称，职务，部门管理模块的功能操作比较相似，都只是对公司基本信息的配置，只是在配置这些信息的时候必须要考虑实际情况，不能随意编造信息，同时又要保证信息的完整。例如在部门管理中，所有的部门信息必须都要在里面，否则会造成其他模块的无法使用。这些模块主要有以下功能：l 职务信息编辑用户在这个模块下可以编辑职务的名称。l 职称信息编辑用户在这个模块下可以编辑职称的名称。l 部门信息编辑用户在这个模块下可以编辑部门的名称。4.7.5 员工管理模块员工管理模块属于一个基本模块，这个模块主要管理员工的基本信息例如部门，职称，职位，姓名，地址等信息。这个模块也是后台管理系统的核心模块，其他所有模块其实都是为这个模块服务的，其他模块必须绑定到某个用户才有意义。当这个用户拥有这些信息以后，就能成功的登入到请假系统和销售支持系统，这些系统就能够分辨出用户的类型和权限，为用户显示菜单。员工管理模块主要有以下功能：l 员工基本信息编辑用户在这个模块下可以编辑姓名，地址，部门等信息。l 用户信息编辑用户在这个模块下可以编辑自己的账号密码。l 用户和角色关系编辑用户在这个模块下可以编辑该用户和角色间的关系。4.8 难点与关键技术的设计方案4.8.1 假期计算的实现方案我遇到主要技术难点集中在请假系统。这个系统是一个请假系统，所以这个系统的核心算法就是假期的计算。这个假期的计算其实是十分复杂的，首先要计算有效的请假开始和结束时间。请假时间开始时间和结束时间必须在有效工作时间内，还要根据公司的要求转换成小时数，因为假期小时数与工作薪资有直接关系。中国的法定假期设置又非常复杂，有公历法定假期像国庆假，也有农历法定假期，像中秋节，端午节。中国还存在的调休机制，虽然每个国庆节每次都放七天，但每次的调休方案都不一样。如果无法准确的计算出法定假期，那就无法计算出有效假期。我对与这个难点的预定解决方案是先解决法定假期问题。我打算建一个法定假期表，将平时的周末也视为法定假期，并将这作为默认数据。我也会为这个法定假期表设置一个管理模块，可以按实际情况设置法定假期，这样就可以适应中国复杂的假期系统了。然后将请假开始和结束时间中去掉多余的无效时间，留下有效开始和结束时间，以我们公司为例，就是上午九点和下午六点，还要扣掉中午休息的一小时。以假期为分界点，将请假时间分割成几段有效假期，然后将这些时间段相加算出总的有效时间，最后将他们转换成小时数。4.8.2 基于JBPM4工作流审批流程的实现方案工作流的流程设计也是个难题。工作流主要解决审批的流程管理，而OA中的审批流程又比较复杂，所以如何设计流程就是个难点。例如，请假的流程需要项目组长和项目经理同时批准才能生效，但是如果组长驳回了，但是经理没有审批，既没批准也没驳回，那么这条记录是就此驳回还是等经理有了决定再驳回。如果组长驳回，经理审批，那么当用户修改后再次提交后，经理还需要再次审批吗。驳回到哪里还是个问题，是驳回到请假申请人还是用户。因为有一种情况是请假的人不是本人，是由别人代请的。驳回给本人的话可能本人不在无法修改，驳回给用户，逻辑上不合理。所以工作流的难点不在程序上，而在逻辑上。对于这个难点，我的预定解决方案是组长和经理不管是谁驳回，这条请假请求就被驳回，且驳回到本人。当然还需要判断请假的用户与请假申请人是否是同一个人。如果不是同一个人，则打算给两个人同时发邮件提醒。以便申请人可以及时修改并提交。4.8.3 倒休管理功能的实现方案倒休管理也是个难点。倒休管理是经理的专门模块，主要是考虑到可能有员工加班的问题，需要给他们一些倒休，这些倒休可以代替事假。倒休管理的难点在于倒休的失效，倒休加给你了，你不用，不能无限的积累，倒休需要一个有效期。可是这个有效期会严重影响有效假期的计算。这个有效期具体怎么算其实是个问题，是设置统一的日期一年，还是每个由经理自己写。如果一次事假包含两次不同的倒休，且不是全包围又怎么办。这个难点还要以后设计的时候根据需求来解决。4.8.4 单点登入的路径转换和session转移为了实现单点登入，主要是使用了耶鲁大学的开放框架Cas。Cas框架可以实现很多功能，包括MD5加密和Session过期的验证跳转。但是Cas的原理是不同路径的网站被拦截进入到一个登入界面，而现在主要实现的是一个网站要引导到不同的网站。需求与他的实现原理有很大的不同，所以需要改造。需要设置一个中间地址，先将所有不同的地址都跳转到这个地址，然后再设置一层过滤器，再将这个地址根据要求分别跳转到其他地址。这就需要多重路径过滤器。还有就是Session的转移，每个系统都需要在Session中放入用户信息，但是Session中的用户信息不一定相同，所以需要设计拦截器，将Session中的用户信息传递到不同系统的Session中。所以路径拦截器的设计很重要，他们的顺序也很重要，每次路径跳转只会有一个拦截器起作用。4.9 运行环境4.9.1 硬件环境1. 服务器端本系统服务器端的配置如下：处理器：Intel core i7 或更高内存：8G硬盘空间：1T网络：100 Mbps 或以上2. 客户端本系统客户端的配置如下：处理器：Intel Pentium III 667Hz 或更高内存：256MB硬盘空间：20GB显卡：SVAG 显示适配器网络：100 Mbps 或以上4.9.2 软件环境1. 服务器端操作系统：Windows Server 2008 网络协议：TCP/IPWeb 服务器：Apache Tomcat 6.0.16数据库：Mysql 5.52. 客户端操作系统：Windows XP/vista/7网络协议：TCP / IP浏览器：Internet Explorer 7.0 及以上4.10 本章小结本章通过对整个销售支持办公系统的各个功能模块的介绍，阐述了整个销售支持办公系统的设计思路，清晰的介绍了本系统的整体作用于预期成果。由于企业的发展日新月异，随着时间的推移会不断上升到新的台阶，由此带来办公和管理方面新的需求与变革，这就对OA办公软件有了新的功能要求。我根据这种对办公系统的新要求，对销售办公系统设置了如上的总体设计。第五章 系统详细设计5.1 系统实现技术框架本系统采用MVC即（Model-View-Controller，模型-视图-控制器) 的架构，将系统分为系统表示层、应用服务层、数据持久层三个层次，现分别对其进行阐述：5.1.1 系统表示层实现技术图20 系统表示层流程图系统表示层是距离用户最近的一层，这一层的主要功能是向用户提供一个交互界面，接收用户发出的请求，并对请求做出处理，最后将处理结果返回用户并在页面上展示。在本系统中主要通过 StrutsAction、ActionForm、Struts-config.xml、JSP、Ajax这些技术来实现。为了增强用户体验并减少服务器带宽的压力，本系统在表示层采用了大量的Ajax无刷新的技术，包括Form表单的异步提交功能。Form表单的异步提交功能主要是使用了Jquery类库的AjaxForm。5.1.2 应用服务层实现技术应用服务层是本系统的核心组件层，他负责系统的主要业务。下面对核心的日志管理、数据处理以及数据通讯等组件做简单介绍。1. 日志管理。本系统采用开源的log4j的日志组件，log4j使用非常容易使用，只需要引入相应的类包，并在perties文件中对相应的功能进行相关配置即可实现在java文件中调用日志记录。Log4j使用起来非常容易，但是想要真正用好它，起到该记录的日志一条不漏，不该记录的日志一条不记还是需要花很多功夫的，要不断的在实践中体会，抓住程序的关键点进行日志记录才是关键。2. 数据处理。本系统需将用户在前台系统输入的数据对应到model层的相应模型中去。而且对控制层的响应很多时候需要输出结构化语言json，这样就需要对数据库中的数据再次结构化以后转换成json数据再传往前台页面。在图片处理方面，也是对控制层提交的图片流数据读取后进行编码计算，并进行缩放或者裁剪，然后保存在文件系统中，并将转化结果回传给控制层。5.2 销售支持管理系统详细设计方案系统主要通过Java来实现，并采用SSH框架，MVC三层结构。具体来说分为实体层实现，控制层实现和服务层实现。这三层是依次调用的，不可以跃层调用。服务层调用控制层，控制层调用实体层，实体层的实体类与数据库中表的表一一对应。5.2.1 实体层设计实体层是三层结构中的最底层。实体层便于将数据库表映射为一个类，这个类包含所有的表字段方便于程序的各层使用，更适合面向对象的思想使用。在销售支持管理系统中主要有两种用户类型，分为销售人员和支持人员。销售人员与客户谈合同，一个项目可能有几个合同，每次谈合同都需要把合同的信息和见面记录下来。对于支持人员，主要对象是项目和模块。一个项目有几个模块，每个模块都有功能，每个模块都有进度。对于某个项目来说，外包工程师可以进项目，也可以出项目，当工程师出项目后，他的信息会进入到历史工程师信息表中。销售支持管理系统的实体层类关系图如下：图21 销售支持管理系统实体层类图5.2.2 控制层设计控制层主要负责对数据库数据的删除，添加，修改，过滤等操作的封装。控制层的每个类对应一个实体层的所有操作，类中的每个方法对应一种数据库操作。控制层主要依赖于Hibernate框架，一般操作都不用编写SQL语句，只需要直接调用框架的内部方法即可。在销售管理系统中分为销售的控制层和支持的控制层，他们的类是分在两个文件夹中，这样可以方便开发和管理。所有的Dao层类都继承于AbstractHibernateDao这个类，AbstractHibernateDao是对Hibernate基本类的再次封装，加强对数据库的操作控制，例如前台展示总是需要分页显示，所以不能一次将结果全部查出，而且每页的条数也是可以控制的，所以需要再次封装，方便使用。销售支持管理系控制层和服务层类图如下：图22 销售支持管理系统控制层和服务层类图5.2.3 服务层设计服务层主要是针对前端服务的，他与控制层不同，控制层主要是针对数据库操作的。前端页面需要一个服务，服务层就需要一个方法与之对应。一个服务可能比较复杂，需要多次对数据库操作，从数据库中拿到数据后可能还需要进行数据处理，如对数据进行排序，去重等。前端对数据的格式要求也是不一样的，有的需要是JSON格式，有的需要是SJSON格式，有的需要是XML格式。将数据库中的信息转化成前端需要的格式也是服务层必须实现的功能。在销售支持管理系统中，模块，工程，外包工程师，工程需求等实体类信息由于经常需要在前台页面显示，而显示的内容与实体层的实体类的内容不相同，一般来说显示的内容比对应的实体类的内容多，而且可能一个表现层类可能包含几个实体类的内容，如果使用不是很频繁，不需要表现层类。销售支持系统表现层类图如下：图23 销售支持系统表现层类图5.2.4 数据库层表设计销售支持管理系统中主要的对象就