计算机论文题目审批表

首先是选题，一般老师都会提供若干个选题给你选，其中必然包括几个“XX系统的设计与开发”，这样的选题就是符合我们前面的假设和预想的。盘他！假设我现在选了一个题目是“基于SSM的XX网上商城的设计与开发”。选完题目就面临着一个问题：是先做开发还是先写文章，或者是一边写一边开发。我的建议是一边写一边开发。原因是：开发的过程是需要写一些文案的，比如需求分析、数据库的表结构的关系、整个系统的交互逻辑等等。而这些文案是可以出现在我们的论文当中的。那接下来就说一下如何开发和写文论，当然某些开发过程我只能粗略的说一下。1.摘要：这是所有论文的第一个小title，说他恶心有时候也恶心，说他简单也是蛮简单的。那么这一部分究竟是要写什么的？由于这一部分需要展现出做这个系统的必要性、开发这个系统的实现方式、系统的功能和系统的作用。所以可以这样写：随着中国经济的高速发展以及网络技术的普及，互联网的技术得到全面的发展，中国的各行各业都在互联网的影响下发生了变革。互联网的快速发展催生了许多产业，其中最具代表性的便是电子商务，电子商务使得企业和客户的营销关系由实体店销售准换为网络电子商务营销。马云曾说：“让天底下没有难做的生意”，越来越多的店家选择在网上开店，使得交易不再限制于天南地北，同时也大大降低了店家的经营成本，在提高收益的同时，也方便了客户，本课题正式在这种背景下应运而生。本课题介绍了“基于SSM的XX网上商城”的开发环境、需求分析、界面设计和数据库设计以及涉及到的框架。本系统采用了B/S架构，使用了Java、HTML、JS等语言，使用了主流的后台开发框架SSM(spring+springMVC+Mybatis)，以及采用了开源的轻量级数据库Mysql进行开发，为网络商城提供了前端展示和后台管理的模块，实现了注册、登录以及购物等主要功能，为消费者提供了便捷快速的购物体验，以及为提高了店家的销售效率。关键字：网上商城，SSM，Java，HTML，JS，MySQL（关键字一般就是把摘要中提及到的关键性技术提取出来，让阅读者一目了然，知道哪些是重点）Abstract：......（英文摘要建议谷歌翻译，然后把明显错误的地方修改一下即可）2.第一章：引言这一部分也是比虚的，其实随便扯一扯就可以了，一般包含以下几部分1.背景2.研究内容。其中背景主要讲一些关于社会发展的趋势导致了一些什么问题，而这些问题又应该如何去解决，多说几句，写到两三百字即可。研究内容就是针对上述的背景我们如何进行改进。细心的同学可能会说，感觉跟摘要有些重复。是的！这两部分内容其实是挺重复的，但是没关系，不过不要使用完完全全一样的话去描述，因为最后论文查重的时候会对文章自引用进行查重的。这一部分也是三五百字即可。3.第二章：系统的开发技术介绍这一部分是需要我们在正式开发之前做好的技术调研，然后对这一部分的技术进行详细的介绍。这一部分我不可能细讲，因为内容太多了，而且对于不同的项目有不同的内容，在查阅资料的过程也是提升技术的一个重要的环节，你可以真真切切的了解到开发一个工程是需要哪方面的知识，因此我就对我所选的这个课题应该使用到的技术栈进行一下介绍，也算是抛砖引玉，各位同学可以根据自己的实际情况进行撰写。开发不同的系统虽然涉及到的业务逻辑不同，处理方式也千差万别，但是本质上都是一样的，都是前端界面通过服务器跟数据库进行数据交互的一个过程，涉及到的内容也无非就是前端、后台和服务器。但是有一个需要注意的点，就是不要把HTML、JAVA等使用的语言介绍也给堆在这里，老师没细看还好，细看还是会显得太水字数了，记住，写工程性的课题不怕没字数。那问题来了，语言介绍不给写那应该些什么呢？应该写涉及到的框架、使用的工具。这些就够了，随随便便就几千字了。下面举例简单说明一下。a. 前端强调一下，不要把HTML、CSS等一下前端的规范展开来写，可以轻描淡写，但篇幅不能过多。这里可以写前端框架的使用，比如使用npm管理包（可以介绍一下npm以及在工程中的使用）、vue的使用（同样可以介绍vue框架以及应用）、element（element以及使用他的好处）等等。也希望同学在做毕设的过程中要真的去了解这些技术并且去使用它，相信我，看完再去用你的技术会有质的飞跃。b. 后台这一部分是重点，对于本课题来说，标题就写了是基于SSM的。对于这个java框架并不熟悉的同学来说建议先去查一下资料，而且很多同学会有疑问，使用技术框架的目的就是为了让开发更加的便捷和快速，但是为什么我们自己在开发的过程中会感觉好像变得更加复杂？很负责任的告诉你，是正常的。因为框架不仅会帮我们封装好一些常用的方法，而且会考虑到更新迭代以及代码可读性等等的一系列的问题，某些规定和配置我们之所以没有感受到他的好处是因为这种校园内的开发并不涉及生产问题，也不会有很多的更新迭代，更加不会考虑到代码的可读性。例如spring的工厂，一开始使用的时候很多同学会觉得为什么我new一个类的时候还要去改配置文件，直接new不香吗？直接new是很香，但是你考虑到真正去工作的时候，假设你要改类的一些关系的时候，还要去改代码，当工程一大，代码去哪里找呢？一个一个文件看吗？显然是非常不可取的，效率非常低，这个时候配置文件的优势就发挥出来了，直接修改配置文件，不需要更改代码，耦合性也大大的降低。好像跑题了，说了这么多就告诉同学们，要沉住气，理解框架这样设计背后的原因，对大家自身技术的提高非常的有帮助！那这一部分我们就可以介绍spring（包括spring的IOC、spring的工厂、spring的AOP等等，并且可以在论文中强调如何应用到我们的系统当中）、springMVC（这一部分可以讲解srpingMVC作为一个连接前端和数据库的工具在实际工作过程中的具体流程，也可以讲述springMVC的分层的概念以及如何应用）、Mybatis（包括跟JDBC的关系、mybatis依赖的配置、使用到的接口、动态代理、一级缓存和二级缓存以及延迟加载等等的一些技术问题）c. 服务器和数据库这一部分可以介绍一下用来搭建服务器的工具和所使用的数据库。假设你是使用了云服务器来搭建了，可以详细介绍一下云服务器的搭建过程包括防火墙、端口等等内容。一般服务器使用tomcat进行搭建，可以把tomcat介绍一下并且介绍一下tomcat是如何监听和解析用户请求的具体流程。一般小型的项目采用MySQL作为数据库，可以详细说一下选择MySQL的原因，比如相对于Oracle的好处。可以介绍一下MySQL数据库的一些特点包括分页、是否支持事务等等。4.第三章：需求分析这一部分是针对具体的业务场景来分析需要开发哪些功能，这一部分可以让你感受一下产品经理的职责，只不过不需要跟程序员对接，因为你自己就是程序员哈哈。一般来说分成两部分就可以了，一部分是对于前端的业务流程，另一部分就是后台服务器的业务流程，可以使用一些软件来绘画流程图，想图个方便可以直接使用word自带的图形进行编写，也不至于难看，就比较简约。想做的好看点的话个人推荐使用xmind，非常简单，可以快速做出美观的流程图。如果没有什么思路，那前端就按照着使用者的逻辑去写，比如用户需要注册、登录、找回密码、购物、退货等操作，那后端就对应着这些前端逻辑需要有相应的业务处理。个人感觉这一部分比较好写，就不再赘述。5.第四章：系统的设计和实现这一部分可以挑选一些有代表性的功能出来细讲，有些同学可能会有疑问，论文可不可以贴代码呢？答案是可以的。但是我个人的建议是贴伪代码，不要把你写的长篇大论的代码全部放进去，不好看而且逻辑混乱，应该做的是把代码抽取为伪代码，贴代码的目的是为了让阅读者清晰地读懂你是如何实现这个功能的，他并不会在意你的语法你的命名。下面列举若干个可以写的内容，并不限于此。a. SSM框架的整合。如何使用Spring来整合并且管理SpringMVC和Mybatis.b. 客户登录状态保存的实现。这一部分可能会涉及到cookies，sessions以及http报文解析等等，都可以详解。c. 后台商品管理的功能。这一部分可以根据管理员的后台管理功能进行描写。d. 商品搜索功能。可以涉及到数据库的模糊搜索。e. 数据库表格的设计。可以体现数据库表格设计的时候如何遵守三范式。f. 可以写在开发过程中遇到的一些疑难杂症。g. 可以写开发过程中使用到的一些比较具有亮点的语言特性。比如java的多线程、lambda表达式。又比如实现注册功能的时候使用的正则表达式。……等等数不胜数。6.第五章：运行结果这一部分非常好写了。截取一些关于你的系统的界面并且介绍一下功能，尽量说详细点，就ok了。7.第六章：总结以及展望这一部分也是比较水的一部分，但是也希望同学们认真写一写。可以写一下你开发这个项目的过程中学习到了什么，可以是XX技术，也可以是艰苦奋斗的精神……。展望可以写有望发展成另外一个淘宝……开玩笑开玩笑，总之劈里啪啦凑个几百字即可。8.参考文献把你开发过程中参考过的文章、论文贴进去之后，往往会发现参考文献不够，太少了！那怎么办呢？那就贴一些关于使用的技术的文章或者参考手册咯，虽然大部分是没看过的，但是还是希望大家可以多少看一看（正义之气跃然纸上）。去知网查找参考文章然后添加到你的参考文献是非常方便的，只需要找到对应的文章并且选择“引用”功能，即可自动生成引用的文字，直接复制到你的论文中。9.致谢第一步，感谢你的导师，感谢你的院领导，感谢你的校领导。说的好听后可能答辩的时候不会太为难你……然后你要感谢你的家人你的舍友你的朋友或者是你家的狗（开玩笑），都可以的，这一部分又轻轻松松两百字。至此，一篇计算机论文就写完了，是不是觉得挺简单的呢？以上内容皆由学术堂提供整理。

