TRIZ技术系统演进视角的计算机辅助创新软件体系架构

李牧南，熊俊霞，许 治，苏锦钿

0 引言

随着各种新材料、新技术的发展，以及消费需求的不断多样化和个性化，工业和服务业新产品的开发变得越来越复杂。同时，随着市场竞争的加剧，新产品开发也面临更高的技术和市场风险。因此，作为新产品开发重要的支撑平台——计算机辅助创新软件（Computer Aided Innovation，CAI），就面临着不断更新和适应新需求的挑战。例如在当前的工业设计中，模糊前端的设计思想需要集成更多不同领域的知识库，有些制造性企业甚至提出能否在新产品设计阶段就导入六西格玛、精益制造等思想；此外，工业设计如何进一步满足新产品开发过程中的用户需求建模、团队协同创新、知识管理与知识沉淀等，这些新增需求都给传统的计算机辅助创新平台（软件）的体系架构提出了更高的要求。传统CAI软件的体系架构需要不断进化和变革，以构建更加开放、柔性、可扩展的CAI软件。本文从发明问题解决理论（Theory of Invention Problem Solving，TRIZ）的技术系统进化理论出发，从一个较新的视角探讨了软件系统架构的技术演化路径，并结合当前国内外主流的CAI软件的体系架构特点，提出了基于面向服务架构（Service－Oriented Architecture，SOA）的新一代CAI软件体系架构设计的总体解决思路和设计框架。

软件体系架构的演化始终紧跟着计算机硬件、网络技术、管理技术和软件技术自身的发展。软件开发依然是目前人类生产实践中最复杂的团队协作活动之一。软件工程作为一种复杂的系统工程，其目的就是为了降低软件开发过程的风险和成本，保证项目或者产品开发进度和质量。软件体系架构设计是整个软件工程的核心环节。首先，软件体系架构设计包括对用户或者产品设计需求进行分析，构建组织业务流程模型，以及对系统（产品）各模块之间的交互任务和通信接口进行准确定义等重要内容［1］；其次，体系架构是后续的详细设计，是代码和测试的基准性参考。根据国外软件工程的应用实例调查，需求工程和体系架构设计的潜在缺陷在后续阶段会逐渐放大，甚至导致软件项目彻底失败。举一个极端例子，假设在设计阶段没有考虑到用户的分布式需求，以及客户端操作系统的差异，系统功能实现采取了传统的客户机／服务器（Client／Server，C／S）架构，可能导致最终上线之后的软件产品出现巨大的客户端版本控制和协调问题，以及并发响应所带来的性能问题，此时整个系统可能面临推倒重来的风险。

1 软件体系结构的技术系统演化分析

在软件工程的实施中，由于存在“缺陷放大”效应，对软件架构设计的灵活性、动态性，甚至自适应性都提出了较高的要求［2］。因此，软件系统的设计需要采用符合技术系统进化方向的设计理念和技术，延长软件产品自身的发展期和成熟期，从而获得更好的推广和经济效益。

1.1 基于TRIZ技术系统进化法则的软件体系结构进化路径分析

TRIZ之父阿奇舒勒通过对专利技术的分析发现，所有技术系统的进化并非完全遵循随机性原则，而是遵循一定的规律或法则，这就是TRIZ归纳和总结的技术系统8大进化法则［3－4］。目前，TRIZ与软件工程、管理理论与方法等领域的结合，也是比较热点的研究［5－8］。结合基于 TRIZ的8大技术系统进化法则，这里以其中3个原则为例，分析软件体系架构的技术演变轨迹。

1.1.1 理性度的趋近法则

TRIZ认为“向最终理想化”方向进化是所有技术系统始终遵循的法则。软件体系架构作为一个技术系统，从诞生到发展的过程，也可以认为是完全按照该进化原则进行。一般来说，理想度的表示公式为［3－4］

对于软件系统来说，以最低的成本和代价满足用户的需求和功能，减少系统的不稳定性，增加系统的可扩展性和可维护性，一直是软件工程的目标。软件体系架构从最初的胖客户端到瘦客户端，从面向对象到面向组件，从传统的两层（C／S）到三层体系（C／S／S），以及 N－tier的体系结构的演变都是这种理想度法则进化的结果。

