关于办公自动化系统的设计与实现.docx

《关于办公自动化系统的设计与实现.docx》由会员分享，可在线阅读，更多相关《关于办公自动化系统的设计与实现.docx（7页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、 关于办公自动化系统的设计与实现 1.1功能需求 本系统是为某校办公自动化的需要而开发的，该学校需要解决如下问题：制造一个集成化的办公环境;支持信息传递;供应具有工作流性质的处理过程和监视功能;供应集成处理与公布信息的工作平台;实现文档治理的自动化;供应与其它治理信息系统( MIS )的信息沟通。 1.2功能介绍 办公自动化系统功能介绍 1.3 流程图 公文流转系统分为三个功能模块。 (1)发文治理模块：发文治理即各个部门提交报文，文件不指定路线，由发文的个人制定流程，报文以附件方式传送，每个用户只需要选择“转呈”下拉菜单中的下一转呈人，该公文就会自动流转到下一个处理人手中，由每个客户端成员查

2、看文件，履行相应动作，并连续流转。治理员进展最终的处理。 (2)收文治理模块：收文治理模块显示了全部需要签收的公文记录，处理人只要点击查看，并进展相应的动作，公文就会根据流转路线向下一个处理人传递。 (3)公文跟踪模块：公文跟踪治理功能供应对单位内部全部在流转公文状态的跟踪、查询，依据工作的实际需要可以对这些功能进展催办、删除和转变流程负责人等功能。 2办公自动化系统设计 2.1系统设计目标 系统的总体设计目标是：基于计算机网络，供应一个安全牢靠的、便利有用的办公正台，在这个平台上，该学校用户可以高效地处理各种公文。依据前文的用户需求和总体设计目标，我们将某校的办公自动化系统的详细目标归纳为：

3、(1) 切实可行的公文处理力量;(2) 稳定性、强健性和安全性;(3) 可定制的流程掌握;(4) 可监控的办文痕迹;(5)良好的集胜利能;(6) 快速的开发过程。 2.2系统框架及功能划分 2.2.1系统框架 初步打算将系统划分为五个局部： (1)公文处理，包括发言、行文、通告、会议纪要; (2)个人工作台，包括个人邮箱、日程安排、修改密码; (3)公文监控，包括来文监控、查阅监控、公文痕迹; (4)系统治理，包括编号治理、流程安排、权限治理; (5)系统集成，包括与Word和Excel在集成。 2.2.2系统功能划分 (1)公文处理模块。公文处理模块负责处理各类公文的办理，各类公文从起草、审

4、核到公布等这些过程都是在这个模块完成的，在这个模块里要为各种公文设置不同的外观，每种公文的界面里有调用WORD和导出WORD的功能。 (2)个人工作台。个人工作台用于对本人各项工作进展统一治理。个人邮箱存放着属于自己的各类公文，别的用户无法进入，邮箱有提示功能，突出显示未办或未阅公文，邮箱里的草稿公文是由于是自己创立的，可以删除，已经阅读过的成文公文也可以删除，待办公文不能删除;日程安排用来安排本人的日程和活动，起到提示的作用;修改密码用来更改用户个人的密码;公文查询用来搜寻查看自己有权限的公文。 (3)公文监控。公文监控供应公文从草稿到成文的办文痕迹，记录什么人什么时间对该公文做了什么事情。

5、 (4)系统治理。系统治理员负责办公自动化系统的公文字号治理，用户权限治理和流程走向治理。 (5)信息集成。信息集成模块负责向该学校门户网站发送通知公告类的公文。在学校的网络中已经实现了与门口网站的连接。 2.3系统具体设计 2.3.1 公共模板的设计 柔性工作流着重强调系统的可重构性、可重用性和可扩展性，系统框架图里公文处理模块里面包括了多种公文处理子模块，但这些公文处理子模块其实有许多过程是相像的，假如我们把这些功能相像的局部做成可重用的模块，即可以到达快速开发的目的又能使系统增加肯定的柔性，再者，假如要修改各公文处理子模块代码时，只需更改模板的代码，而由模板生成的其他子模块则能够自动更新

