基于SSH的任务调度系统的设计与实现

基于SSH的任务调度系统的设计与实现摘 要随着科学技术的飞速发展和各行各业的分工愈发明细化，对于改革传统的人工任务调度方式的呼声越来越大。得益于快速发展的计算机技术，我们看到了改革的方向。本系统是针对企业或者事业单位甚至一个小团队的任务调度而设计的，目的是改变传统的调度方式，通过计算机来计算各项任务的最佳人员分配和最佳时间分配，绘制出任务调度图，以此更好地进行各项任务的调度和团队协作，该系统是一种任务调度系统。本系统采用了B/S体系结构，主要实现语言是JAVA，后台数据库使用的是MySql。整个系统实现角色将分为组长和组员，实现功能包括帐号注册、修改信息、项目管理、任务管理、消息管理、团队管理等功能。本任务调度系统的设计实现可以远程实现任务的调度与科学分配，并通过评估各项任务与参与人员，来使项目更好的进行任务调度。关键词： 任务调度；B/S；SSHDesign and Implementation of Task Scheduling System Based on SSHAbstractWith the rapid development of science and technology and the division of labor in all walks of life more and more refined, for the reform of the traditional task of scheduling tasks more and more. Thanks to the rapid development of computer technology, we see the direction of reform. The purpose of this system is based on the design and implementation of the task scheduling system based on SSH, which is designed for the task scheduling of enterprises or institutions or even a small team. The purpose is to change the traditional scheduling mode and calculate the most Good staff allocation and the best time allocation, draw the task scheduling map, in order to better carry out the task scheduling and team collaboration, the system is a task scheduling system.The system uses a B / S architecture, the main realization of the language is JAVA, the background database using MySql. The whole system implementation role will be divided into group leader and team members, to achieve the functions, including account registration, modify information, project management, task management, message management, team management and other functions. The design and implementation of the task dispatching system can realize the scheduling and scientific allocation of the task remotely, and make the task plan be carried out by evaluating the tasks and the participants.朗读显示对应的拉丁字符的拼音字典Keywords: Task scheduling; B/S; SSH目 录摘 要IAbstractII目 录III1 引言11.1 课题研究意义及背景11.2 论文的目的及设计要求12 研究现状及设计目标22.1 任务调度系统的现状22.2 任务调度系统优缺点分析22.3现行研究存在的问题及解决方法22.3.1 现行研究存在的问题22.3.2 解决办法32.4 本课题要达到的设计目标32.5 经济效益分析43 关键问题及分析53.1 问题分析与设计53.1.1 核心问题即任务调度53.1.2 数据表间联系63.1.3 系统安全性64 调度算法设计75 需求分析85.1 USE-CASE用例图85.2 类图85.3 活动图95.4 功能需求105.5 开发环境105.6 系统交互图115.6.1 系统架构类交互图115.6.2 系统协作图125.6.3 系统状态图136 系统设计156.1 系统体系结构156.2 系统功能结构156.3 系统架构的设计目标166.4 系统架构设计166.5 数据库表结构176.5.1 数据库设计原则176.5.2 数据库设计概述186.5.3 数据库设计周期186.5.4 数据字典197 系统实现217.1 公共模块217.1.1 模块功能217.1.2 模块代码217.2 注册模块267.2.1 模块功能267.2.2 模块代码267.3 登录模块297.3.1 模块功能297.3.2 模块代码297.4 搜索模块317.4.1 模块功能317.4.2 模块代码317.5 项目管理模块337.5.1 模块功能337.5.2 模块代码337.6 任务调度模块407.6.1 模块功能407.6.2 模块代码408 结论与展望49参考文献50致 谢51VI1 引言在实际生产生活中，许多项目是由多个任务组成的，并且这多个任务存在约束关系，有一类约束关系为树状的约束关系，小至产品，大至广场的修建。如产品由工件装配而成，而工件又由一系列精加工任务组成，再如广场由各类功能区组成，而各类功能区又由一系列建造流程租出。所以任务调度是各行各业都离不开的，在以前这些工作都由人力完成，或者采用低效的任务调度策略。到了现在，各行各业都在运用计算机进行复杂计算或自动化处理事务，计算机能够进行快速复杂计算，可以实现远程办公，团队协作，并有将数据可视化的能力。使用计算机并且加上高效的调度策略，不仅能提高工作效率，还能进行更科学更客观的分配。计算越复杂，计算机的优越性体现的越明显。在多任务的项目中，计算机可通过各类算法，如关键路径算法或多机调度算法，来进行任务评估和总体任务调度，计算机与人们的生产生活密切相关，故现在开发任务调度系统。本系统运用了当前的流行框架Spring，Struts2，Hibernate，保证了可扩展性与可维护性。1.1 课题研究意义及背景虽然科技进步在改革开发这几十年来速度飞快，计算机行业也发展迅速，但仍然有大量商家或企业，甚至项目组，采用落后的人工管理方式或者低效的任务调度策略，这无疑是对计算机的一种无视。计算机处理信息的准确度与高效率远远超过人类，在团队协作中项目又可以被分成一个个小任务。故此，本人开发这套基于SSH的任务调度系统，使团队协作与任务分派更加科学高效，进而促进企业经济效益的提高。1.2 论文的目的及设计要求任务调度系统主要目的是对企事业单位项目的任务集进行调度分配，敏捷高效地处理任何或大或小的项目。使项目小组的工作效率大大提高，工作成本大大降低。本系统开发主要包括调度算法的设计，后台程序的处理，后台数据库的建立和维护，和前端页面的展示开发。算法要求高效性和可实现性，后台要求业务逻辑的合理性与科学性，数据库要求数据的完整性和一致性，前台页面又要求美观性与功能完备性。正因为此，本人选择采用SSH三大框架的整合技术和MySQL数据库进行系统的开发。本系统的实现角色将包括项目组长和项目组员这两个角色，用户可同时扮演两种角色，共有的功能包括修改登录密码、发起项目、删除项目、参与项目、添加任务、删除任务、添加成员、删除成员、处理消息。其中组长部分的功能还包括组员管理、更新项目，其中组员部分的功能还包括申请加入与申请退出。并且，不光保证实现这些功能，还得为本任务调度系统提供一个良好的人机交互，提高系统友好性。2 研究现状及设计目标2.1 任务调度系统的现状长久以来一般的大小项目组均采用传统的人工方式或者低效的调度算法来负责项目任务集合的日常管理工作，在以前，也就是计算机尚未普及前，基于树状任务集的项目的管理方式是人工管理，这样的缺点是显而易见的，效率低下并且错误率高。如果我们应用计算机来代替落后的人工管理方式，无疑会极大程度地提高效率和准确率，使我们更加精准的管理项目。目前存在的调度算法多以时间轮转为主，虽然保证了项目树状结构的横向，但忽略了纵向。针对这个问题，本文提出了更优秀的调度算法。2.2 任务调度系统优缺点分析1优点(1) 采用可扩展性强、分离度高的B/S模式。(2) 数据库选用了市场上应用广泛的关系型数据库。(3) 界面美观大气，操作逻辑科学合理。2缺点(1) 软件稳定性有待提高目前，B/S模式已经广泛应用于网站和系统建设，但同时，B/S模式也存在着很多需要我们注意的问题，如并发性操作、大数据量访问等，这就很考验系统的设计和代码，因为他们会极大影响软件的稳定性。另外，软件行业中，版本更迭是非常常见的，但在更新版本的过程中，因为没有进行良好的交接，很容易造成系统的不稳定，为后期的维护工作带来巨大的困难。(2) 存在安全隐患B/S模式系统中的B是浏览器的意思，暨客户端操作是通过浏览器进行的，而浏览器又常采用脚本模式，脚本语言目前尚未完善，所以存在一些安全隐患。2.3现行研究存在的问题及解决方法2.3.1 现行研究存在的问题1. 调度系统形式落后多以人工为主进行项目任务的调度，没能做到与时俱进，采用计算机和网络来进行调度。2. 调度算法低效暴力先行算法多以时间轮询为主，忽略了任务可并行以及树状结构任务调度以纵向为主的机理。3数据库选择问题市面上的数据库种类繁多，从这么多中选出一个适合本系统、拥有强大功、移植性强的数据库是非常重要的。选择时必须保证它可以有效的与其它数据库结合，降低系统的特定数据库的依赖，增强软件的可移植性。4可扩展性 因为需求的增多减少，或者弥补系统现有缺陷，程序进行修改和升级是必然的，这就要求程序具有良好的可扩展性。5开发平台和语言选择一个良好的的开发平台和适合本系统的语言能够降低开发成本，延长生命周期。2.3.2 解决办法考虑到目前任务调度系统的需求与研究现状，想要解决上述问题应该从以下几方面的要求出发：1数据库选用MySql，足以保证数据存放的持久性，当存储设备改变时，不用重写程序代码就可以方便的移植过去。2系统实现模式采用B/S架构，实现过程也做到模块化，把用户界面与跳转逻辑分开，把业务信息又按应用功能分开，同时与数据交互层分开，任一方的改变都不会过多影响对方。3开发平台选用Eclipse，语言选用JAVA作为主要的开发语言，该语言一次编写随处运行以及强大的可伸缩性对于系统的开发和维护提供了强有力的保障。4设计一个能兼顾树状任务集纵横两个方向的调度算法，充分利用参与人员的时间空档，来缩短整个项目的完成时间2.4 本课题要达到的设计目标本课题采用B/S模式，面向或大或小的项目管理而开发的任务调度系统，为了系统的安全性，该系统只允许已经注册到该系统的用户使用。系统有两种角色：项目组长和项目组员。各用户可同时承担所有角色，各角色功能如下：1.共有功能：a、注册、登录功能，个人信息管理功能，如对密码的修改。b、部分项目管理功能，实现了对项目的管理操作，包括对项目的搜索、查看操作。c、部分任务管理功能，实现了对所有项目任务的管理操作，包括对任务集的查看操作。2项目组长：a、具有管理组员、处理申请功能b、具有部分项目管理功能，包括对项目的删除操作。3项目组员：a、具有申请加入与退出项目组的功能。2.5 经济效益分析本任务调度系统是针对项目组任务调度和团队协作而开发的，一方面因为系统的人机交互界面的友好型和功能的全面性，工作效率与沟通成本均能得到较大改善，另一方面，系统开发运行成本低，所以经济效益是不言而喻的，能够用低成本得到高回报。3 关键问题及分析一个相对成熟的系统，对于稳定性和安全性都有很高的要求，本系统也不例外，所以本系统应用分层思想，通过前后台分离开发，来保证系统的稳定性与安全性。考虑项目组长和组员进入系统后功能需求的不同，需要对各用户类型的不同功能做详细分析。3.1 问题分析与设计在本次系统的设计中，势必会遇到许多以前没遇到过的问题，会需要许多曾经没有接触过的技术去攻克难点。所以，现将研究设计中要解决的问题总结如下：3.1.1 核心问题即任务调度此次所研究的问题是在3个约束下使由树状任务集组合而成的项目所用时间尽可能短。3个约束指的是：(1)对于每个任务, 必须等待其所有的前继任务完成后才能处理此任务;(2)对于每个组员, 任意时刻只能进行一个任务, 且必须满足完成一个任务后才能开始另一个任务;(3)不存在相同任务。1、任务树和任务分类由于项目的任务图呈树状结构，仅仅边的方向与正常的树相反，姑且可称之为任务树。任务树上的结点代表任务，有向边代表任务之间的次序关系。其中，叶结点任务为刚开始就可被进行的任务，根结点任务为最终进行的任务。当根结点任务完成，标志着整个项目完成。设有一个项目, 项目由N任务组成.这N个任务可绘制出树状结构。在某个任务完成后, 剩下的未完成任务仍可绘制出树状结构。由任务树和问题的约束条件可知, 初始时只能调度某个叶节点任务.当某个任务结点的所有子节点任务全部完成, 则此任务结点就转换为叶节点任务。 现在分类任务:可调度任务是属于某空闲组员的叶节点任务;1 谢志强, 杨静, 周勇,等. 基于工序集的动态关键路径多产品制造调度算法J. 计算机学报, 2011, 34(2):406-412.准可调度任务是属于某非空闲组员的叶结点任务;不可调度任务是所有非叶节点任务;所有可调度任务和准可调任务的任务集为备选任务集2 谢志强, 杨静, 周勇,等. 基于工序集的动态关键路径多产品制造调度算法J. 计算机学报, 2011, 34(2):406-412.附录：外文资料Java Web Services ArchitectureWhat Are Web Services?A Web service is a software application identified by a URI, whose interface and bindings are capable of being identified, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via Internet-based protocols. A Web service is simply an application that exposes a function that is accessible using standard Web technology and that adheres to Web services standards. This is significant because Web services are developed for and deployed onto any platform using any programming language. There is nothing revolutionary or exceptional about the technology of Web services. The technology is simple. In fact, you use and probably have developed applications already that incorporate most of the technologies of Web services.Chapter 3: Component-Based Service DevelopmentDesignAfter the requirements analysis is complete, the design phase can begin. You do not have to wait until all the requirements have been documented before beginning the design phase. During design, you will identify areas where the requirements are incomplete and where more information is needed. Requirements, design, and implementation should be done in small increments to create the service. In each phase, new information will require a change to previous phases. During the design phase for an application,1、The services that make up the application must be designed.2、The design of the services in the service layer must support QoS requirements identified during requirements analysis.3、The design must also support the functional requirements that were identified.4、The design must support the feature list and use cases.5、The design must map to the business architecture and the conceptual service model.6、Existing services that can be reused must be identified.ArchitectureOrganizations that set up a services product line establish a set of core assets for building services. For purposes of discussion, we group those assets into three distinct architectural viewpoints, shown in Figure 3.5: application architecture, technical architecture, and process architecture. Each architectural viewpoint consists of artifacts that address that particular concern.Application ArchitectureApplication architecture for the component-based services layer consists of the artifacts that guide and provide the vision for the design and implementation of services. Some of these artifacts include conceptual architecture, frameworks and libraries, baseline architecture, developer guides, and blueprints. These artifacts determine the software architecture of the services in the service layer. The conceptual architecture provides a description and diagrams of the various layers within a component-based service and how those layers collaborate to provide a functioning service.When an organization sets out to develop a services layer for applications, it usually creates a set of frameworks to help developers create services. These frameworks implement the conceptual architecture. The frameworks give the service developer plug points to provide functional code in each layer of the service. They also dictate the way messages pass between layers. The framework provides additional features that separate the functional developer from many platform details, so a developer who writes functional code does not need to worry about too many technical details of the execution environment. A good services framework will let the functional service developer focus on implementing the solution to the business problem rather than creating solutions to technical problems.Once the framework is complete, the architect selects a set of architecturally significant use cases to implement the baseline architecture. The use cases should be sufficient to eliminate technical risks from the project. They should be selected to demonstrate that the nonfunctional requirements could be met. In most cases, only a few use cases will be selected, and the baseline architecture will fully implement them. They should demonstrate a thread through all layers and tiers of the architecture and provide enough of a demonstration of the architecture to permit successful development of the system.In addition to conceptual architecture, frameworks, and architecture baseline, the architecture should also include detailed developer documentation. This documentation gives functional developers the information they need to implement the rest of the use cases for the component-based services. Also, in a typical product line, a set of blueprints should be developed that contains a sample application for developing services. These blueprints show the best practices for using the frameworks to develop services using the product line assets provided.Layered Architecture A conceptual architecture for a services layer is a model that depicts a layered architectural style. Each layer in a layered architectural style is a package of software that has a well-defined interface and a few well-known dependencies with other layers. Each layer implements one technical function within the service. For instance, a data access layer is responsible for encapsulating the technical means for accessing a database. All data access requests to a database go through the data access layer for that database. The data access layer has the responsibility of hiding the data access mechanism from upstream layers.In a closed layer system, a layer may only access adjacent layers. In an open layer system, layers may access any other layer in the system, not just the ones they are adjacent to. We recommend the open layered architectural style for J2EE service development. This gives developers the ability to interchange layers, which greatly improves the services maintainability. If one layer changes, and the new layer supports the same interface contract as the one it is replacing, adjacent layers dont necessarily need to change. The layered architectural style also facilitates parallelism in development. Once the contracts have been defined for each layer, multiple development teams can implement each layer independently. As long as the contract for each layer is not broken, an integration task at the end of the project is all that is necessary to complete development. The conceptual architecture for a typical component-based service consists of six layers, shown in Figure 3.6.The conceptual architecture for a typical component-based service consists of six layers. Proxy Layer The proxy layer follows the classic proxy design pattern from the Gang of Four book (Gamma et al. 1994). The J2EE patterns book (Alur, Crupi, and Malks 2001) calls this layer the Business Delegate. The proxy layer consists of local objects that the consumer of the service uses to access the service. The proxy abstracts all the details of looking up the service and invoking the remote method. It provides a strongly typed interface for the service client, which will not allow the client to send incorrectly typed data. If a service requires an integer and a string, the proxy will ensure that the client uses those data types.The client uses local native method invocation on a local object. For instance, a bank account service proxy will have a method called debit account with a bank account number String and a BigDecimal amount argument. The proxy looks up the URL of the bank account service in a registry, translates the arguments into a SOAP XML message, and posts it to the service. The service proxy handles all the complexities of registry lookup-SOAP, XML, and URL connections. The service developer creates proxies for any client who wishes to use the service. For instance, if a Java client, Visual Basic client, and Perl script all need to access the service, the developer provides a proxy for each one, to make accessing the service as easy as possible.An alternative to creating a different proxy for each service is to use a dynamic proxy. A dynamic proxy uses a WSDL contract specification to dynamically provide strongly typed methods that match the WSDL specification. It uses reflection to create methods that match the specification in the WSDL document. This technique allows the developer and consumer to use a single proxy for all available services.Service Faade The service faade receives the service request, transforms it into a native method call, and invokes the proper method on the component. It adapts the component for use in a service-based environment. For instance, JAX-RPC is itself a service faade layer. It accepts a SOAP message and calls a stateless session bean with the arguments from the SOAP message. It also formats the results from the call to the stateless session bean into SOAP and returns it to the proxy. The service faade understands the protocol and data format of the services environment in a Web services environment; this is typically SOAP and HTTP. The service may have multiple service faades for each protocol type the service supports. For instance, a service might use both JAX-RPC to expose services via HTTP as well as a message-driven bean that accepts a SOAP message over JMS. The service faade layer may also translate the SOAP message into a ValueObject passed to the session faade for execution.Session Faade The session faade layer implements the distributed interface for the component. For instance, a stateless session bean that executes the logic for a bank account service has a session faade. It supports Remote Method Invocation (RMI) for the component interface. The session faade does not implement the business logic itself. Instead, the session faade dispatches the request to the business logic layer for execution. The session faade understands the native protocol and data format for the component.Business Logic The business logic layer contains objects that execute the business functions. The Command pattern should be considered to implement these objects. With the Command pattern, each use case in the requirements document is implemented as a separate command or set of commands executed in the business logic layer. Each command object implements a command interface. The command interface has a simple execute (ValueObject) method. A value object contains just data, no business logic, and is meant to transfer data from one tier or layer to another. It has simple attributes and getters and setters. It is built from the SOAP message passed in to the session faade layer.Each command object has business logic in its execute method. The value object argument for the execute method contains the request data required for executing the use case command. The typical execute method performs functions such as accessing the data access layer, executing the business logic, and returning a value object that contains the results of the use case to the session faade.At a typical UML diagram for a session faade and business logic layer，the business logic commands are executed by the session faade, which implements a CommandInvoker interface. Command invokers are responsible for creating the correct command, executing it, and returning the results to the upstream layer.Data Access Layer The business logic layer commands do not access resource systems directly. They do so via the da