软件体系架构作为软件工程最大的复用构件，其进化的目标就是提高软件的复用水平、提高软件整体的成产效率、降低成本，并提高系统整体的功能和性能水平。

1.1.2 增加系统动态性与可控制性法则

TRIZ关于增加系统动态性与可控制性的法则包括三个具体演化方向［3］：①增加系统柔性；②增加系统可移动性；③增加系统可控制性。软件系统架构从当初的机器语言、汇编语言架构，一直到今天的面向对象、面向Agent、面向服务的体系架构，可以清晰地看到向这三个方向的演化进程。例如机器语言体系架构—汇编语言体系架构—结构化编程体系架构—面向对象体系架构，就是不断增加系统柔性和可控性的过程。“面向对象→面向构件→面向A－gent”的路线显然是体系架构在向增加系统移动性方面的进化努力。

1.1.3 增加集成度再进行化简法则

这条技术进化原则认为技术系统首先会趋于结构复杂化，例如：通过增加系统构件数量来提高系统的功能，然后再逐渐简化系统。面向对象的软件技术出现的目的之一就是为了满足功能需求不断增长的需要。当人们日常的工作和生活越来越依赖软件系统时，如银行、电信、航空和政府等主要部门开始实施信息化时，传统结构化编程的模式无法满足如此复杂的功能需求。面向对象技术的发展衍生了基于构件的软件体系架构，可以将功能需求经过分解后，以构件（J2EE中的Java企业柄（Enterprise JavaBean，EJB）、COM＋、公共对象请求代理结构（Common Object Request Broker Architecture，CORBA）等）的方式进行集成和组合。尽管单纯进行业务功能封装的方式满足了复杂的功能性需求，但是也逐渐面临着巨大的性能和维护风险。软件工程架构师不得不将原来粒度较大的构件重新进行分解，并开始考虑利用客户端的计算资源，这就是分布式软件架构思想的出发点之一，例如面对海量的互联网下载任务事件，P2P技术就是通过简化服务器端构件的设计复杂性，充分利用客户端的计算和网络资源，从而提高整体的文件下载效率。体系架构集成再简化的路径示意图如图1所示。

面向对象技术诞生以来，出现了以微软和SUN公司为代表的两种主流开发语言和工具提供商，也出现了微软COM＋与SUN公司的EJB组件如何兼容和交互的问题。SOA的出现正是出于对这些异构组件集成的需要，通过采取基于标准的 Web service封装和简单对象访问协议（Simple Object Access Protocol，SOAP）实现异构组件之间的访问和交互。

1.2 基于技术系统进化法则的软件体系架构进化模式

从软件体系架构发展的历史来看，至少可以找到TRIZ技术进化规则中的3条来较好地描述软件体系架构进化的趋势。根据这3条进化规则以及软件体系架构的演化历史，软件系统架构技术的进化模式如图2所示。

从图2可以看出，当前软件系统架构技术进化的路线与TRIZ技术系统演化的规则基本吻合，同时当前主流的系统架构是具有工业标准的SOA和相关技术［9－10］。随着互联网技术的发展，以及现有信息系统之间通信的需求，具有支持标准化、跨平台、异构组件之间通信、松耦合和高复用等特点的SOA思想逐渐成为软件体系架构设计的主流思想之一。不可否认，尽管与传统的面向对象／组件架构相比，SOA出现的时间还不长，尚不能完全取代传统的面向对象的体系架构设计。对于基于SOA的应用来说，尽管当前还存在.Net和J2EE两种主流应用框架的异构问题，但是面向服务的思想已经逐渐得到了软件工程领域的广泛认可。尤其是随着云计算、物联网、普适计算等多种跨平台、计算终端异构等应用场景的出现，SOA架构无疑具有更广阔的应用前景。例如：在一个典型物联网应用系统中，支持无线射频识别（Radio Frequency Identification，RFID）读写的程序或者设备可能是基于传统的C语言的应用，企业的企业资源计划（Enterprise Resource Planning，ERP）系统则采用J2EE架构，而企业的邮件或者OA系统又是基于微软的.Net技术架构，此时如何实现不同信息系统之间的交互、整合和复用，SOA模型就是一个目前为止比较有效的解决方案。尽管SOA还存在服务模块之间协同性差、缺乏主动任务发现机制和横向关注点支撑等问题，但是依然代表目前软件体系架构发展的方向［9］。

