《未来软件开发及主流方向》由会员分享，可在线阅读，更多相关《未来软件开发及主流方向（8页珍藏版）》请在金锄头文库上搜索。
1、未来软件开发的主流方向：规则引擎2011-02-12 11:33 作者： 出处：天极网开发频道责任编辑：郑重规则引擎 (Rule Engine)介绍规则引擎起源于基于规则的专家系统，而基于规则的专家系统又是专家系统的其中一个分支。专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。利用它就可以在应用系统中分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时可以动态地管理和修改，从而为企业保持灵活性和竞争力提供有效的技术支持。简单地说：让程序的业务逻辑可以通过规则
2、配置进行处理。.NET 下的开源规则引擎有：序号：1规则引擎：Drools.NET介绍说明：Drools.NET 是 .NET 版的 Drools，基于 Charles Forgy 的 RETE 算法的开源的业务规则引擎。官方地址：http:/droolsdotnet.codehaus.org/序号：2规则引擎：SRE介绍说明：SRE (Simple Rule Engine)是.NET 下的一款轻量级的开源正向串行的推理规则引擎(forward chaining inference rule engine)。它容易理解，可以解决复杂的问题。官方地址：http:/ 是.NET 平台下的一款开源轻
3、量级的业务规则引擎(aka Rule Based Engine)，它由正向串行的推理引擎(forward-chaining inference engine)和 XML 驱动流控制引擎(XML-driven flow control engine)组成.它支持 RuleML 0.9 Naf Datalog 和 Visio 2003 建模。官方地址：http:/ 下的开源规则引擎有：序号：1规则引擎：Drools介绍说明：Drools 是 Java 语言开发，基于 Charles Forgy 的RETE 算法的开源的业务规则引擎。官方地址：http:/www.jboss.org/drools/序
4、号：2规则引擎：Jamocha介绍说明：Jamocha 是一个 Java 语言开发的开源规则引擎。官方地址：http:/ 信息元(Information Unit)信息元是规则引擎的基本建筑块，它是一个包含了特定事件的所有信息的对象。这些信息包括：消息、产生事件的应用程序标识、事件产生事件、信息元类型、相关规则集、通用方法、通用属性以及一些系统相关信息等等。2) 信息服务(Information Services)信息服务产生信息元对象。每个信息服务产生它自己类型相对应的信息元对象。即特定信息服务根据信息元所产生每个信息元对象有相同的格式，但可以有不同的属性和规则集。需要注意的是，在一台机器上
5、可以运行许多不同的信息服务，还可以运行同一信息服务的不同实例。但无论如何，每个信息服务只产生它自己类型相对应的信息元。3) 规则集(Rule Set)顾名思义，规则集就是许多规则的集合。每条规则包含一个条件过滤器和多个动作。一个条件过滤器可以包含多个过滤条件。条件过滤器是多个布尔表达式的组合，其组合结果仍然是一个布尔类型的。在程序运行时，动作将会在条件过滤器值为真的情况下执行。除了一般的执行动作，还有三类比较特别的动作，它们分别是：放弃动作(Discard Action)、包含动作(Include Action)和使信息元对象内容持久化的动作。4) 队列管理器(Queue Manager)队列
6、管理器用来管理来自不同信息服务的信息元对象的队列。未来应用规则引擎的趋势商业世界充满了关于变化的陈词滥调，如任何事物都会改变，唯一不变的是变化等等。而在技术领域里，情况正好相反。我们仍然在试图解决 30 年前软件业中同样的一堆问题-也许比 30 年前还要多的问题。在过去的十年，IT 从业人员淹没在软件方法学的大量文献中，如快速软件开发，极限编程，敏捷软件开发等，它们无一例外地强调灵活和变化的重要性。但商业通常比开发团队所依赖的软件过程和技术改变得更加迅速。当商业策划人员试图重整 IT 部门，以支持新的业务转型时，仍然觉得很费劲。哪些软件项目正在使用规则引擎目前中国移动的 BOSS 系统、企业应
7、用的 ERP、CRM 以及电子商务的销售系统等。软件工程会如何发展？我觉得在未来几年我们会看到如下的趋势： 需求工程，渐成热点：专业化的角色，日益复杂的业务创新，全球分布的团队以及互联网级的交付速度，这些都对需求获取的正确性和有效性提出了更高的要求；我预计需求工程的研究和实施会成为近期的热点，其中 Use Case 技术会被更广泛而正确的应用，而相关工具的研发也会成为热点（如 IBM Rational Requirements Composer、Ravenflow 等）。用例的优势在于它天生是黑盒的，它用自然语言抽象了用户和目标系统的交互，避免了混入分析、设计和实现细节，以保证用例可以被不懂具
8、体技术的业务及测试人员所真正理解。同时，需求分析员又可以方便地通过用例分析（即用分析类来试图在理想方式下实现用例），将需求体系精华成分析模型。在这一过程中，需求分析员可以更进一步地完善基于用例的需求体系，而不必担心分析模型会污染需求，从而实现需求与分析的分离及有效互动。 DSSA 和MDD，老树新花（基于领域的构架DSSA与模型驱动的开发MDD）：随着软件应用的日益普及，软件已经超出了将手动流程自动化的范畴，而开始成为业务创新的主要推动力。因此，引入捕获特定领域内最先进需求及其实现架构的 DSSA 成为行业客户的热点之一。而且，DSSA 的引入将 MDD 门槛大大降低了，也使基于 DSSA 的
9、 MDD 支撑工具成为可能，从而可以极大地提高开发效率并保证软件质量（例如，Telelogic 的 Rhapsody 就是一个成功的基于实时嵌入式系统构架的 MDD 工具）。 迭代/敏捷，渐成标准：随着软件交付周期的日益加快，迭代化开发已经成为大多数软件开发团队的必选项。但是迭代对整个团队的需求、架构、协同及测试能力都提出了更高的要求，现在许多开发团队都在试图导入迭代化开发的过程中，敏捷可以是被看成迭代化开发的一种导入方式，只不过敏捷的范围其实比迭代化开发更大一些。敏捷的三个要素是迭代开发、坦诚合作和自适应性。坦诚合作其实才是敏捷的精髓，如Ivar 所说，敏捷其实是有关 Social Engi
10、neering 的。敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。 持续集成，蓄势待发：持续集成是保证迭代化开发质量的主要方式，通过持续集成可以利用自动化的方式来尽量自动地、尽早保证代码质量。随着迭代和敏捷的流行，持续集成相关的工具成为现在市场上的新热点（如持续集成框架 IBM Rational BuildForge, 开源软件CruiseControl，代码静态分析工具 Klocwork Insight，IBM Rational Software Analyzer 等）。持续集成是一个复杂的系统工程，组织需要首先将现有的配置管
11、理/变更管理工具与 Build 环境紧密集成并完成自动化 Build 过程，在根据企业/项目/产品的现状，定义如何自动化地检测软件质量(代码静态分析、单元测试或冒烟测试) ，并定义需要自动化生成的管理报表。 基于实践的过程框架，方兴未艾：开发角色的专业化的和分布的全球化都要求软件开发过程更加规范，而敏捷又要求过程必须紧密贴合项目的实际需要，因此传统的大一统的过程无法符合这一需求。新一代的过程将是以实践为核心的，项目可以通过组装所需的不同实践来获得贴近项目要求的过程。IJI（Ivar Jacobson International）的 EssWork 框架和 IBM Rational的 RMC 都
12、是新一代的基于实践的过程框架。依据过程专家长时间的经验，他们很小心、很仔细地将一个完整的开发过程组件化，从开发过程抽象出一个个可以被单独导入又可以被组装到一起的实践，从而使逐步求精式的过程改进成为可能。对于一个软件组织而言，如果已经建立一个比较成熟的软件开发流程，但觉得这一流程并不适合所有项目的实际需要，那么目前可以考虑的是用实践的方式去重新梳理现有流程，以使项目组能够以实践为单位来组装出切合项目实际的流程；另外，该组织也可以将适用于本组织的业界流行的实践导入到现有流程当中，IJI 公司的专家从业界最佳经验中抽取了八个实践,配置管理.昨日黄花：随着开发团队规模的日益减小，配置管理的复杂性大大降
13、低了，我们注意到越来越多的用户转向使用开源的配置管理工具（如 Subeverison，JIRA ，hosted-projects 等等）；未来的配置管理工具更多的以一种全生命周期管理平台（Application Lifecycle Management）的方式出现，弱化了单项的配置管理能力而强调了全流程的整合（如 Microsoft VisualStudio Team System 和 IBM Rational Team Concert 等）。即便配置管理的复杂性降低了，但它仍然是开发项目管理的最重要的支撑平台之一。目前的重点应该是加强对项目经理进行有关配置管理知识的培训，让他们理解到配置管理能力（如并行开发、基线回退等等）能够如何帮助项目开发过程的，从而使配置管理工具/环境的价值能够得到充分的发挥。
