利用网络通讯基础及先进的网络应用平台，建设一个安全、可靠、开放、高效的信息网络和办公自动化、信息管理电子化系统，为管理部门提供现代化的日常办公条件及丰富的综合信息服务，实现档案管理自动化和办公事务处理自动化，以提高办公效率和管理水平，实现企业各部门日常业务工作的规范化、电子化、标准化，增强档案部门文书档案、人事档案、科技档案、 财务档案等档案的可管理性，实现信息的在线查询、借阅，最终实现“无纸”办公。
1需求分析
1.1功能需求
本系统是为某校办公自动化的需要而开发的，该学校需要解决如下问题：创造一个集成化的办公环境;支持信息传递;提供具有工作流性质的处理过程和监督功能;提供集成处理与发布信息的工作平台;实现文档管理的自动化;提供与其它管理信息系统( MIS )的信息交流。
1.2功能介绍
办公自动化系统功能介绍
1.3 流程图
公文流转系统分为三个功能模块。
(1)发文管理模块：发文管理即各个部门提交报文，文件不指定路线，由发文的个人制定流程，报文以附件方式传送，每个用户只需要选择“转呈”下拉菜单中的下一转呈人，该公文就会自动流转到下一个处理人手中，由每个客户端成员查看文件，履行相应动作，并继续流转。管理员进行最后的处理。
(2)收文管理模块：收文管理模块显示了所有需要签收的公文记录，处理人只要点击查看，并进行相应的动作，公文就会按照流转路线向下一个处理人传递。
(3)公文跟踪模块：公文跟踪管理功能提供对单位内部所有在流转公文状态的跟踪、查询，根据工作的实际需要可以对这些功能进行催办、删除和改变流程负责人等功能。
2办公自动化系统设计
2.1系统设计目标
系统的总体设计目标是：基于计算机网络，提供一个安全可靠的、方便实用的办公平台，在这个平台上，该学校用户可以高效地处理各种公文。根据前文的用户需求和总体设计目标，我们将某校的办公自动化系统的具体目标归纳为：(1) 切实可行的公文处理能力;(2) 稳定性、健壮性和安全性;(3) 可定制的流程控制;(4) 可监控的办文痕迹;(5)良好的集成功能;(6) 快速的开发过程。
2.2系统框架及功能划分
2.2.1系统框架
初步决定将系统划分为五个部分：
(1)公文处理，包括发言、行文、通告、会议纪要;
(2)个人工作台，包括个人邮箱、日程安排、修改密码;
(3)公文监控，包括来文监控、查阅监控、公文痕迹;
(4)系统管理，包括编号管理、流程安排、权限管理;
(5)系统集成，包括与Word和Excel在集成。
2.2.2系统功能划分
(1)公文处理模块。公文处理模块负责处理各类公文的办理，各类公文从起草、审核到发布等这些过程都是在这个模块完成的，在这个模块里要为各种公文设置不同的外观，每种公文的界面里有调用WORD和导出WORD的功能。
(2)个人工作台。个人工作台用于对本人各项工作进行统一管理。个人邮箱存放着属于自己的各类公文，别的用户无法进入，邮箱有提示功能，突出显示未办或未阅公文，邮箱里的草稿公文是由于是自己创建的，可以删除，已经阅读过的成文公文也可以删除，待办公文不能删除;日程安排用来安排本人的日程和活动，起到提醒的作用;修改密码用来更改用户个人的密码;公文查询用来搜索查看自己有权限的公文。
(3)公文监控。公文监控提供公文从草稿到成文的办文痕迹，记录什么人什么时间对该公文做了什么事情。
(4)系统管理。系统管理员负责办公自动化系统的公文字号管理，用户权限管理和流程走向管理。
(5)信息集成。信息集成模块负责向该学校门户网站发送通知公告类的公文。在学校的网络中已经实现了与门口网站的连接。
2.3系统详细设计
2.3.1 公共模板的设计
柔性工作流着重强调系统的可重构性、可重用性和可扩展性，系统框架图里公文处理模块里面包括了多种公文处理子模块，但这些公文处理子模块其实有很多过程是相似的，如果我们把这些功能相似的部分做成可重用的模块，即可以达到快速开发的目的又能使系统增加一定的柔性，再者，如果要修改各公文处理子模块代码时，只需更改模板的代码，而由模板生成的`其他子模块则能够自动更新。在本文中，我们把这个模块称为“公共模板”。
2.3.2 流程部分设计
在设计流转机制时，本系统在处理时将所有待处理的公文进行分类，然后针对每一类公文和处理该公文的对象来确定相应的流转规则，并在系统建模阶段将该规则写入数据库中。
假设现有部门A、部门B和部门C，同时有公文a、公文b和公文c。针对这三个部门和三类公文，我们可以设计一个简单的流转规则。对于公文a，只能由部门C起草，部门 B和部门C可以接收、发送，而部门A只能回复;对于公文b ，部门B和部门C都能起草，但只有部门C能接收和发送，其它部门只能回复;对于公文c，所有部门都能起草、发送和接收。该规则可以用相应的状态
2.3.3 权限管理的设计
一个OA系统中有很多参与者，而且一般也有多种公文;每一类公文针对不同的参与者又有不同的权限。为了解决这个问题，可以引入RBAC(Role-Based Access Control)技术，先将用户按部门和职责分组，再根据需要定义一些角色(比如起草、审核、回复、签发、发布等) ，然后将相应的组分配相应的角色。实现时要将角色设置游离出业务逻辑，设计可配置的单独模块，独立于业务逻辑;而业务逻辑里判断的只是角色，不涉及到具体用户。这样设计后，人员变动、权限更改就不会影响整个系统的应用逻辑。 3办公自动化系统实现
3.1公共模板实现
(1)所有文档：显示所有文档;
(2)草稿文档：显示起草后未提交审核但保存了的文档;
(3)删除的草稿文档：从草稿文档视图内删除了的文档;
(4)已发布公文：已经成文并经过校办公室发布成功的文档;
(5)已回收公文：由于起草错误或发送错误而传递到用户邮件数据库里的已成为公文可以被回收，所有回收的公文被放入该视图;
(6)预归档文档：在前文已经介绍，归档部分要与该学校的另一个系统衔接，所以本系统里的归档只是预归档，仅仅将公文的状态设置为归档;
(7)在审核文档：所有起草完毕并已提交审核但未成文文档。
3.2表单
我们采用了三种表单：草稿表单、审核表单和成文表单。
(1)输入文本：公文草稿，当用户起草时，使用该表单，它有“本部门审核”、 “校办公室审核”、“校对”等操作，
(2)处理文本：审核公文表单，整个审核期间的文档都用此表单，它有“获取编号”、“提交部门领导审核”、“提交校领导审核”、“保存”、“回复”操作等。
(3)成文表单，当公文完成上述流程后，公文接收者看见的文档就是以Doc表单打开的，它含有“关闭”和“打印”操作，除了这两个操作外，还为秘书设计了错发而设计的“收回”操作和因为漏发而设计的“补发”操作以及公文归档设计的。
3.3邮件模板的实现
3.3.1 代理
为了自动或后台运行一些任务，我们为邮件数据库定义了一些代理，其中有个使用最频繁的代理mailprocess，此代理的触发条件设置为“邮件到达之前”，主要的功能是将收到的文档按状态分类，供不同的视图使用。
3.3.2 应用与邮件的集成
在工作流的应用开发中，邮件和应用程序将集成在一起。当需要时，可以通过开发的应用程序向上级部门发送一个邮件，在邮件中将申请以及连接文档以邮件的形式发送给相关领导。
3.4数据库实现
本系统采用用户-角色-模块的三层安全模式，第一层为用户，第二层为角色，第三层为系统模块。用户和角色之间建立关系，角色和模块权限之间建立关系，而用户和模块权限之间没有直接的关系。此模型将系统的模块权限和用户分开，使用角色作为一个中间层。用户访问模块时，通过其所在的角色对模块的访问权限来获得访问该模块的权限，通过这种分层的管理模式可以实现有效的权限管理。
3.5权限管理实现
Domino在实现时可以用ACL来完成，Domino是带有RBAC技术的群件开发工具，它的Domino Admin可以进行用户设置和群组划分，它的Domino Designer除了可以进行正常的程序开发之外，还可以针对某个数据库文件定义角色，并可以通过该数据库文件的ACL将角色分配给相应的用户组和用户。具体实现时可以在某类公文数据库的ACL里定义一些角色。
3.6监控数据库的实现
监控数据库在实现时主要是创建了三张表单和若干个视图和一个代理。三张表单，每张表单对应一类监控信息。在表单的上半部显示公文的基本信息，下半部显示公文痕迹信息，在下半部的这个带附签的表格里，第一项标签有“收文单位”、所有应接收人员、补发收文情况、流转序列四项;代理用来将办公痕迹写到文档里。
1.
2.
3.
4.
5.
6.
7.
8.