考勤综合管理平台项目说明书.doc

考勤综合管理平台

项目说明书
（.NET项目研发组）
文件编号：
TD07003

文档编号
TD07003
版本号
QMS20一三
分册名称

第1册/共1册
总页数

正文

附录

编制

审批

生效日期

武汉厚溥教育科技有限公司

目 录
第1章 项目介绍 3
1.1文档编制目的 3
1.2项目开发背景 3
1.3项目特点 3
1.4项目开发环境配置 4
第2章 项目总体结构 5
2.1源码目录介绍 5
2.2数据库目录结构 7
2.3系统模块介绍 7
2.4模块大体功能简介 8
2.5系统代码格式要求 9
【个人心得】 10
第3章 项目展示 11
3.1系统角色分工 11
3.2项目主体内容展示 12
【个人心得】 23
第4章 模块需求介绍 24
4.1公共功能 24
4.1.1登录 24
4.1.2系统主页 25
4.2管理员功能 27
4.2.1用户管理 27
4.2.2部门管理 32
4.2.3考勤设置 36
4.3主管功能 37
4.3.1考勤管理 37
4.3.2请假审批 41
4.4员工功能 43
4.4.1我的考勤 43
4.4.2请假申请 46
【个人心得】 51
第5章 项目总体评价 52
5.1用户界面评价 52
5.1.1用户界面设计的基本原则 52
5.1.2用户界面设计规范 53
5.2功能性评价 55
5.3代码设计分析 55
【个人心得】 59
第6章 项目进度监控评表 60
【个人心得】 62

第1章 项目介绍
当今社会正处于信息时代，信息技术已渗透到社会生活的各个领域，特别是各行业的管理领域，智能化信息处理已是提高效率、规范管理、客观审查的最有效途径。考勤作为一个公司的基层管理，是公司对员工工作管理的基本依据。
1.1文档编制目的
编写此文档的主要目的是明确所要开发的软件所应具有的功能，使系统分析人员和软件设计人员能清楚地了解用户的需求，并在此基础上进一步提出概要设计和完成后续设计与开发工作，为软件开发范围、业务处理规范提供依据，也是应用软件进行最终验收的依据。
系统对企业员工的资料和考勤情况进行管理，通过每日的打卡把出勤信息输入到系统中，保存员工每日的出勤情况，以便于统计出勤情况。同时方便管理员查阅，即节省了人力，又省去了中间的很多容易出错的步骤。让企业的考勤管理更具有透明性，且方便管理。此外系统还涉及用户管理的问题、部门管理等问题，因此还要求系统具有系统管理的处理功能。
1.2项目开发背景
考勤是一个比较烦琐的工作，公司每天都要对员工的出勤状况（包括迟到、早退、请假、旷工等情况）进行记录。而随着企业规模的扩大和市场竞争的更加激烈，企业的人事管理日趋复杂，规范的考勤管理是现代企业提高管理效益的重要保证，而传统的人工管理存在着效率低、不易统计、成本高和易出错等弊端，已经无法适应现代企业的需求。各类企业都越发认识到人力资源管理的重要性及提升企业自身人力资源管理水平的迫切性。而人力资源管理水平的提升不仅需要高素质的管理人员而且也需要信息化工具进行辅助。因而将传统的人工考勤管理计算机化，建立一个高效的、无差错的、规范的考勤管理系统，能够大大的提高企业的管理效率，有效的帮助企业实现“公正考勤，高效薪资”，使企业的管理水平登上一个新的平台。
1.3项目特点
此系统具有如下5个特点：
Ø 灵活性：本系统可以根据不同的登录用户，自动识出用户的身份，并引导和呈现出该用户可以进行的操作。
Ø 简单便捷的用户操作：功能模块的操作采用简单易行的使用原则，用户可以很容易理解某个操作的含义并很容易上手。
Ø 友好的用户界面：系统的操作界面简单、美观、大方，能够给用户一种简洁舒适的感觉。
Ø 跨浏览器兼容性：系统支持多种主流浏览器，用户可以根据自己的喜好选择喜欢的浏览器来访问本系统。
Ø 多用户同时在线：本系统以B/S结构构建，支持多人同时在线，多个不同的用户可以同时在系统中进行操作。
1.4项目开发环境配置
l 设备配置
u 服务器端最低配置
n 硬件平台：英特尔T4300处理器，2G内存，80G硬盘空间。
n 软件平台：Windows Server 2003，数据库 SQL Server 2005
u 客户端配置
n 软件平台：Windows XP 或更高版本，浏览器IE 8+，Chrome 12+，FireFox 6+
l 服务器端必要的软件
操作系统 Windows Server 2003或更高版本，数据库 SQL Server 2005 或更高版本，.net framework 3.5或更高版本
l 开发工具及语言
u VS 2010，SQL Server 2005
u C#
第2章 项目总体结构
一个设计良好的项目结构必备的条件是：易维护性、可扩展性、当遇到需求变更或功能变更时能够以最低的代码成本响应变更。这就要求整个软件在设计上做好周密、全方位的设计。
此软件总体设计如下。
2.1源码目录介绍
我们现从整个项目的源码结构上做如下分析,以下是对项目源码部分进行分开介绍，如下：

