工作日志管理系统开发与设计

工作日志管理系统开发与设计内容摘要：

节 硬件环境： 一、计算机 本系统面向中小型软件企业 ..对硬件的要求相对较低 ..选择计算机主要是本着经济 ..运行稳定的原则 ..目前主流的 PC 机就可以满足本系统的配置要求。 二、网络 由于 B/S 架构是基于 WEB 的 ..因此网络选择的好坏将直接影响系统的性能。 选择网络主要是考虑其传输速度以及稳定性两个方面 ..目前的主流网络产品：快速以太网、 ATM、 FDDI 等。 此系统主要使用快速以太网。 因 此快速以太网即能处理多个 LAN 用户的同时请求 ..以可以应付高性能 PC 及其复杂应用程序带来的迅速高峰：从网络负载能力角度来讲 ..快速以太网为服务器和客户机带来了真正的好处：由于标准的迅速普及和产品来源的多样化 ..快速以太网的性价比 领先于其他高速网络技术。 在网络协议方面 ..基于完全可靠性传输的考虑 ..使用了 TCP/IP协议 [12]。 第二节 软件环境 ： 一、操作系统 当前流行的网络操作系统主要有： NetWare、 UNIX、 OS/ Windows 系列操作系统等。 基于系统服务面向的用户及安全性考虑 ..服务器 使用 Windows2020. Windows操作系统以其友好的图形界面 ..以及简单的操作要求 ..深受用户青睐 ..另外由于它对使用者要求相对其他操作系统简单 ..所有一般普通用户都能直接上手 ..基于以上考虑 ..选择了 Win XP 作为开发及运行环境。 二、开发语言 开发基于 B/S 的系统 ..目前比较流行的是 和 JSP..二者各有优势 ..就像筷子和勺子一样 ..筷子用来吃菜无疑是最好的选择 ..但是喝汤呢。 最好的选择当然是勺子。 2 将 C作为一种面向对象语言 ..在很多方面来看 ..C将 成为微软的与 Java 相似的语言。 C另一个有趣的地方是所有对象都自动变成 COM 对象。 如果 C能取得很大的市场份额 ..那么它将给 带来类似于 Java 的功能 ..并且具备更快的性能 ..因为它可以和 Windows 环境紧密集成 [13]。 C是 开发中一个最重要的功能 ..微软会将 C发展成为 Java 的强劲对手。 这也是他们 .Net 框架的一个重要组成部分。 C是微软在编程市场上几百对手的主要工具。 微软能在这个产品后面倾注全力 ..C便可以成为许多程序员的又一种选择。 C产生的结果是将进一步加固 微软和 Sun 产哦的战线。 这对用户是有利的 ..他们可以选择两者之一来开发新的应用。 ASP 另一亮点是它使用 ADO 对象 ..ODBC..OLEDB 和事务处理管理器。 因此ASP Web 数据库应用开发特别简单。 发展了更多的功能 ..因为有了 ADO+。 ADO+带来了更强大更快速的功能。 JSP 和 JDBC 目前在易用性和性能上同 ASP/ADO相比已有些落后 ..当新版本 +出现后这样的差别会更明显 [14]。 将对大型站点（ web farms）有更好的支持。 事实上 ..微软在 这方面付出了巨大的努力。 可以让你考虑到多服务器（ multiple servers）的场合 ..当你需要更强大的功能时 ..仅仅只需要增加一台服务器。 整个 .NET 框架已经充分地提供了这个方法。 提供了外部会话状态（ external session state）来提供内置式 web farm 的支持。 另外 ..由于请求的各组件互相间经过了充分的优化 ..所以速度很快。 于是 还有以下一些显而易见的优点： 对版本的更新提供内在的支持降低了开发成本 (一 ) 增强的性能。 是在服务器 上运行的编译好的公告语言运行库码。 可利用早期绑定、实时编译、本机优化和盒外缓存服务。 这相当于在编写代码行之前便显著提高了性能。 (二 ) 世界级的工具支持。 框架补充了 Visual Studio 集成开发环境中的大量工具箱和设计器。 WYSIWYG 编辑、拖放服务器控件和自动部署只是这个强大的工具所提供功能的少数几种。 (三 ) 威力和灵活性。 由于 基于公共语言运行库 ..因此 Web 应用程序开发人员可以利用整个平台的威力和灵活性。 .NET 框架类库、消息处理和数据访问解决方案都可从 Web 无缝访问。 也与语言无关 ..所以可以选择最适合应用程序的语言 ..或跨多种语言分割应用程序。 另外 ..公共语言运行库的交互性保证在迁移到 时保留基于 COM 的开发中的现有投资。 (四 ) 简易性。 使执行常见任务变得容易 ..从简单的窗体提交和客户端身份 验证到部署和站点配置。 例如 .. 页框架使您可以生成将 3 应用程序逻辑与表示代码清楚分开的用户界面 ..和在类似 Visual Basic 的简单窗体处理模型中处理事件。 另外 ..公共语言运行库利用托管代码服务（如自动引用计数和垃圾回收）简化 了开发 [15]。 (五 ) 可管理性。 采用基于文本的分层配置系统 ..简化了将设置应用于服务器环境和 Web 应用程序。 由于配置信息是以纯文本形式存储的 ..因此可以在没有本地管理工具帮助的情况下应用新设置。 此 零本地管理哲学也扩展到了 框架应用程序的部署。 只需将必要的文件复制到服务器 ..即可将 框架应用程序部署到服务器。 不需要重新启动服务器 ..即使是在部署或替换运行的编译代码时。 (六 ) 可缩放性和可用性。 在设计时考虑了可缩放性 ..增加了专门用于在聚集环 境和多处理器环境中提高性能的功能。 另外 ..进程受到 运行库的密切监视和管理 ..以便当进程行为不正常（泄漏、死锁）时 ..可就地创建新进程 ..以帮助保持应用程序始终可用于处理请求。 (七 ) 自定义性和扩展性。 随附了一个设计周到的结构 ..它使开发人员可以在适当的级别 插入 代码。 实际上 ..可以用自己编写的自定义组件扩展或替换 运行库的任何子组件。 实现自定义身份验证或状态服务一直没有变得更容易。 (八 ) 安全性。 借助内置的 Windows 身份验证和基于每个应用程序的配置 ..可 以保证应用程序是安全的。 鉴于以上原因 ..我们采用了 C + 来开发此系统。 第三节 数据库平台 当前流行的数据库平台主要有： Oracle、 SyBase、 InformixOnline、 MS SQL Server、 IBM DB Foxpro 等。 考虑到本系统是针对于中小型软件企业开发的 ,所以选择了简单 ,功能比较完善且适合于中小型系统使用的 MS SQL Server 数据库 [16]。 本系统共有注册 /审核模块、日志 /总结模块、任务模块、通知模块、消息模块、职员管理模块、权限模块、自 定义设置模块、评论模块和附加模块。 如图： 4 工 作 日 志 管 理 系 统日志/总结模块通知模块任务模块消息模块自定义设置模块评论模块职员管理模块附加模块 图 模块划分 (一 )日志 /总结模块 该模块是职员写、查看、删除日志和总结的模块。 日志 /总结提交后就不能修改。 每个职员也可以查看自己的日志和总结。 如果后台开启了公开日志功能 ..职员之间就可以互相查看日志。 否则只有拥有查看职员日志 /总结的权限才能进入查看别人的日志 /总结。 (二 )通知模块 发布通知。 可以群发 ..也可以单独发送给某个人。 每个注册用户可以查看和删除自己发送的通知。 (三 )任务模块 这是分 配任务给职员的模块。 任务分配方式有两种：分配给单个用户和分配给多个用户。 职员查看自己的任务但不可以删除。 任务的删除是由分配者来结束的 ..并且任务是可以被跟踪的 ..也就是可以查看任务的完成进度。 (四 )消息模块 每个用户都可以向其他用户发送消息。 当有新消息时 ..会在用户登陆的主界面后有声音和弹出一个对话框提示。 用户可以删除自己收到的消息。 (五 )职员管理模块 是对职员的人事信息进行管理 ..包括查看职员信息 ..修改职员相关信息 ..删除职员（删除职员并不删除其相关的资料：日志和总结）。 (六 )自定义设置模块 此模 块是设置系统的相关配置以及对系统的一些内容上的自定义设定：系统名 ..底部版权信息、 LOGO 和 BANNER、管理部门（增加、删除、修改）、管理职位（增加、删除、修改）、管理职称（增加、删除、修改） ..备份数据库和还原数据库。 (七 )评论模块 查看职员的日志和总结之后 ..可以对其评价。 如果在系统设置里面没有开放 5 评价则会隐藏评价的相关页面。 用户可以看到自己的日志 /总结的评价 ..如果在后台设置了公开评论 ..则也可以查看别人的日志 /总结的评论。 (八 )附加模块 附加模块是一些实用的小工具：提醒和发邮件。 提醒：用 户在设置了提醒的时间和内容之后 ..到了设置的时间。 只要登陆此系统 ..就会有声音和提示框提示。 发邮件：系统只是利用其他邮箱的 POP3 接口来发送邮件。 四、系统框架搭建 经过需求分析以及模块划分 ..再结合本系统实际做了详细的分析考虑之后 ..本系统采用目前流行的 MVC 模式来设计。 系统组织总体框架图如图 ： 图 系统组织总体框架 MVC 英文即 ModelViewController..即把一个应用的输入、处理、输出流程按照 Model、 View、 Controller 的方式进行分离 ..这样一个应用被分成三个层 —— 模型层、视图层、控制层。 大性和灵活性。 视图 (View)代表用户交互界面 ..对于 Web 应用来说 ..可以概括为 HTML 界面 ..但有可能为 XHTML、 XML 和 Applet。 MVC 设计模式对于视图的处理仅限于视图上数据的采集和处理 ..以及用户的请求 ..而不包括在视图上的业务流程的处理。 业务流程的处理交予模型 (Model)处理。 在本系统中 ..视图也就是 WEB层 ..它负责把后台取得的相关数据 ..包括日志、通知、任务以及职员详细信息等显示在页面 ..也负责把用户的操作状态 显示出来 ..让用户清楚的知道自己所做操作的结果 [17]。 模型 (Model)：就是业务流程 /状态的处理以及业务规则的制定。 业务流程的处理过程对其它层来说是黑箱操作 ..模型接受视图请求的数据 ..并返回最终的处理结果。 业务模型的设计可以说是 MVC 最主要的核心。 业务模型还有一个很重要的模型那就是数据模型。 数据模型主要指实体对象的数据 保存（持续化）。 在此层 ..主要是处理一些业务逻辑 ..比如查找用户、查找日志、查找总结等。 它接受视图层的数据 ..并进行业务处理。 控制 (Controller)可以理解为从用户接收 请求 , 将模型与视图匹配在一起 ..共同完成用户的请求。 划分控制层的作用也很明显 ..它清楚地告诉你 ..它就 6 是一个分发器 ..选择什么样的模型 ..选择什么样的视图 ..可以完成什么样的用户请求。 控制层并不做任何的数据处理。 在此系统中 ..控制层和视图层并无明显的分层 ..也就相当于结合在一起了。 模型、视图与控制器的分离 ..使得一个模型可以具有多个显示视图。 如果用户通过某个视图的控制器改变了模型的数据 ..所有其它依赖于这些数据的视图都应反映到这些变化。 因此 ..无论何时发生了何种数据变化 ..控制器都会将变化通知所有的视 图 ..导致显示的更新。 这实际上是一种模型的变化 传播机制。 模型、视图、控制器三者之间的关系和各自的主要功能 [18]..如图 所示： 图 MVC 组件类型关系和功能 而且在系统中使用了 MVC 模型后 ..其优点有： 首先 ..最重要的是应该有多个视图对应一个模型的能力。 在目前用户需求的快速变化下 ..可能有多种方式访问应用的要求。 例如 ..订单模型可能有本系统的订单 ..也有网上订单 ..或者其他系统的订单 ..但对于订单的处理都是一样 ..也就是说订单的处理是一致的。 按 MVC 设计模式 ..一个订单 模型以及多个视图即可解决问题。 这样减少了代码的复制 ..即减少了代码的维护量 ..一旦模型发生改变 ..也易于维护。 其次 ..由于模型返回的数据不带任何显示格式 ..因而这些模型也可直接应用于接口的使用。 再次 .. 由于一个应用被分离为三层 .. 因此有时改变其中的一层就能满足应用的改变。 一个应用的业务流程或者业务规则的改变只需改动 MVC 的模型层。 控制层的概念也很有效 ..由于它把不同的模型和不同的视图组合在一起完成不同的请求 ..因此 ..控制层可以说是包含了用户请求权限的概念。 最后 ..它还有利于软件工程化管 理。 由于不同的层各司其职 ..每一层不同的应用具有某些相同的特征 ..有利于通过工程化、工具化产生管理程序代码。 7 所以 ..整个项目按照 MVC 模式的详细组织框架图如图 ： 图 系统的详细组织框架 五、权限分配策略 本系统的权限采用了按角色和自定义权限相结合的方式来分配 ..这是借鉴了目前论坛权限分配的广泛做法 ..这样不仅提高了权限管理的灵活性 ..也提高了安全性。 权限分配是除基本权限 [注 1]之外的其他权。