基于Web的权限管理框架功能规格说明书

1基于WEB的权限管理框架功能规格说明书研究开发中心邵正军修订历史纪录20051114邵正军10初建名词解释WEB应用程序WEBAPPLICATION，又简称WEB应用、WEBAPP。最终用户最终使用WEB应用程序的用户，包括系统管理员、普通用户。CSSHTML页面上用它来控制显示样式，以达到样式和内容分离的效果。1前言本产品是个权限管理框架，为WEB应用程序的权限管理提供基础设施和框架。任凭人们发挥怎样的想象力，目前这份规格说明书都不是完整的，所有措辞都需要经过多次修订才能最后定稿。本说明书描述的是完全从用户（是指本框架的用户，包括WEBAPP开发者、最终用户）的视角看产品如何工作的内容。它不关心产品内部如何实现，它谈论的是功能特性。在这里给出屏幕图形与布局仅仅是为了演示背后蕴含的功能性，实际的外观与感觉（LOOKANDFEEL）将根据图形设计人员的输入与用户反馈随时间不断加以改进。2背景你是否有过需要为一个应用程序创建登录验证和授权机制的经历呢如果你是一个比较有经验的程序员，那你一定有过，而且可能不止一次了。那么，再回想看看，是不是会感觉每一次的新实现都好像似曾相识、可是又与以前不完全一样唔，这正是我们要思考的地方，为什么我们要一再地重复自己3目标我们的目标是产出一个基于WEB的通用权限管理框架（以下简称权限框架/框架），供BROWSER/SERVER结构的WEB应用程序（以下简称WEB应用/WEBAPP）使用，免去每个项目重复从头开发权限管理功能的痛苦，提高生产力。24范围界定权限框架用JAVA语言实现。如果你想在J2EE多层结构中寻找它的位置，那你到WEB层去找就对了，它的定位就在WEB层。它需要运行在SERVLET23/JSP12（ORLATER）规范兼容的WEBSERVER（譬如TOMCAT41XORLATER）中，为WEBAPP的权限管理提供基础设施和框架。本框架立足于满足大部分情况下粗粒度权限控制的需要，譬如系统功能（菜单、按钮等）的访问控制。对常见通用权限管理行为（譬如用户/角色信息维护、菜单/按钮的访问权限许可等）提供必要的缺省实现，也提供途径给WEB应用开发者覆盖这些缺省实现；对于细粒度的权限控制，譬如种种业务层面上的权限管理要求，由于权限框架无法预知也不能做任何假定，所以这也是框架实现难点所在。本框架的解决方案是以API的形式提供扩展点，WEB应用开发者在扩展点上插入满足自己业务规则要求的权限许可模块即可。由于外部扩展也是建立在权限框架的游戏规则上的，所以就保证了整个WEB应用的权限管理都是在协调一致的机制下进行。5权限模型解决复杂的权限管理问题的过程可以抽象概括为判断【WHO是否可以对WHAT进行HOW的访问操作（OPERATOR）】这个逻辑表达式的值是否为TRUE的求解过程。这里涉及的相关概念说明如下WHO权限的拥有者或主体。典型的有PRINCIPAL、USER、GROUP、ROLE、ACTOR等等。本框架的访问控制方法会采用“基于角色的访问控制（主，公认的有效方法）针对个别用户的访问控制（辅，增加灵活性）用户组”（这一点参见访问控制方法的考虑一节），所以直接跟授权有关系的实体就只有角色（ROLE）和用户（USER）。譬如业务经理（ROLE），张三（USER）WHAT权限针对的资源（RESOURCE）（包括资源类别（THETYPEOFRESOURCE）和资源实例（THEINSTANCEOFRESOURCE）。譬如报表。HOW亦作ACTION，表示某种访问方法（亦请参考OPERATOR条目解释）。譬如删除。3OPERATOR操作。表示施加于WHAT的HOW动作。是一种RESOURCERELATED的概念，单独的HOW动作是没有实际意义的，譬如删除；只有与具体资源结合在一起才有意义，譬如删除报表。访问控制方法的考虑51基于角色的访问控制基于角色的访问控制（RBAC）是目前公认的解决企业级的统一资源访问控制的有效方法。其显著的两大特征是1减小授权管理的复杂性，降低管理开销。2灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。概念示意图说明这种方法中，角色（ROLE）权限分配的单位与载体。权限不考虑分配给特定的用户。相对于基于用户（USER）的访问控制来讲，角色的数量比用户总是少得多，因此极大地降低了系统管理员授权管理的复杂性。同时一个用户可以身兼多个角色，给安全策略带来了很大的灵活性和伸缩性。对一个具体用户来讲，他拥有的权限是对该用户身兼的角色（可能是多个）授予的权限的并集（UNION）。这可以解决90的问题。但是，现实当中有一些比较特殊的情况，需要在角色的基础上再针对某个具体的用户指定特别的访问资源限制，这时就无法优雅地解决了。452基于角色的访问控制针对个别用户的访问控制这种方法立足于要解决上一种方法剩下的那10的问题。让系统管理员也可以针对某个具体用户指定权限，支持对角色授权同时对用户授权的情况。概念示意图说明对一个具体用户来讲，他拥有的权限是直接对该用户本身授予的权限和对该用户身兼的角色（可能是多个）授予的权限的并集（UNION）。从上图中箭头线的粗细可以看出，虽然权限框架同时支持两种方式及其结合，但还是希望有个主要/辅助之分针对角色的授权是公认的好方法，应为主；针对用户的授权用来配合解决特定情况下的需要，应为辅。这些道理要让系统管理员明白，最好能在系统授权界面上有所体现、有所提醒。这种方法看起来很不错唔，让我们再想想有无其他的需要对了，古语云物以类聚，人以群分。现实中的人们生活生产总是分成一组一组的，以组为单位分配事务似乎已成了现实中人的思维习惯，而我们的权限模型在这方面似乎还欠缺点什么53基于角色的访问控制针对个别用户的访问控制用户组这种方法立足于要弥补上一种方法留下的那个欠缺，引入“用户组（GROUP）的概念”。概念示意图5说明这种方法是完全建立在上一种方法之上的，与上一种方法不同点在于增加了用户组。人们可以按照现实中的思维习惯，将用户编成组，再将用户组与角色关联。当然用户仍然可以直接与角色关联。对一个具体用户来讲，他拥有的权限是直接对该用户本身授予的权限和对该用户身兼的角色（可能是多个）授予的权限和对该用户所属的组（可能是多个）授予的权限的并集（UNION）。所以，比对以上多种访问控制方法，我们判定，胜出者是“基于角色的访问控制针对个别用户的访问控制用户组”，这将是我们的权限框架的权限模型所采用的访问控制方法。6从系统边界看到的与本框架相关者说明6建立在本框架基础上的WEBAPP系统的权限子系统核心会涉及以下几个部分1在框架基础上的业务相关扩展（如果有的话）。参与者为WEBAPP开发者，在系统开发时进行。2定义权限。参与者为WEBAPP开发者，设计和实现系统时便需划分整个系统所有子系统或模块中，应该有哪些受控资源及其访问权限。这里完成的是PRIVILEGE与RESOURCE的声明，并没有真正将PRIVILEGE与具体RESOURCE实例联系在一起形成OPERATOR（这里的相关概念参见“权限模型”一节）。3分配权限。参与者为WEBAPP这个系统的最终用户中的系统管理员（ADMIN）角色。系统管理员指定PRIVILEGE与RESOURCEINSTANCE的关联。在这一步，权限真正与资源实例联系到了一起，产生了OPERATOR。系统管理员利用OPERATOR这个基本元素，来创造他想要的权限体系（这里的相关概念参见“权限模型”一节）。如，创建角色，创建用户组，给用户组分配用户，将用户组与角色关联，为不同角色分配相应权限等等，这些操作都是由系统管理员来完成的。4使用权限。参与者为WEBAPP这个系统的最终用户中的普通用户（USER）。他们使用系统管理员分配给的权限去访问各个定义好的受控资源。下文中在描述框架的功能规格时，会因时因景从不同的相关参与者的角度来阐述看法和要求，为便于醒目地识别，届时会以“相关”的形式（譬如“WEBAPP开发人员相关”）来表示，请读者注意此约定。7最终用户直接体验的功能此部分功能的用户是最终用户。从上层WEBAPP系统菜单的角度来看，权限系统提供的功能就表现为两个入口点（URL）1）权限管理；2）变更密码。前者面向系统管理员角色，属于受控资源；后者面向所有用户，属于不受控资源。下面分别详述。71权限管理系列功能这些功能维护着系统的安全保护机制，均涉及敏感信息，关系着权限子系统能否正常工作，所以这些功能本身均应该有安全保护机制，而且这种保护机制应该是内建于框架内的，不应该依赖于上层WEB应用（有趣，这容易让人想起那个古老的鸡与蛋的故事）。7这些功能应只有ADMIN角色才有权使用，被赋予系统管理员角色的所有用户皆可访问这些资源（功能）。任何角色和用户均无法剥夺系统管理员的这些权利。这些功能包括角色信息维护，用户组信息维护，用户信息维护，给用户组分配用户，将用户组与角色关联，为不同角色分配相应权限等等。这些功能汇集为一个入口点，一般通过上层WEBAPP的系统菜单进入（可能的菜单项名字是“权限管理”）。入口引出的页面长相大致如下页面分左右两帧，左帧为树形结构导航，所有的页面都将展示在右帧显示区。WEBAPP开发人员相关哦，老兄，你的这些页面长成什么样我的WEBAPP是经过美工专门设计的，有鲜明的主题，我可不想权限子系统看起来与我的产品格格不入本产品定位为权限框架，将来必为许许多多显示风格各异的WEBAPP所用，那么怎样才能使本框架的页面自然融入到这些WEBAPP中呢答案是使用CSS。框架的所有页面，其显示样式全部通过一个统一的CSS文件来控制，WEBAPP开发者将来只要把这个CSS文件替换成与相应WEBAPP匹配的风格即可，无需改动任何页面代码。711用户（USER）信息管理维护“用户列表”界面长相大致如下8说明点击用户名超链接和“新建”按钮会分别转至编辑和新建界面，这两个画面长相很类似，“编辑用户”界面大致如下说明你已看到，本框架支持针对个别用户的授权。但正如前文“基于角色的访问控制针对个别用户的访问控制”一节所述针对角色的授权是公认的好方法，应为主；针对用户的授权用来配合解决特定情况下的需要，应为辅。所以9此处在“授权”按钮旁边给出了相应的文字警示以提醒系统管理员。点击“授权”按钮，弹出用户授权界面，其长相请参见“角色授权界面”。用户密码是非常重要的信息，需要有相应的传输保密机制。WEBAPP开发人员相关观察力敏锐的WEBAPP开发人员已经看出一些问题来了，有的已经迫不及待地发问嘿，我说，这些信息你们存放在哪儿在引入你们这一套权限框架之前我们系统已经有了一些用户权限管理方面的数据库表，可是你们不至于要让我的系统有两套这样存储着相同意义的数据却结构相异毫不相干的数据库表吧那会徒生无尽烦恼并会彻底把用户弄糊涂那决不行嗯，问得棒极了我们的解答是这样正如你透过界面所看到的（真厉害），权限框架有一套用户权限管理方面的数据库表，表结构基于我们的权限模型（前文有述）。权限框架的产品包里会缺省提供主流数据库的建表脚本（MYSQL，ORACLE，SYBASE，SQLSERVER）。但在我们看来，WEBAPP开发者根本无需了解这些表的结构甚至于存在，因为你既然引入了权限框架，干嘛还要陷身于这些苦累的活呢，全部交给权限框架去处理吧有一种情况例外，就是上文提问中讲到的“在引入你们这一套权限框架之前我们系统已经有了一些用户权限管理方面的数据库表”，并且可能有许多程序在用这些表，为了引入权限框架而去改这些程序，WEBAPP程序员才不愿意干呢（重要的是这些程序并没有犯错）。我们这样解决这个问题框架可以不用自带的数据库表而用WEBAPP既有的。表名是什么，字段名是什么，这些都不重要，权限框架把这些做成灵活的可配置项；重要的是我们必须就这些表的结构和含义达成一致，这是协议，不满足这个协议，那你的数据库表就必须改（增），你的相关程序就必须改协议如下用户表用户名（字符型，PK），密码（字符型），用户全名（字符型）用户用户组映射表组名（字符型，PK），用户名（字符型，PK）用户组表组名（字符型，PK），描述（字符型）角色用户组映射表角色名（字符型，PK），用户组名（字符型，PK）角色表角色名（字符型，PK），描述（字符型）角色用户映射表角色名（字符型，PK），用户名（字符型，PK）712用户组（GROUP）信息管理维护10“用户组列表”界面长相与“用户列表”大致相同，但是在“删除”的处理策略上是这样的只有空的用户组（即没有关联到任何用户）才能够删除，否则不予执行删除动作并且给用户以友好的警示信息。点击用户组名超链接和“新建”按钮会分别转至编辑和新建界面，这两个画面长相很类似，“编辑用户组”界面大致如下713角色（ROLE）信息管理维护“角色列表”界面长相与“用户列表”大致相同，但是在“删除”的处理策略上是这样的只有满足以下条件才能删除角色，1）没有与任何用户组关联；2）没有与任何用户关联；3）没有与任何授权操作关联。除此以外不予执行删除动作并且给用户以友好的警示信息。点击“角色列表”界面的“新建”按钮会转至“新建”界面，大致长相如下11说明从现实情况总结来看，系统管理员授权管理的开销有时还是蛮大的，很多情况下从相近的已经授权的角色复制权限然后改一改要比全新从头授权要轻松得多。所以，本框架加入“从已有角色复制权限”这一功能纯粹是为了便于系统管理员工作。用户填写完毕点击“SAVE”，处理完毕后即会转向角色列表界面。点击“角色列表”界面的角色名超链接会转至“编辑”界面，这与“新建”画面长相很类似，“编辑角色”界面大致如下说明点击“授权”时会出现角色授权界面，其长相大致如下12“增加”的界面大致如下需要关注一点系统管理员在对角色进行权限许可授予时，往往是工作量巨大而且特别乏味。所以一定要注意尽量降低管理员管理开销。关于这一点，请看一个典型的场景某个系统中有一些公共的菜单需要开放给系统的每一个用户，譬如“修改密码”、“关于”、“系统帮助”等等（朋友，数一下吧，是不是几乎每个系统都有这种类似的情况），对系统管理员来说，这无疑是一种挥之不去的负担，他/她必须为每个用户都指定一遍这些公用菜单的访问权限这显然不是我们希望看到的情景，我们必须为系统管理员减负解决方法是单独设置一个不受访问权限控制的“非受控资源/公共菜单按钮”登记区，凡在此登记的菜单按钮都权限框架都认为其可为所有用户访问。“编辑”的界面大致如下72变更密码功能这个功能是提供给LOGIN到WEBAPP系统中的每个用户（包括系统管理员和普通用户）的，该资源应属于不受控资源，不在权限管理的授权范围，人人可访问。权限框架在提供这个功能的同时亦应有机制保证这一点。进一步说，系统投入运行后，新增加一个角色/用户，即便在没有接受系统管理员任何授权时缺省都是可访问这个功能的。WEBAPP开发者亦需要明白这个道理并适当安排菜单入口（可能的菜单项名字是“变更密码”）。这个功能的页面长相大致如下138登录（LOGIN）认证功能原则可插入（PLUGGABLE）性，低侵入性。设想一个场景一个WEBAPP系统从初期的DEMO原形（PROTOTYPE）逐步演化而来，到最后，功能基本完备了，是要考虑用户登录认证这一块功能的时候了。这时引入本权限框架，开发人员不需要改动WEBAPP任何既有代码，甚至于可以完全不晓得此登录认证功能的存在，即可享用框架带来的登录认证功能，完全是一种通过RUNTIME配置即可插入使用的机制。这就是我们想要提供的登录认证功能。技术实现相关或许会考虑使用SERVLETSPECIFICATION23的FILTER机制来实现。这种情况，WEBAPP开发人员只需把框架提供的拦截器通过WEBAPP部署描述文件配置好即可，它会拦截所有的HTTPREQUEST，若该用户已经是合法登录用户则放行，否则转向LOGIN页面。为了方便上层WEBAPP，该页面由权限框架提供缺省实现，无需WEBAPP编码实现。如果要求与相应WEBAPP的显示风格匹配，只要替换CSS文件即可。若CSS还无法满足要求，则可直接替换掉该页面文件，但这时有一点要求用户名域、密码域的元素名称以及FORM的METHOD、ACTION取值都必须与原文件相同。LOGIN页面的FORM的ACTION指向的TARGET必须是权限框架提供，因为这涉及到认证的动作以及下一步的对所请求资源的授权验证。再设想一个场景WEBAPP系统已经投入使用，有一个用户的职责就是每天察看某一张报表的数据。可是要看到这张报表他必须每次登录然后等待出现系统主界面，然后层层深入到第三层菜单，点击其中的一个菜单项，出现相应的画面，在此画面上点击某个超级链接，才能看到这张报表。很繁琐但这个用户是个聪明人，他把这个超级链接放到浏览器的“我的最爱”或者“收藏夹”中，期望每次点击此链接，系统登录后便直接转到这个请求的链接，他就可以看到报表了（我仅仅是看指定的报表而已，为什么需要每次看到主界面和讨厌的三层菜单）。上段描述的场景很典型，也合情合理。但并不是所有的应用都有这种情况，有的系统就要求不管你请求的是什么资源，每次都必须把你带到主界面。那么权限框架如何处理这两种不同的情况支持其中的哪一种解答是两种都支持，做成灵活的配置项，根据具体WEBAPP项目要求，通过RUNTIME配置即可。WEBAPP开发人员相关关于用户名/密码等信息的存储约定，请参见“数据库表协议”。9访问控制（ACCESSCONTROL）功能14此部分功能的用户是WEBAPP开发人员。正如权限模型一节所说，解决复杂的权限管理问题的过程可以抽象概括为判断【WHO是否可以对WHAT进行HOW的访问操作（OPERATOR）】这个逻辑表达式的值是否为TRUE的求解过程。当然，判定当前登录用户是谁（那个用户，什么角色等），那是权限框架的事情，所以WEBAPP开发人员在程序中只需向权限框架提问“可以对WHAT进行HOW的访问操作吗”。这就够了，这就是权限框架要提供给上层WEBAPP的API。大家要知道，一个系统在设计阶段便需划分整个系统应该有多少子系统、多少子模块、多少菜单、多少页面按钮，其中有哪些应该是受控资源，它的访问权限是怎样的。这是权限定义，完成的是PRIVILEGE（HOW）与RESOURCE（WHAT）的声明。直到系统管理员进行了权限分配时，权限才真正与资源实例联系到了一起，注册于某个地方（也许是数据库，也许是文件）。程序执行到向权限框架提问“可以对WHAT进行HOW的访问操作吗”时，框架会到权限注册处去匹配寻找，便可以做出该用户是否有权访问该资源的判定。基本上，访问控制可以有两个控制级别粗粒度表示类别（TYPE）级，即仅考虑对象的类别THETYPEOFOBJECT，不考虑对象的某个特定实例。比如，查询/报表管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。细粒度表示实例（INSTANCE）级，即需要考虑具体对象的实例THEINSTANCEOFOBJECT，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，查询/报表管理中，删除某报表，需要区分该报表实例是否为当前用户所创建。下面分别从这两个方面介绍本框架的支持情况91系统功能项权限控制（粗粒度权限控制）这种控制是系统最常见的需求，不同用户对系统功能项有不同的限制，通常表现为某些系统菜单、页面按钮的不可见或灰掉。在这一控制层面，权限框架提供直接完全支持。WEBAPP开发人员相关必须预先对全系统的受控以及非受控的功能项（菜单、按钮）作一个全局规划，保证每一个功能项分配有一个全局唯一的标识号，并向权限框架注册。然后只要在需要决定是否显示某个菜单、按钮之前，调用权限框架API向权限框架提类似问题“可以对NEWMENUPERMESSION“ABC”进行访问操作吗”即可，根据结果的TURE/FALSE决定是否显示这个菜单、按钮。92防止直接URL侵入15因为是WEB应用程序的缘故，浏览器不受WEBAPP或权限框架控制，所以单纯采用上一节的介绍的方法会导致安全隐患。请看一个场景因为权限不允许，用户张三的菜单“报表”被封掉了，在系统给他展现出来的界面中根本看不到这个菜单，于是他根本无法访问“报表”，OK，权限系统赢了可是，有一天张三上厕所的时候无意中看到李四在使用“报表”菜单，这小子打了鬼主意，乘李四离开座位的时候偷偷到他机器上，点击该菜单并记下其URL，然后回到自己机器前，在浏览器的地址栏敲入这个URL，哇，“报表”界面出现了瞧，这一下，权限系统输了，输得很惨所以，可以看到，这种“直接URL侵入”的问题是非常危险的，特别是在WEB应用中你根本无法阻止用户在地址栏输入任何东西。权限框架必须负责解决这个问题，这也是他的职责所在怎么解决哦，有一种简单的解决方法如下WEBAPP开发人员相关除了保证每一个功能项（菜单、按钮）分配有一个全局唯一的标识号外，每一个功能项还必须分配有一个全局唯一的HTTPREQUESTURL并向权限框架注册。这样的话，被限制访问的功能项，首先不会显示出来，其次就算用户在地址栏直接输入URL，也会被权限框架的拦截器拦截然后判定为非法，然后阻拦掉。于是系统就是安全的了93业务面上的定制权限控制（细粒度权限控制）系统功能项权限控制可以解决菜单按钮是否可见的问题，譬如所有RD研发员角色都可以看见报表列表界面的“删除”按钮、可以执行这个动作，而其他角色则不可以。这种方法确实可以解决类别（TYPE）级的粗粒度权限控制问题。但是它解决不了这样的实例（INSTANCE）级的细粒度业务规则级别的问题，譬如虽然所有RD研发员角色都可以看见报表列表界面的“删除”按钮、可以执行这个动作，但是只有选中的该报表是当前用户所创建才可以真正允许删除。正如前文“范围界定”一节所说，对于类似于这种，各种各样业务层面上的权限管理要求，由于权限框架无法预知也不能做任何假定，所以这也是框架实现难点所在。本框架的解决方案是以API的形式提供扩展点，WEB应用开发者在扩展点上插入满足自己业务规则要求的权限许可模块即可。由于外部扩展也是建立在权限框架的游戏规则上的，所以就保证了整个WEB应用的权限管理都是在协调一致的机制下进行。14大学本科生毕业设计（论文）撰写规范本科生毕业设计（论文）是学生在毕业前提交的一份具有一定研究价值和实用价值的学术资料。它既是本科学生开始从事工程设计、科学实验和科学研究的初步尝试，也是学生在教师的指导下，对所进行研究的适当表述，还是学生毕业及学位资格认定的重要依据。毕业论文撰写是本科生培养过程中的基本训练环节之一，应符合国家及各专业部门制定的有关标准，符合汉语语法规范。指导教师应加强指导，严格把关。1、论文结构及要求论文包括题目、中文摘要、外文摘要、目录、正文、参考文献、致谢和附录等几部分。11题目论文题目应恰当、准确地反映论文的主要研究内容。不应超过25字，原则上不得使用标点符号，不设副标题。12摘要与关键词121摘要本科生毕业设计（论文）的摘要均要求用中、英两种文字给出，中文在前。摘要应扼要叙述论文的研究目的、研究方法、研究内容和主要结果或结论，文字要精炼，具有一定的独立性和完整性，摘要一般应在300字左右。摘要中不宜使用公式、图表，不标注引用文献编号，避免将摘要写成目录式的内容介绍。122关键词关键词是供检索用的主题词条，应采用能覆盖论文主要内容的通用技术词条（参照相应的技术术语标准），一般列35个，按词条的外延层次从大到小排列，应在摘要中出现。13目录目录应独立成页，包括论文中全部章、节的标题及页码。1514论文正文论文正文包括绪论、论文主体及结论等部分。141绪论绪论一般作为论文的首篇。绪论应说明选题的背景、目的和意义，国内外文献综述以及论文所要研究的主要内容。文管类论文的绪论是毕业论文的开头部分，一般包括说明论文写作的目的与意义，对所研究问题的认识以及提出问题。绪论只是文章的开头，不必写章号。毕业设计（论文）绪论部分字数不多于全部论文字数的1/4。142论文主体论文主体是论文的主要部分，要求结构合理，层次清楚，重点突出，文字简练、通顺。论文主体的内容要求参照大学本科生毕业设计（论文）的规定第五章。论文主体各章后应有一节“本章小结”。143结论结论作为单独一章排列，但不加章号。结论是对整个论文主要成果的归纳，要突出设计（论文）的创新点，以简练的文字对论文的主要工作进行评价，一般为4001000字。15参考文献参考文献是论文不可缺少的组成部分，它反映了论文的取材来源和广博程度。论文中要注重引用近期发表的与论文工作直接有关的学术期刊类文献。对理工类论文，参考文献数量一般应在15篇以上，其中学术期刊类文献不少于8篇，外文文献不少于3篇；对文科类、管理类论文，参考文献数量一般为1020篇，其中学术期刊类文献不少于8篇，外文文献不少于3篇。在论文正文中必须有参考文献的编号，参考文献的序号应按在正文中出现的顺序排列。产品说明书、各类标准、各种报纸上刊登的文章及未公开发表的研究报告（著名的内部报告如PB、AD报告及著名大公司的企业技术报告等除外）不宜做为参考文献引用。但对于工程设计类论文，各种标准、规范和手册可作为参考文献。引用网上参考文献时，应注明该文献的准确网页地址，网上参考文献不包含在上述规定的文献数量之内。1616致谢对导师和给予指导或协助完成论文工作的组织和个人表示感谢。内容应简洁明了、实事求是，避免俗套。17附录如开题报告、文献综述、外文译文及外文文献复印件、公式的推导、程序流程图、图纸、数据表格等有些不宜放在正文中，但有参考价值的内容可编入论文的附录中。172、论文书写规定21论文正文字数理工类论文正文字数不少于20000字。文管类论文正文字数1200020000字。其中汉语言文学专业不少于7000字。外语类论文正文字数800010000个外文单词。艺术类论文正文字数30005000字。22论文书写本科生毕业论文用B5纸计算机排版、编辑与双面打印输出。论文版面设置为毕业论文B5纸、纵向、为横排、不分栏，上下页边距分别为25CM和2CM，左右页边距分别为24CM和2CM，对称页边距、左侧装订并装订线为0CM、奇偶页不同、无网格。论文正文满页为29行，每行33个字，字号为小四号宋体，每页版面字数为957个，行间距为固定值20磅。页眉。页眉应居中置于页面上部。单数页眉的文字为“章及标题”；双数页眉的文字为“大学本科生毕业设计（论文）”。页眉的文字用五号宋体，页眉文字下面为2条横线（两条横线的长度与版芯尺寸相同，线粗05磅）。页眉、页脚边距分别为18CM和17CM。页码。页码用小五号字，居中标于页面底部。摘要、目录等文前部分的页码用罗马数字单独编排，正文以后的页码用阿拉伯数字编排。23摘要中文摘要一般为300字左右，外文摘要应与中文摘要内容相同，在语法、用词和书写上应正确无误，摘要页勿需写出论文题目。中、外文摘要应各占一页，编排装订时放置正文前，并且中文在前，外文在后。24目录目录应包括论文中全部章节的标题及页码，含中、外文摘要；正文章、节题目；参考文献；致谢；附录。正文章、节题目（理工类要求编写到第3级标题，即。文科、管理类可视论文需要进行，编写到23级标题。）25论文正文251章节及各章标题论文正文分章、节撰写，每章应另起一页。各章标题要突出重点、简明扼要。字数一般在15字以内，不得使用标点符号。标题中尽量不用英文缩写词，对必须采用者，应使用本行业的通用缩写词。18252层次层次以少为宜，根据实际需要选择。层次代号格式见表1和表2。表1理工类论文层次代号及说明层次名称示例说明章第1章章序及章名居中排，章序用阿拉伯数字节11条111题序顶格书写，与标题间空1字，下面阐述内容另起一段款1111题序顶格书写，与标题间空1字，下面阐述内容在标题后空1字接排项1题序空2字书写，以下内容接排，有标题者，阐述内容在标题后空1字版心左边线版心右边线表2文管类论文层次代号及说明章节条款项一、（一）1（1）居中书写空2字书写空2字书写空2字书写空2字书写版心左边线版心右边线各层次题序及标题不得置于页面的最后一行（孤行）。26参考文献正文中引用文献标示应置于所引内容最末句的右上角，用小五号字体。所引文献编号用阿拉伯数字置于方括号“”中，如“二次铣削1”。当提及的参考文献为文中直接说明时，其序号应该与正文排齐，如“由文献8，1014可知”。经济、管理类论文引用文献，若引用的是原话，要加引号，一般写在段中；若引的不是原文只是原意，文前只需用冒号或逗号，而不用引号。在参考文献之外，若有注释的话，建议采用夹注，即紧接文句，用圆括号标明。不得将引用文献标示置于各级标题处。19参考文献书写格式应符合GB77141987文后参考文献著录规则。常用参考文献编写项目和顺序应按文中引用先后次序规定如下著作图书文献序号作者书名（版次）出版地出版者，出版年引用部分起止页第一版应省略翻译图书文献序号作者书名（版次）译者出版地出版者，出版年引用部分起止页第一版应省略学术刊物文献序号作者文章名学术刊物名年，卷（期）引用部分起止页学术会议文献序号作者文章名编者名会议名称，会议地址，年份出版地，出版者，出版年引用部分起止页学位论文类参考文献序号研究生名学位论文题目出版地学校（或研究单位）及学位论文级别答辩年份引用部分起止页西文文献中第一个词和每个实词的第一个字母大写，余者小写；俄文文献名第一个词和专有名词的第一个字母大写，余者小写；日文文献中的汉字须用日文汉字，不得用中文汉字、简化汉字代替。文献中的外文字母一律用正体。作者为多人时，一般只列出前3名作者，不同作者姓名间用逗号相隔。外文姓名按国际惯例，将作者名的缩写置前，作者姓置后。学术会议若出版论文集者，可在会议名称后加上“论文集”字样。未出版论文集者省去“出版者”、“出版年”两项。会议地址与出版地相同者省略“出版地”。会议年份与出版年相同者省略“出版年”。学术刊物文献无卷号的可略去此项，直接写“年，（期）”。参考文献序号顶格书写，不加括号与标点，其后空一格写作者名。序号应按文献在论文中的被引用顺序编排。换行时与作者名第一个字对齐。若同一文献中有多处被引用，则要写出相应引用页码，各起止页码间空一格，排列按引用顺序，不按页码顺序。参考文献书写格式示例见附录1。27名词术语科技名词术语及设备、元件的名称，应采用国家标准或部颁标准中规定的术语或名称。标准中未规定的术语要采用行业通用术语或名称。全文名词术语必须统一。一些特殊名词或新名词应在适当位置加以说明或注解。文管类专业技术术语应为常见、常用的名词。采用英语缩写词时，除本行业广泛应用的通用缩写词外，文中第一次出现的缩写词应该用括号注明英文全文。28计量单位20物理量计量单位及符号一律采用中华人民共和国法定计量单位（GB310031021993，见附录2），不得使用非法定计量单位及符号。计量单位符号，除用人名命名的单位第一个字母用大写之外，一律用小写字母。非物理单位（如件、台、人、元、次等）可以采用汉字与单位符号混写的方式，如“万TKM”，“T/（人A）”等。文稿叙述中不定数字之后允许用中文计量单位符号，如“几千克至1000KG”。表达时刻时应采用中文计量单位，如“上午8点45分”，不能写成“8H45MIN”。计量单位符号一律用正体。29外文字母的正、斜体用法按照GB310031021986及GB71591987的规定使用，即物理量符号、物理常量、变量符号用斜体，计量单位等符号均用正体。210数字按国家语言文字工作委员会等七单位1987年发布的关于出版物上数字用法的规定，除习惯用中文数字表示的以外，一般均采用阿拉伯数字（参照附录3）。211公式原则上居中书写。若公式前有文字（如“解”、“假定”等），文字顶格书写，公式仍居中写。公式末不加标点。公式序号按章编排，如第1章第一个公式序号为“（11）”，附录2中的第一个公式为（1）等。文中引用公式时，一般用“见式（11）”或“由公式（11）”。公式中用斜线表示“除”的关系时，若分母部分为乘积应采用括号，以免含糊不清，如A/BCOSX。通常“乘”的关系在前，如ACOSX/B而不写（A/B）COSX。212插表表格不加左、右边线。表序一般按章编排，如第1章第一个插表的序号为“表11”等。表序与表名之间空一格，表名中不允许使用标点符号，表名后不加标点。表序与表名置于表上，居中排写（见附录4）。表头设计应简单明了，尽量不用斜线。表头中可采用化学符号或物理量符号。全表如用同一单位，将单位符号移到表头右上角，加圆括号（见附录4中的例2）。表中数据应正确无误，书写清楚。数字空缺的格内加“”字线（占2个数字宽度）。表内文字和数字上、下或左、右相同时，不允许用“”、“同上”之类的写法，可采用通栏处理方式（见附录4中的例2）。表内文字说明不加标点。文管类的插表在表下一般根据需要可增列补充材料、注解、附记、资料来源、某些指标的计算方法等。21表内文字说明，起行空一格，转行顶格，句末不加标点。表题用五号字，表内文字及表的说明文字均用五号字，中文用宋体。表格容量较大，必要时表格也可分为两段或多段（这只能发生在转页时），转页分段后的每一续表的表头都应重新排字，重排表头的续表上方右侧应注明（续表）字样。213插图插图应与文字紧密配合，文图相符，技术内容正确。2131制图标准插图应符合技术制图及相应专业制图的规定。机械工程图采用第一角投影法，应符合附录5所列有关标准的规定。电气图图形符号、文字符号等应符合附录6所列有关标准的规定。流程图符合国家标准。对无规定符号的图形应采用该行业的常用画法。2132图题及图中说明每个图均应有图题（由图号和图名组成）。图号按章编排，如第1章第一图的图号为“图11”等。图题置于图下。有图注或其他说明时应置于图题之上。图名在图号之后空一格排写。引用图应说明出处，在图题右上角加引用文献编号。图中若有分图时，分图号用A、B等置于分图之下。图中各部分说明应采用中文（引用的外文图除外）或数字项号，各项文字说明置于图题之上（有分图题者，置于分图题之上）。图题用五号字，图内文字及说明均用五号字，中文用宋体。2133插图编排插图与其图题为一个整体，不得拆开排写于两页。插图应编排在正文提及之后，插图处的该页空白不够排写该图整体时，则可将其后文字部分提前排写，将图移到次页最前面。2134坐标单位有数字标注的坐标图，除无单位者（如标示值）之外，必须注明坐标单位。2135论文中照片图及插图毕业论文中的照片图均应是原版照片粘贴（或数码像机图片），照片可为黑白或彩色，应主题突出、层次分明、清晰整洁、反差适中。照片采用光面相纸，不宜用布纹相纸。对金相显微组织照片必须注明放大倍数。毕业论文中的插图不得采用复印件。对于复杂的引用图，可采用数字化仪表输入计算机打印出来的图稿。214附录22理工类论文附录的序号采用“附录1”、“附录2”等，附录顺序为开题报告、文献综述、外文文献的中文译文及外文复印件等。文管类论文附录序号相应采用“附录一”、“附录二”等。3、论文排版要求31纸张要求及页面设置名称格式要求纸张B5（182257），幅面白色页面设置上下页边距25CM和2CM，左右页边距24CM和2CM，页眉、页脚分别为18CM和17CM，对称页边距、左侧装订并装订线为0CM、奇偶页不同、无网格页眉宋体字五号居中页码宋体字小五号居中32封面详见模版、B5纸单面打印名称格式要求本科毕业设计/论文宋体字小二号，行距固定值25磅，间距段前、段后分别为05行，要求字体居中论文题目黑体字二号,行距固定值25磅,间距段前、段后分别为05行。论文题目中文字数不得超过25字,要求字体居中填写姓名宋体字小三号,行距固定值20磅,间距段前、段后分别为05行,要求字体居中大学楷体字小二号，行距固定值20磅,间距段前、段后分别为05行。每字间空1格,要求字体居中年月宋体字小三号，行距固定值20磅,间距段前、段后分别为05行。数字用阿拉伯数字，日期为论文提交日期,要求字体居中33封面2详见模版、B5纸单面打印名称格式要求本科毕业设计/论文宋体字小二号，行距固定值25磅,间距段前、段后分别为05行，要求字体居中论文题目黑体字二号，行距固定值25磅,间距段前、段后分别为05行。论文题目中文字数不得超过25字，要求字体居中学院（系）宋体字四号，行距固定值20磅,间距段前、段后分别为05行，字体左对齐专业同上学生姓名同上学号同上指导教师同上答辩日期同上34本科毕业设计/论文任务书单面打印本科毕业设计/论文B5纸，单面打印，不编页码2335中、英文摘要名称中文摘要英文摘要标题摘要黑体字小二居中，行距固定值20磅，间距段前、段后分别为1行ABSTRACTTIMESNEWROMAN体小二号居中，行距固定值20磅，间距段前、段后分别为1行段落文字宋体字小四号，行距固定值20磅TIMESNEWROMAN体小四号，行距固定值20磅关键词同上，“关键词”三字加粗同上，“KEYWORDS”两词加粗页码罗马大写数字，TIMESNEWROMAN体小五号字罗马大写数字，TIMESNEWROMAN体小五号字36目录名称示例格式要求标题目录黑体字小二号居中，行距固定值20磅，间距段前、段后分别为1行各章目录格式范例黑体字小四号,行距固定值20磅，两端对齐，页码右对齐节标题目录格式范例宋体字小四号，行距固定值20磅，两端对齐，页码右对齐，左缩进2字符条标题目录格式范例宋体字小四号，行距固定值20磅,两端对齐，页码右对齐，左缩进3字符（条标题目录文科左缩进2字符）页码格式范例罗马大写数字，TIMESNEWROMAN体小五号字37正文示例名称理工论文文科论文格式要求各章标题第1章一、黑体字小二号居中，行距固定值20磅，间距段前、段后分别为1行，理工类章序号与章名间空一个汉字节标题11（一）黑体字小三号，行距固定值20磅，间距段前、段后分别为05行，理工类题序与题名间空一个汉字条标题1111、黑体字四号，行距固定值20磅，间距段前、段后分别为05行，理工类题序与题名间空一个汉字款标题1111（1）黑体字小四号，行距固定值20磅，理工类题序与题名间空一个汉字正文段落文字宋体字小四号，段落首行左缩进2个汉字。行距固定值20磅（段落中有数学表达式时，可根据表达需要设置该段的行距）38其它名称格式要求结论标题要求同各章标题，正文部分宋体字小四号，行距固定值20磅，段落首行左缩进2个汉字参考文献标题要求同各章标题，正文部分宋体字小四号（英文用TIMESNEWROMAN体小四号），行距固定值20磅致谢标题要求同各章标题，正文部分宋体字小四号，行距固定值20磅，（英文用TIMESNEWROMAN体小四号）附录标题要求同各章标题，正文部分宋体字小四号（英文用TIMESNEWROMAN体小四号），段落首行左缩进2个汉字。行距固定值20磅，（段落中有数学表达式时，可根据表达需要设置该段的行距），装订时附录内容加封面大学毕业设计/论文评审意见表B5纸，单面打印，不编页码24大学毕业设计/论文答辩委员会评语表B5纸，单面打印，不编页码注1毕业设计/论文模版用WORD2003文档排版，详见教务处网页“文档下载”“实践教学用表”中毕业设计/论文模版，下载的模版文档会变形需要进行整理。2未注明事宜，请查看撰写规范有关要求。4、论文打印输出要求41输出样式计算机双面打印输出。42字体字号论文正文字体为宋体，小四号字。第一层次（章）题序和标题用小二号黑体字。题序和标题之间空1个字。第二层次（节）题序和标题用小三号黑体字。题序和标题之间空1个字。第三层次（条）题序和标题用四号黑体字。第四层次（款）题序和标题用小四号黑体字。第五层次（项）题序和标题用小四号宋体字。页码用小五号字，在底线下居中。论文的中文和外文摘要属二次文献置于目录前，并编入目录，按第一层次（章）的编辑要求处理。参考文献、致谢、附录同样按第一层次（章）的编辑要求处理，另起新页，与正文一起顺序用阿拉伯数字编页。43摘要及关键词中文摘要题头用小二号黑体字居中排写，然后隔行书写摘要的文字部分，摘要正文用小四号宋体，行距20磅。英文论文摘要另起一页，其内容及关键词应与中文摘要一致。英文选用字体TIMESNEWROMAN，字号与中文摘要相同。摘要的中、外文示例见附录7和附录8。摘要正文后下空一行打印“关键词”三字，关键词题头用小四号宋体字字体加粗顶格书写，然后空一格书写有关关键词，各关键词之间加标点符号“；”最后一词之后不加标点符号。44目录目录题头用小二号黑体字居中排写。目录中各章题序及标题用小四号黑体，其余用小四号宋体,行距为20磅。目录的打印实例见附录9和附录10。45正文层次正文层次的编排理工类论文应采用表3的格式，文管类可采用表4的格式。表3理工类论文层次代号打印说明25层次名称示例说明章第1章小二号黑体节11小三号黑体条111四号黑体款1111项1小四号黑体正文用小四号宋体表4文管类论文层次代号打印说明章节条款项一、（一）1（1）小二号黑体居中排空2字，小三号黑体空2字，四号黑体空2字，小四号黑体空2字，小四号宋体正文的示例参见附录11和附录12。46公式公式序号的右侧符号靠右边线顶边排写。公式较长时最好在等号“”处转行，如难实现，则可在、运算符号处转行，转行时运算符号仅书写于转行式前，不重复书写。公式中第一次出现的物理量应给予注释，注释的转行应与破折号“”后第一个字26对齐，格式见下例式中MF试样断裂前的最大扭矩（NM）；F试样断裂时的单位长度上的相对扭转角，F（RAD/MM）。公式中应注意分数线的长短（主、副分线严格区分），长分线与等号对齐，如213NX附录1参考文献示例参考文献1崔忠圻金属学及热处理北京机械工业出版社，1989，36452张安峰，邢建东，陆文华高铬铸铁的氧化行为金属学报，1993，29（6）2632683周敬跃，李伟文利用基元叶片理论单级跨音速轴流压气机特性见中国工程热物理学术讨论会北京工程热物理研究所，1985，1811964王连东镦粗新理论及新工艺的研究硕士学位论文齐齐哈尔东北重型机械学院,1992，126134DDL275JOHNKT,GEORGESAALLOYANDMICROSTRUCTURALDESIGNLONDONACADEMICPRESSINCLTD1993，1252362386SISLERHHELECTRONICSTRUCTUREPROPERTIESANDTHEPERIODICLOW,SELECTEDTOPICSINMODERNCHEMISTRYREINHOLDPUBLISHINGCORPORATION,1963，10278897CAIANQIUANANALYSISOFTHECRFEMOCSYSTEMANDMODIFICATIONOFTHERMODYNAMICPARAMETERSISIJ