图(38)
各项目层次说明如下：
项目
说明
WebSite
界面表示层，引用BLL、Model、SVSE.Framework
BLL
业务逻辑层，引用DAL、Model、SVSE.Framework
DAL
数据访问层，引用SVSE.Framework、Model
Model
实体层，引用SVSE.Framework
SVSE.Framework
基础框架层

各层源码展开如下图所示：

2.2数据库目录结构

2.3系统模块介绍

2.4模块大体功能简介

2.5系统代码格式要求
为保证项目开发代码的规范性、可读性，特制定该代码规范：
1、 命名规范：C#语言规范规定了C#所采用的命名规则为Pascal命名法。其中，命名空间、类型（类、结构、枚举、委托、接口）首字母大写；方法、属性、事件、公共字段、常量首字母大写；私有字段、局部变量、方法参数首字母小写。命名时，名称应具备一定的意义，而非随意命名。
2、 在三层框架中，实体层应命名为Model或以Model结尾；业务逻辑层应命名为BLL或以BLL结尾，与该层相关的所有业务逻辑类及类文件（cs文件）应以BLL结尾；数据访问层应命名为DAL或以DAL结尾，与该层相关的所有数据访问类及类文件应以DAL结尾。
3、 方法的逻辑应做到职责明确、功能单一。即每个方法只负责完成明确的一个功能，多个功能应采用多个方法。每个方法的代码应尽量做到简短精炼，避免一个方法的代码过长，如果一个方法代码过长可将其拆分成多个小的方法。
4、 方法的参数不宜过多，过多的参数容易导致维护的困难。如果方法的参数超过了6个，则应考虑将方法的参数包装成特定的类型。
5、 如果多个类都使用同一段代码或同一个类似的方法，则应考虑将该段代码、该方法的公共相同部分提取出来，封装成一个通用的方法，使用到的类应该是调用公共的方法而不是将相同的代码复制粘贴。
6、 业务逻辑的代码应写在BLL层，DAL层应只负责执行SQL语句，不做任何逻辑上的分支判断等操作。
7、 确保数据库连接每次使用之后都会关闭。可以将关闭数据库连接的方法的代码放在finally块中以确保执行。
8、 绝对不要将数据库连接对象SqlConnection设置为静态的。应该在每次使用数据库连接时创建一个新的SqlConnection对象，并在使用完之后关闭它。
9、 不要相信用户的输入永远是正确的。应该总是对用户的输入进行验证，确保用户的非法输入不会产生程序的异常。
10、 不要使用try…catch…来做输入数据的有效性验证。应使用验证方法（如判断、正则表达式等）对数据进行有效性验证。
11、 如果定义的字符串很长（比如用字符串定义了一条很长的复杂Sql查询语句），则应考虑将字符串分行显示以增加可读性。可以采用两种方法：使用“+”号将每个字符串常量分行连接起来；或者使用原义字符串“ x”abcdedfg……” ”。
12、 如果要验证字符串是否为空（null）或空字符串（””），建议使用string.IsNullOrEmpty方法。
13、 不要对string类型的变量、属性等再次调用ToString()方法，产生string.ToString()这类毫无意义的代码。
14、 在拼接Sql语句时，如果参数超过2个，应使用string.Format方法来代替直接使用+号的字符串连接。建议总是使用string.Format方法代替+号以提高阅读性。例如，将”select * from table where Name=’”+ name + “’ and Pwd=’”+ pwd +”’”改写为string.Format(”select * from table where Name=’{0}’ and Pwd=’{1}’”,name,pwd)。
15、 如果要进行大量的字符串拼接，请使用StringBuilder类，而不要直接使用+号连接。
16、 在涉及身份验证（如登录验证）、数据安全等影响系统安全的关键段，执行的SQL语句应使用参数化查询，不应该使用拼接的SQL语句。
17、 尽量使用强类型数据、强类型集合（如List<T>、Dictionary<TKey,TValue>）以获得更好的编程支持及数据安全。
18、 不要把大量的数据存储在全局对象中（如Session、ViewState、Application等），全局对象应只保存关键的、较少量的数据及信息。
19、 在定义Javascript函数（方法）时，绝对要注意函数的命名不能与window对象的属性或者方法名称产生冲突。
20、 Javascript命名规范：函数的首字母小写，从第二个单词起，每个单词首字母大写；对象的首字母大写。
以上规范最终解释权归武汉厚溥教育科技有限技术公司所有 特此声明！
【个人心得】