本文对SOA的定位可能存在一定争议，有学者或许会认为面向Agent体系架构（Agent－Oriented Architecture，AOA）应该是更为先进的体系架构。实际上，AOA思想的出现比SOA思想早10年左右，但是长期以来缺乏工业化应用和行业标准的支持，以及各种Agent平台之间的融合问题，导致AOA难以真正走向行业和企业级应用［11］。不可否认，AOA在系统的适应性、协作性、反应式系统等领域优于SOA的思想，但是SOA具有简洁、直观和容易实现的特征，因此当前基于SOA的行业应用比AOA广泛得多［12］。

2 当前主流计算机辅助创新软件的特点及其体系架构分析

CAI技术是将TRIZ理论、现代工业设计、自然语言处理和计算机软件技术融合的一种新技术，可以简单表示为［5］

一般认为影响创新的主要因素有［4］：①客观规律发现的困难；②问题发现的困难；③设计者的个人偏见和思维定势；④个人掌握的知识和能力的局限性。CAI的目标就是帮助设计者克服思维定势，从全新的观念出发，朝着理想解的方向筛选出最佳方案，从而节省资源，高效完成设计任务，实现技术突破和创新，完成相关专利申报和知识管理工作。

CAI软件的一个鲜明特点就是集成现有的创新理论和方法，其中最主要的创新理论就是TRIZ，具体的技术包括［5］：创新问题分析、定义和转换技术、语义分析与类比技术、标准解到特定解法的二级类别技术、效应知识库技术、专利查询与数据挖掘技术、方案评价技术等。IT信息化技术包括CAI软件平台软件的设计与开发技术等。

当前主流的CAI软件都将TRIZ理论作为主要的创新理论，在软件设计过程中实现发明问题分解、效应分析、标准解类别、特定解类比、专利知识库查询等基本功能，从几款主流CAI软件的发展阶段来看，基本上还是处于面向对象技术发展的中期技术水平。几款主流的CAI软件发展阶段及特点对比如表1所示。

表1 部分主流CAI软件一览表

从表1可以看出，主流的CAI软件产品由于历史原因发展到今天主要采取面向对象的编程思想，体系架构主要表现为两层架构（C／S，B／S）。尽管大部分CAI软件提供的主要是单机版本工具，但实际上还都是“标准客户端编程＋数据库”的架构，如果把数据库独立出来，如数据库部署到SQL Server和Oracel等大型数据库，则变成了典型的C（B）／S架构。

3 基于SOA的CAI软件体系架构设计

SOA是面向对象技术在软件体系架构领域的一大发展。SOA的出现主要解决基于网络／互联网环境下，多个异构系统之间的代码复用和交互问题。面向对象技术的发展衍生了EJB和COM＋两大基本构件，而这两种构件由于开发环境和语言不通，很难实现功能继承和代码复用。如何实现这些异构组件和功能模块之间的复用和交互，最大程度地保护已有软件资产的投资，需要采用一种更大粒度的功能组件和更加普适的通信协议，这就是SOA的基础部件 Web service和SOAP。显然，SOA架构的出现最大程度地保护了原有系统的功能价值，实现了基于互联网层自由访问和信息共享。因为SOAP实际上是运行在超文本传输协议（HyperText Transfer Protocol，HTTP）之上的应用，可以规避大部分网络安全策略和防火墙的拦截，同时具有较高的访问安全性，所以得到了软件工程界的重视。近年来，随着云计算和物联网应用的兴起，软件支撑部分更加需要跨平台的通信和协作，因此基于SOA的软件系统设计思想在云计算中的地位和作用愈加凸显和重要，但是两者之间究竟是存在竞争还是逐步走向融合，目前还没有最终的定论［13］。

3.1 基于SOA架构的CAI软件系统的特点分析