接触异常开始我就弄不明白她，不会用她，想在系统中是异常机制发挥的淋漓尽致，进行了很多尝试，利用异常控制程序流程，利用异常做数字的判断函数，利用异常消除系统中可能出现的恼人的异常提示框，为了更好了利用异常看了很多关于异常的文章，直到有一天看到了一句话——“永远不要去处理你不知道怎么处理的异常”，这才恍然大悟，感觉自己一直在用强大的异常机制干一些旁门左道的是事，更谈不上理解异常在程序中的地位和意义，异常其实一种报告机制，“她以一种不可回避的方式报告程序中所出现的问题”，她帮助程序员走向正确的道路，她忠实的向程序员提供错误报告，她希望有谁能重视并处理掉她报告的问题，哈，真不敢想象，没有了异常机制该如何编制高质量的程序！下面就个人的理解和看法瞎说几句，敬请各位批评指正，不胜感激！ 异常的工作原理，在有问题的地方产生异常，马上停止当前的工作，转向异常处理代码，如果找不到异常处理代码，就会见异常向一层汇报，上一层接到异常会做同样的事，转向异常处理代码，或者再将异常向上汇报，这样逐层间错误传递出去，直到有一层处理了异常或是一直报告给程序的使用者——用户。这个层就是调用栈，当用户A运行程序B，B从函数C开始执行，调用函数D，再调用函数E，再调用函数F，这时F出现了异常，那么这个异常的调用栈就是A(栈底)—〉B—〉C—〉D—〉E—〉F(栈顶)，这个异常就会沿着这个栈从栈顶开始向栈底的方向报告，如果在函数C中有对这个异常的处理代码，那么这个异常的报告链就是F—〉E—〉D—〉C。可以看出，如果在完整的调用栈中没有处理这个异常的代码，用户A就成了异常报告的终点，向windows界面系统，会弹出一个恼人的消息对话框哈。那么用户A向谁报告呢，哈哈，这个已经不属于程序的范围了，感觉用会对程序而言好像上帝一样，诉说痛苦已经让上帝都听到了，就心满意足了哈哈，看来程序真虔诚哈哈。对于异常这个特性，也可以比喻成下属向上级报告问题，如果下属知情不报，问题就严重了，你要是领导知道下属是这样的八成就踢了他，相反如果你有一个报告机制健全的下属队伍，哈哈你就威风了。日本企业文蛤中有个宗旨——联络，商谈，报告，其实就是想让员工都具有向上级汇报的习惯。现在再看看程序，哈哈，你不用给她们灌输什么企业文化，不用她们讲述什么报告的重要性，她们本身就是忠实报告的，如果把程序员比作企业老总，那么程序就是训练一队有素的员工。怎样处理异常。在这里有个原则就是“永远不要去处理你不知道怎么处理的异常”，也就是只处理你知道如何处理的异常，对那些你不知道的异常必须广开言路，并积极地向上级汇报。什么叫知道如何处理呢？先说一下处理异常有哪些方式，大体有，弹出提示消息框(这个消息框不同于那个恼人的异常报告消息框，她是捕获异常后，根据处理的具体环境程序员主动编写的友好的提示消息框)，记录错误日志，吞掉，做善后工作等等，那么出现异常时就要站在出现异常的模块的立场上考虑一下我应该选择哪种处理方式呢？如果不能做出选择就选择不处理，即向上级报告。举个例子，函数Fun1是创建并返回一个活动的数据连接对象的方法，他接受一个数据库连接字符串，如果调用者（上级）给他一个错误的连接字符串，这时Fun1创建不了连接对象，产生了一个创建不了连接对象的异常，那么这时他应该怎样处理这个异常呢？弹出友好的消息框？说什么友好，Fun1根本就不知道是什么原因使他接收到了错误的连接字符串，弹一个“连接字符串有误”，用户肯定都有杀你的心，这个提示和用户的业务逻辑有嘛关系！记录错误日志，这个还行，但是记录下来的文字无非就是“连接字符串有误，连接字符串是：SQL……”，好点的话，从连接字符串中看出了问题，一般情况下还得根据代码上下文去找问题原因。这个方式不是不行是不好。吞掉，哈哈开什么玩笑，你既创建不了连接，又不吱一声，想让调用者疯了呀，这个肯定不行。做善后工作，行，确实应该清理一下现场，免得浪费资源，但是还是没吱一声，所以这个方式做的不彻底。没招了，哈，其实上面的分析给我们指明了一条路，帮助我们祛除了错误的选择，这条路就是向上汇报，或是不加任何出来代码，或是记录日志，做些善后，再重新将异常抛出。那么什么时候就知道怎样处理异常了，这就得看实际的情况和用户的要求了，这句话等于没说，就像其他的标题醒目但给出的结论却模棱两可文章一样，哈哈，这里可以给几个建议，1，一般地，底层模块或是方法中不要处理异常，2，编写公共模块、DLL等是，不能采用弹出对话框等依赖于平台，框架的方式处理异常，3，编写公共模块、DLL等时，必须在使用文档中注明每个方法属性可能抛出的异常。4，永远不要写 try 这样的语句。{ } catch(Exception) { o nothing } 自定义异常。明白了异常的原理和机制后，就可以自己定义异常了，这样的实践往往在编写控件、公共模块、DLL等的时候，用错误编号在网上搜索一下，能找出一大堆关于错误代码的描述。其中大多数是M(icro)S(oft)制定的，MS 从操作系统到各种各样的框架都有对各种异常的编号，对每种异常做出了详细的定义，如果你还用过像Spread等商业控件，也可以看到他里边的各种各样的异常定义，也就是说我们自己也可以定义异常，在必要的时候，这样就可以让自己写的模块也加入到训练有素的员工队伍中了。至于如何定义异常，具体的编成语言有具体的做法，比如C#中指定一异常一个从Exception继承来的类，VB中异常是个全局变量等等，参见感兴趣语言的语法指南就可以了。对异常的重新认识，一直以来许多人都认为异常是非常可怕的，可恶的，她是错误的化身，她有恼人的弹出对话框，弄得用户跟凶煞恶神似的哈哈，其实这些都是误解，异常一直默默地忠实的报告着程序中出现的严重的不可回避的问题，她为了程序、系统的正确性、严谨性呼唤你，希望你重视这些问题，希望你用智慧解决这些问题，她是多么的可爱，又是多么的高尚，从来没有因为对她的误解而放弃自己的使命……异常很重要，我们更好学会如何去使用她。

先下载，后修改。