个人心得与总结日志

我的体会
1、
2、
3、
我打算做

第3章 项目展示
一个好的应用界面的必备的条件是：内容清楚、指示明白、屏幕美观和有亲切感。界面通常包含图形和文字。应用界面的设计是对控件进行适当的取舍及功能的选择和处理过程。在程序设计中需要对设计的方法反复推敲才能使其达到完美的境界。
3.1系统角色分工
本系统主要分为三种角色：系统管理员、主管、员工。各角色进入系统后，根据权限可以操作的模块如下：

系统管理员：主要完成系统各模块基本数据的初始化工作，包括定义部门、录入员工、设置年月份的特殊上班/休假日期。

主管：主要完成对所管辖的部门的员工的请假审批工作，以及考勤信息的导入、查看部门员工的考勤状态。

员工：主要完成请假的申请，以及个人年月份的考勤状态数据的查询。
3.2项目主体内容展示
用户登录页面：

注：（系统管理员：admin）登录成功后，根据用户的不同角色，到达不同的功能页面。系统管理员登录成功后到达考勤设置页面：

用户管理页面：

点击“添加”，打开新增用户界面：

点击“编辑”，打开编辑用户信息界面：

删除用户：

部门管理页面：

点击“添加”，打开新建部门界面：

点击“编辑”，打开修改部门信息界面：

修改个人信息页面：

主管登录成功后到达考勤管理页面：

点击“导入考勤数据”，打开考勤导入界面：

点击表格中的“查看”，打开员工考勤查看界面：

请假审批页面：

点击“查看”，打开请假单审批界面：

当请假单处于“归档”状态时，则打开查看请假单信息界面：

员工登录成功后到达我的考勤页面：

我的考勤状态数据也可以以日历的形式展示：

请假申请页面：

点击“请假”，打开发起请假申请界面：

点击“编辑”，可以打开请假申请信息编辑界面：

【个人心得】

个人心得与总结日志

我的体会
1、
2、
3、
我打算做

第4章 模块需求介绍
本系统按照角色身份功能可以分为公共功能、管理员功能、主管功能、员工功能四大类。
4.1公共功能
公共功能为使用本系统的所有用户都具有的功能。其中包括登录和个人信息。
4.1.1登录
4.1.1.1用户登录
Ø 信息来源：所有用户
Ø 信息要求：用户登录系统及其身份验证
Ø 事件信息系统处理：点击登录按钮后，验证用户名和密码是否允许登录。对于用户名或密码无效的用户，弹出提示“用户名或密码错误！”，并不允许登录；对于通过验证的用户，允许用户登录，并根据用户的不同身份跳转到相应的默认页面。
Ø 信息处理结果：对于系统管理员，默认跳转到“考勤设置”；对于主管，默认跳转到“考勤管理”；对于员工，默认跳转到“我的考勤”。

4.1.2系统主页
4.1.2.1个人信息
Ø 信息来源：所有用户
Ø 信息要求：当前登录的用户可以修改登录密码以及手机号码
Ø 事件信息系统处理：点击保存按钮，保存用户修改的手机号码信息。如果“新密码”和“确认密码”都为空，则可以提交保存，且保存时不用修改登录密码；如果只填写了其中一项，则需给出提示——另一项也必须填写，此时不能提交保存；如果这两项都填写了，则还需要验证两次输入的密码是否一致，如果不一致，给出提示，且不能提交保存；只有两次输入密码相同时，才允许提交保存，此时将修改当前用户的登录密码为本次新设置的密码。
Ø 信息处理结果：将用户修改的手机、登录密码信息更新到数据库。

4.1.2.2退出
Ø 信息来源：所有用户
Ø 信息要求：退出系统
Ø 事件信息系统处理：点击退出按钮，注销当前用户的登录，并跳转到登录页面。
Ø 信息处理结果：注销当前登录用户信息，跳转到登录页面。

