河南科技大学自考论文模板

业务规则发现及其引擎应用研究

摘要

【从这里键入摘要内容。字体和格式均不需要修改。页面格式已经设置完毕(小四号宋体)。】扼要概括论文主要设计了什么内容，如何设计的，设计效果如何。语言精练、明确，语句流畅；英文摘要须与中文摘要内容相对应；中文摘要约400-500个汉字，英文摘要约300-450个实词；关键词要反映毕业设计说明书（论文）的主要内容，数量一般为4-6个。

设计类论文的摘要：应有类似的文字：（1）本设计的依据和意义的简要描述（2）采用什么方法（面向对象的方法或软件工程的方法）进行需求分析、总体设计，详细设计、实现了哪些重要的功能。（3）（如果有这部分内容的话）设计过程中对什么问题进行了研究，提出了什么新的思路或者方法（4）系统设计或者研究达到了什么目标。

研究类论文的摘要：（1）本课题的依据和意义的简要描述（2）对哪些算法或者方法进行了哪些研究（3）提出了什么新的思路或者方法，或者对什么方法提出了改进思想（4）经过什么测试验证，证明了新的方法的可行性，或者效果等（4）研究达到了什么目标。

关键词：关键词1，关键词2，关键词3，关键词4，关键词5，关键词6

页眉设置：河南科技大学本科毕业设计论文

页码设置：前言之前部分用I，I，I…编号

从前言开始用阿拉伯数字1，2，3…编号，前言为第1页

BUSINESS RULE DISCOVERING AND RULE

ENGINE APPLICATION RESEARCH

ABSTRACT

【从这里键入英文摘要内容】

KEY WORDS：关键词1，关键词2，关键词3，关键词4，关键词5，关键词6

目录

前言 ............................................................................................................... V 第1章标题. (2)

§1.1 为什么要提出业务规则方法 (2)

§1.2 业务规则入门 (3)

§1.2.1 什么是业务规则 (3)

§1.2.2 业务规则方法的基本原则 (3)

第2章业务规则发现及管理 (5)

§2.1 业务规则的发现方法 (5)

§2.1.1 业务规则的功能分类 (5)

§2.1.2 业务规则的一般分类 (5)

§2.1.3 规则描述的方法 (5)

§2.2 管理业务规则 (6)

第3章业务规则引擎及其应用 (7)

§3.1 业务规则引擎介绍 (7)

§3.1.1 规则引擎产生的背景 (7)

§3.1.2 规则引擎的工作原理 (7)

§3.2 规则引擎的工作过程和应用方法 (7)

第4章基于Spring框架的规则引擎 (8)

§4.1 J2EE中的Spring时代 (8)

§4.1.1 轻量级Spring框架介绍 (8)

§4.1.2 Spring框架与重量及侵入式框架EJB比较 (8)

§4.2 基于Spring框架设计规则引擎 (8)

第5章基于规则引擎的虚拟银行贷款申请系统实现 (9)

§5.1 功能需求 (9)

§5.2 业务规则发现 (9)

§5.3 基于业务规则贷款申请系统设计 (9)

§5.3.1 Struts设计表示层的UI界面 (10)

§5.3.2 Spring完成业务逻辑层的设计 (11)

§5.3.3 Hibernate完成贷款申请对象的持久化 (11)

§5.3.4 Spring容器来绑定组件 (11)

结论 (12)

参考文献 (13)

致谢 (15)

附录 (16)

符号说明

【从这里输入符号说明，标题下空一行写内容。】

毕业设计说明书（论文）中所用主要符号表示的意义及单位，此项为可选项目。

前言

【从这里输入前言，前言格式不需要修改，标题下空一行写前言内容。】前言应说明本课题的意义、目的、研究范围及要达到的技术要求；简述本课题在国内外的发展概况及存在的问题；说明本课题的指导思想；阐述本课题应解决的主要问题和采用的研究方法，要求自然、概括、简洁、确切。在文字量上要比摘要多。

标题

为什么要提出业务规则方法

标题下空两行写内容。正文各章、节、小节与前面的标识之间均空一格，每节、小节均与前面内容之间空一行。标题不要多于三级（1.1.1），若需要有四级标题，则用1，2，3…来表示。如：

1.业务问题的解决

如果在编码时解决所有的业务问题，就不会满足时间底线的要求，导致项目交付日期一次次的调整。如若主要需求中途不断改变，将会导致无休止的返工。有些项目看起来从一次死锁到另一次死锁，有些项目被轻易地打断，“总是在修改，但从来不策划”是普遍现象。即便成功交付，业务逻辑被固化到代码中，使后期的维护工作变得代价高昂和困难。

2. IT驱动的业务

现在业务和IT的运营已经不能分开，在承担项目时，合乎逻辑的步骤就是把业务和IT项目团队无缝地组织到一起，要求他们根据面向业务地方法开发需求。但是很多公司却没有注意这一点，业务人员编写着模糊不清、重点不明地“需求”，IT人员还在对这些“需求”有一点点了解就开始编程。

如果是陈述问题的几个项目，直接使用带括号的项目符号，比如：

业务规则方法的基本原则：

（1）规则应该被明确地记下来。

（2）规则应该用简明的语言描述。

（3）规则应该独立于规程和工作流程而单独存在。

（4）规则应该建立在事实的基础上，事实应该建立在由术语表达的概念的基础上。

（5）规则应该以所期望的方式指导或影响行为。

（6）规则应该由可识别的重要业务要素驱动。

（7）规则应该能够供被授权的部门使用。

（8）规则应该只有一个来源。