办公系统网页设计 第1篇
可行性分析（Feasibility Analysis）也称为可行性研究，是在系统调查的基础上，针对新系统的开发是否具备必要性和可能性，对新系统的开发从技术、经济、操作的方面进行分析和研究，以避免投资失误，保证新系统的开发成功。可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。
与其它的系统相比，本系_立性相当强，只需要投入较少的资金即可。而它的成功运行将节省大量的人力物力，使原来从事这方面工作的人员可以投入到更为实际的工作中，提高各部门的工作效率，而且对于任何一个企业来说，投入这样一个系统在经济方面绝对可行。
针对目前的编程语言而言，目标系统比较适合采用流行的JAVA语言进行编写。JAVA 是 SUN 公司推出的一种编程语言。它是一种通过解释方式来执行的语言，语法规则和 C++ 类似。JAVA 有许多值得称道的优点，如简单、面向对象、分布式、解释性、可靠、安全、结构中立性、可移植性、高性能、多线程、动态性等。 JAVA 摈弃了 C++ 中各种弊大于利的功能和许多很少用到的功能。JAVA 可以运行于任何微处理器，用 JAVA 开发的程序可以在网络上传输，并运行于任何客户机上。[4]
Java具有简单易用、完全面向对象、具有平台无关性且安全可靠的特点，完全适合作为面向Internet的开发工具，因此本系统的开发在技术上具有可行性。
从目标系统使用难易程度上来看并不复杂，界面设计亲切，容易使用。系统管理员要有一定的数据库方面的知识，要掌握设置数据源连接数据库的方法并要对公司的运作有较为深入的了解。但只需专业人事做短期的培训就可以拥有熟练使用系统的能力。最后，就是需要操作员对本系统的各部分功能有全面的了解。因此，本系统在操作上是完全可行的。
网上办公系统是根据现在的企业公司的实际情况而开发的管理系统，是具有实际意义的，公司人员管理，公司公文管理，业务管理、信息发布等方面的网络通信系统，由于是毕业设计所以不同于以往的软件开发，因此不存在侵权问题，在法律上是可行的。
综上所述，本系统是完全可行的。在技术，操作，经济，法律发面都具有实际的可行性。因此，系统可以进行开发。
表示数据存储 表示输入/输出的信息
表示数据流向 表示处理
图2-2系统业务流图
Stream map of system’s operation
接口设计主要包括：
用户界面；
软件接口；
硬件接口；
1）用户界面
在用户界面部分，根据需求分析的结果，用户需要一个友善、简洁的界面使用Dreamweaver编程。
2）软件接口
使用SQLServer自己提供的连接池技术连接数据库。
3）硬件接口
在输入方面，用键盘，鼠标进行输入。
在输出方面，使用显示器。
在网络传输部分的网络硬件部分，为了实现高速传输，使用快速以太网。
内部接口方面，各模块之间采用函数调用、参数传递、返回值的方式进行信息传递。
通过对一些典型网上办公系统的考察、分析，并结合企业要求，本系统具有以下功能：
1．登录模块：它是由管理员登录模块与员工登录模块组成。管理员的用户名与密码被保存在属性文件中，所以在管理员登录中要对属性文件进行读取，而员工的用户名与密码被保存在数据库中，登录时从数据库中读取。员工登录与管理员登录都向Servlet提交数据，但有所不同的是二者提交的Servlet不同，处理的方法也不同。
2．部门，职位，员工状态管理模块：部门，职位及员工状态管理这三个模块非常相
似，但员工状态管理只有管理员权限的用户才可以操作，员工无权对其做任何操作。
3．公告管理模块：所有员工都有权发布、查看公告，管理员才有权删除及查看。
4．公文管理模块：公文发送包括公文的正文与附件两部分。当一方用户给另一方发
办公系统网页设计 第2篇
本次毕业设计历时近三个月，在此期间，张老师、同学和朋友给了我无私的支持和帮助，我的毕业设计能够顺利完成是与他们分不开的。在此，我要向他们表示衷心的感谢。
紧张而忙碌的毕业设计即将完成，我由衷地感到高兴，我想这将是我终生难忘的一段学习经历，因为在此期间我收获的不仅仅是知识。再次向帮助过我的老师、同学和朋友们致以最衷心的感谢！由于自身能力有限，本次设计中必然存在欠缺与疏漏之处，请各位老师批评指正。
[1] Michael V. Mannino 数据库设计、应用开发与管理[M].第2版 北京：电子工业出版社，2005
[2] 张海藩.软件工程导论[M].第３版.北京: 清华大学出版社，2003.
[3] 萨师煊，王珊. 数据库系统概论[M].第３版.北京: 高等教育出版社，2003.
[4] 孙卫琴.Tomcat与Java Web开发技术详解[M].第1版.北京：电子工业出版社，2004.
[5] 张孝祥.Java就业培训教程[M].第１版.北京：电子工业出版社，2002 .
[6]周绪 管丽娜 白海波 编著《SQL Server2000中文版入门与提高》，清华大学出版社，2004。
[7] 导向科技，夏帮贵，刘凡馨《中文版SQL Server数据库开发培训教程》.第一版.人民邮电出版社，2005年：P269~275
[8] Mike Gunderloy Joseph .《SQL Server 2000 从入门到精通》.第二版.电子工业版社，2001年：P274~294
[9] 孙印杰,薛书琴.Dreamweaver 8中文版应用教程[M].第二版.北京:电子工业出版社,2006.
[10] 敬铮等.SQL Server 高级开发与应用[M].第三版.北京：国防工业出版社，2005.
办公系统网页设计 第3篇
详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统，也就是说，经过这个阶段的设计工作，应该得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。
详细设计阶段的关键任务是确定怎么样具体的实现用户需要的软件系统，也就是要设计出程序的“蓝图”。除了应该保证软件的可靠性之外，使将来编写出的程序容易理解、容易测试、容易修改和维护，是详细设计阶段最重要的目标。结构程序设计技术是实现上述目标的基本保证，是进行详细设计的逻辑基础。
详细设计过程中的工具可以分为图形、表格和语言3类。例如：
程序流程图，又成为程序框图，它是历史最悠久、使用最广泛的表示过程设计的方法，然而它也是用得最混乱的一种方法。
盒图（N-S），处于要有一种不允许违背结构程序设计精神的图形工具的考虑，Nassi和Shneiderman提出了盒图，又称为N-S图。盒图没与箭头，因此不允许随意转移控制。坚持使用盒图作为详细设计的工具，可以使程序员逐步养成用结构化的方式思考问题和解决问题的习惯。
PAD图，是问题分析图（problem analysis diagram）的英文缩写，自1973年由日本日立公司发明以后，已得到一定程度的推广。它用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易[2]。
选择（分支） 开始或结束
处理 输入输出
1）功能：实现用户登陆；
2）程序流程图：
图5-1 系统登录程序流程图
System landing programme flow chart
图5-2 员工发布公告流程图
employee sending affice programme flow chart
图5-3 设定员工密码流程图
installing employees’code programme flow chart
办公系统网页设计 第4篇
1: Introduction
to Objects
The genesis of the computer revolution was in a machine. The genesis of our programming languages thus tends to look like that machine.
But computers are not so much machines as they are mind amplification tools (“bicycles for the mind,” as Steve Jobs is fond of saying) and a different kind of expressive medium. As a result, the tools are beginning to look less like machines and more like parts of our minds, and also like other forms of expression such as writing, painting, sculpture, animation, and filmmaking. Object-oriented programming (OOP) is part of this movement toward using the computer as an expressive medium.
This chapter will introduce you to the basic concepts of OOP, including an overview of development methods. This chapter, and this book, assume that you have had experience in a procedural programming language, although not necessarily C. If you think you need more preparation in programming and the syntax of C before tackling this book, you should work through the Thinking in C: Foundations for C++ and Java training CD ROM, bound in with this book and also available at .
This chapter is background and supplementary material. Many people do not feel comfortable wading into object-oriented programming without understanding the big picture first. Thus, there are many concepts that are introduced here to give you a solid overview of OOP. However, many other people don’t get the big picture concepts until they’ve seen some of the mechanics first; these people may become bogged down and lost without some code to get their hands on. If you’re part of this latter group and are eager to get to the specifics of the language, feel free to jump past this chapter—skipping it at this point will not prevent you from writing programs or learning the language. However, you will want to come back here eventually to fill in your knowledge so you can understand why objects are important and how to design with them.
All programming languages provide abstractions. It can be argued that the complexity of the problems you’re able to solve is directly related to the kind and quality of abstraction. By “kind” I mean, “What is it that you are abstracting?” Assembly language is a small abstraction of the underlying machine. Many so-called “imperative” languages that followed (such as Fortran, BASIC, and C) were abstractions of assembly language. These languages are big improvements over assembly language, but their primary abstraction still requires you to think in terms of the structure of the computer rather than the structure of the problem you are trying to solve. The programmer must establish the association between the machine model (in the “solution space,” which is the place where you’re modeling that problem, such as a computer) and the model of the problem that is actually being solved (in the “problem space,” which is the place where the problem exists). The effort required to perform this mapping, and the fact that it is extrinsic to the programming language, produces programs that are difficult to write and expensive to maintain, and as a side effect created the entire “programming methods” industry.
The alternative to modeling the machine is to model the problem you’re trying to solve. Early languages such as LISP and APL chose particular views of the world (“All problems are ultimately lists” or “All problems are algorithmic,” respectively). PROLOG casts all problems into chains of decisions. Languages have been created for constraint-based programming and for programming exclusively by manipulating graphical symbols. (The latter proved to be too restrictive.) Each of these approaches is a good solution to the particular class of problem they’re designed to solve, but when you step outside of that domain they become awkward.
The object-oriented approach goes a step further by providing tools for the programmer to represent elements in the problem space. This representation is general enough that the programmer is not constrained to any particular type of problem. We refer to the elements in the problem space and their representations in the solution space as “objects.” (Of course, you will also need other objects that don’t have problem-space analogs.) The idea is that the program is allowed to adapt itself to the lingo of the problem by adding new types of objects, so when you read the code describing the solution, you’re reading words that also express the problem. This is a more flexible and powerful language abstraction than what we’ve had before. Thus, OOP allows you to describe the problem in terms of the problem, rather than in terms of the computer where the solution will run. There’s still a connection back to the computer, though. Each object looks quite a bit like a little computer; it has a state, and it has operations that you can ask it to perform. However, this doesn’t seem like such a bad analogy to objects in the real world—they all have characteristics and behaviors.
Some language designers have decided that object-oriented programming by itself is not adequate to easily solve all programming problems, and advocate the combination of various approaches into multiparadigm programming languages.
Alan Kay summarized five basic characteristics of Smalltalk, the first successful object-oriented language and one of the languages upon which Java is based. These characteristics represent a pure approach to object-oriented programming:
Aristotle was probably the first to begin a careful study of the concept of type; he spoke of “the class of fishes and the class of birds.” The idea that all objects, while being unique, are also part of a class of objects that have characteristics and behaviors in common was used directly in the first object-oriented language, Simula-67, with its fundamental keyword class that introduces a new type into a program.
Simula, as its name implies, was created for developing simulations such as the classic “bank teller problem.” In this, you have a bunch of tellers, customers, accounts, transactions, and units of money—a lot of “objects.” Objects that are identical except for their state during a program’s execution are grouped together into “classes of objects” and that’s where the keyword class came from. Creating abstract data types (classes) is a fundamental concept in object-oriented programming. Abstract data types work almost exactly like built-in types: You can create variables of a type (called objects or instances in object-oriented parlance) and manipulate those variables (called sending messages or requests; you send a message and the object figures out what to do with it). The members (elements) of each class share some commonality: every account has a balance, every teller can accept a deposit, etc. At the same time, each member has its own state, each account has a different balance, each teller has a name. Thus, the tellers, customers, accounts, transactions, etc., can each be represented with a unique entity in the computer program. This entity is the object, and each object belongs to a particular class that defines its characteristics and behaviors.
So, although what we really do in object-oriented programming is create new data types, virtually all object-oriented programming languages use the “class” keyword. When you see the word “type” think “class” and vice versa.
Since a class describes a set of objects that have identical characteristics (data elements) and behaviors (functionality), a class is really a data type because a floating point number, for example, also has a set of characteristics and behaviors. The difference is that a programmer defines a class to fit a problem rather than being forced to use an existing data type that was designed to represent a unit of storage in a machine. You extend the programming language by adding new data types specific to your needs. The programming system welcomes the new classes and gives them all the care and type-checking that it gives to built-in types.
The object-oriented approach is not limited to building simulations. Whether or not you agree that any program is a simulation of the system you’re designing, the use of OOP techniques can easily reduce a large set of problems to a simple solution.
Once a class is established, you can make as many objects of that class as you like, and then manipulate those objects as if they are the elements that exist in the problem you are trying to solve. Indeed, one of the challenges of object-oriented programming is to create a one-to-one mapping between the elements in the problem space and objects in the solution space.
But how do you get an object to do useful work for you? There must be a way to make a request of the object so that it will do something, such as complete a transaction, draw something on the screen, or turn on a switch. And each object can satisfy only certain requests. The requests you can make of an object are defined by its interface, and the type is what determines the interface. A simple example might be a representation of a light bulb:
Light lt = new Light();
();
The interface establishes what requests you can make for a particular object. However, there must be code somewhere to satisfy that request. This, along with the hidden data, comprises the implementation. From a procedural programming standpoint, it’s not that complicated. A type has a function associated with each possible request, and when you make a particular request to an object, that function is called. This process is usually summarized by saying that you “send a message” (make a request) to an object, and the object figures out what to do with that message (it executes code).
Here, the name of the type/class is Light, the name of this particular Light object is lt,and the requests that you can make of a Light object are to turn it on, turn it off, make it brighter, or make it dimmer. You create a Light object by defining a “reference” (lt) for that object and calling new to request a new object of that type. To send a message to the object, you state the name of the object and connect it to the message request with a period (dot). From the standpoint of the user of a predefined class, that’s pretty much all there is to programming with objects.
The diagram shown above follows the format of the Unified Modeling Language (UML). Each class is represented by a box, with the type name in the top portion of the box, any data members that you care to describe in the middle portion of the box, and the member functions (the functions that belong to this object, which receive any messages you send to that object) in the bottom portion of the box. Often, only the name of the class and the public member functions are shown in UML design diagrams, and so the middle portion is not shown. If you’re interested only in the class name, then the bottom portion doesn’t need to be shown, either.
It is helpful to break up the playing field into class creators (those who create new data types) and client programmers(the class consumers who use the data types in their applications). The goal of the client programmer is to collect a toolbox full of classes to use for rapid application development. The goal of the class creator is to build a class that exposes only what’s necessary to the client programmer and keeps everything else hidden. Why? Because if it’s hidden, the client programmer can’t use it, which means that the class creator can change the hidden portion at will without worrying about the impact to anyone else. The hidden portion usually represents the tender insides of an object that could easily be corrupted by a careless or uninformed client programmer, so hiding the implementation reduces program bugs. The concept of implementation hiding cannot be overemphasized.
In any relationship it’s important to have boundaries that are respected by all parties involved. When you create a library, you establish a relationship with the clientprogrammer, who is also a programmer, but one who is putting together an application by using your library, possibly to build a bigger library.
If all the members of a class are available to everyone, then the client programmer can do anything with that class and there’s no way to enforce rules. Even though you might really prefer that the client programmer not directly manipulate some of the members of your class, without access control there’s no way to prevent it. Everything’s naked to the world.
So the first reason for access control is to keep client programmers’ hands off portions they shouldn’t touch—parts that are necessary for the internal machinations of the data type but not part of the interface that users need in order to solve their particular problems. This is actually a service to users because they can easily see what’s important to them and what they can ignore.
The second reason for access control is to allow the library designer to change the internal workings of the class without worrying about how it will affect the client programmer. For example, you might implement a particular class in a simple fashion to ease development, and then later discover that you need to rewrite it in order to make it run faster. If the interface and implementation are clearly separated and protected, you can accomplish this easily.
Java uses three explicit keywords to set the boundaries in a class: public, private, and protected. Their use and meaning are quite straightforward. These access specifiers determine who can use the definitions that follow. public means the following definitions are available to everyone. The private keyword, on the other hand, means that no one can access those definitions except you, the creator of the type, inside member functions of that type. private is a brick wall between you and the client programmer. If someone tries to access a private member, they’ll get a compile-time error. protected acts like private, with the exception that an inheriting class has access to protected members, but not private members. Inheritance will be introduced shortly.
Java also has a “default” access, which comes into play if you don’t use one of the aforementioned specifiers. This is sometimes called “friendly” access because classes can access the friendly members of other classes in the same package, but outside of the package those same friendly members appear to be private.
Once a class has been created and tested, it should (ideally) represent a useful unit of code. It turns out that this reusability is not nearly so easy to achieve as many would hope; it takes experience and insight to produce a good design. But once you have such a design, it begs to be reused. Code reuse is one of the greatest advantages that object-oriented programming languages provide.
The simplest way to reuse a class is to just use an object of that class directly, but you can also place an object of that class inside a new class. We call this “creating a member object.” Your new class can be made up of any number and type of other objects, in any combination that you need to achieve the functionality desired in your new class. Because you are composing a new class from existing classes, this concept is called composition (or more generally, aggregation). Composition is often referred to as a “has-a” relationship, as in “a car has an engine.”
(The above UML diagram indicates composition with the filled diamond, which states there is one car. I will typically use a simpler form: just a line, without the diamond, to indicate an association.)
Composition comes with a great deal of flexibility. The member objects of your new class are usually private, making them inaccessible to the client programmers who are using the class. This allows you to change those members without disturbing existing client code. You can also change the member objects at run-time, to dynamically change the behavior of your program. Inheritance, which is described next, does not have this flexibility since the compiler must place compile-time restrictions on classes created with inheritance.
Because inheritance is so important in object-oriented programming it is often highly emphasized, and the new programmer can get the idea that inheritance should be used everywhere. This can result in awkward and overly complicated designs. Instead, you should first look to composition when creating new classes, since it is simpler and more flexible. If you take this approach, your designs will be cleaner. Once you’ve had some experience, it will be reasonably obvious when you need inheritance.
员工登录模块
员工登录处理模块
查看公告模块
<%@ page contentType=_text/html; charset=gb2312_ language=_java_ errorPage=__ %>
<%@ include file=_../hear/_%>
<%
Collection coll=(Collection)(_msg_);
if(coll==null){
%>
<%
}else{
Iterator it=();//用Collection对象的iterator()方法获得
while(()){
Affice dep=(Affice)();
%>
<%
(_msg_);//移除request对象中所带的属性
%>
发送公文处理模块
<%@ page contentType=_text/html; charset=gb2312_ language=_java_ errorPage=__ %>
<%@ include file=_../hear/_%>
<%
Collection coll=(Collection)(_msg_);
if(coll==null){
(_您的网页已过期请重新登录_);
}else{
Iterator it=();
if(()){
Bumf bumf=(Bumf)();
%>
<%
String ok=(String)(_ok_);
if(ok!=null){
(ok);
(_ok_);
%>
_ size=_15_/>
<%
(_msg_);
%>
办公系统网页设计 第5篇
网上办公系统
当今社会是一个信息飞速发展的社会，因此，针对各行业来说，为了达到求质量、求速度，尽可能的脱离手工操作的目标，现在都开始应用计算机来管理公司的日常事务。
在现代社会中，任何一个行业，任何一个企业，高效准确的办公都是至关重要的。快捷的信息交流，畅通的公文传递，迅速的资料查询，自动的工作流转等等都能提高一个企业的办公效率，进而提高其市场竞争力。
传统的办公模式主要以纸介质为主，在计算机飞速发展的今天，显然已经远远不能满足高效率、快节奏的现代工作和生活的需要。网络技术的迅猛发展，为信息的交流和共享，团队的协同运作提供了技术的保证，同时也预示着网络化办公时代的来临。
据了解现在企业日常管理中，企业员工管理、文件流转等功能都是核心功能。通过基于网络的办公自动化系统，就可以实现企业对员工信息方便的进行管理，也可以大大的提高文件的传输速度，从而提高了企业的工作效率。
本系统是根据企业日常办公的需求进行开发设计的，主要实现如下目标：
通过本系统实现企业办公自动化管理。利用计算机高效率的特点实行快速的信息查询、员工信息管理、查看职位信息和部门信息、短信息的发送与接收管理、在线信息的查看、员工账号管理，完全替代落后的人工管理，为企业节省人力物力资源。