从用户需求不断发展变化的角度看，进一步提升CAI软件的开放性、柔性和可扩展性，在CAI软件的体系架构设计中显得极为重要。基于SOA的体系架构最大程度地降低了传统CAI软件客户端安装和维护的成本，提高了用户访问的便捷性。在一个互联网和移动通信技术高速发展的时代，对软件和计算资源的访问已经从传统的PC扩展到手机、平板电脑等移动计算设备，而SOA的架构保障了跨平台和异构网络环境的高效访问和数据交互。随着系统功能的服务化和虚拟化，基于SOA的CAI软件为更大范围内协同创新的计算辅助“云”的建设和资源整合提供了条件。与目前主流的传统CAI软件相比，基于SOA的CAI软件的优势如表2所示。

表2 基于SOA的CAI软件与传统CAI软件的对比分析

在工业产品的设计流程中，CAI软件的主要目标不仅是辅助用户完成产品的创意和概念设计，还广泛用于技术设计、参数设计、工艺设计中。因此，CAI软件设计和开发是一个涉及认知心理学、创新科学、软件工程和人因工程等多个学科和知识领域的复杂系统工程［14］，同时在整个新产品设计流程中，CAI软件又是一个几乎贯穿整个新产品设计过程的辅助支撑平台，如图3所示。

从图3可以看出，CAI软件首先需要接收新产品的需求，由于需求的文字表述等问题，在录入用户产品需求描述内容时，有必要考虑接口的规范和描述文档内容的规范问题。另外，因为很多产品需求分析可能来自其他软件系统，所以在接收产品需求功能模块时需要考虑灵活的接收、查询和内容校验机制。其次，作为经过CAI软件过滤和筛选过的创意以及产品概念雏形可能有多个，而且一个产品创意可能仅为某种迭代设计的中间产物，因此CAI的输出接口应该是可以交互的，即当前即使处于产品的详细设计阶段，依然可以回溯和查询创意筛选的结果数据，反馈详细设计可能存在的矛盾和问题。第三，在产品走向市场后，最终用户可能会提出对原始概念和创意部分进行修正和部分改动，因此如何考虑用户意见的反馈也是未来CAI软件需要考虑的问题。

SOA的软件体系把系统主要的交互接口和业务逻辑功能封装成统一的“服务”，而这种服务可以实现跨平台的访问和交互，系统内部之间采取松耦合，有利于多个不同知识结构和开发背景的人员协同开发。

3.2 CAI软件发展和进化趋势分析

根据上述关于软件体系架构技术路线图和基于TRIZ的技术进化规则的分析，可以发现SOA的软件体系架构符合当前软件技术发展和进化的方向。基于SOA的体系架构可以满足功能即服务的需求，又是与其他创新设计理念融合、交互的重要基础。近年来，有学者提出了TRIZ与质量功能配置（Quality Function Deployment，QFD）、综合集成、公理化设计等理论的融合，以及CAI、产品生命周期管 理 （Product Lifecycle Management，PLM）和CAx等系统相互整合的概念，这些都对现有CAI软件的开放性和模块的松耦合性提出了更高的要求［15］。在现有面向对象编程框架下，基于SOA的架构可以最大程度地保护已有代码和功能模块，并实现对既有代码的复用。同时，在当前的互联网背景下，如何运用最新的互联网理论和技术实现更广泛的协同创新支撑，也是下一代CAI软件系统需要关注的热点之一［16］。

3.3 基于SOA的CAI软件体系结构设计框架

基于SOA的软件系统通过功能分解后再封装，有利于降低开发难度和提高效率，同时所有功能模块的标准化封装、松耦合性结构也降低了后续的维护难度，还可以最大程度地复用现有的代码和模块。这里提供一个基于TRIZ理论的CAI软件的架构设计框架。基本功能需求参考主流软件已有的模块。一般基于SOA架构的简单形式化表示可以参考式（3），简单的结构示意图可以参考图4。

3.3.1 SOA体系的基本技术和协议

面向服务的体系架构模型所涉及的基本技术和协议主要有以下三个方面的内容：

（1）Web服务描述语言（Web Services Description Language，WSDL） 用来描述 Web服务和说明如何与 Web服务通信的可扩展标记语言（eX－tended Markup Language，XML），为用户提供详细的接口说明书。

（2）简单对象访问协议 SOAP是一种轻量的、简单的、基于XML的协议，它被设计成在 Web上交换结构化和固化的信息。SOAP最大的优势在于可以和现存的许多因特网协议和格式结合使用，包括 HTTP、简单邮件传输协议（Simple Mail Transfer Protocol，SMTP）等。SOAP还支持从消息系统到远程过程调用（Remote Process Call，RPC）等大量的应用程序。

