开封大学KAIFENG UNIVERSITY毕业论文通讯录管理系统的设计与实现姓名:xxxx院系:软件技术学院专业:软件技术班级:09级软件四班指导教师:x x x目录论文摘要 (3)前言 (4)一、管理信息系统的开发 (4)（二）MIS系统开发过程 (5)二、可行性研究及需求分析 (6)（一）可行性研究 (6)（二）需求分析 (7)三、通讯录管理系统的概要设计 (7)（一）通讯录管理系统用例图 (8)（二）通讯录管理信息系统概要设计 (8)（三）通讯录管理信息系统的功能模块说明 (9)四、通讯录管理系统的界面设计 (9)（一）概念设计 (9)（二）数据库逻辑结构设计 (11)五、通讯录管理系统的详细设计 (14)（一）开发工具的选择 (14)（二）编码规范 (14)（三）系统模块的详细设计 (15)六、系统测试 (27)七、系统的运行 (28)（一）硬件约束 (28)（二）系统运行环境 (28)结束语 (29)参考文献 (29)论文摘要通讯录管理系统是方便同学间交流、联系而设计的一个系统。
它主要分为两大部分，一个是同学录管理系统，一个是同学之间交流的区域。
该系统由三个要素组成，分别是：管理员、好友和其他成员，他们之间相互联系，形成了一个有机的整体。
为提高用户对该系统的满意，必须正确处理他们之间的关系。
本系统总体上分为三大界面：登陆界面、注册页面和管理页面。
具体是新用户在登陆界面有个注册帐号连接，输入无误后可进入注册页面，注册完后用户可以加入自己的好友，用户还可以自己注册个人信息。
通讯录管理系统是一个专门针对储存用户联系方式以及一些简单个人信息的实用管理系统，它方便了用户对众多同学、朋友、同事等个人信息的储存和快速查阅的功能，大大减少了查找过程的时间。
【关键词】VS .NET 2008 数据库数据库组件E-R图前言通讯录管理系统是典型的信息管理系统(MIS),其开发主要包括后台数据库的建立和维护以及前端应用程序的开发两个方面，一方面要求建立起数据一致性和完整性强、数据安全性好的库另一方面则要求应用程序功能完备,易使用等特点。
本文分析了通讯录管理系统的应用需求，按照数据库设计理论一步一步地给出了系统需求说明书、全局ER图、系统关系模式，子模式，建立了数据库.然后进行了具体的程序设计，实现了数据库表的浏览，记录的添加、删除和修改，报表的生成，实现了多数据库表的连接操作，实现了条件查询和模糊查询，并灵活实现了对不可更新查询结果集的更新操作，实现了密码修改维护功能，设计充分利用Visual Studio .NET 2008进行开发，提高了编程效率。
本文对通讯录管理系统的整个设计开发过程的进行了详尽的介绍。
第一章对MIS系统的开发方法和过程进行看阐述。
第二章对通讯录管理系统的开发进行概述，介绍了系统开发的方法以及过程、系统的功能、特点及开发本系统的意义。
第三章阐述了对通讯录管理系统的分析和系统功能模块化设计思想，引入了功能模块设计思想，并介绍了系统中的数据库和表的设计，包括对每一张表的详细说明。
第四章详细介绍了该系统数据库的相关设计及其所要实现的数据存储。
第五章详尽的阐述了该系统的设计流程和实现方案，本章详尽对系统的实现作了介绍，包括各级菜单的实现及用户界面的实现，第六、七章介绍的是系统中遇到的问题及解决的方法，和程序调试的想法。
文章的最后是对本次毕业设计的总结，同时还附上了论文的主要参考文献。
一、管理信息系统的开发(一)MIS系统开发方法管理信息系统的开发方法有原型法和面向对象的开发方法等：原型法的开发思路是首先根据用户的要求，由用户和开发者共同确定系统的基本要求和主要功能，利用系统快速生成工具，建立一个系统模型，再在此基础上与用户交流，将模型不断补充、修改、完善，如此反复，最终直至用户和开发者都比较满意为止，从而形成一个相对稳定、较为理想的管理信息系统。
面向对象的开发方法于20世纪80年代开始兴起的，是一种基于问题对象的自底向上的一种系统开发方法，这种方法的特点是以对象为基础，对象是分析问题和解决问题的核心。
（二）MIS系统开发过程一个MIS系统的开发过程一般包括如下几个步骤：1. 需求分析：需求分析主要是了解用户的需求。
一般的开发团队中，需求分析都是由资历较深的系统分析员或项目经理担当，可见它的重要性。
2. 概要设计：概要设计紧跟在需求分析之后。
用户需求明确后，将得到的数据分析后，开始构建数据库的逻辑结构。
此时，数据库中的表格还未成形，通过各种分析工具画出数据流图，最后就可抽象出数据库的具体表结构。
这时由系统分析人员反复审核。
确认所有的需求都考虑在内，没有遗漏后，就可以开始制订概要设计文档。
概要设计文档形成后，整个程序的逻辑框架也就形成了。
3. 详细设计：概要设计完成后，根据设计中制订的业务模块。
就可以进行详细分析设计了。
详细设计就是将各个业务模块的窗口全部建好，各个窗口控件的处理代码全部用语言表达出。
4. 编码：程序编码相对于其他环节来说比较简单，程序员只需要根据详细分析文档写程序编码，保证代码没有错误即可。
需要在不断的实践中形成自己独特的风格。
总的来说，不要过分地追求复杂的算法，因为那可能会导致后期维护人员无法读懂你的代码而造成维护的困难。
5. 测试：程序编码完成后，就需要测试。
测试有几种类型，主要是测试代码有无逻辑错误以及在加载数据环境下程序的稳定性问题。
测试工作中发现的错误应及时改正，然后将它记录到测试文档中。
6. 打包：测试完成，确认无误后。
程序就可以打包发行了。
打包一般使用工具如PWISE等。
7. 维护:由于之前需求分析的不足，或是程序编码上的漏洞等，所以在程序打包发布之后，还有一项重要的工作就是对系统的维护。
维护包括：改进性维护、适应性维护、完善性维护及预防性维护等。
二、可行性研究及需求分析（一）可行性研究通讯录管理系统在实际中应用广泛，其中的很多的功能都很齐全也很强大。
它不仅是新老同学联系的桥梁，而且还是自我娱乐的好方式。
通讯录管理系统的功能一般包括：查询（查看、预览）、更新（添加、修改、删除、注册）及生成预览报表等功能。
实现的功能概括为用于注册用户，以及用户的同事,朋友；还供注册用户的个人资料进行修改；对于用户的联系，方便同学之间的查找；可以对于自己的朋友,同事,做进一步的资料获得；用户可以对朋友的基本资料作相应的改动；可以对于朋友的基本资料作相应的删除, 以适应自己需要等等。
但有这些优点的同时它也存在着一定的缺点，就比如更新不够多样化等等。
但一定会在短时间内弥补这些缺点，提高质量，完善功能。
以便系统能完成，实行更多的功能给用户带来方便。
可行性研究的目的使用最小的代价在尽可能短的时间里确定问题是否能解决，通过复杂系统的规模与目标，研究与此类似的系统后，我们具体从下面两个方面考虑。
（1）技术上可行性研究。
由于对通讯录管理系统这一类的联系记录管理系统进行开发已有一定的时期，有很多成功的实例，技术基础也已经非常雄厚，因而技术上的准备应该不成问题。
（2）经济上可行性研究。
由于通讯录管理系统是一个比较小型的系统，是由我一个人进行开发的，所以从人力、物力、财力方面来说都是可行的。
（3）操作可行性。
在对问题正确定义的基础上，通过分析问题，导出试探性的解，然后复查并修正问题定义，再次分析问题，改进提出的问题，以便最后保证系统的正常运行。
（二）需求分析通讯录管理涉及个人信息、好友信息、个人兴趣爱好信息等多种数据管理。
从管理的角度可将通讯录分为三类：个人信息管理、好友信息管理、好友数据管理。
通讯录信息管理包括好友添加、删除、查询等操作，系统用户管理包括系统用户类别和用户数据管理，通讯录管理系统主要应具有以下功能：具体功能如下：设计不同用户的操作权限和登陆方法用户维护借个人信息用户查看个人情况信息维护作者个人密码根据好友情况对数据库进行操作并生成报表根据修改情况对数据库进行操作并生成报表查询及统计各种信息维护好友信息三、通讯录管理系统的概要设计（一）通讯录管理系统用例图图1系统用例图（二）通讯录管理信息系统概要设计根据实际情况，使用原型法即以少量代价快速地构造一个可执行的软件系统模型。
使用户和开发人员可以较快地确定需求，然后采用循环进化的开发方式，对系统模型作连续的精化，将系统需具备的性质逐渐增加上去，直到所有的性质全部满足。
此时模块也发展成为最终产品了。
通过对用户需求的分析，我可以分析出该通讯录管理信息系统大致可以分为几个模块：用户个人维护管理模块、作者基本信息、好友基本信息管理模块、密码修改模块、用户修改好友管理模块、好友查询管理模块等。
模块图如下：图2功能模块图（三）通讯录管理信息系统的功能模块说明用户维护管理：系统用户身份的确认、录入、修改与删除。
普通用户管理：包括个人注册、填写基本信息、返还修改、删除和注销等。
好友管理：好友基本情况查询；好友个人数据的录入、添加、修改和删除等。
普通用户管理：包括个人注册、填写基本信息、返还修改、删除和注销等。
好友管理：好友基本情况查询；好友个人数据的录入、添加、修改和删除等。
四、通讯录管理系统的界面设计（一）概念设计在概念设计阶段中，设计人员从用户的角度看待数据及处理要求和约束，产生一个反映用户观点的概念模式。
然后再把概念模式转换成逻辑模式。
将概念设计从设计过程中独立开来，使各阶段的任务相对单一化，设计复杂程度大大降低，不受特定DBMS 的限制。
利用ER方法进行数据库的概念设计，可分成三步进行：首先设计局部ER模式，然后把各局部ER模式综合成一个全局模式，最后对全局ER模式进行优化，得到最终的模式，即概念模式。
1、设计全局ER模式所有局部ER模式都设计好了后，接下来就是把它们综合成单一的全局概念结构。
全局概念结构不仅要支持所有局部ER模式，而且必须合理地表示一个完整、一致的数据库概念结构。
（1）确定公共实体类型为了给多个局部ER模式的合并提供开始合并的基础，首先要确定各局部结构中的公共实体类型。
在这一步中我们仅根据实体类型名和键来认定公共实体类型。
一般把同名实体类型作为公共实体类型的一类候选，把具有相同键的实体类型作为公共实体类型的另一类候选。
（2）局部ER模式的合并合并的原则是：首先进行两两合并；先和合并那些现实世界中有联系的局部结构；合并从公共实体类型开始，最后再加入独立的局部结构。
（3）消除冲突冲突分为三类：属性冲突、结构冲突、命名冲突。
设计全局ER模式的目的不在于把若干局部ER模式形式上合并为一个ER模式，而在于消除冲突，使之成为能够被所有用户共同理解和接受的同一的概念模型。
（4）全局ER模式的优化在得到全局ER模式后，为了提高数据库系统的效率，还应进一步依据处理需求对ER模式进行优化。
一个好的全局ER模式，除能准确、全面地反映用户功能需求外，还应满足下列条件：实体类型的个数要尽可能的少；实体类型所含属性个数尽可能少；实体类型间联系无冗余。