4.2管理员功能
系统管理员的主要功能是对系统的的基础数据进行维护，保证系统的正常运行。其功能包括用户管理、部门管理、考勤设置。
4.2.1用户管理
4.2.1.1查询用户
Ø 信息来源：系统管理员
Ø 信息要求：以表格形式显示分页的用户的数据
Ø 事件信息系统处理：点击查询按钮时，根据所输入的查询条件对用户数据进行联合查询，并将查询结果数据以分页的形式显示在表格中。列表中列头标题为超链接，点击可以实现按照对应的字段对数据进行升序/降序排列切换显示。
Ø 信息处理结果：查询出所有符合条件的非管理员用户（即所有员工、主管），并以表格形式分页显示。

4.2.1.2添加用户
Ø 信息来源：系统管理员
Ø 信息要求：实现用户的添加功能
Ø 事件信息系统处理：1.用户类型的选项为“员工”、“主管”。2.点击保存按钮时，对用户信息中的必填项进行验证，如果没有填写，则进行相应的提示，并不允许提交保存。如果必填项都已填写，则可以提交保存。提交保存时，需要首先对该用户ID进行验证是否已经存在，如果已经存在则提示“该用户ID已经存在！”，并不允许保存；如果该用户ID不存在，则保存用户信息，并根据保存结果给出相应的提示。
Ø 信息处理结果：将填写的用户信息保存到数据库，完成用户的添加。

4.2.1.3修改用户
Ø 信息来源：系统管理员
Ø 信息要求：对系统中现有用户的信息进行修改
Ø 事件信息系统处理：1.页面打开时，自动加载出该用户的信息，其中用户ID为只读不能修改。2.点击保存按钮时，对用户信息中的必填项进行验证，如果没有填写，则进行相应的提示，并不允许提交保存。如果必填项都已填写，则可以提交保存，并根据保存结果给出相应的提示。
Ø 信息处理结果：将填写的用户信息更新到数据库，完成用户信息的修改。

4.2.1.4删除用户
Ø 信息来源：系统管理员
Ø 信息要求：将所选择的用户从系统中删除
Ø 事件信息系统处理：点击删除按钮时，对用户的删除操作弹出确认提示“确定要删除选择的用户吗？”如果选择“否”，则不做任何操作；如果选择“是”，则删除所选择的所有用户数据，并根据删除结果给出相应的提示。
Ø 信息处理结果：将用户信息从数据库中删除。

4.2.2部门管理
4.2.2.1查询部门
Ø 信息来源：系统管理员
Ø 信息要求：以表格形式显示分页的部门的数据
Ø 事件信息系统处理：1.加载部门列表时，如果该部门下不存在任何用户，则最后一列操作列中显示删除按钮；如果该部门下存在用户，则不显示删除按钮。2.点击查询按钮时，根据所输入的查询条件对部门数据进行联合查询，并将查询结果数据以分页的形式显示在表格中。
Ø 信息处理结果：查询出所有符合条件的部门数据，并以表格形式分页显示。

4.2.2.2添加部门
Ø 信息来源：系统管理员
Ø 信息要求：实现部门的添加功能
Ø 事件信息系统处理：点击保存按钮时，对部门信息中的必填项进行验证，如果没有填写，则进行相应的提示，并不允许提交保存。如果必填项都已填写，则可以提交保存。提交保存时，需要首先对该部门名称进行验证是否已经存在，如果已经存在则提示“部门名称已经存在！”，并不允许保存；如果该部门名称不存在，则保存部门信息，并根据保存结果给出相应的提示。
Ø 信息处理结果：将填写的部门信息保存到数据库，完成部门的添加。

4.2.2.3修改部门
Ø 信息来源：系统管理员
Ø 信息要求：对部门信息进行修改
Ø 事件信息系统处理：1.页面打开时，自动加载出部门信息。2.点击保存按钮时，对部门信息中的必填项进行验证，如果没有填写，则进行相应的提示，并不允许提交保存。3.提交保存时，如果修改了部门名称，则需要对新的部门名称进行验证是否已经存在，如果存在则提示“部门名称已经存在！”，并不允许保存。保存之后，根据保存结果给出相应的提示。
Ø 信息处理结果：将填写的部门信息更新到数据库，完成部门信息的修改。