（3）统一描述、发现和集成协议（Universal Description，Discovery and Integration，UDDI）UDDI其实是一种目录服务，企业可以使用它对Web services进行注册和搜索。程序开发人员通过UDDI机制查找分布在互联网上的 Web service，在获取其WSDL文件后，就可以在自己的程序中以SOAP调用的格式请求相应的服务。

3.3.2 SOA架构设计约束

（1）Service Provider设计约束

Service Provider设计其实就是传统的面向对象构件（组件）设计的升级，但是服务粒度的设计依赖外部调用约束（Invoke）和内部交互约束两个方面的约束。

（2）Service Invoker设计约束

服务调用或者消费设计需要考虑服务发现的效率，以及参数的可读性、响应的效率和安全性问题。

（3）Service Registry设计约束

一般服务发布和注册需要考虑在UDDI中心披露更多实质性的功能描述和说明，使其他开发者或者服务消费者能够快速浏览和引用，即获取的 WSDL文件能够快速地被集成到使用者的模块中。

3.3.3 基于SOA的CAI软件设计框架

软件体系架构设计包括哪几个部分，目前还没有统一的定义。例如：CMM（capability maturity model for software）规范体系认为体系架构设计是概要设计（High level）的一部分，而又有学者和机构认为体系架构设计应该在概要设计之前，是软件工程中一个独立的阶段，架构设计是概要设计的基础，是对用户需求进行建模分析和对系统总体结构进行规划的重要阶段。体系架构设计的输出应当包括系统的需求模型、系统逻辑结构、子系统或模块构成、模块之间通信协议或机制、用户与系统界面原型、业务流程建模与校验、系统测试流程与用例、数据与代码规范、开发工具与语言、硬件与网络资源要求与说明和风险控制策略。限于篇幅，本文只给出CAI软件的需求描述、系统逻辑结构设计、主要的业务流程设计、Use－case设计和一个功能服务模块的对象化设计。

（1）功能需求分析 根据当前主流CAI软件的功能框架，以及TRIZ解决发明问题的流程和思路，CAI软件系统的需求经过分析和整理后，主要有如下几个需求点：

1）发明创新问题的接收、转化、定义、分解。

2）资源约束矛盾和冲突的分析和技术进化分析。

3）物－场分析与标准解映射，一级类比。

4）标准解到基于领域知识的特定解。

5）效应知识库。

6）创新案例知识库。

7）专利检索与挖掘。

8）创新案例库。

9）解决方法和路径评价。

10）效果反馈。

（2）系统逻辑结构设计 采用基于SOA的软件系统，一般可以采取top－down的设计方式。基于top—down设计方式的CAI软件系统的逻辑架构示意图如图5所示。

（3）部分主要Use－case设计 系统部分的Usecase设计图如6所示。

（4）主要业务流程设计 主要的业务流程参考TRIZ理论关于创新和发明问题的解决流程进行设计，具体设计如图7所示。

（5）对象与组件层设计实例分析 对象与组件层设计部分已经覆盖了详细的设计部分，这里给出专利查询服务功能的组件设计简化示意图，如图8所示。

基于图8的组件层设计之后，Web service封装后的WSDL和服务浏览窗口如图9所示。

4 结束语

CAI软件系统作为当前TRIZ应用和推广的重要辅助工具和平台，国内外都比较缺乏针对其软件体系架构、软件开发技术演化路径和方向的研究。一方面，由于当前国内外主流CAI软件供应商的商业秘密保护策略；另一方面，国内外研究CAI软件的机构大多数以TRIZ咨询公司，或者TRIZ与创新理论研究机构为主，缺乏对软件系统架构、软件技术演化等领域的关注和研究的专业激励。本文是广东省创新方法与决策管理系统重点实验室的一个前期科研成果，是建立在对当前国内外主流CAI软件充分调研基础上的概览性成果。

本文的主要创新有两点：①从TRIZ技术系统演进的视角分析了当前主流CAI软件体系架构发展的现状，并根据软件体系架构技术发展的技术系统演化规则，提出了基于SOA的新一代CAI软件系统设计思想；②从软件工程架构设计的角度，综合当前国内外的主流CAI软件产品功能模块，给出了一个具有一定参考价值和工程实践意义、基于SOA架构的下一代CAI软件设计框架。

