修改毕业设计论文

修改毕业设计论文内容摘要：

设置 “→” 用户管理 “→” 用户修改 “ 菜单， 其窗体由五个标签、两个文本框、两个组合框和一个按钮组成，分别设置它们的属性，其中两个组合框的属性设置为只读属性。 在用户修改的窗体里选择用户名即可修改用户密码和权限，系统价自动更改后台数据库的用户信息。 设计界面如图 所示 图 用户修改 删除模块设计 选择 ” 系统设置 “→” 用户管理 “→” 用 户删除 “ 菜单， 窗体设计较简单，分别由一个文本框、一个组合框和两个按钮组成，组合框的属性设置为只读属性。 由于删除的用户只可以是后台数据库中存在的用户 在下拉按钮中选择要删除的用户名，即可删除用户名及其有关信息。 关于用户管理的子菜单，只有管理员有权限进入设置。 基本工资模块设计 选择 ” 设置 “→” 基本工资 “ 菜单，自动弹出基本工资设置的对话框（如图 所示 ） ， 在网格中会显示数据库中现有的基本工资级别和金额，用户在填写完级别和金额后单击添加或者修改按钮进行后台数据库的更新。 在网格中选择要删除的基 本工资，点击删除按钮，系统会自动进行删除，并且所有的操作后会自动刷新网格，以及时提供给用户信息。 图 基本工资设置 选择 ” 设置 “→” 岗位工资 “ 菜单后，自动弹出 对话框 ，其功能与基本工资设置相同，在此不在赘述。 信息维护模块设计 选择 ” 信息维护 “→” 部门管理 “ 菜单后会出现如图 对话框，管理员用户可以通过网格浏览现有库中的部门信息，在部门信息框架中输入部门信息，同时也可添加、修改部门信息，数据库自动更新。 当删除一条信息时，会出现如图 所示 提示信息，用户可以选择删除 或者取消操作。 但如其部门已经被引用，则 delete语句会与约束条件发生冲突，不能删除。 图 确定删除对话框 图 部门 管理 设置 选择 ” 信息维护 “→” 员工管理 “ 菜单后会出现如下对话框， “性别”组合框默认为“男”，如用户输入的不是“男”或者是“女”时，添加操作将不能进行，并且 在填写员工信息时，员工的性别默认为 “ 男 ”。 其 进行的操作与部门管理相同，不再 赘述。 添加工资模块设计 选择 ” 信息管理 “→” 发放工资 “ 菜单，网格显示的是现有后台数据库中的员工工资信息，右 边可以直接浏览员工工资信息。 直接点击选择网格中的工资信息，单击删除按钮可直接删除。 考虑到设计页面的大小问题，对工资信息的添加和修改操作转移到另一个窗体 （如图 所示）中进 行。 用户可以在工资信息中输入员工的工资信息，由于添加和修改的操作同时在一个窗体中进行，员工编号不知道要添加的哪一个，所以员工编号的下拉按钮不是 “ 只读 ” 属性，用户在输入员工编号时应输入一个存在的员工，不然则弹出 如图 所示 的提示框。 图 工资信息设置 图 员工不存在提示 员工查询模块设 计 选择 “ 工资查询 ”→“ 按员工查询 ” 菜单，弹出如 图 所示 对话框， 用户 可以选择单人查询或者全部显示，但是不能对员工的工资做任何的改动。 管理员可以查看所有人的工资情况，但是普通用户只可以查看自己的工资情况，别人的工资情况不允许查看。 图 按员工查询 选择 “ 工资查询 ”→“ 按部门查询 ” 菜单，弹出对话框，当选择 “ 部门编号 ” 后可执行 “ 单个显示 ” ，若想全部显示，可直接单击 ” 显示所有 “ 按钮。 网格中将会同时刷新后台数据库信息，但是不能做任何的修改。 第五章 各模块设计要点 登录模块设计 登录模块是所有用户进入工资管理系统的唯一途径，除了确定用户类型以外，还要注意用户登录的密码是否与后台数据库的一致，如果不一致则会弹出图。 用户在登录模块出现的所有情况我都予以考虑了。 在用户登录时根据判断用户的权限，在模块中有“ If power 管理员 Then = False = False”的代码，此项决定了主界面的操作模块。 在调试所有登录情况都成功后，我想到了一种恶意登录此系统的情况，因此我设置了“ try_times”来限制用户的强制登录如图 所示。 用户管理设计 在添加用户模块中，我仿造了一般填写信息时的方法设计了“确认密码”操作，如果在操作错误时候会弹出如图 所示的提示信息，点击确定后，鼠标自动停在密码文本框中，用户不需要再次输入用户名，在此说明一下，在我做的系统中几乎所有的错误转移都有如上的提示和 获得焦点的操作。 删除用户模块中，在用户点击了确定按钮以后，会有如图 ，为用户删除考虑了情况。 图 “确认密码”错误 信息管理设计 这个部门主要由部门信息和员工信息组成，发放工资是对员工工资的管理，部门信息的设置和员工信息设置基本相同。 员工信息中引用了“ DTPicker”控件，默认的日期为登录的日期，用户可以点击直接更改日期，增强了程序的完整性。 还有值得一提的是在员工信息录入的时候，由于后台数据库“性别”设置默认为“男”，因此我设置了默认为“男”的操作，具体看代码中叙述。 如果用户没有完成信息的录入却点击了“确定”按钮后，会出现如图。 如果用户在使用添加按钮时，输入了一个已经存在的员工编号，根据主键的不可重复性，员工信息不能插入后台数据库，则会弹出如图 所示的对话框。 图 提示信息 图 添加存在情况 发放工资主要是对企业已有员工的工资设置，提供了添加、修改和删除操作。 添加操作和修改操作都在一个对话框中进行，根据数据库数据参照完整性，其中基本工资和岗位工资必须是已经存在的级别，其文本框被设置为“只读”属性，用户不可自动输入信息。 查询工资设计 查询工资时主要考虑 用户的权限问题，主要在登录模块中用全局变量记录了用户的权限，在用户点击确定以后系统会统计权限，分配给用户正确的查询工资的方法。 第 六 章 测试与维护 系统测试 在 MIS 开发过程中采用了多种措施保证软件质量，但是实际开发过程中还是不可避免地会产生差错，系统中通常可能隐藏着错误和缺陷，未经周密测试的系统投入运行，将会造成难以想象的后果，因此系统测试是 MIS 开发过程中为保证软件质量必须进行的工作。 大量统计资料表明，系统测试的工作量往往占 MIS 开发总工作量的 40%以上。 因此 ，我们必须重视测试工作。 由于程序中隐藏的缺陷只在特定的环境下才有可靠显露，系统缺陷通常是由于对某些特定情况考虑不周造成的。 因此测试不是为了表明程序正确；成功的测试也不是没有发现错误的测试。 有意义的软件测试应该是从“破坏”软件系统的角度出发，精心设计最有可以暴露程序系统缺陷的测试方案。 因此软件测试的目标应该是以尽可能少的代价和时间找出软件系统中潜在的错误和缺陷。 从产品角度看，测试计划中的测试项目包括软件结构中的分系统层、子系统层、功能模块层、程序模块层中的各类模块，从测试本身看，分为单元测试，组合测试，确 认测试等。 测试对象是随阶段而异的，最基本、最初的测试是单元测试，后面的组合测试、确认测试都是以被测过的模块作为测试对象的。 (1) 单元测试： 单元测试也称模块测试或程序测试，单元测试是对每个模块单独进行的，验证模块接口与设计说明书是否一致，对模块的所有主要处理路径进行测试且与预期的结构进行对照，还要对所有错误处理路径进行测试。 对源码进行审查，对照设计说明书，表态地检查源程序是否符合功能的逻辑要求，是进行单元测试前的重要工作工。 单元测试一般是由程序员完成，也称程序调试。 (2) 组合测试 组合测试也称集成测 试或子系统测试，通常采用自顶向下测试和自底向上测试两种测试方法。 组合测试的对象是指已经通过单元测试的模块，不是对零散模块进行单个测试，而是用系统化的方法装配和测试软件系统，是一个严格的过程，必须认真地进行，其计划的产生和单元模块测试的完成日期要协调起来，这种测试应在系统目标机上进行，造成系统应用的环境条件，除了开发部分项目负责人参加以外，还应该有相应系统的用户参加，给评审员进行演示。 (3) 确认测试 确认测试是对通过组合测试的软件进行的，这些软件已经存于系统目标设备的介质上，确认测试的目的是表明软件是可以 工作的，并且符合“软件需求说明书”中规定的全部功能和性能要求。 确认测试是按照这些要求定出的“确认测试计划”进行的。 测试工作是由一个独立的组织进 行，而且测试要从用户的角度出发。 (4) 系统测试 系统测试是对整体性能的测试，主要解决各子系统之间的数据通信和数据共享问题以及检测系统是否达到用户的实际要求，系统测试的依据是系统分析报告。 系统测试应在系统的整个范围内进行，这种测试不只对软件进行，而是对构成系统的硬、软件一起进行。 系统测试与建构同时进行或略慢。 系统测试需要确认从头到尾的功能正常才算完成，应当尽量避免系 统测试延到项目末尾进行 (5) 用户验收测试 在系统测试完成后，进行用户的验收测试，它是用户在实际应用环境中所进行的真实数据测试。 在具体的测试中，一般应遵循以下原则：由程序设计者之外的人进行测试；测试用例应由两部分组成：输入数据和预期输出结果；应选用不合理的输入数据与非法输入测试；不仅要检验程序是否实现预期功能，还应检查程序是否做了不应该做的工作；集中测试容易出错的程序模块；对程序修改以后，必须重新进行测试。 在开发本系统时，为了使系统能够稳定运行，对本系统进行了有针对性的全面测试，采取的方式是： 菜 单项测试： 为了保证每一项下拉菜单能够正确实现系统设计的功能，我把相关的基础数据，基本上全部输入到本系统中，并对每一个菜单项反复进行了增加、删除、修改等操作，从而保证了菜单级功能的正确实现。 数据跟踪： 完成菜单项测试后，我又对系统内的每一个数据进行了跟踪。 例如：在成绩管理模块中，我首先对考试类型进行设定，然后在成绩添加模块中进行数据操作，随时观察这两个模块之间是否有冲突产生，配合得是否正确，再然后在成绩浏览模块中进行验证，说明该功能完全正常，对其它的功能模块也进行了类似的设置。 综合测试： 在以上 测试的基础上对系统功能进行了整体的测试，依次来检验系统功能是否符合系统设计的要求。 系统运行与维护 系统的运行： 初始数据的输入 本系统的输入采用鼠标和键盘相结合的输入方法。 怎样使用本系统： 本系统的使用相应简单，基本上只要会使用 Windows 软件就会使用本系统，在具体的操作时， 只需点击鼠标左键即可进行相应功能的选择。 系统的维护： 本系统是个较复杂的人 机系统，由于系统外部环境与内部因素的变化，不断影响系统的运行，同时需要系统不断地适应这些变化，不断地完善系统，以提高系统运行的效率与服 务水平，这就需要自始至终进行系统的维护工作。 系统的维护主要包括四个方面： （ 1）程序的维护：指的是修改部分或全部程序，这种维护往往是在条件发生变化或原系统的效率低的情况下进行的。 （ 2）数据文件的维护：指的是按照用户的要求对数据文件进行不定期的修改。 （ 3）代码的维护：随着系统的发展和变化，可能会出现旧代码不能适应新要求的问题，因此，有必要变更代码，予以维护。 （ 4）硬件的维护：指的是对系统所使用的设备进行维护。 本系统的日常维护由系统的专人来负责，如果出现一些不能解决的问题，则由开发者来负责。 结束 语 这次的毕业设计用 2 个月的时间，在这两个多月的时间里自学 Visual Basic 的一些教程 、课程代码设计等。 从这个过程给我感触到了不少东西。 一些看起来很容易的东西，等真正做起来的时候就不一样了。 以前没有过类似的经验，这次作为第一次课程设计课，我抱着试试看的态度去写，一开始看了只有这么几个模块是心里挺高兴的，但是当我真真正正地去把一个操作写成功时，很多意想不到的情况发生了。 有时候会为了一个操作不能调试成功而整个晚上都不能去安心做其他的作业。 编程是一个很繁琐的过程，要考虑到很多错误转移情况，在这期间 会有很多以前不曾想过的问题出现，次数多了，不免会有觉得做不下去的感觉。 但是我从中发现，只要一步一步调试、静下心来看待问题，再复杂再微小的问题都会迎刃而解，当一个程序被调试出来时，那时的快乐相比与任何困难都值得的。 在着手写程序时觉得思路一片混乱，无意间出现的问题会不知道怎么解决。 这时，需要去再看看一些教程，去请教一些学的比较好的同学。 几乎所有情况都会有解决方法。 这需要我们耐心的去寻找问题的答案。 书到用时方恨少，经过这次设计真正的体会到了这句话的含义。 我们还要不停的去努力。 还有好多东西等待我们去学习。 致 谢 在这次设计的过程中，我的同学和老师给了我不少帮助。 多谢多次帮助我的那位同学和一直关心我的马艳芳老师。 由于此次设计的主要语言 Visual Basic 语言没有经过正式的教学，在很多方面都还存在一知半解的情况，正是由于你们的帮助和指导才让我能完成这次设计。 在这次设计之中学到了不少知识，真正的体会到了软件制作的乐趣。 衷心的感谢你们。 但。