4.2.2.4删除部门
Ø 信息来源：系统管理员
Ø 信息要求：将所选部门从数据库中删除
Ø 事件信息系统处理：点击删除按钮时，对用户的删除操作弹出确认提示“确定要删除该部门吗？”如果选择“否”，则不做任何操作；如果选择“是”，则删除所选择的部门数据，并根据删除结果给出相应的提示。
Ø 信息处理结果：将该部门从数据库中删除。

4.2.3考勤设置
4.2.3.1显示设置信息
Ø 信息来源：系统管理员
Ø 信息要求：以列表的形式显示所选月份的考勤设置信息
Ø 事件信息系统处理：1.点击显示按钮，将所选年月份的整月的考勤设置信息以列表形式展示出来，并显示“保存”按钮。2.列表中的“状态”一列显示为下拉列表，下拉列表的选项为“默认”“上班”“休假”，默认选项为“默认”。
Ø 信息处理结果：显示出所选月份的每一天的状态数据。

4.2.3.2保存设置信息
Ø 信息来源：系统管理员
Ø 信息要求：将列表中该月份的每一天所选择的下拉列表的状态保存到数据库
Ø 事件信息系统处理：点击保存按钮，将整个列表中该月份的每一天所选择的下拉列表的状态保存到数据库中，并根据保存结果给出相应的提示。
Ø 信息处理结果：将所选月份的每一天的状态数据保存到数据库中。

4.3主管功能
4.3.1考勤管理
4.3.1.1查看考勤
Ø 信息来源：主管
Ø 信息要求：以列表形式展示部门员工在所选年月的考勤状态
Ø 事件信息系统处理：1.页面加载后，以分页的形式显示当前主管所管理的部门下所有员工的基本信息，列表中列头标题为超链接，点击可以实现按照对应的字段对数据进行升序/降序排列切换显示。2.点击“查看”打开考勤查看界面，可以选择年月并查询该员工在所选年月的考勤状态信息。3.考勤状态信息以列表形式展示，详情见“员工功能——我的考勤——查看考勤信息（列表）”。
Ø 信息处理结果：显示该员工在所选年月的考勤信息状态数据。

4.3.1.2导入考勤
Ø 信息来源：主管
Ø 信息要求：将Excel形式的考勤打卡记录导入到系统中
Ø 事件信息系统处理：点击导入考勤数据按钮，打开考勤导入界面。浏览要导入的考勤记录Excel文件，并点击导入按钮完成打卡记录的导入。如果没有选择文件，则提示“请选择要导入的Excel文件”。所选的文件必须是Excel工作表形式的考勤打卡记录信息，如果所选文件格式不正确，则给出相应的提示“Excel文件格式不正确”。若Excel文件格式无误（即为打卡记录Excel表），则将Excel中所有的打卡记录全部导入到数据库，并根据导入结果给出相应的提示。
Ø 信息处理结果：将所选的考勤Excel文件中的打卡记录保存到数据库，完成打卡记录的导入。

4.3.2请假审批
4.3.2.1查询请假单
Ø 信息来源：主管
Ø 信息要求：以表格形式显示当前主管所管理的部门的所有员工的请假申请
Ø 事件信息系统处理：页面加载后，以分页的形式显示当前主管所管理的部门下所有员工的请假申请记录，默认查询出“待审批”的请假数据；列表中列头标题为超链接，点击可以实现按照对应的字段对数据进行升序/降序排列切换显示；点击查询按钮时，根据所输入的查询条件对请假单数据进行联合查询，并将查询结果数据以分页的形式显示在表格中。
Ø 信息处理结果：查询出所有符合条件的请假申请数据，并以表格形式分页显示。

4.3.2.2审批请假单
Ø 信息来源：主管
Ø 信息要求：对部门员工的请假申请进行审批
Ø 事件信息系统处理：点击列表上的查看超链接，打开请假审批界面。页面打开时，加载出请假申请的信息，并且为只读不能修改；并根据当前请假单的状态，显示出不同的审批信息：如果当前请假单为“待审批”，则审批信息为空，需要主管对该请假单进行审批。其中，“审批结果”包括“同意”、“不同意”，且为必填项。点击确定按钮时，需要对必填项进行验证。保存时，将审批结果信息保存到数据库，并且更新请假单的状态为“归档”；如果当前请假单为“归档”，则查看请假单的审批信息，为只读。
Ø 信息处理结果：将部门员工的请假单审批结果保存到数据库。