限于篇幅和笔者的研究水平，这里给出的设计框架还需要进一步细化，真正落实到具体的CAI软件系统中，这也正是下一步研究的重点内容之一。

［1］ TAYLOR 段 ，MEDVIDOVIC N，DASHOFY E.Software architecture：foundations，theory，and practice［M］.Hoboken，N.J.，USA：Wiley Publisher，2009.

［2］ QIN Zheng，XING Jiankuan，DONG Jinchun，et al.Software architecture［M］.2nd ed.Beijing：Tsinghua University Press，2008（in Chinese）.［覃 征，邢剑宽，董金春，等.软件体系结构［M］.2版.北京：清华大学出版社，2008.］

［3］ TAN Runhua.Theory of inventive problem solving［M］.Beijing：Science Press，2004（in Chinese）.［檀润华.发明问题解决理论［M］.北京：科学出版社，2004.］

［4］ FEY V，RIVIN E.Innovation on demand［M］.Cambridge，UK：Cambridge University Press，2005.

［5］ MA Jianhong，LI Juan，TAN Runhua.Development of a computer aided inventive problem solving system—Invention Tool 2.0［J］.Journal of Hebei University of Technology，2004，33（4）：1－6（in Chinese）.［马建红，李 娟，檀润华.计算机辅助创新设计系统——Invention Tool 2.0开发［J］.河北工业大学学报，2004，33（4）：1－6.］

［6］ DELOACH 段 ，PADGHAM L，PERINI A，et al.Using three AOSE toolkits to develop a sample design［J］.International Journal of Agent－Oriented Software Engineering，2009，3（4）：416－476.

［7］ BONNEMA 段 .TRIZ for systems architecting ［C］／／Proceedings of the ETRIA World TRIZ Future Conference.Amsterdam，the Netherlands：Elsevier，9：702－707.

［8］ WANG Suhua，DURGESH S，CHEN Dengjie.Software development and quality problems and solutions by TRIZ ［J］.Procedia Computer Science，2011，5：730－735.

［9］ LING Xiaodong.A review of SOA ［J］.Computer Applications and Software，2007，24（10）：122－125（in Chinese）.［凌晓东.SOA综述［J］.计算机应用与软件，2007，24（10）：122－125.］

［10］ LIU Min，YAN Junwei.Study on SOA based grid manufacturing and its architecture［J］.Journal of Tongji University：Natural Science，2007，35（2）：239－243（in Chinese）.［刘敏，严隽薇.基于SOA的网格化制造模式及体系结构［J］.同济大学学报：自然科学版，2007，35（2）：239－243.］

［11］ MAO Xinjun.State－of－the－art，challenges and prospects of Agent oriented software engineering［J］.Computer Science，2011，38（1）：1－6（in Chinese）.［毛新军.面向Agent软件工程：现状、挑战与展望［J］.计算机科学，2011，38（1）：1－6.］

［12］ CABRI G，LEONARDI L，PUVIANI M，et al.Comparing service－oriented computing and Agent－oriented programming towards integration ［J］.Web Intelligence and Agent Systems，211，9（2）：135－146.

［13］ ZHU Zhiliang，YUAN Haitao，SONG Jie，et al.SOA and clouding computing：competition or integration［J］.Computer Science，2011，38（12）：6－11（in Chinese）.［朱志良，苑海涛，宋 杰，等.SOA与云计算：竞争还是融合［J］.计算机科学，2011，38（12）：6－11.］

［14］ LIU Xiaoying，LI Yan，PAN Peiyuan，et al.Research on computer－aided creative design platform based on creativity model［J］.Expert Systems with Applications，2011，38（8）：9973－9990.

［15］ LEON N.The future of computer－aided innovation［J］.Computers in Industry，2009，60（5）：539－550.

［16］ HUSIG S，KOHN S.“Open CAI 2.0”— Computer Aided Innovation in the era of open innovation and Web 2.0［J］.Computers in Industry，2011，62（4）：407－413.

［17］ KLUENDER D.TRIZ for software architecture［J］.Procedia Engineering，2011，9：708－713.