6、。在本文中，我们把这个模块称为“公共模板”。 2.3.2 流程局部设计 在设计流转机制时，本系统在处理时将全部待处理的公文进展分类，然后针对每一类公文和处理该公文的对象来确定相应的流转规章，并在系统建模阶段将该规章写入数据库中。 假设现有部门A、部门B和部门C，同时有公文a、公文b和公文c。针对这三个部门和三类公文，我们可以设计一个简洁的流转规章。对于公文a，只能由部门C起草，部门 B和部门C可以接收、发送，而部门A只能回复;对于公文b ，部门B和部门C都能起草，但只有部门C能接收和发送，其它部门只能回复;对于公文c，全部部门都能起草、发送和接收。该规章可以用相应的状态 2.3.3 权限治理的

7、设计 一个OA系统中有许多参加者，而且一般也有多种公文;每一类公文针对不同的参加者又有不同的权限。为了解决这个问题，可以引入RBAC(Role-Based Access Control)技术，先将用户按部门和职责分组，再依据需要定义一些角色(比方起草、审核、回复、签发、公布等) ，然后将相应的组安排相应的角色。实现时要将角色设置游离出业务规律，设计可配置的单独模块，独立于业务规律;而业务规律里推断的只是角色，不涉及到详细用户。这样设计后，人员变动、权限更改就不会影响整个系统的应用规律。 3办公自动化系统实现 3.1公共模板实现 (1)全部文档：显示全部文档; (2)草稿文档：显示起草后未提交审

8、核但保存了的文档; (3)删除的草稿文档：从草稿文档视图内删除了的文档; (4)已公布公文：已经成文并经过校办公室公布胜利的文档; (5)已回收公文：由于起草错误或发送错误而传递到用户邮件数据库里的已成为公文可以被回收，全部回收的公文被放入该视图; (6)预归档文档：在前文已经介绍，归档局部要与该学校的另一个系统连接，所以本系统里的归档只是预归档，仅仅将公文的状态设置为归档; (7)在审核文档：全部起草完毕并已提交审核但未成文文档。 3.2表单 我们采纳了三种表单：草稿表单、审核表单和成文表单。 (1)输入文本：公文草稿，当用户起草时，使用该表单，它有“本部门审核”、 “校办公室审核”、“校对

9、”等操作， (2)处理文本：审核公文表单，整个审核期间的文档都用此表单，它有“猎取编号”、“提交部门领导审核”、“提交校领导审核”、“保存”、“回复”操作等。 (3)成文表单，当公文完成上述流程后，公文接收者观察的文档就是以Doc表单翻开的，它含有“关闭”和“打印”操作，除了这两个操作外，还为秘书设计了错发而设计的“收回”操作和由于漏发而设计的“补发”操作以及公文归档设计的。 3.3邮件模板的实现 3.3.1 代理 为了自动或后台运行一些任务，我们为邮件数据库定义了一些代理，其中有个使用最频繁的代理mailprocess，此代理的触发条件设置为“邮件到达之前”，主要的功能是将收到的文档按状态分

10、类，供不同的视图使用。 3.3.2 应用与邮件的集成 在工作流的应用开发中，邮件和应用程序将集成在一起。当需要时，可以通过开发的应用程序向上级部门发送一个邮件，在邮件中将申请以及连接文档以邮件的形式发送给相关领导。 3.4数据库实现 本系统采纳用户-角色-模块的三层安全模式，第一层为用户，其次层为角色，第三层为系统模块。用户和角色之间建立关系，角色和模块权限之间建立关系，而用户和模块权限之间没有直接的关系。此模型将系统的模块权限和用户分开，使用角色作为一个中间层。用户访问模块时，通过其所在的角色对模块的访问权限来获得访问该模块的权限，通过这种分层的治理模式可以实现有效的权限治理。 3.5权限治

11、理实现 Domino在实现时可以用ACL来完成，Domino是带有RBAC技术的群件开发工具，它的Domino Admin可以进展用户设置和群组划分，它的Domino Designer除了可以进展正常的程序开发之外，还可以针对某个数据库文件定义角色，并可以通过该数据库文件的ACL将角色安排给相应的用户组和用户。详细实现时可以在某类公文数据库的ACL里定义一些角色。 3.6监控数据库的实现 监控数据库在实现时主要是创立了三张表单和若干个视图和一个代理。三张表单，每张表单对应一类监控信息。在表单的上半部显示公文的根本信息，下半部显示公文痕迹信息，在下半部的这个带附签的表格里，第一项标签有“收文单位”、全部应接收人员、补发收文状况、流转序列四项;代理用来将办公痕迹写到文档里。