4.4员工功能
4.4.1我的考勤
4.4.1.1查看考勤信息（列表）
Ø 信息来源：员工
Ø 信息要求：以列表形式展示所选年月的考勤状态。
Ø 事件信息系统处理：点击查看按钮，查询出当前登录的员工在所选年月的考勤状态结果信息，并以列表的形式显示出来。其中：1.将所选月份的所有日期（从当月的第一天到当月的最后一天，如所选日期为4月，则显示4月1日~4月30日）的每一天的考勤状态数据都显示出来；2.显示的信息包括：日期、星期、首次打卡时间、最后打卡时间、考勤状态。其中：
日期：当天的日期
星期：当天是星期几
首次打卡时间：当天第一次打卡的时间
最后打卡时间：当天最后一次打卡的时间
考勤状态：见下3“考勤状态”
3.考勤状态：根据当天的打卡情况、是否请假、是否需要上班、是否为默认休假日、是否为指定休假日等综合信息，系统自动推断出当天的考勤结果状态。考勤状态共有8种：
² 正常：当天正常按时打卡
² 未打卡：当天只有一次打卡记录
² 请假：当天包含于审批同意的请假申请时间范围内
² 休假：当天为默认休假日（周末）或指定休假日（见考勤设置）
² 缺勤：当天没有打卡记录
² 迟到：第一次打卡时间晚于上班时间，且当天打卡两次
² 早退：最后一次打卡时间早于下班时间，且当天打卡两次
² 迟到且早退：当天打卡两次，且第一次打卡时间晚于上班时间，最后一次打卡时间早于下班时间
4.考勤的状态以半天为计算单位。如果当天全天的考勤状态具有一致性，则只显示全天的考勤状态的综合结果（即当天只有一种状态）；如果当天全天的考勤状态不具有一致性，则需要分别显示上午的考勤状态和下午的考勤状态（即当天有两种状态）。
具有一致性的考勤状态：当天中的半天（上午或下午）不是请假状态，即全天上班或全天不上班
不具有一致性的考勤状态：当天中的半天（上午或下午）处于请假状态，另外半天处于上班状态
Ø 信息处理结果：显示所选年月的考勤信息状态数据。

4.4.1.2查看考勤信息（日历）
Ø 信息来源：员工
Ø 信息要求：以日历形式展示所选年月的考勤状态。
Ø 事件信息系统处理：以日历形式显示当前登录的员工在所选年月的考勤状态信息。当鼠标停留在日历中的某一天的单元格时，可以以气泡的形式显示出当天的首次打卡时间和最后打卡时间。考勤状态见“查看考勤信息（列表）”。
Ø 信息处理结果：显示所选年月的考勤信息状态数据。

4.4.2请假申请
4.4.2.1查询申请
Ø 信息来源：员工
Ø 信息要求：以表格形式显示当前用户发起的所有请假申请
Ø 事件信息系统处理：页面加载后，以分页的形式显示当前用户发起的所有请假申请记录；列表中列头标题为超链接，点击可以实现按照对应的字段对数据进行升序/降序排列切换显示；点击查询按钮时，根据所输入的查询条件对请假单数据进行联合查询，并将查询结果数据以分页的形式显示在表格中；最后一列中，如果该请假单的状态为“待审批”，则显示为编辑和删除按钮，允许对请假单进行编辑和删除。如果请假单状态为“归档”，则显示为查看超链接，只允许查看请假单的信息。
Ø 信息处理结果：查询出所有符合条件的请假申请数据，并以表格形式分页显示。

4.4.2.2新增申请
Ø 信息来源：员工
Ø 信息要求：发起请假申请单
Ø 事件信息系统处理：点击确定按钮时，对请假单中的必填项进行验证，如果没有填写，则进行相应的提示，并不允许提交保存。如果必填项都已填写，则可以提交保存。提交保存时，需要首先验证当前填写的请假时间段内是否已经请过了假，以及是否与其他请假单中的请假时间产生冲突（也就是与其他请假单的请假时间存在交集）。如果存在冲突则提示在该时间段内已经存在请假记录，并不允许保存；如果不存在冲突，则保存请假单信息，且将该请假单的状态设置为“待审批”，并根据保存结果给出相应的提示。
Ø 信息处理结果：将发起提交审批的请假单信息保存到数据库。

4.4.2.3修改申请
Ø 信息来源：员工
Ø 信息要求：修改已经发起的请假单的信息
Ø 事件信息系统处理：点击确定按钮时，需要对请假单中的必填项进行验证。提交保存时，如果修改了请假时间，则需要对新填写的请假时间进行验证，是否与其他请假单中的请假时间产生冲突。如果存在冲突则提示在该时间段内已经存在请假记录，并不允许修改。保存修改后的请假单信息，并根据保存结果给出相应的提示。
Ø 信息处理结果：将修改后的请假单信息更新到数据库，完成请假单的修改。

4.4.2.4删除申请
Ø 信息来源：员工
Ø 信息要求：删除还未审批的请假单
Ø 事件信息系统处理：点击删除按钮时，对用户的删除操作弹出确认提示“确定要删除该请假申请吗？”如果选择“否”，则不做任何操作；如果选择“是”，则删除所选择的请假申请，并根据删除结果给出相应的提示。
Ø 信息处理结果：将还未审批的请假单从数据库中删除。

【个人心得】

个人心得与总结日志

我的体会
1、
2、
3、
我打算做

第5章 项目总体评价
5.1用户界面评价
5.1.1用户界面设计的基本原则
5.1.1.1用户界面设计原则
基于平台开发的应用软件应坚持图形用户界面（GUI）设计原则：
（1）界面直观、对用户透明：用户接触软件后对界面上对应的功能一目了然、不需要太多培训就可以方便使用本应用系统。
（2）始终强调软件用户是所有处理的核心：用户界面应当由用户来控制应用如何工作、如何响应，而不是由开发者按自己的意愿把操作流程强加给用户。
5.1.1.2一般交互原则
企业级系统的应用软件的一般交互遵循以下原则：
（1）一致性：菜单选择、数据显示以及其它功能都应使用一致的格式。
（2）提供有意义的反馈。
（3）执行有较大破坏性的动作前要求确认。
（4）在数据录入上允许取消大多数操作。
（5）减少在动作间必须记忆的信息数量。
（6）允许用户非恶意错误，系统应保护自己不受致命操作的破坏。
（7）按功能对动作分类，并按此排列屏幕布局，设计者应提高命令和动作组织的内聚性。
（8）提供语境相关的帮助机制。
5.1.1.3信息显示原则
企业级系统的应用软件信息显示遵循以下原则：
（1）只显示与当前用户语境有关的信息。
（2）不要用数据将用户包围，使用便于用户迅速吸取信息的方式表现信息。
（3）使用一致的标记、标准缩写和可预测的颜色，显示信息的含义应该非常明确，用户不必再参考其它信息源。
（4）产生有意义的出错信息。
（5）使用缩进和文本来辅助理解。
（6）使用窗口分隔/控件分隔不同类型的信息。
（7）高效地使用显示器的显示空间。
5.1.1.4数据输入原则
企业级系统的应用软件数据输入遵循以下原则：
（1）尽量减少用户输入动作的数量。
（2）维护信息显示和数据输入的一致性。
（3）交互应该是灵活的，对键盘和鼠标输入的灵活性提供支持。
（4）在当前动作的语境中使用不合适的命令不起作用。
（5）让用户控制交互流，用户可以跳过不必要的动作、改变所需动作的顺序（如果允许的话）以及在不退出系统的情况下从错误状态中恢复。
（6）为所有输入的动作提供帮助。
（7）消除冗余输入。可能的话提供缺省值、绝不要让用户提供程序中可以自动获取或计算出来的信息。
5.1.2用户界面设计规范
5.1.2.1界面规范的总体规定
本应用系统显示界面总体上分为三帧：菜单工具栏区域、状态栏区域、应用软件工作区，如下图：

（1）顶层为菜单工具栏区域，高度为89px。
（2）中间为应用软件工作区。
（3）底部为状态栏区域，固定在当前窗口（浏览器）的底部，高度为26px。
5.1.2.2界面一致性规范
本系统各软件界面在设计中应该保持界面的一致性。
一致性既包括：使用标准的控件；使用相同的信息表现方法，如：在字体、标签风格、颜色、术语、显示错误信息等方面保持一致。
5.1.2.3显示信息一致性规范
（1）字体：系统缺省字体采用如下设置：font-size：12px。
（2）日期：采用长格式，以yyyy-MM-dd的形式格式化。使用缺省字体。
（3）对齐：系统整体以居中对齐方式显示；表格内容居中对齐显示。
（4）颜色：系统采用统一的蓝色风格界面。
（5）提示信息：系统所有的前台提示信息均采用浮动的红底白字横幅形式，具有清晰醒目的特点。
（6）弹窗：系统所有弹出窗口页面均采用流行的弹出层的形式，附加伸展打开的动画效果。
5.2功能性评价
（1）易用性：系统的操作简单，按钮的功能明确，系统界面简洁，具有良好的可操作性，用户可以很快上手使用本系统，不需要专业的培训。
（2）可扩展性：系统采用三层架构模式，各层之间职责明确：表示层负责用户页面的展示；业务逻辑层负责处理整个系统中的业务逻辑规则；数据访问层负责操作数据库；实体层负责将数据封装为对象，作为各层之间数据传递的载体；基础框架层为系统的运行提供了基础的功能服务。三层架构模式+基础框架，使得本系统具有较强的可扩展性：可以通过扩展基础框架来增加系统运行时底层的基本功能；可以添加实体类，以扩展数据库表结构等数据库对象；可以添加新的业务逻辑类，来处理新的业务逻辑等。
（3）安全性：系统采用了多种方式来保证用户在使用系统的过程中，不会产生安全隐患：
² 身份验证：通过ASP.NET框架提供的安全可靠的Forms身份验证，使得非法用户不能够登录和使用本系统。
² 参数化查询：使用基于参数化的SQL语句，防止了SQL注入的产生，从而避免了恶意用户对系统的攻击。
² 数据的有效性验证：对用户输入的数据始终做有效性验证，使得无效数据、错误数据、危险数据不能够被录入到系统中，从而减少了系统在运行过程中产生异常的可能，提高了系统的稳定性和安全性。
（4）可维护性：基于三层架构模式+基础框架的代码设计，各层之间相互分离的职责，使得系统的可维护性大大增强：当需要修改获取数据的源头时，只需要修改数据访问层的代码；当需要改变界面呈现的元素样式时，只需要改变表示层的代码；当需要改变整个系统运行的的行为，或者给整个系统添加功能插件、模块时，只需要更改基础框架层的代码等。
（5）智能性、健壮性：系统中对于可能出现的人为性错误均进行了自动化的验证处理，比如部门名称不应该重复，用户ID不应该重复等，提高了用户在使用系统时的工作效率，减少了人工对数据进行验证的繁琐步骤，降低了出错的可能性，使得系统更加智能和健壮。
5.3代码设计分析
（1）实体类分析

所有的实体类都继承了实体类基类Entity，使得所有的实体类都具有统一的行为特征——都是Entity，这就方便了实体类功能特性的扩展：只要基类改变了某一个行为或特征，则其会影响到所有的实体类，比如需要给实体类添加一个ToJson方法，则只需要在基类中添加该方法，然后所有的子类就都可以继承该方法，不用重复在每一个子类中添加；同时，也把本身相互之间没有联系的每一个实体类相互联系了起来，通过Entity基类，便可以对所有实体类进行统一的操作，使得后续的插件化、切面化的功能模块扩展可以很容易实现。
（2）数据访问层分析

数据访问层采用当前主流的实体数据模型——ORM框架的模式，具有以下显著的优点：
Ø 使用实体类作为数据传递的载体，避免了大量使用DataTable、DataSet等弱类型数据集，使得代码具有强类型的编程优点：智能感知、自动类型推断、编译时的类型成员检查。由于可以智能感知，这使得开发人员在编写代码时的开发效率大大提升；通过自动类型推断和编译时类型成员检查，使得在开发过程中出现低级错误（如字段名拼写错误等）的几率几乎为零，并且可以获得编译器的检查支持。
Ø 使用主流的ORM框架模式进行数据访问，使得开发人员可以更加的专注于系统的业务逻辑，而不用过多地关注于如何在代码中向数据库插入一条数据，开发人员节省了编写基本增删改查SQL语句的时间，大大提升了开发效率以及开发质量。

Ø 对于复杂的查询，ORM框架本身提供的方法或许不能满足，在这种情况下可以依旧使用底层的ADO.NET进行Sql语句的编写，利用SqlHelper提供的一套封装好的、完善的数据库访问方法，可以很方便地对数据库进行操作，执行所需要的任何SQL语句、存储过程等。

Ø 数据访问层DAL中所有的数据访问类都继承与数据访问基类BaseDAL，该类提供了数据访问操作中常见的增删改查、分页等方法，使得每一个继承于该类的具体的数据访问类不用花费大量时间在最基本的数据库操作上，而是把重心转移为相关的业务逻辑的数据操作，从而提升了开发效率，降低了代码中产生低级Bug的几率。
【个人心得】

个人心得与总结日志

我的体会
1、
2、
3、
我打算做

第6章 项目进度监控评表
以附件：N一三34班项目进度控制表 为准：

【个人心得】

个人心得与总结日志

我的体会
1、
2、
3、
我打算做